Heart-Profit ERP
September 29, 2024, 07:33:43 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Analyse Behoefterun Inkoop inhoud > standaard inhoud  (Read 970 times)
0 Members and 2 Guests are viewing this topic.
Heart Informatisering B.V.
Partner
******
Offline Offline

Posts: 27468


View Profile WWW
« on: October 11, 2012, 12:55:30 pm »

M.i.v. deze Releasenote is de Behoefterun drastisch gewijzigd m.b.t. de afhandeling van Behoeftes Ongeacht de Verschijningsvorm; ofwel, behoeftes in -------.

Omdat deze impact redelijk groot kan zijn, is ervooralsnog een nieuwe rubriek opgenomen in het scherm waaruit de Behoefterun kan worden opgestart, te weten: "Methode behoeftes Ongeacht Verschijningsvorm 1/2".

Methode #1 is de defaultwaarde, en betreft de werkwijze zoals deze tot heden werd uitgevoerd. Laat deze rubriek op deze #1 staan, en de Behoefterun zal niet anders werken dan voorheen.

Methode #2 triggert de nieuwe werkwijze. Deze methode zal zichzelf eerst nog moeten bewijzen, en zit derhalve achter een expliciet in te stellen rubriek.

Vanwaar een aanpassing en een nieuwe werkwijze?

Wel, Ongeacht Verschijningsvorm kunnen we weliswaar behoeftes hebben (we hebben een produkt nodig in produktie, en het maakt ons niet uit of dit uit een zak van 25 Kg, een bigbag van 400 Kg, of uit een container van 1000 Kg komt), maar, we kunnen niet inkopen of produceren ongeacht de Verschijningsvorm (let op: Kg-bulk kan wel, maar betreft dan een specifieke Verschijningsvorm: "KG").

Een behoefte ongeacht Verschijningsvorm zal dus moeten worden omgezet naar een behoefte géacht Verschijningsvorm, en, zie de Helptekst van het scherm waar we de Behoefterun opstarten, dit doet ze conform verschillende algoritmes; een zo'n algoritme is het kiezen van de meest optimale Verschijningsvorm kwa inhoud; hebben we 10 Kg nodig, dan zal een zak van 25 Kg worden ingekocht, en hebben we 800 Kg nodig, dan kopen we een container van 1000 Kg in.

Per heden zijn een tweetal problemen gekonstateerd, waarbij we ons eigenlijk kunnen afvragen waarom dit niet eerder gekonstateerd is.

In een praktijksituatie hebben we te maken met een grondstof. Deze wordt niet aan klanten verkocht, en alleen maar verbruikt in produktieorders. In Produktieorders is 22000 Kg ongeacht de Verschijningsvorm (-------) behoeftig. Het produkt wordt in bulk ingekocht, en, er is een openstaande Inkooporder gegenereerd voor 20000 Kg bulk. Omdat er geen silo's zijn waarin het produkt kan worden opgeslagen, worden de goederen ontvangsten direkt afgevuld in containers (met ieder hun eigen inhouden), maar, stel maar voor het gemak maar eens containers van 1000 Kg per stuk. Op voorraad hebben we nog 8 containers van 1000 Kg staan.

Wel, zo naar bovenstaand voorbeeld kijkend, hebben we 8000 Kg op voorraad staan, staat er 20000 Kg uit inkoop te komen, en kunnen we beschikken over 28000 Kg. We hebben "slechts" 22000 Kg nodig, en dus zou dit makkelijk moeten kunnen zonder opnieuw bij te bestellen.

Helaas bleek de praktijk anders... De behoefte van 22000 Kg ongeacht Verschijning moest worden omgezet naar een behoefte géacht Verschijning. Hierbij kon het systeem kiezen uit twee Verschijningen: of "Container 1000 Kg", of "Kg Bulk".

Zodra ze container koos hadden we 22 TN uitgaande behoefte in containers, en slechts 8 TN op voorraad, en dus werd er 14 TN besteld. Koos ze voor "bulk", dan hadden we 22 TN behoefte, 20 TN op inkoop, en werd er alsnog 2 TN besteld.

Het ging alhier fout omdat de behoefte in ------- niet door meerdere Verschijningsvormen gedekt kon worden.

Een tweede situatie die fout ging, betrof een situatie waarin er 140 Kg behoeftig was ongeacht de Verschijningsvorm, het Artikel maar één Verschijningsvorm kende (een vat van 200 Kg), maar, dit vat nu incidenteel een keer bij een andere Leverancier werd ingekocht, die geen 200 Kg in het vat levert, maar 210 Kg. Ofwel, er was een Inkooporder gemaakt voor "vat", en op de Inkooporderregel werd de inhoud ad 200 Kg overschreven met 210 Kg.

De behoefte in ------- kon maar door 1 Verschijningsvorm worden gedekt: "een vat van 200 Kg". Maar, aangezien een vat met 210 Kg iets anders is dan een vat met 200 Kg, werd deze behoefte niet gedekt, en volgende er alsnog een besteladvies voor een vat van 200 Kg, terwijl er eigenlijk al ingekocht was (zij het met een andere inhoud).

Hoewel je van bovenstaande situatie zou kunnen stellen dat als je verschillende inhouden inkoopt, je ook andere Verschijningsvormen moet hebben, was ook dat geen oplossing, omdat dan net zo'n probleem kon optreden als "inkopen in bulk, en opslaan in containers".

Bij methode #2 is de werkwijze nu dan ook drastisch anders. De uitgaande behoefte in ------- wordt afgezet tegen alle voorraad en inkomende behoeftes van Verschijningsvormen waaruit mag worden omgevormd ("Afnemen Inhoud" bij de Verschijningsvorm staat op Ja). Blijft er daarna op enig moment een behoefte over, dan zal dit een behoefte zijn die overblijft nadat alle inzetbare voorraad, en inkomende behoeftes zijn ingezet. De behoefterun zal nu deze "dekkende" behoeftes elimineren, en continueren met het "tekort".

Ofwel, de 22 TN wordt weggestreept tegen de dekkende 8 TN op voorraad + 20 TN op inkoop, er blijft geen behoefte over, en dus hoeft er niets te worden ingekocht.

De 140 Kg wordt weggestreept tegen de inkoop van 210 Kg, er blijft geen behoefte over, en er hoeft niets te worden ingekocht.

Maken we het voorbeeld wat moeilijker, en stellen we dat we 1000 Kg in ------- nodig hebben, we 1xV200 (vat 200 Kg) met een inhoud van 200 Kg op voorraad hebben, we bij Leverancier A 1xV200 hebben ingekocht met een inhoud van 200 Kg, en bij Leverancier B 2xV200 doch met een inhoud van 210 Kg, dan geldt:

Dekkend = 200 Kg (voorraad) + 200 Kg (Leverancier A) + 420 Kg (Leverancier B) = 820 Kg. We hebben 1000 Kg nodig, blijft derhalve een restbehoefte van 180 Kg over. De inkomende (dekkende) behoeftes worden geëlimineerd en we gaan met het tekort van 180 Kg verder. Resultaat is dat we 1 vat van 200 Kg zullen moeten inkopen.

Bij methode #1 werd de uitgaande behoefte van 1000 Kg omgezet naar een uitgaande behoefte van 5 vaten van 200 Kg, hadden we 1 vat van 200 Kg op voorraad, stond er 1 vat van 200 Kg op inkoop (de vaten met een inhoud anders dan 200 Kg telden niet mee!) en stelde het systeem voor om 3 vaten van 200 Kg (= 600 Kg) in te kopen.

Nb: Reden dat bij deze procedure alleen de Verschijningsvormen meetellen waarvan "Afnemen Inhoud" op "Ja" staat, is dat als we bijv. verf produceren in een mengkuip, en dit na produktie afvullen in blikjes van 1 Kg, 2½ Kg en 5 Kg, en tevens in vaten van 200 Kg, we niet zullen willen dat het systeem voorstelt dat er niet geproduceerd hoeft te worden "omdat we eerst maar onze hele voorraad met blikjes van 1, 2½ en 5 Kg moeten opentrekken". Door bij die Verschijningen in te stellen dat Afnemen Inhoud niet is toegestaan, tellen deze niet mee als "dekkend voor een behoefte ongeacht Verschijningsvorm", en zal (ondanks een aanwezige voorraad in blikjes) toch worden voorgesteld te produceren.

FunktieOmschrijvingDtm.Vl.WyzDtm.L.Wyz
LOBHGN      Omschrijving (nog) niet bekend    27-03-2012    09-10-2012
LOBHGNTL    Omschrijving (nog) niet bekend    07-05-2012    09-10-2012
LOBHGNV1    Omschrijving (nog) niet bekend    07-05-2012    09-10-2012
LOBHGNV3    Omschrijving (nog) niet bekend    07-05-2012    09-10-2012
LOBHGNVI    Omschrijving (nog) niet bekend    29-12-2008    09-10-2012
LOBHOBTD    Omschrijving (nog) niet bekend    07-05-2012    10-10-2012
LOBHOI1     Opbouwen Indexen.    29-03-2012    09-10-2012
LOPBGNF1    Omschrijving (nog) niet bekend    07-05-2012    09-10-2012
LOPBIVGN    Genereren Produktiebehoefte    09-10-2012    10-10-2012
LOPIGN      Omschrijving (nog) niet bekend    06-12-2010    10-10-2012
LOPIGN2     Omschrijving (nog) niet bekend    07-05-2012    09-10-2012
LOPIGNDI    Omschrijving (nog) niet bekend    07-05-2012    09-10-2012
Logged
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.06 seconds with 19 queries.