General
The following describes the prerequisites for creating the interface environment for transferring the transactions listed below from pre-systems to Financials:
- A/R invoice documents
- A/P invoice documents
- G/L postings
- A/R payment documents
The transfer files are prepared to receive such transactions, but the manner in which they are put in the files must be defined for each pre-system.
Included sections
- The first section deals with transfer of A/R and A/P invoice documents and G/L postings.
- The second section describes the transfer of A/R payment documents in the Update A/R batch payments routine.
- The third section describes the transfer of A/R payments and their settlements in the Work with open batches routine.
- The fourth section deals with journal maintenance.
- The last section describes the fields in the transfer files.
Transfer of invoice documents and G/L postings
The interface between Financials and Distribution for transferring A/R invoice documents and G/L postings is handled through transfer groups in Distribution. The transfer groups are defined in a similar way as the routines in the Routine table in Financials. When Financials is to be integrated with other pre-systems for transferring invoice documents and/or G/L postings, the routines must be set up in the Interface type table.
An interface type can be defined for pure G/L postings from, e.g. a payroll system, or for invoice documents from an invoicing system. It is important to keep these types apart, both if they emanate from the same system and if they come from different pre-systems. An interface type can only be used either for pure G/L postings that are transferred to the G/L, or for invoice documents, with or without G/L postings, that are transferred to the A/R or A/P, with or without transfer to the G/L.
The files in which the transactions should be put before updating Financials are:
| File | Description |
|---|---|
| SROKBA | Transfer file for A/R invoice documents |
| SROLBA | Transfer file for A/P invoice documents |
| SROLBACT | Transfer file for A/P invoice documents with credit transfer payment data |
| SROLBS | Transfer file for A/P sundry suppliers |
| SROLBSCT | Transfer file for A/P sundry supplier with credit transfer payment data |
| SROLBV | Transfer file for VAT transactions belonging to A/P invoice documents |
| SROLBAL | Transfer file for A/P invoice document lines |
| SROIBT | Transfer file for G/L postings, both pure ones, and those belonging to invoice documents |
| SROECT | Transfer file for EU statistics (INTRASTAT) information connected to invoice documents |
Note: The routines for getting the information into the files must be created for each installation.
For more information about the fields in the individual files, see About the fields in the transfer files.
The parameters defined for an interface type decide which transactions should be transferred from the respective file when an interface type is selected for transfer. All invoice documents and G/L postings that fulfil the selection criteria are transferred, and no cross-reference is done between the files to check that, e.g., the income postings belonging to an invoice document is transferred from SROIBT when the invoice document is transferred from SROKBA. It is thereby VERY IMPORTANT that the records in the files have all the information necessary to make the transfer complete and correct.
The transfer to Financials is done in the Retrieve financial transactions – Interface to Financials from the General Interface file routine, where all established interface types are listed and can be selected for transfer. The following parameters for an interface type control which transactions are selected for transfer and how they should be handled:
| Parameter | Description |
|---|---|
| Interface type | The interface type selected will only transfer the G/L postings from SROIBT that have the same interface type. |
| Voucher type | The voucher type gives the voucher number(s) to the G/L postings based on the voucher number series defined for the type. The voucher type must be valid for routine GIT, if it should be used for transferring all three transaction types, or be valid for BARI if transferring A/R invoice documents only, or BAPI if transferring only A/P invoice documents. The G/L postings for the invoice documents are transferred also, but no pure G/L postings are valid. |
| Voucher break level | The voucher break level can be 1 (one voucher number for all the postings in the journal) or 2 (each transaction should have a voucher number of its own, i.e. the same as the document number). Pure G/L postings must have break level 1, but invoice documents can have both, but if break level 2 is used, summation over several invoice documents cannot be done when updating the G/L. |
| Summary code | The summary code for G/L postings before transfer to Financials, which is on a higher level than in Financials, since voucher numbers have not been given yet. Postings with the same interface type, accounting period, account combination, VAT handling code, transaction currency and quantity code will be summarised. When transferring invoice documents, the reference number is also a part of the summation standards, and there is one reference number per invoice document, so summation will normally not be done. |
| Document type | If a document type is defined, only the transactions in SROKBA or SROLBA (and SROLBACT and SROLBAL and SROLBS and SROLBSCT and SROLBV) with that document type will be transferred. If underscores (___) are used in the field, all document types are valid for the transfer. If the interface type is used for transferring pure G/L postings, the field must be blank. |
| Identity code | The identity code will only transfer the A/R or A/P transactions from SROKBA or SROLBA (and SROLBACT and SROLBAL and SROLBS and SROLBSCT and SROLBV) that have the same identity code. Identity codes FI and DI are not valid, since these are system defined codes. If the interface type is used for transferring pure G/L postings, the field must be blank. |
| System code | The system code for A/R or A/P, which is defined in the Language table, decides whether the system should transfer transaction from SROKBA or SROLBA (and SROLBAL and SROLBACT and SROLBS and SROLBSCT and SROLBV). If the interface type is used for transferring pure G/L postings, the valid system code is the code defined for G/L. |
Example:
You use a project control system that generates employee salaries and A/R invoice documents based on the number of hours that are debited. The salaries and invoice documents are to be transferred to Financials. Salaries, which are pure G/L postings, must be transferred separately from the A/R invoice documents. The salary postings only concern the G/L, while the invoice documents should update both the A/R and the G/L, whereby two interface types must be established:
| Field | Salaries | Invoice documents |
|---|---|---|
| Interface type | SAL | INV |
| Voucher type | 1.00 | 2.00 |
| Break level | 1.00 | 2.00 |
| Summary code | YES | NO |
| Document type | – | |
| Identity | IN | |
| System code | G/L | A/R |
When the actual transfer is done, a number of interface types can be selected at the same time. One journal per interface type can be created, or one journal per all A/R invoice documents, A/P invoice documents or pure G/L postings from all interface types. The accounting periods of the transactions can also be overridden with another period. This must be done if any transactions have accounting periods that are closed or too far in the future. The voucher dates may also be overridden with another date.
Transfer of A/R payments in the Update A/R batch payments routine
If the transfer of A/R payments should be handled in routine Update A/R batch payments, then the file in which the paid documents should be put before updating Financials is:
- SROKBP – transfer file for A/R payment documents
Note: The routine for getting the information into the files must be created for each installation.
On the update panel you define the parameters that decide which paid documents should be transferred, and define the values for the G/L postings:
| Parameter | Description |
|---|---|
| Accounting period | The accounting period will be the accounting period of the A/R payment documents and the G/L postings.
Note: Payment documents cannot be posted in future periods. |
| Voucher type | The voucher type gives the voucher number to the G/L postings based on the voucher number series defined for the type. One voucher number will be used for all payment documents in the journal. The voucher type must be valid for routine BARP. |
| Document type | The document type controls the numbering of the payment documents, from the document number series defined for the type. The document type also controls which liquid asset account will be used for the payment. The payment document will be booked via the contra pseudo account defined for the document type. Document-level takes precedence over voucher-level pseudo for both manual and batch run. |
| Voucher date | The voucher date will be the overall voucher date for all the G/L postings. |
| Identity code | The identity code will only transfer the transactions from SROKBP that have the same identity code. |
One journal per transfer is created, with the same accounting period, voucher type, voucher number and voucher date for all the G/L postings in the journal.
Transfer of A/R payments in the Work with open batches routine
The Work with open batches routine enables manual registration of transactions as well as import, validation and maintenance of the erroneous interface data. Currently, A/R payments, A/R Cash book payments and A/R settlement transactions are supported. Payment and settlement data for import to Financials should be loaded into the following open batch interface files:
| File | Description |
|---|---|
| SROKBPP | A/R payment interface file |
| SROKBPS | A/R settlement interface file |
| SROKBSP | A/R settlement pre-interface file/document list |
| SROKBCB | Cash book header interface file |
| SROKBVH | Voucher additional info interface file |
| SROKBSN | Sundry information interface file |
| SROKBTX | Text interface file |
The detail description of the file fields is given in the last section of the document. For further information, see also Open batch file relations.
Due to the variety of bank file layouts, the system does not provide any standard function that interprets bank data and loads the bank-related information into the Open batch interface files. However, the users, who import bank data from the IFS (Integrated File System) with the Transfer transactions from/to IFS function, have the possibility to define an IFS communicator type dedicated to handle the Open batch interface files. The IFS communicator type may define the program, which will transfer bank data from the IFS, interpret bank data, load the data into the Open batch interface files and finally run the import into Financials.
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.
Imported data may be corrected in the routine Work with open batches on the panels which are identical with the ones used for manual registration. The defaulting, validation rules and also data completion based on the applied template are common for the manual and the imported transactions creation.
Journal maintenance
Journal maintenance is used to correct journals in error. This is especially important for trouble shooting when the interface is implemented.
Example (step by step):
- An interface type for A/P invoice documents with G/L postings is selected for transfer, so the system will search for and transfer transactions from SROLBA, SROLBACT, SROLBAL, SROLBS, SROLBSCT, SROLBV and SROIBT. A journal is created in which all the transactions are put, and a journal number is retrieved from the journal number series JOU for the accounting year of the transactions.
- If the invoice journal contains errors, i.e., something is wrong with the transactions transferred from SROLBA, SROLBACT, SROLBS, SROLBSCT and SROLBV, a message will inform you that the A/P invoice journal is in error and no update will be performed. An invoice control journal will also be printed, with details for all the errors found.
- The invoice journal should then be corrected in the journal maintenance routine. When all errors have been corrected, you update the journal to the A/P again. If corrected properly, a message will then inform you that no errors were found in the A/P invoice journal and update will proceed. An invoice update journal will also be printed, with details for the updated invoice documents.
- Once the A/P is updated, the system will try to update the G/L with the G/L postings from SROIBT.
The system will also try to update the G/L with the G/L postings from SROLBAL, if the automatic A/P invoice matching routine is activated.
If the G/L journal contains errors, i.e., something is wrong with the transactions transferred from SROIBT, a message will inform you that the G/L journal is in error and no update will be performed.
- It is the same journal as for the invoice documents. Error lists will also be printed with details for all the errors found.
- You correct the G/L journal in the journal maintenance routine. When all errors have been corrected, you update the journal to the G/L again. If corrected properly, a message will inform you that no errors were found in the G/L journal and update will proceed. A forced update may also be done, and all the faulty postings will then be posted to the general error account. Forced update is only valid if there are no errors on the control account postings.