Epicor applied 2026.1.2 this week and it appears to have broken or made changes and is now affecting shipping.
It appears if we have a shipment with multiple orders it is not pulling all the information in to Quick Ship and only one order is showing up on the International Paperwork. So right now we can’t ship international.
OOFT. You’ve had such bad luck since moving to the cloud.
We really have. It has been a very painful process. I have always been an Epicor support but after what I have been seeing I would not recommend them.
We aren’t on 2026.x yet so I won’t be much help. Likely will need a ticket.
Kinetic we are still on 2025 but Quick Ship in cloud we don’t have an option to apply or delay patches like Kinetic so we are at their mercy and they do things quick. Quick Ship in cloud is now on 2026.1.2 items broke this week.
I’ve got an open ticket in 2025.2 (Quickship) where the international paperwork is always wrong. Either it’s always list price, or it pulls IUM but the unit price is based on the SalesUM. So, I have a script I run to fix it all (on prem).
We’ve been dealing with this since we left 2021 in Quickship and there is never a resolution.
I had and issue with quick ship not pulling the discounts and populating the correct export value. When I changed to Rest API connection between Kinetic and Quick Ship that fixed it. But now there may be other issues with this connection. I am testing it now.
That’s the first fix, but we have a lot of products that we stock differently than we sell. Our values are never correct. The fix was to update the product in QS and put a UOM conversion in QS, but these are part specific, and we can’t do that. Plus the part just gets overwritten the next time we ship…
I doubt they can handle that.
Well I tested it and it appears that when Quick Ship updated it lost functionality with Kinetic 2025.2.20. It was working fine until the Quick Ship update. Our Pilot is 2025.2.22 and it works fine.
We’ve run into to same issues. Changing to rest fixed one issue with values but added a lot more. We haven’t been able to use the subcontract shipment entry since the change. Have reverted to classic in order to ship those. Thank goodness we stll have that to fall back on for now.
We just had a multi order international shipment that was 100% list price and we’re using Rest. So that doesn’t resolve the issue.
Depending on who you talk to at Epicor they don’t recommend REST yet. As it’s not done and has a different set of issues compared to the FreightSvc.
Yea, we are getting differing opinions from them. One says use rest to fix this and the next says use web service to fix that. So tiring.
Having classic as a fall back for now is getting us by, but doesn’t help our users feel good about losing classic in a few months.
that is what I got today. I wasn’t told to go back to webservice but it was a suggestion. The issue the Rest API fixed is a bigger issue to keep fixed than the issue it broke today. I wonder what else it will break.
Once again customers doing all the testing.
Make sure they are using the kinetic UI for shipping. We saw that when using classic, it still uses the full value but the browser did it correctly.
We noticed this with something else. It worked differently in the Kinetic UI vs classic.
I can try that. When you press the “International” button on the Manifest info tab, it launches a the Quickship URL. I can’t imagine the Kinetic versus Classic UX would matter in this case.
You can look in the shipmentRequest json on QS carrier XML tab and see what credentials it’s using. If requested by classic it uses web and kinetic uses rest if configured.
I only see the carrier files, nothing epicor related.
EDIT: Looked it up by the QS pack id. I found it. It’s using Services instead of Rest. It’s configured for Rest.
Maddening.
It also seems to be DHL more than all the other carriers.