Order release with no or null Ship To

We have discovered that there is sometimes no ShipTo on an order release. The order header does have a ShipTo. I have not been able to re-create the situation to identify what is causing it.

When order lines are created, the system assigns the ShipTo from the order header to the releases.

If the order header ShipTo is changed, the user is prompted to update (or not) the release ShipTo. If the user selects Yes, the releases are updated with the new ShipTo from the order header. If the user selects No, then the release ShipTo remains as it was. Short of manual deletion, I cannot get the release ShipTo to be null.

Has anyone seen this or know what might cause it?

I have not seen this issue myself. I would first take a look at any BPMs data or method directives that you might have in play. They could impact the ship to. After that, I would take a look at the specific customer records for the orders experiencing the issue. Make sure there is a valid ship to entry in the customer record.
Good luck!

I’m pretty sure you either have to have a valid Ship To or Use OTS checked.

The confusing bit is blank/null is usually a valid Ship To code.

I believe when a customer record is created, it also creates a Ship To entry for that customer with a blank Ship To code.
:white_check_mark:

I HATE, HATE, HATE how Epicor does the NULL ship to on customer creation. It makes no sense to me and causes innumerable headaches for users of the system.

Hold on while I go destroy something to calm down…

office space nothing to see here motherfucker GIF

Ok, I’m back and settled down enough to explain how the Customer works in Epicor.

When you create a Customer in Epicor, it is creating 2 records. One is in the Customer table and is generally referred to as the “Sold To”. The second record is created in the ShipTo table and is generally referenced as the “Ship To”. In addition to Sold To and Ship To, there is also the Bill To. The Bill To is stored on the Customer table, not in the CustBillTo table like you would expect.

Let’s just say that is all we have done at this point. We created a new Customer and only entered what the system requires. If you create a Sales Order, the Sold To, Bill To, and Ship To will all have the same address and the Ship To field will be “” (it is actually not a null value it is an empty field). Additionally, the Bill To address will be defaulting to the address on the Customer Detail screen.

If you want a different Bill To address, you have to go to the Customer Billing page and enter a different address there. If you do, that address becomes the default Bill To. It also enters the information into the BT fields in the Customer table. You can actually add more than one Bill To to a customer by creating another customer and using the Alternate Bill To functionality. If you do add an Alternate Bill To to a customer, that data is stored in the CustBillTo table.

Now the Ship To (oh how I hate you). The address that is on the Customer Detail page is the address that gets stored in the ShipTo table with that “” Ship To ID. If you want to change the address on that record, you have to change the Sold To address. If you want the Sold To address and Ship To address to be different, that is when you need to create a new Ship To ID on the customer record to have something different. But, adding a new Ship To ID adds a record to the ShipTo table where you will have 2 Ship Tos for the customer. The one you just created and the “” one. Which of the Ship Tos is the default one? Glad you asked. The default Ship To is the one that is marked as Primary Ship To, but if you have multiple Ship To records in the ShipTo table and none of them are marked as primary, the “” Ship To record is the default.

As an added bonus, let’s talk about Contacts. Customer Contacts can exist at two levels, the Customer (Sold To) level and the Ship To level. Additionally, the same exact contact can exist at both the Customer and Ship To level with different Contact IDs. If you are reporting on the Ship To only table, you have to be very careful that you know what you are after. Without a join to something like the OrderHed, you must know what Ship To you need to filter on. Otherwise, you can end up with the wrong list of contacts. Additionally, if you want contacts on the “” Ship To, you actually add them to the Customer contacts, not the Ship To contacts.

And all of this could be avoided if Epicor would just create the first Ship To record with a 1 instead of a “”. I think I even put in an Idea for this, but I’m to angry to go look for it.

Let me know if you have any questions.

Oh, and for good measure, I HATE you Ship TO.

i hate you middle finger GIF

5 Likes

Was not thinking that what looked like null was not actually null. Grr.

Will need to use an if then to look at the order head ship to if the release ship to is this silly null-looking thing.

In this case, there was supposed to be a ship to, so I just updated it with DMT. Also had to update the invoice detail, which is what the BAQ is running against.

Thanks.