Dit is bewust niet gedaan, omdat het dan (wat ons betreft) kan gebeuren dat "wij" uit de doeken doen hoe iemand werkt, terwijl we altijd al volhouden dat we dat niet doen ...

Misschien wat ver gezocht, maar toch.

Ehh ... dit zou aans ons moeten liggen. Hoe/wat weet ik nog niet.
Kun je even een voorbeeld van een Artikel enz. (alles wat nodig is om het bij jullie na te doen) geven ?
Ook graag wàt je doet, want wie weet zijn we vergeten hoe jullie werken (en je bent er ook aardig uniek in, vandaar).

Uit de helptekst van Toevoegen Produktieorder (scherm 39) :

< Aantal EPU kan niet worden bepaald voor Artikel ..... >

  Middels de Formule van een van de Receptregels werd gebruik gemaakt
  van een kode EPU, welke het aantal Eenheden Per Uur berekent wat             
  de opgegeven Resource per Recepteenheid (en eventueel per Artikel) 
  kan verwerken.                                                     

  Middels deze kode kan bijvoorbeeld worden aangegeven dat m.b.v. een
  bepaalde Resource 750 meter/uur kan worden geproduceerd, zodat op   
  deze manier de benodigde tijd kan worden berekend.                 

  Deze melding verschijnt indien het aantal EPU niet kon worden       
  bepaald.                                                           

  -> Is er een Resource opgegeven bij de Produktieorder ?                       
     Is het Produktiestation als Resource bekend ?                   


Helpt dit misschien ?

Eerste regel van dit topic :


 

Werken jullie al met DKK's ?

En gaat het alleen om vrachtkosten ?

Oops.

Komt iets meer bij kijken dan een Layoutvariabele, maar is wel te doen. Je krijgt wel een aanbiedinkje.

Yep, toen ik het las had ik er ook meteen een goed gevoel bij. Gaan we wel doen, denk ik.

Uitstekende reaktie, die ik ook wel had willen doen, maar waarbij e.e.a. zo erg afhankelijk is van de kreativiteit, kennis, en kunde van jou als degene die tegenover de man/vrouw zit, dat er haast geen maatstaf voor te geven is. Wat echter wel altijd geldt, is precies wat jouw voorbeeld aangeeft : leg ze een vergelijking met iets bekends voor, waarvan je op voorhand weet wat het resultaat is (en daar wordt 'ie al redelijk ondoenlijk voor 95% van "gebruikers").

In dit kader (en voor iedereen nuttig om te doorgronden) kan ik leuk verwijzen naar het Uitgebreid Beveiligings Beleid wat speciaal (en niet toevallig natuurlijk) voor Johan is gemaakt (ook leuk dat niemand dat weet, ahum, maar daar doen we nog wel een keer wat aan). Ook dit komt puur voort uit de requests van zo'n EDP figuur, en als je er eenmaal aan toegeeft, zit je er ook aan vast.
Je wilt niet weten hoeveel en hoelang wij hier intern discussies hebben gehad over de pure onzin hiervan, omdat het domweg op het verkeerde niveau wordt aangepakt, plus vooral de kennis die je EERST moet hebben van de "echte" omgevingen. En dan doel ik op een jaar of 30 terug, en de gebruikelijke "multi user" systemen van toen.
Hele discussies hebben we gehad over het "dan maar thuishoren" in het OS als je zoiets eenmaal in Profit wenst, maar, waar het al in zit. Niet dat ik wil zeggen dat je daarmee 100% kunt voldoen aan wat de EDP verlangt, maar wèl dat je daarnaar kunt verwijzen, en waar hij toch geen verstand van heeft. Heeft hij dat per abuis wel, volgende poging ...

Het punt is gewoon dat je dagen met zo'n man om de tafel zit, en je eigenlijk kontinu over lucht praat. Mij lukt het wel, en ik heb hier diverse rapportages liggen (laatste was van E&Y EDP-Audit meen ik), maar misschien ben ik ook wel de enige die dat voor elkaar krijgt (lees : zo moeilijk is het, en zo veel moet je van werkelijk àlles weten). Overigens was deze rapportage ook domweg namens een klant, die ik echter "te woord heb gestaan" (trouwens, volgens mij vergde het wel een week).

Een hele belangrijks is altijd de autorisaties op de database, waarbij het voor mij niet zo moeilijk is om te verwijzen naar de klant die dat op de juiste wijze doet (zoals eerder door mij aangegeven), met een telefoonnummer erbij. Of de EDPer dat nummer gaat draaien of niet maakt mij niet uit, ik ben er daarmee vanaf. Zeg niét dat -als het moet- e.e.a. middels een SQL/Server database kan worden opgelost, want dan mag je die overmorgen aanschaffen ...

Ehh, op wat voor een Variabel Overzicht had je dit subtotaal geprint willen hebben (c.q. welk Overzicht leent zich daarvoor) ?

Yep. Althans, niet als je niet op de e.o.a. manier (!) aangeeft dat de Kostenregel is gerelateerd aan een levering van fysiek spul.

Merk op dat de Leverdatum zoals je die kunt opgeven bij de VORegel (heb ik niet eens gekontroleerd, maar zal ook wel voor een Kostenrtegel) net zo min iets zegt als dat dat iets zegt bij een VORegel voor goederen. Immers, als je de goederen een week later (of eerder) levert, wordt dié datum gerespekteerd bij de Fakturering (en dat wil je ook). Als je dit uitwerkt voor Kostenregels, zie je dat het zou moeten gaan raden. Denk ik deze aan de situatie dat je een Kostenregel wel gerelateerd aan een fysieke levering wilt hebben, maar wat nou als je het laatste nog niet hebt gedaan (of een week te vroeg doet). En dus, er wordt niet geraden, maar het wordt gewoon gedaan als je de Order eenmaal faktureert (ook niet goed, maar je moet toch wat).

De oplossing is in alle gevallen : zorg dat de Kostenregel is gerelateerd aan de fysieke levering. Zoals met DKKs mogelijk is.

Jawel, maar als het verhaal begint met Geleverde Artikelen, en je beoordeelt e.e.a. middels een Afleverdatum dan zal het wel de gerealiseerde "leverdatum" betreffen, toch ?

Klopt. Is nooit ontwikkeld voor Windows. Doen we dan toch maar wel een keer.

Verder, ik denk, als je een beetje bij bent met upgrades klopt er even niet veel van de Trefwoorden funktionaliteit. Zit 'm niet zo zeer in de funktionaliteit (of helptekst) maar in het opbouwen van de Trefwoorden (zo blijkt mij vandaag).
Wordt aan gewerkt ...

... wat met terugwerkende kracht geldt of zo ?
Komt niet helemaal goed heh ...

Dan wil ik graag ook nog wel weten hoe je het voor elkaar krijgt om voor een Leverancier ALLE prijzen onjuist in te voeren. 

Om meerdere redenen een interessante post Johan. Het toont in elk geval mede dat die omschrijvingen "hier wel, daar niet" worden weergegeven, waarbij ik de Releasenotes al een tijd van "niet" verdenk.

Aangaande het muteren kunnen we daar -denk ik- tegenwoordig verregaand verbetering in aanbrengen.
Merk in elk geval op dat dit alles geautomatiseerd wordt bepaald, en dat het niet zo is dat iemand hier van een funktie kenmerkt wat voor een soort het is.

Die EDP auditor kan ik me alles bij voorstellen (zelf meerdere keren tegenover zo'n man gezeten), en je moet van aardige huize komen wil je niet "nat gaan". Maar, in de praktijk dus net zo goed; als jij niet wilt dat iedereen in LOAR enz. kan browsen, moet je echt wel wat uithalen, wat voor zover ik weet één klant ook daadwerkelijk heeft gedaan, en als er daar wat aan de knikker is kunnen wij niet eens ondersteunen ... .
Als het tegenovergestelde van pragmatisch rigide is, is een EDP auditor rigide. Maar ja, heb je'm/haar niet zelf uitgenodigd ? 


Op termijn zullen we alles uit je post hebben behandeld.
Dank.