How to get BTC-AUD buy price without fees - api

Is there any way to get the exchange rates without fees factored in because they seem to vary based on transaction volume and payment method?
The API documentation says:
Note that exchange rates fluctuates so the price is only correct for
seconds at the time. This buy price includes standard Coinbase fee
(1%) but excludes any other fees including bank fees.
Source: https://developers.coinbase.com/api/v2#get-exchange-rates
So the assumption is you can divide the exchange rate returned by 1.01 to get the fee excluding the standard Coinbase fee of 1% and conversely for sell price, you would multiply by 1.01.
However, the pricing from November 2017 has a much more complex pricing structure and makes no reference to the "standard Coinbase fee" referred to in the documentation.
See https://support.coinbase.com/customer/en/portal/articles/2109597-coinbase-pricing-fees-disclosures

Related

How do I retrieve the currency details of a journal transaction from the REST API in Acumatica?

I’m having a hard time making sense of multi-currency transactions. I’m using the REST API to retrieve journal transaction details. I’m hitting the /entity/Default/18.200.001/JournalTransaction endpoint with $expand=Details and some date filters. The base currency of this Acumatica instance is USD, but some journal transactions are entered in EUR. The problem is that for these EUR transactions, I have no way of knowing these debit/credit amounts were entered in the non-default currency. I see the EUR amount, but the CurrencyID of the transactions indicates “USD”. About the only thing I notice is that the transaction is in the “US” branch, but the details are in the “EU” branch. Is there a way, via the REST API, to query journal transactions/details, and discern what currency the debit/credit amount is represented in?
Journal header contains CurrencyID field which should tell you what currency it belongs to.

Exchange gain or loss on partial payments in Odoo

I found out Odoo is not creating exchange gains or losses for partial
payments. Only at the time of full payment Odoo is calculating the
exchange difference. This is creating serious headache for the user,
when they see aged payable, receivable, partner ledger, general
ledger, etc exchange rate is not considered. This is giving the users
wrong information about the payments they have made.
Impacted versions: 11
Steps to reproduce:
1) Make 2 different Multi currency Invoices for the single supplier
2) Modify the current exchange rate under currencies
3) Make a partial payment for one single invoice with exchange difference
Current behavior:
It does not generate the Exchange gain or Loss for the partial invoice payments
Expected behavior:
Irrespective of the full payments or partial, it should generate the Exchange gain or Loss as per the payment date and Invoice record Date
By default Odoo will generate exchange gain or loss only when all invoice paid, on partial payments exchange isn't computing.

mantle.account.invoice.Invoice - How to correctly handle credit invoicing?

Let us assume there is a situation when I have an invoice from a supplier to my company (e.g. 1000 EUR). My company returns all the goods because of a problem. The supplier shall issue a credit invoice in amount of 1000 EUR, which I register in my system. As a result I will have (on behalf of the supplier) an account payable of 1000 EUR and an account receivable in the same amount. What is the preferred way of handling this situation, because there will be no money transferred, either way.
Should I generate a paymentApplication to both invoices? I want to see them as +1000 -1000 = 0 EUR.
The current data model and services do not support applying an invoice to an invoice, i.e. canceling part or all of one invoice with another. That is something I have considered but IMO is messy... even if it is a common practice in certain parts of the world (from my limited knowledge of it an archaic practice that isn't so commonly used any more). That could be supported though, I have certainly considered it (adding an entity or perhaps modifying PaymentApplication to support it, adding a service to do it and a corresponding GL posting service to balance AP/AR accounts).
Right now the best thing to do a cancel the original invoice, which does the proper reverse GL postings if the invoice has already been posted.
If you want both invoices in the system and canceling entries somewhere the currently supported approach is to use a FinancialAccount, basically use FinancialAccount payments to pay both invoices and then the balance of the FinancialAccount represents the amount due or owed to the external party. There is full support for these sorts of FinancialAccount transactions, doing payments both ways (withdrawals and deposits), representing the liability for positive balances in the GL, etc.

Paypal fees in a chained or parallel payment

I have an answer about how Paypal calculates the fees to apply to each receiver in case of a chained or parallel payment done with the Adaptive Payment API.
Is the fee calculated on the total amount payed by the sender? In this case each receiver would pay a proportional portion of the total fee. Or is it charged a fee to each amount in which the transaction is split? We will work with Spanish fees (3.4% + 0.35 euros) and in this last case Paypal charges would be significantly higher because of the fixed 0.35 euros that would be charged to each transaction. We are mainly worried about the case this also applies to the commission for the marketplace because we would be loosing money in some transactions when our commission would be lower than 0.35 euros.
This is the only info I've found and I still didn't understand it.
In the text they do not specify that issue (unless I am misunderstanding anything due to I am Spanish-speaking), so I had tried to deduce it with the examples at the end of the text although they pointed that "The scenario above is an example only and is not representative of actual PayPal fees".
But it resulted that the scenarios were completely unreal as they charged a higher fee to a secondary receiver that was receiving an amount of $130 than other receiving $150. So it was impossible for me to get any conclusion.
If the receivers pay the fee, you can specify whether the primary receiver in a payment with several receivers pays the entire fee or all receivers pay a portion of the fee.
•Sender pays the fee – the sender can pay a fee for a simple payment, parallel payment or chained payment.
•Receiver Pays the Fee in a Parallel Payment – the sender can send a payment that is split directly among 2 to 6 receivers. Each receiver pays a portion of the fee based on the amount of the payment each receiver gets.
•Each Receiver Pays the Fee in a Chained Payment – the sender can send a payment that is indirectly split among one or more receivers. The primary receiver, identified as the merchant, pays a fee and each of the other receivers also pay a fee based on the payment amount each receives.
•Primary Receiver Pays the Fee in a Chained Payment - the sender can send a payment that is indirectly split among one or more receivers. If the primary receiver pays the fee in a chained payment, other receivers pay no fees. The fees paid by the primary receiver are based on the total fees assigned to all receivers.
•Secondary Receivers Pay the Fee in a Chained Payment - the sender can send a payment that is indirectly split among one or more receivers. The primary receiver doesn’t have to pay the fees with the secondary receivers paying all the fees.
Fees are determined by PayPal and are based on criteria, such as the transaction volume of the receiver.
So each of your receivers would be charged the (3.4% + 0.35 euros) if you split the payment between the receivers.

Currency used in the cart must match the currency of the seller account

My client's Google Checkout account is based in UK, hence its default currency is GBP. Accordingly, I thought I'd let users pay using GBP - they actually think they are paying in USD but behind the scenes I convert USD to GBP according to the conversion rate.
Anyway, I keep getting the following error message:
The currency used in the cart must match the currency of the seller account. You supplied a cart with USD and the seller account is associated with GBP.
When I check the Integration Console for the message that is being sent from the website to Google Checkout's API, this is what I get:
_type=checkout-shopping-cart&shopping-cart.items.item-1.item-name=Credits&shopping-cart.items.item-1.item-description=Description&shopping-cart.items.item-1.item-currency=GBP&shopping-cart.items.item-1.unit-price=64.42&shopping-cart.items.item-1.quantity=1
As you can see, I made sure the currency is set to GBP, yet it still complains. Is there anything I can do to fix this?
How are users thinking they are paying in USD? If they see the Place Order page in USD, then the cart is posted in USD, hence your problem.
Also please keep in mind that credit card companies will add extra fees for currency conversions, which are unknown at the time of transaction to both the seller and Google Checkout. Usually the fees appear as a separate item on the buyer's credit card statement. You may want to inform non-UK buyers about this and emphasize that the currency fees are out of your control.
This doc has some info related to this error:
https://checkout.google.com/support/sell/bin/answer.py?hl=en&answer=71444