Anyone else recently go to cloud and have had issues and have had support being very complacent about the issues. No urgency when affecting production or shipping. I have had patches break stuff and now the Quick Ship update broke a calculation. Getting very frustrated.
Agree 100% with the lack of urgency…but quite frankly I’m not sure it’s a cloud-centric problem.
Pilot just went to 2026.100 with a new framework requirement (plus some of the Linux quirks). We know there’s a lot of BPM triage that’ll be required, that’s in progress…it’s some of the base issues we’ve run into while testing that kinda bother me.
One is a functional nightmare (but we might be able to work around)…and one that’s a complete breach of user profile security. That’s the one that scares me the most - because if it’s happening in one spot, it could be happening ANYWHERE in Kinetic.
Been on cloud for a while and thats always been my experience with support.
Putting in tickets seems like a waste of time and I cant say has ever resolved anything for me.
This forum is basically the only place I ever get solutions from.
We are still on 2025.2 but updated a patch and it broke our ability to retrieve serial numbers so we manually entering them. I guess the problem exists in 2025.2.21 too. How does that break?
The Quick Ship was updated from 2025 to 2026.1 and it broke the Export value calculation. It was working find and now we are running into serious shipping issues.
Yikes…we’re on 2025.2.16 live. Don’t use serial numbers or QuickShip so afraid I can’t help there.
As for stuff breaking in patch or version changes…I may catch flak on this but whatever.
I just don’t think there’s enough QA/validation testing on code before it goes out. The 2026.100 showstopper that we ran into in Customer Shipment Entry is unfathomable. It goes completely contrary to the entire user security setup as it pertains to site access. It isn’t just that the initial load list shows a user (who’s limited to Site B access, we’ll say) packs from ALL sites (A,B,C,D)…and that user can UPDATE records in the other sites.
that sounds like a nightmare
If you don’t user Serial numbers you should be fine to update…MAYBE. But updating to 2025.2.20 broke it for us.
We’ll go to 2026.100 when we have to…not making further changes to 2025.2.x…and the issue isn’t finding the CSEntry bug. The nightmare is the realization that it could run much deeper than just that specific function.
No kidding we have nothing but issues with Case Entry. Right clicks open up a module we don’t own. They tired to tell us to get the module but i fought them on that. Just all Crazy.
Very frustrating…and I know we’re not the only ones getting banged with all these issues. We can’t all be glorified beta-testers for their software. There just aren’t enough hours in the day.
“Sorry we broke something, please buy something else.”
I dont really think they did any testing, if we are being honest.
2026.1 has been in the works for how long now and it still broke emails and APR?
I really just don’t see how they could have done any meaningful testing and not caught that, considering how basic of a feature it is.
It seems to be the new standard for software these days, the end users are QA.
I reported this problem last week, the issue is due to an invalid where clause being sent to RetreiveSerialNumbers (double single quotes). The system shoots down the request because it detects sql injection.
The simple solution until they can fix this is to create a preprocessing BPM on SelectedSerialNumbers.RetreiveSerialNumbers with the following
whereClause = whereClause.Replace("''", "'");
I have tickets on the same two issues and getting the same lack of responses.
I was suppsed to have a webex on the ship value issue today but was cancelled with no new invite.
My serial issue thread…
https://www.epiusers.help/t/anyone-seeing-issues-with-serial-number-searchs-in-2025-2-20-or-up-specifically-possible-sql-injection-unexpected-keyword/135624
They know this and can’t fix it. Sad.
Crazy because I just fixed it in 2 minutes
Never thought of that, off to BPMs..
How does something like this even make it to production, yeesh.
Today I found out in application studio that if in the “provider model” for a baq, you have “server paging” check it causes the baq to fail the first time its called. But apparently if you click “refresh grid” it doesnt fail.
Really boggles the mind.
Probably because they already had enough reported cases and reviews that they get it… but they could at least communicate that to you.
Then we have a million BPMs to deal with bugs and have to review whether we can turn them off or not later on 
… Nice fix though @mbayley !
I prefix those BPMs with “BF” and try to put the case number in the description. I typically clean them up before our next upgrade.
I’ve got a dozen or so like this one. We can’t wait on their schedule to fix something that is affecting production.