All documents required by law have been developed to become models that meet every type of business need. Templates are created using OpenOffice by merging with fields in the coreBos application. Each template is designed to be compiled or merged against one entity. The module Merge Labels is a specified created module that determines the related information you can merge inside the template, as fields labels. This extension ins will list all available fields for each module and their internal name so we can easily copy and paste the field names into our OpenOffice template documents. Then they are uploaded to the Documents module in OpenOffice format. And through the actions created, these models can be generated automatically by data related to a specific organization and the result is the custom printable document. We as a business solution company are committed to improving the use of Open Source tools and applications and this is one of the reasons why OpenOffice is chosen instead of Microsoft Word, with the guarantee of such sensitive data will not be the subject of some incidents of lack of information from third parties.
Some of the advantages that have been used by this extortion is its ability to create a document written in OpenOffice and make it parameterized, so they can be customized when some data is retrieved from the database for specifics field of the document.Gendoc has a simple syntax using mainly directives like for each, if exists, iteration. Based on syntax are created all the templates for GDPR compliance. Rather than static documents that need to be customized manually, using the above features in GenDoc, you can create some models with dynamic field or part. Furthermore, the completion of dynamic fields on the document could be conditional.
Every GDPR template start with the organization module which represents the client in terms of business. Through Gendoc syntax were able to access all the fields on the organization but also all the information of related entities with this account like employee, physical areas or third parties.This means that each template need a starting module and record. In general the field substitution marker is {Entity.field}, where Entity is the module name and the field is the internal coreBOS field name.
We used {foreach entity} directive to merge all the related entities with the main merge entity to build dynamic documents, if the system finds related entities Gendoc will add the result to the final document but if no related entity is found the whole block will be ignored. Inside the block fields are supported even > < >= ⇐ = != operators for more detailed conditions. Using the fact the foreach directive accepts a module name as a parameter, we used the for each syntax on GDPR templates to build conditional expression to retrieve all the third parties related with the organization, and then generating all the corresponding letters of engagements in order to be compliant with GDPR.
some field in the compilation. We used if exists directive to build boolean logic expression in the employee- organization relation. In the cases that the employee record related with the main entity is data protection officer (DPO), inside the document are merged all the legal information related that GDPR adheres. For example {ifexists Employees.empisdpo=1} condition guarantees that all text contained inside the {ifexists} and {/ifexists} will be added to the final document. So in other words if there exists at least one employee related to the main entity Organizations whose indicated field empisdpo is checked the text will be merged. If the entity or field does not exist the whole block will be ignored.
As with the foreach directive, we can also use some conditionals like this: This text will appear if there are one or more inventory lines with a total amount superior to 150 . For each related entity of the parent merge entity it will merge the entire text contained between the two commands and add the result to the final document, if no related entity is found the entire block will be ignored.
The ifexists/ifnotexists directives will permit us to create flexible and adaptable templates that can cover many cases. Also, these directives can be combined with the foreach directive in order to create extremely functional structures. The nested foreach use case has more powerful effect.
The label's name is expression and it permits us to tap into all of the functionality that already exists in the coreBOS workflow expression language. So if you know how to define a workflow expression you also know how to add one here. This is basically custom coding right in your template using a language you already know how to work with (or you should know).
GenDoc also can repeat a part of the document as many times as the result of the condition is true through iteration keywords. Inside the {foreach} blocks is referenced a special variable called {iteration} whose value will be that of the current loop iteration. This was useful to enumerate the elements or to print conditional text based on the iteration. Fields with multiple values (multiple selection) are supported directly, no special syntax is required.