GL Transaction Validator - How to implement Business Rules at Fact_Acct
The purpose of this page is to help you implement validation logic at the general ledger. There exist two validation hooks in Doc.java.
- fireFactsValidate(...) - this option helps you inspect and manipulate either the document or the resulting facts (GL entries). Be aware that this method is unfortunately called before GL Distributions and inter-company balancing,
- fireDocValidate(...) - this option helps you inspect and manipulate the document either just before or just after the facts are posted. Unfortunately, this method does not allow you access to the facts (GL entries).
Here are two scenarios where you can use the above validation hooks:
- You want to enforce a rule that all income and expense accounts must have a profit center (Activity). You can use the fireFactsValidate to inspect the facts to ensure this field is set.
- You want to set the AD_OrgTrx_ID for all inter-company postings using foreFactsValidate. This helps any given organization know the detailed balances of DueTo and DueFrom for all other organizations.
- You want to execute business logic after a document posts using fireDocValidate. You can kick off a workflow, create new records, review the current document and posted facts (GL entries).
Implementation
To make use of the above validator hooks, you create a plugin using the factory method. The concept is similar to creating a process using the factory method. The general steps for fireFactsValidate(...) are:
- Create a new plugin
- Create a class that implement the FactsValidator interface
- Create a factor in your plugin to let the system know that your plugin implements the FactsValidator interface (see process example for details)
Notes
Be aware that implementing logic at the Fact_Acct (GL) level is pretty late in the process. A document will not post until after it is complete. If the document (example: AP Invoice) was created in error (example: missing a Profit Center), you might not be able to change the document after the GL validator throws an error. In the case of an AP Invoice, the user would need to Reverse Correct the original invoice and create a new one. An alternative is to implement Document Validation to ensure the document valid before you allow the user to complete it.