API Forum

This forum is in read-only mode.
Please refer to our API support in case you have any questions.
We can be reached at api@e-conomic.com
e-conomic API developer forum

DebtorPayment and exchange rate issue

0
Hi,

 

When I make a DebtorPayment via CashBookEntry_CreateFromData it wants the AmountDefaultCurrency.

But I don't know this value and I dont have the exchange rate to be able to calculate it!

I only know that customer A has been invoiced e.g. X  USD and has paid X USD into our USD account, and now I somehow have to calculate the amount in my default currency (DKK) in order to make this entry. When I do this manually via the interface then e-conomic finds the correct exhange rate by itself but how can I get this functionality via the API?

Btw, I'm accessing the API via Perl so using straight SOAP calls.

 

Secondly, I'm a little confused regarding 'DebtorPayment'. When I make this via the API it creates a 'debit' entry. When I make it via the interface it makes a 'credit' entry. Is DebtorPayment in the API not the same as "Customer Receipts" in the interface? It's a little confusing that the API calls are not labelled the same as the interface.

 

Thanks.

Regards,
created Apr 30, 2013 by TS23
0% Accept Rate
Q 2 A 0 C 0

1 Answer

0

Hi,

Let me address your questions one by one.

 

Regarding exchange rates:

The e-conomic application utilizes a commercial exchange rate feed - from XE.com - which, unfortunately, we cannot expose via the API (consider the potential for abuse).

However, 'official' exchange rates are really only usable for invoices anyway - and these will be somewhat 'fictitious' anyway, since the exchange rate of the eventual payment is likely to be different, thus resulting in an exchange rate difference affecting your net base currency revenues anyway. In other words: If you use a fixed or other-sourced rate, the net result will be the same (i.e., any difference between 'your' rate and what the e-conomic GUI application would have suggested will be compensated by by a similar difference in the eventual exchange rate difference).

As far as payments go, the 'official' exchange rates aren't really usable anyway - since payments are factually cash, and thus need to be registered using the exchange rate offered by your bank. And I've personally never come across anyone who can buy or sell currency at official rates anyway :-)

Now, your case is a little special, since, while your accounts are denominated in DKK, you have an actual USD-denominated bank account. e-conomic doesn't really support foreign currency-denominated accounts directly - that's not an API limitation per se.

From an accounting perspective, one would typically handle this by registering payments on the account at a 'somewhat fictitious' exchange rate to your default currency. And then, at period or accounting year closing, register manual adjustments to the account, such that the default currency balance of the account at period end is correct as of that time. However, you should of course involve your bookkeeper or accountant to make sure you're aligned on this.

Regarding terminology differences - which typically arise around Debtors vs Customers, Creditors vs Suppliers, or Cash Books vs Day Books: While we obviously strive to maintain consistency between the GUI application and the API here, the case is simply that, when the API was first launched, what's now called Customers in the GUI were called Debtors. So, there was consistency back then. Subsequently, terminology changes have been deemed proper for the GUI - whereas, in the API, that'd obviously be a breaking change. Consequently, both existing and new functionality in the current API will refer to Customers as Debtors - to at least maintain consistency within the API.

"Customer receipts" in the GUI is a day book (CashBook in API terms), which has likely been set up in your account to handle customer payments (DebtorPayment in the API) - i.e., entries of type DebtorPayment.

The credit/debit dimension in the GUI is really an accountant thing - in practice, registering a credit entry in the GUI will reverse the sign. Similarly, editing an entry of e.g. -100 will show as "credit 100". The API doesn't work with debit/credit, but purely with signs (technically, we don't even save the debit/credit 'setting' of the entry). And, accounting-obviously, customer payments are negative on the customer, and positive on the bank account.

answered May 3, 2013 by Christian Estrup
Visma e-conomic A/S
...