Heart-Profit ERP

Bij het Printen van de Verkooporders kan een reeks Verkooporders worden opgegeven. Bijvoorbeeld moeten alle Verkooporders van deze ochtend afgedrukt worden. Verkooporders die op dat moment in behandeling zijn worden dan overgeslagen en zullen aan het einde van de reeks opnieuw worden benaderd om  alsnog geprint te worden. Als op dat moment iemand uit de bewuste Order gaat omdat hij/zij even iets anders moet doen terwijl de Verkooporder nog niet is afgehandeld, wordt de Verkooporder ineens geprint (zoals het ook gewenst was), want we wilde alle Verkooporders afgedrukt hebben. Echter deze Verkooporder was nog niet klaar en er zullen dus nog Verkooporderregels aan toegevoegd worden. Als we dan aan het einde van de dag nogmaals alle niet geprinte Verkoororders willen afdrukken zal de zojuist in de 2e doorloop wel geprinte Verkooporder worden overgeslagen, immers deze is al geprint. Middels deze Rubriek kunnen we aangeven dat we een Verkooporder die we niet kunnen locken (iemand is nog met de Verkooporder bezig) niet moeten opnemen in een tijdelijk bestand, zodat deze straks in een 2e doorloop alsnog geprint wordt, maar dat deze moet worden overgeslagen.

Funktie	Omschrijving	Dtm.Vl.Wyz	Dtm.L.Wyz
LOPRVO	Printen Verkooporders	31-12-2009	20-08-2010

Merk op dat de hele toegepaste methode sowieso niet waterdicht is, en problemen kan uitlokken.

Dus, als gebruiker A een Verkooporder toevoegt, en gebruiker B de Verkooporders print, dan sloeg printen de Verkooporder van A tijdelijk even over, en werd deze in een 2e doorloop alsnog verwerkt, wachtend tot de gebruiker de order had vrijgegeven.
De nu ingebouwde oplossing zegt feitelijk "blijf niet wachten tot die order is vrijgegeven, sla haar gewoon over, en behandel het als een order die op een later moment is toegevoegd, en later nog een keer geprint zal moeten worden".

Wat hier niet mee ondervangen wordt, is de situatie dat A een order moet toevoegen van 100 regels, nét 25 regels heeft ingevoerd, en voor regel 26 eerst even uit de order moet en wat gegevens moet uitzoeken. Gebruiker B kan nu de order printen, omdat deze niet meer geallokkeerd is. Gebruiker A gaat vervolgens weer verder met haar order, en voert de resterende 75 regels in. Deze worden echter nooit meer geprint ! omdat de Verkooporder al een status "geprint" heeft, en Printen Verkooporders kan worden opgestart met de optie "alleen de nog niet geprintte orders printen".
Bij die kombinatie kan het voorkomen dat er een halve order wordt uitgelopen.

Procedureel wordt dit (door de betreffende klant) nu opgelost doordat bekend is dát het om zo'n grote order gaat, die vooraf te blokkeren, en bij het klaar zijn van de order deze weer vrij te geven. Een echte oplossing is dit niet. Een juiste oplossing zou zijn dat iedereen zelf moet aangeven dat ze klaar zijn met een order, en dat deze geprint mag worden. Bij de grote hoeveelheid orders (1000 per dag) is dit voor de klant niet wenselijk.

Overigens hoeft dit helemaal niet tot problemen te leiden indien iedereen zich maar aan de procedure houdt "iedereen print zijn eigen werkbonnen". De verkoper weet dan zelf wel dat hij klaar is met invoeren, en dat de orders geprint kunnen worden. De problemen ontstaan pas zodra iemand orders gaat afdrukken van andere gebruikers (die mogelijk nog niet klaar zijn met hun order).

Een erg voor de hand liggende oplossing is te stellen dat bij het Toevoegen-/Wijzigen van een nieuwe Verkooporderregel de indikator "Verkooporder is geprint" moet worden gereset. Echter, dat zou ervoor zorgen dat als er één regel aan de order wordt toegevoegd, de order opnieuw wordt geprint, en derhalve 2x geraapt wordt. Problematiek die overigens normaliter door "Raaplijsten" wordt opgelost, doch nu kunnen ontstaan omdat er op basis van "een print van de Verkooporder" wordt geraapt.

Bij aankomst bij het Touch Screen Leveren Verkooporder, alwaar hetgeen geraapt is moet worden geboekt op de order, zal de eventuele fout alsnog gekonstateerd worden, omdat er 25 regels op de bon staan, maar 100 op de order. Of anders, omdat het TS scherm aantoont hoeveel colli er geraapt moeten worden over de hele order (X van Y geraapt), en dit aantal niet overeenkomt met wat er geraapt is.

Indien gewenst kunnen we (ter voorkoming van het feit dat bij het gereedmelden op het TS scherm iemand zit te slapen en niet ziet dat de order anders is dan op basis waarvan er geraapt werd) in de barcode van de Verkooporder aangeven hoeveel colli er op de VO stonden op het moment van printen, en verwerking blokkeren indien het aantal colli van de print afwijkt van de order zodra e.e.a. geboekt wordt; dit zou nl. impliceren dat de order inmiddels gewijzigd is.