We have dropship customers that require us to remove (overwrite with "X") the customer's contact (ARContact, SOContact) and address (ARAddress, SOAddress) information every few months.
The address and contact are overdriven on sales orders and invoices.
Acumatica's privacy tools seem to go too far, restricting the customer's account as well.
Does anyone have a solution for this?
Best answer by Brian Stevens
View original
+4
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…
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.
+4
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.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
