Jump to content
  • 0

Status van de order op basis van oudste gerelateerde record


eroos

Question

Posted

Ik zit met het volgende probleem:

 

De status van een order wordt bepaald door de aanwezige voorraad. Wanneer er van een product voldoende voorraad is dan krijgt de order de status compleet.

 

Welnu, wanneer 2 orders hetzelfde product hebben, dan krijgen beide orders de status compleet. Ik zou graag willen dat alleen de oudste order de status compleet krijgt. Tenzij er voldoende voorraad is om beide orders de status 'compeet'mee te geven. ter illustratie voeg ik een simpel voorbeeldje toe. Een vereenvoudigde voorstelling van de huidige situatie.

 

In dit voorbeeld zou het tweede record de status 'In bestelling' moeten hebben. Mits de voorraad 2 stuks zou bevatten dan mogen beide orders op compleet komen te staan.

 

Een maar... dit wens ik zonder een sortering of script.

compleet.fp7

10 answers to this question

Recommended Posts

  • 0
Posted

Ik denk dat je heel wat velden mist, waardoor je niet de juiste hoeveelheid kunt kennen.

 

Feitelijk dien je het KOOP te bepalen (Klant Order Ontkoppel Punt).

Het maakt niet uit hoe of vanwaar de vraag om een artikel binnenkomt, vanaf dit punt behandel je alle aanvragen op dezelfde manier, onafgezien wie/hoe/vanwaar/waarom enz de vraag gesteld wordt.

 

Je zegt:

De status van een order wordt bepaald door de aanwezige voorraad

 

Ik zeg:

De status van een order wordt bepaald door de beschikbare voorraad.

 

En die berekening heb je niet.

Stel dat er een bestelling per telefoon binnenkomt, afhaling later.

Het artikel is fysisch nog aanwezig (op 't schap), maar is eigenlijk al 'verkocht'.

 

De basisvelden die je zou nodig hebben voor een simpele voorraadopvolging zijn o.a.:

+ Receiving: materials that have been received into inventory as new products.

- Manual Orders: orders that have been keyed by a customer service representative

- Web Orders: orders that have been processed by the eCommerce system

- Return to Inventory (RTI): products that have been returned as used, but are still resellable. In some business models these products may be returned to a special part number to indicate that they are to be resold at a discount since they have been used or cannot be repackaged as new.

- Return to Vendor (RTV): defective merchandise that has been returned to the vendor for credit or replacement.

- Production: raw materials that are consumed during the production process.

+/- Adjustments: manual adjustments to the inventory to correct for mistakes and shrink (theft).

 

Nu komt pas hoe je het probleem van orders aanpakt:

 

Daar heb je een afzonderlijke berekening voor nodig:

Ordered Quantity On Hand

 

+ ActualQuantityOnHand: calculation from above.

+ OrderedQuantityOnHand: purchased items waiting to be received from the supplier.

 

Bekijk het geheel eens vanuit die invalshoek.

  • 0
Posted

Natuurlijk Peter, Jean weet heel goed waarover het gaat omdat hij heel goed heeft begrepen waarover het gaat. We mogen niet vergeten dat Jean hier de uitvinder is van de behangpapiermythe, en gelijk heeft ie.

In plaats van schamele spaarpotpogingen te doen om hem eens tussen ons op een confituursessie te hebben, zouden we hem beter officieel uitnodigen als spreker in Antwerpen of in Nice. Misschien dat zijn universiteit dan snapt wat voor gereputeerd talent ze in huis hebben, en dat ze dan eens voor hun eigen uitstraling zorgen door hem naar hier te sturen.

  • 0
Posted

Jean,

 

Bedankt voor je uitgebreide kennisvoordracht. Ik ben het geheel met je eens. Ik schreef ook dat dit een eenvoudige voorstelling van zaken was.

 

Ik heb een tweetal voorbeelden toegevoegd die het geheel verduidelijken. Hierin kun je ook zien dat de voorraad uit veel meer bestaat dan alleen de aanwezige voorraad.

 

In het tweede plaatje zie je vervolgens waar het om gaat. Zodra een product voldoende vrije voorraad heeft dan wordt de order vrijgegeven. Alleen geldt dat voor iedere gerelateerde order die op dat moment open staat. De klant wenst op basis van de complete orders een planningslijst te maken. Het probleem is nu dat ze niet kunnen zien aan de orderlijst wie er nu aan de beurt is. De langst openstaande order krijgt het eerst binnengekomen product. Zij achten het dus wenselijk dat alleen de oudste order op compleet komt te staan zodat meteen duidelijk is wie het product behoort te krijgen.

 

Vrije voorraad = beschikbare voorraad. Zodra deze op pakbon staan gaan ze van de vrije voorraad af. Ze gaan pas van de werkelijke voorraad af wanneer ze het pand verlaten.

Het gaat dus nog om het moment voor de pakbonfase.

 

Hopelijk schept dit meer duidelijkheid en heb je alsnog een passende oplossing.

compleet.thumb.jpg.251b15f38df4ffcbefd44238a5d80105.jpg

Voorraad.jpg.d8f6c303b0f533777d319fb4af7c0065.jpg

  • 0
Posted

Iets duidelijker, maar niet helemaal.

Ik ken je gegevensflow niet en ook niet de berekeningen achter je velden.

 

Op het eerste zicht vind ik het raar dat er 1 in vrije voorraad is, terwijl er 2 in backorder staan. (en 0 in min. voorraad).Maar dat is iets anders.

 

Je probleem is een 'toewijzing' die je zonder 'klikken' wil doen.

 

Ik denk in de richting van een op datum gesorteerde bonnummerartikelnummerhoeveelheidlijst, wat je de oudste eerst zal geven met het aantal.

Dan een vergelijking maken met het aantal opnieuw beschikbare artikelen, een toewijzing van het aantal aan de oudste.

Indien het opnieuw beschikbare aantal groter is dan het ontbrekende aantal voor de gegeven bonnummer kan naar de volgende gegaan worden.

Indien het opnieuw beschikbare aantal kleiner is dan het ontbrekende..... 8O:twisted:

 

Met een 'klik' zouden we er al zijn.....

  • 0
Posted

Jean... je bent ook niet te foppen...!

 

Om het voorbeeld te laten slagen heb ik de vrije voorraad, even met de hand, ééntje verhoogd, zodat de productregels voor die order op 'compleet' kwamen te staan. Ik heb nog even overwogen of ik dit erbij zou melden maar ik dacht "dat zien men toch niet". Helaas dat ziet men dus wel... heel goed!

 

Er is in dit voorbeeld dus geen vrije voorraad en dus ook geen werkelijke voorraad. Die moet nog binnenkomen.

 

Minimale voorraad is iets geheel anders. Als men altijd een minimale voorraad wenst dan kan dat hier opgegeven worden. Er wordt dan automatisch bijbesteld als de voorraad onder het minimale niveau zakt. Bijvoorbeeld voor producten met een hoge doorloop snelheid.

 

De werkelijke toewijzing gebeurd door de order om te zetten naar de pakbon. Op dat moment wordt de vrije voorraad aangepast. De overige order springt dan automatisch op 'in bestelling'.

 

Het gaat er dus om dat de klant in één oogopslag ziet dat er twee orders zijn met dit product maar door de status kan zien dat de een voorrang heeft boven de ander op basis van de oudste datum en het feit dat de order compleet is.

 

Is er geen oplossing te verzinnen met een recursief CF-je en de GetNthrecord() functie?

  • 0
Posted
.... maar ik dacht "dat zien men toch niet". Helaas dat ziet men dus wel... heel goed!
:lol:

 

De werkelijke toewijzing gebeurd door de order om te zetten naar de pakbon.

Dus alles wat op dat order staat wordt 'pakbon' ?

Is dat in een lineItem tabel ?

Op dat moment wordt de vrije voorraad aangepast. De overige order springt dan automatisch op 'in bestelling'.

Op welke manier gebeurt dit precies ?

Berekening, script....

Is er geen oplossing te verzinnen met een recursief CF-je en de GetNthrecord() functie?

 

Misschien wel, maar ik tracht nog altijd 'greep' te krijgen op de structuur en de dataflow.

En vermits je het ook zonder sortering wilt hebben......en zonder 'klik'.....

  • 0
Posted

Jean,

 

Alle items die voldoende voorraad hebben gaan naar pakbon. Een order kan dus meerdere pakbonnen hebben. Alleen die orderregels die naar pakbonregels gaan worden door middel van een berekening van de voorraad afgehaald.

 

De gehele voorraad werkt door middel van berekeningen en relaties in de productentabel. Hier komt geen script aan te pas.

 

Op het moment dat een bepaalde productcode (uniek) beschikbare voorraad heeft dan springen de gerelateerde orderregels op 'groen'. Als alle regels van de order, voorraad hebben dan geeft de order 'compleet' aan, anders 'Deels'. De klant heeft de keuze om incomplete orders uit te leveren of te kiezen voor complete orders (Deelleveren toestaan: ja of nee).

 

Wat nu wenselijk is dat de status (groen kleurtje en compleet) alleen voor de oudste regel geldt voor de orderregel, indien er bijvoorbeeld maar 1 product is binnengekomen maar er wel twee openstaande orderregels zijn met dat product. Nu worden ze allebei als compleet aangegeven. Het voorbeeldje wat ik er in eerste instantie aan toegevoegd hebt illustreerd dat.

  • 0
Posted

Voor zover ik er zicht op heb zit je probleem net tussen twee bewerkingen in, waarbij de ene van de andere afhangt.

 

Je inventory wordt pas aangepast nadat het artikel van status verandert (orderbonartikel wordt pakbonartikel).

 

Het resultaat hiervan moet een terugkoppeling krijgen naar de overblijvende orderbonartikelen.

 

Dat heb je al met een kleurweergave.

 

Maw, links reageert op veranderingen van rechts.

 

Wat jij nu wil bereiken is dat rechts een reactie geeft op wat er overblijft links nadat er rechts een verandering is.

 

Nu, wat is je definitie van 'oudste' ?.

Indien we enkel naar de datum kijken, kan bv een Max(datum) berekening al iets helpen.

Maar wat dan met records met dezelfde datum ?

 

Dus wordt het bv Max(timeStamp).

 

Je zou bv met een CF kunnen werken waarbij je de records per tijdsindicatie (timestamp) in een stack zet, waarbij er een verwijzing is naar het aantal van het artikel in de inventory (die nu momenteel op bv 0 (nul) staat).

 

Van het ogenblik dat die waarde niet nul meer is, wordt de eerste lijn van de stack verwijdert.

Daarbij heb je al de 'oudste' die aan je voorwaarde voldoet.

 

Maar ik zit voorlopig vast wanneer het méér dan 1 is voor het 'oudste'.

 

Mijn CF doorloopt de stack, past de eerste aan met '1', en vervolgt de loop in de stack om dan te herbeginnen tot ofwel de stack leeg is, ofwel de inventory terug op nul staat.

 

Indien de oudste 2 aantallen mist en de volgende maar 1 en de inventory heeft er 2 beschikbaar, wordt de tweede van de stack verwijdert, terwijl de 'oudste' nog altijd met 1 open blijft in de stack. :evil:

 

Dus twee of meerdere bonnen krijgen ieder 1 artikel per recursie.

En dat is de bedoeling niet.

 

Maw. ik zit voorlopig vast.

 

Ik vrees dat dit 'terug naar familie' wordt.

 

Ik heb spijtig genoeg geen tijd om verder te zoeken, tenzij ik een tijdelijke :idea: krijg.....

 

Een volledig zicht op het geheel zou natuurlijk een hulp zijn, terwijl we nu 'op veronderstelling' moeten afgaan....

  • 0
Posted

Jean,

 

Je uitleg is helder. Je begrijpt dat ik niet de volledige database kan vrijgeven. Ik zal eens met de huidige uitleg en iterpretatie een poging wagen om het geheel in een CF te plaatsen. Voor nu bedankt voor je aandacht. Ik ga er mee aan de slag. Mocht ik de oplossing gevonden hebben dan meld ik dat uiteraard.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...