Heart-Profit ERP

Het gebeurt regelmatig dat er, bij de verschijning "STUK" 1 minder wordt geleverd (op de pakbon) als dat er besteld wordt.
Voorbeeld:
Op order 20070226387 (GELDER) staan besteld 80 bananen (regel 11), de order wordt via het touchscreen leveren volledig afgemeld. Echter op de uiteindelijke pakbon worden 79 stuks doorbelast.
Dit gebeurt zonder dat wij de aantallen aanpassen.

Wat is hier aan de hand?

Even ter voorbereiding : Als je kijkt naar het gewicht, en je rekent uit hoeveel "bananen" dat hadden moeten zijn, kom je dan op 80 of op 79, of misschien 79,4 of zo ?

Het gewicht is op basis van 79 bananen (1 banaan is 200gr. 79x200gr = 15,8 kilogram)
Dus ik kom op 79 bananen.

ps. Het had dus 16 kilogram = 80 bananen moeten zijn.

Ben je er nu uit, of is er iets verkeerd ?

Ja er is nog niets verkeerd, en dat is dat er 79 bananen op de pakbon staan ipv 80.

Dan pas je dat maar met een pen aan.  :thankyou:
Krijg je van mij die banaan wel.

Maar o wee als ik straks merk dat je zelf met de oplossing had kunnen komen. Dan krijg ik van jou een doos bananen.
Gedroogde graag. :drool:

Wel, dat is dan mooi niet.

Volgens mij neem je mij niet helemaal serieus
Dit gebeurt (zojuist geconstateerd) toch wel meerdere keren per dag, en kost dus geld.

Ik ben ondertussen even wezen kijken (ben nu weer met iets anders bezig), maar ik zie zo snel geen Voorraadmutaties van deze levering. De laatste voorraadmutatie van 100130/STUK is van 23-02-2007 terwijl de order van 26-02 is (en dus alleen maar na die datum geleverd zou moeten kunnen zijn).

Nou het verhaal wordt nog iets gekker, na 27/12/2006 komen er helemaal geen mutaties meer voor m.b.t. de bananen (art. 100130) bij
zowel de verschijning STUK als KG. Hier iets toch iets vreemds aan de hand?

Ik heb het idee dat er helemaal geen voorraadmutaties meer worden bijgehouden, ook niet in Hmenu 1-4-2-1, Hmenu 1-4-2-4.

Zie printscreen.

Er gaat hier volgens mij iets goed mis....

Alle voorraadmutaties in overzicht 1-4-2-1 staan er wel in.... :wacko:

Klopt denk ik toch wel, je moet alleen bij een andere Verschijningsvorm kijken.
Vwb de 100130 is het DS18KG die je op voorraad hebt liggen, en waarvoor de voorraadmutaties staan.

Je hebt gelijk inderdaad.
Maar het probleem m.b.t. het verschil in aantal op de pakbon bestaat nog wel  :wink:

Ik denk dat ik de oorzaak al wel gevonden heb.

Jouw bananen artikel is in KG, en ligt in dozen van 18 Kg op voorraad.

Je wilt een banaan ook 'los' kunnen verkopen. Normaliter per verschijningsvorm ST met een inhoud van 1, maar ja, bij een artikel in kilogrammen werkt dat niet want je zou 1 kilogram verkopen. Dus heb je een Verschijningsvorm 'STUK' welke je bij Kilogrammen gebruikt. Deze verschijning heb je v.w.b. de banaan een inhoud van 0,200 kg toegekend, ofwel, iedere keer als we 1 STUK leveren, dan moet er 0,200 Kg uit een doos worden afgeboekt. Als je 80 bananen levert moet er 80 x 0,200 Kg = 16,000 Kg worden afgeboekt.

Normaal gesproken zou je '100130/STUK' op voorraad moeten hebben wil je dat via een Raaplijst kunnen leveren, maar het TS is o.b.v. een rubriek bij de Verschijningsvorm in staat om de omgerekende hoeveelheid rechtstreeks uit de doos af te boeken.

Maar... (en daar gaat het mis)... als jij dozen inkoopt van 18 Kg, en je verkoopt òf volle dozen òf je verkoopt de bananen per stuk, in welk geval er steeds 0,200 Kg uit de doos wordt afgeboekt, hoe komt het dan dat je op dit moment een doos bananen op voorraad hebt liggen met een inhoud van 4.425 Kg?? Dat zou altijd een veelvoud van 0,200 Kg moeten zijn.

Stel even dat je in dit voorbeeld 80 bananen zou moeten leveren, dan moet er 16 Kg worden afgeboekt.
Uit deze doos kan nog 4,425 Kg worden gehaald en het restant ad 11,575 zal uit een nieuwe doos van 18 Kg moeten komen. Beide mogelijk ook nog eens van een andere charge. Als de Pakbon deze regel voor regel afhandelt (en die kans is groot omdat ze ook charges kan vermelden) je het volgende krijgt:

4,425 / 0,200 = 22,125 stuks. Maar ja, stuks en decimalen kan niet, dus dat worden 22 stuks.
11,575 / 0,200 = 57.875 stuks, wordt 57 stuks.
tezamen 79 stuks.

Leuke theorie, nu nog kijken of die klopt.

De 4,425 op voorraad is hoe dan ook fout, en zal vast de boosdoener zijn. En, zonder dit handmatig af te boeken raak je het probleem dan ook niet kwijt, want als je het iedere keer in veelvouden van 0,200 hier uit afboekt, blijf je die 0,025 houden.

tesamen

Ik kan hem hier nu in ieder geval reproduceren. Het ligt dus aan die voorraad die geen veelvoud van 0,200 Kg is.
In plaats van dat het bij de Pakbon fout gaat kan het ook de berekening in het TS scherm zijn.
Je hoort (euh, leest) zo meer.

Als ik naar mijn voorraadmutaties kijk, wordt er 4,425 Kg en 11,575 Kg afgeboekt.
Op je Pakon wil je geen Kilogram zien, maar een aantal stuks.
Die hoeveelheden worden dus teruggerekend naar stuks, en weggeschreven.
Er wordt weliswaar 22,125 stuk en 57,875 stuks weggeschreven (tezamen 80 stuks) maar het veld in de database op de Raaplijst/Pakbon heeft geen decimalen. Die vallen dus weg, waardoor je alsnog 22 en 57 krijgt = 79 krijgt.

Duurde even :heat:, maar zou nu opgelost moeten zijn. :clapping:

In de nieuwe situatie (waarvoor je overigens een Upgrade nodig hebt  :yahoo:) zal in de situatie dat je 'stuks als bulk behandelt' toch slechts in veelvouden van de bestelde werkelijke inhoud worden afgeboekt. :crazy:

Ofwel, bananen die per 0,200 Kg uit een doos geboekt moeten worden, zullen enkel per 0,200 Kg hieruit worden geboekt. Heb je een doos van 4,425 Kg liggen (misschien wel ontstaan omdat je ook bananen per Kilogram levert en specifiek afweegt op Kg) dan wordt daar nu maximaal 4,400 Kg uit afgeboekt (veelvoud van 0,200) waardoor er een restant blijft liggen van 0,025 Kg. De andere 11,6 Kg zal dan uit een nieuwe doos worden gehaald.

Mooi!
Maare, wat gebeurt en nu met het restant van 0,025 kilogram (zie jouw voorbeeld). Worden deze afgeboekt door de verschijning "kg".
Dus als ik op een verkooporder 1 kilogram verkoop, boekt Profit 0,025 uit het restant en 0.975 kg, klopt dit?

Dat denk ik wel ja.