Helaas ... dit is altijd al een probleem.
Of heb ik het nou mis ?

Het lijkt mij dat meer terugontvangen dan ooit geleverd in deze niet mogelijk zou moeten zijn. Ik weet alleen niet hoe gemakkelijk het is om dit te voorkomen, waar het immers eigenlijk gewoon een Goederen Ontvangst is (waar je best meer mag ontvangen dan besteld). Maar we zullen toch eens kijken of dit is te voorkomen.

Voor de rest lijkt het me dat we het even in je database moeten korrigeren.

Haha, nee joh, zo leuk was m'n idee helemaal niet !
Met het refereren naar de Layout Variabelen bedoelde ik alleen maar te zeggen dat het mechanisme behoorlijk gelijk is;
"Ergens" bestaat een gegeven in de database, en de klant wil dat gegeven beschikbaar gesteld hebben op een print. Wel, hier ook zo, alleen er is niets variabels aan.

Dit vermijdt dat je alles moet doen (jouw twee weken), en toch iedereen tevreden, want je kan krijgen wat je wilt.
Moet je niet "alles" willen natuurlijk, maar als dat zo was was dat al gebeurd.

Dus alles gewoon te programmeren door ons.

Je zou ook kunnen denken aan een op zich standaard schermpje (op te roepen middels een standaard toets) "Extra gegevens", en dat daarin á la een Layout Variabele de extra gegevens worden weergegeven. Dus, zo'n "gegeven" moet dan worden aangevraagd (zoals Paul zojuist heeft gedaan), en dan kan ik me voorstellen dat dit voor 0,25 uur moet kunnen mits er geen overhead is (zeg maar zoals de Layout Variabelen 95 keer van de 100 worden aangevraagd).
Omdat de F1 van een betreffende RA funktie ook niet altijd alles weergeeft wat je wilt, plus het ook nog wel eens op een 4e keer F1 drukken kan staan, is dit misschien beter ?

N.b.: De eerste keer voor die 0,25 uur kan natuurlijk nooit.

... maar er staat al 660 op een Inkooporderregel uit mei 2010 ...

Mag wel toch ? dat leest wat makkelijker ...

Ik had mijn tekst stiekem nog gewijzigd !
sorry !

Het is nu al (gewoon) bruikbaar, maar nog niet 100% mooi/goed. Technisch bijna bruikbaar, zeg maar.
Zie hier onder voor een paar voorbeelden; zo zie je nog niet wàt je wijzigt (kop ontbreekt).
Of bij Weergeven zie je ze nog niet terug (dacht ik).

We deden hiermee rustig aan, en het werkelijk technisch werkbaar maken ... misschien maandag ?

Dank je wel Paul !

Het eerste. En dan werkelijk aan alle tabellen ... En dié velden kan je dan in de statistieken opnemen, maar dat moet op zich per tabel worden gemaakt (en uiteraard lenen lang niet alle tabellen zich voor het opnemen van de velden ervan in de statistieken; relatief weinig eigenlijk).

En dat je er ook nog weer Layoutvariabelen van kan laten maken, is weer iets anders ...

Ok, let op ...

Als je zodirekt een upgrade krijgt, kon het wel eens zo zijn dat je een versie aantreft die het je toestaat zelf velden op te nemen bij de Artikelen. Eigenlijk bij alles ...
Nu zou dit volgens plan altijd bij een module hebben moeten horen, en misschien is dat ook wel zo, maar misschien is dat voor jou/jullie niet het geval. Aan jullie wel de eer om zo'n veld in de statistieken op laten nemen, waarbij voor ik voor dit eerste geval 14 uur reken voor opname in één Statistiek (Standaard Overzicht). Je mag het dan zo zien dat zo'n willkeurig veld als Niveau kan worden opgegeven en werkt zoals gebruikelijk. Dus, je krijgt dan alles van een RAL kleur eruit, of het wordt per kleur gesommeerd, enz. Na deze eerste keer worden het de gebruikelijke prijzen.

Nu vraag je niet om dit voor de bouwvak klaar te hebben (die statistieken), maar je moet ons ook de gelegenheid geven er een stukje langer aan te werken dan die 14 uur. Afijn, het gebruikelijke verhaal (eerste keer, moeilijk moeilijk )

Marco - Ondanks dat je helemaal gelijk hebt, vind ik dat er toch wel wat in zit. "Kleur" is in deze bijzonder en verdient eigenlijk ook een bijzondere behandeling. Dat dit al 23 jaar niet het geval is heeft ergens wèl te maken met jouw verhaal; ik zal er nog eens beter over nadenken.

Dank je.

Kan op zich wel hoor, 2 uur (Toevoegen / Wijzigen / Weergeven).
Dan heb je nog niet de statistieken natuurlijk, maar dat komt dan later wel. Die zullen het trouwens ook met terugwerkende kracht doen, dan weet je dat alvast.

Trouwens, denk er even over na of je nog iets aan de indikatie RAL/Pantone (enz.) hebt. Die 6 posities vraag je niet voor niets, en aangezien RAL een deelverzameling van Pantone is - en je sommige artikelen alleen in Pantone (het is maar een voorbeeld) zal hebben, zijn je statistieken waardeloos als je niet àlles (ook !) in Pantone opneemt. Snap je ?

Ok. Ik weet het niet zeker, maar ik denk dat je iets wilt wat niet kan (werken). Maar eerst even de uitleg van wat er misgaat, en waarom :

Ooit bestond het pakket uit een hard geprogrammeerde tweedeling In Receptverschijningen die "M" en "G" heetten (laat maar even waarom). De M had dan voorrang indien beide bestonden voor een produkt (Artikelnummer / Recept). In die omgeving klopte dat op een gegeven moment niet, en toen is bedacht dat "Alfabetisch eerste" ook een job kon doen. Niet alleen kon de G daarmee voorrang krijgen boven de "M" (de G is eerder in het alfabet) maar ook kon men een Receptverschijning domweg met een A (enz.) laten beginnen, en dan werd die gehanteerd voor de Kostprijsberekening.

In jouw geval heb je die M en die G niet, en als je "Alfabetisch eerste" op N zet, moet het systeem toch iéts doen, en hanteert dan maar het alfabet. En tja, dat maakt in jouw geval dus niets uit t.o.v. het op J zetten van die rubriek ...
Dit verklaart dus wat je ziet gebeuren.

Omdat de Kostprijsberekening in principe Massaal moet kunnen gebeuren, kan er ook niet om een Receptverschijning worden gevraagd, want die hoeft over alle Recepten heen helemaal niet te bestaan.

Om dit op te lossen voor jou, zou er bij het Artikel een rubriek "Receptverschijning hanteren voor Kostprijsberekening" bij moeten, waarmee je bereikt wat je probeerde in te vullen bij Standaard Verschijningsvorm. Maar, ik denk dat je hetzelfde bereikt door alsnog het betreffend Recept (Receptverschijning) als Kostprijs Kalkulerend aan te merken, met mijn vraag waarom je dat niet doet ? En eigenlijk zeg je dat zelf in je laatste post al.


Waarom dit eigenlijk niet werkt ligt besloten in het gegeven dat je feitelijk over andere produkten praat, zonder dat het Artikelnummer anders is. Het mag op zich wel, maar of dit nu meer of minder tegen het randje is, je moet je realiseren dat de Potentiële Kostprijs op het Artikelnummer ligt, en je dus ook die altijd zal zien, onafhankelijk van de Receptverschijning die je *eigenlijk* wilt zien. Dus, als jij wilt weten wat de Kostprijs is voor het produkt met de blauwe folie, wat heeft het dan voor een zin om de Kostprijs van de witte folie gepresenteerd te krijgen ...
Als je hiermee kan omgaan (en daar lijkt het wel op), dan is het dus zaak om de Receptverschijning te kunnen opgeven die voor de Kostprijsberekening gehanteerd moet worden. Wel, dat had je al gedacht - en dat moet dus ook kunnen.

Sorry Johan, hier was ik mee bezig, maar hij was van m'n scherm verdwenen. Ik kijk er zodirekt verder naar.

Dank je voor je uitgebreide verslag !

Maar nou zit ik te denken ... wat nou als dit is gerelateerd : 's nachts een ander artikel bij een charge dan 's ochtends ?

Ik bedoel, kan je bij het onderwerp van dat topic nu eigenlijk niet net zoiets konstateren ?