Heart-Profit ERP
November 27, 2024, 11:01:25 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Afrondingsverschil bij ontvangst Uitgaande Faktuur  (Read 486 times)
0 Members and 0 Guests are viewing this topic.
Heart Informatisering B.V.
Partner
******
Offline Offline

Posts: 27476


View Profile WWW
« on: January 15, 2021, 04:17:41 pm »

Betreft de situatie waarbij een Faktuur van USD 3.521,- volledig wordt ontvangen op een USD rekening. De koers van de USD staat op 0,8150. In de Journaliseringsmodule leidde dit tot een melding Kontroletotaal <> Interface, waarbij het Kontroletotaal een niet-afgerond bedrag betrof (EUR 2.869,6150) en de Interface het Kontroletotaal afrondde op EUR 2.869,62.

Nb: Andere funkties ronden het Kontroletotaal welke de Interface in gaat niet af, en verschillen daarmee van deze funktie. Dit duidt er al op dat de kans groot is dat er hier ook niet moet worden afgerond.

Dát het Interfacebedrag hier wel werd afgerond stamt uit 2002, met een voorbeeld waarbij (in een EUR bedrijf) een SGD bedrag werd ontvangen op een USD Faktuur (overigens, voor dezelfde klant als nu) én onder genoemde twijfels over het juist hebben ingericht van de Journaalpostdefinities; die situatie zullen we na deze aanpassing opnieuw beoordelen. Bij de gratie dat een Kontroletotaal ook gebruikt wordt om het te journaliseren USD bedrag te bepalen, zou dat al voldoende reden moeten zijn om een Kontroletotaal welke de Interface in gaat nooit af te ronden.

USD 3.521,- x 0,8150 = EUR 2.869,6150 (waarbij de Interface in de Bedrijfsvaluta EUR werkt).

Dat terugrekenend naar dollars leidt tot EUR 2.869,6150 / 0,8150 = USD 3.521,-

Zouden er het bedrag afronden (EUR 2.869,62) en dat afgeronde bedrag terugrekenen naar een USD bedrag dan leidt dat tot een bedrag van USD 3.521,01. Merk overigens op dat dit soort verschillen nog groter worden naar mate het om een Valuta gaat met een lagere koers (bijv. de Turkse Lira). Terug naar het voorbeeld uit 2002:

In dit voorbeeld staat de koers van de USD op 1.111762; de koers van de SGD staat op 0,612603.

Vervolgens hebben we een Faktuur van SGD 3.737,68 welke volledig betaald wordt op een USD rekening. Bij het getagd afboeken geven we aan dat we een bedrag van SGD 3.737,68 hebben getagd. Het Kontroletotaal welke de Interface in gaat is daarmee SGD 3.737,68 x 0,612603 = EUR 2.289,7140.

Dit bedrag journaliserend op een USD rekening, zou impliceren dat er EUR 2.289,7140 / 1.111762 = USD 2.059,5361 dollars zouden zijn ontvangen. Dat bedrag kan niet als zodanig worden gejournaliseerd, en dus wordt er USD 2.059,54 op de dollarrekening gejournaliseerd. USD 2.059,54 heeft een tegenwaarde van EUR 2.289,7183. Dit leidt uiteindelijk tot wederom een melding dat het Kontroletotaal afwijkt t.o.v. de Interface.

De Journaalpostdefinitie is op zich uitgerust met de mogelijkheid om zelf afrondingsverschil te journaliseren, maar, die wordt niet getriggerd, omdat het verschil 0,0043 is, wat afgerond op 0,00 uitkomt.

Dit probleem is destijds opgelost door het bedrag welke de Interface in gaat af te ronden op 2 decimalen (en wat nu fout blijkt te zijn).

De oplossing van dát probleem zal hem moeten zitten in het feit dat als we met Vreemde Valuta werken, we zullen moeten accepteren dat er afrondingsverschillen kúnnen ontstaan in het Kontroletotaal. Als we toestaan dat het kontroletotaal met bijv. maximaal 1 cent mag afwijken dan elimineren we daarmee de foutmelding dat het Kontroletotaal niet overeenkomt met wat de Interface aangeeft. Met een marge van 1 cent op het Kontroletotaal komen we verder, maar kunnen we dit voorbeeld ook niet 100% goed journaliseren. Dát wordt dan veroorzaakt doordat dit eigenlijk een slecht voorbeeld is!

Indien we een proces via Batchboekingen laten lopen, kan een Funktie in Profit feitelijk voor iedere Journaalpostregel bepalen welk bedrag er op welke regel geboekt moet worden. Zodra er (zoals in dit voorbeeld) rechtstreeks een Financiële Interface wordt aangestuurd, hebben we enkel de parameters "Interfacebedrag", "Kontroletotaal" en "Restbedrag t.o.v. het Kontroletotaal" tot onze beschikking, en mág het niet zo zijn dat we 3 Valuta's aan de orde hebben!

Lees: wat er in dit voorbeeld gebeurt is dat we zeggen dat een Faktuur volledig betaald is op onze USD rekening, terwijl we niet eens hoeven aan te geven welk bedrag er dan op de USD rekening is ontvangen.

Ofwel, wil hetgeen we in dit voorbeeld willen oplossen goed kunnen werken, dan zal éérst de funktionaliteit "Getagd verwerken Ontvangst" in staat moeten zijn om aan te geven wat het ontvangen USD bedrag is op de USD rekening waarop we de betalingen willen boeken, moet op basis van dát USD worden bepaald wat het Kontroletotaal wordt, en kunnen we het bedrag daarna boeken op de USD rekening waarna er geen verschillen meer zullen optreden. Zonder deze mogelijkheid om een andere Valutakode te kunnen overschrijven is het niet toegestaan dit soort fakturen op deze manier te boeken.

Nb: We zullen het nu niet blokkeren, maar, boekt U het tóch op deze wijze, dan kunnen er kleine afrondingsverschillen ontstaan.

FunktieOmschrijvingDtm.Vl.WyzDtm.L.Wyz
ADBOTV1     Journaliseren    11-06-2019    15-01-2021
ADBOTVW1    Omschrijving (nog) niet bekend    11-06-2019    15-01-2021
ADUOTG      Omschrijving (nog) niet bekend    25-09-2018    15-01-2021
Logged
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.219 seconds with 20 queries.