Let op: A.g.v. een vernieuwde werkwijze van Emballage voor Emballageset-Id's vervangt dit topic sinds eind november 2019 de vorige versie, zie nog te vinden is in
http://ha1.heartprofit.nl/profit/index.php?topic=29408.0.
Let op: ook deze tweede versie is al enigzins achterhaald v.w.b. de wijze waarop de Klientgerichte Emballageset op Emballage-Id wordt geregistreerd. Het gehele topic is hier nog niet op aangepast, maar, de eerste reply bevat nu een aantal wijzigingen op de werkwijze.Een Emballageset is een definitie van de Emballage onderdelen die moeten worden afgeboekt zodra we iets gaan afvullen in een bepaalde Verschijningsvorm.
Tot vandaag hadden bestonden er twee soorten Emballagesets:
1. de standaard Emballageset, waarmee op Verschijningsvormniveau kon worden aangegeven dat een Verschijningsvorm "Blik 20 liter" bestaat uit 1 leeg blik en 1 deksel.
2. de Kliëntgerichte Emballageset, waarmee kon worden aangegeven dat als een bepaalde Kliënt (lees: Debiteur) een produkt besteld in een "Blik 20 liter", dit blik met een rood deksel moet worden geleverd.
In plaats van methode #2 is er nu een nieuwe methode toegevoegd, die, indien ze gebruikt wordt, methode #2
vervangt!
Voor het gemak noemen we deze methoden dan nu even 2a en 2b.
2a. Betreft de de oude Kliëntgerichte Emballage op Debiteur + Verschijningsvorm.
2b. Betreft een nieuw geïntroduceerde methode op Emballageset-Identifikatie, waarbij een speciaal Emballagese-Id Kenmerk afdwingt hoe de produkten voor een bepaalde klant moeten worden afgevuld. Methode 2b. kan alleen worden gebruikt i.c.m. de module
Profit-Kenmerk, en wordt aktief zodra we een Kenmerk 'Emballageset-Id" definiëren.
Vanwaar deze nieuwe methode?
De nieuwe methode is een verregaande uitbreiding op de Kliëntgerichte Emballage die we al onderkenden in Profit, maar, deze Kliëntgerichte Emballage tillen we nu naar een volgend level: in de nieuwe situatie kunnen we er voorraad van gaan aanhouden van klantspecifieke Emballage én gaan we rekening houden met de wensen van de klanten in onze Intercompany Bedrijven...
Situatieschets:In de voor ogende liggende situatie hebben we te maken met een bedrijf waarvan het moederbedrijf in Nederland gevestigd is en er ook vestigingen zijn in (o.a.) Italië en Turkije. In de oude situatie kon Nederland Emballagesets aanmaken waarmee ze per Verschijningsvorm kon vastleggen uit welk (leeg) blik deze bestond, en welk deksel erbij hoorde. Daarnaast kon via Kliëntgerichte Emballage worden vastgelegd dat een bepaalde klant afwijkende Emballage heeft; bijvoorbeeld het standaard blik, maar met een
rood deksel.
Hoewel we in Profit jaren lang op deze manier met Kliëntgerichte Emballage zijn omgegaan, werkte het eigenlijk alleen bij de gratie dat we ook 1:1 met een Verkooporderregel een Produktieorder zouden maken. Omdat (dan) de Produktieorder 'wist' voor welke order dit geproduceerd werd, was óók bekend voor welke Debiteur er werd geproduceerd, en zodoende kon bij het Afvullen rekening worden gehouden met de Emballage die voor dié specifieke Debiteur bestemd was. Tsja... tót de order gereedgemeld werd en de Output op Voorraad terecht kwam... dan was ineens de verbinding met de Debiteur verbroken. Voorraaditems ontstaan weliswaar op basis van Kliëntspecifieke wensen, maar, ze worden er niet naar uniek gemaakt. Een van de oplossingen die kon worden toegepast was dat als we een Produktieorder die 1:1 voor een Verkooporder werd geproduceerd gingen gereedmelden, we de opgeboekte Output direkt reserveerden op een Raaplijst voor die betreffende Verkooporder. Het opgeboekte Voorraaditem werd dan gereserveerd (omdat het op een Raaplijst stond) en kon dan aan niemand anders meer worden geleverd.
"Voorraad aanhouden" voor zo'n klant werd niet ondersteund, immers, op voorraad konden we niet zien voor welke Debiteur iets was geproduceerd.
Een volgend probleem ontstond als we hier ook Intercompany bij gingen betrekken. Het Italiaanse Bedrijf verkocht een produkt in een blik van 20 liter aan een Italiaanse klant en deze Italiaanse klant heeft specifieke wensen omtrent de te gebruiken Emballage; hij wil een standaard blik hebben met een rood deksel. Als Italië zelf zou produceren, zou ze dit kunnen oplossen met de huidige Kliëntgerichte Emballageset, maar... Italië produceert zelf niet, ze koopt in bij Nederland, en levert daarna uit voorraad. De Nederlandse vestiging moet nu gaan produceren en zal rekening moeten gaan houden met de klantspecifieke wensen van de klant uit Italië. Maar... Nederland weet zelf helemaal niets van de Italiaanse klant af (immers, de Debiteur van haar Verkooporder is het Italiaanse zusterbedrijf en niet de klant van dat bedrijf).
Deze problematiek gaan we nu oplossen door de introduktie van een
Emballageset-Id. Dit betreft eigenlijk niet veel meer dan een Identifikatie waaraan we Emballage gaan koppelen. Een Identifikatie die we uniek maken per Bedrijf, en die bij iedere bestelling dient te worden doorgegeven. Als Italië iets aan haar klant verkoopt onder een zo'n Emballageset-Id, dan zal ze dat Emballageset-Id ook aan Nederland moeten doorgeven als ze dit produkt inkoopt bij Nederland. Daarna weet Nederland (zonder ook maar iets van de klant van het Italiaanse bedrijf af te hoeven weten) welke Emballageset-onderdelen gewenst zijn.
Het doorgeven van dit Emballageset-Id gaan we doen middels een
Kenmerk. Middels Module
Profit-Kenmerk kunnen we een Artikel van maximaal 3 Kenmerken voorzien, waarmee we het produkt, alle orders voor dit produkt en tevens de voorraad uniek kunnen maken naar een Kenmerkwaarde, zónder daarvoor een nieuw Artikel te hoeven op te nemen. Zo kunnen we straks voorraad hebben van ons Artikel in een 20 liter blik met Emballageset-id "B12345", maar kunnen we tegelijkertijd ook voorraad hebben van dezelfde Artikel-/Verschijning met Emballageset-Id "B67890".
Hoe aktiveren we deze nieuwe methode?
Om straks onze Artikelen uit te kunnen rusten met een Kenmerk welke representatief is voor de "Emballageset-Id", zullen we eerst (éénmalig) een Kenmerkletter "E" moeten vastleggen waarmee we het Emballageset-Id gaan registreren. Hiertoe gaan we naar Toevoegen- of Wijzigen Artikelen. Op het Tabblad "Kenmerken" vinden we een toets F5 welke ons leidt naar "Raadplegen Kenmerk-Definities". Hier kunnen we met F4 onze letter "E" toevoegen. De Raadpleegfunktie toont daarna deze Kenmerkletter "E":
Als deze Kenmerkletter 'E' formeel is vastgelegd, kunnen we feitelijk al Kenmerken opnemen bij ons Artikel, maar, dat doen we later... Eerst gaan we naar de Standaard Bedrijfsparameters (Hoofdmenu, F5, F5, B) om daar aan te geven dat Kenmerkletter "E" het Kenmerk is welke we gebruiken om de Emballageset-Id mee te registreren:
Let op: Als deze parameter is ingesteld gaat Profit er vanuit dat de Kliëntgerichte Emballage via een Emballageset-Id werkt.
In ons voorbeeld hebben we te maken met 3 Bedrijven; één in Nederland, één in Italië en één in Turkije. Het éénmalig inrichten van deze Emballageset-Id dient in ieder van die Bedrijven te gebeuren!
Emballageset-Id's uniek per Bedrijf
Zoals aangegeven hebben we te maken met 3 bedrijven: een nederland bedrijf, een italiaans bedrijf en een turks bedrijf. Alle 3 hebben hun eigen klanten, en alle 3 zullen ze ook hun eigen (desnoods oplopende) Emballageset-Id's willen kunnen gebruiken. Om te voorkomen dat zowel Italië als ook Turkije op enig moment allebei een nummer "12345" hebben, hebben we besloten om de Emballageset-id's uniek te maken met een 1 positie die we per Bedrijf kunnen vastleggen.
Welke letter we als 1e waarde per bedrijf gebruiken mag u zelf bepalen. Dit mag gewoon "A", "B", "C" zijn, maar u zou ook de 1e positie van uw Bedrijfs_id kunnen invullen, of bijv. de 1e letter van het Land waarin het bedrijf gevestigd is. Er geldt één regel: de code moet uniek zijn over alle bedrijven heen!
In ons voorbeeld hanteren we :
C = Nederland
B = Italië
T = Turkije.
In Italië hebben we nu een klant welke met Kliëntgerichte Emballage werkt. Net zoals voorheen kunnen we via Hoofdmenu-3-5-4-1 naar Kliëntgerichte Emballage gaan, maar, in plaats van daar Emballage te koppelen aan een kombinatie van Debiteur + Verschijningsvorm, nemen we nu een Emballageset-Identifikatie op. Wat er precies in deze Identifikatie komt te staan doet er op zich niet veel toe, mits de waarde maar begint met de 1e Positie die voor dat bedrijf is afgedwongen (B in dit geval, immers "B = Italië"). Voor dit voorbeeld hanteren we een kode "12345", welke, met de "B" van het Italiaanse Bedrijf ervoor dus "
B12345" wordt.
Als we bij de Kliëntgerichte Emballageset een Emballageset-Id opnemen welke nog niet eerder is gebruikt, dan zal er (onder water) ook formeel een Emballageset-Id worden gegenereerd. De bij de Kliëntgerichte Emballage ingevulde omschrijving is dan generiek voor de Omschrijving van die Emballageset-Id.
Nb: Eventueel kunnen we op een later moment nog besluiten dat we deze Emballageset-Id's automatisch gaan genereren; vooralsnog gebeurt dat niet en kan de Gebruiker daar zijn/haar eigen algoritme voor verzinnen.
Nb2: Voor de duidelijkheid kunnen we hierbij ook een omschrijving invullen; deze is generiek voor de Emballageset-Id en staat ons toe om aan te geven wat deze Emballagset nu precies zo anders maakt dan de standaard versie.
Nb3: In de vorige versie gold dat deze Emballageset-Id
uniek moest zijn per Debiteur; bij iedere Debiteur (lees: schip) waren er wel andere Emballageswensen en als er al twee Debiteuren waren met gelijke Emballagewensen, dan was dat toeval. In de versie vanaf 28 november 2019 geldt dat deze Emballageset-Id
niet meer uniek hoeft te zijn. Dit, opdat we in staat zijn om meerdere Debiteuren met dezelfde Emballageset-Id te kunnen laten werken. Zo geldt bijv. in Italië dat Overheidsinstellingen hun produkt altijd geleverd moeten krijgen in een blik met een blauw deksel. We zijn dan in staat om meerdere Debiteuren (Overheidsinstellingen) naar dezelfde Emballageset-Id te laten verwijzen.
Italië definieert zelf welke Emballage hierbij hoort
Stel dat Italië straks een produkt gaat verkopen en via een Kenmerk aangeeft dat dit volgens Emballageset-Id "B12345" dient te gebeuren, dan zal ze, als ze dit produkt bij Nederland gaat inkopen, niet alleen deze "B12345" moeten doorgeven, maar, ze zal ook moeten (kunnen) aangeven welke Emballage er bedoeld wordt als deze Emballageset-Id wordt gebruikt. De registratie van deze onderdelen is in Italië puur registratief, immers, Italië produceert zelf niets en hoeft (dus) ook niet af te vullen.
Via Hoofdmenu-3-5-4-2 kunnen de verschillende Emballageset-Id's worden geraadpleegd. Toets
Shift+F5 leidt dan tot een overzicht van waaruit de onderdelen van deze Emballageset-Id kunnen worden geraadpleegd (en gemuteerd). Deze funktie kan ook via
Shift+F5 worden benaderd vanuit Hoofdmenu-3-5-4-1, immers, ook daar staat bij één of meerdere Debiteuren de code "B12345" ingevuld en zal Shift+F5 leiden tot de Emballage onderdelen die aan B12345 hangen.
Voor de duidelijkheid: Italië koopt in bij Nederland, en Nederland (de Leverancier) moet e.e.a. afvullen conform de door Italië aangegeven specifikaties. De enige reden dat Italië Emballageset onderdelen opneemt, is opdat ze weet welke gegevens ze aan Nederland moet doorspelen zodra ze besteld met kenmerk "B12345".
Aangezien het binnen dit ontwerp enkel gaat om het afboeken van
eenmalige Emballage, zijn een tweetal rubrieken die we normaliter aantreffen bij de opname van een Emballageset-onderdeel disabled. Het betreft de velden 'Meeleveren op Verkooporder J/N' en 'Komt Retour J/N'. Ook voor deze twee velden geldt dat we in de toekomst best kunnen besluiten dat deze alsnog nodig zijn, vooralsnog zullen we het zonder deze twee rubrieken moeten stellen, omdat we daarmee te ver afdwalen van het oorspronkelijke doel. Bedenk dat we ook een categorie Intercompany Verkooporders hebben welke niet over de voorraad loopt, en het feit dat Nederland een extra 'blikopener' zou moeten meeleveren op de Verkooporder, feitelijk impliceert dat die produkten ook op een Intercompany Inkooporder terecht moeten komen willen we dit in Italië kunnen ontvangen (om vervolgens nog maar te zwijgen over een uitbesteding die direkt geleverd moet worden, waarbij die voorraad slechts een fraktie van een seconde op voorraad terecht komt en daarna direkt doorgeleverd moet worden op de Intercompany Verkooporder). Dit gaan we nu niet verder uitwerken, zoals gezegd, we dwalen af... Vooralsnog derhalve hard geblokkeerd.
De onderdelen die Italië opneemt in de Emballageset zullen ook in Nederland als zodanig bekend moeten zijn, immers, het is Nederland die haar produkten moet afvullen in deze Emballage-onderdelen. Ofwel, als Italië vindt dat een klant zijn blik met een rood deksel geleverd moet krijgen, dan zal Nederland, die uiteindelijk dient af te vullen conform de wensen van de Italiaanse Klant, moeten beschikken over een Artikelnummer welke representatief is voor zo'n rood deksel. Nederland zal er ook voor moeten zorgen dat deze Emballage-onderdelen tijdig worden ingekocht.
Aangezien ieder Emballageset-onderdeel waaraan Italië refereert (dus) ook in Nederland bekend moet zijn, zou het wenselijk zijn dat Italië en Nederland automatisch konden beschikken over dezelfde Emballage-Artikelen. Voegen we een nieuw blik in Italië toe, dan zou het handig zijn als we die ook automatisch in Nederland hebben. Technisch is daar op zich best wel iets voor te verzinnen, maar vooralsnog valt ook dit buiten het ontwerp; het is een ander onderwerp welke niet specifiek benodigd is om het geheel te kunnen laten werken. Laat de praktijk dit maar even uitwijzen; het kan altijd nog. Vooralsnog is dus het uitgangspunt dat de Emballage Artikelen gewoon "
dubbel" worden ingericht; 1x in Nederland en 1x in Italië.
Nb: Merk hierbij ook op dat deze registratie, die nu dubbel lijkt, misschien helemaal zo slecht nog niet is; immers, we kunnen de Emballageset-onderdelen nu in Italië op een totaal andere wijze inrichten als dat we dat voor Nederland doen. Bedenk hierbij ook dat als Nederland 'world-wide' produceert, en Italië "slechts" over Italië gaat, Nederland dus véél meer Emballage-Artikelen zal hebben dan Italië. Met dat we besluiten dat deze Emballage Artikelen
niet worden doorgekopiëerd, kunnen we het nu zo inrichten dat een Emballage Artikel in het ene bedrijf E-000001 heet, terwijl ze in het andere bedrijf Y0039 wordt genoemd. Immers, als Nederland maar weet dat er een Y0039 moet worden afgeboekt wordt er feitelijk enkel een 20 liter blik met een code "B12345" aan Italië geleverd, en dat is voor iedereen "voldoende".
Blik met blauw deksel voor Italiaanse Overheidsinstellingen
Alvorens naar de inrichting van het Artikel over te gaan, nog even een extra voorbeeld naar aanleiding van de Italiaanse Overheidsinstellingen, waarbij meerdere Debiteuren naar dezelfde Emballageset-Id moeten kunnen verwijzen, omdat ze bijv. altijd een produkt geleverd moeten krijgen met een blauw deksel.
Zoals aangegeven geldt dat als we via Hoofdmenu-3-5-4-1 een Emballageset vastleggen en daar een Emballageset-Id invullen, dit generiek is voor de opname van een Emballageset-Id én het koppelen van dat Emballageset-Id aan de Debiteur. Het is ook mogelijk om éérst via Hoofdmenu-3-5-4-2 een Emballageset-Id op te nemen, en deze dan later te koppelen aan de Debiteuren voor wie deze van toepassing is. Zo maken we hieronder een definitie voor een blik van 20 liter voor de Italiaanse Overheidsinstellingen:
Koppelen we daar een blik met een blauw deksel aan:
en gaan dan via Hoofdmenu-3-5-4-1 deze Emballageset-Id opnemen bij meerdere Debiteuren:
Nb: Merk op dat omdat er nu wordt gerefereerd aan een reeds bestaande Emballageset-Id, de omschrijving wordt overgenomen van dat Id.
Op deze manier kunnen we nu meerdere Debiteuren naar dezelfde Emballageset-Id laten verwijzen:
Inrichting van het Artikel
Als Italië straks iets gaat gaat bestellen bij Nederland, zal ze de Identifikatie van de Emballageset moeten doorgeven. Feitelijk dient dus onze 'behoefte' uniek te worden gemaakt naar de Emballageset-Id, immers, een blik van 20 liter met een Id "B12345" is een ander blik dan een met een Identifikatie "B67890". Het doorgeven van het Emballageset-Id gaan we doen met behulp van een Kenmerk; het Kenmerk "E" (Emballageset-Id) waarmee dit topic begon.
Als we een nieuw Artikelnummer zouden toevoegen, dan weten we al dat we dat in 3 administraties moeten doen (Nederland, Italië en Turkije). Maar, nu gaan we dit Kenmerk implementeren in een situatie waar niet eerder met de module
Profit-Kenmerk werd gewerkt. Een implementatie waarbij we al beschikken over meer dan 10.000 Artikelnummers die we nu verder uniek willen kunnen maken naar een Emballageset-Id, en dan staan die Artikelen óók nog eens in twee andere administraties...
Bij een bestaand Artikel mogen we in principe geen Kenmerkgegevens wijzigen. Het is dus niet de bedoeling dat een produkt die we eerst op lengte x breedte x dikte hebben registreerd, een volgende keer gaan wijzigen naar emballageset x kleur x etiket. Zodra een Artikel van Kenmerken wordt voorzien, zal dit Artikel overal in Profit geregistreerd worden mét die Kenmerken. Een Artikel ligt dus bijv. op voorbeeld met bepaalde lengte maten of in bepaalde kleuren (of zoals wij straks willen: met een bepaalde Emballageset-Id). Dat houdt in dat als we achteraf een bestaand Artikel gaan uitbreiden met een Kenmerk, dit Kenmerk op talloze plekken in de database
moet worden aangebracht, omdat de boel anders inconsistent is. Als een Artikel verkocht wordt, zal ze worden verkocht met een bepaalde kombinatie van Kenmerkwaarden. Daarna mag alleen dié kombinatie met Kenmerkwaarden aan die klant geleverd worden (immers, het produkt welke we hebben afgevuld in een 20 liter blik met het rode deksel, en welke we op voorraad uniek maken d.m.v. een Kenmerk (E=Emballageset-Id) B12345, gaan we niet leveren op een order van een klant die (E)B67890 besteld heeft. Op eenzelfde manier geldt dat als een produkt nu géén Kenmerken heeft, het Kenmerk feitelijk op "XX" staat (Nb: de 1e positie van deze twee letters gebruiken we praktisch nooit, en derhalve vermelden we vaak enkel de 2e letter, dus (X) zou feitelijk XX betreffen en (E) impiceert XE). Zouden we enkel een Kenmerkletter toevoegen en verder niets doen, dan produceren we op onze nieuwe order het produkt mét Kenmerk (E), maar, we kunnen nog allerlei behoeftes hebben die op (X) staan, en die we nooit meer geproduceerd krijgen omdat het Artikel nu ineens voorzien is van een Kenmerk.
Met andere woorden, áls we een Artikel uitbreiden met een Kenmerk (E), dan zal de hele database moeten worden aangepast om de data van dit Artikel eveneens uit te breiden met een Kenmerk (E). Binnen Profit bestaat er een zgn.
Kenmerkrun welke een gewijzigd Kenmerk kan doorkopiëren naar de rest van de Database. Maar, let op: deze run is hooguit ontwikkeld om voor de klanten van wie we weten dat ze deze run gebruiken, de meest gangbare tabellen aan te passen. Sterker nog, er worden meer tabellen niet aangepast dan wel, en zelfs van tabellen (zoals orders) die wél worden aangepast, worden alleen de 'openstaande' orders gewijzigd.
Zie verder topic:
http://ha1.heartprofit.nl/profit/index.php?topic=29396.0 voor een uitgebreide uitleg, de mitsen en maren, en verdere regels...
Als we hieronder verder gaan, gaan wij er vanuit dat u dat topic over de Kenmerkrun heeft gelezen en begrijpt dat u goed moet testen of die Kenmerkrun ook in uw situaties alle logistieke processen ondersteunt.
We vervolgen het voorbeeld bij een bestaand Artikelnummer 426EE0000. Als we een Verwacht Voorraad Verloop van dit Artikel opvragen, dan zien we in de kolom 'Kenmerken' overal de waarde 'XXXXXX' staan: Deze kolom wordt gevuld met een zgn.
Samengesteld Kenmerk welke een optelling is van de 3 afzonderlijke Kenmerken die een Artikel kan hebben. Als een Kenmerk niet gebruikt wordt, is haar waarde "XX". Hebben we 3 Kenmerken die niet gebruikt worden, dan krijgen we "XXXXXX".
We gaan dit Artikel wijzigen, en vullen op Tabblad 8 het 1e Waardegebonden Kenmerk met de letter "E". Er volgt direkt een foutmelding:
Deze blokkade heeft alles te maken met de waarschuwingen zoals opgenomen in het eerder genoemde topic over de Kenmerkrun. Het laatste wat we willen is dat een willekeurige Gebruiker zomaar Kenmerken gaat wijzigen en de boel in de soep laat lopen. Ofwel, dit is alleen voor Gebruikers weggelegd die als 'Systeem-Manager' zijn ingericht. Loggen we in met een Userid die voldoende rechten heeft, dan krijgen we in plaats van een foutmelding een tweetal waarschuwingen die ons er op attenderen dat wat we aan het doen zijn geen gebruikelijke aktie betreft.
Het Niet-waarde-gebonden Kenmerk laten we op 'X' staan.
Het Waarde-gebonden Kenmerk zetten we op 'E' van Emballagset-Id.
Rubriek 'Waarde' laten we leeg. Hiermee zouden we een defaultwaarde kunnen toekennen welke voor dit Artikel geldt, maar, aangezien we die niet op voorhand kunnen bepalen, laten we dit veld leeg.
Expliciete Kenmerkaanpassing dient op Ja te staan (dat gebeurt standaard).
Impliciete Kenmerkaanpassing dient op Nee te staan (eveneens de default werkwijze).
De Behoefteregistratiewijze (in het 2e blok) laten we op 'V' staan (Voorraadeenheden).
Nb: Via de Behoefteregistratiewijze (V/1/2/3) kunnen we regelen dat Profit bij behoeftes moet gaan 'vragen' om de waarde van Kenmerk1, Kenmerk2, Kenmerk3 danwel een kombinatie ervan. We laten haar hierboven op 'V' staan, wat inhoudt dat Profit gewoon blijft vragen om een aantal Voorraadeenheden; de waarde van het Kenmerk zal op een andere wijze worden bepaald (daarover straks meer). Zouden we bij het Artikel een '1' invullen in de Behoefteregistratiewijze, dan zal Profit per Verkooporderregel gaan vragen met welke Kenmerkwaarde (Emballageset-Id) we een produkt aan iemand willen we verkopen. De Gebruiker zou dan in staat zijn om een produkt welke voor een andere klant met andere Emballageset specifikaties is ontwikkeld, toch te kunnen leveren aan een klant waarvoor het niet bedoeld is. Op zich zit in zoiets natuurlijk ook weer funktionaliteit, maar, uitgangspunt is dat dat nu niet aan de orde is. De Behoefteregistratiewijze laten we dus op 'V' staan!
Als we de wijziging met F1 verwerken, volgt de volgende vraag:
Als de defaultwaarde zoals opgenomen bij het Artikel óók geldt voor de Artikel-/Verschijningen, kunnen we deze vraag met Ja beantwoorden. Beantwoorden we de vraag met 'Nee' dan zal hooguit de Kenmerkletter worden doorgekopiëerd naar de Artikel-/Verschijningen, met feitelijk voor de situatie 'Kenmerkletter opnemen bij een bestaand Artikel, en defaultwaarde = <leeg>' eenzelfde effekt of we de vraag nu met Ja of Nee beantwoorden
Keren we terug naar Raadplegen Artikelen, dan zien we dat het Grid toont dat het Artikel nu een Kenmerk (E) bevat:
Maar... dit gebeurt nu enkel en alleen in de (Nederlandse) administratie waarin we deze Kenmerkletter bij het Artikel opnamen; in de andere bedrijven staat nog steeds geen Kenmerk geregistreerd.
Ook geldt dat als we opnieuw het VVV opvragen, we nog steeds bij alle Inkooporders, Verkooporders, Produktieorders, Voorraad etc. de Kenmerken op 'XXXXXX' zullen zien staan. Dit is het moment waarop de
Kenmerkrun om de hoek komt kijken!
Met Kenmerkrun doorkopiëren van de Kenmerken naar de (Intercompany) Database
De Kenmerkrun vinden we bij Hoofdmenu-1-1-1-2-5. Ook deze funktionaliteit is niet zo maar voor iedereen weggelegd, ze kan enkel worden uitgevoerd door Gebruikers die
expliciete Autorisatie hebben voor de Funktie
LOVAKGAP.
Zijn we wél geautoriseerd voor de Kenmerkrun, dan komen we in de volgende Funktie terecht:
In de modus waarin dit scherm standaard wordt aangeroepen, doet ze feitelijk nog niets, omdat rubriek 'Wijzigingen Uitvoeren J/N' op 'Nee' staat. Zouden we nu op F1 drukken, kan wordt er in de TROEP Directory een logfile opgebouwd die ons op voorhand (nog zonder daadwerkelijk iets te wijzigen) zal vertellen wat er precies waar gewijzigd wordt.
De rubriek 'Exclusief openen J/N' kan met 'Ja' worden gevuld als u weet dat u de enige persoon bent die in het systeem zit. Dit is dus alleen weggelegd voor momenten waarop alle mederwerkers uit Profit zijn; weggelegd voor een rustige avond, of wellicht een weekend. Als de rubriek met 'Ja' wordt gevuld, zullen de aan te passen tabellen voor 'alleengebruik' worden geopend, waardoor het aanpassen van de Database veel sneller zal verlopen.
Dan volgt er nog een hele serie met J/N rubrieken waarmee we kunnen aangeven in welke Tabellen we dit Kenmerk opgenomen willen hebben. Het op Ja zetten van deze rubrieken is
alléén aan de orde als we bij een Artikel welke al met Kenmerken werkt, een default Kenmerkwaarde op Artikelniveau wijzigen, en vinden dat dit door moet worden gekopiëerd naar de hele Database. Dit zouden we eigenlijk nooit mogen doen! (zie wederop topic
Kenmerkrun).
We vullen de kleinst nodige selektie in kwa Artikelnummer (in dit geval: gewoon 1 Artikel, nl. het Artikel welke we zojuist gewijzigd hebben), zetten rubriek 'Wijzigingen Uitvoeren J/N' op Ja (wat we ook default op "Ja" kunnen zetten m.b.t. module
Profit-DynScreen) en we starten de Kenmerkrun op middels F1.
Na uitvoering van de Kenmerkrun is het Kenmerk ook opgenomen in bij de gelijknamige Artikelen (en Artikel-/Verschijningen) in de Intercompany Bedrijven; tevens is het Kenmerk nu opgenomen in alle tabellen die ondersteund worden door de Kenmerkrun. Zouden we nu opnieuw het VVV van dit Artikel opvragen, dan zien we dat bij alle regels het Kenmerk 'XXXXXX' is gewijzigd naar 'XEXXXX'.
Vanaf dit punt zouden we in staat moeten zijn om gewoon ons oude dagelijkse werk op te kunnen pakken, zoals we gewend waren vóórdat dit Artikel Kenmerken had. Het Artikel is uitgerust met een Kenmerk, de (openstaande Verkooporderregels) zijn uitgebreid met het Kenmerk, de Voorraad is dat ook, ofwel, wat op voorraad stond, kunnen we gewoon gebruiken om de (aangepaste) orders mee uit te leveren. Funktioneel is er dus nog eigenlijk niets gewijzigd op dit moment, hooguit hebben we het Artikel nu van een Kenmerk voorzien.
Italië bestelt bij Nederland, en dient Emballageset Id door te geven
Langzaam maar zeker komen we toe aan waar het daadwerkelijk om draait. Als Italië bij Nederland gaat inkopen, zal ze bij haar bestelling de Emballageset-Identifikatie moeten gaan doorgeven. Alle Uitgaande- en Inkomende Behoeftes in Italië (maar ook in de andere bedrijven) zullen nu uniek worden gemaakt naar het Kenmerk (E). De eerste behoefte ontstaat bij het plaatsen van een Verkooporder in bedrijf Italië.
Eerder in dit topic hebben we bij een Belgische Debiteur "ACRUX" een Kliëntgerichte Emballageset opgenomen voor de Verschijningsvorm "20.0LMR". Aan dit type blik hebben we voor dié specifieke Debiteur het Emballageset-Id "B12345" toegekend. "Acrux" wil immers zijn 20 liter blikken hebben geleverd in een 20 liter blik met een rood deksel.
Als we nu in Italië een Verkooporderregel toevoegen aan deze Italiaanse Debiteur (ACRUX) én we verkopen een Artikel (426EE0000) welke is uitgerust met een Kenmerk (E) én we verkopen dit in een Verschijningsvorm (20.0LMR) waaraan voor deze Debiteur een Kliëntgerichte Emballagset is opgenomen, dan herkent Profit dat er voor deze kombinatie een Kliëntgerichte Emballageset bestaat met Identifikatie "B12345" (we hebben immers in een Bedrijfsparameter aangegeven dat Kenmerk (E) die Emballageset-Id impliceert). Profit bepaalt de Emballageset-Id en vult deze code automatisch in op de Verkooporderregel als Kenmerkwaarde van het Kenmerk (E).
Nb:
Nog even terugkomend op de Behoefteregistratiewijze... Zouden we daar een '1' invullen:
en dan een Verkooporderregel toevoegen, dan 'vraagt' Profit om de Kenmerkwaarde van het 1e Kenmerk:
Met andere woorden, in plaats van een Label, is het Kenmerk ineens een Textbox control geworden waarin we de waarde van de Emballageset-Id kunnen overschrijven. Dit kán voor sommige situaties dus best handig uitpakken, maar, vooralsnog is het uitgangspunt dat de Behoefteregistratiewijze op 'V' blijft staan, en dat we de Emballageset-Id's niet gaan wijzigen.
Het Kenmerk "(E)B12345" maakt de behoefte aan dit produkt nu verder uniek. Deze behoefte (geacht Kenmerkwaarde) ontstaat op de Verkooporder in Italië aan de Italiaanse Debiteur, maar als we gaan Inkopen, zal ze ook op de Inkooporder van Italië bij Nederland komen te staan en daaraan gekoppeld staat ze (dus) ook op de Intercompany gegenereerd Verkooporder van Nederland aan Italië. Nederland "weet" nu dat er een behoefte is aan Artikel "426EE0000" in een Verschijningsvorm "20.0LMR" en waarbij de Emballageset wensen van Identifikatie "B12345" van toepassing zijn. De Intercompany Verkooporder van Nederland aan Italië zal als Debiteur "het Italiaanse zusterbedrijf" hebben. Leveringen aan dit Italiaanse Bedrijf zouden in principe allen leveringen moeten betreffen van produkten waarvan de 1e letter van het (E) Kenmerk begint met de letter "B", immers, B was Italië.
Tenslotte besteden we de order in Italië. Italië koopt het produkt dan (geacht Kenmerk) in bij Nederland, en Nederland verkoopt (geacht Kenmerk) aan Italië.
De Emballageset van Italië in Nederland
In Nederland komt nu een bestelling binnen van ons zusterbedrijf "Italië" voor een produkt met Emballageset-id "B12345". Als Nederland nog niet weet wat Italië met "B12345" bedoeld (omdat het de eerste bestelling betreft met code "B12345") dan zal Italië bij haar bestelling bij Nederland moeten aangeven wat ze met "B12345" bedoelt. Italië weet welke onderdelen ze moet doorgeven, want ze heeft hier (zie eerder) zelf ook de mogelijkheid om vast te leggen uit welke Emballageset onderdelen "B12345" bestaat.
Nederland dient nu óók een Emballageset te definiëren, maar nu niet voor een Verschijningsvorm, maar voor een Emballageset-Id "B12345". Via een separate menu optie binnen Kliëntgerichte Emballage (Hoofdmenu-3-5-4-2), kunnen we nu Emballagesets Raadplegen op Emballageset-Id.
In die funktionaliteit voegen we een nieuwe Emballageset-Id "B12345" toe die we vanuit Italië hebben doorgekregen. De omschrijving van de Emballageset-Id wordt standaard gevuld met omschrijving van de Emballageset-Id zoals deze in het oorspronkelijke bedrijf (Italië) is gedefiniëerd; Nederland kan deze omschrijving desgewenst aanpassen.
Vervolgens kan Nederland vastleggen welke Emballage-onderdelen er moeten worden afgeboekt als het Italiaanse bedrijf code "B12345" doorgeeft. Onderstaand scherm demonstreert dan dat we er voor kunnen kiezen om deze Emballage-onderdelen niet hetzelfde Artikelnummer te laten hebben als in het Italiaanse bedrijf; dit mogen dus onze eigen Artikelnummers zijn. Vanzelfsprekend moeten de Artikelen inhoudelijk wel overeenkomen met wat Italië vraagt (immers, als wij een geel deksel gaan opnemen waar een rood deksel gevraagd is, dan zullen we het verkeerd doen).
Een Emballageset van een Debiteur in Nederland
Voor een Debiteur in Nederland werkt de Emballageset niet veel anders dan hierboven beschreven. Ook Nederland zal (zodra de nieuwe methode geaktiveerd is) haar Kliëntgerichte Emballage moeten registeren m.b.t. een Emballagset-Id welke via een Kenmerk behoeftig wordt, en op voorraad herkend kan worden. Met als uitgangspunt dat Nederland het bedrijf betreft waar geproduceerd wordt, is het onzin als we (zoals in Italië) éérst voor ons zelf een Emballageset zouden moeten registreren op Debiteur + Verschijningsvorm, om daarna alsnog dezelfde Emballage onder het Emballageset-Id te moeten vastleggen. Deze twee worden derhalve gekombineerd tot één handeling.
Gebruikmakend van de oude wijze van de Kliëntgerichte Emballageset, registreren we via Hoofdmenu-3-5-4-1 een Emballageset op Debiteur + Verschijningsvorm.
Bij deze koppeling zijn we (nèt als Italië) verplicht om een Emballageset-Id in te vullen. Ook hier maakt de 1e positie van deze Emballageset-Id deze Id uniek naar het aktieve bedrijf; in dit voorbeeld geldt dat de Nederlandse Emballagesets beginnen met de letter 'C'.
Let op:Kliëntgerichte Emballagesets die via menu optie #1 worden toegevoegd (met een Emballageset-Id als attribuut) komen óók automatisch te voorschijn als we ze via menuoptie #2 raadplegen (op Emballageset-Id). Andersom, Emballagesets die we via menuoptie #2 toevoegen, komen
niet bij het Raadpleegoverzicht van menuoptie #1 te staan.
Ongeacht in welk van bovenstaande schermen we met Shift+F5 de Emballageset-onderdelen opvragen, in beide gevallen leidt ze tot dezelfde funktie:
Produktieorders
Uiteindelijk is natuurlijk het doel dat als we gaan produceren, we onze produkten zo kunnen afvullen dat ze voldoen aan de wensen van onze (Intercompany) Debiteuren. Het begint daarmee met de vraag "welke behoefte is er", op basis waarvan een plan kunnen maken hoe we een bepaalde Produktieorder (een kuip die geproduceerd wordt) gaan afvullen.
Naast de Verkooporder van 40 blikken van 20 Liter (E)B12345 uit Italië, heb ik inmiddels ook een Verkooporder opgenomen in Nederland, voor 60 blikken (E)C67890.
Vervolgens ga ik een Produktieorder maken voor één Batch 426EE0000 op een Produktiestation waarop ik batches tot 5000 Liter kan produceren. Het Recept voor dit Artikel staat op 4550 Liter:
In ander recentelijk opgeleverd maatwerk, kunnen we aangeven dat voor een specifieke 5000 Liter Menger geldt dat er altijd 125 Liter niet kan worden afgevuld, omdat dit achterblijft in het leidingwerk tussen de Menger en de Afvullijn; zie topic
http://ha1.heartprofit.nl/profit/index.php?topic=29386.0Dit resulteert (dus) in een Produktieorder waarbij we feitelijk 4550 Liter gaan produceren (voor die hoeveelheid hebben we grondstoffen nodig) maar waarop we slechts 4425 Liter kunnen afvullen (omdat er 125 Liter niet afvulbaar is en in het leidingwerk achterblijft).
De Output hierboven bevat nu 221 blikken van 20 Liter (= 4420 Liter) plus een restantje van 5 liter, tezamen: 4425 Liter.
Dit is 'hoe we vroeger' een Produktieorder maakte, hooguit 'gekorrigeerd voor het uitval wat in het leidingwerk achterblijft'.
Separaat aan het maatwerk Emballageset via een Kenmerk, is er ook maatwerk ontwikkeld om een Menger vol te plannen. Deze funktionaliteit is nog in ontwikkeling, wordt hieronder voor het eerst een beetje beschreven, omdat nu het nut van dat scherm zichtbaar wordt. De output die hierboven al is toegevoegd aan het
Afvuladvies van de Produktieorder verwijder ik eerst! om daarna dat 'Menger vullen' scherm duidelijker uit te kunnen leggen. Dus, alvorens naar dat planscherm te gaan, verwijder ik eerst alle Outputitems van deze Produktieorder; Raadplegen P.O. Output toont dan een leeg Grid:
Listmover "Menger volplannen"
Vanuit Raadplegen Produktieorderoutput (Hoofdmenu,5-2-1-1-Shift+F5) roep ik met toetskombinatie
Control+F5 het nieuwe "Menger volplannen" scherm aan.
Het scherm bestaat uit een Listmovercontrol, waarbij de Linkerlist toont welke Behoeftes er zijn aan het te produceren produkt:
en waarin de rechterlist toont wat we nu in de Output van de Produktieorder is opgenomen:
Onderaan de Listmover control worden dan nog de (toegestane) Verschijningsvormen getoond waarin een eventueel surplus kan worden afgevuld; stel dat we meer produceren dan behoeftig is, dan kunnen we hier aangeven in welke Verschijningsvormen we dát surplus willen afvullen.
Rechts van de Listmovercontrol hebben we nog een klein overzichtje waarin de totalen worden bijgewerkt; onder de streep zien we hoeveel we nog moeten afvullen.
In dit scherm ziet de planner dat hij een Produktieorder heeft van 4550 Kg, waarvan naar verwachting 4425 Kg dekkend mag zijn om 'behoeftes' aan dit produkt mee te dekken. In het scherm links zien we welke behoefte er is. Hierin treffen we de behoefte van 800 Liter (40 blikken van 20 Liter) van Emballageset-Id "B12345" aan, zijnde de Intercompany order die automatisch in ons systeem binnenkwam omdat Italië een order aan haar klant uitbesteedde aan ons. Ook zien we de behoefte aan 60 blikken x 20 Liter (= 1200 Liter) voor Emballageset-Id "C67890", zijnde iets wat we (binnen Nederland) aan een van onze eigen Debiteuren hebben verkocht én waarbij de klant specifieke Emballage wensen heeft. Tenslotte is er ook nog een behoefte van 500 Liter zónder dat er een Debiteur of Emballageset-Id aan de orde is; dit kunnen verkopen zijn aan klanten die dit produkt besteld hebben, maar genoegen nemen met 'het standaard blik'.
Het is nu taak aan de planner om een keuze te maken welke Behoeftes hij wil dekken met de Produktieorder die hij nu gaat volplannen. In dit voorbeeld zien we dat we 4425 Kg kunnen gaan afvullen, terwijl er (slechts) een Behoefte is aan 2500 Kg. We gaan nu de behoeftige regels van links- naar rechts verplaatsen. Dit kunnen we doen door een specifieke regel dubbel aan te clicken, we kunnen ook een regel selekteren en gebruik maken van de 'move' buttons:
Ik selekteer nu alle regels in de linkerlist, en verplaatst deze naar rechts. De Listmovers tonen dan:
Rechts van de Listmover control zien we dat iedere verplaatsing van links- naar rechts (of andersom) van invloed is op de totalen. Die totalen tonen nu aan dat we nog 1925 Liter moeten afvullen:
Op ieder willekeurig moment kunnen we met F1 de stand van de Listmover (en de Spinners onder de Listmover) opslaan. Als we dat doen, en terugkeren naar Raadplegen Produktieorder-Output, dan zien we daar terug wat we in het "Menger volplannen" scherm hebben ingevuld. Ook hier is nu bekend volgens welke Emballageset-Id's we onze order moeten afvullen.
In de header bovenin het scherm, zien we dat deze Produktieorder is gemaakt voor een specifieke
Produktievorm: 20.0LMR:
Hiermee geven we feitelijk aan dat we met deze Produktieorder alléén willen afvullen in dát specifieke 20 Liter blik; daardoor kúnnen we onder in het scherm een eventueel surplus ook alleen maar in dié Verschijningsvorm afvullen. Als we nu deze Produktievorm eens weghalen bij de Produktieorder, en dan het scherm nógmaals aanroepen, dan zien we dat er naast behoefte aan een 20.0LMR óók nog behoefte is aan een 5.00LMR:
Onderaan de Listmover kunnen we ons surplus nu ook in andere Verschijningsvormen afvullen, immers, de Produktievorm beperkt ons nu niet meer tot enkel de 20.0LMR.
De 5 liter blikken gaan we nu ook naar rechts verplaatsen (immers, zolang we behoefte hebben aan iets, zouden we 'dom' zijn als we er niet voor zorgen dat we dat gaan afvullen (immers, die mogelijkheid hebben we). Daarna gaan we 'het restant', het 'surplus', verdelen over de Verschijningsvormen die onder in het scherm staan. In dat schermdeel is ook zichtbaar dat we v.w.b. de 4 liter blikken nog 7914 Liter op voorraad hebben liggen. De planner zal dié Verschijningsvorm dus vast niet kiezen om zijn 'surplus' in af te vullen, immers, de voorraad van 4 liter blikken puilt al uit...
Uiteindelijk vullen we de spinners als volgt in:
hetgeen resulteert in de volgende totalen:
en de volgende Output in onze Produktieorder:
Produktieorder Print
Het eerste document waarop voor Produktie kenbaar zou moeten worden gemaakt wat er precies in welke Verschijningsvorm dient te worden afgevuld, en welke Emballageset onderdelen daarvoor moeten worden gebruikt, is de Produktieorder. De print van deze Produktieorder is altijd maatwerk; iedere klant heeft zijn eigen wensen en eisen voor de P.O. Print.
De klant voor wie wij dit maatwerk hebben ontwikkeld print zijn Produktieorder m.b.v. Excel. Hier hebben we alvast een opzet gemaakt hoe zoiets er uit zou kunnen gaan zien, inclusief een Barcode waarmee de Output via een Scanterminalscherm kan worden opgeboekt.
Vanuit Raadplegen Produktieorder Output is het ook mogelijk om met toetskombinatie Shift+F5 toont een overzicht op te vragen van de Emballageset-onderdelen van een Outputregel. Tevens toont dit overzicht ook hoeveel er van ieder onderdeel op voorraad ligt (funktionaliteit die ooit voor iemand ontwikkeld is die op voorhand zo wilde kunnen zien of er voldoende Emballage-onderdelen aanwezig zijn).
EAN Code Toevoegen
In de vorige versie van dit topic werd nog vermeld dat we per kombinatie Artikel-/Verschijjningsvorm-/Kenmerkwaarden een EAN Code konden/moesten opnemen. Dit was feitelijk bedoeld om op de Produktieorder een Barcode met EAN Code af te kunnen drukken, zodat we met dié Barcode onze Produktieorder Output konden opboeken. Inmiddels is dit achterhaald! Met duizenden klanten en duizenden Artikelnummers ontstaan er miljoenen kombinaties van specifieke wensen aan Emballage of (straks) Labels. Dit zijn er zoveel, dat het geen doen is om voor iedere unieke kombinatie een EAN Code op te nemen. Dat moet dan ook maar niet nodig hoeven te zijn. In Topic
http://ha1.heartprofit.nl/profit/index.php?topic=29620.0 is inmiddels ondervangen dat sommige Kenmerken niet hoeven te leiden tot nieuwe EAN Codes. We kunnen dan verschillende klanten hetzelfde produkt in een 20 liter blik leveren, waarbij voor iedere klant de EAN Code gelijk is, maar toch iedere klant een ander 20 liter blik met een ander deksel kan krijgen. Voor hém geldt dat de EAN code altijd uniek is voor zijn versie van het blik.
Het opboeken van de P.O. Output werkt nu dan ook niet meer op basis van een Barcode waarin de EAN Code is verwerkt, nee, ieder Outputitem van een Produktieorder, uniek gemaakt naar Artikel + Verschijningsvorm + Kenmerkkombinatie (en eventueel debiteur) resulteert nu in een eigen Sub-Chargenummer. Op basis van dát Subchargenummer wordt nu de Produktieorder opgeboekt. Zie topic
http://ha1.heartprofit.nl/profit/index.php?topic=29439.0De Barcode op de Produktieorder bevat nu enkel het Subchargenummer. De Produktieorder drukt de Emballage-onderdelen af die bij de betreffende Emballageset-Id horen; zo is bekend dat met "B12345" een standaard blik met een rood deksel bedoeld wordt:
Opboeken P.O. Output
De Output van een Produktieorder kunnen we opboeken via Hoofdmenu-5-2-2-2, of via een Scanner.
Als we via 5-2-2-2 opboeken, dan selekteren we in de raadpleegfunktie (die de Output v/d P.O. toont) de juiste regel, en boeken we deze met F4 op. In dat popup zien we onze Emballageset-Id weer terugkomen:
Als we via een Scanner opboeken, dan scannen we (bijv.) de Barcode zoals die op de Produkieorder is opgenomen; het scherm toont voor welk Kenmerk dit is (E)C67890 in deze situatie (immers B12345 was via het scherm geboekt):
Na het opboeken komt het produkt op voorraad te liggen. Het Artikelnummer is dezelfde, de Verschijningsvorm ook, maar de Kenmerken (B12345 <> C67890) maken het Voorraaditem verder uniek:
De Voorraadmutaties tonen ons dat voor deze Opboeking van deze 40 blikken, er 40 lege blikken en 40 deksels zijn afgeboekt, met als Artikelnummer hetgeen wat wij in onze Kliëntgerichte Emballageset (op Kenmerk) hadden vastgelegd:
Voor Kenmerk (E)C67890 geldt dat er 60 lege blikken zijn afgeboekt alsmede 60 gele deksels:
Kijken we tenslotte nog bij Raadplegen Te Leveren Artikelen (Hoofdmenu-3-2-1-1) dan zien we dat we daar meerdere te leveren regels hebben voor dezelfde Artikel-/Verschijning, maar deze regels zijn allen voor andere kombinaties van Emballageset-id's. De order 'weet' welke Emballageset een klant moet krijgen, en aangezien we op voorraad ook weten hoeveel voorraad er is van welke Emballageset-Id, wordt hier netjes de voorraadhoogte getoond van dié Emballageset die voor de betreffende klant van toepassing is.
Edit: De informatie in dit topic is inmiddels iets gewijzigd m.b.t. behoeftes zónder Kenmerkwaarde, ongeacht Kenmerkwaarde en geacht Kenmerkwaarde. Zie hiervoor de aanvulling in topic http://ha1.heartprofit.nl/profit/index.php?topic=29417.0
Uitgangspunten / niet ondervangen:
Opvragen V.V.V. van een Emballageset OnderdeelHet is niet mogelijk om een Verwacht Voorraad Verloop op te vragen van een specifiek Emballageset Onderdeel. Dit wordt als 'onzin' betiteld. Onzin, in die zin dat we Emballageset onderdelen gewoon op basis van een onderschreden Bestelniveau kunnen inkopen, waardoor er geen specifieke behoefte is aan het willen opvragen van zo'n Verwacht Voorraad Verloop. Merk op dat indien dit wél graag zou willen kunnen opvragen, dit òf niet werkbaar is òf een dermate prijskaartje met zich mee brengt dat het om die reden niet interessant is. Het probleem daarbij is dat feitelijk alle Openstaande Verkooporderregels zullen moeten worden doorlopen om uit te zoeken of er sprake is van een Emballageset op Emballage-Id, of een normale Klantspecifieke Emballageset of de normale Emballageset.
Wij hebben expliciet besloten dit niet te ontwikkelen.
Meeleveren op Verkooporder <> Retour EmballageHet is niet alleen niet mogelijk om bij Emballage op basis van Emballage-Id te kunnen instellen dat een bepaald Emballageset-onderdeel moet worden meegeleverd op de Verkooporder, danwel dat bepaalde onderdelen wel/niet retour komen, maar het uitgangspunt is ook dat dit niet bij de 'standaard Emballageset' als zodanig wordt geregistreerd. Immers, anders zou iets wat standaard 'Retour' moet komen alsnog op detailniveau niet kunnen worden overruled. De situatie waarbinnen dit maatwerk is ontwikkeld betreft puur de éénmalig verbuikte Emballage welke in Produktie wordt afgeboekt.
Alléén eenmalig Emballage bij Gereedmelden ProduktieorderZie ook het vorige punt, aangezien binnen dit ontwerp zaken als 'Mee te leveren op de Verkooporder' en 'Komt Retour = Ja' zijn uitgesloten, komt het er feitelijk op neer dat we het enkel en alleen over 'eenmalige emballage' hebben, welke wordt afgeboekt bij het opboeken van de Output van een Produktieorder. Dat is daarmee dan ook de enige plek waar deze nieuwe Emballageset gebruikt wordt. Overige funktionaliteit, zoals bijv. 'Printen Prijsreglement', 'Printen Recept met Emballage', 'Slijtage-/Huur berekeningen' zijn verder
niet aangepast, simpelweg omdat ze binnen dit onderwerp niet aan de orde zijn danwel niet gebruikt worden. Middels aanvullend maatwerk is vanzelfsprekend nog van alles mogelijk.
Kompleet- en Gedeeltelijk Gereedmelden niet ondersteund bij meerdere Debiteuren-/VerkoopordersAanleiding voor de ontwikkeling van de Kliëntgerichte Emballage per Emballageset-Id is dat de Output van een Produktieorder (het afvuladvies) uniek gemaakt gaat worden naar de Verkooporderregels die dat produkt behoeven. Op die manier ontstaat er ook een 1 op veel relatie tussen een Produktieorder en de Debiteur waarvoor we produceren. Tot op heden was het op zich al mogelijk op klant specifiek te produceren, maar daarbij gold dat de hele Produktieorder voor één specifieke Debiteur bestemd was (en niet slechts een deel daarvan). Funkties als 'Kompleet Gereedmelden Produktieorder', die vanuit één scherm zowel de input (grondstoffen afboeken) als de output (opboeken gereed produkt) boekt, anticiperen er momenteel dus alléén op dat de hele order voor dezelfde klant is.
Als we in de nieuwe situatie meerdere Verkooporderregels (Debiteuren) gaan koppelen, ontstaat er een 1:n situatie waar de huidige Kompleet- & Gedeeltelijk Gereedmeld funkties niet tegen kunnen. Aangezien deze funktionaliteit niet gebruikt wordt binnen de omgeving waarvoor de huidige uitbreiding ontwikkeld wordt, is besloten deze funkties hier buiten beschouwing te laten. Dit soort gereedmeld funkties blijven op zich gewoon doen wat ze deden, kunnen dus nog steeds worden gebruikt als bijvoorbeeld de hele Produktieorder voor één Verkooporder bestemd is, maar, zodra de Output andere Verkooporders bevat dan de P.O. header, wordt uitvoering van dit soort funkties geblokkeerd.
Of andersom, het Opboeken van Gereed produkt op Produktieorders waaraan meerdere Verkooporderregels zijn gekoppeld, wordt ondersteunt door:
* (Getagd) Handmatig Opboeken P.O. Output (Hoofdmenu-5-2-2-2)
* Scanterminal Opboeken P.O. Output (Scanterminalmenu, Produktie, Opboeken Output)
Kenmerken bij MengreceptuurBinnen dit ontwerp zijn voor het eerst Kenmerken ingezet bij Artikelen die met Meng Recepturen werken. Hierbij is vooralsnog alleen dié funktionaliteit aangepast die voor de problematiek van dit ontwerp nodig was. Zo kunnen behoeftes géacht een Kenmerkwaarde via een Listmoverscherm worden 'gesleept' naar de Output v/d P.O., maar is het (nog) niet mogelijk om handmatig output met een bepaalde Kenmerkwaarde op te nemen, dan wel te wijzigen.
Kenmerken en ScanterminalschermenOok zij opgemerkt dat verreweg de meeste Scanterminalschermen géén Kenmerken tonen, simpelweg omdat dit nooit van toepassing was; we konden immers toch geen Kenmerken opnemen bij produkten die met Mengrecepturen werden geproduceerd. Her en der kan het voorkomen dat (in toch al overvolle schermen) er ergens ruimte gemaakt moet worden om alsnog de Kenmerken weer te kunnen geven.
