Heart-Profit ERP
June 29, 2024, 10:36:34 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Kostprijzen  (Read 1832 times)
0 Members and 1 Guest are viewing this topic.
esa123
Poster
*
Offline Offline

Posts: 15


View Profile
« on: December 09, 2013, 10:08:47 am »

Bij het aanmaken van een productie order met een X aantal liters wordt automatisch het aantal verschijningen berekend door het aantal liters te delen door de werkelijke inhoud van de opgegeven verschijning.
Tot zover niets mis mee en zolang je daar niet vanaf wilt wijken ook geen probleem.

In ons geval echter maken we gebruik van sub codes:
Dat betekend dat we van bijvoorbeeld artikel 667VR0013 ook artikel 690VR0013 uit een en dezelfde batch willen produceren.
Dit is namelijk exact hetzelfde product maar wordt onder een andere code verkocht.
De werkwijze is dan als volgt: eerst geef je de productie order op noprmale wijze in en  daarna ga je de output wijzigen naar de benodigde (sub) code nummers: zie voorbeeld.
 
Dit werkt prima zolang je daar geen rechten aan gaat ontlenen.
Op het moment dat je de productie order gereed gaat melden, dan boek je beide regels op als gereed product.
Hp zal dan alleen van de originele code een kostprijs mee overnemen en netjes verwerken zoals het hoort.
Van de sub code daarentegen wordt de kostprijs niet mee over genomen en boekt HP naar vrd zonder de juiste waarde.

Aangezien wij heel vaak gebruik maken van sub codes en deze ook al in eerste aanleg, dus bij het ingeven van de productie order, inzichtelijk willen hebben.
Graag een passende oplossing hiervoor……….

Logged

Heart-Profit company ID : CH
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« Reply #1 on: December 09, 2013, 11:14:27 am »

Je krijgt e.e.a. nu voor elkaar om zowel een 667 als een 690 in één Produktieorder te produceren door gebruik te maken van 'Bijprodukten'.

Bedoeld om bijv. stenen te produceren, waarbij het je doel is om 1e keuze te produceren, maar waarbij er ook 2e keus stenen uit de order kunnen komen. Omdat e.e.a. een 'Bijprodukt' is, en we een 2e keus niet eenzelfde kostprijs willen meegeven als een 1e keus, werken Bijprodukten met een zgn. Terugwinwaarde (instelbaar bij de Artikel-/Verschijning).

Dit projecterend op jullie situatie, zou je bijv. een P.O. kunnen maken voor 1000 liter 667.
De kostprijs van de grondstoffen en bewerkingen voor deze 1000 liter zijn (stel) EUR 5.000,- waaruit normaliter zou volgen dat 1 liter 667 een kostprijs krijgt toegekend van EUR 5.000,- / 1000 liter = EUR 5,00 per liter.

Door nu ook 200 liter 690 in de output van de P.O. op te nemen wordt dit per definitie betiteld als een bijprodukt.
Bij de Artikel-/Verschijning van de 690 kun je een terugwinwaarde opgeven, die op bijv. EUR 3,50 / liter zou kunnen staan.

Het werken met Bijprodukten vereist dat je bij het gereedmelden éérst de hoeveelheid bijprodukt opgeeft, immers, die is van invloed op de prijs van het daadwerkelijk te produceren produkt. Door 200 liter 690 op te boeken á EUR 3,50 wordt er 200x3,50 = EUR 700,- in mindering gebracht op de kostprijs van de charge, die daarmee op EUR 4.300,- uitkomt. Ervanuitgaande dat er dan nog 800 liter 667 volgt, krijgt deze een kostprijs van EUR 5,3750 per liter (4300/800).

Ik begrijp dat wat jij wilt neerkomt op "ik wil én 667 én 690 (en in theorie nog 10 andere artikelen) kunnen produceren in dezelfde order, en die moeten dan allen dezelfde kostprijs toegekend krijgen".


Oplossing zoals voorgesteld
Nauwelijks te overzien. Het druist in tegen een aantal basis uitgangspunten, zoals een Chargenummer die uniek moet zijn voor het Artikelnummer.
Je zult op diverse plekken vastlopen, waarbij vooraf amper kan worden overzien welke. Je wilt 667 én 690 via hetzelfde Recept kunnen produceren. Maar voor welk artikel definieer je je recept ? De 667? En wat dan als 667 niet behoeftig is, maar de 690 wel ? Daar heb je geen recept voor. Natuurlijk kun je de 690 óók als recept definiëren met de 667 als bijprodukt, maar dat is geen doen. Stel maar voor wat er gebeurt als je het artikel onder nog 10 artikelnummers verkoopt...
Denk aan funktionaliteit als 'eerst opboeken, dan afboeken', die produkten met 'prijs niet bekend' op voorraad legt, en achteraf de waarde gaat toekennen. Een dergelijk proces zal als eerste niet meer werken als we klakkeloos een 2e produkt zouden produceren in dezelfde order.


Klant-/Artikelnummers
Klant-/Artikelnummers kunnen we gebruiken om een produkt onder een ander Artikelnummer aan een klant te verkopen.
We zouden ermee in staat zijn om een 667 van voorraad te rapen, en deze aan een klant te verkopen als 690.
Of, de klant bestelt 690, maar in de Verkooporderregel komt automatisch te staan dat we dan 667 moeten leveren.

In theorie komen we daar natuurlijk wel een eind mee, maar... deze oplossing zorgt ervoor dat op de documenten een ander artikelnummer (en-/of omschrijving) komt te staan, en, dat hoeft niet voldoende te zijn. Stel dat je 1000 liter 667 produceert, en dit afvult, dan zou je altijd bij het leveren het produkt moeten ometiketteren, omdat ze als 667 op voorraad ligt, en als 690 de deur uit moet.
Ik vermoed dat het jouw bedoeling is er voorraad van aan te houden, en al meteen 690 op voorraad te kunnen hebben zodat er niets om geëtiketteerd hoeft te worden bij het rapen.


Oplossing via Verschijningsvorm
Wat doe je normaliter met een klant specifieke verschijning waarvoor je voorraad wilt aanhouden?
Stel dat je een Artikel hebt, en een klant wil dat produkt hebben in een specifieke verschijning, met een ander label, of desnoods met een andere inhoud, dan maak je een andere Verschijningsvorm aan bij dat artikel. Wel. Dát zou hier dus ook de job kunnen doen. Als een 690 hetzelfde is als een 667, dan zou je ervoor kunnen kiezen hier geen 2e artikelnummer 690 voor aan te maken, maar de 690 te zien als aparte verschijningsvorm van je 667. Je produceert dan gewoon één artikel en kunt dat óók afvullen in een 690 verschijning.
Uiteraard zul je dat moeten kombineren met klant specifieke artikelnummers, want je wilt natuurlijk niet op je faktuur naar de klant vermelden dat je een 667 levert in een 690 verschijning, je zult alleen de 690 willen vermelden.


Oplossing via Halffabrikaat
Een oplossing zou kunnen zijn om het produkt welke je onder verschillende artikelnummers op voorraad wenst te produceren als een halffabrikaat te definiëren. Deze gaat dan voor 100% in het recept van de 667, maar ook voor 100% in het recept van de 690. Op die manier kun je een P.O. hebben voor 1200 liter 667, een P.O. voor 500 liter 690, die dan resulteren in een P.O. voor 1700 liter halffabrikaat.


Oplossing via Kenmerken
Een oplossing die als geen ander zou werken, is door gebruik te maken van Kenmerken. Je zou in staat zijn om een produkt X te produceren, hier één set Verschijningsvormen voor te hebben, en in een Kenmerk "het etiket" te registeren. Je verkoopt dan een produkt X met een 667 etiket of een 690 etiket (of een van de 100 andere mogelijke etiketten).
Een Artikel in één Verschijning onder 10 verschillende etiketten leveren impliceert dan hooguit dat de Kenmerkwaarde van het etiket wijzigt.
Deze oplossing vereist de module Profit-Kenmerk, waar jullie al wel eens mee getest hebben, maar welke nooit echt in gebruik is genomen.

Resumer: de oplossing met Kenmerken lijkt mij het beste. Als je e.e.a. niet met Kenmerken wilt oplossen, dan zou ik voor de oplossing met een formeel halffabrikaat gaan die tot meerdere (unieke) eindprodukten leidt. Alle rest lijkt me niet eenvoudig te werken.
Het enige wat ik me nog kan bedenken is dat als je werkt op de wijze zoals je nu doet, en je kostprijzen over het algemeen wel redelijk stabiel zijn, je zelf een reële terugwinwaarde bij de 690 zou kunnen vastleggen, waardoor het verschil in waarde met de 667 verkleind wordt. Toch blijf je dan alle problemen behouden m.b.t. één Chargenummer die voor twee Artikelen op voorraad gebruikt wordt, welke elders tot ellende kan leiden...
Logged

Heart-Profit company ID : HA
Pages: [1]
  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.014 seconds with 19 queries.