Uitbesteden aan Leverancier van Intercompany Bedrijf M.i.v. deze Releasenote is er een bijzonder stukje maatwerk ontwikkeld m.b.t. de afhandeling van een Uitbesteding i.c.m. Direkt Leveren. En, om het meteen nog wat complexer te maken, wordt in dit voorbeeld een order twee maal uitbesteedt, waarvan één keer via een Intercompany order. Deze specifieke situatie wordt in deze Releasenote nader toegelicht. Waar de Releasenote op dit moment alléén gebruikt kan/mag worden voor deze situatie, geldt dat de toegepaste methode zich in principe ook best kan lenen voor andere situaties, bijv. het uitbesteden aan een normale leverancier.
Nb: In navolgende tekst volgen een aantal schermen waarin bedrijfsnamen worden genoemd. Verder geen privé gegevens. Genoemde bedragen zijn allemaal fiktief.
Probleemstelling
Een bedrijf in Italië (Boat) is gedeeltelijk eigendom van een nederlands bedrijf, met vestigingen over de hele wereld. V.w.b. de World-Wide orders maakt het Italiaanse bedrijf gebruik van het netwerk van het nederlandse bedrijf. Het Italiaanse bedrijf verkoopt verf aan (de kapitein van / of de reder van) een schip. Het schip wat geschilderd moet worden kan in principe overal in de wereld in een haven liggen; in dit geval hanteren we "Singapore" als voorbeeld.
a. Italië verkoopt aan een schip
b. Italië besteedt deze order uit aan Nederland
c. Nederland besteedt deze order uit aan haar Leverancier in Singapore, wat feitelijk een zusterbedrijf is van Nederland.
Binnen Profit hadden we op zich al funktionaliteit om een order uit te besteden aan een Leverancier, en ook aan een Intercompany Bedrijf. Als we een order zouden uitbesteden aan een normale Leverancier, dan gold dat 1:1 met de Verkooporder er een Inkooporder werd gegenereerd, en stond deze Inkooporder vervolgens open. Als de Leverancier uiteindelijk het bericht gaf dat de goederen geleverd waren, moest er een normale
Goederen Ontvangst worden geboekt, waarbij de goederen technisch een fraktie van een seconde op een
Dummy Lokatie Direkte Leveringen op voorraad werden geboekt, en waarna vervolgens de Verkooporderregel automatisch werd geleverd vanaf deze dummy lokatie. Per saldo was er nooit voorraad op deze lokatie (vandaar ook dat ze 'dummy' heette), en het effekt was dat de Verkooporderregels werden gefaktureerd met de hoeveelheden zoals bij Goederen Ontvangst aangegeven.
Uitbesteding aan een Intercompany Bedrijf was ook mogelijk, en welke situatie nog steeds zal worden toegepast bij orders aan een schip die bijv. in de haven van Rotterdam ligt. In deze situatie zal de Verkooporder in Italië leiden tot een Inkooporder bij het Nederlandse Bedrijf, en volgt daaruit dat het Nederlandse Bedrijf een Verkooporder heeft naar het Italiaanse bedrijf. De Verkooporder in Nederland ziet er nu precies uit als iedere willekeurige andere Verkooporder; Nederland zal goederen moeten afleveren op een adres in de haven van Rotterdam (maar de faktuur gaat naar Italië).
De Charges die door Nederland worden geleverd, worden wederom automatisch als "Ontvangen" geboekt op de Inkooporder in Italië (bij Nederland), op de "Dummy Lokatie Direkte Leveringen", en worden daarvan vanaf deze lokatie automatisch doorgeleverd op de Verkooporder in Italië aan het schip.
Nog complexer wordt het in de situatie "Word Wide", waarbij Nederland op haar beurt de order weer uitbesteedt aan een zusterbedrijf in Singapore (overigens een bedrijf welke niet logistiek binnen Profit registreert wordt, dus, wat dat betreft is het een 'normale leverancier', maar, welke informatie wel even bekend moet zijn v.w.b. de uitleg van de inkoop-/verkoopprijs bepaling verderop).
Als Singapore levert, zou er dummy voorraad moeten worden opgeboekt in Nederland, die vervolgens op de verkooporder geleverd zou moeten worden, wat dan weer zou triggeren dat er voorraad in Italië op een dummy lokatie zou moeten worden opgeboekt, en in Italië weer aan de klant als geleverd zou moeten worden geboekt. Een procedure die redelijk omslachtig is, zeker gezien het feit dat er eigenlijk helemaal geen goederenstroom plaatsvindt tussen alle Intercompany bedrijven; Singapore levert rechtstreeks aan de klant van Italië, en het enige wat afgehandeld moet kunnen worden is dat de bedrijven elkaar onderling kunnen faktureren voor het juiste bedrag.
Nog een extra complexiteit die hierbij optreedt, is dat naast het assortiment van produkten wat voor Italië, Nederland en Singapore gelijk is, er ook een assortiment aan produkten is die wel door het ene bedrijf gehanteerd wordt, maar niet door het andere bedrijf (of de andere bedrijven). We willen dus produkten kunnen verkopen die niet (formeel) in het assortiment van de Leverancier voorkomen, maar, wat natuurlijk altijd klantspecifiek geproduceerd kan worden. In een uiterst geval moet het er zelfs opneer kunnen komen dat de bestelling niet veel meer betreft dan 'het scannen van de bestelling van de kapitein van het schip, en deze, via het nederlandse bedrijf, doorsturen naar de Leverancier in Singapore, die vervolgens zelf wel weet welke produkten er geleverd moeten worden'.
Omdat er in deze situatie er eigenlijk helemaal geen goederenstroom plaatsvindt tussen de Intercompany Bedrijven, is nu een nieuwe methode bedacht waarbij we niets via de voorraad laten lopen. De Intercompany Orders die gegenereerd worden, worden als 'afgesloten' regels opgenomen, en hoeven niet (expliciet) geleverd te worden; er loopt niets via de voorraad, dus er valt niets te leveren. Op de "heenweg" triggert de Verkooporder die in Italië wordt toegevoegd alle Intercompany orders t/m de uitbesteding in Nederland naar Singapore aan toe. Op de "terugweg", als de pakbon getekend retour komt, kan de Inkooporder van Nederland bij Singapore worden gewijzigd op basis van de produkten waarvan Singapore aangeeft ze te hebben geleverd; deze informatie wordt weer doorgekopieerd naar alle Intercompany orders, waarna de bedrijven elkaar onderling kunnen faktureren, en waarna Italië haar klant kan faktureren.
Uitgangspunten
* Er zijn altijd 4 orders aan de orde.
- #1 De Verkooporder in Italië aan de kapitein van het schip
- #2 De Inkooporder vanuit Italië bij het Nederlandse bedrijf
- #3 De Verkooporder van Nederland aan Italië (welke volgt uit #2)
- #4 De Inkooporder (uitbesteding) van Nederland aan Singapore
* Inkoopprijzen gelden per Ontvangstlokatie. Per Ontvangstlokatie mag slechts één Valutakode worden gebruikt voor alle produkten van de betreffende Leverancier.
* In bedrijf Nederland zal er maar één Leverancier gekoppeld mogen zijn aan de betreffende Ontvangstlokatie. De Ontvangstlokatie (World-Wide Singapore) dwingt dus a.h.w. de Leverancier af.
* De Intercompany Bedrijven verkopen elkaar tegen een Intercompany Prijs. De Prijs die Singapore aan Nederland berekent is dezelfde prijs als die Nederland aan Italië berekend (maar zal wel een andere zijn dan die Italië aan haar klant berekend). De onderlinge bedrijven verdienen dus niets aan de orders; het concern als geheel uiteraard wel immers er is een order aan een klant verkocht.
* Waar bovenstaand is uitgelegd dat het alle Intercompany Bedrijven elkaar tegen dezelfde prijs verkopen, en waar het normaal gesproken zo is dat 'de verkopende partij altijd de prijs bepaalt', is het uitgangspunt voor deze orders dat de prijs bepaalt wordt door het Inkopende Bedrijf ! Dit heeft ermee te maken dat de trigger voor de Intercompany orders begint bij de Inkoop van Italië bij Nederland, alsmede het feit dat aan de Inkoopzijde er in een eerder stadium al Inkoopprijzen zijn ontwikkeld die uniek kunnen worden gemaakt naar een Ontvangstlokatie, en waarmee gerealiseerd kan worden dat een Inkoop in Singapore voor een schip in de haven van Singapore tot een andere prijs leidt dan een Inkoop bij Singapore voor een schip wat in een haven in Indonesië.
* Variabele Artikelomschrijving staat Aan.
* Deelleveringen worden niet ondersteund; iedere order dient in één keer te worden afgehandeld. Als 'een werk' op voorhand wordt verkocht als verschillende 'deelwerken' waaruit meerdere fakturen dienen te volgen, dient dit als separate verkooporders te worden toegevoegd.
* Geen ondersteuning voor DKK Tarieven en-/of Inkoopprijs verhogende faktoren.
* Funktionaliteit alleen beschikbaar in de Windows versie. Vereist de modules Profit-Intercompany en Profit-Uitbesteding.
Parameter Instellingen
* In zowel Italië alsmede in Nederland zal parameter "Intercompany Leveren tegen Kostprijs" met "I" moeten worden gevuld.
* In (minimaal) Italië zal parameter "Intercompany Uitbesteding o.b.v. Afleveradres 9999" met "Ja" gevuld moeten worden.
Eenmalige instellingen per Afleveradres
In Italië wordt er een Verkooporder geplaatst aan (de kapitein van) een schip. In theorie mág deze Verkooporder op basis van een vrij Afleveradres 9999 worden toegevoegd, maar, beter is om (omwille van Statistieken) formeel Afleveradressen op te nemen bij deze Debiteur, dan kunnen we aldaar ook extra instellingen registreren. In het voorbeeld verkopen we aan een schip "M/V Ajax" die onder Afleveradres #2 "de haven in Singapore" als Afleveradres heeft:
Op Tabblad #4 bij het Afleveradres geven we aan dat dit Afleveradres beleverd moet worden vanaf Raapvloer "Word-Wide-Singapore" (WWSIN), én plaatsen we een vinkje bij rubriek "Uitbesteden aan Leverancier van Intercompany Bedrijf J/N".
Nb: De Raapvloer WWSIN is nodig omdat we aan de Inkoopzijde de Inkoopprijs bepalen op basis van een Ontvangstlokatie, en we "iets" moeten hebben wat vanuit de Verkooporder deze Ontvangstlokatie van de Inkooporder doet triggeren: de Raapvloer.
Verkooporder Toevoegen
Vervolgens voegen we een Verkooporder toe. De Debiteur is "AJAX" en het Afleveradres is "2". Zodra we beide hebben ingevuld, zien we dat rechts boven in het scherm de rubriek "Uitbesteden aan Leverancier IC Bedrijf J/N" automatisch met "Ja" wordt beantwoord, dit, omdat we dit bij het Afleveradres al als zodanig hebben geregistreerd.
Op het tweede Tabblad kan middels een Combobox een Intercompany Bedrijf worden geselekteerd aan welke moet worden uitbesteedt. Indien er maar één Intercompany Bedrijf is aan wie uitbesteedt kan worden, zal deze automatisch worden gevuld en worden disabled. De Raapvloer wordt in dit voorbeeld gevoed met de 'WWSIN' waarde zoals we die bij het Afleveradres hadden vastgelegd.
Na F1 komen we (zoals gewoonlijk) terecht in Toevoegen Verkooporderregels.
Het lijkt nu alsof er nog niet veel bijzonders gebeurd is, maar dat is er wel degelijk ! Waar we normaal gesproken direkt door gaan met het toevoegen van onze Verkooporderregels, zouden we nu terug kunnen keren naar het hoofdmenu, om te bekijken wat er op dit moment allemaal al gebeurd is.
In Italië hebben we een Verkooporder toegevoegd aan (de kapitein van) een schip. Bij de Verkooporderheader hebben we aangegeven dat deze order moet worden uitbesteedt aan de Leverancier van een Intercompany Bedrijf, en hebben we via de Comboxbox aangegeven aan welk Intercompany Bedrijf we de order gaan uitbesteden. Een van de uitgangspunten was dat het Inkopende Bedrijf 'de prijs' bepaalt. Een ander uitgangspunt was dat 'alle prijzen voor een ontvangstlokatie in dezelfde valutakode moeten staan'.
In bovenstaande prijsafspraak (Hemnu-4-6) is vastgelegd dat de prijzen voor Ontvangstlokatie "World-Wide-Singapore" (WWSIN) in "SGD" (Singapore Dollar) gelden.
Hieruit volgt dat in Italië bekend is dat er bij Nederland moet worden ingekocht, in SGD. Het systeem heeft deze Inkooporderheader dan ook alvast toegevoegd.
Als Italië een Inkooporder heeft bij Nederland in SGD, impliceert dit dat Nederland een Verkooporder heeft aan Italië, eveneens in SGD.
Omdat Nederland niet over alle duizenden debiteuren van Italië moet hoeven te beschikken, is de order in NL geplaatst aan het Italiaanse Bedrijf "BOAT". Via Afleveradres 9999 worden de afleveradresgegevens van de klant in Italië kenbaar gemaakt aan het Nederlandse bedrijf.
In Nederland is weer bekend dat de lokatie WWSIN gekoppeld is aan Leverancier "Singapore". Dit, bij de gratie dat er slechts voor één Leverancier Inkoopprijzen gedefinieerd mogen zijn voor de Ontvangstlokatie "WWSIN". Zodoende kan er in Nederland ook alvast een Uitbestedingsorder worden gemaakt aan Singapore.
Ofwel, het feit dat we in Italië een verkooporderheader aanmaakte, triggert al direkt de aanmaak van een drie tal Intercompany orders. In totaal hebben we dan 4 orders, die altijd "als setje" bij elkaar horen.
Let op: Vanaf dit moment zouden we al een Multi Media Button kunnen opnemen, en de order puur op basis van een scan kenbaar kunnen maken aan de Intercompany Bedrijven; hierover straks meer.
Verkooporderregels Toevoegen
Middels normale Artikel-/Verschijningen geven we de produkten aan die we gaan verkopen. Het systeem respekteert hierbij eventuele definities van Kliënt-/Artikelen.
Zo is het mogelijk dat Italië aan haar klant een Artikel 502AB0020 verkoopt, welke in Nederland wordt ingekocht onder Artikelnummer 502AC0020, en welke weer aan Singapore wordt uitbesteedt als 502AS0020. Uiteraard is het ook mogelijk dat het Artikelnummer in alle bedrijven gelijk is.
Onderstaand zien we dat we in Italië een Verkooporderregel toevoegen voor 502AB0020 in blikken van 20 liter; 50 Verschijningen.
Ook hier geldt, dat zodra we deze regel met F1 hebben verwerkt, deze orderregel in alle IC orders is opgenomen. In de Inkooporder van Italië bij Nederland zien we dat er een regel is toegevoegd:
Is de Verkooporder van Nederland aan Italië uitgebreid met deze regel:
en is de regel toegevoegd aan de Uitbesteding van Nederland bij Singapore:
Nb: Merk overigens op dat omdat
iedere regel direkt in
alle 4 orders wordt opgenomen, het regelnummer in alle orders hetzelfde zal zijn. Orderregel #1 in de order van Italië aan de kapitein, zal dus ook orderregel #1 zijn in de Inkooporder van Nederland aan Singapore.
Vanuit Toevoegen Verkooporderregels in Italië is vooraf gekontroleerd of het wel mogelijk is om deze orderregels in alle bedrijven aan te maken. Stel dat het verkochte produkt niet door Nederland geleverd wordt (maar wel door Singapore geleverd kan worden), dan zal er een melding volgen die zegt dat het Artikelnummer niet bestaat in Nederland. Voor de verkoop van 'niet in alle bedrijven bekend zijnde artikelnummers' hebben we bedacht één algemeen Artikelnummer te introduceren; gezien de opbouw van de Artikelnummers (nnnCCnnnn) zouden we uitkomen op bijv. Artikel 999ZZ9999. Aan dit Artikel koppelen we vervolgens alle Verschijningsvormen die we nodig achten. In mijn voorbeeld heb ik 999ZZ9999 beschreven als "Non defined Intercompany Item".
Stel dat ik dit Artikel verkoop, dan zorgt het mechanisme van "Variabele Artikelomschrijving" ervoor dat we de standaard omschrijving "Non defined IC item" kunnen overschrijven met de produktomschrijving die we willen.
Omdat we "alle" Verschijningsvormen aan dit produkt gekoppeld hebben, kunnen we het produkt in iedere verschijning verkopen. Dit produkt wordt op eenzelfde wijze opgenomen op alle Intercompany orders, in dit geval gekombineerd met de variabele omschrijving. Uiteraard mag het duidelijk zijn dat als we een willekeurig produkt met een variabele omschrijving verkopen, we op de verkooporder van Italië naar de klant best in staat zullen zijn om een verkoopprijs in te vullen, maar, het systeem zal niet weten voor welke prijs we het produkt intercompany inkopen. Deze prijs blijft 0,00 bij de gratie dat we haar niet weten.
Maar, het staat u natuurlijk altijd vrij om meerdere van dit soort algemene 999ZZ9999 artikelnummers op te nemen, bijv. per prijsklasse een artikel, en waarbij dan alsnog een korrekte inkoopprijs opgenomen kan worden in een prijslijst. Dit valt en staat dus bij hoe u e.e.a. verder inricht.
Vervolgens vinden we dat de order klaar is.
Nb: "Iets" of "iemand" zal er nu voor moeten zorgen dat de Leverancier in Singapore de order krijgt. Hoe dat stukje konkreet wordt ingevuld is nog niet 100% duidelijk, de kapitein kan ook kontakt hebben met Singapore, maar desnoods wordt de Inkooporder in het andere bedrijf gefaxt-/gemaild.
Pakbon getekend Retour vanuit Singapore
Dan gebeurt er een hele tijd niets. De order ligt nu bij Singapore, en, het wachten is tot we van Singapore de pakbon getekend retour ontvangen, waaruit blijkt welke produkten er daadwerkelijk geleverd zijn, hoeveel, en tegen welke prijs. Hierbij anticiperen we ook op het feit dat de kapitein van het schip kontakt opneemt met leverancier Singapore, omdat aanvullend bijvoorbeeld een slaapkamer nog een extra kleurtje dient te krijgen.
Net als dat we op de 'heenweg' orderregels in Italië kunnen toevoegen die in de IC orders worden opgenomen naar Singapore, kan in Nederland uit de getekende Pakbon van Singapore volgen dat er andere produkten zijn geleverd, en dient deze informatie terug te worden gekopieerd tot aan de order aan de klant.
Ook als Artikelnummers wel op voorhand bekend zijn, en geleverd worden zoals besteld, kunnen er alsnog dingen kunnen wijzigen. Zo ondersteunen we normaliter aan de verkoopzijde een zgn. Drydock methode, waarbij we 100 blikken kunnen verkopen, maar met de klant afspreken dat hij hetgeen hij niet verbruikt terug mag sturen. Vervolgens kunnen we 20 blikken retour worden geboekt op dezelfde order, waarna de uiteindelijke faktuur het saldo van 80 blikken in rekening zal brengen.
Dergelijke methode kan ook hier aan de orde zijn, ware het niet dat wij nu geen 20 blikken retour zullen krijgen. Er loopt nl. niets over de voorraad. Uitgangspunt is dat alles door de Leverancier in Singapore wordt afgehandeld, en uit de getekende pakbon die retour komt zal in zo'n geval volgen dat er meer-/minder verbruikt is.
Aan de inkoopzijde is een nieuwe funktie "Raadplegen Inkooporderregels" ontwikkeld voor dit type Intercompany Uitbesteedde orders.
Vanuit dit scherm kunnen we nieuwe orderregels toevoegen, en bestaande orderregels wijzigen danwel verwijderen. Alhier moeten we de order gelijk maken aan wat er volgens de Pakbon van Singapore geleverd is. In het kader bovenin het scherm wordt het totale orderbedrag weergegeven, wat mede indikatief kan zijn voor het feit dat de order verder korrekt is.
Zo kunnen we bijv. aangeven dat er 33 Verschijningen geleverd zijn:
Als we een Inkooporderregel Toevoegen of Wijzigen vanuit de Inkooporder bij Singapore, dan zal hieruit wel volgen wat de prijs is die Singapore bij Nederland in rekening brengt. Gezien het uitgangspunt "de Intercompany bedrijven verkopen elkaar tegen dezelfde prijs, en verdienen zelf niet aan de IC orders", volgt daaruit dat ook de prijs waarvoor Nederland aan Italië verkoopt, danwel Italië bij Nederland inkoopt bekend is. Echter, de prijs die Singapore berekend, zal in geen verhouding staan tot de prijs die Italië aan haar klant berekend. Dat zal alsnog handmatig (door Italië) vastgelegd moeten worden.
Om te voorkomen dat de Verkooporder in Italië tegen een verkeerde prijs (bijv. 0,00) wordt gefaktureerd aan het schip, krijgt iedere Verkooporder die vanuit de Inkooporder bij Singapore wordt gewijzigd een trigger "Verkoopprijs moet gekontroleerd worden" toegekend. Alvorens deze order gefaktureerd kan worden, zal iemand per Verkooporderregel de Verkooporderregel moeten wijzigen, de prijs eventueel aanpassen, en dit met F1 te bevestigen.
Goedkeuren Inkooporder Singapore
Indien de Pakbon getekend retour is gekomen, en de Inkooporder in Nederland bij Singapore gelijk is gemaakt aan de produkten die conform deze pakbon geleverd zijn, feitelijk, het moment dat we 'klaar zijn', resteert ons nog één handeling: formeel aangeven dát we klaar zijn. Dit doen we vanuit Raadplegen Inkooporderregels van de order in Nederland bij Singapore (de plek waar we die order gelijk maken aan de pakbon), middels toets Shift-F5 (Goedkeuren).
Om zeker te zijn dat we de juiste order goedkeuren, toont "Goedkeuren" ons het Afleveradres van de order in het andere bedrijf (Italië). Tevens is in het kader bovenin het scherm het totale orderbedrag zichtbaar. Ervanuitgaande dat ieder produkt een prijs heeft, zal dit totale orderbedrag indikatief kunnen zijn voor het feit dat we niets vergeten zijn.
"Goedkeuren" genereert nu alsnog onderwater 'ontvangsten' en 'leveringen' voor al deze orders. Hoewel er niets 'over de voorraad' zou lopen, maken we geen voorraadmutaties, leggen we ook niets op voorraad, maar we maken wel de ontvangstrecords en de leveringsrecords formeel aan, dit, opdat aanpassing van allerlei andere processen niet nodig is. Immers, een fakturatie zal de geleverde charges faktureren, en, zolang er geen leveringsrecords zijn zouden we een andere methode moeten verzinnen om er toch een faktuur uit te kunnen laten komen. Ook geldt dat bijv. talloze overzichten, waaronder de verkoopoverzichten en -statistieken, hun data putten uit de geleverde charges. Zonder de aanwezigheid van deze records zouden dit soort overzichten bij voorbaat niet werken.
E.e.a. dus meer als technisch argument om niet het halve pakket te hoeven aanpassen voor deze bijzondere situatie.
Na goedkeuring kan Nederland aan Italië faktureren, en kan Italië aan haar klant faktureren. De faktuur van Singapore aan Nederland hoeft dan in principe nog niet ontvangen te zijn. Als deze wordt ontvangen, zou deze gelijk aan de voormelding behoren te zijn.
Multi Media Buttons
De Multi Media funktionaliteit die binnen dit ontwerp is ontwikkeld, staat beschreven in topic
http://ha1.heartprofit.nl/profit/index.php?topic=25021.0,
http://ha1.heartprofit.nl/profit/index.php?topic=25104.0 en topic
http://ha1.heartprofit.nl/profit/index.php?topic=25107.0In het kort: in bedrijf Italië alsmede in bedrijf Nederland kan een Multi Media Toepassing "Orderscan" moeten worden toegevoegd. Hiervan dient te worden aangegeven dat deze intercompany moet worden gekopieerd. Zoals eerder uitgelegd, geldt dat vanaf het moment dat de Verkooporderheader in Italië is toegevoegd, alle Intercompany orders in het systeem bekend zijn. Vanaf dat moment is het mogelijk om bijv. een scan van de order van de kapitein op te nemen als Multi Media Button bij de betreffende Verkooporder, waarna deze automatisch bij alle Intercompany orders wordt opgenomen. De orderscan kan vervolgens worden opgevraagd vanuit de Verkooporder in Italië aan de kapitein, vanuit de Inkooporder van Italië bij Nederland, vanuit de Verkooporder van Nederland aan Italië, en vanuit de Inkooporder vanuit Nederland bij Singapore.
Om Multi Media Buttons eenvoudiger aan een order te kunnen koppelen, kan dit nu vanuit het Grid (Raadplegen Verkooporders) worden opgenomen.
Het laatste topic beschrijft de mogelijkheid hoe nieuwe documenten kunnen worden aangemaakt, en als Multi Media Button aan de betreffende order kunnen worden gekoppeld (waarna ze meteen weer worden opgenomen bij alle Intercompany orders). Deze methode is ontwikkeld om de gebruiker zelf een vrije lap tekst in te kunnen laten voeren, met allerlei tekst, uitleg, specifieke wensen van de klant. Denk hierbij ook aan het feit dat de bestelling die Italië ontvangt in het Italiaans kan staan, en door iemand vertaald moet kunnen worden naar iets wat door Singapore begrepen kan worden (Engels).
Op zich bood het de standaard funktionaliteit al wel een mogelijkheid om bij het genereren van de Uitbestedingsorder "tekst door te kopiëren", maar, dit betrof slechts een eenmalige kopie van de tekst van de Verkooporderregel naar de Inkooporderregel. Dit werkte niet Intercompany, en zorgde er ook niet voor dat als de tekst achteraf gewijzigd werd, er nógmaals werd doorgekopieerd; laat dus staan dat de tekst vanuit willekeurig welke van de 4 orders gewijzigd kon worden, en daarna 'teruggekopieerd' werd. Deze Multi Media Button tekst betreft één tekstdocument die éénmalig op disk wordt opgeslagen (waarbij de gebruiker zich overigens niet hoeft te bemoeien met het verzinnen van de lokatie, en de naam van de file), en waar op 4 plekken een Multi Media Button wordt opgenomen die verwijzen naar hetzelfde document.
Mogelijke aanvullingen
* Ongedaan maken van een procedure "Goedkeuren order"
