De athenticatie was Robert z'n inbreng, maar m.i. gaat het daar niet om.
De programmatuur kijkt domweg naar de Kontaktpersoon gegevens met ID van de user. Als ik hiér nu geen gelijk in heb is het een ander verhaal.
-> Wie ?

ChangeKey zal wel niet werken als je dit als eerste probeert met de Kontaktpersonen. Dus wees op je hoede als je dat pad op wilt.


Klopt. Maar ik denk dat het niet dit is wat je parten speelt. Zie mijn normalisatie verhaaltje aan het eind. Het gaat om het "algemeen" moeten kunnen addresseren van personen bij bedrijven, en dan kom je toch echt op de Kontaktpersonen uit ...
Dat iemand personeelsnummers adviseert in plaats van userids was in de betreffende (!) context wellicht niet onjuist. Immers, je moet er maar op zien te komen dat waar je (stel) 50 mensen personeel hebt waarvan 10 gebruikers, dat je iets als ene userid moet gebruiken voor het kontaktpersoon id. Het is ook niet formeel natuurlijk, zie ook het aangegeven verschil in het normalisatie verhaaltje. Dus, in het datamodel zou het niet staan, en het wordt procesmatig opgelost.

Uit het laatste volgt ook meteen de formele oplossing : een entiteit waarin je de email gegevens kwijt kan, plus verwijzingen vanuit alle plaatsen waar dit kan optreden. Dus Kontaktpersonen, Userids, en ook Adresgegevens (wat momenteel eveneens procesmatig is opgelost). Word je daar blij van ? tuurlijk niet. Je zit je het schompes te registreren, en nu werkt het ook. Maar ja -en inderdaad- zien (van uit logika) dat het zo moet kan je niet.
De "adviseur" is dan ook niet veel aan te rekenen, net zoals je het ons niet echt mag aanrekenen dat we het niet "slim" hebben opgelost. Immers, het is juist wel slim, maar past intussen niet in jouw plaatje.

Alles bij elkaar had dit de volgorde moeten zijn (niet dat dat prakrijk is, maar voor de lol toch wel) :
Hé, we hebben personeel. Mooi, die nemen we op bij de Kontaktpersonen van ons Bedrijds-id (pas op, want ook Bedrijfs-id is er zo één, waar immers niets 1zegt dat het wel handig is als deze Relatie (ja ja) overeenkomt met het Bedrijfs-id terwijl wel (heel) veel programmatuur ook daarop anticipeert. Vervolgens : hé we hebben ook users. Laten we het ID daarvan maar gelijk houden aan het ID van die Kontaktpersonen. Deze volgorde is juist, maar niet hanteerbaar (omdat je users moet hebbe om Kontaktpersonen in te kunnen vullen).

Om een lang verhaal niet nog langer te maken : voeg gewoon die Kontaktpersonen even opnieuw toe.


Maar laten we deze niet vergeten. Dus graag even een konfirmatie.

Ik denk dat het verhaal iets anders is ...

Ten eerste, het mailen in Profit is zo opgezet dat het de Kontaktpersoon bij een Relatie is die de email verstuurt dan wel ontvangt. Dit is misschien niet zo maar te raden, maar zo is het wel en dit is ook minder verkeerd als je denkt, als je eerst even normaliseert. Hieruit enkele puntjes :

Als iemand een email moet ontvangen, zal deze toch zeker niet als User (entiteit Gebruikers) in het systeem gedefinieerd moeten zijn ?
Juist.
Als iemand een email moet ontvangen, en dat gebeurt op een bepaald email adres, dan zal het toch niet zo zijn dat de feitelijk zelfde benodigde gegevens voor het versturen van een email plots nogmaals, en dan elders moeten of mogen worden geregistreerd (zoals bij de Gebruikers gegevens) ?
Juist.

Alleen al hieruit volgt dat het niet bij de Gebruikers hoort, en in elk geval bij de Kontaktpersonen mag.

Omdat webshop gebruikers redelijk anoniem zijn, en zeker geen Users (Gebruikers) als zodanig in Profit zijn, terwijl deze wel behoren in te loggen omdat ze uiteindelijk helemaal zo anoniem niet zijn (de gebruiker werkt bij een bestaande klant), en deze "gebruiker" emails toegezonden kunnen worden (Orderbevestiging, Pakbon, Faktuur), aangevuld met het gegeven dat zo'n gebruiker toch redelijk 1 op 1 is met een Kontaktpersoon zoals je die bij een Relatie zou definiëren, is het dus wederom juist dat de email gegevens bij de Kontaktpersoon zijn geregistreerd. Sterker, dat waren ze al redelijk eeuwig, om e.e.a. vanuit Profiit-Kontakt/-Mail te kunnen gebruiken.

Omdat er omwille van het laatstgenoemde domweg geen andere plaats te bepalen *is* (met als uitgangspunt dat de Kontaktpersonen zelf goed genormaliseerd zouden zijn opgezet (wat *niet* het geval is !), is de Kontaktpersoon de enige juist plaats, bepaald uit normalisatie.

Als je dan verder nog iets wilt als "ik als User in Profit wil iemand een Inkooporder emailen", dan is die "ik" helaas niets anders als een User (Gebruiker) die (wederom genormaliseerd) toevallig 1:1 overeenkomt met een Kontaktpersoon bij een Relatie (in mijn geval User PS bij Relatie Heart). Merk op dat dit niets anders is als een Debiteur die 1:1 tevens als Relatie is gedefinieerd, met weliswaar het verschil dat de Debiteur technisch niet zonder de relatie kan (funktioneel ook niet) terwijl de User technisch wel zonder de Kontaktpersoon kan (omdat dit funktioneel ook kan, zolang de betreffende gegevens maar niet zijn benodigd, en welke gegevens onmiddellijk nodig zijn bij aanwezigheid van Profit-Kontakt.

Wat er nu mis gaat met "personeelsnummers" kan ik niet vertellen (je legt immers niets uit), maar jullie zullen het personeel wel een Userid "ABC" hebben gegeven, met personeelsnummer "123". EN DIT IS ONJUIST.
Dit is al onjuist omdat het systseem nu niet zonder maatwerk kan bepalen dat User ABC dezelfde is als Kontaktpersoon 123, terwijl het systeem zoals het is erop anticipeert dat (andersom gezien) Kontaktpersoon ABC (bij bedrijf ADP = Bedrijfs-ID) wel de persoon zal zijn die achter het scherm zit met Userid ABC.

Mocht je nu enigszins in verwarring zijn en niet meer goed weten hoe de AMBI module (uit het hoofd) S4 in elkaar zat : De belangrijkste basis is hier het gegeven dat een niet-User een email gestuurd moet kunnen worden (da's logisch), terwijl diezelfde persoon als wel-user ook een email moet kunnen sturen. Er is geen verschil met beide gegevens groepen, en dus horen die in 1 entiteit (anders zou er pure redundantie volgen).

Zoiets ?

Ik heb er niet veel verstand van, maar ik kan me zo voorstellen dat als je dit soort gegevens openbaar maakt, een hacker er weer door komt.

Wilfred,

Sorry voor deze zeer late response, maar dat is mijn schuld. Ik zat er destijds naar te kijken en dacht "hier klopt iets niet" maar kon het op dat moment niet uitwerken. Nu, na jouw email aan Menno, kon dat wel.

1.
Je zult de Dos editor hier gebruiken op "e.o.a." onjuiste manier. Die moet via een .bat file worden aangeroepen, wat in jouw geval klaarblijkelijk niet gebeurt (maar in plaats daarvan ed.exe zal worden aangeroepen). Je mist nu de macro's die o.a. van F1 "Saven" maakt. Echter :
Middels Bedrijfsparameters - S kan je instellen met welke Editor je hier wenst te werken, en dat is dan ook het eerste wat hier niet is gebeurd. Daardoor kom je in de Dos editor terecht. Stel hier "DHTML Editor" in, en dit probleem is opgelost.

2.
Dat zou vanzelf gaan na F1 als genoemde Macro's aktief zijn.

3.
Deze is iets lastiger om van afstand te beantwoorden, maar je voelt wel dat dit in de DHTML-Editor in de basis wel zal werken.
Je moet mij alleen niet vragen of je die characters hetzelfde terug ziet op de print enz., dan wel in een gegenereerd HTML dokument. Je zal dit zelf moeten proberen, en als het niet meteen gaat zoals je hoopt zal je het zelf moeten oplossen. Dit hangt van een aantal zaken af zoals unicode, code pages, ondersteunde charactersets door de printer, geïnstalleerde charactersets voor het scherm (zie Google die je ook geregeld vraagt om taal xxx te installeren (Chinees en zo).
Ik denk eerlijk gezegd dat niemand dit zo doet (die andere talen probeert in te typen) omdat iedereen ze laat genereren (door ons, zie ook BK). Dat genereren werkt wel, maar is in de ons bekende situatie alleen no afhankelijk van de printer waarop e.e.a. moet worden afgedrukt, en wat in diezelfde bekende situaties gebeurt via "Dos methoden", ofwel een vanaf het begin (genereren) tot het eind (printen) consistente methode. Jullie echter hebben daar tussenin zitten a. HTML als opslagmethode waarin e.e.a. echt anders zal zijn, b. HTML weergeven wat afhankelijk is van die opslag methode, en eventueel c. het printen wat zal moeten uitgaan van die opslag methode.
En nu weten wij het niet meer ....

Het geheel komt plots op mij over als een trajekt waar je niet zo maar mee klaar bent, tenzij alles toevallig werkt zoals bedoeld (met als konklusie dat je e.e.a. toch op een consistente manier aan het gebruiken bent, want zo'n "toeval" bestaat niet).

Peter

"Zo moet inrichten" ? Je hebt nog niet eens verteld wat je wilt doen !?

Maar daar ben je nu mee bezig hoop ik ...

Marco,

Ik heb dit even in een apart topic gezet (waar jij het in Funktie-trigger Workflow toegevoegd - missend bestand map LOPW? plaatste);

Aldaar snapte ik de context al niet, en nu gelukkig helemaal niet meer. Maar daarom juist : ik had even geen zin om een niet-gerelateerd onderwerp weer helemaal door te lezen om w.s. tot de konklusie te komen dat ... het niet gerelateerd was. Ofwel :

Nu het toch in een apart topic staat, kan je het van een context voorzien die ik kan volgen (ja, ik ).

Iedereen, en vooral jij ook !!!

Hmm ... maar dat van die Kalenders begrijp je ?

Dat is helaas niet mogelijk volgens de wijze waarop de funktionaliteit is voorgesteld. Denk hierbij ook aan aanroepen via een Userbutton.
Met wat prutswerk ad 2,5 uur lukt het misschien (!) wel (Userbutton werkt dan met de oude methode), maar zo niet dan wordt het een volledig nieuwe funktie (11 uur).

Sorry ...

Zonder het helemaal uit te vlooien, zal de levertijd van het produkt wel te lang zijn om nog op tijd binnen te komen. Je hebt het dus te laat besteld. Of beter : je hebt de Behoefterun te laat gedraaid.
Ik ga er vanuit dat dit alles wordt veroorzaakt doordat jij of de betreffende levencier dicht is vanaf kerst t/m 5 januari. Dus, zie je Kalenders.

Dat lijkt me niet. Ik heb gezegd dat je daarvoor een snelle enz. PC moet hebben. En die zal je nog wel niet hebben ingezet.

Ehh, volgens mij moet je de Budget module eens induiken. Laat het budgetteren zelf maar zitten, maar gebruik van daaruit de management rapportages. Daar kan alles officieel naar excel. Als je het een beetje wild maakt komen er 18 of zo sheets uit, omdat het in 1 niet past ...

Veel plezier !

... is dat wij op 2 januari allemaal thuis blijven !

Het forum zal worden gemonitored langs welke weg ondersteuning ook gewoon plaatsvindt.

Iedereen in elk geval een goede jaarwisseling gewenst, en een geweldig 2009 !

Peter

Johan,

Gisteren was Richard hiermee bezig, maar die is onderweg ziek naar huis vertrokken. Zojuist nog even gebeld, maar weinig aanspreekbaar. Het punt is nu :

- wij zouden niet weten wat er is veranderd, maar àls er iets is veranderd zou Richard het moeten weten;
- wij weten werkelijk niet waar we het moeten zoeken.

Mooi, maar niet zo mooi. En dus maar de vraag :
Hoeveel last hebben jullie hier op dit moment van ?
Ik ga er vanuit dat Richard er de 29e weer is en op die dag de oplossing ook wel zal volgen.

Zeg s.v.p. eerlijk als je zo lang niet kan wachten, want we kunnen er iemand opzetten, maar met wellicht het resultaat dat die het eind van deze (korte) dag toch niets heeft gevonden.
... En daarbij heb ik ver weg ook nog in gedachten dat jullie de laatste tijd mij net iets te veel problemen met het systeem zelf hebben (zoals ook momenteel) en dat het aan een kapotte index kan liggen. En dan vinden we dus zeker weten niets ! En dus : Als Richard kan bewijzen dat er ook niets aangepast *is*, kunnen we gemakkelijk zeggen : reorganiseer de hele handel eens.

Heb je inderdaad geen superhaast ermee, dan zou ik sowieso dat reorganiseren doen, om vervolgens bij de nieuwe orders hopelijk te konstateren dat het euvel is verholpen.

?


PS: Mocht je in de geegenheid zijn, zet dan s.v.p. beide lange overzichten uit jouw posts even in een Notepadje en maak er  attachments van. Nu duurt het heel lang om het topic op te vragen.

Voor de aardigheid en misschien verder begrip nog een aanvulling :

De reden dat dit is veranderd zoals omschreven, is gelegen in het feit dat de volledige real time verwerking met de Scanterminals in het meer bijzondere geval van deze produktieomgeving niet "aansloot" bij de verdere processen in het systeem. Het al gegeven voorbeeld betrof de "Behoefterun", en meer in consistentie met de omgeving waarvoor dit is ontwikkeld betreft dit het "Toekennen Grondstoffen". Let wel, in alle geval gaat het hier (mede) om het doodleuk inzetten van produkt B waar produkt A is gevraagd (input van de Produktieorder), en waarbij het systeem dit op voorhand niet weet.

Zoals dit wàs opgelost (en dat was al moeilijk genoeg) werd e.e.a. weer consistent gemaakt bij het Afsluiten van de Produktieorder. En dit mag werken als je bijvoorbeeld eens per dag inkoopt (Behoefterun) of de betreffende partijen en (andere !) produkten toekent aan de input van de Produktieorders (Toekennen Grondstoffen). Alleen ... dit gebeurt niet eens per dag, maar feitelijk continu. En dus, waar het scannen op zich weliswaar voor real time verwerking zorgde, was de interne administratieve afhandeling dit niet, en werd uitgesteld tot Afsluiten Produktieorder.

De funktionele werking mag nu als volgt worden gezien :

a. Er wordt ingekocht (op basis van een (verwachte) behoefte;
b. Produkt wordt toegekend aan de Produktieorders; dit mogen appels op sinaasappels zijn;
c. Door produktie worden partijen en/of produkten gekozen die niet behoeven te voldoen aan de registratie in de Produktieorder (zie b.); Dit betreft niets anders dan het scannen van een pallet produkt, daarmee aangevend "*dit* doen we, ook al moest het anders";
d. Gedurende de produktie kan net zo vaak van partij/produkt worden gewisseld als is gewenst volgens de methode beschreven onder c.
e. Parallel aan c. en d. treedt ook weer b. op, met gevolgen voor a.

Het is feitelijk punt e. waar het om gaat, waar aan de ene kant tijdens produktie iedere keer het beste wordt gedaan wat op dat moment aan de orde is, en waarbij veranderd produkt het oorsrponkelijke ook laat vrijvallen, waardoor dit opnieuw kan worden ingezet middels "Toekennen Grondstoffen". Het geheel is nu dus één grote interaktie van real time registraties, waarbij aan de ene kant bijvoorbeeld een inkoper continu monitort wat bijv. voor het komende uur het beste is kwa produkt toekenning, terwijl aan de andere kant vele produktielijnen dit weliswaar als advies hanteren, maar toch anders kunnen beslissen bijvoorbeeld op basis van de kwaliteit van het produkt. Deze kan te slecht zijn voor de betreffende klant, maar ook te goed.

Het geheel is nu volledig real time opgezet, met parallel daaraan de grootst denkbare flexibiliteit in produktie, en met daarnaast handhaving van de inzichten in voor- en nakalkulatie op diverse niveaus, met als eerste niveau de Produktieorder zoals die uit de Receptuur komt, het tweede niveau waarbij Toekennen Grondstoffen dit aanpast, en het derde niveau waarbij de produktieafdeling nog weer iets anders doet. De nakalkulatie betreft dan het verschil tussen hoeveelheid output en gebruikte input, waarbij "gebruikte input" van ieder van de 3 genoemde niveaus kan zijn, doch waarbij dit momenteel deels is gebaseerd op zelf te maken queries.
Merk nog op dat het grootste deel van de problematiek in deze - het omrekenen betreft van voorgekalkuleerde (Receptuur, niveau 1) appels naar gehanteerde sinaasappels op niveau 2 en 3.