MANAGEMENT CHART MODULE
The management chart module offers ISIE processing tracking functions. It includes statistics on the volumes of data processed and on the processing times.
This management chart module enables the following requirements to be met:
– Analysing and optimising performances.
– Replying to queries in the event of processing anomalies.
– Successfully tracking the ISIE processing without knowing the OS.
DATA ENTRY FORM MODULE
The data entry form module enables forms to be parameterised simply so that users may enter data directly in ISIE.
The data entries made using these forms are guided and checks are made instantaneously on the data.
The data entered may then be managed (visualisation, printing, deletion, etc.) via a consultation screen before being disseminated/synchronised within the information system:
– On systems downstream from the Interpreter (ISIE processing).
– On the ISIE data repositories (ISIE tables).
– On data repositories external to ISIE.
ACCOUNTING DOCUMENTATION MODULE
The ISIE solution includes an accounting documentation module, the aim of which is to provide return statements of the accounting entries produced by ISIE for operating users.
This module meets the following requirements:
– Simple implementation and maintenance
– In direct line with the ISIE parameterisation
– Based on production data
– Offering various returns: Accounting entry table, T accounts, graphs.
Using this module, a user can select one or more operating events that they wish to document and they have several accounting charts available and parameterised in ISIE which apply for these operating events.
Like the ISIE parameterising documentation and all the other ISIE modules, this accounting documentation module has the advantage of being totally integrated into the ISIE product. All the flow parameterisation is done in the design module; the parameterisation of the accounting documentation is a component of this parameterisation of the flows and may under no circumstances be desynchronised from it. Maintenance is thus facilitated, it is not necessary to parameterise and maintain a tool connected to the accounting interpreter to benefit from the documentation of the
DATA FINANCE MODULE
ISIE has a complete traceability module. This functionality enables, inter alia, traceability requirements to be met on accounting and financial data.
This module enables the record of the data received, processed and generated to be kept at the end of processing, in a parameterisable way. Thus, from a management movement received, ISIE, through the audit trail, enables the accounting entries generated at the end of processing (detailed and grouped) to be retrieved: top-down traceability.
From an accounting entry generated at the end, ISIE also makes it possible to retrieve the management movements at the origin of this accounting entry: bottom-up traceability.
The ISIE product enables the desired information to be parameterised in the audit trail:
– Type of outputs (EBS) to be tracked or not (general characteristic of the type of EBS).
– Indicator on the various parties involved using the “user” in order to track, inter alia, the production launch of the parameterisation.
– Data characterising the accounting entries generated (data to be kept for the EBSs declared as having to be tracked): data for which a function has been attributed.
– Data characterising the entry movements: “identifying” data.
Data feed into and operation of a financial database.
The ISIE product includes a module enabling a data warehouse of detailed financial data to be set up and the production of returns on these data.
This module meets the need to set up a third-party database (or auxiliary database, operating base, etc.) and to propose financial returns to provide documentary evidence of the financial statements, of the detailed financial analyses, a general balance sheet, etc.
The data constituting the data model originate from the ISIE processing operations: incoming flows (EO), detailed flows (EBS detail), aggregated outgoing flows (EBS), and data external to ISIE via enrichment variables. Navigation in the Data Finance model is done on the basis of a dynamic cross-reference table making it possible to zoom down to the most granular level of the detailed data. The results obtained can be exported in PDF format or in an Excel spreadsheet.
The implementation of this module is fully integrated and can be parameterised by the user in three phases:
– Parameterisation of the Finance Data: design and selection of the data in the design module.
– Data feed into the Finance Data: storage model for the data relating to the financial statements fed in as the ISIE processing operations are completed.
– Return of the data through the production of standard statements, and possibility of constituting your own returns from an Internet browser.
MANAGEMENT OF REJECTIONS MODULE
The ISIE solution includes rejection or anomalies and recycling management.
The movements processed in ISIE may be rejected for various reasons:
– Movement received from the upstream applications not conforming to the expected data (format incoherent, validation/list of values/to tables, etc.).
– Translation rule not provided for an EO received (possibility of parameterising the rejection of an event if no accounting entry could be generated).
– Error condition verified (e.g. validation of the existence of the account in the tables, after multiple accesses to various tables), etc.
This management of rejections enables unitary rejections and rejections in coherent information sets to be processed (batch management) This notion of batches is totally parameterisable and enables all the anomaly management requests to be answered.
Rejection management transactions enable:
– The number of movements rejected, the rejection dates and the number of associated rejections to be known.
– A rejected movement and the cause(s) of rejection to be known.
– A rejected movement to be modified.
– A rejected movement to be deleted.
The detection of an anomaly means the rejection of the original event(s) and thus guarantees the coherence of all the applications or data repositories fed in. Management of \u2028 alerts is thus fully integrated into the ISIE solution. As soon as a rejection is detected, an alert message can be sent using the customer’s messaging system to the desired recipient.\u2028. “Technical” rejections (processing interrupted, server down, etc.) are also managed using the administration console and the management chart module.
Parameterisation of the management rules
The ISIE design module is dedicated to the final users and it offers graphic modelling of the rules. This graphic parameterisation environment enables the rules to be retrieved in a user-friendly and explicit way. The implementation of the parameterisation of a flow is done entirely by parameterisation and with no programming. A user who is not an IT specialist but who has been trained on using the solution is perfectly capable of parameterising and maintaining the ISIE flows.
Parametrisation is done on the basis of parameterisation entities stored and available in data repository dictionaries. This principle enables re-usability and a centralised management of the rules, thus saving a great deal of time for parameterising and also facilitates the maintenance of the implementation rules.
The parameterisation is thus based on these “data repository” entities internal to ISIE:
– A dictionary of data internal to ISIE automatically repatriated, proposed as standard for the connectors or inputted manually. All the data which composes the entry and exit structures are referenced therein.
– A table manager internal to ISIE also enabling the external tables to be accessed to validate and, where necessary, enrich the information.
– Variables: results of operations (calculations, extractions, searches in tables, concatenation, etc.) defined uniquely by flow and that can be used at all levels of parameterisation (variables, conditions, accounting entries, etc.).
– Conditioned variables: implementation of conditioned variables for a complex parameterisation and enabling all types of inter-application translation requirements to be met.
– Simple or combined conditions defined uniquely for a flow and that can be used at all parameterisation levels (four levels of conditioning possible).
The possibility of combining the simple parameterisation entities enables very complex rules to be managed while keeping complete mastery, legibility and maintainability of these rules. These management rules are necessary within the context of the management of the interfaces between applications but may also be used within the context of the propagation of data repository items.