I already have a working FedEx API in production with two services: rate and shipping.
Note that I use:
My own packages: "PackagingType": "YOUR_PACKAGING"
Almost always I know estimated weight of parcel: "RequestedPackageLineItems": { "Weight": { "Value": "42" } }
So, I do rate&buy label with concrete price. But sometimes package exceeds dimensions or weight is changed after buying label – this leads to additional payments and total price for label is different in real life than i receive at the moment of buying label.
The question is: How can I get REAL weight and price of sent package?
I tried to use tracking service with no luck – API returns old incorrect data of weight and no price.
For example, I know that label 123456789012 was created with 2 lbs of weight with price 9.45$. Later on, weight changed dramatically (to 48 lbs) and price changed to 48.98$. I know that because of talking with real people but request to tracking service of FedEx API says that PackageWeight is still 2 LB and Payments parameter contains only "Type": "SHIPPER_ACCOUNT" value and that's all.
Okay, I've found out that i need to request invoices because they contain needed information. How to get them? Didn't find any documentation inside PDF for developers.
Related
My question is related to already solved issue where saving product in "All shops" context made prices in all shops the same no matter the currency. So if product in Poland would cost for example 100 PLN, then in Germany 100 EUR and in Great Britain 100 GBP. Link to this topic:
Prestashop Multistore - local store prices are overwritten with price from default shop
Anyways the provided solution doesn't cover this very same problem of product combinations additional costs. So I want to ignore those fields when saving product in "All shops" context.
Does anyone know how to solve it??
I achieved it by editing overriden Product.php (from /classes/Product.php) - funtion updateAttribute (around line 1800+). I took it's body, except return, into an if statement:
public function updateAttribute(...) {
if (Shop::getContext() == Shop::CONTEXT_SHOP){
// function body here
}
return true;
}
Now when saving product with combinations in "All shops", it's not updating product attributes (additional price, stock etc.) - those can only be saved in context of specific/selected shop.
Let's say that I'm developing an application about shopping. I have defined the following endpoints, which are quite self-explanatory:
GET /items
GET /items/{item-id}
GET /stores
GET /stores/{store-id}
Now, I want to create another endpoint that displays the price of individual item at different stores. This price information is not included in /items/{item-id} since I don't think it's suitable to be an attribute of item, and getting the list of prices requires a bit more calculation as I cannot return the object directly. I will name the endpoint /items/{item-id}/prices and expect a response like this:
[
{
"store_id": "store_1",
"price": 13.00
},
{
"store_id": "store_2",
"price": 12.99
}
]
I want to extend this further and create another endpoint that returns the price information for all items, but I'm having trouble naming this endpoint. So far I've thought of /items/prices or /items?display=prices but the former might be confusing as it matches with /items/{item-id}, and the latter just.. does not seem to make sense for me.
What is the best name to pick for my endpoint so that it stays consistent with the convention?
For all items pricelist endpoint for a single store, I'd recommend GET /stores/{store-id}/prices or GET /stores/{store-id}/pricelist.
For all items/stores pricelist, I'd use GET /items/pricelist or GET /items/*/pricelist, (both special before /items/{item-id}), which could be store-specified on demand by ?store={store-id}.
Adding prices endpoint to items would make no sense as item itself has nothing to do. It is store's responsibility to dictate the price.
I would suggest renaming stores endpoint to /stores/description/{id} and adding prices subcategory /stores/prices/by-item/{id} and /stores/prices/by-store/{id}.
I would say that for sepecfic item /prices/{store-id}/{item-id}
and for all prices /prices/{store-id}
I originally reported this to Self-Service support in December, but I never got a response. I recently realized that, even in the production environment, selecting a currency parameter for an Inspiration or Cheapest-Date endpoint always returns the origin country's currency despite selecting another currency. (In the Low-Fare endpoint it seems to work as designed.) I tested this in both my web application and in Amadeus' own explorer tool. Here is a snip from the JSON response in the Explorer:
"meta": {
"currency": "EUR",
"links": {
"self": "https://test.api.amadeus.com/v1/shopping/flight-dates?origin=MAD&destination=MUC&departureDate=2019-04-14,2019-10-10&oneWay=false&duration=4,7&nonStop=true¤cy=USD&viewBy=DATE"
},
"defaults": {
"departureDate": "2019-04-14,2019-10-10"
}
}
Notice that the meta.currency value is EUR, but the meta.links.self (the query I ran) shows a GET parameter of currency=USD. The same problem I reported in Dec.
I am posting this for suggestions about how to get some action from Amadeus (hope they read this), or a suggested workaround (obvious one is hiding Currency field from the Inspiration and Cheapest-Date form).
The currency parameter in Flight Inspiration and Cheapest Date Search, works only along with maxPrice. Prices in the response are computed in a currency determined by the origin/destination pair: they cannot be converted in a given currency.
Since it's a bit confusing, we are going to update the currency parameter naming and documentation. Point taken and sorry for the delay in the response.
For the Amadeus self-service rest APIs: v1/shopping/flight-offers and flight-dates, is the price.total response field inclusive of all taxes and fees?
I seem to need to add total + totalTaxes to get a price that's close to the one provided by the airline directly.
If there are developer docs that explain in more detail each response field, please do point me to them. I have been unable to find any.
In reference to these APIs:
https://developers.amadeus.com/self-service/category/203/api-doc/4/api-docs-and-example/10002
https://developers.amadeus.com/self-service/category/203/api-doc/5/api-docs-and-example/10003
and this field:
"price": {
"total": "259.91",
"totalTaxes": "185.91"
},
“total” is the total price you will have to pay, it includes the totalTaxes.
You can access the model directly on Swagger (under the Response Class (Status 200)) you have the Model button. But you are right the description of those parameters need to be added, point taken.
As highlighted in the accepted answer, the total price is the total including all taxes, personally, I was also initially confused and had to manually check with a travel agent to confirm. I would suggest Amadeus splits the description as follows
"price": {
"totalFare": "74.00",
"totalTaxes": "185.91"
"totalAmount": "259.91"
},
according to the documentation, the Create Shipment method requires the property "items" - an array of the items being shipped, for example:
{
"tracking_number": "EJ958083578US",
"comments": "Ready to go...",
"order_address_id": 1,
"items": [
{
"order_product_id": 15,
"quantity": 2
}
]
}
In our business, a shipment almost invariably contains ALL items from the relevant order.
That being the case, is there a way to create a shipment without listing all items (which would require iterating over the product line-items)? Or, alternatively, a way to include all items by default (without iterating)?
We are simply wishing to automate the process of adding tracking numbers to orders - which (as a manual process) involves uploading a csv with [order_number: tracking_number] - i.e. it self-evidently assumes that all items are being shipped. The API seems not to include that (very sensible) option, but I may be wrong.
From Bigcommerce Support:
There is not a way to add a tracking number without adding a shipment nor a way to default the shipment to include all products. This is a helpful suggestion though that I will be passing on to our Product Team for possible implementation into future versions of the API.
Unfortunately for now it is necessary that you GET to the products subresource of an order and iterate over all of the products to pull their 'id' values and 'order_address_id' values so you can generate your POST request to the shipment subresource. It is not necessary to make a GET request to the shipping address subresource directly unless you want the details of that shipping address. It is also not necessary to make a GET request to the base order object unless you want details found there or you are looking to automate the process of checking for orders ready to ship.
So assuming you know an order ID that you want to ship it should only take 2 requests total to both GET the products subresource and then POST to the shipment resource.