Toch is dat moeilijker dan het lijkt, wat ook met "logika problemen" van doen heeft.
Niet alleen buiten het laatste gaat het om de vele programmatuur die hiermee consistent zou moeten worden gemaakt. Voorbeeldje :

Je hebt nu eenmaal een Kontrakt voor de Leverancier en/of Artikel lopen, maar je maakt (één van) beiden inaktief. En nu ? Hier heb je dus een logika probleem en een inconsistentie probleem bij elkaar. Immers, als je eenmaal besluit dat het Kontrakt moet worden uitgediend, waar gaan we dit dan allemaal tegenkomen ? ... en denk niet dat Toevoegen Inkooporder(regel) het enige is wat een Inkooporder(regel) kan maken ...

Dit kan rustig worden samengevat onder "kom je nooit uit".

Merk ook op dat met name Leverancier en Debiteur ("Inaktief" maken) nooit als zodanig letterlijk zijn bedoeld, doch voortkomen uit de wens van iemand van zulks, doch met andere context (!), en dan hoeft het beestje maar een nèt iets verkeerde naam te hebben, en de rest meent het in andere context te mogen / kunnen zien.

Denk verder aan de opzet zoals het bij het Artikel ooit is bedoeld, en waarbij domweg is gezegd : Als je het Artikel niet kunt plaatsen op een Verkooporderregel, kan er ook nooit meer Behoefte aan ontstaan, en is die kontrole dùs voldoende.
Ja, totdat iemand datzelfde produkt ergens in een Receptuur (als grondstof) heeft staan, en er vanuit die hoek weer Behoefte aan kan ontstaan. Of erger ... er zijn mensen die werken helemaal niet met de Behoefterun ...

Je ziet dus dat het van kwaad tot erger wordt, en wat elders als een handigheidje begon, kan uitmonden in een onoverzichtelijk drama.
Alle programma's aanpassen is nog te doen (alhoewel ik niet zou kunnen zeggen hoeveel dat er zijn, maar denk maar aan honderden), maar de logika problematiek ... geen doen. Nog een laatste voorbeeld : als wij lekker rigide die honderden programma's aanpassen  - stel 1 per minuut - zijn de kosten te overzien. Maar nu moet stuk voor stuk worden bepaald welke wel en welke niet, en kom je uit de vraag "statistieken ?" al niet zo snel. Dit hangt immers af van hoe je de betreffende statistiek beoordeelt, en als je niet oppast kies je ervoor dat het oude produkt natuurlijk zichbaar moet blijven, maar er vervolgens voor de rest van het produktgamma nog maar 99% van de koek over is, terwijl dat feitelijk 100 % is. Dus maar een J/N veldje erbij ?
Dat is nu dus, stel, gemiddeld 5 minuten per programma alleen voor de beoordeling, waarmee je op vijfhonderden minuten komt.
Dat klinkt als minimaal 1000 minuten, toch ? Mooi, dat is minimaal 16,67 uur. En wat heb je dan ? geen idee, waarschijnlijk 40 voorstellen voor maatwerk van 1 uur per stuk. Of 39 van 1 uur en 1 van 20 uur.

Kortom, totaal niet te overzien.
Het effekt ? zo hier en daar wil iemand er iets bij, zoals jij zou kunnen zeggen "doe alleen maar bij Toevoegen Inkooporderregel".
Overmorgen heb je er dan toch weer een in zitten omdat er, zoals gezegd, veel meer is.

Ik ga er vanuit dat dat Routeplan toch minimaal bestaan hééft. Immers, het nummer klopt te goed ...

Lijkt me niet veel van te kloppen. Is bij ons gewoon "snel" hoor.
Met 1 per seconde zou je ook een uurt bezig zijn ...

Waarvan de CPU zo hoog wordt kan ik ook niet volgen.
Virusscanner misschien ?

Geblokkeerde funktie ??
Bij jullie was het wellicht ook ramen krabben vanmorgen, maar je moet niet al zo vroeg aan de Berenburg gaan hoor.

Kortom samengevat, ik zal het gemist hebben, maar ik weet totaal niet waar je het over hebt nu.

Je hebt gelijk;
was hier ook al zo besproken ...

(wij zijn net Friezen hier ).

In detail zou ik een andere reaktie kunnen hebben :

Je noemt twee sequences (detail, en op funktioneel niveau zeg maar), maar hoe lopen die zaken (evt) door elkaar ?
Dus, je zult wel niet de prijsopbouw raadplegen als de 0-prijs nog niet is ingevuld.

Anders gezegd, ja, het zou zeker kunnen helpen als je nu alles bij/doorelkaar noemt.
Vergeet ook de UserButtons niet !!

Wat denk je ?

Hopen op "elke keer mis" en dan op de e.o.a. manier erover communiceren ? en hopen dat "elke keer" ook de "eerstvolgende keer" is ?

Er zitten hier nu zo veel uur in in een poging het na te doen dat ik moet vragen of jullie dit niet kunnen nadoen. Tja, ik weet het, dat heb je al keurig netjes aangegeven, doch met de mededeling "niet altijd" (strekking).

Er moét iets zijn wat het foutgaan triggert, maar wij komen er niet op. Voor jullie : houd svp in de gaten dat dit al "aan het gebeuren kan zijn" op het moment dat je net begint bij Raadplegen Verkooporderregels. Of zelfs idem bij de vorige Verkooporder.

Zelfbescherming ... allemaal zelfbescherming.

Als jullie het na kunnen doen, c.q. als je kunt aangeven hoe dit gebeurt, kunnen wij het oplossen.

Merk op dat wij hier niet eens hoeven te beginnen met pogingen om dit na te doen, om dat dit volledig afhankelijk is van de inrichting (de mogelijkheden die de gebruiker heef, de zijstapjes, de meldingen die verschijnen). Dus helaas is het zo dat alleen bij jullie zelf het "gegarandeerd" is dat het kan gebeuren. En dus : mocht je het kunnen nadoen dan houden we ons aanbevolen ...

Ik word er hier op gewezen dat dit alleen maar werkt als je iemand die geen omzet heeft gehad een faktuur stuurt met 0,00 erop ...

Maar dit is iets direkter.

Eens.

Ook bij het opvragen van het Openstaande Salddo vanuit Raadplegen Openstaande Faturen (o.i.d.) wordt e.e.a. anders gesaldeerd. Opdat je weet wat je wel en niet mag verwachten aan inkomsten (hangende een geschil situatie).

... waarbij je je kunt afvragen welke van de twee situaties juist is.
Persoonlijk, als ik  faktuurkorting geef, zou ik die niet over de doorbelaste kosten willen geven. Maar ja, of je klant dat ook begrijpt (en de afspraken zo zijn gemaakt) ...