We’ve been running 10.2.400.8 for the last year and a half, ever since going live with Epicor. We just upgraded to 10.2.700.12, and now we’re getting errors when trying to add a Service Call Center Line item for a serialized part without adding the serial number.
Our consultants are telling us that this was a bug that was ‘fixed’ with the upgrade, but this is getting in the way of our now-established processes. Previously, we could open a call and start logging information about it before getting all of the detailed info from customers, so could leave the serial number blank initially and go back to add it later. (Often that’s not needed at all, if the issue is resolved in the field without ever needing to issue an RMA.) Now we can’t add the line item at all without knowing the serial number first.
Can I get a check of which behavior is “correct”? Having only two versions to compare, doesn’t give me much to go on, especially since I didn’t see anything about this change in the release documents for 10.2.500, 600, or 700. And is there any way to revert to the old behavior?
I would say that if it is serialized then you should have the S/N. If you don’t know the S/N, you could use a Part on the Fly which won’t have serialization turned on and then once you know the details you can go back and enter the information when you get it. That would be my recommendation.
Hello Brian,
Did you get a solution to this problem? If not, what is your teams workaround?
We are upgrading to 10.2.700.17 and seeing the same issue that wasn’t there in 10.2.400.9. Also we are using it the same way your company is using serial numbers for the call.
We started up a CASE for it and Epicor changed it to a PROBLEM as they could re-create it. My concern here is the time it is going to take to get this fixed under development team vs. customer support who work to get a fix much faster. Also, not sure if the fix will be available in our version or we will be forced to upgrade to the next version.
And you are right, there is nothing in the release notes mentioning there is a change in the workflow on Service Call Center’s use of Serial Number.
Thanks,
Uzma
We ended up just accepting the ‘fixed’ behavior of requiring serial numbers.
There was initially pushback from the service people who need to enter this data, but I think once they got used to the new process, it ended up being not that big of a deal.
@bsiller One of the behaviors they fixed was that SCC would create a blank Serial Number for the serialized part if a Serial Number wasn’t provided. The logic was only supposed to ask to create the S/N if the provided S/N didn’t exist yet but it instead it just created the blank record behind the scenes. I would venture to guess you have Serial Number records with a blank S/N in the SerialNo and SNTran table.