From reading the information about NewOrderSingle FIX-Protocol message on FIXimate I can't figure out how to properly use the Side, tag 54=.
For the below orders, what are the correct sides?
Buy CAD, sell USD: Symbol is USD/CAD, Side needs to be 1 or 2?
Buy EUR, sell USD: Symbol is EUR/USD, Side needs to be 1 or 2?
You're asking whether the instrument is quoted as base/terms currency or the inverse.
That depends on your counterparty and the FIX-Protocol specification that you and they specify together.
Usually it's baseCCY/termsCCY and the answer to your question is 2 and 1:the 2 to buy termsCCY, the CAD in USDCAD,andthe 1 to buy baseCCY, the EUR of EURUSD.
So you see you can use either case as shown by your CADUSD example. That's because a client, for example, may want to buy 1.000.000 USD of EURUSD (in other words a nice round figure amount quoted in USD) but with the price quoted in the conventional EURUSD and not as the unconventional USDEUR.
In that case it would be 2 to buy USD (and sell EUR).
From memory I think the baseCCY, or dealt currency, FIX-Protocol tag is 12= or 15=, and that removes any ambiguity about the size and side and currency quoting convention.
No doubt you get what I am talking about tho.
Related
Use the C2 country code for China worldwide for comparable uncontrolled price (CUP) method, bank card, and cross-border transactions.
Found on this page: https://developer.paypal.com/docs/api/orders/v1
I'm struggling to make sense of what it actually means!
I know what ISO codes are - what I am trying to figure out is why the 'C2' (China) code might be used for ALL bank card/cross-border/CUP transactions worldwide, regardless of the ACTUAL countries involved - or if that's not what it means at all!
I've been using the Android billing client for a while now and always display the prices using getPriceAmountInMicros() from the SkuDetails object returned from the billing client.
Often we get complains from some of the customers that the price we display is not the same price they're paying. I've always assumed this is due to local taxes and that the Google play Store doesn't return the prices with local taxes included.
However, going to the documentation of getPriceAmountInMicros() things start to get a bit fuzzy. In particular this section:
This value represents the localized, rounded price for a particular currency.
What is a "localized price"? Is this including taxes? I cannot find any explicit place where it says this includes taxes or that it doesn't. By contrast the documentation for getPrice() explicitly states that the price does not include taxes.
Looking into a completely different resource, yet connected to a sku, one can see the same method - getPriceAmountInMicros(). In this method, it's explicitly stated that the price does not include taxes. It would seem odd to me that they would choose to name the method in a SkyDetails object the same, but have different semantics. Nevertheless, I want to be sure and would highly appreciate your help!
Thanks for pointing this out.
Because the QPS of computing taxes during skuDetails queries would be high, our servers defer tax computation to the purchase flow. So unless you need getPriceAmountMicros() for, say, refunds; you should simply use getPrice().
When creating certain objects on Shippo, there's this object_purpose attribute that allows you to select either QUOTE or PURCHASE. I can see that PURCHASE is for labels that are meant to be bought and used in the end, but when should I use QUOTE only?
It's fine to use PURCHASE for all your objects. Just remember, that a complete from / to address is required.
You should use QUOTE when you don't intend to actually buy a label - such as getting rates to show to a buyer or just doing a shipping estimate. The benefit of using QUOTE is that rates can be retrieved using less information (such as only passing the zip codes), since the the full street address is not required.
I'm working on this kind of data structure :
Now, say I have to search for products that are < 90 EUR, it should only returns the product "item2". On the other hand, if I search for products that are == 100 EUR, I should only returns the product "item1".
I have 60 000 products and 16 currencies, so I just can't convert all products in all currencies on a daily basis (as the currency rates updates daily) only to be able to perform this search.
I have 2 questions :
is this use case a good fit for a Postgres function ? Is there any other good and sustainable solution if not ?
if a postgres function is the solution. Given that I'm using Ruby on Rails (4.2) and the search requests (on products sizes, colors etc...) are chained using ActiveRecord : is the call to the DB function still chainable and usable in AR ?
Thanks for your help
Using a function for this is a terrible idea, because performance will suffer greatly: the exchange rates will change over time, rendering your indexes useless.
Further, it's a terrible idea to store a single price per item. Thing psychological prices and tax considerations: if something is €99.99 including VAT in the Eurozone, it'll probably make sense to sell it for $99.99 plus sales tax in the US. No amount of exchange rate manipulation using functions or other will change that. (Compare the prices of Apple in the US, in France, in the UK, etc.).
For each item, associate a price in Euros, one in Dollars, etc. -- each with a currency_id, and have the exchange rates reside in a separate table. Or create some kind of price-list table in which you associate prices based on currency (e.g. €99 = $99) to a price_id, and associate the products (it's actually the SKU, btw) to their corresponding price_id.
You can fill this data in semi-automatically using an exchange rate table, and periodically update them using one as well. But really: do reserve the ability to manually set prices, make sure you mark prices as including or excluding tax. And when it comes to taxes, don't forget that tax rates are different from a place to the next and from a product to the next.
For the record, I ended up creating a new column "price_eur" in the "products" table where I convert each price to EUR whatever is the original currency. Doing so I can perform a consistent search based on this price_eur column.
I just wanted to know if there was an alternative solution but looks like there is no other simple way...
What is the allowed format for PayPal's Website Payments Standard (WPS) forms in the "amount" field? Must the decimal point be ".", or is it currency-dependant? Must there always be exactly two decimal places, or can there also be three (for currencies that have such small nominations) or none (for currencies that have hyper-inflation)?
I know that this should be a question for PayPal's documentation/forums, but the first has a vast room for improvement (to say the least) and the second is as speedy as a sleeping snail. I have posted a question there, but I don't expect any replies sooner than about two weeks. Hopefully someone here will have an idea.
Looks like it's not currency dependent and the API is expecting at most two (2) decimal places with a period separator.
amount
[...] Limitations: Value must be a positive number. No currency symbol. Must have two decimal places, decimal separator must be a period (.), and the optional thousands separator must be a comma (,).
Website Payments Standard Button Manager API Overview