| Redisplay Messages: Compact | Brief | All | Full Show Messages: All | Without Replies| Author: | Rob_and_Shelagh  | | Posted: | Jun 29, 2016 07:36 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 24 times | | Topic: | Suggestions | |
| In Suggestions, Teup writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, maninblack writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, maninblack writes:
| | In Suggestions, Teup writes:
| | Whenever a buyer uses onsite PayPal, I do not receive the amount I instruct in
the invoice, but an up to date conversion of the Bricklink grand total field
in the currency that the buyer chooses. Tax-wise, this is a problem.
Please allow setting a grand total in the actual currency that a buyer chooses
to pay in. This way, the figures of the invoice and the actual payment will match.
I think this is a high priority issue, because technically, it currently forces
us to do something that is technically illegal.
Or is there a way to prevent this that I didn't think of? Retroactively changing
the invoice is the best solution that came to my mind, but that's pretty
tedious.
|
Nearly all of my orders are paid in a different currency to my listed prices
as they are in US$ and I am a UK seller. Mainly GBP but I accept many currencies.
The only price difference I have received different the invoice was for Japanese
Yen. I expected this as (I believe) they cannot pay the .xx part of the amount
but must round up (or down?).
If you are setting your own currency rather than using XE.com then this could
account for the difference. Especially as the markets are so volatile just now
due to Brexit.
Neil
|
I thought sellers had to use the BL exchange rate.... and BL does not allow sellers
to use their own exchange rates, the "funny money people" from a few years back
were legislated against in the ToS.
Robert
|
I was just checking that to make sure it's still there and they do have to
use the BL exchange rate provided by XE.com
Quote from ToS 'Using other exchange rates is prohibited. Currency conversion
is done the same way using the same exchange rates in all stores'.
Neil
|
OK, I hope this has not opened up a loophole in that. To clarify, the exchange
rate comes from XE.com at time of order batch submission, my understanding is
that a seller cannot use a rate (even from XE.com) from a different point in
time... as you stated, currencies can move quite quickly at the moment.
Robert
|
I remember the days of "funny money people".. frustration number one for me 
The problem is that I use the exchange rate at the moment of invoicing, so that
should account for the discrepancy. I currently can't think of a way to have
my software use the exchange rate of the moment of submission.. (also, I think
in theory this would also be a slight legal problem as for the tax agency the
purchase takes place at the date of invoice, nothing that happens before that
has any legal status to them.. but that is pretty theoretical, very unlikely
they'd make a fuss over that as long as people have businesses in Panama
 )
|
Your reasoning may be honourable but the intent of the ToS is that it is calculated
at submission.
Think about it from your customer's POV. He is informed of the amount he
has to pay in the currency he selects at the time of purchase and that is what
he is contracting to pay. If he then gets invoiced a different (let's say
higher) amount later that is wrong.
Sorry but you should go with the BL rate like everyone else.
Robert
|
 |
| Author: | Rob_and_Shelagh | | Posted: | Jun 29, 2016 07:10 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 26 times | | Topic: | Suggestions | |
| In Suggestions, maninblack writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, maninblack writes:
| | In Suggestions, Teup writes:
| | Whenever a buyer uses onsite PayPal, I do not receive the amount I instruct in
the invoice, but an up to date conversion of the Bricklink grand total field
in the currency that the buyer chooses. Tax-wise, this is a problem.
Please allow setting a grand total in the actual currency that a buyer chooses
to pay in. This way, the figures of the invoice and the actual payment will match.
I think this is a high priority issue, because technically, it currently forces
us to do something that is technically illegal.
Or is there a way to prevent this that I didn't think of? Retroactively changing
the invoice is the best solution that came to my mind, but that's pretty
tedious.
|
Nearly all of my orders are paid in a different currency to my listed prices
as they are in US$ and I am a UK seller. Mainly GBP but I accept many currencies.
The only price difference I have received different the invoice was for Japanese
Yen. I expected this as (I believe) they cannot pay the .xx part of the amount
but must round up (or down?).
If you are setting your own currency rather than using XE.com then this could
account for the difference. Especially as the markets are so volatile just now
due to Brexit.
Neil
|
I thought sellers had to use the BL exchange rate.... and BL does not allow sellers
to use their own exchange rates, the "funny money people" from a few years back
were legislated against in the ToS.
Robert
|
I was just checking that to make sure it's still there and they do have to
use the BL exchange rate provided by XE.com
Quote from ToS 'Using other exchange rates is prohibited. Currency conversion
is done the same way using the same exchange rates in all stores'.
Neil
|
OK, I hope this has not opened up a loophole in that. To clarify, the exchange
rate comes from XE.com at time of order batch submission, my understanding is
that a seller cannot use a rate (even from XE.com) from a different point in
time... as you stated, currencies can move quite quickly at the moment.
Robert
|
|
| Author: | Rob_and_Shelagh | | Posted: | Jun 29, 2016 06:55 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 23 times | | Topic: | Suggestions | |
| In Suggestions, maninblack writes:
| | In Suggestions, Teup writes:
| | Whenever a buyer uses onsite PayPal, I do not receive the amount I instruct in
the invoice, but an up to date conversion of the Bricklink grand total field
in the currency that the buyer chooses. Tax-wise, this is a problem.
Please allow setting a grand total in the actual currency that a buyer chooses
to pay in. This way, the figures of the invoice and the actual payment will match.
I think this is a high priority issue, because technically, it currently forces
us to do something that is technically illegal.
Or is there a way to prevent this that I didn't think of? Retroactively changing
the invoice is the best solution that came to my mind, but that's pretty
tedious.
|
Nearly all of my orders are paid in a different currency to my listed prices
as they are in US$ and I am a UK seller. Mainly GBP but I accept many currencies.
The only price difference I have received different the invoice was for Japanese
Yen. I expected this as (I believe) they cannot pay the .xx part of the amount
but must round up (or down?).
If you are setting your own currency rather than using XE.com then this could
account for the difference. Especially as the markets are so volatile just now
due to Brexit.
Neil
|
I thought sellers had to use the BL exchange rate.... and BL does not allow sellers
to use their own exchange rates, the "funny money people" from a few years back
were legislated against in the ToS.
Robert
|
|
| Author: | Rob_and_Shelagh | | Posted: | Jun 29, 2016 05:20 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 39 times | | Topic: | Suggestions | |
| In Suggestions, Teup writes:
| | Whenever a buyer uses onsite PayPal, I do not receive the amount I instruct in
the invoice, but an up to date conversion of the Bricklink grand total field
in the currency that the buyer chooses. Tax-wise, this is a problem.
Please allow setting a grand total in the actual currency that a buyer chooses
to pay in. This way, the figures of the invoice and the actual payment will match.
I think this is a high priority issue, because technically, it currently forces
us to do something that is technically illegal.
Or is there a way to prevent this that I didn't think of? Retroactively changing
the invoice is the best solution that came to my mind, but that's pretty
tedious.
|
Any invoice MUST ALWAYS show the amount to be paid, period. Whatever currency
the buyer selects, the amount should be fixed at the time of invoice (or before).
If what you are saying is true then is it:
a) buyers are doing their own conversion and sending a different amount?
b) somehow BL is offering them another figure when they come to pay that differs
from the invoiced amount?
either way, this is not acceptable.
Robert
|
|
| Author: | Rob_and_Shelagh | | Posted: | Mar 2, 2016 12:37 | | Subject: | Re: Self-Insurance Disclosure | | Viewed: | 38 times | | Topic: | Suggestions | |
| In Suggestions, SylvainLS writes:
| | In Suggestions, Brettj666 writes:
| | […]
That being said, the Queen is still our official head of state and when we
mail letters, we lick her head..
|
I thought you were supposed to lick the other side….
|
We don't lick her anymore, she's been replaced by "faceless" RM shipping
labels that don't have the queen on them 
Robert
|
Next Page: 5 More | 10 More | 25 More | 50 More | 100 More
|
|
