We are experiencing a scenario where we need to update a Customer Ship To address and it is then affecting all open sales order ship to values with the same ship to location.
For example, I made a small change to a particular ship to address in the customer file. Once I made that small change, I noticed that each and every open sales order tied to that customer with whom I made the change now has been updated to that same ship to address that I previously updated, regardless if that was the same ship to address beforehand. Even if other orders under that customer had various ship to locations, they now all default to this newly updated ship to value.
I only want sales orders going forward to reflect this small address change, not update all open sales orders to go to this particular address by default.
I looked over company config, Site config and the Customer maintenance file and didn’t see any setting that would enforce this.
I ran Sales Order Entry in Base Mode to see if there was any mod that would affect/yield this behavior.
Any suggestions would be highly valued and appreciated!
It sounds to me like you need to create a new Ship To in Customer Maintenance – not edit an existing. Then, use the new one on the orders you want to have affected.
I agree with Dan. I have always found this to be a surprising design… this use of referential data for customers and suppliers in Epicor.
For example, when I use a part, the system uses data in place at that time to provide part desc and other part setup variables. When I cut a job for an order, the system uses data in place at that time to provide description of what I’m making. It does not place “part ID” on all of these places and force all places used to accept part description, etc. changes. Why when I use a customer or a vendor I only get the ID on the order and then any address changes henceforward to customer or vendor record are reflected on all sales orders, quotes, pos, etc due to the referential nature of the data? This is also regardless of whether the order is open or closed.
I can pull up invoices from 6 years ago and see some new address on it when print preview, not the one that the original invoice was sent to, due to the referential data being used (customer ID) instead of system having taken a snapshot of the data at that point in time. It surprises me that this is not an auditing problem, but alas I am not an accountant.
Sorry for long rant ~ I don’t know of any system settings to make this optional.
Selecting a different ShipTo in Order Entry, can cause existing fields in the order to update. Specifically the unit price - unless you use price lists. And even if you do use price lists, the price on the order lines will “update” to match the price list. So any manual changes to price will be lost after changing the ShipTo.
Our customers are construction sites, so they rarely use the same ShipTo. And we often don’t know the exact ShipTo details (like the exact street address or road and mile marker) until after the order has been placed. When we create a new ShipTO, and then select it on the header of the order, it zero’s out all the prices of the order lines (we don’t use price lists).
@Nancy - I was “this close” to having to create UD fields to hold a copy of the address fields on packers, so that when someone changed the ShipTo info (as opposed to creating a new ShipTO), I’d have a record of where that shipment actually went.
Isn’t that the craziest thing? You probably shouldn’t let you coworkers see E10 help
I greatly appreciate your comment on changing the ship to (and customer id also) making other fields update too. We’ve have significant problems with unexpected pricing changes made from this as well as bookings errors. Very painful…
I think there is a thread on here on making a BPM to read all the line prices before the ShipTo change, and then restore them after.
My folks learned to just do a “Send to Excel” of the lines List, before updating, then just using “Paste update” to get the info back to where it was (required moving some columns around to be efficient)