Open nightcoding2021 opened 5 months ago
xerc
commented
5 months ago There is also seemingly no way to verify UPS will actually create a shipment to a given address, without fully creating and confirming the piece in one step?
you may create a label in sandbox mode alias CIE | keep in mind ; these ShipmentCharges are not your NegotiatedRates
https://github.com/UPS-API/api-documentation/blob/1646e7cfa63a4cb462625a476c94adcfb2d744f9/Shipping.yaml#L6-L10
UPSRahul
commented
5 months ago Hi, thank you for your comment. UPS introduced the RATE API to replace the need for a two-step shipping process.
xerc
commented
5 months ago @UPSRahul ; if you're up for checking the RATE API with me i am up expl./ RATE from DE to DE results in "The requested Package Type is unavailable for the selected service between the selected locations" but same JSON creates a label [reportet 17.03.24 via e-mail ; no response yet]
UPSRahul
commented
5 months ago Hi, if you're comfortable doing so, can you please post your rate and ship curls with all PII removed. An alternative to this would be to reach out to our help desk: https://developer.ups.com/contactus
xerc
commented
5 months ago Hi, if you're comfortable doing so, can you please post your rate and ship curls with all PII removed. An alternative to this would be to reach out to our help desk: https://developer.ups.com/contactus
e-mail support is very slow & .. // if you want direct contact to improve the API - check my website or the ticket ID(s)
UPSRahul
commented
5 months ago Hi, if you're comfortable doing so, can you please post your rate and ship curls with all PII removed. An alternative to this would be to reach out to our help desk: https://developer.ups.com/contactus
e-mail support is very slow & .. // if you want direct contact to improve the API - check my website or the ticket ID(s)
Hi, since there is an active UPS Help Desk ticket, we have internally forwarded and notified the Help Desk team of this issue. Moving forward, the Help Desk should be able to better support this inquiry.
We will keep this issue open if nightcoding2021 has any additional follow-up, thank you.
nightcoding2021
commented
4 months ago What @UPSRahul has advised regarding Rate API would be correct, and would have the effect of re-creating the two-step process. However, it was more efficient how it was designed before. What I've done as an immediate solution is to capture the negotiated rate when using Shipping API - and having a process to immediately void the shipment if the cost exceeds an acceptable amount. That isn't ideal but is the only viable immediate fix when I've got other extremely urgent integration tasks on non-UPS matters.
The other problem is that this doesn't provide/assign a UPS tracking number unlike the XML 2-step process. Previously, I would capture the tracking/waybill number and use that to populate the commercial invoice (own forms) before generating and uploading to the forms history. Now I think the only way to put the tracking number on commercial invoice (own forms) would be to upload a second, revised, form with the tracking number populated after shipment creation. That means the commercial invoice (own forms) has become a two step process under the JSON API.
I have now got the JSON API integration operational & it was used to print all live UPS labels today. There is no way I'm any better off than before, in fact this API change is definitely a backward step with zero positive benefits for users that I can identify (but perhaps for users using functionality I'm not).
cdrez
commented
3 months ago I am running into the same problem. We have international shipments and would like to use our own commercial invoice, but don't know the tracking number prior to shipping. So anything I upload to the paperless endpoint would not contain an accurate tracking number. As far as I can tell, you can't edit a previously uploaded form and add the correct tracking number after shipping (unless that's an endpoint I'm missing).
The rate API is also a problem. We sometimes have to rely on what the actual cost is that is returned by the ship API in order to calculate invoice line totals, not necessarily the rate API since they can potentially disagree. We could use the rate API and just trust that number or void the shipment if it's off by too much, as @nightcoding2021 said, but this is a very inelegant solution.
Maybe ideally, there would be an option in the paperless API to upload a form with a tracking number (or another way to identify what shipment it belongs to) directly after shipping, and UPS would apply that uploaded form to the shipment after the fact.
For the moment we are stuck using paper invoices and potentially incurring a supposed $1-5 fee for every shipment that doesn't have a paperless invoice.
nightcoding2021
commented
3 months ago Due to a massive programming workload this year, I left things as they were - uploading paperless invoice without tracking number on the document.
However, I believe it's possible to upload revised documents via paperless API/endpoint. So the solution might be to upload the commercial invoice without tracking when creating shipment, then capture the tracking number, then immediately generate and upload an identical commercial invoice with the tracking number now populated.
So far, I haven't had any problems with customs clearance now the tracking number isn't on the invoice.
However, it was far more efficient the way things were with the 2-step shipping process - why on earth change that? Very frustrating to do a lot of work, and end up worse off than before - except, I suppose, the somewhat improved security on the new API.
eworbit
commented
3 months ago Conceptually, after uploading the commercial invoice (even without tracking number), and then performing the shipment call:
/ShipmentRequest/Shipment/ShipmentServiceOptions/InternationalForms/FormType=01
/ShipmentRequest/Shipment/ShipmentServiceOptions/InternationalForms/UserCreatedForm/DocumentID=
CUSTOMS AGENTS HAVE ALL THEY NEED as this links the DocumentID to the shipment/tracking#. It'd be nice if UPS would just confirm it in their documentation. There shouldn't be any further thing we need to do to solve the is chicken-or-the-egg issue.
nightcoding2021
commented
3 months ago Currently I am creating own commercial invoice, uploading via paperless API, and then specifying DocumentID in shipping call. So on the UPS systems, the commercial invoice is linked to the tracking number/shipment. I haven't received any complaints from UPS brokerage or receiving countries.
However, ideally I'd like to keep populating the UPS tracking ID on the paperless invoice. "Upload Paperless Document" call provides the DocumentID, which is then linked when creating the shipment in InternationalForms node.
The question for @UPSRahul is what is best practice to replace the uploaded commercial invoice, with an updated invoice that includes the tracking number? I either need to delete the document and over-write with a new one, or delete, upload a new document (which would have a new DocumentID), and then link that new DocumentID to the original shipment. As @cdrez mentioned, this doesn't seem to be possible?
Any ideas?
Unless I've misunderstood this, UPS has eliminated the two stage process ShipConfirm & ShipAccept? This is a major problem, first up the tracking number is needed for the commercial invoice generation - the waybill numbers are printed on the invoice itself. There is also seemingly no way to verify UPS will actually create a shipment to a given address, without fully creating and confirming the piece in one step? Merging it into one step might make sense for something simple like labels for postal letters, but not for something as serious as international shipping where a much greater level of accuracy and caution is critical, especially considering the monetary value involved in some of these shipments.
Does anyone know how to workaround this and effectively revert to the two stage process?