Installation & Configuration
This section describes the procedure for integrating the Data Capture module into an existing project. It is essential to ensure that you are using the version of the module that corresponds to the version of Axelor Open Suite (AOS) currently deployed. A summary table, available in the first few pages, allows you to check compatibility between versions.
Prerequisites
Prerequisites: correct use of AOS products requires valid Guardian licenses. First and foremost, you must have an AOS web app.
In the settings.gradle file of this web app, it is essential to add a Maven reference to enable dependencies that will be retrieved from the company's Nexus.
Installation
During installation, it is essential to ensure compatibility between the desired version of the Data Capture module and the version of Axelor Open Suite (AOS) currently in place. To integrate the Dematerialization module, you must add the Nexus dependency that corresponds to a target version.
Depending on the project requirements, it is also possible to include dependencies on the Edifact, Mindee, or Rossum modules.
If only Edifact format files are used, it is possible to integrate only the dependency for this specific module, without using the entire Dematerialization module.
Additional libraries
No specific action is required to use the Edifact-lib and FacturX-lib libraries. The Edifact-lib library is automatically included with the Edifact module, while FacturX-lib is integrated into the Dematerialization module.
Configuration
Customizing data extraction according to specific business needs requires configuring the various elements mentioned above. This section proposes a step-by-step configuration method, structured in what is considered to be the most intuitive order.
All file types will be converted and interpreted in JSON format, allowing for consistent configuration of the various elements.
However, for certain specific formats, such as Edifact, this conversion to JSON may not be immediately understandable. A later section will provide additional details on this subject.
A concrete example will be used in the following steps to facilitate understanding.
Schema
- The first step is to complete the schema header by indicating its name, the type of application (Edifact, JSON, etc.), and the type of document that will be generated (e.g., invoice, purchase order, etc.).
- Next, you need to define the different fields to be extracted. Each field must be named and then associated with a path corresponding to the structure of the JSON file, to be entered in the “Element” field. The $ symbol is used to navigate the file hierarchy.
For example, to extract information about the document type, you would specify: information$type.
If the data to be extracted is in a list, the “Parent element” field must be filled in with the key corresponding to that list. In the example, it is possible to retrieve all the dates using the Dates key (see image above):
- To illustrate this with the extraction of all dates, if the objective is to extract a particular element within a repeated set, it is possible to apply a conditional filter using the @ character.
For example, to retrieve only the receipt date, apply a filter to the “date” element based on the value of the ‘type’ key, then specify that the element to be extracted is “value”.
The path in the “Element” field will then be: date_list$date[@type=‘receipt’]$value
Mapping rules
To associate an extracted value with a field in the final document, you must select the corresponding checkbox. Once this step has been completed, you must define the mapping rule to apply (the rule according to which the association takes place).
Creating a mapping rule involves several steps:
-
Select the target field to be filled in the document.
-
Choose the type of generation to use from the following three options:
-
From extracted data: the value is used as is, directly from the source file.
-
Mapping table: the extracted value is transformed by applying a predefined mapping table.
-
Groovy formula: the value is processed using a Groovy formula, and the result of the formula is used.
A dummy field named extracted has been introduced to make it easier to write formulas. It allows direct access to the extracted value.
An example of the formula:
- In the specific case of list management, it is essential to activate the ”Line type object" field. You must then specify the list to be generated in the document as well as the field to be filled in.
Extraction rule
In some cases, raw data must be interpreted before it can be associated. To do this, you need to define an extraction rule. This rule allows you to apply a Groovy formula to the extracted data.
For example, if the dates are provided in the yyyymmdd format, but Axelor Open Suite expects a yyyy-mm-dd format, an extraction rule must be used to perform the appropriate conversion.
In this case, the value displayed in the “Extracted data” field will correspond to the result of the Groovy formula. It will no longer correspond to the raw data as it appears in the source file.
Default mapping rule
Sometimes, certain fields in the generated document require generic information that is not directly present in the source file. In this case, you can use the default mapping rules.
These rules work in a similar way to conventional mapping rules, allowing the use of correspondence tables or Groovy formulas.
However, they offer an additional feature: the ability to use default processes to generate data. This option allows certain fields to be pre-filled automatically using Axelor Open Suite (AOS) internal processes.
For example, in AOS invoice lines, tax line sets (taxLineSets) are automatically filled in when a product is selected. This behavior can be reproduced using default mapping rules.
Additional configuration
A dedicated panel allows you to define the view that will be used once the object has been generated, as well as the models and parameters associated with the relevant schema.
Capture parameters
Capture parameters are the central element of the Data Capture configuration. They allow the same schema to be applied to multiple models while ensuring the consistency of the processed data.
First, fill in the header by specifying the type of used application (e.g., Edifact, JSON, etc.) and the capture schema to be applied.
Next, select the generation type from the available options:
-
Generate from the captured data: this is the classic mode, in which the provided file is used directly to feed the template.
-
Generate from the orders / supplier arrivals: these options allow you to retrieve an existing object in AOS (for example, an order) from a reference and generate a document (such as an invoice) based on the data that is already present in the system.
This approach not only allows you to rely on standard ERP processes, but also to compare the information extracted from the file with that generated by AOS, thus ensuring consistency.
Control rules
It is possible to add business control rules to mapped data in order to verify its consistency. These rules are expressed using Groovy formulas and can be defined as blocking or non-blocking.
They alert the user during data validation in the event of inconsistencies and can automatically interrupt the process in the context of automatic generation if the conditions are not met.
Post-processing formula
A post-processing formula can also be configured. It allows additional actions to be triggered after data integration, such as sending notifications, executing workflows, or other automations.
Special cases
In the specific case of invoice generation, additional parameters are available. In particular, they allow:
-
Automate the creation of an object as soon as the template is defined.
-
Consolidate invoice lines as needed.
Data capture template
The creation of a Data Capture template consists of the following steps:
-
Selecting the type of used application (e.g., Edifact, JSON, etc.).
-
Configure the appropriate capture settings.
-
Next, specify the file from which the data will be extracted.
Some fields, such as the associated schema, are filled in automatically. However, it is recommended that you check that these values correspond to desired elements.
At this stage, it is also possible to request an automatic generation of the document from the extracted data.
Once the template has been generated, various information becomes available and can be viewed for analysis or verification.
Mapped data: on the right-hand side of the screen, the various action buttons are displayed, as well as the mapped data according to the schema, integrated into the fields of generated document. If necessary, it is possible to modify this data before proceeding with its validation.
Extracted data: on the left side, the data extracted from the source file is visible. It can also be modified manually, provided that the debugging option, available in the right panel, is activated.
Depending on its type, the provided file is displayed in the center of the interface for easy reading.
At the bottom of the template, a box summarizes any anomalies, detected during the data extraction and mapping process.
Once the template has been validated, document generation can be launched. If it fails, the template automatically reverts to “anomaly” status, allowing the data to be reviewed and modified before a new attempt is made.
