M.i.v. deze Releasenote is er een uitbreiding op het ontwerp "Singapore" (zie
http://ha1.heartprofit.nl/profit/index.php?topic=25040.0). De nieuwe situatie valt onder het ontwerp "Turkije", en is grotendeels vergelijkbaar aan de Singapore-methode, doch met één groot verschil.
Waar i.g.v. de Singapore-methode een Verkooporder wordt uitbesteedt aan Leverancier "Singapore" van een Intercompany bedrijf, en "Singapore" slechts "een Leverancier" betreft in dat bedrijf (waarvan we hooguit zodra zij geleverd heeft moeten registreren dat ze geleverd heeft), wordt in het ontwerp "Turkije" uitbesteedt aan Leverancier "Turkije" van een Intercompany bedrijf, en geldt dat "Turkije" óók als bedrijf in Profit bekend is! We besteden dus eigenlijk uit aan een IC bedrijf, maar doen dit via een ander IC bedrijf.
Hebben we bij de "Singapore-methode" te maken met 4 orders, nu komt er een extra order bij, omdat de Inkooporder in bedrijf B bij de Leverancier nu ook een Verkooporder zal triggeren aan bedrijf B. We hebben nu altijd te maken met 5 orders!
1. VOA = Verkooporder in bedrijf A aan de klant.
2. IOAB = Inkooporder in bedrijf A bij IC bedrijf B.
3. VOBA = Verkooporder in bedrijf B aan bedrijf A.
4. IOBC = Inkooporder in bedrijf B bij IC bedrijf C.
5. VOCB = Verkooporder in bedrijf C aan bedrijf B.
In de voor ogen liggende situatie bedrijf bedrijf A altijd Italië, is bedrijf B Nederland, en is bedrijf C Turkije.
Italië verkoopt aan (de kapitein van een) Schip die in de haven van Turkije ligt. Ze besteedt de order via Nederland uit aan Turkije. Turkije zal nu daadwerkelijk moeten gaan leveren.
Loopt bij de "Singapore-methode" er helemaal niets over de voorraad, voor de "Turkije-methode" geldt dat Turkije een écht bedrijf is in Profit, en ook daadwerkelijk zal moeten leveren (Raaplijst, Rapen, Pakbon etc). In Turkije zal dus wel degelijk echte voorraad geleverd moeten worden.
Bij een 'normale' Intercompany order zal het rapen van goederen in het ene bedrijf de goederen direkt opboeken in het andere bedrijf, of anders de goederen op een Inslaglijst plaatsen in het andere bedrijf. Deze werkwijze is in de Turkije-methode geëlimineerd. Omdat er geen goederenstroom plaatsvindt in A en B (C levert rechtstreeks aan de klant van A), wordt de levering van Turkije aan de klant alleen 'onder water' doorgeboekt, maar vinden er geen Voorraadmutaties plaats, noch komt er in A of B iets op voorraad.
Het "onder water doorboeken" van de Levering naar de andere IC bedrijven vereist een extra handeling. Puur in theorie hadden we kunnen besluiten dat zodra Turkije iets levert, deze levering ook direkt in Nederland en Italië bekend zou moeten zijn, maar... "waarom?" We zouden het ons alleen maar erg moeilijk maken omdat allerlei funktionaliteit zoals "terugboeken Levering" dan ook ineens de reeds onder water doorgekopieerde voorraad zou moeten terughalen uit de andere bedrijven. Hiermee zouden we e.e.a. onnodig complex maken.
In het "Singapore" ontwerp is gesteld dat pas zodra de hele order klaar is, en Singapore de Pakbonnen getekend retour stuurt danwel de Faktuur stuurt, exact bekend is wat ze geleverd zal hebben. Pas op dát moment worden alle orders gelijk gemaakt aan hetgeen Singapore aan heeft gegeven wat ze geleverd heeft.
Op eenzelfde wijze doen we dit nu ook bij Turkije. Turkije mag op zich (deel-) leveringen doen, fouten maken en leveringen terugboeken, maar op het moment dat de hele order klaar is en gefaktureerd wordt, dán worden alle gegevens geacht kompleet te zijn. En, hoewel we het doorboeken van de Leveringen zouden kunnen ophangen aan die Fakturatie, hebben we er toch voor gekozen hier een extra stap voor te introduceren. Dit, omdat het vaak voorkomt dat bij het Genereren (en printen) van de Faktuur, en alsnog fouten naar boven komen die eerst gekorrigeerd moeten worden.
Waar wij in Nederland een reeds verzonden Faktuur eenvoudig kunnen laten vervallen en opnieuw kunnen genereren (als de klant een fout konstateert, spreken we met hem af dat hij de Faktuur mag weggooien en dat hij een nieuwe krijgt) is dit in Italië absoluut verboden. Voor Italië hebben we derhalve al eens iets ontwikkeld dat van iedere Uitgaande Faktuur expliciet dient te worden aangegeven dat ze "verzonden" is. Is de Faktuur nog niet verzonden, dan zou de Faktuur nog gekorrigeerd mogen worden, maar is ze verzonden naar de klant, dan mag er niets meer gewijzigd worden, en MOET er gecrediteerd worden.
Dat zelfde "markeren als verzonden" wordt nu in Turkije gebruikt om de Levering door te boeken naar de andere IC bedrijven. Ook Turkije mag dus 'fouten' konstateren op de Faktuur, de Faktuur laten vervallen, de order korrigeren, en opnieuw faktureren, maar zodra de Faktuur als 'verzonden' wordt gemarkeerd wordt de gehele Levering op die order doorgekopieerd naar de IC bedrijven.
Let op: Net als bij de Singapore methode is ook hier geen funktionaliteit ontwikkeld om een dergelijke doorkopiëring van de levering ongedaan te maken!
Voor het (onder water) doorleveren van de voorraad wordt in bedrijf A en B een extra Journaalpost uitgevoerd in de vorm van:
Nog te faktureren Voorraad Aan Nog te ontvangen Fakturen
Omdat bij deze boeking geen Grootboekrekeningen worden geraakt die afhankelijk zijn van een Financiële Groep (Artikel) wordt er maar één boeking uitgevoerd, voor de totale verkoopwaarde van de voorraad.
Naast een aantal beperkingen die al aan de orde waren in het "Singapore" ontwerp (zie eerder genoemde Releasenote) gelden er nog een aantal uitgangspunten:
* Deelfaktureren van bedrijf C aan B is niet toegestaan (dit zou nl. een 1:n relatie vereisen m.b.t. het doorkopieren van de orderregels).
* Verzamelfakturatie in bedrijf C aan B is niet toegestaan (iedere Verkooporder wordt geacht op een separate Faktuur in rekening te worden gebracht).
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| ADIFGN | Omschrijving (nog) niet bekend | 24-09-2014 | 23-06-2015 |
| LOIOVW | Verwijderen Inkooporders. | 01-06-2015 | 19-06-2015 |
| LOIRTV | Toevoegen Inkooporderregels | 12-06-2015 | 19-06-2015 |
| LOIRUBGK | Omschrijving (nog) niet bekend | 15-12-2014 | 19-06-2015 |
| LOIRUBRA | Omschrijving (nog) niet bekend | 21-05-2014 | 19-06-2015 |
| LOIRVW | Verwijderen Inkooporderregel | 03-06-2015 | 19-06-2015 |
| LOIRWYF1 | Omschrijving (nog) niet bekend | 03-06-2015 | 19-06-2015 |
| LOLRBK | Invullen Raaplijst-Regel. | 29-05-2015 | 19-06-2015 |
| LOLRRA | Raadplegen Raaplijst. | 16-10-2014 | 22-06-2015 |
| LOLRRG | Rapen en Goedkeuren Raaplijst. | 29-05-2015 | 19-06-2015 |
| LOLRRGA1 | Omschrijving (nog) niet bekend | 29-05-2015 | 19-06-2015 |
| LOLRTBZ3 | Omschrijving (nog) niet bekend | 29-05-2015 | 22-06-2015 |
| LOLRTRKO | Omschrijving (nog) niet bekend | 31-10-2014 | 19-06-2015 |
| LOUFDB | Fin. Doorbelasten Faktuur | 29-05-2015 | 22-06-2015 |
| LOUFGN1 | Omschrijving (nog) niet bekend | 05-06-2015 | 22-06-2015 |
| LOUFRA | Raadplegen Uitg. Fakturen | 14-04-2015 | 22-06-2015 |
| LOUFRDRA | Raadplegen Uitg. Fakturen Debiteur | 14-04-2015 | 22-06-2015 |
| LOUFVW | Verwijderen Uitgaande Faktuur | 11-11-2014 | 22-06-2015 |
| LOUFWYVS | Omschrijving (nog) niet bekend | 11-02-2014 | 22-06-2015 |
| LOVOTV | Toevoegen Verkooporders | 18-06-2015 | 19-06-2015 |
| LOVOTVVA | Omschrijving (nog) niet bekend | 18-06-2015 | 19-06-2015 |
| LOVOUBGK | Omschrijving (nog) niet bekend | - - | 22-06-2015 |
| LOVRAW | Omschrijving (nog) niet bekend | 27-02-2014 | 19-06-2015 |
| LOVRRA | Raadplegen Verkooporderregels | 04-06-2015 | 19-06-2015 |
| LOVRVW1 | Omschrijving (nog) niet bekend | 25-03-2015 | 22-06-2015 |
| LOVRWYF1 | Wijzigen Verkooporderregels. | 18-06-2015 | 19-06-2015 |
