Batches transferred from an interface to the Open batch environment are referred to as automatically created batches. Batches can be transferred to the Open batch environment by using the Import from interface function on the Work with open batches panel (which is most common), or via the Transfer transactions from/to IFS program.
Automatic import of payments through the open batch process consists of the following steps:
- Preloading
- Loading
- Batch update
You also have the possibility to determine if the data should be loaded all the way through until it is updated in the system or stopped after reaching a certain processing status.
Import process
Transactions data which should be imported to DC1 must be loaded into the dedicated Open batch interface files. The standard starting panel for the import of transactions can be reached from the Work with open batches routine. On this panel all the necessary import parameters should be specified. It may be done either by indicating a Batch import option, which defines all the parameters, or by specifying each parameter separately.
A Template is one of the parameters, which is mandatory for import. The indicated template is used to display the imported batch data on the corresponding detail panel in the Work with open batches routine as well as to complete the interface file field values. The completion of the interface data is done the same way as the data completion on the manual registration panel, meaning the following:
- The field values are completed based on the initial constant values and initial parameters defined for the indicated template. See section Setting up the detail panel templates in Setting up the Open batch functionality.
- The data is completed according to the defaulting rules, based on the related field values.
The completion based on the template always precedes the defaulting process.
The Stop after loading, also a mandatory import parameter, defines if the loading process should be interrupted to enable maintenance in the Work with open batches routine. The possible alternatives are the following:
- The created batch is stopped in Work with open batches only if errors are found.
- It is always stopped, regardless of the validation result.
- It is stopped in Work with open batches before the data validation process is started. The transactions are not created yet, but the interface data is available for maintenance. The interrupted loading process should be manually started for the batch.
See Import batches from interface for detailed instructions.
The image below explains the process in which the transactions are loaded from the interface files to the batch files in the Open batch environment.
Flowchart
Interface files
The interface consists of a number of mutually related files into which the payment and settlement definitions should be entered before the loading process is started. The different interface files are:
- A/R payment interface file
- A/R settlement interface file
- cash book header interface file
- voucher additional information interface file
- sundry debtor address interface file
- document free text interface file
For more information, see About DC1 Financials interface environment.
Native files
A native file (or detail entry panel native file) is a file based on which transactions of the given type are automatically created. The native file consists of the transaction information along with the validation and status information. The native file structure is a mirror image of the corresponding detail registration panel structure. It enables viewing and validating interface data the same way as manual registration. Each transaction detail entry panel has a dedicated native file. The different native files are:
- voucher entry native file
- payment entry native file
- settlement data for payment entry native file
- cash book entry native file
- sundry information native file
Open batch files
Open batch files are the files currently existing in the system that store the data required for the open batch transaction processing. The following steps describe in detail the transfer of payments from the interface to the Open batch environment.
Batch preloading
During the payment preloading process the payment transactions are loaded from the interface files to the native files. Transactions are selected for preloading by the origin code value and organized into batches and vouchers by the preloader. The image below displays the payment preloading process in more detail.
Flowchart
During the batch preloading process, only the batch header is written directly to the open batch file as shown in the image above. The other interface descriptions are loaded to the corresponding native files (including voucher and cash book headers).
If the preloader is running in preload mode, i.e. Stop after loading is specified as 1 (Stop after preloading), the preloaded batch is not submitted for loading and the preloader advances to the next batch transaction, if it exists for selection.
If the preloader is running in load mode or in update mode, i.e. Stop after loading is specified as 2 (Stop after loading) or 3 (Don’t stop before update), then the loading process of the previously preloaded batch is submitted before the preloader advances to handle a new batch. For batches whose headers have some errors, no transactions are loaded to the open batch files and all the transactions are held in the native files until the batch header is corrected. As soon as this is done the transaction loading process can be continued.
Batch loading
The batch loading is a part of the transaction import process that loads transactions assigned to a batch, from the batch native files to the open batch files. All the transactions belonging to the given batch will be loaded. Contrary to the preloading process that comprises preloading of multiple batches, the loading process always loads one batch at a time. The existence of a valid batch header record is a prerequisite for the batch to be submitted for loading. If a batch header created by the preloader is in error, then the error has to be corrected before the loading process may be started. The image below displays the payment preloading process in more detail.
Flowchart
The loading process consists of the following consecutive sub-processes:
Sub-process | Description |
---|---|
Batch opening and lock | Before the batch loading process is started the batch is opened and exclusively allocated to the loader process. |
Batch header error check | If the batch is in the preloaded status the batch header is validated and if no errors are found the loading process continues. If errors are found, then the batch is interrupted and the loading process does not continue. |
All vouchers loading | All the valid native voucher records that belong to the current batch and have either of the statuses Preloaded, Header created or Partially loaded are loaded. |
All settlements loading | The payment related settlements are loaded after the related payment is created. |
Batch unlock and closing | Before the batch is submitted for update, the exclusive lock is released and the batch is closed. |
Batch update | A batch can be submitted for update only if no errors exist and the batch has reached status 3 (Loaded). |
Batch update
If no errors exist for the batch transactions and all the batch related interface data is either successfully loaded/created or set to status 4 (Deleted), then the batch is submitted for update.
Batch error correction
During import of batches from the interface, if an error occurs during validation, then the batch is not submitted for update. All the errors in a batch should be corrected before it can be successfully updated. Dedicated error codes are assigned to describe batch, voucher, cash book or payment related errors. The block diagram below provides an overview of where to go when an error is found.
Note: The terms interface voucher, interface payment or interface cash book are used to describe the set of interface data, which is to be used to create the corresponding voucher header, cash book header, or payment transaction.
Flowchart
Batch loading statuses
Automatically created batches can have different statuses which are indicated by the Status field on the Work with open batches panel. The following statuses are valid:
Status | Description | Additional information |
---|---|---|
0 | Preloaded | No batch related transactions have been created yet. The interface data assigned to the batch is not validated, but as it is preloaded to the entry panel native files, it can be viewed and maintained. |
1 | Header validated | Batch header data passed the validation, but due to errors no batch related vouchers have been created yet. |
2 | Partially loaded | Some of the interface vouchers or interface transactions did not pass the validation performed during the loading process. |
3 | Loaded | The entire batch related interface data has either been successfully loaded or set to status 4 (Deleted). |
4 | Deleted | Automatically created batches are set to status 4 (Deleted) by using the Delete option. All transactions that have already been created in the batch have been deleted while the interface transactions (data used for transaction creation) have been set to status 4. In other words, no batch transactions exist for a batch in status 4 and all the interface transactions are in status 4. A batch in status 4 can be restored using the Restore option, or cleared (delete the whole batch including the interface transactions) using the Clear option. |
Related topics
- About the Open batch environment
- About transferring payments to the Open batch environment
- Import batches from interface
- Import batches from interface using IFS communicator
- Correct the batch header of an automatically created batch
- Correct interface voucher related errors in a batch
- Correct interface transaction related errors in a batch
- Correct transaction related errors in a batch
- Correct settlement information for an A/R payment with settlement option *DOC_TYPNO
- Correct settlement information for an A/R payment with settlement option *DOC_LIST
- Correct settlement information for an interface transaction with settlement option *DOC_LIST using the “Create and stop on error” function
- Use an alternative method when correcting the settlement information for an A/R payment with settlement option *DOC_LIST
- Correct interface data related to cash book transactions in a batch
- Reload an automatically created batch
- Completely remove an incorrectly loaded batch
- Update an automatically created batch
- About DC1 Financials interface environment
- Setting up the Open batch functionality