Data in the Accounting Engine
Overview
There are 2 different types of data in the Accounting Engine:
- Configuration data - the data (input by the user) to define the accounting rules and determine the range of outputs possible for a given set of input transactions
- Transactional data - the raw Business Events (real world/life-cycle) which the Accounting Rules Navigator processes and ultimately converts into journals
Input Data Structure
The Accounting Engine can receive financial data in the form of a Business Event. These Business Events are representations of real-world transactions or life-cycle events, with a structure defined by the user. You can send records with multiple amounts and relevant information. Based on the set configuration, one of the amounts, the Transaction Amount, will be used for processing.
Business Events
A Business Event is a representation of real-world transactions or life-cycle events, with a structure defined by the user. They are referred to in the system as Business Event Types.
Accounting Engine Output
“Complete Journal” - an accounting entry enriched with all the required fields/details that can be consumed by a target system (GL/SLR).
Grouping
Journal Lines generated by the Accounting Engine are grouped within a Journal by Core Date, Subledger Node, and Accounting Basis.
This ensures that all Journal Lines in a Journal have:
- The same Accounting Basis
- The same Subledger Node
- The same Core Date
This prevents, e.g. reversing and permanent Journal Lines to be grouped within on Journal.
Reprocessing
Fynapse supports the reprocessing of failed Business Events, Business Event rollback, and Journals.
Business Events
A Business Event is considered failed if it does not create a Journal. What that means is an error occurs during processing, which prevents Fynapse from generating Journal Lines from a submitted Business Event. Such failed Business Event is then marked as errored and submitted for reprocessing.
For more details, refer to How Do I Know a Business Event Is Errored? in Business Event Definition.
Journals
A Journal which was successfully generated from a Business Event is considered failed in two instances:
- The Posting Date of the Journal falls into a closed period
- The created Journal fails a validation created for Journals by the user
For more details, refer to Validations.
Information about why a record failed can be downloaded from the Error Management screen. You can then:
- For Business Events, correct the configuration which resulted in an errored Business Event
- For Journals:
- Open a closed period
- Change the validation which caused the Journal to fail
The failed records will be automatically resubmitted for reprocessing. Fynapse automatically submits all failed records for reprocessing according to schedules defined by users with the Fynapse System Administrator role via the Reprocessing screen. A failed record will be automatically submitted for reprocessing for a defined number of retries starting from the date it was first marked as errored. If you do not remove the cause of the error after the defined limit of retries, the record will remain in the errored status.
Currently, automatic resubmission occurs by default once a day at 8:00 UTC unless it is defined differently by a user with the Fynapse System Administrator role.
You can also trigger reprocessing manually, outside of the allocated automatic reprocessing slots.
For more details about triggering manual reprocessing, refer to Error Management.
Posting Components
Posting Components are configurations of DR/CR patterns which are the first step in creating Journals. Based on the criteria defined in a Posting Pattern, a Business Event will generate a number of Debit and Credit records.
A Business Event can have multiple Posting Components linked to it, each of which can have its own criteria assigned to determine when the Posting Component is triggered. This means that a Business Event can generate outputs for more than one Accounting Configuration.
Posting Components can be re-used across different Business Events, which reduces the need for duplication of Posting Components and then eases the maintenance.
Based on the defined Posting Patterns, each Posting Component can contain many DR/CRs each of which can be triggered in different situations.
Posting Components assign a Posting Code during processing, which is then used to derive the General Ledger account.
Moreover, Posting Components create records on different dates, e.g. trade & settlement, from a single Business Event.
Posting Components can be managed either via the UI or via a bulk upload process.
