Financial posting management overview
Interfacing is supported between Civica Cx Housing and third party financial accounting systems for the transfer of all relevant transactional events. Groups of transactions can be combined into a financial batch and then submitted for upload to the finance system into the live accounts. The first step in the process is to construct a financial map to configure the nominal ledger account codes into which the transactions will be posted. In its simplest form, a map must specify the profit & loss and contra balance sheet codes into which the transactions will be posted. A second set of codes can also be nominated, as required, to match the housing organisation's accounting requirements e.g. as sub-ledger codes or for cost centre control. As the number of generated transactions will be significant, and often to the same set of ledger codes, the system provides a 'consolidation' option, allowing like transactions to be rolled-up into an overall sub-total and posted as a single entry. The structure of the financial posting map is compiled through the addition of discrete data fields, defining how each data element required by the import routines of the nominated third party accounting system map to a counterpart within Civica Cx Housing. As the import structure for each third party accounting system is prescribed, all relevant source fields will be automatically available for selection in the corresponding configuration window. Similarly, the field order dictated by this structure is automatically applied to the relevant data on export; hence there is no requirement to assign column positions to the individual field mappings. In addition to the two field level mapping options that are available to the end user - a default (fixed) value or specific system entity - more complex requirements can be captured within a SQL stored procedure, as required.
Before a posting map is effective, it must be linked to a definition. The definition controls the desired subset of transactions for inclusion in a financial batch, storing the relevant transaction type (Invoice, Works order, etc) from where the subset will be derived. Over and above the core transaction elements, it is also possible to include additional analysis fields within each batch posting (e.g. Repair commitment works order priorities). Whilst a definition can be used as a receptacle for all transactions of the selected type, any number of rules can also be linked to refine the subset of transactions. For example, a rule could easily be created to, say, include only repair-originating transactions with a priority set to 'Emergency'. Where multiple rules exist, standard And / Or expression operators are automatically applied to make logical sense of the combined rules. To successfully manage transactions containing a VAT element, at least one additional definition is required, flagged as VAT related. This will be used to capture VAT values for transactions included in the results set. Where no matching definition can be found for the transactions being processed (net or VAT elements), an entry is automatically recorded in the error audit log, stamped with the current system date and assigned a qualifying reason.
On final submission of the batch, each included transaction is marked, ready for interfacing with a third party finance system, thus eliminating the possibility of duplication.
Separate help articles have been created for each key aspect of financial posting management, including:
In addition, separate help articles focus on the generation and submission of financial batches, specifically: