Met ingang van heden hebben we een stukje funktionaliteit welke jaren geleden is geďntroduceerd laten vervallen, simpelweg omdat ze niet meer van deze tijd is c.q. gewoonweg als "te gevaarlijk" mag worden betiteld.
Ooit was het mogelijk om een Verkooporderregel te noteren voor 100 Verschijningen. Deze 100 Verschijningen werden naar de Raaplijst gestuurd, de Raaplijst werd geprint, de Raaplijst werd uitgelopen, en als de Gebruiker had geraapt wat er op zijn bon stond, kon ze de Raaplijst met "Rapen & Goedkeuren" als "geraapt" registeren. De voorraad werd administratief afgeboekt en werd tijdens de Faktuurrun gefaktureerd.
Vervolgens werd het voorbeeld iets complexer. Er was 100 besteld, er was 100 naar de Raaplijst gestuurd, de Raaplijst werd geprint, en op dat moment belt de klant op "ah, ik wil er toch maar 25 hebben". Omdat de spullen nog niet geraapt waren werd de vermindering van de Verkooporderregel in mindering gebracht op het nog-niet-geraaptedeel-van-de-Verkooporderregel. Tevens werd bij die Raaplijst geregistreerd dat deze Raaplijst "Gewijzigd" was sinds ze voor de laatste keer geprint was, en dat ze (dus) opnieuw moest worden geprint alvorens iemand "Rapen & Goedkeuren" mocht gebruiken, immers, het zou kunnen zijn dat iemand de goederen was gaan rapen, 100 geraapt had, maar ondertussen de bestelling was gewijzigd naar 25 en ze dus 75 van de geraapte voorraad weer moest gaan terugleggen, opdat er nog steeds 25 aan de klant zou worden geleverd.
Hoewel bovenstaande theoretisch handig en klantvriendelijk is, gaat deze vlieger steeds minder vaak op en kan ze ongemerkt tot problemen leiden.
Bedenk hier maar bij dat het Rapen steeds vaker via een geautomatiseerd proces loopt en soms via EDI een electronisch bericht naar een externe partij gaat met de opdracht om 100 Verschijningen te rapen.
De 100 Verschijningen zijn in praktijk geraapt, staan klaar om de vrachtwagen in te gaan, en niemand gaat de automatisch gewijzigde Raaplijst met de ingevulde geraapte Raaplijst vergelijken op verschillen; Gebruikers zetten een Bedrijfsparameter "Verplicht printen Raaplijsten" op een dermate waarde dat het niet eens nodig is óm een Raaplijst verplicht te printen, immers "dit gaat toch via EDI?"
Als dit op die manier optreedt loop je dus het risico dat er daadwerkelijk 100 Verschijningen de vrachtwagen in gaan, maar dat het "in mindering brengen op het nog niet geraapt deel van de Verkooporderregel" toe staat dat de order wordt teruggebracht tot 25. Als dit dan ook nog gebeurt in een omgeving waarbij niemand expliciet regel voor regel scant wat ze geraapt heeft, maar gewoon via "Rapen & Goedkeuren" zegt dat ze geraapt heeft wat er op haar Raaplijst stond, maar ze verzuimt dit te vergelijken met de inmiddels gewijzigde Raaplijst, dan ontstaat de situatie dat de klant er 100 krijgt, terwijl er maar 25 worden berekend.
Per heden stellen we dan ook dat het niet meer is toegestaan dat een bestelling "automatisch" in mindering wordt gebracht op het nog niet geraapte deel van een Raaplijst. Als de goederen al geraapt zijn is het sowieso niet meer toegestaan de orderregel te wijzigen, en dat zelfde geldt nu ook als de goederen al op de Raaplijst staan. Desgewenst kan afdeling verkoop zélf kontakt opnemen met de afdeling die de produkten raapt, om tegen te houden dat een bepaald produkt niet meer, of niet meer volledig te rapen. Dit produkt moet dan handmatig van de Raaplijst worden verwijderd alvorens de bestelling van de verkooporder mag worden verlaagd. Vanzelfsprekend vergt dit iets meer werk (hetgeen juist het werk was wat geëlimineerd werd door dit automatisch in mindering te brengen), maar het is een stuk veiliger, en begrijpbaar voor iedereen, omdat je op deze manier beter weet waar je mee bezig bent.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOOVWY | Wijzigen Verplaatsopdracht | 17-01-2023 | 18-01-2023 |
| LOVRCL | Omschrijving (nog) niet bekend | - - | 18-01-2023 |
| LOVRVW1 | Omschrijving (nog) niet bekend | 29-12-2022 | 17-01-2023 |
| LOVRWY | Wijzigen Verkooporderregels | 28-12-2022 | 17-01-2023 |
