The Validate Account Code (Budget Check) integration is a real-time, synchronous process that verifies financial data at the point of checkout. When a user clicks "Checkout," Unimarket sends a request to your ERP or Finance system. To confirm that the chosen account combinations are valid and that sufficient budget exists.
Integration Process
Trigger: The process starts automatically when a user attempts to finalize their requisition.
Request: Unimarket sends an XML message containing line numbers, account codes, and transaction amounts.
ERP Check: Your ERP processes this data based on your specific business logic.
Response: The ERP returns a status of Valid, Invalid, or Warning, which Unimarket uses to either allow the checkout or stop it with a message to the user.
Implementation Options via Unimarket Connector
If you are using the Unimarket Connector middleware, you can choose between two main configuration methods:
Option 1: Calling a Stored Procedure (SP)
The Connector executes a customer-defined stored procedure in the ERP database to perform the validation.
| Feature | Details |
|---|---|
| Input Data | Line numbers, account strings, and total amounts (plus optional fields like username or financial year). |
| Output Data | Returns the status (Valid/Invalid/Warning) and a custom message for the buyer. |
| Pros | High security (budget values are hidden); real-time data; total control over business logic. |
| Cons | Higher implementation effort; requires handling complex data types. |
- line_number : Integer - line number of items in the checkout
- account : String - the account code for the line item
- amount : numeric - the value to checkout for the line item
Optional Values
The following optional values can be used:
- Username: The user trying to purchase against the account code. Used to determine if they have permission to purchase against the account.
- Organization unit: The user's organization unit. Used to determine if they have permission to purchase against the account.
- Finance year: The Financial Year of the transaction used to validate the correct budget year. Only applicable if the community has FY's setup.
INPUT to the SP: (minimum required) (example as JSON array)
[
{"line_number": 1, "account": 123-4567-10, "amount": 123.12},
{"line_number": 2, "account": 123-4567-11, "amount": 200.00},
{"line_number": 3, "account": 123-4567-12, "amount": 738.50},
{"line_number": 4, "account": 123-4567-13, "amount": 120.15},
{"line_number": 5, "account": 123-4567-14, "amount": 23.12}
]
OUTPUT after SP call:
[
{"line_number": 1, "status": "Valid", "message": ""},
{"line_number": 2, "status": "Invalid", "message": "Some message"},
{"line_number": 3, "status": "Invalid", "message": "Some message"},
{"line_number": 4, "status": "Warning", "message": ""},
{"line_number": 5, "status": "Valid", "message": ""}
]
Option 2: Reading a Budget Table
The Connector performs a lookup against a simplified "budget table" provided by the customer.
| Feature | Details |
|---|---|
| Table Structure | Requires a minimum of two columns: Account Code and Budget amount. |
| Logic | Any account not found in the table is automatically rejected as "Invalid". |
| Pros | Very simple to implement on the customer side. |
| Cons | Less "real-time" (depends on table refresh frequency); actual budget numbers are exposed to the Connector. |
Minimum table structure required:
"ACCOUNT CODE", "BUDGET"
4740-14100-10, 46.33
4740-14100-11, -114.5
4740-14100-12, 500.32
Response Types and User Experience
| Result | Outcome for the User |
|---|---|
| Valid | The requisition proceeds to the next stage of checkout normally. |
| Invalid | A hard stop; the user cannot proceed and must change the accounting data. |
| Warning | A soft stop; a message (e.g., "Budget is low") is displayed, but the user can click checkout again to proceed. |