Crediteren

Een bijzonder ontwerp, bedoeld om diverse Crediteringsproblemen te omzeilen.

Inleiding

In het meest eenvoudige voorbeeld van een levering van een Verkooporder, komt er op enig moment een bestelling binnen van een klant en wordt er een Verkooporder toegevoegd. Vervolgens wordt er een Raaplijst aangemaakt, worden de goederen daadwerkelijk geraapt (Pakbon) en worden ze verzonden (Vrachtbrief). Zodra de goederen geraapt zijn, zijn ze voor het systeem "geleverd", en kan de order worden gefaktureerd. Zo'n faktuur kan direkt met de zending mee, maar kan ook achteraf worden nagezonden.

We kunnen het voorbeeld al iets moeilijker maken door het introduceren van de zgn. "DryDock funktionaliteit"; rubriek "Komt Retour J/N" (op Verkooporder niveau). Binnen dat ontwerp is het mogelijk om aan te geven dat een klant delen van de geleverde goederen retour mag sturen. Hierbij gaat het dan niet zo zeer om een situatie dat een klant een produkt geleverd krijgt welke niet voldoet en derhalve retour gezonden wordt c.q. omgeruild moet worden voor een ander, maar ze is eerder bedoeld voor situaties waarin de klant niet precies weet hoeveel ze nodig heeft, derhalve 'teveel' bestelt (om in ieder geval voldoende te hebben) en daarbij de afspraak maakt dat retour gezonden mag worden wat niet verbruikt wordt. Vergelijk het maar met de situatie dat er een feest georganiseerd wordt, u ervoor wilt zorgen dat u voldoende drank in huis heeft, en bij de supermarkt diverse kratjes bier, flessen wijn, flessen frisdrank etc. inslaat en met de supermarkt afspreekt dat alles wat niet verbruikt weer terug gebracht mag worden. Maar, de funktionaliteit kan ook worden gebruikt indien (een deel van) de geleverde produkten niet geaccepteerd worden; een betonfabrikant levert tegels-/banden en bij aankomst bij de klant zijn er een aantal kapot. Nog een ander voorbeeld zou kunnen zijn dat de kleur van het bestelde produkt niet helemaal overeenkomt met hetgeen benodigd is, dat de hele partij retour komt en er een ander produkt geleverd moet worden.

Om iets retour te ontvangen van een klant hebben we op zich natuurlijk geen "DryDock" funktionaliteit nodig; we kunnen immers altijd handmatig een Creditorder maken en de goederen retour nemen. Maar... als we dát doen, hebben wij éérst een Debetfaktuur aan onze klant voor de levering en daarna nog een Creditfaktuur voor de retouren, en, als wij twee Fakturen hebben, krijgt onze klant die ook, en dus zal zij twee fakturen moeten inboeken, kontroleren, betalen etc.

Het "DryDock" maatwerk was een van de eerste ontwerpen om dit soort Creditfakturen te elimineren. Het bijzondere van de "DryDock" funktionaliteit is dat de retour op dezelfde order wordt geboekt als de order waarop de levering heeft plaatsgevonden, en waarna er uiteindelijk één Faktuur volgt waarop de levering en de retouren verrekend zijn. De klant krijgt dus niet meer meerdere fakturen, maar krijgt één overzichtelijke Faktuur die zij kan matchen met wat ze afgenomen-/verbruikt heeft. Dus; om nog een konkreet voorbeeld te geven: we leveren 100 blikken verf aan een klant, de klant verbruikt slechts 80 blikken en stuurt de resterende 20 blikken retour, dan krijgt de klant uiteindelijk maar één Faktuur voor 80 blikken. Zonder het Drydock maatwerk zou ze eerst een Debetfaktuur hebben gekregen voor 100 blikken en later nog een Creditnota voor 20 blikken.

Vanzelfsprekend geldt dat als we een levering met een retour willen verrekenen en gesaldeerd op één Faktuur in rekening willen brengen, we dús niet eerder kunnen Faktureren tot het moment waarop we weten wat er daadwerkelijk is afgenomen-/retourgezonden-/verbruikt. In het eerder gegeven voorbeeld dat wij een feestje organiseren gaan wij op een vrijdag naar de supermarkt en kopen we onze drank in, op zaterdag is ons feestje, en maandag brengen we de restanten terug en kan de rekening worden opgemaakt. We hebben al wat meer tijd nodig voordat de rekening kan worden opgemaakt in de situatie van de betonleverancier, omdat daar pas bekend is hoeveel tegels/banden er kapot zijn als de pallet is afgestapeld. Maar... we moeten nóg groter denken! In ons voorbeeld gaan we schepen verven, variërend van enkel het dek, tot aan het hele schip, de hutten maar ook de buitenkant van het schip.

Proof of Delivery
Afhankelijk van wat er precies geschilderd moet worden, kunnen er duizenden liters verf nodig zijn, en kan het werk maanden in beslag nemen. Een schip kan in iedere haven van de wereld liggen en u doet zaken met diverse agenten die voor u de honneurs waarnemen. Daarnaast hebben we ook nog te maken met zaken als dat een kapitein van een Italiaans schip in de haven van Singapore ligt, de Italiaanse rederij contact onderhoudt met een Italiaanse leverancier die worldwide kan leveren, maar zij haar bestellingen moet laten lopen via een Intercompany Bedrijf welke de worldwide contacten afhandelt. Er wordt een bestelling geplaatst bij een Italiaanse vestiging van een bedrijf welke worldwide opereert, zij laat de order lopen via de europese moedermaatschappij, die vervolgens weer de order laat uitvoeren door agenten en vestigingen over de hele wereld. We hebben nu ineens met meerdere partijen te maken. Rederijen, agenten, diverse intercompany bedrijven, een kapitein die rechtstreeks afspraken maakt met de partij die uiteindelijk de goederen levert, aan de andere kant van de wereld zit, met tijdzones te maken heeft en niet alles (direkt) kan overleggen met de eigenaar van het schip etc.

Willen we uiteindelijk onze klant een Faktuur kunnen sturen, dan zullen we ons moeten baseren op de informatie die we van anderen krijgen. En uiteraard zullen zij moeten kunnen aantonen dat er ook geleverd is wat gezegd wordt dat er geleverd is. De klant zal dus moeten tekenen voor ontvangst, danwel voor de "per saldo" verbruikte hoeveelheid (waarbij retouren verrekend zijn met de leveringen). Er is dus een 'bewijs' nodig dat er geleverd is; Proof of Delivery" (P.O.D.).

Voor dit soort (Intercompany) Uitbestedingen is in het verleden al divers maatwerk ontwikkeld. Maatwerk waarmee orders als 2, 3, 4 of zelfs 5 traps raket orders kunnen worden aangemaakt en waarbij er ook veelal helemaal NIETS over de voorraad loopt; u levert immers zelf niets en de goederen die u aan uw klant faktureert zijn misschien wel nooit in het land geweest waarin u gevestigd bent; een ander heeft geleverd en stuurt u de rekening, en u stuurt die rekening (met een winstmarge) door naar uw klant. Of we nu te maken hebben met een Debiteur die iets bestelt bij een Italiaans bedrijf, welk bedrijf haar order via een europese moedermaatschappij uitbesteedt aan een leverancier in Singapore, of dat we gewoon zelf de order leveren (omdat we bijvoorbeeld europese leveringen zelf verrichten), maakt nu even niet uit...

Tussen het moment dat wij de goederen hebben geleverd en het moment dat het schip daadwerkelijk geverfd is en bekend is hoeveel er retour gezonden gaat worden kunnen enkele maanden zitten. En, al die tijd hebben wij onze klant niet kunnen faktureren, al was het maar omdat onze klant van ons één totale faktuur verwacht. Zouden we al eerder een Faktuur sturen, dan wordt ze toch niet betaald...

Financieel gezien maken we echter kosten (we raken voorraad kwijt) terwijl daar geen dekking (omzet) tegenover staat zolang we de order niet faktureren. Dit, terwijl in veel gevallen al lang bekend is hoeveel er van welk produkt geleverd is, soms ook de retouren al bekend zijn, maar het (administratieve) P.O.D. enkel nog niet ontvangen is.
N.b.: Uiteraard kan er middels diverse vormen van financieel reserven in oplossingen worden gedacht, maar al deze handelingen zijn expliciet, kunnen worden vergeten of vergens anderszins meer tijd om te automatiseren. Dus, wat we nastreven is dat alles "vanzelf" in orde komt.

Veel ellende ontstaat doordat de order nu soms te vroeg wordt gefaktureerd (om de omzet te kunnen boeken) en dan achteraf tóch blijkt dat het nèt even anders bleek te zijn. Ondertussen kan de order niet meer worden gekorrigeerd omdat ze een status "Gefaktureerd" heeft, en kunnen we de Faktuur niet meer laten vervallen "omdat de periode is afgesloten".

Een lange inleiding, maar hier is waar het nieuwe maatwerk oplossingen biedt...

Inrichting

Aktiveren maatwerk
Bij "Wijzigen Faktuurparameters Verkoop" (Hoofdmenu,F5,F5,2) vinden we op tabblad #2 een Bedrijfsparameter "Verkooporder 'open' tot Definitief Afsluiten J/N". Indien deze parameter met "Ja" wordt beantwoord zal de funktionaliteit zoals beschreven in dit topic aktief worden, en kunnen er zgn. Nep-Fakturen worden gegenereerd op basis van Bestellingen.

Nb: Zolang u zich niet realiseert wat deze funktionaliteit doet is het advies de parameter uit te laten staan!

Instellen laatst gebruikt Faktuurnummer Nep-Fakturen o.b.v. bestelling
"Nep-Fakturen" op basis van een bestelling worden in een separate Faktuurnummerrange genummerd. Nèt als met de inrichting van uw normale Faktuurnummers, geldt dat het ook voor dit soort ranges verstandig is om dit in te richten in overleg met Heart. Op die manier voorkomt u dat uw Faktuurranges te snel vol zullen lopen.

Indien "BTW Andere Landen" niet aktief is, vind u deze parameter via Hoofdmenu,F5,F5,2 op Tabblad #1.

Is "BTW Andere Landen" wel aktief, dan zal deze Faktuurrange per Aangifteland moeten worden ingesteld:

Financiële Interface LOVOTFGF
Voor het verrekenen van debet-/credit Nep-Fakturen is een Financiële Interface beschikbaar gesteld. De hier aan te koppelen Journaalpostdefinitie zal een indeling hebben in de vorm "Tussenrekening Verrekening Nep-Fakturen / Aan Debiteuren". Voor een volledige beschrijving van deze Interface zie de Interfacehelptekst via Shift+F5 bij Raadplegen Interfaces (Hoofdmenu,7,8,6,1).

Verkooporder 'open' tot Definitief Afsluiten

In de nieuwe situatie geldt dat een Verkooporder 'open' blijft staan tot dat expliciet is aangegeven dat ze 'definitief' is afgesloten. Omdat de order 'open' blijft staan, hebben we langer de tijd om haar formeel te kunnen korrigeren, waardoor korrekties die voorheen enkel via een Creditfaktuur konden lopen nu niet meer aan de orde zijn. Ook staan we toe dat een Verkooporder op ieder moment gefaktureerd kan worden, zelfs als we (administratief) nog helemaal niets geleverd hebben. Dit gebeurt met de al enkele keren genoemde zgn. Nep-Fakturen; daarover zodirekt meer.

Tevens wordt er vooraf meer inzicht gegeven (Excelsheet) in wát er precies gefaktureerd zal worden. Hierdoor wordt vooraf al visueel dat bijvoorbeeld bepaalde prijzen nog niet zijn ingevoerd, of Kommissie Ontvangers ontbreken, wat voorheen pas zichtbaar werd na het kontroleren van de reeds gegenereerde Faktuur.

Nep-Fakturen

Alvorens u het idee zou kunnen krijgen dat "Nep" etc. illegale handelingen impliceert, ... nee. Het handelt hier om het formaliseren van anders ondoenlijke werkzaamheden en procedures (voor zowel de leverancier = gebruiker van Heart-Profit, als voor de klant).
Het is aldus juist andersom : we hanteren een technische / geautomatiseerde procedure die via normale fakturen - maar die we "nep" noemen omdat ze de deur niet uitgaan - leiden tot fakturen in de meest normale vorm en die in alle statistieken en (btw) aangiftes worden meegenomen. Deze fakturen gaan de kast in en ze gaan niet naar de klant.

Het doel ervan is om te kunnen "korrigeren", in die bedrijfsprocessen die dat excessief behoeven. Dit, terwijl de klant bijvoorbeeld 1 faktuur wenst voor zijn gehele projekt. We zouden ook kunnen zeggen dat het onderhanden werk wat normaliter financieel-technish aan de orde is, nu meteen formeel wordt geboekt (en dus ook aangegeven bij de belastingen). Het doel voor de Heart-Profit gebruiker is dat de omzetten worden geboekt wanneer ze er feitelijk zijn, in plaats van vele maanden later omdat het projekt eerst volledig moet zijn afgerond (en de klant dus niet zit te wachten op al die korrigerende fakturen). De pieken (en ook dalen) die anders zouden ontstaan in het omzet- en winstverloop, worden hiermee genivelleerd.

Nepfakturen worden uiteindelijk altijd gecrediteerd. Dit gebeurt als er een korrigerende Nepfaktuur of normale faktuur wordt gemaakt. Ook als de de Verkooporder definitief wordt afgesloten zal het systeem er op toezien dat er geen Nepfaktuur achterblijft als laatste faktuur en dat het geheel wordt gladgetrokken met een laatste normale faktuur indien nog nodig (bijvoorbeeld indien er meer geleverd is dan dat er aan normale faktueren is gefaktureerd).

Voor een Verkooporder kan er op enig moment nooit meer dan 1 Nepfaktuur bestaan. Dit moet als volgt worden gezien :
Indien in maart een Nepfaktuur werd geïnitieerd van 1000 (euro etc.) maar er in April een extra Nepfaktuur van 200 is gewenst, wordt de faktuur van maart tegengeboekt ad 1000 (wat dus in/per april gebeurt) en volgt een nieuwe Nepfaktuur van 1200. Er is nu wederom maar 1 Nepfaktuur "aktief", in die zin dat de hoeveelheid in effect zijnde "Nep" altijd in de laatste Nepfaktuur wordt aangetroffen.
Zie nu verder wat er gebeurt aangaande omzet en aangiftes (etc. etc.) :
De omzet in maart was 1000 en die blijft 1000;
De omzet in april is 200, omdat er immers 1000 is gecrediteerd en 1200 is gedebiteerd.
Als nu in augustus de definitieve (normale) faktuur voor de klant wordt opgesteld, en er zou sinds april niets meer zijn veranderd, dan wordt de Nepfaktuur van 1200 tegengeboekt en een normale faktuur gemaakt van 1200. De omzet in april was en blijft 200 en de omzet in augustus is 0.

Definities / Regels / Uitgangspunten:

* Een Nep-Faktuur betreft een Faktuur die wordt gegenereerd op basis van een Bestelling;
Eigenlijk behoort er pas gefaktureerd te worden als er geleverd is, doch een verplichting is dit niet.

* Een Verkooporder wordt de éérste keer altijd gefaktureerd op basis van de Bestelling. Lees : De Nep-Faktuur bestaat altijd mits er maar wordt gefaktureerd.

* Je faktureert 'omdat je het leuk vindt'. Lees : Je wilt de omzet nemen, en faktureert dus. Maar meer dan de hoeveelheid die de Verkooporder impliceert is niet mogelijk (je kan wel later de Verkoophoeveelheid doen afnemen zonder meteen opnieuw te faktureren).

* Zodra er wordt gefaktureerd op basis van een Levering, zal altijd éérst (indien van toepassing volgens eerder genoemde Bedrijfsparameter) een Nep-Faktuur volgen die Faktureert tot aan de hoeveelheid van de Bestelling (dit is hetzelfde als het 2e punt hierboven).

* Na iedere gemaakte Faktuur (Nep of Werkelijk) volgt er automatisch opnieuw een Nep-Faktuur tot aan de hoogte van de Bestelling.

* Nep-Fakturen zijn alleen aan de orde bij Debet Verkooporders.

* Een Nep-Faktuur betreft een Faktuur die als Intern van worden gezien (blijft binnenshuis) en wordt niet naar de klant verzonden.

* Bij het genereren van een nieuwe (nep) Faktuur zal de laatste Nep-Faktuur voor 100% worden gecrediteerd.

* Een Nep-Faktuur wordt nooit een echte Faktuur; wel kan er een Echte-Faktuur worden gegenereerd die gepaard gaat met een creditering van de eerdere Nep-Faktuur.

* Als een order Definitief wordt Afgesloten zal het saldo van de Nep-Fakturen nul (0,00) zijn; er zijn nu alleen "echte" Fakturen.

* Logistiek wijzigt er niets.

Uitsluitingen

Deze tekst zal aan wijziging onderhevig zijn :

Vooralsnog zijn "Nep-Fakturen" uitgesloten voor Landkode "Italië"; dit met als enige reden "omdat het niet gewenst was" en derhalve niet ontwikkeld is.

Uiteraard zouden we ook kunnen zeggen "voor een Italiaans Bedrijf moet je de parameter maar niet aanzetten", maar, omdat vanwege diverse geldende afwijkende Italiaanse regels nu kan gesteld kan worden dat de werking voor Italië extra aandacht vergt, en aangezien die aandacht nog niet besteed is, is e.e.a. voorlopig hard geblokkeerd.

Denk hierbij aan de volgende te ondervangen - c.q. nog goed op degelijkheid te kontroleren aspekten:

Spese Bolli
Als er in Italië geen BTW wordt berekend over een binnenlandse levering, wenst de Italiaanse fiscus toch een soort belasting te innen, dit in de vorm van een 'Spese Bolli belastingzegel', die we natuurlijk niet op onze 'Nep-Fakturen' zullen plakken als die niet verzonden worden.

BTW Vrijstellingen
Zullen vast niet van toepassing zijn op 'Nep-Fakturen', aangezien deze niet naar de klant verzonden worden.

BTW registers
Aangiftes van Uitgaande- en Inkomende Fakturen vinden plaats in een Italiaans BTW register (V1, V2, V3, A1 t/m A5 etc.)
Wat te doen met de 'Nep-Fakturen'? In Italië hebben ze er géén register voor...
We zouden de Fakturen achterwege kunnen laten, maar dan zou de omzet die we kreëeren niet worden aangegeven in de aangifte.

Italië derhalve niet; het is niet nodig.

Voorbeeld 1

Laten we eens het eerder genoemde (1000 <> 1200) voorbeeld in een konkreet voorbeeld toepassen. Merk op dat dit in zoverre lastig als voorbeeld te reproduceren is, omdat ik niet vandaag een Verkooporder kan genereren met een ordernummer uit maart, dus, daar moeten we maar even doorheen kijken. Ook is mijn voorbeeld meteen wat complexer omdat het ontwerp 'Nep-Fakturen' hier meteen is gekombineerd met 'Kommissie Reserveringsfakturen via een Interne Creditfaktuur' (zie topic http://ha1.heartprofit.nl/profit/index.php?topic=27941.0).

Let op:
Binnen het bedrijf waarin dit maatwerk geaktiveerd is, geldt dat Nep-Fakturen voor iedere Verkooporder werken. En, vooralsnog óók nog eens verplicht, of we nou zonder kunnen of niet. Hierbij is het plan om op een later tijdstip te gaan bepalen voor welke situaties e.e.a. wel/niet nodig is, en die situaties òf helemaal uit te sluiten òf instelbaar uit te kunnen sluiten van het werken met Nep-Fakturen. Vooralsnog geldt dat e.e.a. voor iedere Verkooporder werkt.
Voorbeeld 1 betreft nu een eenvoudig voorbeeld waarbij de Nep-Fakturen worden uitgelegd, maar, betreft een situatie waarvoor deze Nep-Fakturen eigenlijk niet aan de orde zouden hoeven te zijn; immers, de Nep-Fakturen zijn ontstaan vanuit de situatie dat we niet kúnnen faktureren omdat er teveel partijen bij betrokken zijn die administratieve verwerkingstijds nodig hebben en we eerst op een P.O.D. moeten wachten, terwijl als we zélf leveren in de haven van Rotterdam, dit niet aan de orde is. Het voorbeeld (welke al gemaakt was voordat deze alinea werd opgenomen) laten we staan.

Toevoegen Verkooporder
Om het topic niet onnodig lang te maken, hier geen schermprints. We gaan ervanuit dat als we hier vermelden dat we een Verkooporder toevoegen waarbij we 10 Verschijningen van een produkt verkopen in een 20 liter blik met een prijs van USD 5,- per Liter, iedereen weet wat we daarmee bedoelen. Ook geldt dat in dit geval een Agent 12,5% Kommissie krijgt over deze order.

Het is half maart, en de order wordt uitgeleverd.
Eind maart willen we onze omzet boeken, welke op dit moment 1000,- betreft (in USD in dit voorbeeld).

Genereren Faktuur
Uitgangspunt is dat iedere Verkooporder separaat wordt afgehandeld en gefaktureerd. Vanuit Raadplegen Verkooporders is in het Shift+F8 menu een optie "X" (Raadplegen te Faktureren Verkooporderregels) opgenomen. Vanuit deze funktie kunnen we status (en de faktureerbaarheid) van de order opvragen op basis van de Bestelling, danwel op basis van de Leveringen.
Deze menu optie komt eerst met een submenu die ons vraagt of we op basis van de Bestelling willen faktureren (dat leidt (dus) tot een Nep-Faktuur) òf dat we een échte Faktuur op basis van een Levering willen genereren.

De 2e keuze zal op dit moment tot een foutmelding leiden, immers, een van de regels is "dat een Verkooporder de eerste keer altijd op basis van de Bestelling wordt gefaktureerd". We kiezen derhalve voor optie #1.

Keuze #1 of #2 leiden beiden tot het scherm "Raadplegen te Faktureren Verkooporderregels", echter, roepen het scherm in een andere 'modus' aan. Omdat we nu keuze #1 (o.b.v. bestelling) hebben gedaan staat rechts in de kop boven het Grid "Faktureren o.b.v. Bestelling" en is de data die getoond wordt op basis van de bestelde hoeveelheden; zouden we het scherm (later) aanroepen op basis van levering, dan toont de kop "Faktureren o.b.v. Levering" en worden de geleverde hoeveelheden getoond.

In de kop boven het Raadpleegoverzicht vinden we o.a. het Verkoopordernummer, het Afleveradres, de Raapvloer van waaruit geleverd moet worden, en de Debiteurgegevens, opgesplitst naar de Debiteur van de Verkooporder (aan wie wordt geleverd), de Groepsdebiteur (welke rederij is de eigenaar van het schip), en de Faktuurdebiteur (naar wie sturen we de Faktuur).
De Administratie Code wordt getoond omdat deze wordt gebruikt om het IMO nummer van het schip in te vermelden. Op die manier kan de gebruiker op voorhand al zien of de order wel op het juiste schip is ingevoerd, en we niet toevallig te maken hebben met een ander schip met dezelfde naam.

De regels van het Grid vertellen ons welke produkten er besteld zijn, hoeveel Verschijningen, welke Inhoud, hoeveel Verschijningen er Retour gezonden zijn, hoeveel eenheden er per saldo besteld zijn, wat de prijs per eenheid is, wat vervolgens de regelprijs is, hoeveel daarvan al gefaktureerd is, en hoeveel omzet we nog kunnen faktureren uit deze order. De som van alle faktureerbare regels wordt boven in de kop vermeld.

Specifikatie in Excel
In de Raadpleegfunktie tonen we weliswaar een aantal gegevens, maar, er kan nog veel meer informatie van een order getoond worden waarmee we op voorhand 'fouten' kunnen konstateren in de order. Fouten, die als we ze op voorhand korrigeren, we achteraf niet aan het crediteren hoeven te slaan, simpelweg omdat we erg voor gaan zorgen dat de faktuur geen fouten bevat. Met behulp van funktietoets F6 kan er een specifikatie in Excel worden opgevraagd.

Nb: De Excelsheet is in de Engelse taal opgesteld.

De Excelsheet bestaat wederom uit een header met daarin een opsomming van een aantal gegevens van de Verkooporder. Een van de aanvullingen t.o.v. wat er in het Grid wordt getoond is dat hier ook de koers van de betreffende Valutakode wordt vermeld, en áls de order is uitbesteed aan een andere Leverancier, dan zal hier die Leverancier en het Inkoopordernummer worden getoond waarmee de produkten bij die Leverancier zijn ingekocht.

De Excelsheet toont vervolgens twee series met Verkooporderregels:

- In het geel de data gebaseerd op de bestelling;
- In het groen de data gebaseerd op de daadwerkelijke levering.

Uit de Excelsheet kunnen we wederom halen dat er 10 Verschijningen van 20 Liter = 200 Liter besteld is.
De prijs bedraagt USD 5,- / L en zorgt derhalve tot een regelprijs van USD 1.000,-.
De koers van de USD bedraagt 0,9390 en derhalve leidt deze USD 1.000,- tot een omzet van EUR 939,-.

Vervolgens wordt er een kostprijs getoond van 3,80/L. Kostprijsgegevens zijn altijd in de bedrijfsvaluta, dus, deze prijs bedraagt EUR 3,80/L (omdat in ons voorbeeld ons bedrijf in EUR is ingericht). Direkt ná de kolom "Costprice/Unit" een kolom "Org" welke de herkomst van deze prijs bevat. Hier zijn de volgende kombinaties mogelijk:

POL Purchaseorderline, ofwel, Inkooporderregel. Treedt op indien u de Verkooporder niet zelf levert, maar de order is uitbesteedt aan een andere (Intercompany) Leverancier. De prijs die op die Inkooporderregel is ingevuld zal de kostprijs bepalen voor deze Verkooporderregel.

SOL Salesorderline, ofwel, Verkooporderregel. Kan bijv. aan de order zijn als een kostprijs door een Verkooporderregel wordt bepaald (bijv. bij Diensten).

ICP Intercompany Costprice Pricelist; de ICP prijs. Een Prijslijst welke via een Bedrijfsparameter kan worden ingevuld en welke (afhankelijk van een periode) de prijzen bevat waarvoor een produkt Intercompany aan zusterbedrijven wordt verkocht.

ITM Item; het Artikel. Indien de prijs niet op een van bovenstaande wijzen kon worden bepaald, zal als laatste de Effektieve Kostprijs van het Artikel worden opgehaald om toch "iets" als kostprijs te kunnen tonen. Zouden we standaard 0,00 weergeven dan zouden we wellicht onterecht kunnen bedenken dat de marge op deze order toereikend is waar we in werkelijkheid verlies maken.

In het groene blok zal deze kolom altijd zijn gevuld met de waarde:

DEL Delivery; Levering. De werkelijke kostprijs van een levering wordt bepaald door de kostprijs van de geleverde Charges; de waarde van de voorraad die geleverd is.

De kostprijs per eenheid leidt tezamen met de hoeveelheid eenheden weer tot de totale kostprijs, en als die tegen de omzet wordt afgezet, resulteert daaruit de marge op deze Verkooporderregel. Deze marge wordt ook weer als percentage weergegeven.

Vervolgens wordt getoond hoeveel er al gefaktureerd is, en wat er (dus) nog te faktureren valt, exclusief btw + vermeerderd met de eventuele btw die over de order verschuldigd is. Leveringen aan schepen zijn in dit geval vrijgesteld van btw, dus de btw is in dit voorbeeld niet aan de orde.

In het Excelrapport worden verder Artikelregels separaat vermeld t.o.v. Kosten-/Diensten.
Kosten en Diensten zijn normaliter doorbelastingen van bedragen die optreden, en waar we niet noodzakelijk iets aan hoeven te verdienen.
Bij een Dienst kan een kostprijs zijn ingevoerd (bij de Verkooporderregel), bij Kosten kan dit niet.
Dit zijn aldus redenen om de Artikelen (waar we het geld mee verdienen) separaat te houden van Kosten/Diensten.

In het Excelrapport staat -indien dat zo is- ook vermeld dat er een Agent is die Kommissie krijgt over deze order. Dit kommissiebedrag wordt tussen na het Subtotaal nog in mindering gebracht, opdat we een nog beter beeld krijgen omtrent de marges in deze order. Mocht het er op neer komen dat we geen winst maken op een order, dan kunnen we ons afvragen of de prijzen allemaal wel juist zijn ingevoerd.

LET OP : De opgenomen/onderkende kostencomponenten (waarvan zojuist enkele voorbeelden genoemd) zijn verre van uitputtend. Bijvoorbeeld, indien een verkooporder een doorbelasting voor vrachtkosten toont, maar niet de vrachtkosten zelf, dan houdt het niet in dat de vrachtskosten niet als kosten drukken op de verkoopoorder. Dit geldt voor de werkelijkheid buiten de verkooporder om (vervoerder belast niet per verkooporder) maar dit geldt voor de context in deze vooral voor het niet onderkennen van bijvoorbeeld DKK's waarmee de vrachtkosten wel degelijk kunnen zijn aangerekend als kosten.
De moraal in deze is dat er indikaties zijn gegeven om tot een idee te komen dat de faktuur juist zal zijn dan wel totaal verkeerd moet zijn, met verder de gedachte dat er in deze best meer kan worden ontwikkeld. Het geeft in elk gevaal een idee van de mogelijkheden.

Met de rubrieken Prijs/eenheid en Kostprijs/eenheid kunnen we wat spelen in Excel in de Excelsheet zelf. Dus, als we toch hiermee bezig zijn (het beoordelen van het resultaat van een aanstaande fakturering) dan kunnen we meteen ook wel kijken hoe het resultaat wordt beïnvloed door het veranderen van een Prijs e.d.; Een "voorwaardelijke opmaak" in Excel zorgt ervoor dat een regel automatisch "rood" kleurt indien de verkoopprijs <> kostprijs tot een negatieve marge leidt.

Faktuur genereren
Een van de regels is "Faktureren doe je 'omdat je het leuk vindt'". Hiermee bedoelen we dat we zélf bepalen dát we nu gaan Faktureren. Willen we (nog) niet faktureren, prima, dan doen we dat gewoon niet. Overigens kunnen we wel altijd deze funktionaliteit aanroepen om de status van de order (en meer) te bekijken. Maar... voor nu geldt dat wij in maart goederen hebben geleverd, hier een omzetwaarde in zit van USD 1.000,- en we deze omzet willen boeken (in maart), en dus gaan we faktureren... Dat doen we met toets F4.

We genereren de Faktuur met een Faktuurdatum van maart. In een kommentaarregel vul ik in dat het om een nep-faktuur gaat, dan herkennen we deze straks makkelijker terug. Er wordt een Faktuur gegenereerd en we keren terug in het Raadpleegoverzicht, waarin de status nu zodanig is aangepast dat er niets meer te faktureren valt; ons hele orderbedrag van USD 1.000,- is gefaktureerd.

Ondanks dat we al geleverd hebben, en we het volste recht zouden hebben om alvast een échte Faktuur te sturen, doen we dat nu niet. Hier kunnen meerdere redenen voor zijn, maar, de meest voorkomende zal zijn dat de klant één Faktuur eist waar alle leveringen en retouren kompleet op staan. De zojuist gegenereerde Faktuur is een zgn. 'Nep-Faktuur'. Nep-Fakturen worden genummerd in een separaat instelbare Faktuurnummerrange, zie het kopje 'Inrichting'. In dit voorbeeld beginnen de Nep-Fakturen met een 9.

De Faktuur betreft een 'Interne' Faktuur en zal niet naar de klant worden verzonden.
Let op : Dit màg ook niet, omdat de procedures in consistentie met elkaar zijn en waarop de programmatuur anticipeert. Klein voorbeeld : als per abuis (of expres) de Nep-Faktuur naar de klant wordt gestuurd, zal een volgende Creditering daarvan eveneens naar de klant moeten worden gestuurd, anders snapt deze het niet meer. Ook geldt dat Nep-Fakturen kunnen bestaan met daarop gegevens die niet bedoeld zijn voor de klant om kennis van te hebben.

In april komt er nog USD 200,- aan omzet bij als gevolg van een nieuwe Verkooporderregel die is toegevoegd aan de order. Merk op dat normaliter de Verkooporder a.g.v. de éérste Levering al een status "L" zou hebben en we geen regels meer zouden mogen toevoegen (order was volledig geleverd). De order Faktureren zou er al helemaal voor zorgen dat we geen regels meer mogen toevoegen. Maar, zie de eerder genoemde parameter - met dit maatwerk blijft de Verkooporder 'open' staan tot ze definitief wordt afgesloten en dus mogen we nieuwe regels toevoegen aan de order. In dit voorbeeld zijn er nog 5 blikken x 5 liter x USD 8,-/L = USD 200,- verkocht, welke meteen zijn geleverd (in april).

Als we nu naar "Raadplegen te Faktureren Verkooporderregels" gaan (op basis van de bestelling), dan zien we dat we "plots weer" USD 200,- kunnen faktureren.
Nb: Wellicht moet u onderstaande afbeelding iets naar rechts scrollen om in de rechterkolommen in het Grid te kunnen zien dat er USD 200,- te faktureren is.

Met toets F4 kunnen we wederom een Faktuur genereren; USD 200,- voor de omzet in april.
(n.b.: òf u dit doet is aan u; gebeurt het nu niet, dan blijft de "te faktureren" staan tot een volgende keer, waarna er desnoods wederom 300 is bijgekomen en nu een extra te faktureren bedrag van 500 zal opleveren)

"Raadplegen te Faktureren Verkooporderregels" (de Shift+F8 + X Funktie) biedt naast toets F4 om te faktureren nog veel meer mogelijkheden. Een van die mogelijkheden is dat we m.b.t. Shift+F4 naar "Raadplegen Fakturen van Verkooporder" kunnen gaan. Die funktie toont ons alle Fakturen die uit deze Verkooporder zijn gegenereerd; Nep-Fakturen, echte Fakturen maar ook bijvoorbeelde de Kommissie Reserveringsfakturen. Zo toont Shift+F4 op dit moment:

We zien nu 2 setjes van ieder 3 fakturen. De Fakturen die met een 9 beginnen zijn de 'Nep-Fakturen' waar het in dit topic om gaat. De Fakturen die met een '8' beginnen zijn Kommissie Reserveringsfakturen (zie http://ha1.heartprofit.nl/profit/index.php?topic=27941.0). Voor dit topic zijn de "9" Fakturen van belang.

Met Faktuurnummer 9000073 herkennen we de eerste Nep-Faktuur van USD 1000,- in maart.

In april hebben we één Faktuur gegenereerd, maar... we zien er twee! (9000074 en 9000075).

Zoals eerder uitgelegd wordt bij het genereren van een nieuwe (nep) Faktuur de laatst gegenereerde Nep-Faktuur voor 100% tegengeboekt; op die manier bestaat er op enig moment maximaal één aktieve Nep-Faktuur. In de maand maart hadden we een Nep-Faktuur van USD 1.000,-. Nu we in april weer gaan faktureren wordt éérst de USD 1.000,- tegengeboekt (dat doen we in de maand april) en wordt vervolgens een nieuwe Nep-Faktuur gegenereerd tot aan de Bestelling (USD 1.200,-). Per saldo hebben we nu over de maand april +1200 -1000 = USD 200,- gefaktureerd (en hebben we in maart USD 1.000,- gefaktureerd). Merk op dat in de kommentaarregel van Faktuur 9000074 staat vermeldt dat dit een Automatisch Creditering betreft van Faktuur 9000073.

Let op : Als we het hebben over "op die manier bestaat er op enig moment maximaal één aktieve Nep-Faktuur" (zoals in voorgaande alinea) dan geldt dit per Faktuur-range. Dus, de "9" fakturen hebben zo'n laatste aktieve Nep-Faktuur, maar de "8" fakturen hebben dit eveneens (in dit geval met waarde -150). Dit dus voor de - en per die ene Verkooporder !

We slaan nu even een paar maanden over en zitten dan in augustus. Het P.O.D. (Proof of Delivery / bewijs van levering) wordt ontvangen, en alles blijkt te zijn ontvangen zoals wij dat geleverd hebben; er verandert verder niets. We gaan nu de échte Faktuur opmaken. Dit doen we wederom vanuit de Shift+F8 / X funktie, maar kiezen daarbij nu voor de menukeuze 'op basis van Leveringen'. In het kader boven in het scherm is zichtbaar dat we nu gaan 'Faktureren o.b.v. Leveringen'.

In totaal hebben we USD 1.200,- (écht) te faktureren, waarvan nog niets (écht) gefaktureerd is. Wederom gebruiken we toets F4 om de Faktuur te genereren, welke (in dit voorbeeld) direkt leidt tot een Foutmelding:

De Verkooporder is als zgn. 'DryDock' order geregistreerd (rubriek "Komt Retour J/N" op Verkooporderheader niveau staat op "Ja"), en in geval van Drydock geldt dat we altijd formeel moeten bevestigen dat de Verkooporder mag worden gefaktureerd. En, opdat we niet de funktionaliteit "Raadplegen te Faktureren Verkooporderregels" hoeven te verlaten, is het middels toets Shift+F5 mogelijk om de Verkooporder goed te keuren voor Fakturatie.

Goedkeuren Verkooporder betreft overigens een separate Funktie, die als gevolg daarvan dus ook separaat geautoriseerd kan worden; indien gewenst kunt u instellen dat bepaalde Gebruikers geen rechten hebben om Verkooporders goed te kunnen keuren voor Fakturatie.

Na de Verkooporder te hebben goedgekeurd voor Fakturatie gaan we alsnog weer met F4 een Faktuur genereren; een échte dus weer, immers we doen het op basis van de Leveringen. In totaal hebben we een bedrag van USD 1.200,- te faktureren.

De regel bij het genereren van een nieuwe (echt of Nep) Faktuur is weer dat we éérst de laatste Nep-Faktuur voor 100% tegenboeken, en dus volgt er eerst een Automatische Creditfaktuur 9000076 die per 21/8 de Nep-Faktuur van april tegenboekt. Vervolgens volgt (eveneens op 21/8) de échte Faktuur van (eveneens) USD 1.200,-. Echte Fakturen worden in dit voorbeeld genummerd in de 5 range, en daarmee staat deze Faktuur bovenaan in het overzicht.

Na april was er niets meer gebeurd, en ook financieel gebeurt er nu feitelijk niets in augustus. We hebben in augustus weliswaar USD 1.200,- omzet uit een échte Faktuur (5066956) maar tevens is in augustus de Nep-Faktuur van april (ad USD 1.200,-) gecrediteerd middels Nep-Faktuur 9000076 zodat deze per saldo tegen elkaar wegvallen.

Hoewel we diverse fakturen hebben gegenereerd die we als 'nep' betiteld hebben, zien we dat er aan het einde van de rit niets raars aan de hand is. De klant heeft (in augustus) zijn faktuur gekregen voor USD 1.200,- maar wij hebben die omzet administratief verwerkt per de periode waarin ook de kosten (inkoop) zijn ontstaan. Aan het einde van de rit geldt dat we

in maart USD 1.000,- aan omzet hebben
in april USD 200,- aan omzet hebben
in augustus USD 0,- aan omzet hebben.

Nb: Merk hierbij wel op dat de kostprijzen die in maart en april zijn geboekt voorgekalkuleerde kostprijzen betreffen, en pas in augustus de werkelijke kostprijs bekend is. Ondanks dat er in augustus geen omzet wordt geboekt (+ 1200 en -1200 is per saldo 0,00) zal er uit een eventueel verschil in kostprijs alsnog een marge kunnen volgen.

Kijken we naar de omzetbelastingaangifte van augustus:

dan volgt ook daar uit dat er per saldo niets wordt aangegeven in de maand augustus.

Vanuit "Raadplegen Fakturen van een Verkooporder" hebben we vervolgens twee toetsen:

waarmee we de Faktuur kunnen printen en waarmee we de Faktuur als "verzonden" kunnen registreren (het al dan niet markeren van Fakturen als 'Verzonden' betreft bestaande funktionaliteit welke aan een separate bedrijfsparameter is opgehangen; zie verder Releasenote http://ha1.heartprofit.nl/profit/index.php?topic=27801.0).

Definitief Afsluiten

Eerst even dit : Ook al hebben we nu een Echte Faktuur gemaakt en dus (!) ook naar de klant gestuurd, niets weerhoudt ons ervan om hierna nog weer nieuwe Verkooporderregels toe te voegen, hoeveelheden op bestaande Regels te doen toenemen en het hele proces opnieuw te laten beginnen, net uiteraard wederom een Nep-Faktuur (waarvan het salso - c.q. de "Aktieve" op dit moment 0.00 is (niet bestaat)).
We gaan er vanuit dat eens de Verkooporder naar tevredenheid kan worden afgesloten, en dan krijgen we dit :

Als laatste stap gaan we de Verkooporder "Definitief Afsluiten". Dit doen we vanuit "Raadplegen te Faktureren Verkooporderregels" (de Shift+F8 / X funktie) m.b.v. funktietoets Control+F5.

Definitief Afsluiten zorgt er voor dat alle eventueel nog openstaande Verkooporderregels worden afgesloten, en zorgt er voor dat er geen nieuwe regels meer aan deze Verkooporder kunnen worden toegekend. Mocht er nog een eventuele Nep-Faktuur open staan, dan wordt deze automatisch gecrediteerd per de opgegeven 'Datum Afsluiting'. Definitief Afsluiten zal de Verkooporder op status "F" zetten. Middels onderstaande melding wordt bevestigd dat de Verkooporder Definitief is Afgesloten:

Nb: Er is niet expliciet funktionaliteit ontwikkeld om het Definitief Afsluiten weer ongedaan te kunnen maken. Het uitgangspunt is op dit moment dat we met de hier beschreven funktionaliteit op voorhand voldoende mogelijkheden hebben om te kunnen zien of de order korrekt is alvorens we deze definitief afsluiten. Ook geldt dat waar voorheen een order in een status 'afgesloten' terecht kwam omdat iemand de order ging faktureren nog vóór ontvangst van het P.O.D., dit nu niet meer nodig is, immers, in zo'n geval genereren we nu een 'Nep-Faktuur', en nog niet direkt de eindafrekening. Hoewel er niets expliciets voor ontwikkeld is, geldt wel dat het verwijderen van de échte Faktuur de Verkooporder weer zal terugzetten op een status "L".
In alle geval geldt dat als de status "Definitied Afgesloten" is ingetreden, alles nog net zo kan worden gemanipuleerd als voordat de hier beschreven funktionaliteit bestond; uiteraard nauwelijks "flexibel" maar in elk geval onveranderd aanwezig.

Overigen

Kostprijs bij Faktuur o.b.v. Bestelling
Als we faktureren op basis van een bestelling dan hoéven we in theorie nog niet alles geleverd te hebben. De daadwerkelijke kostprijs hoéft daarmee niet bekend te zijn. Toch zal onze (Nep-) Faktuur de Statistieken in gaan en zal daar een kostprijs bijhoren. Als Kostprijs voor dit soort Fakturen wordt de kostprijs gehanteerd waarvoor het produkt Intercompany met zusterbedrijven wordt verhandeld; de ICP prijs.

Aanmaningen
De Interne (Nep-) Fakturen zullen niet worden meegenomen in het Aanmaningen trajekt. Immers, de fakturen werden niet naar de klant gestuurd en bleven intern (ze gaan meteen de kast in). We kunnen moeilijk onze klant gaan aanmanen voor fakturen waarvan op voorhand bekend is dat we die fakturen niet naar de klant toesturen. Omdat bekend is dat soms ook de Ouderdomsanalyse Debiteuren als print wordt gebruikt om naar een klant te sturen, is die funktie uitgebreid met een optie 'Inclusief niet verzonden Fakturen J/N'. Daarmee kan de gebruiker zelf bepalen of ze het overzicht voor zichzelf genereert (en de niet verzonden fakturen er wél op wil hebben) òf dat ze het overzicht voor een klant gebruikt (en de niet verzonden fakturen er niet op wil hebben.

Altijd ter hoogte van de bestelling
Of en wanneer we gaan faktureren bepaalt u zelf, maar zodra er gefaktureerd wordt, geldt dat we altijd Nep-Fakturen hebben ter hoogte van de bestelling, óók al zouden we zónder kunnen; dit is zo bepaald en is bedoeld voor "kontrole procedures" en het erop kunnen bouwen dat ieder fakturatie-trajekt op dezelfde wijze heef plaatsgevonden. Bijvoorbeeld, als we in een willekeurige Verkooporder geen Net-Fakturen aantreffen, dan kunnen we er 100% zeker van zijn dat er domweg nog niet is gefaktureerd. Maar ook : dat als dat wel zo is, het systeem (deze funktionaliteit) ergens faalt. Kortom, er mag nimmer onduidelijkheid bestaan, óók niet of de Faktuur nu bij de klant ligt of niet. Voor alle Verkooporders geldt (bij het aan hebben van de in het begin genoemde Bedrijfsparameter) dus precies dezelfde procedure. Dus als we eigenlijk geen reden hebben voor Nep-Fakturen voor een betreffende klant of soort Verkooporder, gebeurt er minimaal dit :

Stel dat we in mei een order krijgt voor EUR 1.000,-, deze ook in mei leveren en faktureren en we tevens de échte faktuur gaan opmaken in mei, dan zullen we alsnog drie fakturen krijgen:

1. een Nep-Faktuur t.w.v. EUR 1.000,-
2. een Credit-Faktuur die bovenstaande Nep-Faktuur tegenboekt
3. een Echte Faktuur t.w.v. EUR 1.000,-

Faktuur 1 & 2 heffen elkaar per saldo op, ook nog in dezelfde maand, en zijn daarmee feitelijk zinloos. Toch worden ze gemaakt, omdat de regel is dat we dat altijd zo doen.

Er is nog een klein verschil (een voordeel !) als we eigenlijk de funktionaliteit niet wensen te gebruiken voor een betreffende Verkooporder, terwijl het standaard dus toch gebeurt, en dat is deze :

We plaatsen voor 1.000,- op de Verkooporder;
1. We faktureren een Echte Faktuur en de 1.000,- nep die daardoor ontstaat wordt meteen tegengeboekt;
2. De Echte Faktuur ad 1.000,- ontstaat;
(tot zover hetzelfde als het voorgaande voorbeeld, doch iets anders uitgeschreven)
We voegen nog t.w.v. 200,- extra toe aan de Order (immers, dit is toegestaan zolang de Order niet formeel is afgesloten);
3. We faktureren nogmaals een Echte Faktuur (zonder deze funktionaliteit niet mogelijk) waardoor weer een Nep-Faktuur van 200,- ontstaat die meteen wordt tegengeboekt en wordt gevolgd door
4. de echte faktuur ad 200,-.
Faktuur 1 en 3 zijn nu zinloos. Echter, last ervan hebben we niet echt want het gebeurt onder water en automatisch, maar het voordeel wat we er van kunnen hebben is dat we alle Nep-Fakturen qua Statistieken zouden kunnen opvragen. Immers, alleen daarin bevindt zich onze volledige omzet ... (zie ook Kommissie funktionaliteit).

Misschien niet voor Italië, maar raakt Italië wel degelijk!

Onder het kopje Uitsluitingen hebben we aangegeven dat dit maatwerk nog even niet aktief is voor Italië, dit, omdat als we daar met dergelijke "Nep-Fakturen" gewerkt gaat worden, er nog diverse zaken uitgezocht moeten worden. Hoe wil je bijvoorbeeld een Faktuur voor de belastingaangifte wél in een BTW Register opnemen, als ze daarin per Faktuurregister gespecificeerd moeten worden en niemand kan vertellen in welk Register dat dan zou moeten...

Toch heeft dit maatwerk wel degelijk raakvlakken met orders die vanuit Italië getriggerd worden: Intercompany Uitbesteding, vanuit Italië.

We onderkennen daarbij drie soorten orders:

1. Drie-trapsraket
Italië verkoopt iets aan een klant, besteedt de order uit aan Nederland, die vervolgens levert aan de klant van Italië. Deze situatie zou optreden indien het Italiaanse zusterbedrijf een order heeft voor een schip welke in de haven van Rotterdam ligt.

We noemen dit een drie-trapsraket omdat er 3 orders bij ter sprake zijn:
1. Een Verkooporder in Italië aan de Italiaanse klant
2. Een Inkooporder in Italië bij het zusterbedrijf in Nederland
3. Een Verkooporder in Nederland aan het zusterbedrijf in Italië, doch met Afleveradres van de Italiaanse klant (in dit geval: de haven in Rotterdam)

2. Vier-trapsraket
Italië verkoopt iets aan een klant in een gebied waar zij niet over gaat, danwel geen kontakten en Prijsafspraken heeft met Leveranciers. De Order wordt uitbesteed aan een Leverancier van de moedermaatschappij in Nederland (die kontakten onderhoud met Leveranciers over de hele wereld). Een voorbeeld zou zijn dat het Italiaanse Bedrijf een Verkooporder heeft aan een schip welke in Singapore ligt. Omdat Italië geen kontakten onderhoud met Leveranciers in Singapore, besteedt zij de order uit aan Nederland, waarna in Nederland de order weer wordt uitbesteedt aan de Leverancier (in Singapore).

We noemen dit een vier-trapsraket omdat er 4 orders bij ter sprake zijn:
1. Een Verkooporder in Italië aan een Italiaans schip welke in Singapore ligt
2. Een Inkooporder in Italië bij het zusterbedrijf in Nederland
3. Een Verkooporder in Nederland aan het zusterbedrijf in Italië
4. Een Inkooporder in Nederland bij een Leverancier in Singapore (die rechtstreeks aan de klant van Italië moet leveren)

3. Vijf-trapsraket
Vergelijkbaar met de 4 trapsraket, echter nu is die Leverancier nog weer een ander Intercompany Bedrijf welke in Profit geregistreerd is.
Zo is er bijvoorbeeld ook een Turks bedrijf aan de orde, welke ook administratief in Profit wordt verwerkt.
Indien Italië verkoopt aan een Italiaans schip welke in een haven in Turkije ligt, dan geldt dat Italië het produkt uitbesteedt aan Nederland, en Nederland op haar beurt weer aan Turkije.
Precies zoals bij de vier-trapsraket, echter dáár eindigt de lus bij een Inkooporder (bij de Leverancier in Singapore) terwijl er nu nog een Verkooporder vanuit een Intercompany bedrijf bij komt.

We noemen dit een vijf-trapsraket omdat er 5 orders bij ter sprake zijn:
1. Een Verkooporder in Italië aan een Italiaans schip welke in Turkije ligt
2. Een Inkooporder in Italië bij het zusterbedrijf in Nederland
3. Een Verkooporder in Nederland aan het zusterbedrijf in Italië
4. Een Inkooporder in Nederland bij Turkije
5. Een Verkooporder in Turkije aan Nederland (met als Afleveradres de klant van Italië)

In alle bovengenoemde situaties zal Italië altijd degene zijn die haar eigen klant faktureert.
In alle bovengenoemde situaties zal Italië inkopen bij Nederland, waaruit volgt dat Nederland verkoopt aan Italië.

De viertrapsraket vormt hier een bijzondere situatie. Zowel bij de drietrapsraket als bij de vijtrapsraket levert er een bedrijf welk in Profit geadministreerd wordt. Hierbij zullen we eerder er op mogen vertrouwen dat als wij 100 Verschijningen geleverd hebben er ook 100 zullen zijn aangekomen. Bij de viertrapsraket (Singapore order) geldt dat wij volledig afhankelijk zijn van wat er op het P.O.D. staat, immers, de goederen worden door een Leverancier van het Nederlandse Bedrijf geleverd, terwijl de goederen zelf nooit in- of via Nederland zullen lopen.

Een van de standaard mogelijkheden bij Profit-Intercompany is dat ook de afhandeling van de Fakturatie Intercompany kan worden verwerkt. Als Nederland verkoopt aan Italië dan is het niet alleen zo dat Nederland een Verkooporder heeft aan Italië en Italië een Inkooporder heeft bij Nederland, nee, ook kwa Fakturen geldt dit. Het zou onnodige tijd van de Gebruiker kosten als een faktuur die Nederland aan Italië stuurt, in Italië handmatig ingeboekt zou moeten worden; en dus kan dit geautomatiseerd. De Uitgaande Faktuur van Nederland kan in Italië automatisch leiden tot de registratie van een Ingekomen Faktuur.

Maar ja... wat dan nu met Nep-Fakturen waarvan we hebben gesteld dat we niet weten hoe dit dan in Italië met haar regelgeving zou moeten werken? Gelukkig, géén probleem. Immers, van Nep-Fakturen hadden we gesteld dat deze niet naar de klant werden gestuurd, en *dus* dan ook niet naar ons Italiaanse zusterbedrijf. Nep-Fakturen blijven dus intern en kunnen daarmee ook op orders van een Intercompany Bedrijf worden toegepast.

Wat verandert er verder?
In topic http://ha1.heartprofit.nl/profit/index.php?topic=25130.0 kunnen we lezen hoe dit Singapore maatwerk bedoeld was. Er zijn vier orders ter sprake die alle vier synchroon lopen kwa regels. De ketting van vier orders kan zowel aan het begin (de Verkooporder in Italië aan de Italiaanse klant) worden gewijzigd, als mede aan het einde van de ketting (de Inkooporder in Nederland bij de Leverancier in bijv. Singapore). Bedenk hierbij dat het schip in Singapore ligt, en de kapitein van het schip weer kontakt kan hebben met Leverancier aldaar, en op het laatste moment bepaalt dat hij òf meer, òf minder òf iets anders wenst te hebben. Zolang er nog geen Pakbon getekend retour is gekomen (= Proof of Delivery), staan alle orders 'open' en kan er van alles gewijzigd worden. Meestal gebeurt dit pas aan het einde zodra het P.O.D. wordt ontvangen, immers, dan blijkt dat onze Leverancier méér heeft geleverd dat er in eerste instantie besteld was, en de kapitein ook heeft getekend voor ontvangst van dat surplus. Op dat moment wordt de Inkooporder bij de Leverancier (Singapore) gelijk gemaakt aan wat er op het P.O.D. staat en kan de order als 'geleverd' worden geboekt. Vanaf dát moment worden de hoeveelheden die op dát moment op de order staan (en die dan geacht worden gelijk te zijn aan het getekende P.O.D.) in alle 4 orders als 'geleverd' geregistreerd, en kan er gefaktureerd worden.

Maar ja... zoals ook in het eerdere voorbeeld kan het maanden duren voordat dat P.O.D. ontvangen wordt, en al die tijd kan er niet gefaktureerd worden. Dat Italië háár klant niet kan faktureren is daarbij één (de kapitein wil toch maar 1 faktuur hebben en weet dat hij niet zal betalen als die faktuur niet kompleet is), maar ook kan het Nederlandse bedrijf, welke puur 'bemiddelaar' is in deze, niet faktureren. In de oude situatie werd derhalve zo'n order er soms 'doorgedrukt'. De tool die de leveringen doorkopiëerde, en welke pas gebruikt mocht worden zodra het P.O.D. ontvangen werd, werd al gebruikt vóórdat het P.O.D. ontvangen was. Hierdoor werden de (op dat moment bekende) produkten als 'geleverd' doorgekopiëerd en konden ze gefaktureerd worden. Het grote probleem was dan echter dat als dan later alsnog het P.O.D. werd ontvangen en daar alsnóg iets anders op bleek te staan, alle partijen flink aan het crediteren konden slaan (handmatig, immers, daar was verder niets voor ontwikkeld).

De nieuwe situatie werkt op eenzelfde wijze, maar dan op basis van de 'Nep-Fakturen'. We hoeven nu niet meer nèt te doen alsof het P.O.D. is ontvangen en in plaats daarvan genereren we gewoon een Nep-Faktuur, en hebben daarmee onze omzet. Blijkt een maand later dat er toch meer besteld is (de omzet van 200 uit april) dan genereren we in april nogmaals een Nep-Faktuur, en zal op gelijke wijze een eerdere faktuur van 1000 worden tegengeboekt, een nieuwe van 1200 gegenereerd, zodat er in april per saldo 200 omzet uit volgt. "Echt" Faktureren kunnen we echter pas zodra het P.O.D. ontvangen is, precies zoals oorspronkelijke bedoeld, doch welke funktionaliteit werd misbruikt om voortijdig te kunnen faktureren, daarmee ellende op de hals halend als het gefaktureerde deel toch niet klopte.

Merk wel op dat als Italië zelf óók 1000 aan omzet in maart wil boeken, 200 in april, en 0 in augustus, dit niet mogelijk is! omdat we de Nep-Fakturen vooralsnog niet toestaan in het Italiaanse bedrijf. Zonder deze Nep-Fakturen zal Italië dus moeten wachten tot in augustus het P.O.D. arriveert, immer pas ná ontvangst van het P.O.D. is bekend wat er daadwerkelijk geleverd is en kan er op basis van de werkelijke leveringen worden gefaktureerd.

	Author	Topic: Crediteren (Read 2255 times)
0 Members and 0 Guests are viewing this topic.