Heart-Profit ERP
July 03, 2024, 02:19:00 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1] 2  All
  Print  
Author Topic: Prijsbepaling inkoop charge gaat niet goed bij af en bij boeken  (Read 6439 times)
0 Members and 0 Guests are viewing this topic.
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« on: July 19, 2010, 12:18:47 pm »

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.
Logged

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« Reply #1 on: July 19, 2010, 12:34:53 pm »

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).



Logged

Heart-Profit company ID : HA
Peter Stordiau
Administrator
Partner
*****
Offline Offline

Posts: 4073


Just testing


View Profile WWW
« Reply #2 on: July 19, 2010, 12:37:35 pm »

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).
Logged

Heart-Profit company ID : HA
moderator all boards
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« Reply #3 on: July 19, 2010, 02:49:51 pm »


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) :

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"?
Logged

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
Peter Stordiau
Administrator
Partner
*****
Offline Offline

Posts: 4073


Just testing


View Profile WWW
« Reply #4 on: July 19, 2010, 03:40:53 pm »

Quote
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.

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.
Logged

Heart-Profit company ID : HA
moderator all boards
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« Reply #5 on: July 19, 2010, 04:29:28 pm »

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......
Logged

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
Peter Stordiau
Administrator
Partner
*****
Offline Offline

Posts: 4073


Just testing


View Profile WWW
« Reply #6 on: July 19, 2010, 07:59:52 pm »

Tabel LOCP.
Logged

Heart-Profit company ID : HA
moderator all boards
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« Reply #7 on: July 20, 2010, 11:29:12 am »

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
Logged

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« Reply #8 on: July 20, 2010, 11:41:37 am »

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

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...
Logged

Heart-Profit company ID : HA
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« Reply #9 on: July 20, 2010, 11:52:45 am »

Als je bedoeld het scherm LOCPARRA, ja

Bij het Raadplegen van de Goederen Ontvangsten van een Artikel (Hmenu-4-2-4-3) is kolom "Prijs per Eenheid" gewijzigd in kolom "Inkoopprijs per Eenheid". Daarnaast is er een 2e kolom opgenomen met daarin de Kostprijs per Eenheid. Dit betreft de waarde waarvoor het produkt op voorraad gekomen is (LOCP->KOSTPRYS).

FunktieOmschrijvingDtm.Vl.WyzDtm.L.Wyz
LOCPARRA    Raadplegen Ontvangen Artikelen    21-01-2009    14-10-2009


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

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« Reply #10 on: July 20, 2010, 12:49:19 pm »

Helaas heb je daar geen gelijk in  Sad

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).
Logged

Heart-Profit company ID : HA
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« Reply #11 on: July 20, 2010, 01:49:04 pm »

ellende hé,

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

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
Peter Stordiau
Administrator
Partner
*****
Offline Offline

Posts: 4073


Just testing


View Profile WWW
« Reply #12 on: July 20, 2010, 05:55:46 pm »

Quote
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.

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.
Logged

Heart-Profit company ID : HA
moderator all boards
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« Reply #13 on: July 22, 2010, 10:24:30 am »

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...

Logged

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« Reply #14 on: July 22, 2010, 10:38:06 am »

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.
Logged

Heart-Profit company ID : HA
Pages: [1] 2  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.1 seconds with 21 queries.