Heart-Profit ERP
July 01, 2024, 12:41:04 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: IC Verrekening via Rekening Courant  (Read 1431 times)
0 Members and 0 Guests are viewing this topic.
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5361


View Profile WWW
« on: January 15, 2021, 12:38:46 pm »


Intercompany verrekenen Fakturen via Rekening Courant

Het Intercompany verrekenen van Fakturen via een Rekening Courant wordt getriggerd vanuit het proces 'Genereren Uitgaande Faktuur' (Hoofdmenu-3-3-3-1).

Financieel verwerken IC-Faktuur J/N
Allereerst zullen we er voor moeten zorgen dat als we vanuit Bedrijf A faktureren aan Bedrijf B, de Uitgaande Faktuur van Bedrijf A in Bedrijf B automatisch leidt tot de opname van een Ingekomen Faktuur. Hiertoe is een Bedrijfsparameter "Financieel Verwerken IC-Faktuur J/N" opgenomen, welke met "Ja" dient te worden beantwoord. Deze parameter is te vinden bij Bedrijfsparameters (Hoofdmenu-F5-F5), P = Intercompany, en dan op het 3e Tabblad.

Nb: Merk op dat deze parameter in beide Intercompany Bedrijven op "Ja" gezet moet worden; we willen immers dat als A aan B faktureert dit hetzelfde werkt als dat B aan A faktureert.

Zodra deze parameter geset is zal de Faktuurgeneratie automatisch een Ingekomen Faktuur genereren in "het andere bedrijf".


Rekening Courant
Indien er óók in beide bedrijven een Rekening Courant is vastgelegd met 'het andere bedrijf', dan zal bovenstaande Faktuurgeneratie niet alleen een Ingekomen Faktuur genereren 'in het andere bedrijf', maar zal die Faktuur door dat andere Bedrijf ook automatisch betaald worden op de Rekening Courant, en wordt die Betaling in het Fakturerende Bedrijf weer als Ontvangst opgenomen op de zojuist gegenereerde Uitgaande Faktuur (die daarmee voldaan is).

Zo'n Rekening Courant verhouding dient in beide bedrijven te worden vastgelegd via Hoofdmenu-7-8-1-2.
In Bedrijf A zullen we de Grootboekrekening kunnen opnemen van de Rekening Courant verhouding met bedrijf B, en in Bedrijf B nemen we een RC verhouding met Bedrijf A op.
In het verdere voorbeeld zal de Rekening Courant van Bedrijf A op Grootboekrekening 1270 worden gejournaliseerd, en de Rekening Courant van Bedrijf B op 1272.
Merk op dat 1270 daarmee niet in Bedrijf A zelf opgenomen hoeft te worden, immers, Bedrijf A zal geen RC met zichzelf hebben; net zo goed zal Bedrijf B geen RC met Bedrijf B hebben.

Multi Valuta = Verrekenen in de Faktuurvaluta
Uitgangspunt bij het opzetten van een Rekening Courant verhouding is dat de Grootboekrekening "Rekening Courant (met Bedrijf xxx)" altijd wordt gedefiniëerd als "Multi-Valuta" rekening. Op die manier kan iedere Faktuur, ongeacht de Valuta waarin ze wordt gefaktureerd, worden verrekend via dezelfde Rekening Courant (waarop dan saldi in verschillende Valuta kunnen worden geboekt). Een 2e uitgangspunt was dat de Bedrijfsvaluta van Bedrijf A altijd overeen moest komen met de Bedrijfsvaluta van Bedrijf B; beide moesten bijv. in EUR zijn opgezet.


Verrekenen in TRY
Nieuw sinds dit topic, en daarmee de aanleiding voor dit topic, is het verrekenen in een vaste Valutakode: Turkse Lira.

In dit voorbeeld is Bedrijf A een Nederlands Bedrijf welke is ingericht in EUR.
Bedrijf B is een Turks Bedrijf, welke is ingericht in TRY (Turkse Lira).
Nb: De 1e grote verandering alhier is dus dat we niet meer voldoen aan de regel "beide IC bedrijven dienen in dezelfde Bedrijfsvaluta te opereren".
Nb2: Aanleiding voor dit topic is mede hetgeen in topic http://ha1.heartprofit.nl/profit/index.php?topic=30341.0 is beschreven.

Bedrijf A wil graag dat er Intercompany wordt gefaktureerd in EUR.
Bedrijf B zal graag in TRY willen betalen, en wil niet "steeds meer Turkse Lira" willen moeten betalen omdat de koers van de TRY t.o.v. de EUR daalt.
Beide willen we kombineren door te Faktureren in EUR, maar die Fakturen direkt te verrekenen via een Rekening Courant in TRY.

* Het verrekenen in een vaste Valutakode TRY i.p.v. in de Faktuurvaluta, triggeren we door te stellen dat de Grootboekrekening "Rekening Courant (met bedrijf xxxx)" moet worden gedefiniëerd als een Vreemde Valuta Rekening in de Valutakode waarin we willen verrekenen: TRY. "Multi-Valuta" mag nu niet meer op Ja staan!


Let op:
- De Rekening Courant in Bedrijf A met Bedrijf B dient op dezelfde manier te worden gedefiniëerd als de Rekening Courant in Bedrijf B met Bedrijf A; is de een in TRY dan moet de ander ook in TRY zijn. Is de een Multi-Valuta, dan moet de ander dat ook zijn.
- Bij het Intercompany verrekenen in een andere Valutakode dan de Faktuurvaluta (zoals we nu in TRY doen) geldt de restriktie dat de vaste Valutakode van de Rekening Courant òf de Bedrijfsvaluta van Bedrijf A moet bevatten òf de Bedrijfsvaluta van Bedrijf B. Bedrijf A is in dit voorbeeld ingericht in EUR, Bedrijf B is ingericht in TRY, en daarmee mogen we òf in EUR òf in TRY verrekenen maar niet in een derde Valutakode (zoals bijvoorbeeld USD); en dat eigenlijk alleen omdat die situatie niet is ontwikkeld ('t is al complex genoeg).

Valutakoersen
In dit voorbeeld hebben we met twee separate bedrijven te maken; een die is ingericht in EUR (en zelfs een Database-Valuta NLG heeft, maar dat is voor u niet echt van belang omdat dat meer een technische aangelegenheid is), en de ander die is ingericht in TRY. Omdat we gesteld hebben dat we alléén mogen verrekenen in de Bedrijfsvaluta van een van de twee Intercompany Bedrijven, is die keuze beperkt tot EUR en TRY. Maar... we hebben nog steeds 2 Bedrijven en in beide bedrijven kan de koers in theorie anders zijn geregistreerd. Daar moeten we rekening mee houden.

Voor Bedrijf A geldt dat ze is ingericht in EUR; de koers van de EUR is daar dus 1,000000; de koers van de TRY staat aldaar op 0,111014.
Voor Bedrijf B geldt dat ze is ingericht in TRY; de koers van de TRY is daar dus 1.000000; de koers van de EUR staat aldaar op 9,116435.

Als we bovenstaande koersen in beide gevallen uitdrukken als een koers van de TRY t.o.v. de EUR, dan leidt dit:
in bedrijf A tot een faktor 0,111014 / 1 = 0,111014, de inverse koers (EUR/TRY) is dan 9,007873.
in bedrijf B tot een faktor 1/9,116435 = 0,109692, de inverse koers (EUR/TRY) is dan 9,116435.

Ofwel, in dit voorbeeld zijn de koersverhoudingen in de twee bedrijven niet consistent ingericht over de twee bedrijven heen.

Doordat deze twee koersverhoudingen van elkaar afwijken, gaat het ineens uitmaken of we de koers berekenen vanuit Bedrijf A of vanuit Bedrijf B!
Dat zóu kunnen worden opgelost door te stellen dat de koersen tussen deze bedrijven altijd consistent dienen te worden ingericht, maar, dat is nu eenmaal niet zo. Merk op dat Bedrijf B in theorie ook weer Intercompany verhoudingen kan hebben met Bedrijf C en de registratie van een nieuwe koers in Bedrijf A ook zou impliceren dat Bedrijf C met een andere koers moet werken. Ofwel, dit gaan we niet verplichten; het is niet anders. Het ene Bedrijf registreert nu eenmaal vaker een koers (desnoods dagelijks) dan het andere Bedrijf; wij proberen daarop te anticiperen.

Resteert dan nog wel de vraag "in welk Bedrijf gaan we dan de koers bepalen?"
Het antwoord lijkt aan de ene kant eenvoudig, nl. dat zou altijd het bedrijf moeten zijn waarin de betaling wordt verricht. Toch levert dat niet op wat we willen, immers, als Bedrijf A aan Bedrijf B faktureert, betaalt B de Faktuur van A. Als Bedrijf B aan A faktureert, betaalt A de Faktuur van B. De koers is dan alsnog anders, waardoor zou gelden dat als A iets verkoopt aan B en B verkoopt het direkt terug, er toch een partij is die er geld aan verdient, omdat hetzelfde EUR bedrag bij het terugverkopen leidt tot een ander TRY bedrag. We moeten dus ongeacht of A aan B verkoopt danwel B aan A verkoopt altijd de koers uit hetzelfde Bedrijf halen (wat in dit geval Bedrijf B is, omdat daar dagelijks de koers van de EUR wordt geregistreerd). Het Bedrijf waarin de koers wordt bepaald voor deze Rekening Courant verrekeningen, wordt dynamisch bepaald, en wel door het Bedrijf welke in TRY is opgezet! We hadden keuze uit twee Bedrijven (A & B) die beide in een andere Valuta opereren (EUR & TRY). Met dat  de Grootboekrekeningen "Rekening Courant (met Bedrijf A & B)" in TRY zijn vastgelegd is dat voor Profit de trigger om de koersen te berekenen in het TRY Bedrijf.
Nb: Merk op dat andere klanten die ook van deze funktionaliteit gebruik willen maken dat theoretisch anders kunnen willen hebben, in welk geval we tegen die tijd dit kunnen overrulen met e.o.a. Bedrijfsparameter.

De koers die feitelijk dient te worden berekend, is de koers waarmee we omrekenen tussen de Faktuurvaluta (EUR) en de Valutakode van de Rekening Courant verrekening (TRY). Merk op dat de Valutakoers van de TRY altijd 1.000000 is in een Bedrijf welke de TRY als Bedrijfsvaluta heeft); de omrekenfaktor wordt aldaar dus berekend als de inverse koers van de EUR (ofwel 1 / EUR-koers).



Voorbeeld:

Er zijn 3 situaties die we zullen testen:

a. Het TRY Bedrijf (B) koopt voorraad (grondstoffen) in bij het EUR Bedrijf (A); A verkoopt aan B, B koopt in bij A.

b. Het TRY Bedrijf (B) verkoopt voorraad terug aan het EUR Bedrijf (A); A koopt in bij B, B verkoopt aan A.

c. Het EUR Bedrijf (A) verkoopt aan een klant, maar besteedt de order uit aan het TRY Bedrijf (B) die rechtstreeks levert aan de klant van Bedrijf (A); A verkoopt aan haar klant, A koopt in bij B, B verkoopt aan A.

Voor het verdere verhaal is het het makkelijkst als we beginnen bij voorbeeld b.

b. Het TRY Bedrijf (B) verkoopt voorraad terug aan het EUR Bedrijf (A); A koopt in bij B, B verkoopt aan A.

* In Bedrijf B voegen we een Verkooporder toe aan Bedrijf A (wat overigens op hetzelfde neerkomt als dat we in Bedrijf A een Inkooporder zouden toevoegen bij Bedrijf B). B is een Bedrijfs in TRY en in Turkije wordt KDV op een order berekend als we niet met die order langs de douane gaan. Als we de KDV even buiten beschouwing willen laten, moeten we bij de Verkooporder in Bedrijf B het veldje "In Transito Verkoop J/N" met Ja beantwoorden; daarmee impliceren we dat we langs de douane gaan, hetgeen er voor zorgt dat er géén KDV wordt berekend (zie Releasenote Custom Clearance

* Vervolgens voegen we een Verkooporderregel toe waarop we 1 blik verkopen met een inhoud van 16,2 Liter tegen een prijs van EUR 10,00 / L. De Verkooporder en haar prijzen zijn in EUR omdat er in dit voorbeeld de Intercompany Prijslijst in euro is gedefiniëerd.

* Deze Verkooporderregel wordt vervolgens geleverd. De Charge die geleverd wordt heeft een kostprijs van TRY 738,43. Deze levering leidt tot een Journaalpost "Te faktureren Voorraad / Aan Voorraad Goederen" voor een bedrag van TRY 738,43.

In "het andere bedrijf", Bedrijf A, wordt deze partij ontvangen. Bedrijf A werkt in EUR. We hebben 16,2 L ingekocht voor EUR 10,- / L., ofwel, in bedrijf A komt er EUR 162,- op voorraad. Dat leidt tot de Journaalpost "Voorraad Goederen / Aan Nog te ontvangen Fakturen" voor een bedrag van EUR 162,-.



* Daarna faktureren we deze order. We hebben 16,2L geleverd tegen een prijs van EUR 10,00 / L ofwel de Faktuur bedraagt EUR 162,-.
Bedrijf B heeft daarmee een vordering op Bedrijf A voor EUR 162,- (zie regel #3).
De koers van de EUR in het TRY Bedrijf bedraagt 9,116435, daarmee is de omzet in Bedrijf B gelijk aan EUR 162,- x 9,116435 = TRY 1.476,86 (zie regel #4).
Op regels #1 en #2 zien we dat "Te faktureren voorraad" wordt tegengeboekt t.l.v. "Kostprijs Verkopen".

Het genereren van een Uitgaande Faktuur in Bedrijf B, leidt tot een Ingekomen Faktuur in Bedrijf A. Deze Ingekomen Faktuur boekt enerzijds de post "Nog te ontvangen Fakturen" tegen, en boekt anderzijds de schuld aan de Crediteur "Bedrijf B".


* Omdat we ook in beide bedrijven Rekening Courant verhoudingen hebben gedefiniëerd is de eerst volgende stap dat deze Faktuur vanuit Bedrijf A betaald wordt. Ondanks dat het om een Faktuur in EUR gaat, zal de betaling plaatsvinden in TRY (immers, de Rekening Courant Grootboekrekeningen zijn in TRY ingericht en impliceren daarmee dat er in TRY verrekend moet worden).
De koers van de TRY in Bedrijf A staat op 0,111014, hetgeen impliceert dat EUR 162,- gelijk is aan TRY 1.459,28. Zou Bedrijf A dít bedrag betalen dan ontvangt Bedrijf B feitelijk te weinig geld. De omzet aldaar in TRY betrof immers TRY 1.476,86. Maar, zoals eerder uitgelegd, om die reden bepalen we de koers van de TRY dús in het TRY bedrijf. Omdat de Betaling direkt plaatsvindt na het genereren van de Faktuur, en ook per dezelfde Faktuurdatum, is de koers van de Betaling feitelijk gelijk aan de koers in die in het TRY bedrijf leidde tot de bepaling van de omzet. We hanteren de koers van EUR = 9,116435 TRY, waarmee bedrijf A een bedrag betaald van TRY 1.476,86. Door deze betaling in TRY is de Faktuur in EUR volledig voldaan. De Crediteur wordt dus in EUR tegengeboekt, maar "Betalingen Onderweg" wordt in TRY (de Valutakode van de betaling) opgeboekt.

De betaling aan "Betalingen onderweg" wordt meteen weer tegengeboekt door een formeel verwerken van het "Afschrift van de betaling", die het bedrag verrekend via de Rekening Courant met bedrijf B. Beide bedragen worden in TRY geboekt.

Betalingen onderweg loopt weer glad, en de eindsituatie in de administratie van Bedrijf A is dat ze (via de Rekening Courant) een schuld heeft aan Bedrijf B voor TRY 1.476,86.

Dan weer terug naar de administratie van Bedrijf B. De betaling van TRY 1.476,86 door Bedrijf A zal daar als Ontvangst binnen komen op de in Bedrijf B gegenereerde Uitgaande Faktuur. In Bedrijf B is de Uitgaande Faktuur daarmee voldaan; de vordering op de Debiteur wordt dus tegengeboekt ter waarde van het Faktuurbedrag (EUR 162,-). Het betaalde bedrag wordt in Bedrijf B ontvangen op de Rekening Courant met bedrijf A, voor een bedrag van TRY 1.476,86. De eindsituatie daarmee voor Bedrijf B is dat Bedrijf B een vordering heeft op Bedrijf A voor  TRY 1.476,86.

Ofwel, A heeft via de Rekening Courant een schuld aan B, en B heeft via de Rekening Courant een vordering op A; gekonsolideerd valt dit tegen elkaar weg.

Let op:
In bovenstaand voorbeeld vallen alle bedragen mooi tegen elkaar weg, ondanks dat er tóch in beide bedrijven een andere koers voor de TRY wordt gehanteerd. Het bedrag welke door A aan B wordt betaald van TRY 1.476,86 zóu formeel gezien bij de koers van 0,111014 tot een tegenwaarde leiden van EUR 163,95 waarmee er (t.o.v. de EUR 162,-) direkt al sprake is van een koersverschil van EUR 1,95. Dat dit bedrag nu niet als koersverschil wordt gejournaliseerd komt omdat de gegenereerde Batchboeking expliciet de informatie bevat dat deze moet worden doorgeboekt tegen een koers van 0,109692 (= 1/9,116435). Door die koers te hanteren wordt er op het moment van Faktureren nergens een koersverschil geboekt. Toch is dat koersverschil wel degelijk aan de orde, maar... dat zal pas ontstaan als we Vreemde Valuta gaan Herwaarderen! Merk daarbij op dat dit voor het TRY bedrijf geen gevolgen zal hebben, immers, aldaar is de koers van  de TRY altijd 1; het saldo op de Rekening Courant is in Bedrijf B dus niet aan Valutaherwaardering onderhevig. Alle bedragen die door zo'n Intercompany Fakturatie en verrekening in EUR worden gejournaliseerd lopen glad en zijn daarmee in Bedrijf B ook niet onderhevig aan de Valutaherwaardering (het saldo is immers 0,00). In Bedrijf A staat er nu echter een saldo van TRY 1.476,86 op de Rekening Courant. Als we in Bedrijf A gaan Herwaarderen, dan berekent Profit de nieuwe tegenwaarde (= EUR 163,95), vergelijkt ze dat met de tegenwaarde die momenteel geboekt is (EUR 162,-) en zal het verschil worden geherwaarderd ten laste-/gunste van een Grootboekrekening Koersverschillen:




a. Het TRY Bedrijf (B) koopt voorraad (grondstoffen) in bij het EUR Bedrijf (A); A verkoopt aan B, B koopt in bij A.
Het voorbeeld is vergelijkbaar aan b., maar nu verkoopt A aan B (danwel koopt B in bij A).

* In Bedrijf A voegen we een Verkooporder (met regel) toe aan Bedrijf B. We verkopen het zojuist (voor EUR 10,- / L ingekochte produkt) weer terug (eveneens voor EUR 10,- / L om te kontroleren dat de Intercompany boekingen hetzelfde zijn als wanneer we vanuit Bedrijf B aan A verkopen). Het Toevoegen van de Verkooporder levert op zich geen Journaalpost op.

* In Bedrijf A leveren we vervolgens de partij die we zojuist hebben ingekocht; die kostte ook EUR 10,-/L. De levering leidt in Bedrijf A tot het financiëel afboeken van de Voorraad met als tegenrekening "Nog te faktureren voorraad".

In "het andere bedrijf", Bedrijf B, is het zo ingericht dat deze levering aldaar via een Inslaglijst wordt ontvangen. Als die Inslaglijst wordt binnengeboekt, leidt dat tot de financiële (en logistieke) opboeking van de voor een bedrag van TRY 1.476,86. De tegenrekening is "Nog te ontvangen Fakturen" voor een bedrag van EUR 162,-.


* Vervolgens faktureren we de levering in Bedrijf A. Dat leidt in dit geval tot een Faktuur waarbij de omzet net zo hoog is als de kostprijs; we hadden deze partij immers in het eerdere voorbeeld ingekocht voor EUR 10,-/L en verkopen het nu weer terug voor EUR 10,-/L.

De Uitgaande Faktuur in Bedrijf A leidt tot een Ingekomen Faktuur in Bedrijf B. In Bedrijf B wordt daarmee "Nog te ontvangen Fakturen" tegengeboekt, met als tegenrekening "Crediteur Bedrijf A". Het faktuurbedrag bedraagt EUR 162,- dus deze post wordt voor dát bedrag geboekt.


* Omdat er ook een Rekening Courant is gedefiniëerd geldt dat de Ingekomen Faktuur in Bedrijf B automatisch betaald wordt via deze Rekening Courant. De RC Grootboekrekening is in een vaste Valutakode TRY vastgelegd, dus, die betaling vindt plaats in TRY. De Valutakoers wordt bepaald in het Bedrijf die in de Valutakode van de betaling werkt; het TRY bedrijf dus. Bedrijf B boekt de betaling op "Betalingen onderweg", en via het verwerken van het Afschrift Betalingen wordt dit bedrag verrekend via de Rekening Courant.


De eindsituatie voor Bedrijf B is dat Bedrijf B via de Rekening Courant een schuld heeft aan Bedrijf A.

De betaling door Bedrijf B impliceert weer dat Bedrijf A dit bedrag heeft ontvangen. Bedrijf A ontvangt een bedrag van TRY 1.476,86 en daarmee is haar Uitgaande Faktuur van EUR 162,- voldaan. Ook hier triggert de Batchboeking dat er niet tegen de TRY koers van Bedrijf A wordt gejournaliseerd, maar tegen de (inverse) koers van de EUR in het TRY bedrijf. Dit zorgt er weer voor dat er in Bedrijf A (op dit moment) geen koersverschil aan de orde is.

maar, als we zouden Herwaarderen in Bedrijf A, dan wordt dat koersverschil wél geboekt. Merk op dat we a.g.v. voorbeeld b. al TRY 1.476,86 op de Rekening Courant hadden geboekt. Door het terugverkopen van hetzelfde produkt tegen dezelfde prijs ontvangen we nu hetzelfde bedrag op de Rekening Courant. De Herwaardering konstateert nu een saldo van 0,00 in TRY, maar vind nog wel een tegenwaarde van EUR 1,95 (a.g.v. de eerdere Valutaherwaardering) en korrigeert die EUR 1,95 nu de andere kant op.



De eindsituatie na deze Fakturatie (en verrekening) is dat Bedrijf A via de Rekening Courant een vordering heeft op B, en B een schuld heeft aan A. De eindsituatie van voorbeeld b. was precies omgekeerd. Als we ná voorbeeld b. én voorbeeld a. in Bedrijf A naar de Grootboekrekening "Rekening Courant met Bedrijf B" kijken, is het saldo 0,00.

Kijken we in Bedrijf B naar de Grootboekrekening "Rekening Courant met Bedrijf A", dan is ook daar het saldo 0,00.

Op beide Rekening Courant Dagboeken zien we in het Boekstuknummer het Faktuurnummer staan waarmee Bedrijf A aan B heeft gefaktureerd en andersom.


c. Het EUR Bedrijf (A) verkoopt aan een klant, maar besteedt de order uit aan het TRY Bedrijf (B) die rechtstreeks levert aan de klant van Bedrijf (A); A verkoopt aan haar klant, A koopt in bij B, B verkoopt aan A.
De laatste situatie, voorbeeld c. werken we hier niet meer volledig uit; dit omdat ze feitelijk hetzelfde is als situatie a.
In deze situatie verkoopt A het produkt aan haar klant (voor bijv. EUR 15,- / L), en besteedt ze de order uit aan B (die direkt moet leveren aan de klant van A).
A koopt dan in bij B, en B verkoopt aan A (maar levert aan de klant van A).
Voor de verdere Intercompany boekingen is die situatie dan vergelijkbaar met voorbeeld a., hooguit zal ze nog gevolgd worden door de Fakturatie in Bedrijf A aan de klant van A.
Logged

Heart-Profit company ID : HA
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.077 seconds with 20 queries.