Je geeft niet de voorbeelden waar ik mee kwam. Dus :

Header 19-12, twee regels (intussen) 24-12. Of je die ook even wilt doen, want die kan wèl (niet doen !!).

Header 19-12, twee regels, 1 24-12 de ander 17-12.

Hoeveel voorbeelden wil je ?
Omdat je een hele simpele ziet, nl. 19-12 en 1 regel met 24-12, doe je die ineens wel ? omdat je die kunt volgen ? omdat die zo makkelijk is ? omdat ?

Als je het niet begrijpt, dan maar niet. Als je maar wel onthoudt dat de regel : "we passen de header nooit aan op veranderde regels" helemaal eenduidig is. Als straks iemand tegen jou zegt dat het onzin is om de header op 19-12 te laten staan waar immers intussen alle regels op 24-12 staan, geef ik jouw mobiele nummer wel. Ok ?

Samengevat : sloop het er maar weer uit.

Dit klinkt goed, maar is het m.i. niet.
Ga voor jezelf maar na wat je zou (moeten) doen als je 2 regels hebt, Deelleveren Ja is, en beide regels tot een andere Leverdatum dan die van de Header leiden; het leukst is beide regels hetzelfde.

Als je hier uit bent, doe dan beide regels verschillend.

Weet je dat ook op te lossen, pas dan de datum in de header aan.

Moraal : zoiets (dus ook de "oplossing" van deze Releasenote) kun je maar beter laten. Je krijgt het toch nooit goed.

Een uitgebreide analyse leert dat er van geen betrouwbare pognose sprake kon zijn.


Gooi maar in je pet.                   

Ik heb twee scenario's waar je een punt aan kunt zuigen :

1. Voor zowel Geleverd als Niet Geleverd hanteren we de Voorkeurleverancier;
2. Voor Geleverd hanteren we de werkelijke - voor Niet Geleverd de Voorkeurleverancier.

(andere kombinaties werken m.i. nooit)

Uiteraard gaan mijn verdere voorbeelden erover dat de werkelijke Leverancier (A) niet de Voorkeur Leverancier (B) is ...
Er is 40 van de 60 geleverd.
Dus let wel, in alle gevallen heeft A geleverd !

Ad 1.
Er is te weinig geleverd (door Leverancier A), maar Leverancier B heeft het 40 % goed gedaan. Tegelijk heeft B het 60% verkeerd gedaan. A doet in dit voorbeeld niet mee.

Ad 2.
Idem, maar nu heeft A het 100% goed gedaan, en B 100% verkeerd.

Ad Ad 1
B deed in het spel niet eens mee, maar heeft het zowel goed als verkeerd gedaan.

Ad Ad 2
A heeft 60% niet geleverd, maar volgens jou 100% goed.
B was niet aan de orde, maar heeft alles verkeerd gedaan.


Naast bovenstaande, ben jij (Lampenier) degene die in veel gevallen bepaalt wie wat krijgt geleverd. Aldus zou je al niets meer hebben aan het bekijken hiervan per filiaal. Immers, als jij slecht inkoopt, en van de benodigde 1000 er maar 400 laat aanrukken, en jouw belangrijkste filiaal krijgt gewoon de 100 bestelde, wat zegt dat dan ?
a. De leverancier is puik in orde
b. De leverancier heeft veel te weinig geleverd
c. Lampenier heeft veel te weinig besteld
d. Dirk-Jan heeft de vraag verkeerd gesteld.

Nogmaals, maar nu ben je bij het minst belangrijke filiaal, en die krijgt er maar 1 van de bestelde 100
a. De leverancier heeft maar 1%% geleverd van wat moest; wat een waardeloze leverancier
b. Lampenier is vergeten te bestellen, maar de puike leverancier is zo goed geweest om toch 1%% te leveren
c. Er moet iets fout zijn met de software, want er zijn toch 2 vrachtwagens de deur uit gegaan.
d. Dirk-Jan had de vraag nooit moeten stellen.

N.b.: Bij twee keer dezelfde letter als antwoord gelden die betreffende twee situaties tegelijk.
Overigens is dit al onderdeel van de nieuwe leermethode.

Klopt.
LOLA

Dit verhaal snap ik wel.

Wat ik niet snap is hoe je de performance van een levering wilt bekijken die niet is gedaan.

Jaaaa ja. En nu dacht jij zeker antwoord gegeven te hebben ?

De gebruiker krijgt een waarschuwing, past niet het Chargenummer aan, en dan ?
Dan blijkt de waarschuwing geen waarschuwing te zijn, neem ik aan ?

En nu dacht je -in al je enthousiasme- zeker dat we dit wel konden volgen ? 

Het lijkt erop (??) dat je werkelijke probleem is dat je e.e.a. in "Gerealiseerd" wilde hebben, terwijl je nu een oplossing zoekt voor Geprognotiseerd (op Verkooporder maar nog niet geleverd). En, dit klopt/kan natuurlijk ook niet.

Als jij zegt dat de output niet betrouwbaar is omdat er geen Leverancier kon worden gevonden omdat er niet is geleverd, dan is er dus helemaal niet geleverd.

Nee, hier snap in elk geval ik geen bal van.

Wie heeft gezegd dat dit zo moet werken ? niemand toch ...
Er dient een melding te verschijnen die je erop wijst dat het zo is (inaktief zijn), maar met een toets kun je toch door ... (maar default niet).

Johan, buiten het Verkoopkontrakt verhaal, het werkt wat anders dan Yvonne heeft duidelijk gemaakt;

Als je nog geen Inkooporderheader hebt, wat het geval is bij de Shift-F5 optie, kun je ieder Kontrakt selekteren wat er bestaat; vervolgens zullen de Kondities worden overgenomen in de Inkooporder Header.
Dat je ook nog een Inkooporder kunt hebben met Kondities, wat nu toestaat dat er een Kontrakt op kan zonder Kondities, is eigenlijk een ander verhaal, en dat probeerde Yvonne -als (ontercht) enige verandering- uit te leggen.

Aan de Verkoopzijde kun je geloof ik Kontrakten maken die default de Konditie van de Debiteur krijgen, en als je geen Kondities wilt in een Verkoopkontrakt moet je die dus expliciet verwijderen. Werkt wel anders, maar wat maakt het uit ...

Hoe maken we het lekker verwarrend ...

Wat dacht je ervan dat ik "Dagen Horizon Produktie Detailplanning" bedoelde ...

Wat mij betreft doet dat ding funktioneel precies wat jij met die "Aantal dagen vooruitrekenen" doet/wilt, en kun van het laatste wellicht stellen dat het een "raar ding" is, terwijl het eerste vrij formeel is.

Dus, ga maar eens na of de detailplanning van produktie (tot wanneer deze vast staat) niet precies overeenkomt met wat je hier wilt.
Ik zeg van wel ...

Hoe ken dit.
Ik had er al een draaibol voor ons bijgezet.

Als *jij* weet hoe het ken vind ik het ook goed hoor.

Huh ?!

Nee, dat is geen rare vraag. Je moet sowieso kunnen doen "wat je doet". Wat dat betreft ken je ons.
Maar alles heeft nu net weer te maken met het gegoochel (een ander woord heb ik er niet voor) wat er wordt uitgehaald rond jullie keuringen. Toen dit topic drie dagen geleden ontstond heb ik ook het ontwerp (eerste stuk is van 2001 meen ik) op m'n bureau laten leggen, waarna het even niet meer leek te hoeven (en ik heb het dus ook niet meer bekeken).

Een wellicht niet helemaal nuttige opmerking : toen ik nog niet wist van de formele sub keuringen, wist ik niet beter of alles werkte al met Doorgangen. Dus, tweede Keuring = Doorgang 2, derde Keuring = Doorgang 3, enz. Je hoort mij niet zeggen dat het zo had gemoeten, maar wel dat je dan "vanzelf" nooit problemen had gehad. Dus ook : nu lopen er vanzelf twee behoorlijk zelfde processen door elkaar.
En sterker : ik zou denken dat wat jullie doen met de Subkeuringen, ooit ook met Doorgangen is opgezet ! (maar dat heb ik misschien verkeerd in mijn hoofd).

Hoe dan ook, ik zal de ontwerpen doornemen, opdat we ook beter weten hoe met het scannen om te gaan.
Voor jou zelf geldt (op dit moment) dat het euveltje "even iets erbij gooien" in de basis niets anders is als dat je de Keuringen niet had gehad, en dat conform Profit dient te gebeuren c.q. werkt zoals het werkt. Kun je zo niet werken, dan moet domweg dááraan iets gebeuren, zoals bijvoorbeeld een simpele Bedrijfsparameter die het de PO toestaat iets toe te voegen bij Status P, en waarbij je ofwel tegelijk nog formele Bijstellingen wilt doen, dan wel daarvan nooit gebruik wilt maken.
Merk op dat jullie wat mij betreft wel degelijk formeel Bijstellingen doen (ga zelf maar na), maar dan in het trajekt van het Kontinue Proces, en wat jullie oplossen met Sub Keuringen. Ik acht dit gewoon fout, maar wat niet inhoudt dat dat zou moeten veranderen.
Dit oordeel van mij sowieso onder het nodige voorbehoud, want er is vast veel meer over te zeggen, en ik heb me destijds nooit bezig gehouden met jullie.

Voor jou geldt : laat maar even rusten nu, en probeer er even voor te zorgen dat je ermee kunt omgaan (bijvoorbeeld via de door Marco aangegeven werkwijze).
Wij komen wel met iets.