Maintaining System Configuration

This transaction serves to maintain system parameters.

The following transaction can be started by clicking the icon for:

• Modifying System Parameter
• Printing system parameters.

The modifications to the system parameters are saved to the TDPARA.INI and DNGPARA.INI files, respectively.

Details are described in the individual transaction panels.

In this panel, individual message channels can be deactivated on a centralized basis. What message channels are available in the table on this panel is defined in the transaction “Maintain Codetables” for table CORTYP.

A message channel is deactivated by not marking the checkbox “Active” of the table on the “message parameter” panel. In processing business transactions, this results in no messages being created any longer in the deactivated format. In the master data on the party in question, an authentication for deactivated channels is not possible.

Autoconvert Standby L/C message :

• The free format message for Standby L/C’s could be generated in two different formats/structures.
• The format/structure could be parameterized by selecting one of the below options:
  • Free format message: The content in the tag 79 narrative of the free format message will be like the letter equivalent of the respective correspondence (e.g. letter amendment message).
  • Original message structure: The content in the tag 79 narrative of the free format message will be like the former original SWIFT message format in a tagged pretty print format but without the individual tag numbers mentioned.

Using the 'Letter layout' panel and other transactions, a number of settings can be made to enable outgoing correspondence on letterheads to be adjusted to the bank's corporate identity parameters in terms of fonts, structure and layout.

The “Letter layout” field provides for 2 possible variants:

In the standard definition, all fields and positions are defined in the header and footer and cannot be modified. Using the [Visualize] button (preview of settings selected), a specimen of the default layout can be viewed. The elements listed in the default definition are adjusted in terms of size and fonts to the document stylesheet / page layout of the letters (in MyModelbank 'a4.xsi'). However, these formatting parameters could be changed via the 'Maintaining document formatting' transaction that can be launched by the [Doc. Style] button. The page layout of the XSI files can be adjusted here.

The benefit of this variant is that there already is a prepared layout that can be used immediately.

To use an own template, the entry 'Use scanned Image' must be selected in the “Letter layout” field. This will result in the “Sender/Header Block by Application” and the “Image Type” field. In the “Image Type” field, a choice can be made between a digital template and letterhead:

• Digital: a scanned image can be used that already contains the logo, the footer, group details and information on the management and supervisory board. This scanned image may be language-dependent and needs to be stored in the frame directory of the installation for each language. In the “Image File path” field, the scan must be selected.
• Stationery: A letterhead can be used which, like the scanned image, may already contain a logo.

As a rule, the structure of a letter is based on the following sub-elements for which a decision can be made as to whether these elements are to be displayed in your letter layout:

• Logo: The file containing the bank's logo for the default layout ('Use Standard layout' was selected), is entered per entity in the “Maintaining Entities” transaction in the “Logo file in letters”.

• Sender details (information on the user, user group, branch): A choice can be made between 2 settings in the 'Output sender information' field. 'Do not use sender details' and 'Use template and sender details':
  • 'Use image and sender block': The block containing the sender details in the header of the letter corresponds to the default layout of the demobase in relation to the fields and positions output there.
  • 'Do not use sender block': The block containing the sender details is not output. Only the letterhead or the scanned template and side footer of the default layout are used.
• Page format: The page format, i.e. height and width of a page, the size of the header, the main section and the footer must be entered in the “Maintaining Document Formattings” transaction. This transaction can be started by the [Doc. Style] button. The page layout of the XSI files can be adjusted here. Outgoing messages by letter in the MyModelbank use the xsi file 'a4.xsi'. We recommend adjusting this xsi file rather than defining a new one.

The [Visualize] button can be used to check the effects of all settings.

In this panel, the default values are defined that are used for processing and settlement of an order in the absence of anything to the contrary being defined in the “Maintaining Service Level Agreements” transaction.

• Processing Time: The time stipulated by the bank for processing, i.e. the time required by a bank clerk for recording purposes.
• Release Time: The time specified by the bank that a controller needs for the release.
• Manager Proc. Time: The time the managers need for technical processing of the order (until the services for release (REL or FIN) have been dealt with).
• SLA Limit: The maximum duration of an order, i.e. specifically until the customer provides feedback (as a rule, in the form of correspondence) on his or her order. The content of the field must be greater than the sum total of processing/release time and the manager processing time.
• Cut-Off Time: The point in time at which the daily processing cut is made, i.e. all orders received after the defined cut-off time will only be available for processing on the following business day.
• Buffer time: This notifies the user as early as possible about a possible danger to an SLA. The field is used to define when an order is to be switched from normal ('green') to warning ('yellow').
• Diary Time: This indicates the processing time per diary. This value is generally overridden by the SLA.
• Order Workflow Time: Defines the throughput time of an order through the pre-order workflow.
• SLA days: If this value is > 0, one or more days are added to the processing time. The cut-off time is only taken into account on the day on which the processing time expires. The calculation is carried out exactly to the day. This adds 1440 minutes (24 hours * 60 minutes) per day.

Meaning of factors: In the fields “Paused”, “correction” and “manual”, a factor can be recorded for calculating the throughput time. The processing time is then calculated by means of this factor.

Example: The parameter defined for the processing time is 180 minutes, interrupted transactions are calculated at a factor of 50%, and transactions to be corrected using a factor of 10%. If the recording of a business transaction is paused, then a processing time now amounting to 90 minutes will be determined for the SPT, and if the transaction is sent for correction, the processing time specified is 18 minutes.

On this panel the 4 Eye Control for static data systems can be activated or deactivated.

For upcoming Standards Releases the activation date(s) can be entered. In addition, activation dates for other topics are mentioned here, if needed.

The general logic of all fields is to enter as date the first date from which new functionality per each topic shall become active.

Production environment:

• In a productive environment, the date must be set to the official release date as announced by the respective community.
• If the activation date field remains empty, the functionality is automatically activated by the application on the “official” release date.

Test environment:

• To test the functionality, the date should be set to any other date.
• Previous functionality to be tested with a current operating date before the activation date.
• New functionality to be tested with an operating date as of or after the activation date.

Swift Standards Releases SR20xx Activation on::

• This is related to the annual Swift Interbank Standards Releases for MT messages.
• In case there are no changes for the messages which are supported by this application, then this option is invisible.
• If an activation date is entered, the new logic will be activated for the Swift MT interbank messages.
• If other correspondent channels (such as SWIFT Score, Bolero, DTA, etc.) are affected by the “interbank” changes as well, then this activation date also activates the related changes in these channels.

Swift CBPR+ activation on:

• Swift interbank payment messages are by default generated as Swift MT messages.
  If activated Swift payment messages are generated as MX messages in XML from the given date.
• MT payment messages and MX (CBPR+) payment messages cannot be generated in parallel by this application.
• For production: The bank using application can decide to activate the functionality at any date between 20. March 2023 and 20. November 2025 to switch from MT- to MX-payments.
• The latest activation date for MX (CBPR+) payments is Sunday, 23. November 2025.

T2 RTGS activation on:

• Target2 system replaces its existing functionality as a 'Big Bang' and is renamed to “T2 RTGS”.
• Before the activation date, Target2 payment messages in a specific Target2 MT format are created.
• After activation date, T2 RTGS payment messages are created in the new XML format.
• The activation date for T2 RTGS payment messages must be Monday, 20. March 2023.

SIC activation on:

• Used to activate the latest version for SIC and euroSIC payment messages (pacs.008 and pacs.009).
• Currently this can be used only by banks, which have set Swiss Franc “CHF” as base currency in the application.
• The activation date for SIC/euroSIC payments is Sunday, 20. November 2022.

Swift Autoconvert to MT759:

• For Letters with no dedicated SWIFT message type of category 7 (MT7xx), DOKA-NG uses autoconversion to MT799.
• Based on the SWIFT recommendation, MT759 should be used instead of MT799 and usage of MT799 shall be reduced.
• On selecting the checkbox “Swift Autoconvert to MT759”, messages will be autoconverted to MT759 instead of MT799.

On this panel it is possible to define which fields in the application shall be checked by a compliance system. Further information is available under Compliance.

System Settings
Message Parameters
Letter Layout
Reference Numbers
Service Level Agreement
Static Data
Swift Release
Technical E-Mail Settings
Compliance

The 16-digit reference number consists of a prefix of up to 5 digits that can be defined per business sector and an 11-digit fixed suffix.
Structure of the digits available: [yy][nnnnn][-nnn], i.e. 2 digits for the year, 5 digits for the numerator, and 4 digits for the subcontract numerator. The numerator portion of the main contract is transferred to the subcontract.
Example of a reference number: Main contract: [Prefix]1100001 , Subcontract: [Prefix]1100001-001