Heart-Profit ERP

Voorbeeld 2 regels in LOVM:
17/07/2010 om 7:18.33 en 7:18.56

Wat is hier gebeurt:
We hebben een voorraadverschil geconstateerd. Mijn medewerker boekt de restdrum af (met waarde EUR 0.71/kg) en boekt daarna in dezelfde run met dezelfde gegevens een kleinere hoeveelheid bij. Deze krijgt echter de prijs EUR 0.34 /kg

Nu is het zo dat eur 0.34 de inkoopprijs was welke in de order stond, echter het materiaal is duurder ingeboekt en ook bevatte deze een DKK van eur 0.15.
Beide gegevens zijn nu verdwenen, ondanks dat het materiaal op "werkelijke prijs" staat en niet op een "vaste prijs".

Kunnen jullie hier eens naar kijken, dit gaat dus niet goed.

Het zou wel eens kunnen zijn dat dit niet (eenvoudig?) anders kan...

Zodra je een Voorraadmutatie doet, zal het systeem de prijs bepalen o.b.v. de aanwezige voorraad.
Is die er niet meer, dan kijkt ze naar de kostprijs van de betreffende Charge: de prijs waarvoor het produkt destijds is ingekocht/geproduceerd.

In werkelijkheid kun je nog veel meer prijzen verzinnen die aan de orde kunnen zijn. Je hebt 1000 Kg geproduceerd voor EUR 5,- per Kg, maar 200 Kg daarvan wordt naar Spanje gestuurd (kostprijs wordt verhoogd). De resterende 800 Kg is inmiddels geleverd. Nu komt de 200 Kg weer terug, waar ook kosten voor gemaakt moeten worden. De 200 Kg wordt weer opnieuw aan iemand geleverd. Vervolgens komt van de volgende 800 Kg ook nog 100 Kg terug. Nu ga je handmatig alles afboeken, en daarna een deel weer bijboeken. Tegen welke prijs? Je hebt verschillende "waarden" gehad van deze partij, en iedere "waarde" is in theorie een mogelijkheid waartegen je het zou willen kunnen opboeken. Mogelijk moet er een extra kombinatie voor je worden toegevoegd: "de waarde van de laatste voorraadmutatie van dit produkt", maar ook dat zou niet juist zijn: immers als je net de 200 Kg aan Spanje geleverd hebt, en daarna 100 Kg handmatig bijboekt, krijgt dat de prijs van de levering aan Spanje terwijl je opboeking daar niets mee te maken hoeft te hebben.

Resumer: Ik denk dat je procedureel iets moet wijzigen... Hoezo éérst alles afboeken en daarna minder weer opboeken? Als jij de hoeveelheid van een restdrum wilt wijzigen, moet je gebruik maken van "Omvormen naar Verlies". Dan kun je gewoon een deel van dié drum afboeken tegen de prijs van de drum, en blijft het restant op voorraad (tegen de prijs die het al had).

Ter overweging (meer voor Wouter dan voor Marco) :

Ik denk niet dat dit kan, dan wel dat we moeten proberen dit na te streven (omdat het eigenlijk niet kan :smile:). Immers :

Niets zegt dat je hier een Charge officieel duurder hebt gemaakt. Je freubelt handmatig een ietwat met de originele charge (verandert de prijs, voegt een DKK toe, enz.), maar er ligt niets aan te grondslag. Financieel technisch lijkt me dit al niet te mogen omdat je het niet kan aantonen (ja, een *impliciete* Kostrpijsverandering, maar daar trappen de heren niet in). Een voorbeeld (voor je eigen gedachten hoe dit wel moet en mag) :

Als je transporteert, en daar DKKs aanhangt (Transportkosten, desnoods inklaring, etc.), dan heb je een dokument wat formeel aantoont waarom de Kostprijs hoger is geworden. Dàn werkt het dus wel (want de Charge (!!) krijgt de Kostrpijs, niet het Voorraad-Item ... ja ook, maar afgeleid van de Charge in dit geval).

Als je handmatig de Kostprijs aanpast (wil aanpassen) dan is de enige methode die legitiem is, werken volgens VPP en de hele handel opnieuw doorrekenen. Nee nee, dat werkt niet voor jou (Marco), maar het is wel een legitieme methode.

Je zal m.i. dus op zoek moeten naar die legitieme methode, die de *Charge* zijn andere Kostprijs geeft. In jouw geval zou dat een bewerking moeten zijn, en dus minimaal een Omvorm Opdracht (en anders een Produktieopdracht).
Zonder zo'n opdracht maar het Chargenummer veranderen, en daar voor het eerst de hogere Kostprijs aan toekennen zal ook werken, lijkt me.

Edit : Wouter's en mijn post hebben elkaar aardig gekruist, en ook al zijn de verhalen volledig verschillend, de moraal is dat wat je (Marco) doet, niet kan. Niet "zo maar", en altijd op te lossen aan jouw kant (procedureel dus).

Je zegt wel dat de overwegingen meer voor Wouter dan voor mij zijn.

Maar toch:
De prijsverhoging komt uit een kostprijsverhogende DKK op de inkooporder regel en is dus formeel niet "gefreubelt". Maar dit is een legitieme implementatie binnen het pakket.
Wat mij betreft is dit dan ook "de waarde" van de desbetreffende charge.

Het systeem echter gaat terug naar de "bestellingswaarde" ipv de "werkelijke waarde" en dat is volgens mij gewoon fout. Zoals je zelf n.l. aangeeft is de DKK een integraal onderdeel van de kostprijs.

Dat ik eventueel een verlies kan omvormen naar verlies = accoord, maar hoe ga ik er dan mee om als ik een keer wat over houdt, en dus moet "omvormen naar winst"?

Hier heb je gelijk in !

Maar dan heb ik het gevoel dat je misschien toch ergens iets doet waardoor dit om zeep gaat. Niet zeker natuurlijk, want er kan best ergens een fout in zitten. Daarom :

Heb je een voorbeeld voor ons van een produkt wat je inkoopt + DKK, wat vervolgens een onjuiste Charge waarde zou hebben ?
Het liefst in de Testbestanden, maar anders komen we er ook wel uit.

eerst even en "domme" vraag:
waar vindt ik de chargeprijs in het systeem.

Nu kwam ik er n.l. achter via die af en bij actie......

Tabel LOCP.

Het lijkt er wat mij betreft op dat de tabel LOCP niet goed gevuld wordt.
2 charges gecontroleerd:
I00702002/1 bij IO 20100702002  regelprijs 0.20 + Dkk = ontvangstwaarde EUR 0.35/kg
I00326016/1 bij IO 20100326016  regelprijs 0.24 + Dkk = ontvangstwaarde EUR 0.39/kg


In LOCP staat echter voor de 2002/1:
13680 kg ontvangen
Hfl 6029.35056

dus dat is Hfl 0.44/kg hetgeen ongeveer EUR 0.20/kg is

Er wordt wat mij betreft een formeel foute aanname gedaan:
Immers een kostprijsverhogende DKK is kostprijsverhogend omdat daar een legitieme grondslag is.

Bv tranportkosten/verpakkingskosten/orderkosten e.d.
Deze waarde wil je laten doorrekenen in de voorraad aangezien het hier de verwervingswaarde betreft.
Dus dan geldt ok dat de waarde verhoogd moet zijn.

vandaar de door ons geconstateerde afwijking.

mvg

MK

En volgens mij is er een ander scherm die jullie gebruiken, waarin deze prijs juist gebruikt wordt als "inkoopprijs".

Dus voordat iemand bedenkt dat deze waarde inclusief DKK's moet zijn...

Als je bedoeld het scherm LOCPARRA, ja


Dit betreft de waarde waarvoor het product op voorraad gekomen is
Dus incl. de kostprijs verhogende DKK's e.d.

Helaas heb je daar geen gelijk in  :(

LOCPARRA is in eerste instantie zo opgezet omdat jij dacht dat je dié kostprijs in dat overzicht erbij wilde hebben.

Uiteindelijk is het in LOCPARRA nu opgelost door expliciet op zoek te gaan naar de Voorraadmutatie van de Goederen Ontvangst, om dáár de waarde te bepalen waarvoor het item op voorraad terecht is gekomen. Die waarde staat dus NIET in LOCP->KOSTPRYS.

V.w.b. de prijsbepaling in een handmatige Voorraadmutatie kunnen we dat in theorie ook doen; waarbij het zoeken in de Voorraadmutaties dan afhankelijk moet zijn van of het een Koop- of een Produktieartikel betreft.

Nog steeds niet degelijk, maar minder slecht dan nu (terwijl niemand daar ooit een probleem mee had).

ellende hé,

zo'n klant die gaat nadenken........

Zullen we eerst eens even helemaal niets doen voordat jullie de boel zo door elkaar halen dat niemand meer weet waar het over gaat ...

Marco, leuk dat je nadenkt.
Kan je nog even aangeven wat er fout is aan de Kostprijs ... ik wil het nog wel een beetje kunnen volgen.

Probleem zit in het feit dat kostprijs aan de inkoopzijde nu binnen jouw systeem 2 definities lijkt te hebben:

1e = is de kale regelprijs van de inkooporder
2e = de waarde waartegen het werkelijk ontvangen wordt in de voorraad (incl. DKK's e.d.)

Wat ons betreft is de 2e de echte kostprijs (gekoppeld aan financiele mutatie)

Jij registreerd in LOCP echter de 1e als zijnde de kostprijs.

dat is de discussie...

Nee, dat is het wat mij betreft niet  :smile:

Jij stelt m.i. dat bij een handmatige voorraadmutatie, waarbij de prijs niet bepaald kan worden o.b.v. de aanwezige voorraad, het systeem bepaalt o.b.v. de LOCP prijs, en daarmee de Inkoopprijs zonder de kostprijsverhogende DKK's.

Met Wouter ben ik het sowieso eens, met Marco misschien. :smile:

Eerst maar even voordat ik zelf de verwarring zaai (ben ik best goed in) : Wouter, bevat LOCP nou the Werkelijke Kostprijs (dus inklusief DKKs) of niet ?
Zo niet, welk volgens ons officieel fenomeen (berekening e.d.) bevat dat dan wel ?

LOCP bevat de kostprijs exclusief de DKK's.

De waarde incl. DKK's staat bijv. in de Voorraadmutaties van de Goederen Ontvangst.

Maar... er is meer aan de hand... denk ik...

Ik koop een produkt in voor EUR 5,- en doe er EUR 2,- aan DKK bij. Het produkt komt voor EUR 7,- op voorraad te liggen (en LOCP bevat een waarde van EUR 5,-).

Als ik eerst alle voorraad verbruikt heb, en daarna weer wat opboek, wordt gewoon de waarde van EUR 7,- gebruikt. LOVMTV toont als kostprijs reden "de voorraadmutaties".

De kostprijs bij een handmatige voorraadmutatie kan door diverse zaken worden bepaald:

- Bestaat het betreffende Voorraaditem?
- Is er voorraad van deze Artikel/Vrs/Charge/Lokatie/Inhoud (ongeacht Intern Charge)
- Is er voorraad van deze Artikel/Vrs/Charge
- Zijn er voorraadmutaties van deze Artikel-/Vrs/Charge
- Zoeken bij Inkooporders
- Zoeken bij Produktieorders
- Laatste kostprijs Artikel

Wat de "reden" is op basis waarvan de prijs bepaald wordt, wordt genoemd in het LOVMTV scherm.
Ben benieuwd wat hier bij MdKraa stond.

Zojuist nl. even ingebeld, en ik konstateer dat de Artikel-/Verschijning waar MdKraa het over heeft, helemaal niet als zodanig is ingekocht. Het is in Verschijning ORIG099 ingekocht, en daarna omgevormd naar 975AI. Daarna treedt bij dié verschijning de situatie op.

Notabene blijkt dat het voorstel om te zoeken naar de Voorraadmutaties van de Goederen Ontvangst al lang wordt toegepast ! Maar ja... het is een ART008660/975AI die MdeKraa opboekt, en die is nooit ingekocht! (maar omgevormd uit een ORIG099).

De volgende manier waarop dán de prijs bepaald wordt, is door het produkt te lokaliseren op de betreffende Inkooporder, die hoort bij het Chargenummer. Hierbij wordt dan enkel de Inkoopprijs gebruikt, en geen DKK's of andere aan de inkoopzijde kostprijsverhogende faktoren (opslagpercentages).

Nb: Merk op dat er helemaal nooit een kostprijs uit LOCP wordt gehaald ! Dit zal puur een aanname geweest zijn omdat MdeKraa vraagt naar de kostprijs van de Charge, en op tabel LOCP gewezen wordt.

De Inkoopprijs uit de Voorraadmutatie van de Goederen Ontvangst te halen wordt ook toegepast in het eerder genoemde scherm (LOARCPRA?), en lijkt me op zich een juiste methode. Het gaat echter fout omdat er aldaar wordt gezocht geacht Verschijningsvorm 975AI terwijl die nooit is ingekocht, maar omgevormd.

Daar moet mogelijk een 2 trapsraket worden ingebouwd: 1e keer niets gevonden, dan o.b.v. het Chargenummer de Inkooporderregel zien te bepalen (waar anders de prijs uitgehaald zou worden), kijken of daar een andere Verschijningsvorm staat, en zo ja, dan nogmaals zoeken met dié Verschijningsvorm waaronder het is ingekocht...

Hoef ik inmiddels niet meer te weten: er zal wel hebben gestaan dat de Prijs uit de Inkooporderregel werd gehaald.

Juist, dank je Wouter. Dat bevestigt mijn vermoeden dat mijn LOCP antwoord onjuist was, want immers :

Dan hadden we nooit voorraad kunnen verplaatsen (naar een magazijn in het buitenland bijvoorbeeld), de "kostprijs" laten ophogen via (Transport) DKKs, en het weer terug laten komen op de eigen voorraad met een vervolgens hogere Kostprijs (wat overigens alleen kan werken als het niet op dezelfde Lokatie komt te liggen als hetzelfde produkt met dezelfde Charge).

Weten we dat ook weer (eens).
:smile:

Maar? mag dit een oplossing zijn?

Ik heb "een gevoel" van niet.

Dit zou moeten gaan om het handmatig opboeken van een produkt in een Verschijningsvorm die op dat moment niet op voorraad ligt (toch ?). Dus, we gaan dan op zoek naar een andere (eigenlijk) willkeurige Verschijningsvorm die uit Inkoop is ontstaan. Hierbij moet je dan m.i. denken aan "zo direkt mogelijk" of zo. Heb ik nog een beetje gelijk, dan slaat dit nergens meer op. Immers, je kan het hier wel (willen) hebben over dat produkt wat net een rondje magazijnen heeft gedaan.

Tuurlijk, Marco zegt onmiddellijk dat bij hem dit rondje niet aan de orde is. Mooi. Maar ook mooi toeval.

Nogmaals-als-ik-gelijk-heb ... je moet helemaal niets handmatig opboeken. Doe je dat toch, dan moet je zelf even de juiste Kostprijs uitzoeken.
Anders gezegd, ik vind het te ver gaan om dit op te lossen. Het kan alsnog weer fout zijn.

Ok, zonder verdere reaktie even aannemend dat ik gelijk heb, kunnen we het nog steeds maken als Marco rekening houdt met de "niet 100%". Wouter, hoeveel tijd zal daar ruwweg inzitten ?

Denk dat het nu nog een kwestie van 0,5 uur is (nadat er eerst al 2 uur uitzoekwerk verricht is).

Ik had eerst ook twijfels over het mogen gebruiken van een Inkoopprijs van een andere Verschijningsvorm, helemaal omdat je kunt bedenken dat die DKK's door de Verschijningsvorm v/d I.O. getriggerd zijn, en mogelijk niet aan de orde zijn bij de andere Verschijingsvorm... echter... het gaat wel om de Inkooporder van hetzelfde Charge waar het om gaat... Ofwel... de Charge zegt feitelijk al dat het produkt op die Inkooporder is ingekocht.
Dan mag het ondertussen wel in een andere Verschijningsvorm zitten, maar als de Goederen Ontvangst Voorraadmutatie wordt gevonden, is het i.i.g. via die I.O. ontvangen. en mag die prijs ook wel gelden.

Bakken we zoiets niet in bij het zoeken naar de Voorraadmutatie, dan geldt dat de prijs uit dezelfde verkeerde I.O. regel gehaald wordt, maar dan zonder DKK's en opslagen erbij, wat denk ik alleen maar fouter is.

Aangaande het laatste : ja, daar zal je gelijk in hebben. Maar misschien moeten we (en iedereen) ons afvragen in hoeverre de gevonden prijs als juist moet worden gezien, of alleen een advies betreft. En natuurlijk, in het ene geval is het gewoon juist, maar in het andere geval is het domweg niet zeker. Nou weet ik alleen niet hoe gemakkelijk herkenbaar het is of het "zeker" is of niet.

Marco, je zal het wellicht niet willen, maar voor 1 uur heb je het wat mij betreft.

Als het met dat ene uurtje "minder fout" gaat  : graag....
:17c:

Aangepast. Staat op je systeem.