Not sure this is the best solution for you, but I’m just throwing out ideas as if I were starting brainstorming with my sys admin asking me to do this. If I understand what you are asking, I’d explore doing it this way as a developer…
- Add a field somewhere (to the customer?) to indicate that this action needs to be performed.
- Create an action or processing screen that can be executed to perform the overwrite with “X” as required. Writing a custom code means that you have complete control over what and how the overwritten data is executed.
- Create a dashboard to monitor when these are overdue (in case any slip by the next step).
- Schedule the action/processing screen to be executed as required. (Be sure to validate that you do not need the contact/address info for open records, such as open sales orders that need to ship!)
You may be able to get by with a carefully constructed GI that pulls all contacts/addresses based on some flag (the custom field suggested above?) and then enable “mass update”. CR302000 isn’t on my menu, but it is the maintenance screen that pops up for a customer contact if you want to explore the GI route. I think you still have to add an action to the associated graph to add to the Mass Actions tab in the GI. The “hidden” GI for the primary list on my system is CR-Contacts2018R1.
Hope this helps. I’m interested in what direction you end up taking, so I’ll be watching here. Please be sure to keep us updated.
Thanks, Brian.
Before posting, I started creating an action to replace contact and address on sales orders with Xs.
I hesitated with that plan because of the number of records and the amount of time and database saves it would need. I wanted to gauge if the SQL route is an option (I know it's frowned upon). I think, based on your response, I'll follow through on the original plan. I don't think ill take it as far as marking the customer account.
Edit:
The address and contacts are overrides on the sales order. They are not from the CR302000 screen.
Anyways thanks for the response, and thank you for your blog.
I definitely would steer clear of doing it via SQL if possible. I don’t remember the exact details right off, but there are revisions stored on addresses. If you simply “update the screen” then I believe it actually creates a new record with the “new” values and retains the old values for historical purposes. As I understand your intent, you want to destroy the original data, not simply move to the “next” address info. SQL would let you destroy it directly, but even then I’d try more for the PXDatabase commands to keep it inside the framework if you have to go down that path.
If you aren’t already familiar, take a look at SOShippingAddress and SOBillingAddress (SQL is SOAddress for both) and notice the CustomerAddressID and RevisionID fields. (Been a while, but I think the “overrides” are at play in this table.) A “normal” change of address info should trigger a new Address record with a new revision, so you run the risk of not destroying the original address but rather creating a new one. The next SO Shipment picks up the changed address info and references the new revision. I fought with this for a while on a project I did last year until I got my brain wrapped around what was happening.
Ok, I will continue to develop to the original idea and will see how it works out.
Regarding revisions, I just tested my local copy while monitoring the SOAddress table. Acumatica only adds a new address if you check, uncheck, and recheck "override." Otherwise, it modifies the current overridden address (so the action should work as needed).
The revision seems to be related to the Address table where Acumatica stores the customer's global addresses. Acumatica defaults/copies the sales order address from this table, as well. When unchecking "override," Acumatica goes back to the last revision instead of creating another row. However, when rechecking "override," Acumatica creates a new row on SOAddress table.