On Customer Update, we are running an in-transaction data directive that is intended to set some “defaults” for New customers. The first condition is:
There is at least 1 added row in the ttCustomer table:
We thought this was working properly, but we suspect this condition was met in a way we had not anticipated.
Some of the “default” fields in this data directive sets the credit limit to $1, CheckDuplicatePO to true, AllowOTS to true, etc, and also a UD field to track the user who “created” the record. Some of these fields are being tracked in our change log.
If I look at the credit limit changes on the change log, I can see an entry in January where the credit limit was raised from $50K to $150K. The next change log pertaining to credit limit was 3 weeks later where the credit limit went from $1 to $150K, but I cannot see any log record of how/when the credit limit dropped down to $1 between the two changes to bring it to $150K. There is NO credit limit change log since the second time it was changed to $150K, but the current limit is back down to $1.
We just had a copy over on our pilot system and the “created by” field does not match between Pilot and Live. The “created by” user in Pilot is in our Accounting department, so they have permissions to change the customer record or create a new one. The “created by” user in Live is in our Order and RMA processing area and does not have permissions to create a new customer account.
Can any other activity (other than creating a new customer) cause the statement “there is at least one added row in the ttCustomer table” to become true? Something like order entry or RMA processing?
Could some process be deleting the customer account, and then recreating it with the same number but losing some the change log data (like setting the credit limit to $1)?
Any help would be greatly appreciated because we are perplexed.
What types of actions (other than adding a new customer) could trigger the added row of the ttCustomer table? This will allow me to test and prove to others on the team that the BPM is NOT working as intended.
Now that I’m re-reading it, it sounds like the customer may have been deleted and readded.
Are you absolutely sure that the order and rma department can’t delete or create new?
Kevin,
I agree that it feels that way, but if the Customer account was DELETED and then RECREATED with the same CustomerID, I know it would get a new CustNum (Key1 on the Changelog) and the change log gets deleted (based on queries and test I have done)? But in this case, we can still see previous changelog entries, so I can only deduce that this Data Directive is firing when some other action occurs (other than creating a new Customer). What else would cause this?
Yes… as @Dragos suggested, the best way to set defaults for a new customer is to create a POST PROCESSING Method BPM on the GetNewCustomer… set the defaults right after the user presses the “new customer” option. This will result in setting all teh defaults as soon as they say that they want a new customer, and they will see the defaults on the screen right away before they save.
We do the same thing for Parts, Orders, POs, Suppliers, etc.
We have tried a Post Processing Method BPM on GetNewCustomer, however we ran into an issue. We are using the AutoAssign for new customer number generation and we have set the CustID field to ReadOnly (except for our accounting group to prevent other users from manually changing that AutoAssign to something else). This worked fine until version 2022.1.3 when Epicor made a change that cause users to get a Business Logic Error (as documented here) Auto Numbering - Customer ID - #93 by jlubow
I still want to know what else (other than adding a new customer) would cause an added row of the ttCustomer table.
I always try the method directives first and use the data directives as a last resort. They can act funny sometimes. But I would try a couple of things to find out if they’re called:
a BPM on the data directive that just writes something in a txt file on the appserver (like a small log)
look in the app server logs (search for Trigger table=“Customer”) - you may need to enable it first in your admin console
