Title: Financial Validation Stored Procedures
Our clients using the Financials license have a growing need to apply business rules to help ensure the right information is being saved and submitted when it comes to financial documents. To aid in this effort, Unanet can develop custom-made validations for Unanet Financials documents including Vendor Invoices, Vendor Payments, Customer Payments, Deposits, and Journal Entries.
The purpose of this document is to provide guidance on when Financial Validation Store Procedures (VSPs) can be use as well as some of the limitations and/or constraints to consider when developing these business rules.
What’s covered in this document:
When does it work
Similar to Unanet's existing Time and Expense VSPs, Financial VSPs are meant to work when:
- A user Saves, Submits, or Posts a financial document
- Bulk posting or copying Journal Entries
- A user is in the edit screen of the following financial documents
- Vendor Invoices (VI)
- Vendor Payment (VP)
- Customer Payment (CP)
- Journal Entry (JE)
- An error or warning can be used to enforce data validation
Although Financial VSPs provide additional data validation and enforcement capabilities, they cannot:
- Create a document
- Update/Insert a document
- Delete a document
Additional Items to be aware of:
- POST is not an explicit trigger for the VSPs: SUBMIT and POST both fire the SUBMIT VSP
- Warnings and Errors will only display on the DETAILS screens
For a client to leverage Financial VSPs, they use Unanet's standard validation store procedure process. A link to the process can be found here.
Depending on the VSPs defined by the engagement, enabling this feature requires the Unanet administrator to update the following properties:
Below, you will find some use cases where Financial VSPs can be leveraged.
Use Case 1: Enforce specific language in description field
You would like to capture specific information when creating a document that is eligible for validation.
The Financial VSP would provide this capability based on the document type:
Use Case 2: Enforce attachments exists
You would like to ensure at least one document is attached when submitting a document.
Use Case 3: Account type is correct
You would like to ensure the proper account type is being used when creating an eligible document that requires a specific account type.
Use Case: 4: Account that requires a project and project owning org is not correct
You would like to ensure that a project and related project owning org are correct when creating an eligible document.
Use Case 5: Validating Debit and Credit entries are recorded on same financial org
You would like to ensure that Journal Entries have the correct organization when the document is being created.
If you would like to start the process, please follow our standard validation store procedure process here.