Document Editor

DOKA-NG provides an exhaustive collection of predefined letters. Correspondence towards the customer and correspondent side is created in almost every business transaction. The transaction documentation of each business transaction, for example Opening an Import L/C) describes in the section 'Outgoing Correspondence' in detail which messages can be created under which conditions and who the receiver of the message is. The texts and rules for creation of these letters are stored within the application.

The “Document Editor” is a built-in functionality available in all business sectors of the application and allows the user to overwrite existing letter correspondence to make minor text adjustments such as

• text additions,
• suppression of texts or
• small formatting changes etc.

These changes can be stored for future usage of the outgoing correspondence.

For any business transaction once the relevant information is filled into the transaction panels, the expected letter correspondence is displayed on the “Messages” panel and from this panel the required language can be set from the dropdown options available. To edit any specific letter template first the magnifying glass icon needs to be clicked to generate the letter and then the specific paragraph or text needs to be selected and double clicked in order to initiate the “Document Editor” window which will reflect the “XML templates” only specific to the selected text and paragraph.

Alternatively to initiate the “Document Editor” one may click on the pencil tab in the “Messages” panel and then further click on the “Document Editor” button. The “Document Editor” window now reflects all the “XML templates” included in the subject letter.

The “XML templates” can be selected one after one to verify the text content both in the original language as well as the content in other translated languages and also the status of the XML templates whether it has been modified or not can be verified.

The Document Editor can be properly be used in Server environments only.

The changes made in the “Document Editor” are stored in the “XMX” (“XML templates”) and “XMR” (“Document rules”) tables under different Key types defined at specific level. These Key types are based on predefined conditions which decides at which business scenario the amended text will be generated.

Ideally to have proper control, the provision of “Document Editor” should be restricted to a Pre-Production or UAT environment and upon validation of the changes should be gradually transported into the production environment via Handling Updates of Data with 4-eye control.

The “Document Editor” functionality allows the users to update, amend and delete the required text and save all the changes made into the letter template at once. As an interactive development, the changes made into the letter templates can be applied and verified on a real time basis.

There are provisions for users to edit the “XML templates” and to update the document rules in the sources. However, those provision has been granted under specific user rights in transaction Maintaining User Profiles.

• User defined as “Document Editor” – An user having rights only for editing the text in “XML template”. This is for the non-technical business users as it allows to change the text only.

• User defined as “Designer” – An user having rights for both editing “XML templates” as well as updating document rules. This is for technically advanced or experienced users with sufficient knowledge to understand the impact of change in the document rules.

For any user having “Document Editor” profile, the advanced document rule update options like “Insert Field” and “Edit Logic” are not available.

The below common functionalities are available for users defined as “Document Editor” and “Designer”:

• “Paragraph by name” - This field allows users to search the text templates by its name. There is provision to key in only a part of the name and then to click on “Search” button to find the target “XML templates” from a list of templates with similar names.

• “Paragraph by content” - This field allows users to key in a part of the content and then click on “Search” button to find the list of templates having similar content. In order to have better search results, search can be done using both by name and content simultaneously.

• “List of Paragraphs” - This field helps the user to select and toggle between the text templates used in the letter.

• “Paragraphs” - Based on the selection of text template at the “List of Paragraphs” field, this field helps the user to know available Key types which reflects under the “Key” column along with its respective level shown under the “Modify in” column. This column helps to determine the specific business scenario at which a specific amended text will be generated. Below are the available key types ordered from very specific towards generic level.
• Document Rule - This implies text content specific to xml template within a specific letter, for instance if within a letter an “XML Template” is modified under the Document Rule Key type then the same change will only reflect for the same letter and “XML Template”combination. The modification in “XML Template” wont reflect if it is used within a different letter.

• Transaction - This implies text content specific to transaction level, for instance such modification in “XML Template” will be reflecting in the letters used within a specific Transactions only like - LITOPN, BCTDAV etc.

• Business Sector - This implies text content specific to Business Sector level, for instance such modification in “XML Template” will be reflecting in the letters used within a specific business sectors like - Export LC, Import LC etc.

• All - This implies text content generic across all business sectors, for instance once an “XML Template” is modified, then the change will be reflected across all letters using the same “XML Template”.

By Default, the text content across all the Key types are identical for a specific “XML template”. However, once amended the text content of the more specific Key type will supersede the other Key types in case amended text content exists at multiple Key types for a specific “XML template”. It also helps to know the status of the templates whether it has been modified or not. The “Modified” column displays either “Yes” or “No” to indicate whether modification of the “XML template” has already taken place or not. Whenever any of the templates are selected, the text content both in original and translated languages are available under “Paragraph Content” and “Same Paragraph in” field respectively. It is for the user to decide whether to use customized or generic texts for every transaction types using a specific “XML template”.

• “Show All” - Once checked, this checkbox displays all the “XML templates” available in the source code of a specific letter. Please note that this is an exhaustive list and only a few of these “XML templates” may be in use at a single instance based on the inherent business logic.

• “Paragraph Content” - Upon selection of any specific “XML template” from the “Paragraphs” field, the “Paragraph Content” reflects the text content in original language along with the language name. This panel is editable and it allow users to amend the text content and save the content on a real time basis by clicking on the “Apply” button. All the text changes will be applied immediately on the subject document and the same can be verified upon reopening the same.

Once the “Paragraph Content” tab is updated with new text, there after when user clicks on the next “XML template” the “Paragraphs” field reflects the “Modified” status as “Save Pending”. Now users have the option to either to save or discard the changes by clicking in the “Apply” or “Discard” button accordingly.

• “Same Paragraph in” - Upon selection of any specific “XML template” from the “Paragraphs” field, the “Same Paragraph in” field reflects the text content in a translated language and the name of the language available. The content of this field is restricted and cannot be changed however it allows the user to select other languages into which the text is translated. In case a new text is inserted in the “Paragraph Content”, the translation of the newly added text needs to be manually updated in the “Same Paragraph in” field.

• “Default” - In case the change in text needs to be reinstated back to its original state, the same can be achieved by clicking the “Default” button. The “Default” option helps to reinstate the original text from the source, even if the text changes is already applied and saved. Once the texts under “XML templates” are reinstated into its default format, the “Modified” column in “Paragraphs” field changes its status from “Yes” to “No” automatically.

Any modification or insertion of text content within those specific “XML templates” that contain an argument (e.g. {$1}) or the blank templates (eg. TRNDOC:emptyline template) should be avoided at first place, otherwise it may lead to certain structural problems. Also any change of “XML templates” in the central modules for example the Settlement module (SETMOD) should be evaluated carefully as this may cause generic impact across the entire application.

The below functionalities are available only for “Designer” user categories -

• “Insert Field” - The “Insert Field” button allows user to insert additional database fields into the content of “XML templates” across any Key types whenever required. Upon clicking on the “Insert Field” button, the “Field Inspector” window is displayed in which any database field from the present transaction can be selected and included in the respective “XML templates”. In general, the field name included in the template appears to be within brackets or sometimes comes with additional function name along with it. When the letter is printed the actual field content will be only visible. Since the “Insert Field” function is more of technical in nature, hence the same is allowed only for users that are defined as “Designer” in the user profile.

• “Edit Logic” - In order to change the document rules the user needs to click on the “Edit Logic” button and update the new rules in “Edit Document” window under a specific “DocRule ID”. It also allows the user to specify the Key types for which this document rule can be used. Now once the new document rule is incorporated,
• the “Discard” button can be used to come out without saving the new rules,
• the “Check” button can be used for compilation, and
• the “Save” button can be used for both compilation and storing the new rule.

By Default, the document rules across all the Key types are identical for a specific “DocRule ID”. However, once amended the new doc rule of the more specific Key type will supersede than that of the other Key types in case new doc rule exists at multiple Key types for a specific “DocRule ID”. The stored document rules are always executed without any error since the changes are already complied while saving and hence there is no possibility of getting error during execution. The document reflects the updated document rule immediately the next time the document is opened. The document rules need to be handled with care since it requires sound technical understanding and hence the same is allowed only for the Designer category of users.

Once changes are made in any specific document using the “Document Editor”, the same will be stored in the database and will be available for all the future contracts.

For database security, commands that might change the database through document rules cannot be stored and will generate an error, for example TradeDesign commands such as 'DBexecutesql' or 'DBread'.

All changes made using Document Editor functionality can be displayed via transaction Maintaining Document Templates. Changes to the document rules can be displayed via transaction Maintaining Document Rules.

The “Document Editor” allows editing of letter correspondence only. Electronic messages such as SWIFT, Score, Bolero, allNETT etc. cannot be changed.

The “Document Editor” allows only to overwrite the existing “XML templates” or the document rules within the letter. In case any additional “XML template” or rule is requested that would follow standard overlay development process. Once the additional template or rule is developed and delivered into the base version, the users will be able to modify the same.

In case any additional documents are required or if the letter changes are complex in nature, those changes will be treated under standard overlay development.