|
 |
| | | Author: | Teup  | | Posted: | Jun 29, 2016 04:59 | | Subject: | Problem with onsite PayPal: grand totals | | Viewed: | 182 times | | Topic: | Suggestions | | Status: | Discarded | |
|
| 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.
|
|
| | | | | |
| | | | | 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: | Teup | | Posted: | Jun 29, 2016 05:31 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 39 times | | Topic: | Suggestions | |
|
| In Suggestions, Rob_and_Shelagh 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.
|
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
|
Exactly. Well, I can not be entirely sure. The only thing I am certain about
is that the USD payments I receive with onsite PayPal are slightly off the grand
totals I have in my administration.
The Bricklink grand total only exists in one currency, and that is my own set
currency - not the currency the buyer pays in. So whenever the buyer pays in
another currency, it seems to me that it gets converted for them by Bricklink,
at the moment of payment.. it's a few percent off at least.. it's not
because of any fees or anything; the payments in Euro do match my invoices.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | FigBits | | Posted: | Jun 29, 2016 07:01 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 32 times | | Topic: | Suggestions | |
|
| In Suggestions, Teup writes:
| | In Suggestions, Rob_and_Shelagh 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.
|
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
|
Exactly. Well, I can not be entirely sure. The only thing I am certain about
is that the USD payments I receive with onsite PayPal are slightly off the grand
totals I have in my administration.
The Bricklink grand total only exists in one currency, and that is my own set
currency - not the currency the buyer pays in.
|
On the Order Summary screen, the total shown is in your store currency. But on
the Order Detail screen, it also shows the total in the currency that the buyer
selected. For you, what does this number match? The amount in your invoice or
the amount they paid?
| | So whenever the buyer pays in
another currency, it seems to me that it gets converted for them by Bricklink,
at the moment of payment.. it's a few percent off at least.. it's not
because of any fees or anything; the payments in Euro do match my invoices.
|
After they pay, does the payment status get updated like it does when they use
the Pay button? (And do you have your order status and payment status fields
separated?)
--
Marc.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | Teup | | Posted: | Jun 29, 2016 07:10 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 22 times | | Topic: | Suggestions | |
|
| In Suggestions, FigBits writes:
| | In Suggestions, Teup writes:
| | In Suggestions, Rob_and_Shelagh 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.
|
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
|
Exactly. Well, I can not be entirely sure. The only thing I am certain about
is that the USD payments I receive with onsite PayPal are slightly off the grand
totals I have in my administration.
The Bricklink grand total only exists in one currency, and that is my own set
currency - not the currency the buyer pays in.
|
On the Order Summary screen, the total shown is in your store currency. But on
the Order Detail screen, it also shows the total in the currency that the buyer
selected. For you, what does this number match? The amount in your invoice or
the amount they paid?
| | So whenever the buyer pays in
another currency, it seems to me that it gets converted for them by Bricklink,
at the moment of payment.. it's a few percent off at least.. it's not
because of any fees or anything; the payments in Euro do match my invoices.
|
After they pay, does the payment status get updated like it does when they use
the Pay button? (And do you have your order status and payment status fields
separated?)
--
Marc.
|
Thanks, I had never looked at this before. Yes, they match. (also answer to therobo)
It just doesn't match the grand total that I had calculated for them when
I made the invoice. I wish that "pay grand total" field could be modified, or
that I could use it to make my invoice, but this is a kind of catch 22; I only
get to see this amount after I've already made the invoice. I could retroactively
change the invoice, of course... easier to just switch of onsite payment..
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | therobo | | Posted: | Jun 29, 2016 07:02 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 22 times | | Topic: | Suggestions | |
|
| In Suggestions, Teup writes:
| | In Suggestions, Rob_and_Shelagh 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.
|
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
|
Exactly. Well, I can not be entirely sure. The only thing I am certain about
is that the USD payments I receive with onsite PayPal are slightly off the grand
totals I have in my administration.
The Bricklink grand total only exists in one currency, and that is my own set
currency - not the currency the buyer pays in. So whenever the buyer pays in
another currency, it seems to me that it gets converted for them by Bricklink,
at the moment of payment.. it's a few percent off at least.. it's not
because of any fees or anything; the payments in Euro do match my invoices.
|
Can you post a screenshot of the numbers in the upper right of the order detail
page for one order and also what the buyer has paid exactly?
|
|
|
| | | | | |
| | | | | Author: | paulvdb | | Posted: | Jun 29, 2016 05:28 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 34 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.
|
Is this a recent change? I checked some onsite payments and always received the
amount that I invoiced. Of course most of my buyers pay the same day, but I had
one buyer who was invoiced on June 10 and paid on June 16. For that order the
invoice and onsite payment were both for USD 52.70.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | Teup | | Posted: | Jun 29, 2016 05:37 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 31 times | | Topic: | Suggestions | |
|
| In Suggestions, paulvdb 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.
|
Is this a recent change? I checked some onsite payments and always received the
amount that I invoiced. Of course most of my buyers pay the same day, but I had
one buyer who was invoiced on June 10 and paid on June 16. For that order the
invoice and onsite payment were both for USD 52.70.
|
I don't really know, I have been away and not extensively been testing onsite
PayPal.. 6 days and the exact same number, that can't be coincidence.. how
is that even possible, though? Do buyers enter their own amount with onsite payment
or is it generated by Bricklink?
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | paulvdb | | Posted: | Jun 29, 2016 07:29 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 24 times | | Topic: | Suggestions | |
|
| In Suggestions, Teup writes:
| | In Suggestions, paulvdb 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.
|
Is this a recent change? I checked some onsite payments and always received the
amount that I invoiced. Of course most of my buyers pay the same day, but I had
one buyer who was invoiced on June 10 and paid on June 16. For that order the
invoice and onsite payment were both for USD 52.70.
|
I don't really know, I have been away and not extensively been testing onsite
PayPal.. 6 days and the exact same number, that can't be coincidence.. how
is that even possible, though? Do buyers enter their own amount with onsite payment
or is it generated by Bricklink?
|
For onsite payment the amount paid is generated by Bricklink. It is the same
as the amount that you see in the order details screen and also the same amount
that you see when you use the DISPGRANDTOTAL tag in your invoice template. Based
on your other posts it seems that you generate your own invoice and don't
use the Bricklink invoice template? I guess that could cause a difference in
grand total.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | WoutR | | Posted: | Jun 29, 2016 07:36 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 21 times | | Topic: | Suggestions | |
|
| In Suggestions, paulvdb writes:
| | In Suggestions, Teup writes:
| | In Suggestions, paulvdb 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.
|
Is this a recent change? I checked some onsite payments and always received the
amount that I invoiced. Of course most of my buyers pay the same day, but I had
one buyer who was invoiced on June 10 and paid on June 16. For that order the
invoice and onsite payment were both for USD 52.70.
|
I don't really know, I have been away and not extensively been testing onsite
PayPal.. 6 days and the exact same number, that can't be coincidence.. how
is that even possible, though? Do buyers enter their own amount with onsite payment
or is it generated by Bricklink?
|
For onsite payment the amount paid is generated by Bricklink. It is the same
as the amount that you see in the order details screen and also the same amount
that you see when you use the DISPGRANDTOTAL tag in your invoice template. Based
on your other posts it seems that you generate your own invoice and don't
use the Bricklink invoice template? I guess that could cause a difference in
grand total.
|
How about this one..
1) Bricklink calculates the order total in the store currency
2) Bricklink shows a currency conversion using the XE.com exchange rates
3) PayPal onsite reads one of these values, but uses its own exchange rate
4) There is a currency conversation difference, causing the buyer to pay a different
amount or the seller to receive a different amount.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | Teup | | Posted: | Jun 29, 2016 07:37 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 25 times | | Topic: | Suggestions | |
|
| In Suggestions, paulvdb writes:
| | In Suggestions, Teup writes:
| | In Suggestions, paulvdb 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.
|
Is this a recent change? I checked some onsite payments and always received the
amount that I invoiced. Of course most of my buyers pay the same day, but I had
one buyer who was invoiced on June 10 and paid on June 16. For that order the
invoice and onsite payment were both for USD 52.70.
|
I don't really know, I have been away and not extensively been testing onsite
PayPal.. 6 days and the exact same number, that can't be coincidence.. how
is that even possible, though? Do buyers enter their own amount with onsite payment
or is it generated by Bricklink?
|
For onsite payment the amount paid is generated by Bricklink. It is the same
as the amount that you see in the order details screen and also the same amount
that you see when you use the DISPGRANDTOTAL tag in your invoice template. Based
on your other posts it seems that you generate your own invoice and don't
use the Bricklink invoice template? I guess that could cause a difference in
grand total.
|
Yeah, I see.. Yes, so I never really used these fields, but now that there's
onsite payment, I sort of need to.
I use the BL macros to generate a list of all the relevant data, and then feed
that into my software. What I could do is use that DISPGRANDTOTAL tag you mentioned
to triangulate the used exchange rate, by dividing that by the item total in
Euro. However, when someone adds a batch and I invoice again, and there are shipping
costs / additional charges already filled out, it will no longer represent the
item total. Seems there's no DISPITEMTOTAL, or, better yet, a tag for the
exchange rate.. I have requested this in a suggestion in the past, but it was
never accepted.
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | FigBits | | Posted: | Jun 29, 2016 09:39 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 32 times | | Topic: | Suggestions | |
|
| In Suggestions, Teup writes:
| | In Suggestions, paulvdb writes:
| | In Suggestions, Teup writes:
| | In Suggestions, paulvdb 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.
|
Is this a recent change? I checked some onsite payments and always received the
amount that I invoiced. Of course most of my buyers pay the same day, but I had
one buyer who was invoiced on June 10 and paid on June 16. For that order the
invoice and onsite payment were both for USD 52.70.
|
I don't really know, I have been away and not extensively been testing onsite
PayPal.. 6 days and the exact same number, that can't be coincidence.. how
is that even possible, though? Do buyers enter their own amount with onsite payment
or is it generated by Bricklink?
|
For onsite payment the amount paid is generated by Bricklink. It is the same
as the amount that you see in the order details screen and also the same amount
that you see when you use the DISPGRANDTOTAL tag in your invoice template. Based
on your other posts it seems that you generate your own invoice and don't
use the Bricklink invoice template? I guess that could cause a difference in
grand total.
|
Yeah, I see.. Yes, so I never really used these fields, but now that there's
onsite payment, I sort of need to.
I use the BL macros to generate a list of all the relevant data, and then feed
that into my software. What I could do is use that DISPGRANDTOTAL tag you mentioned
to triangulate the used exchange rate, by dividing that by the item total in
Euro. However, when someone adds a batch and I invoice again, and there are shipping
costs / additional charges already filled out, it will no longer represent the
item total. Seems there's no DISPITEMTOTAL, or, better yet, a tag for the
exchange rate.. I have requested this in a suggestion in the past, but it was
never accepted.
|
When a batch is added the cost of all the previous batches is recalculated at
the current exchange rate. (A side effect of this is that a buyer could lower
their total cost in their own currency by adding a small item to an order if
the value of their currency has increased since originally placing the order.)
So, you should always be able to calculate the exchange rate that BL is using
by comparing BASEGRANDTOTAL and DISPGRANDTOTAL.
--
Marc.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | Teup | | Posted: | Jun 29, 2016 10:23 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 22 times | | Topic: | Suggestions | |
|
| In Suggestions, FigBits writes:
| | In Suggestions, Teup writes:
| | In Suggestions, paulvdb writes:
| | In Suggestions, Teup writes:
| | In Suggestions, paulvdb 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.
|
Is this a recent change? I checked some onsite payments and always received the
amount that I invoiced. Of course most of my buyers pay the same day, but I had
one buyer who was invoiced on June 10 and paid on June 16. For that order the
invoice and onsite payment were both for USD 52.70.
|
I don't really know, I have been away and not extensively been testing onsite
PayPal.. 6 days and the exact same number, that can't be coincidence.. how
is that even possible, though? Do buyers enter their own amount with onsite payment
or is it generated by Bricklink?
|
For onsite payment the amount paid is generated by Bricklink. It is the same
as the amount that you see in the order details screen and also the same amount
that you see when you use the DISPGRANDTOTAL tag in your invoice template. Based
on your other posts it seems that you generate your own invoice and don't
use the Bricklink invoice template? I guess that could cause a difference in
grand total.
|
Yeah, I see.. Yes, so I never really used these fields, but now that there's
onsite payment, I sort of need to.
I use the BL macros to generate a list of all the relevant data, and then feed
that into my software. What I could do is use that DISPGRANDTOTAL tag you mentioned
to triangulate the used exchange rate, by dividing that by the item total in
Euro. However, when someone adds a batch and I invoice again, and there are shipping
costs / additional charges already filled out, it will no longer represent the
item total. Seems there's no DISPITEMTOTAL, or, better yet, a tag for the
exchange rate.. I have requested this in a suggestion in the past, but it was
never accepted.
|
When a batch is added the cost of all the previous batches is recalculated at
the current exchange rate. (A side effect of this is that a buyer could lower
their total cost in their own currency by adding a small item to an order if
the value of their currency has increased since originally placing the order.)
So, you should always be able to calculate the exchange rate that BL is using
by comparing BASEGRANDTOTAL and DISPGRANDTOTAL.
--
Marc.
|
Yeah, you are correct, I realised it later. Whether I have at that stage updated
my additional charges fields or not should be irrelevant, comparing those two
should always provide me with the exchange rate that was used. I can then use
that rate as a starting point for generating my invoices with my software.
|
|
|
| | | | | |
| | | | | Author: | maninblack | | Posted: | Jun 29, 2016 06:43 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 31 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.
|
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
|
|
|
| | | | | | | | | |
| | | | | | | 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: | maninblack | | Posted: | Jun 29, 2016 07:03 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 21 times | | Topic: | Suggestions | |
|
| 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
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | 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: | Teup | | Posted: | Jun 29, 2016 07:17 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 27 times | | Topic: | Suggestions | |
|
| 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
 )
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | 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: | Teup | | Posted: | Jun 29, 2016 07:42 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 24 times | | Topic: | Suggestions | |
|
| In Suggestions, Rob_and_Shelagh writes:
| | 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
|
I understand that, I only once had a question about it and when I explained the
customer fully agreed, though. Well, let's put this aside and say that I
am willing to change to the BL policy even if that technically violates tax law
in this country (I personally don't really mind whether I am scenario A
or scenario B inaccurate  as long as I can be consistent) - I'm not sure
how I can change it, because BL does not have an exchange rate tag in the invoice
that I can use. I will need to know the used exchange rate in order to know what
the shipping & handling costs would look like with that same rate. Currently
I can only infer it after I've sent the invoice and look at that "pay grand
total"..
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | Author: | Rob_and_Shelagh | | Posted: | Jun 29, 2016 07:51 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 26 times | | Topic: | Suggestions | |
|
| In Suggestions, Teup writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | 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
|
I understand that, I only once had a question about it and when I explained the
customer fully agreed, though. Well, let's put this aside and say that I
am willing to change to the BL policy even if that technically violates tax law
in this country (I personally don't really mind whether I am scenario A
or scenario B inaccurate as long as I can be consistent) - I'm not sure
how I can change it, because BL does not have an exchange rate tag in the invoice
that I can use. I will need to know the used exchange rate in order to know what
the shipping & handling costs would look like with that same rate. Currently
I can only infer it after I've sent the invoice and look at that "pay grand
total"..
|
Your shipping and handling costs are not calculated and entered in your own store
currency? Then they are converted by BL to the pay currency at the BL exchange
rate?
I think you just need to change your procedure. Also note you are creating a
BL valid reason for a buyer to request cancellation of an order.
Robert
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | Jun 29, 2016 08:00 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 34 times | | Topic: | Suggestions | |
|
| In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, Teup writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | 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
|
I understand that, I only once had a question about it and when I explained the
customer fully agreed, though. Well, let's put this aside and say that I
am willing to change to the BL policy even if that technically violates tax law
in this country (I personally don't really mind whether I am scenario A
or scenario B inaccurate as long as I can be consistent) - I'm not sure
how I can change it, because BL does not have an exchange rate tag in the invoice
that I can use. I will need to know the used exchange rate in order to know what
the shipping & handling costs would look like with that same rate. Currently
I can only infer it after I've sent the invoice and look at that "pay grand
total"..
|
Your shipping and handling costs are not calculated and entered in your own store
currency? Then they are converted by BL to the pay currency at the BL exchange
rate?
I think you just need to change your procedure. Also note you are creating a
BL valid reason for a buyer to request cancellation of an order.
Robert
|
Yes they are, that is exactly the problem. Because I need to convert them to
the currency of the buyer, at the time the buyer placed the order.
Yes, they may cancel the order, I accept that. Alternatively however I need to
sell a buyer shipping or insurance at an exchange rate from the past, that is
equally strange. It's a choice between doing something illegal and violating
BL terms.. but still, I really don't mind changing if only I understood how.
Curiously the invoice tags return the grand total of the buyer, the currency
code of the buyer, the currency name of the buyer and the currency sign of the
buyer, but NOT the item total or the exchange rate of the buyer.. those
seem far more interesting to me.. I need either these fields, or use the
Bricklink invoice system. But I can't create a legally valid invoice using
only the Bricklink system and relying on the "pay grand total" field.. I need
to do it with my software or otherwise I will have bigger problems with the tax
agency than just currencies that are slightly off..
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | Jun 29, 2016 08:07 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 23 times | | Topic: | Suggestions | |
|
| In Suggestions, Teup writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, Teup writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | 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
|
I understand that, I only once had a question about it and when I explained the
customer fully agreed, though. Well, let's put this aside and say that I
am willing to change to the BL policy even if that technically violates tax law
in this country (I personally don't really mind whether I am scenario A
or scenario B inaccurate as long as I can be consistent) - I'm not sure
how I can change it, because BL does not have an exchange rate tag in the invoice
that I can use. I will need to know the used exchange rate in order to know what
the shipping & handling costs would look like with that same rate. Currently
I can only infer it after I've sent the invoice and look at that "pay grand
total"..
|
Your shipping and handling costs are not calculated and entered in your own store
currency? Then they are converted by BL to the pay currency at the BL exchange
rate?
I think you just need to change your procedure. Also note you are creating a
BL valid reason for a buyer to request cancellation of an order.
Robert
|
Yes they are, that is exactly the problem. Because I need to convert them to
the currency of the buyer, at the time the buyer placed the order.
Yes, they may cancel the order, I accept that. Alternatively however I need to
sell a buyer shipping or insurance at an exchange rate from the past, that is
equally strange. It's a choice between doing something illegal and violating
BL terms.. but still, I really don't mind changing if only I understood how.
Curiously the invoice tags return the grand total of the buyer, the currency
code of the buyer, the currency name of the buyer and the currency sign of the
buyer, but NOT the item total or the exchange rate of the buyer.. those
seem far more interesting to me.. I need either these fields, or use the
Bricklink invoice system. But I can't create a legally valid invoice using
only the Bricklink system and relying on the "pay grand total" field.. I need
to do it with my software or otherwise I will have bigger problems with the tax
agency than just currencies that are slightly off..
|
Wait, I could divide BASEGRANDTOTAL by DISPGRANDTOTAL.. use that as the exchange
rate. And when the buyer pays in Euro, use the XE.com exchange rate for figuring
out the hypothetical dollar grand total, to get a consistent and complete euro-dollar
administration. Think I will do that..
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | Author: | therobo | | Posted: | Jun 29, 2016 09:51 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 38 times | | Topic: | Suggestions | |
|
| In Suggestions, Teup writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, Teup writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | 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
|
I understand that, I only once had a question about it and when I explained the
customer fully agreed, though. Well, let's put this aside and say that I
am willing to change to the BL policy even if that technically violates tax law
in this country (I personally don't really mind whether I am scenario A
or scenario B inaccurate as long as I can be consistent) - I'm not sure
how I can change it, because BL does not have an exchange rate tag in the invoice
that I can use. I will need to know the used exchange rate in order to know what
the shipping & handling costs would look like with that same rate. Currently
I can only infer it after I've sent the invoice and look at that "pay grand
total"..
|
Your shipping and handling costs are not calculated and entered in your own store
currency? Then they are converted by BL to the pay currency at the BL exchange
rate?
I think you just need to change your procedure. Also note you are creating a
BL valid reason for a buyer to request cancellation of an order.
Robert
|
Yes they are, that is exactly the problem. Because I need to convert them to
the currency of the buyer, at the time the buyer placed the order.
|
You don't need to convert s&h to the buyer's currency.
Your store prices are in €, your s&h prices are in €.
The € sum is converted to the buyer's currency at the time of the last order
batch and that's all he needs.
| |
Yes, they may cancel the order, I accept that. Alternatively however I need to
sell a buyer shipping or insurance at an exchange rate from the past, that is
equally strange. It's a choice between doing something illegal and violating
BL terms.. but still, I really don't mind changing if only I understood how.
Curiously the invoice tags return the grand total of the buyer, the currency
code of the buyer, the currency name of the buyer and the currency sign of the
buyer, but NOT the item total or the exchange rate of the buyer.. those
seem far more interesting to me.. I need either these fields, or use the
Bricklink invoice system. But I can't create a legally valid invoice using
only the Bricklink system and relying on the "pay grand total" field.. I need
to do it with my software or otherwise I will have bigger problems with the tax
agency than just currencies that are slightly off..
|
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | Jun 29, 2016 10:20 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 24 times | | Topic: | Suggestions | |
|
| In Suggestions, therobo writes:
| | In Suggestions, Teup writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, Teup writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | 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
|
I understand that, I only once had a question about it and when I explained the
customer fully agreed, though. Well, let's put this aside and say that I
am willing to change to the BL policy even if that technically violates tax law
in this country (I personally don't really mind whether I am scenario A
or scenario B inaccurate as long as I can be consistent) - I'm not sure
how I can change it, because BL does not have an exchange rate tag in the invoice
that I can use. I will need to know the used exchange rate in order to know what
the shipping & handling costs would look like with that same rate. Currently
I can only infer it after I've sent the invoice and look at that "pay grand
total"..
|
Your shipping and handling costs are not calculated and entered in your own store
currency? Then they are converted by BL to the pay currency at the BL exchange
rate?
I think you just need to change your procedure. Also note you are creating a
BL valid reason for a buyer to request cancellation of an order.
Robert
|
Yes they are, that is exactly the problem. Because I need to convert them to
the currency of the buyer, at the time the buyer placed the order.
|
You don't need to convert s&h to the buyer's currency.
Your store prices are in €, your s&h prices are in €.
The € sum is converted to the buyer's currency at the time of the last order
batch and that's all he needs.
|
True, but it's not all I need My invoice needs to account for the
funds that I receive. It needs to "predict" the right amount that will come in.
I will try dividing BASEGRANDTOTAL by DISPGRANDTOTAL, use that factor on items+S&H+credit
in Euro. That should probably (hopefully) allow me to arrive at the same grand
total in dollar as bricklink will display after I've sent my invoice.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | TheBrickGuys | | Posted: | Jun 29, 2016 14:34 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 39 times | | Topic: | Suggestions | |
|
| | | 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
|
Just out of curiosity, what is the advantage of listing your inventory in US
dollars instead of your own default currency, especially sense most of your orders
are from your home country?
Jim.
|
|
|
| | | | | |
| | | | | Author: | enig | | Posted: | Jun 29, 2016 08:15 | | 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.
|
Also recently had an issue where quoted amount (via our brilliant) differed from
invoiced amount because of USD/EUR fluctuations.
And I thought the quoting feature can not possibly be broken any more than it
already was. But they did it. Now quoted amount is no longer the amount showing
up once the quote is accepted. What was the single most important purpose
of the quoting system again?
Anyone who is still thinking that we have competent people working on BL needs
to wake up.
I am sorry I can not be more positive. I know someone up there is trying. But
you need ti try harder. PLEASE.
|
|
|
|
| | | | | | | | | |
| | | | | | | Author: | Teup | | Posted: | Jun 29, 2016 08:24 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 23 times | | Topic: | Suggestions | |
|
| In Suggestions, enig writes:
| | Now quoted amount is no longer the amount showing
up once the quote is accepted. What was the single most important purpose
of the quoting system again?
|
Haha That's awkward.. why can't we all just have 1 currency in the
world and every single issue would be solved.. this currency problem is horrible,
what if people add more items.. what if people remove items.. what about shipping
costs.. what about this, that.. it's just a nightmare It's not some
tricky or difficult math problem, it's something that's impossible to
solve in a 100% correct way..
|
|
| | | | | | | | | |
| | | | | | | Author: | Rob_and_Shelagh | | Posted: | Jun 29, 2016 08:24 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 29 times | | Topic: | Suggestions | |
|
| In Suggestions, enig 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.
|
Also recently had an issue where quoted amount (via our brilliant) differed from
invoiced amount because of USD/EUR fluctuations.
And I thought the quoting feature can not possibly be broken any more than it
already was. But they did it. Now quoted amount is no longer the amount showing
up once the quote is accepted. What was the single most important purpose
of the quoting system again?
Anyone who is still thinking that we have competent people working on BL needs
to wake up.
I am sorry I can not be more positive. I know someone up there is trying. But
you need ti try harder. PLEASE.
|
I can't see how it could do better in this case. The quote and the order
are the same value in your store currency. The fact that the USD rate changed
between the 2 events is outside BL's control. The only other way would be
to fix the USD amount then return a different EURO amount which makes no sense
to me, IMO the local store currency is your "offer" and the buyer risks exchange
difference (either way) by delaying placing an order.
Robert
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | enig | | Posted: | Jun 29, 2016 08:37 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 21 times | | Topic: | Suggestions | |
|
| In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig 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.
|
Also recently had an issue where quoted amount (via our brilliant) differed from
invoiced amount because of USD/EUR fluctuations.
And I thought the quoting feature can not possibly be broken any more than it
already was. But they did it. Now quoted amount is no longer the amount showing
up once the quote is accepted. What was the single most important purpose
of the quoting system again?
Anyone who is still thinking that we have competent people working on BL needs
to wake up.
I am sorry I can not be more positive. I know someone up there is trying. But
you need ti try harder. PLEASE.
|
I can't see how it could do better in this case. The quote and the order
are the same value in your store currency. The fact that the USD rate changed
between the 2 events is outside BL's control. The only other way would be
to fix the USD amount then return a different EURO amount which makes no sense
to me, IMO the local store currency is your "offer" and the buyer risks exchange
difference (either way) by delaying placing an order.
Robert
|
Has it always been like this?
Anyways.
The purpose of the Price Quote feature is to provide an option for buyers
to request a quote before entering into an order contract. The buyer will know
the final cost of an order before placing the order, while the seller
can suggest a final price without holding inventory.
http://www.bricklink.com/help.asp?helpID=2437
In this case a buyer was looking at the quoted amount and clicked "accept". The
amount changed at that instant.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | Rob_and_Shelagh | | Posted: | Jun 29, 2016 08:46 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 27 times | | Topic: | Suggestions | |
|
| In Suggestions, enig writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig 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.
|
Also recently had an issue where quoted amount (via our brilliant) differed from
invoiced amount because of USD/EUR fluctuations.
And I thought the quoting feature can not possibly be broken any more than it
already was. But they did it. Now quoted amount is no longer the amount showing
up once the quote is accepted. What was the single most important purpose
of the quoting system again?
Anyone who is still thinking that we have competent people working on BL needs
to wake up.
I am sorry I can not be more positive. I know someone up there is trying. But
you need ti try harder. PLEASE.
|
I can't see how it could do better in this case. The quote and the order
are the same value in your store currency. The fact that the USD rate changed
between the 2 events is outside BL's control. The only other way would be
to fix the USD amount then return a different EURO amount which makes no sense
to me, IMO the local store currency is your "offer" and the buyer risks exchange
difference (either way) by delaying placing an order.
Robert
|
Has it always been like this?
Anyways.
The purpose of the Price Quote feature is to provide an option for buyers
to request a quote before entering into an order contract. The buyer will know
the final cost of an order before placing the order, while the seller
can suggest a final price without holding inventory.
http://www.bricklink.com/help.asp?helpID=2437
In this case a buyer was looking at the quoted amount and clicked "accept". The
amount changed at that instant.
|
Yes I think it has always been like that but good point! I think the wording
should include something that says the "store price quote is fixed but if paying
in a different currency than the store's the rate might fluctuate between
quote and order, the actual conversion will be done using BL/XE rate at time
of order submission"... in line with what is stated for ordinary unquoted orders.
I don't think it would be fair to hold sellers to a currency converted quote
as anything could happen between quote and order with the rate, the buyer on
the other hand has the option simply not to go ahead if his currency collapses.
Robert
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | enig | | Posted: | Jun 29, 2016 09:31 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 31 times | | Topic: | Suggestions | |
|
| In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig 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.
|
Also recently had an issue where quoted amount (via our brilliant) differed from
invoiced amount because of USD/EUR fluctuations.
And I thought the quoting feature can not possibly be broken any more than it
already was. But they did it. Now quoted amount is no longer the amount showing
up once the quote is accepted. What was the single most important purpose
of the quoting system again?
Anyone who is still thinking that we have competent people working on BL needs
to wake up.
I am sorry I can not be more positive. I know someone up there is trying. But
you need ti try harder. PLEASE.
|
I can't see how it could do better in this case. The quote and the order
are the same value in your store currency. The fact that the USD rate changed
between the 2 events is outside BL's control. The only other way would be
to fix the USD amount then return a different EURO amount which makes no sense
to me, IMO the local store currency is your "offer" and the buyer risks exchange
difference (either way) by delaying placing an order.
Robert
|
Has it always been like this?
Anyways.
The purpose of the Price Quote feature is to provide an option for buyers
to request a quote before entering into an order contract. The buyer will know
the final cost of an order before placing the order, while the seller
can suggest a final price without holding inventory.
http://www.bricklink.com/help.asp?helpID=2437
In this case a buyer was looking at the quoted amount and clicked "accept". The
amount changed at that instant.
|
Yes I think it has always been like that but good point! I think the wording
should include something that says the "store price quote is fixed but if paying
in a different currency than the store's the rate might fluctuate between
quote and order, the actual conversion will be done using BL/XE rate at time
of order submission"... in line with what is stated for ordinary unquoted orders.
I don't think it would be fair to hold sellers to a currency converted quote
as anything could happen between quote and order with the rate, the buyer on
the other hand has the option simply not to go ahead if his currency collapses.
Robert
|
Just to be clear - this is in no way a rant because I am getting a few cents
less, in case anyone is wondering I had the quote feature enabled temporarily
and simply forgot to turn it off. This was the very fist quote ever accepted
at this store, and it was actually my customer who brought this up - he was confused.
I would have never noticed. First quote, first customer (less than 10 FB), first
hiccup.
Where I am getting is - I do not believe that no one has asked this question
before. How long ago have we had the quoting feature implemented?
I'd say the quoting should work exactly as currently described. The exact
quoted amount, (in whichever currency the buyer has requested) should be carried
into the invoice. That's the reason for the quote as I see it. The quote
is for the buyer, not for the seller.
You are right - BL has no control over the currency fluctuations. It has always
been the case. Seller's prices are in EUR, buyer selects USD. Between the
time of order/invoice and the payment, the amount the seller is getting (if he
were to exchange immediately) is almost always a little + or -. At the same time,
same is true for the buyer if he's paying in other currency than he's
holding. The amount going out of his pocket depends on the currency ratios at
the time of payment.
Shouldn't quotes work in the same principle? I see quote as a draft for the
invoice. Seller quotes the amounts minus the payment details. If the buyer accepts
the quoted amount (in the currency he requested the quote in), he gets the payment
details.
It should not matter if the currency ratios change. Buyer is requesting a final
amount before committing to the order. It should be exactly that. The currency
ratio at the time of the quote should be carried into the invoice.
My two cents.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | Rob_and_Shelagh | | Posted: | Jun 29, 2016 10:06 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 25 times | | Topic: | Suggestions | |
|
| In Suggestions, enig writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig 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.
|
Also recently had an issue where quoted amount (via our brilliant) differed from
invoiced amount because of USD/EUR fluctuations.
And I thought the quoting feature can not possibly be broken any more than it
already was. But they did it. Now quoted amount is no longer the amount showing
up once the quote is accepted. What was the single most important purpose
of the quoting system again?
Anyone who is still thinking that we have competent people working on BL needs
to wake up.
I am sorry I can not be more positive. I know someone up there is trying. But
you need ti try harder. PLEASE.
|
I can't see how it could do better in this case. The quote and the order
are the same value in your store currency. The fact that the USD rate changed
between the 2 events is outside BL's control. The only other way would be
to fix the USD amount then return a different EURO amount which makes no sense
to me, IMO the local store currency is your "offer" and the buyer risks exchange
difference (either way) by delaying placing an order.
Robert
|
Has it always been like this?
Anyways.
The purpose of the Price Quote feature is to provide an option for buyers
to request a quote before entering into an order contract. The buyer will know
the final cost of an order before placing the order, while the seller
can suggest a final price without holding inventory.
http://www.bricklink.com/help.asp?helpID=2437
In this case a buyer was looking at the quoted amount and clicked "accept". The
amount changed at that instant.
|
Yes I think it has always been like that but good point! I think the wording
should include something that says the "store price quote is fixed but if paying
in a different currency than the store's the rate might fluctuate between
quote and order, the actual conversion will be done using BL/XE rate at time
of order submission"... in line with what is stated for ordinary unquoted orders.
I don't think it would be fair to hold sellers to a currency converted quote
as anything could happen between quote and order with the rate, the buyer on
the other hand has the option simply not to go ahead if his currency collapses.
Robert
|
Just to be clear - this is in no way a rant because I am getting a few cents
less, in case anyone is wondering I had the quote feature enabled temporarily
and simply forgot to turn it off. This was the very fist quote ever accepted
at this store, and it was actually my customer who brought this up - he was confused.
I would have never noticed. First quote, first customer (less than 10 FB), first
hiccup.
Where I am getting is - I do not believe that no one has asked this question
before. How long ago have we had the quoting feature implemented?
I'd say the quoting should work exactly as currently described. The exact
quoted amount, (in whichever currency the buyer has requested) should be carried
into the invoice. That's the reason for the quote as I see it. The quote
is for the buyer, not for the seller.
You are right - BL has no control over the currency fluctuations. It has always
been the case. Seller's prices are in EUR, buyer selects USD. Between the
time of order/invoice and the payment, the amount the seller is getting (if he
were to exchange immediately) is almost always a little + or -. At the same time,
same is true for the buyer if he's paying in other currency than he's
holding. The amount going out of his pocket depends on the currency ratios at
the time of payment.
Shouldn't quotes work in the same principle? I see quote as a draft for the
invoice. Seller quotes the amounts minus the payment details. If the buyer accepts
the quoted amount (in the currency he requested the quote in), he gets the payment
details.
It should not matter if the currency ratios change. Buyer is requesting a final
amount before committing to the order. It should be exactly that. The currency
ratio at the time of the quote should be carried into the invoice.
My two cents.
|
It depends on what a seller intends to quote. If he is simply quoting goods plus
shipping in his store currency and he is not intending to make a forex quote
then current set up seems correct. If on the other hand he wants to give a fixed
foreign currency quote then the current system does not do that. Maybe the system
should offer both options?? We don't use it anyway for other reasons at the
moment so I'm open minded on a debate about enhancing the feature.
Robert
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | Author: | enig | | Posted: | Jun 29, 2016 10:19 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 27 times | | Topic: | Suggestions | |
|
| In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig 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.
|
Also recently had an issue where quoted amount (via our brilliant) differed from
invoiced amount because of USD/EUR fluctuations.
And I thought the quoting feature can not possibly be broken any more than it
already was. But they did it. Now quoted amount is no longer the amount showing
up once the quote is accepted. What was the single most important purpose
of the quoting system again?
Anyone who is still thinking that we have competent people working on BL needs
to wake up.
I am sorry I can not be more positive. I know someone up there is trying. But
you need ti try harder. PLEASE.
|
I can't see how it could do better in this case. The quote and the order
are the same value in your store currency. The fact that the USD rate changed
between the 2 events is outside BL's control. The only other way would be
to fix the USD amount then return a different EURO amount which makes no sense
to me, IMO the local store currency is your "offer" and the buyer risks exchange
difference (either way) by delaying placing an order.
Robert
|
Has it always been like this?
Anyways.
The purpose of the Price Quote feature is to provide an option for buyers
to request a quote before entering into an order contract. The buyer will know
the final cost of an order before placing the order, while the seller
can suggest a final price without holding inventory.
http://www.bricklink.com/help.asp?helpID=2437
In this case a buyer was looking at the quoted amount and clicked "accept". The
amount changed at that instant.
|
Yes I think it has always been like that but good point! I think the wording
should include something that says the "store price quote is fixed but if paying
in a different currency than the store's the rate might fluctuate between
quote and order, the actual conversion will be done using BL/XE rate at time
of order submission"... in line with what is stated for ordinary unquoted orders.
I don't think it would be fair to hold sellers to a currency converted quote
as anything could happen between quote and order with the rate, the buyer on
the other hand has the option simply not to go ahead if his currency collapses.
Robert
|
Just to be clear - this is in no way a rant because I am getting a few cents
less, in case anyone is wondering I had the quote feature enabled temporarily
and simply forgot to turn it off. This was the very fist quote ever accepted
at this store, and it was actually my customer who brought this up - he was confused.
I would have never noticed. First quote, first customer (less than 10 FB), first
hiccup.
Where I am getting is - I do not believe that no one has asked this question
before. How long ago have we had the quoting feature implemented?
I'd say the quoting should work exactly as currently described. The exact
quoted amount, (in whichever currency the buyer has requested) should be carried
into the invoice. That's the reason for the quote as I see it. The quote
is for the buyer, not for the seller.
You are right - BL has no control over the currency fluctuations. It has always
been the case. Seller's prices are in EUR, buyer selects USD. Between the
time of order/invoice and the payment, the amount the seller is getting (if he
were to exchange immediately) is almost always a little + or -. At the same time,
same is true for the buyer if he's paying in other currency than he's
holding. The amount going out of his pocket depends on the currency ratios at
the time of payment.
Shouldn't quotes work in the same principle? I see quote as a draft for the
invoice. Seller quotes the amounts minus the payment details. If the buyer accepts
the quoted amount (in the currency he requested the quote in), he gets the payment
details.
It should not matter if the currency ratios change. Buyer is requesting a final
amount before committing to the order. It should be exactly that. The currency
ratio at the time of the quote should be carried into the invoice.
My two cents.
|
It depends on what a seller intends to quote. If he is simply quoting goods plus
shipping in his store currency and he is not intending to make a forex quote
then current set up seems correct. If on the other hand he wants to give a fixed
foreign currency quote then the current system does not do that. Maybe the system
should offer both options?? We don't use it anyway for other reasons at the
moment so I'm open minded on a debate about enhancing the feature.
Robert
|
I am not fond of the quotes either, to say the least. Left it enabled by mistake.
I think I will try asking my buyers directly whether they would have placed the
orders regardless of the quote option at my store, and decide what I do then.
As for how it should work - perhaps someone should look into (German?) law and
see if there is a section covering this very matter. That's the reason why
BL was cursed with this thing in the first place. It should work exactly as the
Law requires.
I would guess that the Law needs the quoted price at the bottom of the equation
to be final, but it's only a guess.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | Author: | Rob_and_Shelagh | | Posted: | Jun 29, 2016 10:29 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 34 times | | Topic: | Suggestions | |
|
| In Suggestions, enig writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig 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.
|
Also recently had an issue where quoted amount (via our brilliant) differed from
invoiced amount because of USD/EUR fluctuations.
And I thought the quoting feature can not possibly be broken any more than it
already was. But they did it. Now quoted amount is no longer the amount showing
up once the quote is accepted. What was the single most important purpose
of the quoting system again?
Anyone who is still thinking that we have competent people working on BL needs
to wake up.
I am sorry I can not be more positive. I know someone up there is trying. But
you need ti try harder. PLEASE.
|
I can't see how it could do better in this case. The quote and the order
are the same value in your store currency. The fact that the USD rate changed
between the 2 events is outside BL's control. The only other way would be
to fix the USD amount then return a different EURO amount which makes no sense
to me, IMO the local store currency is your "offer" and the buyer risks exchange
difference (either way) by delaying placing an order.
Robert
|
Has it always been like this?
Anyways.
The purpose of the Price Quote feature is to provide an option for buyers
to request a quote before entering into an order contract. The buyer will know
the final cost of an order before placing the order, while the seller
can suggest a final price without holding inventory.
http://www.bricklink.com/help.asp?helpID=2437
In this case a buyer was looking at the quoted amount and clicked "accept". The
amount changed at that instant.
|
Yes I think it has always been like that but good point! I think the wording
should include something that says the "store price quote is fixed but if paying
in a different currency than the store's the rate might fluctuate between
quote and order, the actual conversion will be done using BL/XE rate at time
of order submission"... in line with what is stated for ordinary unquoted orders.
I don't think it would be fair to hold sellers to a currency converted quote
as anything could happen between quote and order with the rate, the buyer on
the other hand has the option simply not to go ahead if his currency collapses.
Robert
|
Just to be clear - this is in no way a rant because I am getting a few cents
less, in case anyone is wondering I had the quote feature enabled temporarily
and simply forgot to turn it off. This was the very fist quote ever accepted
at this store, and it was actually my customer who brought this up - he was confused.
I would have never noticed. First quote, first customer (less than 10 FB), first
hiccup.
Where I am getting is - I do not believe that no one has asked this question
before. How long ago have we had the quoting feature implemented?
I'd say the quoting should work exactly as currently described. The exact
quoted amount, (in whichever currency the buyer has requested) should be carried
into the invoice. That's the reason for the quote as I see it. The quote
is for the buyer, not for the seller.
You are right - BL has no control over the currency fluctuations. It has always
been the case. Seller's prices are in EUR, buyer selects USD. Between the
time of order/invoice and the payment, the amount the seller is getting (if he
were to exchange immediately) is almost always a little + or -. At the same time,
same is true for the buyer if he's paying in other currency than he's
holding. The amount going out of his pocket depends on the currency ratios at
the time of payment.
Shouldn't quotes work in the same principle? I see quote as a draft for the
invoice. Seller quotes the amounts minus the payment details. If the buyer accepts
the quoted amount (in the currency he requested the quote in), he gets the payment
details.
It should not matter if the currency ratios change. Buyer is requesting a final
amount before committing to the order. It should be exactly that. The currency
ratio at the time of the quote should be carried into the invoice.
My two cents.
|
It depends on what a seller intends to quote. If he is simply quoting goods plus
shipping in his store currency and he is not intending to make a forex quote
then current set up seems correct. If on the other hand he wants to give a fixed
foreign currency quote then the current system does not do that. Maybe the system
should offer both options?? We don't use it anyway for other reasons at the
moment so I'm open minded on a debate about enhancing the feature.
Robert
|
I am not fond of the quotes either, to say the least. Left it enabled by mistake.
I think I will try asking my buyers directly whether they would have placed the
orders regardless of the quote option at my store, and decide what I do then.
As for how it should work - perhaps someone should look into (German?) law and
see if there is a section covering this very matter. That's the reason why
BL was cursed with this thing in the first place. It should work exactly as the
Law requires.
I would guess that the Law needs the quoted price at the bottom of the equation
to be final, but it's only a guess.
|
German law, I am almost certain, will require the price to be shown up front
in Euro as that is their currency, I don't think it will concern itself with
prices quotes in other currencies as, in most cases, these would be exports outside
of Germany. I think other EU countries may have similar law too. I can't
think why they would want to legislate for a German business quoting on a sale
to the USA for example, that is not a German/EU consumer protection issue.
Might be wrong, just my 2 cents
Robert
Robert
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | Author: | enig | | Posted: | Jun 29, 2016 11:20 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 32 times | | Topic: | Suggestions | |
|
| In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig writes:
| | In Suggestions, Rob_and_Shelagh writes:
| | In Suggestions, enig 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.
|
Also recently had an issue where quoted amount (via our brilliant) differed from
invoiced amount because of USD/EUR fluctuations.
And I thought the quoting feature can not possibly be broken any more than it
already was. But they did it. Now quoted amount is no longer the amount showing
up once the quote is accepted. What was the single most important purpose
of the quoting system again?
Anyone who is still thinking that we have competent people working on BL needs
to wake up.
I am sorry I can not be more positive. I know someone up there is trying. But
you need ti try harder. PLEASE.
|
I can't see how it could do better in this case. The quote and the order
are the same value in your store currency. The fact that the USD rate changed
between the 2 events is outside BL's control. The only other way would be
to fix the USD amount then return a different EURO amount which makes no sense
to me, IMO the local store currency is your "offer" and the buyer risks exchange
difference (either way) by delaying placing an order.
Robert
|
Has it always been like this?
Anyways.
The purpose of the Price Quote feature is to provide an option for buyers
to request a quote before entering into an order contract. The buyer will know
the final cost of an order before placing the order, while the seller
can suggest a final price without holding inventory.
http://www.bricklink.com/help.asp?helpID=2437
In this case a buyer was looking at the quoted amount and clicked "accept". The
amount changed at that instant.
|
Yes I think it has always been like that but good point! I think the wording
should include something that says the "store price quote is fixed but if paying
in a different currency than the store's the rate might fluctuate between
quote and order, the actual conversion will be done using BL/XE rate at time
of order submission"... in line with what is stated for ordinary unquoted orders.
I don't think it would be fair to hold sellers to a currency converted quote
as anything could happen between quote and order with the rate, the buyer on
the other hand has the option simply not to go ahead if his currency collapses.
Robert
|
Just to be clear - this is in no way a rant because I am getting a few cents
less, in case anyone is wondering I had the quote feature enabled temporarily
and simply forgot to turn it off. This was the very fist quote ever accepted
at this store, and it was actually my customer who brought this up - he was confused.
I would have never noticed. First quote, first customer (less than 10 FB), first
hiccup.
Where I am getting is - I do not believe that no one has asked this question
before. How long ago have we had the quoting feature implemented?
I'd say the quoting should work exactly as currently described. The exact
quoted amount, (in whichever currency the buyer has requested) should be carried
into the invoice. That's the reason for the quote as I see it. The quote
is for the buyer, not for the seller.
You are right - BL has no control over the currency fluctuations. It has always
been the case. Seller's prices are in EUR, buyer selects USD. Between the
time of order/invoice and the payment, the amount the seller is getting (if he
were to exchange immediately) is almost always a little + or -. At the same time,
same is true for the buyer if he's paying in other currency than he's
holding. The amount going out of his pocket depends on the currency ratios at
the time of payment.
Shouldn't quotes work in the same principle? I see quote as a draft for the
invoice. Seller quotes the amounts minus the payment details. If the buyer accepts
the quoted amount (in the currency he requested the quote in), he gets the payment
details.
It should not matter if the currency ratios change. Buyer is requesting a final
amount before committing to the order. It should be exactly that. The currency
ratio at the time of the quote should be carried into the invoice.
My two cents.
|
It depends on what a seller intends to quote. If he is simply quoting goods plus
shipping in his store currency and he is not intending to make a forex quote
then current set up seems correct. If on the other hand he wants to give a fixed
foreign currency quote then the current system does not do that. Maybe the system
should offer both options?? We don't use it anyway for other reasons at the
moment so I'm open minded on a debate about enhancing the feature.
Robert
|
I am not fond of the quotes either, to say the least. Left it enabled by mistake.
I think I will try asking my buyers directly whether they would have placed the
orders regardless of the quote option at my store, and decide what I do then.
As for how it should work - perhaps someone should look into (German?) law and
see if there is a section covering this very matter. That's the reason why
BL was cursed with this thing in the first place. It should work exactly as the
Law requires.
I would guess that the Law needs the quoted price at the bottom of the equation
to be final, but it's only a guess.
|
German law, I am almost certain, will require the price to be shown up front
in Euro as that is their currency, I don't think it will concern itself with
prices quotes in other currencies as, in most cases, these would be exports outside
of Germany. I think other EU countries may have similar law too. I can't
think why they would want to legislate for a German business quoting on a sale
to the USA for example, that is not a German/EU consumer protection issue.
Might be wrong, just my 2 cents
Robert
Robert
|
Yes, I was thinking among the same lines. But we do have a few other currencies
in EU. The Law, I guess, is intended for the shops operating in Germany OR perhaps
also for shops that are also in EU and, in one way or another, targeting the
German market too. Whethet the Law covers the second part or no, and whether
there is a requirement for the grand total to be displayed in EUR (even if it's
not the currency used in the transaction), is another question.
To me this is a very simple question with straight-forward answer. Grand total
is Grand total is Grand total. The bottom line of what was quoted and the bottom
line and the amount charged must be the same. That's the essence of the Law,
the way I understand it. If I am right or wrong.. is another matter.
What and where exactly the "bottom line of the Grand total" may also be debatable,
once you involve more than one currency.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | Author: | Rob_and_Shelagh | | Posted: | Jun 29, 2016 11:42 | | Subject: | Re: Problem with onsite PayPal: grand totals | | Viewed: | 30 times | | Topic: | Suggestions | |
|
| In Suggestions, enig writes:
| | Yes, I was thinking among the same lines. But we do have a few other currencies
in EU. The Law, I guess, is intended for the shops operating in Germany OR perhaps
also for shops that are also in EU and, in one way or another, targeting the
German market too. Whethet the Law covers the second part or no, and whether
there is a requirement for the grand total to be displayed in EUR (even if it's
not the currency used in the transaction), is another question.
To me this is a very simple question with straight-forward answer. Grand total
is Grand total is Grand total. The bottom line of what was quoted and the bottom
line and the amount charged must be the same. That's the essence of the Law,
the way I understand it. If I am right or wrong.. is another matter.
What and where exactly the "bottom line of the Grand total" may also be debatable,
once you involve more than one currency.
|
| | yep, put another way, I suspect that specific law requires a firm price in a stated currency (usually the local one) but is unlikely to require a local company to guarantee a price in another currency "as well". For cross border shipments within the EU then if the price is offered in an EU currency (not just Euro) then I suspect no issue. But this whole point is about a quote in USD in terms of an export out of the EU in which case I can't see why that law has anything at all to do with it. Going back a few posts, I think the net outcome is an exporting business can quote in whichever currency it chooses to satisfy a potential buyer and can choose whether it will cover any currency movement or not, simple international trade. What tools BL provides to help its' sellers to do that (or not) is upto BL I guess.
|
Robert
|
|
|
|
|
|
Netherlands, Utrecht
United Kingdom, England
Canada, Ontario
Germany, Berlin
USA, California
Lithuania, Panevėžys
)
)