Sales order does not match the pack customer

Epicor ERP 10
1

In “Customer Shipment Entry” when we select “New Pack” and then put in an order number, we get an error that says, “sales order does not match the pack customer” we can not click passed this error, so we can not ship.

2

We discovered that there was a Pack ID number 0 that was created earlier in the day. To solve the problem we had to delete the 0 pack ID. Once we did that, we could ship like normal again.

3

We had the same issue happened with us today and luckily I found your post resolution. Do you know how this happens?

4

I think it happens when someone starts a pack, but doesn’t finish it, But im not positive that is the cause.

5

This is a bug we found that has been corrected in later versions of E10. Support did not have any record of this, but the issue does not happen in the latest version. We run 10.1.500.9 and it is still present. We have a BPM in place to catch and stop it from happening.

We found the bug in Customer Shipment Entry that will cause an existing PackNum to be changed from its current number to 0. We were able to recreate this in our Test environment with the base form and all BPM’s disabled.

With (2) existing Customer Shipments (ex 12345 & 12346), the following steps will recreate the issue.

  1. Open Customer Shipment Entry and enter the first existing PackNum into the pack id field (ex. 12345) and press ‘Tab’.
  2. Enter a PackNum with an invalid character into the pack id field (ex 1w346) and press ‘Tab’. - Oops, typed a ‘w’ instead of a ‘2’ in the PackNum.
  3. Pack ID field changes from the invalid PackNum entered to ‘0’.
  4. Enter the correct PackNum (ex. 12346) into the pack id field and press ‘Tab’.
  5. PackNum 12346 will load into Customer Shipment Entry.
  6. Enter the first PackNum (ex. 12345) into the pack id field and press ‘Tab’.
  7. Error message ‘Record not found. Add new?’. Click ‘No’.
  8. Enter ‘0’ into the pack id field and press ‘Tab’.
  9. PackNum 0 loads into Customer Shipment with the lines from the first PackNum, 12345.
6

Interesting…seems like a lot of steps to recreate the issue that an end user would actually do something like that. Normally the end user would create a new Pack ID or even if they were to enter an existing Pack ID, I wouldn’t think they would be switching back forth between Pack ID’s to even possibly re-create the issue. Step #8 is where it doesn’t make sense for a user to enter ‘0’ in the Pack ID field at all. Good to know what causes the issue and how to resolve it for future references.

7

Our dispatchers do it all the time. Open a Pack in Customer Shipment, print the Pack Slip, open the next, print the Pack Slip, etc… Steps (6) - (9) are just to show that the original Pack Number was changed to 0. Steps (2) and (4) are the cause of the bug. This was just a detailed step by step that I submitted to support to recreate the issue.