Heart-Profit ERP
July 03, 2024, 12:59:49 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Available To Promise (ATP) check bij Verkooporderregels (2)  (Read 1836 times)
0 Members and 0 Guests are viewing this topic.
Heart Informatisering B.V.
Partner
******
Offline Offline

Posts: 27445


View Profile WWW
« on: September 21, 2007, 10:11:47 am »

Middels een Bedrijfsparameter kan worden aangegeven of bij het Toevoegen van Verkooporderregels een Available To Promise kontrole (check) moet worden uitgevoerd. Indien deze parameter aan wordt gezet, zal van iedere Verkooporderregel door het systeem moeten worden gekontroleerd of de ingevulde Leverdatum mogelijk is.

Dit gebeurt door per Verkooporderregel een Behoefterun te draaien. Uit deze Behoefterun mogen best Besteladviezen volgen, maar deze behoeftes mogen niet in het verleden komen te liggen. Ofwel, zodra de gevraagde Leverdatum voldoende ver in de toekomst ligt dat hetgeen verkocht wordt uit voorraad geleverd kan worden danwel tijdig geproduceerd/ingekocht kan worden, dan zal de orderregel geaccepteerd mogen worden. Zodra er echter een Leverdatum wordt ingevoerd waaraan we niet kunnen voldoen, dan zal deze geweigerd worden, c.q. zal de ATP check de Leverdatum wijzigen in hetgeen als eerste mogelijk is.

 
De ATP Check werkt met als uitgangspunt dat iedere vorige Behoefterun per saldo in evenwicht was, en als ze nu niet meer in evenwicht is, dit het gevolg moet zijn van de laatst erbij betrokken Verkooporderregel. Dit hoeft echter niet per definitie zo te zijn, immers, indien we Voorraad handmatig afboeken, danwel Omvormen, danwel handmatig Produktieorders opnemen welke voorraad nodig hebben, dan zal dit alsnog de VTV status van een Artikel kunnen wijzigen. Hiermee zal v.w.b. de reeds gekontroleerde VO regels geen rekening worden gehouden (doch dit zou eigenlijk wel horen!).

 
Om een ATP Check van een VO-regel te kunnen uitvoeren, mag alleen het resultaat van de vorige Behoefterun (reeds goedgekeurde VO regels) tezamen met de te kontroleren VO-regel worden uitgewerkt. Het zal derhalve niet mogelijk zijn om een ATP Check uit te voeren indien een ander werkstation aan het kontroleren is.

Zolang de ATP Check niet is uitgevoerd, zal de VO-regel niet worden meegenomen in de Behoefterun, en daarmee geen behoefte kreëren. En, ervanuitgaande dat de ATP Check impliceert dat we alleen dat mogen verkopen waarvan we kunnen garanderen dat we dit ook tijdig kunnen leveren, mag een Verkooporderregel waarvan de ATP Check nog niet is uitgevoerd dus ook niet worden geleverd; immers, dit zou betekenen dat zonder dat de orderregel formeel gekontroleerd is, we toch zouden toestaan dat ze voorraad wegkaapt die voor een andere order bedoeld was.

 
Omdat het uitvoeren van de ATP Check impliceert dat per Verkooporderregel een Behoefterun gedraaid moet worden, is het advies deze parameter niet zonder meer op Ja te zetten.

Vooralsnog is de ATP Check niet toegestaan indien het aktieve bedrijf een Intercompany Bedrijf betreft; immers, het verkopen van een produkt wat toebehoort aan een Intercompany Bedrijf zou vereisen dat er in dat andere Bedrijf een Behoefterun gedraaid zou moeten worden om de status te weten in het aktieve bedrijf. Dit vergt nog meer van deze funktionaliteit, en is (mede omdat ze niet nodig is voor de klant voor wie e.e.a. ontwikkeld is) bij deze achterwege gelaten. Indien gewenst zou dit als aanvullend maatwerk kunnen worden uitgewerkt.

 
Eigenlijk mogen we stellen dat er praktisch niets mag gebeuren met een Verkooporderregel waarvan is gesteld dat ze v.w.b. Available To Promise gekontroleerd moet worden, doch die kontrole nog niet is uitgevoerd. Hier hoort bijv. ook bij dat het niet zal zijn toegestaan om een Produktieorder te genereren vanuit een Verkooporderregel die nog niet ATP gekontroleerd is, danwel e.d. Verkooporderregel uit te besteden; deze orders zouden in behandeling kunnen worden genomen (en voorraad wegsnoepen) nog voordat gekontroleerd is of de bestelling van de klant per deze datum problemen oplevert.

 
Het uitvoeren van de ATP Check kontroleert of de gevraagde Leverdatum juist is, en past deze mogelijk aan naar een datum die wel mogelijk is. In theorie zou dit kunnen resulteren in een leverdag die de klant niet gunstig uitkomt, waarna deze datum alsnog weer gewijzigd moet worden. Vooralsnog is het zo dat de Leverdatum ongestraft naar achteren geschoven mag worden, zonder dat er opnieuw een ATP check hoeft te worden uitgevoerd (later leveren mag altijd, hooguit hebben wij het produkt dan wat langer op voorraad liggen); wordt de Leverdatum naar voren geschoven, dan zal altijd opnieuw moeten worden gekontroleerd of dat haalbaar is.

Let op: Er wordt vooralsnog geen rekening gehouden met Houdbaarheid. Is Houdbaarheid aan de orde, dan zouden we moeten stellen dat ook een verschuiving naar een later moment problemen op kan leveren, immers de voorraad die nu aanwezig is, hoeft op dat latere moment niet meer houdbaar te zijn.

 
Als een ATP Check wordt uitgevoerd in een Verkooporder waarbij de indikator "Deelleveren Toegestaan J/N" op Nee staat, dan zal de Leverdatum van die Verkooporder (en Verkooporderregels) worden aangepast naar de Leverdatum van het produkt welke het meest kritisch is; "de verste Leverdatum geldt dan voor de hele order".

 
 LET OP: Bij het wijzigen van de Leverdatum a.g.v. de ATP check worden enkel de Leverdata velden gewijzigd. Strikt genomen zou er met veel meer zaken rekening gehouden moeten worden, welke achterwege zijn gelaten omdat ze bij de klant voor wie e.e.a. ontwikkeld is niet van toepassing zijn. Middels aanvullend maatwerk kan voor degene die deze aanpassingen wel wenst, e.e.a. alsnog worden ontwikkeld.

Hierbij doelen we op bijv. het feit dat Verkoopprijzen afhankelijk van de Leverdatum kunnen worden gedefinieerd, en dat het eerder-/ later leveren feitelijk een andere Verkoopprijs kan impliceren. Zo ook kunnen DKK Tarieven afhankelijk zijn van de Leverdatum, kunnen we te maken hebben met opname in Routeplanning, en nog een aantal zaken.  
 
 
FunktieOmschrijvingDtm.Vl.WyzDtm.L.Wyz
LOBHOBMS    Omschrijving (nog) niet bekend    15-05-2007    20-08-2007
LOLLDR      Direkt Leveren    06-07-2007    03-09-2007
LOLLTVDL    Toevoegen aan Raaplijst    28-03-2007    03-09-2007
LOLLTVGL    Regel toevoegen aan Raaplijst    28-03-2007    03-09-2007
LOLLTVOR    Gehele Verkooporder toevoegen    26-10-2005    03-09-2007
LOLLTVZR    Levering zonder Raaplijst    27-11-2006    03-09-2007
LOOFT       Omschrijving (nog) niet bekend    14-08-2007    20-08-2007
LOPAICWY    Parameters Intercompany    17-07-2007    03-09-2007
LOPAVPWY    Wijzigen Verkooporder Parameters    21-08-2007    03-09-2007
LOPBGNCO    Omschrijving (nog) niet bekend      -  -        03-09-2007
LOPBGNF1    Omschrijving (nog) niet bekend      -  -        03-09-2007
LOPBIVGN    Genereren Produktiebehoefte    05-03-2007    03-09-2007
LOPIGN      Omschrijving (nog) niet bekend    26-06-2007    03-09-2007
LOVOBHGN    Omschrijving (nog) niet bekend      -  -        20-08-2007
LOVOGNPO    Genereren Produktieorders vanuit Verkooporder    16-02-2006    03-09-2007
LOVOGNUB    Genereren Uitbestedings-Order    01-12-2005    03-09-2007
LOVOOFKZ    Keuze overige funkties    23-07-2007    20-08-2007
LOVORA      Raadplegen Verkooporders    13-08-2007    05-09-2007
LOVRBHGN    Omschrijving (nog) niet bekend      -  -        03-09-2007
LOVRGNPO    Genereren Produktieorder    04-07-2007    03-09-2007
LOVRTV      Toevoegen Verkooporderregels    31-08-2007    03-09-2007
LOVRTVF1    Omschrijving (nog) niet bekend    03-07-2007    16-08-2007
LOVRTVVA    Omschrijving (nog) niet bekend    17-08-2007    03-09-2007
LOVRWG2     Omschrijving (nog) niet bekend    16-02-2007    20-08-2007
LOVRWYF1    Wijzigen Verkooporderregels.    07-02-2007    20-09-2007
Logged
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« Reply #1 on: December 20, 2007, 12:55:30 pm »

Vooralsnog is het zo dat de Leverdatum ongestraft naar achteren geschoven mag worden, zonder dat er opnieuw een ATP check hoeft te worden uitgevoerd (later leveren mag altijd, hooguit hebben wij het produkt dan wat langer op voorraad liggen)

Deze regel is inmiddels onderuit gehaald, omdat het later leveren van een bepaalde regel veelal ook zal impliceren dat daardoor de andere regels ook later geleverd moeten worden. Inmiddels is het al enige tijd zo dat zodra de Leverdatum gewijzigd wordt, ook de ATP check opnieuw moet worden uitgevoerd. Wel zal natuurlijk gelden dat de datum dan altijd akkoord moet zijn, ervanuitgaande dat als we iets volgende week op voorraad kunnen hebben, een leverdatum daarna altijd gehaald moet kunnen worden.
Logged

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

Posts: 5361


View Profile WWW
« Reply #2 on: December 20, 2007, 01:31:13 pm »

Een opmerking die ook maar even gemaakt moet worden is de volgende:

De ATP check wordt uitgevoerd per nieuw toegevoegde Verkooporderregel. Een Verkooporderregel draait pas mee in de Behoefterun als de ATP Check van die regel is uitgevoerd (en akkoord bevonden). Feitelijk is het beoogde doel van deze methode dat iedere verandering van resultaat in de Behoefterun, het gevolg moet zijn van de nieuw erbij betrokken Verkooporderregel, immers regel voor regel wordt bij de ATP berekening erbij betrokken.

Echter...

Naast Verkooporderregels zijn er nog veel meer systeemdelen van waaruit een behoefte kan ontstaan, en waar géén ATP check wordt uitgevoerd. Zo hebben we bijvoorbeeld ook Produktieorders, Omvormorders, Werkorders, Verplaatsorders die een behoefte aan materiaal kunnen triggeren, c.q. ervoor kunnen zorgen dat de voorraad die een eerdere ATP kontrole gebruikte om de hoeveelheid voor een order te dekken, ineens wordt weggekaapt. Uitgangspunt hierbij was dat dit door een produktiechef zelf zal worden uitgevoerd, en die dient te weten wat wel/niet kan.
Merk op dat niets hem tegenhoudt, en dat als bijv. iemand een Produktieorder toevoegt waarvan de benodigde grondstoffen niet tijdig aanwezig zullen zijn, een iedere volgende ATP check nimmer zal kunnen uitkomen op een geldige leverdatum. Staat een planningsperiode ingesteld op 42 dagen, dan zal de Leverdatum 6 weken worden opgeschoven en alsnog gekonstateerd worden dat we te laat zijn met bestellen. Wellicht nog erger is dat als de foutsituatie is opgelost, de leverdatum van diverse orderregels dan al 6 weken is opgeschoven, en de oorspronkelijk gevraagde datum misschien wel niet meer bekend is (afhankelijk van op welk moment de ATP check wordt uitgevoerd; direkt na invoering van de order, of bijv. batchgewijs aan het einde van de ochtend).

Mer ook op dat bijv. het afboeken van voorraad (derving, kapot gevallen, etc.) ervoor kan zorgen dat leverdata die eerst goedgekeurd waren alsnog ineens niet meer gehaald kunnen worden.

De Behoefterun die vanuit de Verkooporderregel gedraaid wordt, betreft dan ook bewust een Behoefterun voor enkel het Artikel uit de betreffende Verkooporderregel (plus respekteren van de Scope). Dit, opdat produkt A niet wordt afgekeurd omdat er bij produkt B een foutsituatie is opgetreden. Pas als B ook in A gebruikt wordt, zal die fout doorwerken in de leverdatum van A.
Logged

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

Posts: 4073


Just testing


View Profile WWW
« Reply #3 on: December 21, 2007, 09:13:20 am »

Voor diegenen die zich afvragen wat nu al de ophef is over een Available To Promise Check, het betreft hier een volledige multi level ATP check, en dus niet alleen voor het verkochte produkt en het niveau van de grondstoffen/halffrabrikaten daar direkt onder. Het betreft dus *alles*.

Wij hebben zelf gesteld dat het werken met de ATP check - welke dus tevens ervoor zorgt dat produkties e.d. worden ingeplanned - eigenlijk gepaard dient te gaan met een gedegen grafische planning. Deze zal dan ook in de komende maanden beschikbaar komen in een eerste versie.
Logged

Heart-Profit company ID : HA
moderator all boards
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.053 seconds with 20 queries.