Settlement options

Related topics

What this document contains:

• Introduction
• Glossary
• Settlement option – definition
• Predefined settlement methods
• Settlement method examples
• *DOC_BRNO based methods
• *DOC_TYPNO based methods
• *DOC_LIST based methods
• Manual settlement method *MANUAL
• Predefined procedures/programs

Introduction

This document describes the parameters and procedures required to define a settlement method, as well as these methods, which are predefined and preloaded at system installation.

Glossary

Vocabulary	Description
Settlement method/Settlement option	The settlement method concept is introduced to control: The way the payment is settled, if it is settled automatically. The way the open documents are displayed on the A/R settlement workbench (FSR04501) panel, if the settlement is performed. The Settlement options table is dedicated to define settlement methods.
Automatic settlement	The term settled automatically is used to describe a settlement which is NOT made on the A/R settlement workbench panel. Currently, such an automatic settlement can be made either at manual registration of an A/R payment, if a settlement option name is entered on the A/R payment entry (FSR48301) panel, or at payment transactions import, if a settlement option number is provided in the settlement interface file. Note: The possibility to settle a payment automatically by providing the settlement option number on the Work with A/R settlements; Settlements overview (FSR09501) panel is not available yet.
Manual settlement	Manual settlement is the term used to indicate that a settlement is performed on the A/R settlement workbench (FSR04501) panel.
Settlement method’s plug-in procedures	Plug-in procedures, which should be defined for a registered settlement option, are the user-defined procedures dedicated to perform a certain phase of the settlement data processing. Note: As the settlement method is defined by setting the user-defined plug-ins, it may be considered as a plug-in itself.
Plug-in type	The procedure’s type indicates which phase of the settlement data processing a certain procedure should perform. The attached table enumerates the defined procedure types. Each type is identified by its constant name declared in the FSM04503 copybook. Plug-in type Declared constant name Declared in Data preloading ST05 FSM04503/*SRCMBR Payment defaulting ST06 FSM04503/*SRCMBR Settlement data validation ST07 FSM04503/*SRCMBR Settlement data editing program ST08 FSM04503/*SRCMBR Settlement data description creation ST09 FSM04503/*SRCMBR
Base settlement option	An existing option can be defined as the base for a new one to indicate that they belong to the same category and the procedures defined for the base option can be re-used.
Base settlement option identifiers	The available, predefined base settlement options are identified in the programs by their constant names, declared in the copybook for the corresponding Settlement data editing program: Base settlement option number Declared constant name Declared in 78 BANKREFSETPGMSOPT FSR496/ *SRCMBR 79 STDSETPGMSOPT FSR493/ *SRCMBR 82 INVLISTSOPT FSR498/ *SRCMBR 81 cManualSettlementCode FSR04501/*SRCMBR
Debtor’s overpayment	The payment amount plus the sum of paid invoice-like and payment-like documents’ remaining amounts (or indicated paid amounts of these documents) is less than zero.
Debtor’s underpayment	The payment amount plus the sum of paid invoice-like and payment-like documents’ remaining amounts (or indicated paid amounts) is greater than zero.

Settlement option – definition

The settlement options (settlement methods) are defined in the Settlement options table (SROSTOT). The table is preloaded with several pre-defined standard entries.

The settlement data (entered manually or in the interface files) is processed in several phases by calling a referenced plug-in procedure. The predefined procedures are gathered in the FSM04503 ASWFinARDocumentSettlementMethods module. The plug-in procedure names are part of the settlement option definition.

The procedures are called from the FSR483 A/R payment details program, triggered by the settlement option entered on the detail payment entry panel FSR48301, and from the settlement loader procedure (ASWBAT_Loader) at the settlement loading.

Note: The possibility to call the settlement procedures by the FSR095 program (or its replacements) from the FSR09511 panel, triggered through the settlement option code chosen for a payment, is currently not applied.

If a settlement option is added or maintained in the Settlement options table, every registered procedure is called in a testing mode to check if it is of correct plug-in type, as well as if an indicated base settlement option is properly used.

The items described in the following sub-sections should be defined for each defined settlement option.

Settlement option name (a unique entry key)

This is the unique text key for the option. It is the option name, which should be provided on the A/R payment entry panel (FSR48301) to perform the settlement.

Option number (a unique entry key)

This is a unique settlement option identifier in a two character option number format. It is used to indicate the settlement option in the settlement interface file SROKBPS.

Note: The option number is introduced to be used wherever the settlement option will need to be indicated by an option used on any “Work with” … panel. This is e.g. to allow to immediately indicate the settlement option to apply on the FSR09501 panel or similar that will be implemented in the future. Currently, the settlement option is indicated by its option number in the settlement pre-interface file SROKBPS.

To avoid option number conflicts with the options already implemented for panels an arbitrary option number range (70-99) is reserved for the settlement options. The option numbers currently used by the predefined standard options are: 78, 79, 80, 81, 82, 83, 84 and 85. Refer to the Predefined settlement methods section.

Option number text

Currently, the field value is used as information only.

Note: This is a short text that may define the settlement option description to be displayed in the “71=Bank ref settlement” format on the “Work with” … panels, where an open item settlement will be allowed in the future by direct option number selection. In the example above the text written to this field would be: “Bank ref settlement“.

Base settlement option

Entering an existing option’s name indicates that the current option belongs to the same category as the base one, and the procedures defined for the base option can be re-used.

Note: An option determines an independent category if it does not require any base option to be entered. An independent option must be created if a settlement document(s) should be identified by another set of interface file fields than the one supported by the existing methods. The new fields’ set normally requires another settlement data structure (see the Settlement data preload conversion procedure section), to be defined for the option’s plug-in procedures.

Currently, the following predefined option numbers determine the independent categories.

Note: If the base option for an option is left blank, it is handled as if this option and the base are equal.

Base option number	Base option name	Interface file fields indicating paid doc(s)	Declared constant name/Copy book
78	*DOC_BRNO	SROKBPS.STIBRN	BANKREFSETPGMSOPT /FSR496
79	*DOC_TYPNO	SROKBPS.STSDOT SROKBPS. STSIDN	STDSETPGMSOPT /FSR493
82	*DOC_LIST	SROKBSP fields	INVLISTSOPT /FSR498
81	*MANUAL	N/A	cManualSettlementCode /FSM04501

Settlement data preload conversion procedure

This is the system identifier of the procedure to be called, in order to extract the settlement data structure values, which are related to the given settlement option, from the general settlement pre-interface file format SROKBPS (or SROKBPS and SROKBSP) and to convert it into the option-dependent data structure format.

The procedure returns the target data structure written into an unformatted character variable. The settlement option number is passed to the procedure implicitly as one of the SROKBPS record field values.

The procedure is called, by the pre-loader, FSR490 program, at transaction’s import. The value it returns is saved in the NVSDAT field of the SRON045 – Settlement data native file and it is used at settlement creation.

All procedures that may be used as the Settlement data preload conversion procedure must have a common procedure interface format:

D usr_ConvertToNative… D                                  PR                          like(tsron045.NVSDTA) D pSettlPreInterfaceRec… D                                                               likeds(tsrokbps) const D pBaseSettlementOptionNo… D                                                               like(tSettlementOptionNo) const D pPluginType                            4A          const D pCheckPluginCompatibility… D                                                  N          const D pErrorDS                                               likeds(tErrorDS) D                                                                 options(*varsize:*nopass)

The meaning of the procedure parameters is the following:

Parameter	Description
pSettlPreInterfaceRec (Input; Mandatory)	The data structure defined based on the SROKBPS settlement pre-interface file record. This parameter should contain, on input, the values of the SROKBPS file record (for which the data should be returned in the settlement data native data structure) as well as the settlement option number.
pBaseSettlementOptionNo (Input; Mandatory)	It is the base settlement option number. It is passed to verify if it is valid for the current procedure.
pPluginType (Input; Mandatory)	It is passed to validate if the procedure is assigned to the correct type (data conversion type) of plug-in procedures.
pCheckPluginCompatibility (Input; Mandatory)	Setting the pCheckPluginCompatibility parameter *ON determines that the procedure should be called in the testing mode in order to check if the procedure is defined with the correct plug-in type (valid for Data preloading), and if an indicated Base settlement option is valid for the procedure. The validation if the correct plug-in type is defined is performed by comparing with the declared constant name assigned to the specific type of procedure/plug-in/. The following constant names are assigned: Plug-in type Declared constant name Defined in Data preloading ST05 FSM04503/*SRCMBR Payment defaulting ST06 FSM04503/*SRCMBR Settlement data validation ST07 FSM04503/*SRCMBR Settlement data editing program ST08 FSM04503/*SRCMBR Settlement data description creation ST09 FSM04503/*SRCMBR
pErrorDS (Output; Optional)	This is a data structure that returns error condition information allowing to identify the error, or warning conditions, encountered by the validation.

Payment data defaulting procedure

This is the system identifier of the procedure to be called to find a document that should be paid by a document to be created, and to default entry values for the document to be created based on the transaction found.

This procedure is executed if the Init from existing field is set to YES for the template applied for payment’s entry (at manual registration, or at import).

A default field value returned by the procedure will not be applied if the corresponding payment field is not blank, and also in case the field’s Initialization code is set to NI (No init) for the applied template.

All procedures that may be used as the Payment defaulting procedure must have a common procedure interface format.

D usr_DefaultPaymentInfo… D                            PR                            like(tsrodta.DTREFX) D pSettlementOptionNo… D                                                           like(tSettlementOptionNo) const D pBaseSettlementOptionNo… D                                                            like(tSettlementOptionNo) const D pPluginType                                4A    const D pCheckPluginCompatibility… D                                                     N     const D pSettlementDataBuffer… D                                                             like(tsron045.NVSDTA) const D                                                               options(*varsize) D pPaymentDS                                       likeds(tPaymentDS) D                                                               options(*varsize) D pRaiseExceptions… D                                                     N      const options(*nopass) D pErrorDS                                              likeds(tErrorDS) D                                                               options(*varsize:*nopass)

The meaning of the procedure parameters is the following:

Parameter	Description
pSettlementOptionNo (Input; Mandatory)	The currently processed settlement option number will be passed by this value; it is to control whether the proper procedure was called for the option (i.e. whether the called procedure really supports this option).
pSettlementDataBuffer (Input; Mandatory)	This is a buffer variable containing the settlement data structure, the format of which is dependent on the settlement option processed. The structure of the SettlementInfo data structure should be common for all the procedures and programs that process the same settlement option and should be defined in copybook members copied to all the sources that contain definitions of those procedures and programs.
pPaymentDS (Input/Output; Mandatory)	This is a data structure, which contains all the payment document values entered and edited on the FSR48301 panel.
pPluginType	It is passed to validate if the procedure is assigned to the correct type (Payment defaulting type) of plug-in procedures.
pCheckPluginCompatibility (Input; Mandatory)	The procedure can be called in the testing mode. It is done by setting *ON the pCheckPluginCompatibility parameter. The check is performed if the procedure is defined with the correct plug-in type (Payment defaulting type), and if the indicated Base settlement option is valid for the procedure. The validation if the correct plug-in type is defined is performed by comparing with the declared constant name assigned to the specific type of procedure/plug-in/. The following constant names are assigned: Plug-in type Declared constant name Defined in Data preloading ST05 FSM04503/*SRCMBR Payment defaulting ST06 FSM04503/*SRCMBR Settlement data validation ST07 FSM04503/*SRCMBR Settlement data editing program ST08 FSM04503/*SRCMBR Settlement data description creation ST09 FSM04503/*SRCMBR
pBaseSettlementOptionNo	It is the base settlement option number. It is passed to verify if it is valid for the current procedure.
pRaiseException (Input; Optional)	It is the parameter that should be set *ON if the procedure sends warnings and errors to the Exception Manager.
pErrorDS (Output; Optional)	This is a data structure that will return error condition info allowing to identify the error, or warning conditions encountered at the procedure processing.

The procedure tries to find a unique A/R document (usually an invoice) that matches the data passed through the pSettlementDataBuffer (e.g. the searched invoice document type and document no, its order no or similar) and the PaymentDS parameters.

If a document is found its reference number will be returned and the found document will be used to initialize the output PaymentDS values that might be used either for the FSR48301 panel initialization, or for completing the payment interface data.

If a document is not found, but the passed data allows making an unambiguous initialization of the PaymentDS values, then the latter will be initialized on output, even though the reference number returned will be zero.

If neither of the cases described above occurs the PaymentDS values will remain unchanged on output.

Only empty on input (i.e. blank or zero, depending on the field format) PaymentDS fields are defaulted.

Settlement data validation procedure

This is the system identifier of the procedure that validates the data that is to be passed to the Settlement description creation procedure. This procedure is called either by the related Settlement data editing program to validate the values entered in the plug-in program window or by the settlement loader to validate the settlement data retrieved from the SRON045 – Settlement data native file.

All procedures that may be used as the Settlement data validation procedure must have a common procedure interface format.

D usr_ValidateSettlementInfo… D                               PR                  9B 0 D pSettlementOptionNo… D                                                                   like(tSettlementOptionNo) const D pBaseSettlementOptionNo… D                                                                   like(tSettlementOptionNo) const D pPluginType                                 4A         const D pCheckPluginCompatibility… D                                                       N         const D pSettlementDataBuffer… D                                                                   like(tsron045.NVSDTA) D                                                                     options(*varsize) D pPaymentDS… D                                                                   likeds(tPaymentDS) const D                                                                     options(*varsize:*omit) D pValidatePayment D                                                       N            options(*nopass) const D pErrorDS                                                    likeds(tErrorDS) D                                                                     options(*varsize:*nopass)

The meaning of the procedure parameters is the following:

Parameter	Description
pSettlementOptionNo (Input; Mandatory)	The currently processed settlement option number should be passed by this value; it is to control whether the proper procedure was called for the option (i.e. whether the called procedure really supports this option).
pBaseSettlementOptionNo	It is the base settlement option number. It is passed to verify if it is valid for the current procedure.
pPluginType	It is passed to validate if the procedure is assigned to the correct type (Settlement data validation) of plug-in procedures.
pCheckPluginCompatibility (Input; Mandatory)	The procedure can be called in the testing mode. It is done by setting *ON the pCheckPluginCompatibility parameter. The check is performed if the procedure is defined with the correct Settlement data validation plug-in type, and if the indicated Base settlement option is valid for the procedure. Plug-in type Declared constant name Defined in Data preloading ST05 FSM04503/*SRCMBR Payment defaulting ST06 FSM04503/*SRCMBR Settlement data validation ST07 FSM04503/*SRCMBR Settlement data editing program ST08 FSM04503/*SRCMBR Settlement data description creation ST09 FSM04503/*SRCMBR
pSettlementInfoBuffer (Input/Output; Mandatory)	This is a buffer variable containing the settlement data structure, the format of which is dependent on the settlement option processed. The structure of the SettlementInfo data structure should be common for all the procedures and programs that process the same settlement option and should be defined in a copybook members copied to all the sources that contain definitions of those procedures and programs. The procedure may perform some editing adjustments for the entered values (like trimming, upper-folding, aligning, defaulting etc.) and return the finally adjusted values on Output.
pPaymentDS (Input; Optional)	This is a data structure, which contains all the payment document values entered and edited on the FSR48301 panel. This parameter may be omitted, if it is called to validate the settlement data entered for a payment still residing only in the payment native file. Such special validation method is not implemented, which means that no validation of settlement data is performed for the non-created payment.
pValidatePayment (Input; Optional)	This is an *on/*off switch allowing to turn off validation of payment related data.
ErrorDS (Output; Optional)	This is a data structure that will return error condition information allowing to identify the error or warning conditions encountered at the procedure processing.

Settlement data editing program

This is the name of the program that is called to interactively enter/edit an extra settlement information, that in addition to the payment data entered on the payment entry panel, may be used by both the Payment data defaulting procedure, to find the document to settle and to initialize some of the payment data, and by the Settlement description creation procedure to create the settlement description for the payment document.

If the settlement data is preloaded for a payment from the interface then the program is called to edit and update the data stored in the SRON045 settlement native file.

If the settlement data is not available for a payment in the native file the program is called to enter these data, if requested, independent of whether the payment is imported from the interface or entered manually. In both cases the entered data is stored in the SRON045N – settlement native file record.

Settlement description creation procedure

This is the system identifier of the procedure to be called to create the settlement definition in the settlement description files:

• SROKBSH – A/R settlement interface file – settlement header
• SROKBSD – A/R settlement input file – settled documents

If the Settlement description creation procedure field is *blank for a given settlement option, then the Settlement description creation procedure is not called for the option and the settlement can either be directly defined by description (the SROKBSH and SROKBSD are loaded directly from an external system) or the A/R settlement workbench panel can be opened for the settlement to be entered manually. In this case the Payment defaulting procedure, Settlement data validation procedure, Settlement data editing program are not mandatory for the settlement option.

All procedures that may be used as the Settlement description creation procedure must have a common procedure interface format:

D usr_CreateSettlementDescription… D                               PR                       9B 0 D pBatchNo                                                     like(tsron045.NVBANO) const D pExtNoSer                                                   like(tsron045.NVERNS) const D pExtRefNo                                                   like(tsron045.NVERFS) const D pSettlementOptionNo… D                                                                     like(tSettlementOptionNo) const D pBaseSettlementOptionNo… D                                                                     like(tSettlementOptionNo) const D pPluginType                                       4A     const D pCheckPluginCompatibility… D                                                            N       const D pSettlementDataBuffer… D                                                                     like(tsron045.NVSDTA) const D                                                                        options(*varsize) D pPaymentDS… D                                                                     likeds(tPaymentDS) const D                                                                        options(*varsize) D pErrorDS                                                      likeds(tErrorDS) D                                                                        options(*varsize:*nopass)

The meaning of the procedure parameters is the following:

Parameter	Description
pBatchNo (Input; Mandatory)	The currently processed batch number is passed by this value; this number will be written to the created settlement description records in the SROKBSH and SROKBSD files.
pExtNoSer (Input; Mandatory)	The processed settlement external number series code is passed by this value; this code is written to the created settlement description records in the SROKBSH and SROKBSD files.
pSettlementOption (Input; Mandatory)	The currently processed settlement option number is passed by this value; it is to control whether the proper procedure was called for the option (i.e. whether the called procedure really supports this option).
pBaseSettlementOptionNo	It is the base settlement option number. It is passed to verify if it is valid for the current procedure.
pPluginType	It is passed to validate if the procedure is assigned to the correct type (Settlement data description creation type) of plug-in procedures.
pCheckPluginCompatibility	Setting the pCheckPluginCompatibility parameter *ON determines that the procedure should be called in the testing mode in order to check if the procedure is defined with the correct plug-in type (valid for Data preloading), and if an indicated Base settlement option is valid for the procedure. The validation if the correct plug-in type is defined is performed by comparing with the declared constant name assigned to the specific type of procedure/plug-in/. The following constant names are assigned. Plug-in type Declared constant name Defined in Data preloading ST05 FSM04503/*SRCMBR Payment defaulting ST06 FSM04503/*SRCMBR Settlement data validation ST07 FSM04503/*SRCMBR Settlement data editing program ST08 FSM04503/*SRCMBR Settlement data description creation ST09 FSM04503/*SRCMBR
pSettlementDataBuffer (Input; Mandatory)	This is a buffer variable containing the settlement data structure, the format of which is dependent on the settlement option processed. The structure of the SettlementInfo data structure should be common for all the procedures and programs that process the same settlement option and should be defined in a copybook members copied to all the sources that contain definitions of those procedures and programs.
pPaymentDS (Input; Mandatory)	This is a data structure, which contains all the payment document values entered and edited on the FSR48301 panel.
pErrorDS (Output; Optional)	This is a data structure, that will return error condition information allowing to identify the error or warning conditions encountered at the procedure processing. The procedure returns: (all constants are defined in the ICCON member; DC1 constants member): DC1_ERROR (-1) – if any errors have been encountered and the settlement description has not been created. DC1_SUCCESS (0) – otherwise. Note: It should be checked if warning handling will not require that also DC1_WARNING (-2) is returned if any warning conditions have been encountered while no error conditions were stated. Each error stated causes an DC1Job exception rising. The type of error is indicated through the UserKey value. All the exceptions raised by the procedure are retrieved and handled by the caller, if needed.

Open item selection option

This is a name of the Open item selection option defined in the Open item selection options table, which is used as the initial option for the A/R settlement workbench program, if this program is started to create a settlement according to the chosen settlement option. The initial selection option can be overridden by another selection option at the settlement workbench program run time.

Note: Contrary to the settlement option that is stored for the payment, the last used open item selection option is not stored for the settlement.

Settlement workbench display flag

This is a Y/N flag that, if set to YES, causes the Settlement workbench to be displayed with the settlement created, even if the settlement completion status was OK.

This flag overrides all the other flags that control the Settlement workbench panel display, such as the flag set in the Document type table or similar.

Settlement auto-balance method

This code determines in which way an automatically created settlement that does not balance should be balanced.

For the predefined, standard settlement options either code 01 can be entered or the field can be left blank. If the payment amount is greater than the amount of the document(s) to be paid, and this field is left blank, then the remaining amount of the payment will be put on account.

Code 01 will switch off the setting on account function and the overpaid settlement will be identified as erroneous.

Predefined settlement methods

The following settlement options are predefined and preloaded at system installation. The preloaded values are described in the corresponding sub-sections.

Option number	Option name	Base option number/name	Description
78	*DOC_BRNO		Bank reference no based settlement
79	*DOC_TYPNO		Standard settlement
80	*DOC_MLTEX	79 *DOC_TYPNO	Standard with multiple EXR docs
81	*MANUAL		Manual settlement
82	*DOC_LIST		Document list settlement
83	*DOC_LISTE	82 *DOC_LIST	Document list settlement with editor
84	*DOC_LIST3	82 *DOC_LIST	Document list – fully settle
85	*DOC_LISTM	82 *DOC_LIST	Document list – Omit not matched

Note: If the base option for an option is left blank, it is handled as if this option and the base are equal.

Settlement method examples

Any existing procedure valid for a base option can basically be used for any other option defined with the same base. Of course, not every possible combination of the available plug-in procedures is predefined and preloaded as the standard system SROSTOT record. To illustrate how a customized method can be constructed the below options are defined as an example of a settlement method.

Example’s Option number	Example’s Option name	Example’s Base option number/name	Example’s Description
86	*DOC_LSTM3	82 *DOC_LIST	OmitNotMatchedSettlefully
87	*DOC_LST30	82 *DOC_LIST	OmitNotMatchedCancelIfBalanced

*DOC_BRNO based methods

Only the *DOC_BRNO option is pre-defined for this category.

*DOC_BRNO

1. Overview

The method may be used at manual registration as well as at transactions import. It is dedicated to settle a payment with a single document uniquely identified by its bank reference number updated in the field DTBRNO of the SRODTAI file.

This method is a plug-in implementation of the one-to-one settlement performed at transactions transfer from the SROKBP file (from the interface file used at import made from the routine Update A/R batch payments) and it basically follows the rules applied there.

If a document is not uniquely identified by the given reference, then the first found document is settled. Only at manual entry is the user informed about the reference not being unique by a warning message shown on the registration panel.

If an indicated document is found, but has another currency or another debtor than the payment, then it is considered as not found (the validation disables multi-debtor and multi-currency settlements).

At settlement creation the document settlement option 1 (Settle) is used. If a document is underpaid, then it will be partially settled and at manual entry a warning message will be sent.

If a document is underpaid, but the missing amount can be covered by the calculated granted hidden discount amount, then the Hidden discount document is created, as it is the standard rule for the Document settlement option 1 (Settle).

The procedures: usr_BankRefPaymentDataDefault, usr_BankRefSettlmntDataValidate and usr_BankRefSettlmntDescCreate perform the identical search process to find the indicated settlement document. It is to ensure that the document used for defaulting is the one which is validated and paid.

2. Pre-defined setup

The preloaded set-up of the *DOC_BRNO settlement option is the following:

Field name/Description	Value
Settlement option SROSTOT.STSETO	*DOC_BRNO
Base settlement option SROSTOT.STBSTO
Option number SROSTOT.STSOPT	78
Settlement option number description SROSTOT. STSTDS	Bank reference no based settl
Data preloading conversion procedure SROSTOT. STSDPC	usr_BankRefSettlmntDataPrelConv
Payment defaulting procedure SROSTOT.STPADP	usr_BankRefPaymentDataDefault
Data validation procedure SROSTOT.STSDVP	usr_BankRefSettlmntDataValidate
Settlement data editing program SROSTOT.STSDEP	FSR496
Description creation procedure SROSTOT.STSDCP	usr_BankRefSettlmntDescCreate
Selection option SROSTOT.STSELO	*STDSELCTN
Workbench display SROSTOT.STSWDS	N
Auto-balance method SROSTOT.STSABM	01
Exch rate on doc level SROSTOT.STEROD	N

3. Settlement data editing program

The program FSR496 serves the FSR49601 Bank reference no. based settlement info entry panel. One input field: Bank reference number is provided to indicate the settlement document. The FSR483 – A/R payment details program calls FSR496 to

• Enable maintenance of the bank reference number incorrectly loaded into SROKBPS and stopped in the native files SRON045.
• Enable bank reference number registration, if the registered payment should be manually settled with the *DOC_BRNO option.
• Enable bank reference number registration, if the payment data for the payment, which is being created, should be retrieved from the indicated document.
• Show the bank reference number of this document, which has already been settled with the created payment.
• Retrieve and display all the messages received from exception manager.

Note: FSR496 does not perform any validation. The validation procedure usr_BankRefSettlmntDataValidate is called either by FSR483, at manual registration, or at loading process by the loading procedure (ASWBAT_Loader, which in turn calls ASWFARSetLoader).

4. Settlement info data structure

The dedicated settlement data structure is declared in the FSR496 copy book.

D * Bank (invoice) reference number based settlement info declaration D tBankRefSettlementInfo… D                    DS               QUALIFIED D bankRefNo                      LIKE(tsrodtai.DTBRNO)

Where tsrodtai defines a template for the SRODTAI record.

D tsrodtai     E DS              EXTNAME(SRODTAI) D                                        BASED(t_Dummy_) D                                        QUALIFIED

5. usr_BankRefSettlmntDataPrelConv

The procedure extracts the bank reference number from the interface record format SROKBPS and converts it into the option-dependent Settlement info data structure format. The returned data structure is written into the SRON045.NVSDTA field value of the Settlement data native file SRON045N.

6. usr_BankRefPaymentDataDefault

The procedure tries to find the indicated document. If a unique record is found in SRODTA then its reference number (SRODTA.DTREFX) is returned together with the following field values, to be defaulted for the created payment:

• Debtor number
• Document date
• Transaction amount
• Transaction currency
• Text
• Exchange rate period, Exchange rate level, only if the Document date was defaulted, as well
• Cost centre

If more than one matching record is found then *zero is returned and these enumerated field values above, which are common for the found documents, are returned to be defaulted for the created payment.

7. usr_BankRefSettlmntDataValidate

The procedure is called either by the FSR483 A/R payment details program or by the loading procedure (ASWBAT_Loader, which calls in turn ASWFARSetLoader, to validate and load settlement) before the settlement data is passed for settlement creation to the usr_BankRefSettlmntDescCreate procedure.

The procedure performs the standard validation of the registered value (the field must not be blank and, if entered, must pass the validation made by GCFR006 program). If the field validation is passed, the procedure tries to find the corresponding document in SRODTA and continues validation for the found document, i.e. tests if the document is open, if it is not allocated in the payment proposal etc. This validation procedure disables multi-currency settlements and cross-debtor settlements, as the documents with another currency or another debtor are considered as not found.

8. usr_BankRefSettlmntDescCreate

The procedure creates the payment related records in SROKBSH and SROKBSD, based on the passed data structure pPaymentDS. The paid document’s related record in SROKBSD is created based on the values passed in pSettlementDataBuffer.

Note: A search for the paid document performed by this procedure matches the one done by the usr_BankRefSettlmntDataValidate and usr_BankRefPaymentDataDefault procedures.

*DOC_TYPNO based methods

There are two pre-defined settlement options belonging to the category: *DOC_TYPNO and*DOC_MLTEX. The only difference is that the value of the parameter Exchange rate on document level. This value decides if the exchange rate should be created for the paid document (as a difference document on document level) or for the whole settlement (as a difference on settlement level).

Settlement option	Exchange rate on doc level
*DOC_MLTEX	YES
*DOC_TYPNO	NO

*DOC_TYPNO

1. Overview

The method may be used at manual registration as well as at transactions import. It is dedicated to settle a payment with a single document uniquely indicated by its document type and document number (updated as the SRODTA. DTDOTY SRODTA.DTIDNO field values).

This method is a plug-in implementation of the one-to-one settlement performed at transactions transfer from the SROKBP file (from the interface file used at import made from the routine Update A/R batch payments) and the one-to-one settlement performed at manual registration on the FSR04004 A/R payment entry panel, accessed from the Enter financial transactions routine.

If a document is not uniquely identified by the given reference, then the first found document is settled. Only at manual entry is a warning message sent to inform the user about the reference not being unique.

If an indicated document is found, but has another currency or another Debtor than the payment, then it is considered as not found (the validation disables multi-debtor and multi-currency settlements).

At settlement creation the Document settlement option 1 (Settle) is used.

If a document is underpaid, then it will be partially settled. At manual entry a warning message is sent.

If a document is underpaid, but the missing amount can be covered by the calculated, granted hidden discount amount, then the Hidden discount document is created, as it is the standard rule for the Document settlement option 1 (Settle).

The procedures usr_StdPaymentDataDefault, usr_StdSettlmntDataValidate and usr_StdSettlmntDescCreate perform the identical search process to find the indicated document. It is to ensure that the document used for defaulting is the one which is validated and paid.

2. Predefined set-up

The preloaded set-up of the *DOC_TYPNO settlement option is the following:

Field name/Description	Value
Settlement option SROSTOT.STSETO	*DOC_TYPNO
Base settlement option SROSTOT.STBSTO
Option number SROSTOT.STSOPT	79
Settlement option number description SROSTOT. STSTDS	Standard settlement
Data preloading conversion procedure SROSTOT. STSDPC	usr_StdSettlmntDataPrelConv
Payment defaulting procedure SROSTOT.STPADP	usr_StdPaymentDataDefault
Data validation procedure SROSTOT.STSDVP	usr_StdSettlmntDataValidate
Settlement data editing program SROSTOT.STSDEP	FSR493
Description creation procedure SROSTOT.STSDCP	usr_StdSettlmntDescCreate
Selection option SROSTOT.STSELO	*STDSELCTN
Workbench display SROSTOT.STSWDS	N
Auto-balance method SROSTOT.STSABM	01
Exch rate on doc level SROSTOT.STEROD	N

3. Settlement data editing program

The FSR49301 Standard settlement info entry two input fields: Document type and Document number.

The program FSR493 serves the FSR49301 Standard settlement info entry panel. Two input fields: Document type and Document number are provided to indicate the settlement document. The FSR483 – A/R payment details program calls FSR493 to:

• Enable maintenance of the bank reference number incorrectly loaded into SROKBPS and stopped in the native files SRON045.
• Enable Document type and Document number registration, if the registered payment should be manually settled with the *DOC_TYPNO option.
• Enable Document type and Document number registration, if the payment data for the payment, which is being created, should be retrieved from the indicated document.
• Show the Document type and Document number of this document, which has already been settled with the created payment.
• Retrieve and display all the messages received from exception manager.

Note: FSR493 does not perform itself any validation. The validation procedure usr_StdSettlmntDataValidate is called either by FSR483, at manual registration, or at loading process by the loading procedure (ASWBAT_Loader, which calls in turn ASWFARSetLoader).

4. Settlement info data structure

The dedicated settlement data structure is declared in the FSR493 copybook:

* Standard settlement info declaration D tStdSettlementInfo… D                    DS               QUALIFIED D docType                          LIKE(tsrodta.DTDOTY) D docNumber                      LIKE(tsrodta.DTIDNO)

Where the tsrodta defines a template for SRODTA record:

* D tsrodta       E DS              EXTNAME(SRODTA) D                                         BASED(t_Dummy_) D                                         QUALIFIED

5. usr_StdSettlmntDataPrelConv

The procedure extracts the settlement option number as well as the document type and number from the interface record format SROKBPS and converts it into the option-dependent Settlement info data structure format. The returned data structure is written into the SRON045.NVSDTA field value of the Settlement data native file SRON045N.

6. usr_StdPaymentDataDefault

The procedure tries to find the indicated document. If a unique record is found in SRODTA, then its reference number is returned together with the following field values, to be defaulted for the created payment:

• Debtor number
• Document date
• Transaction amount
• Transaction currency
• Text
• Exchange rate period, Exchange rate level, only if the Document date was defaulted as well.
• Cost centre

If more than one matching record is found then *zero is returned as the reference number. The enumerated field values above, if they are common for the found documents, will be returned to be defaulted for the created payment.

7. usr_StdSettlmntDataValidate

The procedure is called either by the FSR483 A/R payment details program or by the loading procedure (ASWBAT_Loader, which in turn calls ASWFARSetLoader, to validate and load settlement) before the settlement data is passed for settlement creation to the usr_BankRefSettlmntDescCreate procedure.

The procedure performs the standard validation of the registered values. If it is passed, it tries to find the corresponding document in SRODTA, and continues the validation for the found document (i.e. tests if the document is open, if it is not allocated in the payment proposal etc.). This validation procedure disables multi-currency settlements and cross-debtor settlements, as the documents with another currency or another debtor are considered as not found.

8. usr_StdSettlmntDescCreate

The procedure creates the payment related records in SROKBSH and SROKBSD, based on the passed data structure pPaymentDS. The paid document’s related record in SROKBSD is created based on the values passed in pSettlementDataBuffer.

Note: A search for the paid document performed by this procedure matches the one done by the usr_StdPaymentDataDefault and usr_StdSettlmntDataValidate procedures.

*DOC_MLTEX

1. Overview

Refer to the Overview for the *DOC_TYPNO settlement option. The difference between the options is the value for the parameter Exchange rate on document level, which decides if the exchange rate should be created for the paid document (as a difference document on document level) or for the whole settlement (as a difference on settlement level).

Settlement option	Exchange rate on doc level
*DOC_MLTEX	YES
*DOC_TYPNO	NO

2. Predefined set-up

The preloaded set-up of the *DOC_MLTEX differs from the *DOC_TYPNO with one field value only. It is the Exchange rate on document level field value, which for this option is set to YES to create a separate exchange rate for each settled document.

Field name/Description	Value
Settlement option SROSTOT.STSETO	*DOC_MLTX
Base settlement option SROSTOT.STBSTO	*DOC_TYPNO
Option number SROSTOT.STSOPT	80
Settlement option number description SROSTOT. STSTDS	Standard with multiple EXR docs
Data preloading conversion procedure SROSTOT. STSDPC	usr_StdSettlmntDataPrelConv
Payment defaulting procedure SROSTOT.STPADP	usr_StdPaymentDataDefault
Data validation procedure SROSTOT.STSDVP	usr_StdSettlmntDataValidate
Settlement data editing program SROSTOT.STSDEP	FSR493
Description creation procedure SROSTOT.STSDCP	usr_StdSettlmntDescCreate
Selection option SROSTOT.STSELO	*STDSELCTN
Workbench display SROSTOT.STSWDS	N
Auto-balance method SROSTOT.STSABM	01
Exch rate on doc level SROSTOT.STEROD	Y

3. Settlement data editing program

Refer to the section Settlement data editing program for *DOC_TYPNO.

4. Settlement info data structure

Refer to the section Settlement info data structure for *DOC_TYPNO.

5. usr_StdSettlmntDataPrelConv

Refer to the section usr_StdSettlmntDataPrelConv for *DOC_TYPNO.

6. usr_StdPaymentDataDefault

Refer to the section usr_StdPaymentDataDefault for *DOC_TYPNO.

7. usr_StdSettlmntDataValidate

Refer to the section usr_StdSettlmntDataValidate for *DOC_TYPNO.

8. usr_StdSettlmntDescCreate

Refer to the section usr_StdSettlmntDescCreate for *DOC_TYPNO.

*DOC_LIST based methods

There are several pre-defined settlement options belonging to the category. They require that the same settlement interface files are loaded. One common settlement info data structure, to be used by the options plug-in procedures, is declared for the methods.

1. Settlement data interface files

For options based on the *DOC_LIST, the settlement data should be loaded into the following files:

• SROKBPS (A/R settlement interface file)
• SROKBSP (A/R settlement pre-interface file; documents list)

The link between the files is the following:

• External reference number series, SROKBPS.STERNS
• External reference number, SROKBPS.STERFS
2. Settlement info data structure

The settlement data structure, common for the plug-in procedures defined for a method based on *DOC_LIST, is declared in the FSR498 copybook as follows:

Invoice list based settlement info declaration

D tInvListSettlementInfo… D                     DS               QUALIFIED D extNoSer                        LIKE(tsrokbsd.STERNS) D extRefNo                        LIKE(tsrokbsd.STERFS)

Where the tsrokbsd defines a template for the SROKBSD record.

D tsrokbsd       E DS            EXTNAME(SROKBSD) D                                         BASED(t_Dummy_) D                                         QUALIFIED

The settlement data extracted by the Settlement data preloading conversion procedure and written to the SRON045.NVSDTA are:

• External reference number series, SROKBPS.STERNS field value,
• External reference number, SROKBPS.STERFS field value,

The linked records (paid documents) loaded into the SROKBSP (A/R Settlement pre-interface file; documents list) file are not processed through a dedicated settlement data structure. They are directly copied by the preloading procedure to the dedicated data base file – SROKBSL – which is a mirror file for SROKBSP.

*DOC_LIST

1. Overview

The *DOC_LIST settlement option is dedicated to import rather than to manually register payments and their settlements. This option should be chosen if an imported payment is to be settled with a provided list of documents.

The fields available in the settlement interface file to identify the paid documents are:

• document type and document number
• document number
• bank reference number
• document reference number

Either document number, or document type and number, or bank reference number, or document reference number should be loaded. If more than one reference is provided then the document found must match all the given references. Otherwise the error code is assigned and the settlement will not be created (will remain in the settlement native files SRON045N and SROKBSL).

The method can be used if the provided payment and settlement information is incomplete and the system should complete not only the missing payment information (the payment’s debtor), but also determine the settlement sequence and the document settlement option.

For this option the erroneous settlement data is to be corrected on the FSR04517; A/R settlement workbench; Interface import/error correction panel, which is accessible directly from the standard, manual registration panel – A/R settlement workbench panel.

If a payment, imported with the *DOC_LIST option, is successfully updated in SRODTA file, then its settlement is always created – with or without errors – and in turn, it is available for corrections from the A/R settlement workbench panel.

The Settlement data validation procedure is not defined for the option. Therefore the corresponding Settlement data editing program is not required for settlement data corrections and could be left blank. However, it is defined for the option to enable viewing settlement data directly from the detail entry panel FSR48301. Viewing possibility may be required if an imported payment is not created in the transaction file SRODTA due to encountered errors, and the A/R settlement workbench panel cannot be accessed yet. In that case, the interface settlement data can be shown on the defined FSR49801 panel directly from the A/R payment detail entry panel FSR48301.

Note: Both cross-debtor and multi-currency settlements are created for this method (the defaulting and validation procedures do not disable them).

2. Predefined set-up

The preloaded set-up of the *DOC_LIST settlement option is the following:

Field name/Description	Value
Settlement option SROSTOT.STSETO	*DOC_LIST
Base settlement option SROSTOT.STBSTO
Option number SROSTOT.STSOPT	82
Settlement option number description SROSTOT. STSTDS	Document list settlement
Data preloading conversion procedure SROSTOT. STSDPC	usr_InvListSettlmntDataPrelConv
Payment defaulting procedure SROSTOT.STPADP	usr_InvListPaymentDataDefault
Data validation procedure SROSTOT.STSDVP
Settlement data editing program SROSTOT.STSDEP	FSR498
Description creation procedure SROSTOT.STSDCP	usr_InvListSettlmntDescCreate
Selection option SROSTOT.STSELO	*STDSELCTN
Workbench display SROSTOT.STSWDS	N
Auto-balance method SROSTOT.STSABM	01
Exch rate on doc level SROSTOT.STEROD	N

3. Settlement data interface files

For options based on the *DOC_LIST, the settlement data should be loaded into the following files:

• SROKBPS (A/R settlement interface file)
• SROKBSP (A/R Settlement pre-interface file; documents list)

The link between the files is the following:

• External reference number series, SROKBPS.STERNS
• External reference number, SROKBPS.STERFS
4. Settlement data editing program

For this option the settlement data editing program is exceptionally handled. As the erroneous settlement data should be maintained from the FSR04517 accessed directly from the manual registration panel, A/R settlement workbench FSR04501 panel, the FSR498 program defined for this method is used only in order to enable viewing of the settlement data. Viewing possibility may be required if an imported payment is not created in SRODTA file due to encountered errors, and the A/R settlement work bench panel cannot be accessed. In that case, the interface settlement data can be shown on the defined FSR49801 panel directly from the detail entry panel FSR48301. FSR498 is called in the enquiry mode.

5. Settlement info data structure

The settlement data structure, common for the plug-in procedures defined for a method based on *DOC_LIST, is declared in the FSR498 copybook as follows:

Invoice list based settlement info declaration

D tInvListSettlementInfo D                     DS                   QUALIFIED D extNoSer                            LIKE(tsrokbsd.STERNS) D extRefNo                            LIKE(tsrokbsd.STERFS)

The settlement data extracted by the Settlement data preloading conversion procedure and written to the SRON045.NVSDTA are:

• External reference number series, SROKBPS.STERNS field value
• External reference number, SROKBPS.STERFS field value

Note: The linked records (paid documents) loaded into the SROKBSP (A/R Settlement pre-interface file; documents list) file are not processed through a dedicated settlement data structure. They will be copied directly from SROKBSP into the dedicated data base file – SROKBSL – which is a mirror file of SROKBSP.

6. usr_InvListSettlmntDataPrelConv

The procedure extracts the settlement option number as well as the document type and number from the interface record format SROKBPS and converts it into the option-dependent Settlement info data structure format.

Additionally, the procedure copies the records from the SROKBSP interface file to the dedicated data base mirror file <-> SROKBSL.

For this option the SROKBSL together with the SRON045 should be considered as the settlement data native files.

7. usr_InvListPaymentDataDefault

The defaulting procedure is run only if the parameter Init from existing is set to YES for the applied template.

The defaulting procedure reads the native file SROKBSL (which is the mirror file of the Settlement interface file SROKBSP) in the SR1KBSL sequence, and searches SRODTA to find the indicated document and to retrieve some payment values from the found document. When this process is completed the procedure assigns also the settlement sequence, if it is not provided in the interface file.

The following field values are returned by this procedure in the parameter pPaymentDS to be used as the default values for the imported payment:

• Debtor number.
  The value is retrieved from the SRODTA record indicated by the first SR1KBSL record, for which the corresponding SRODTA record exists.

  Note: If the reference is not unique, then the first found document is considered.

• Transaction amount.
  The calculated value is the sum of remaining amounts of all the documents indicated by the SROKBSL records and found in SRODTA. The sum is returned only if all the indicated documents found in SRODTA have the same transaction currency as the payment document.
• Transaction currency.
  The value is retrieved from the first found SRODTA record indicated by the SR1KBSL record. The value is returned as the default currency if all the documents indicated in SR1KBSL and found in SRODTA are updated with this transaction currency (SRODTA.DTTCUR).

The default field values returned by this procedure will be used for the imported payment only if the following conditions are fulfilled:

• The interface file field value is blank.
• The constant field value is not defined for the template, which was indicated at transfer.
• The initialization code of the field is NOT set to NI (No init) for the template, which was indicated at transfer.

If an indicated document is found in SRODTA, then its reference number is updated in the SROKBSL record as the SROKBSL.SLREFX field value. It is done to assure that the document used by the Payment defaulting procedure is the one that will be settled by the Settlement description creation procedure. This process can be considered as the defaulting process of the Reference number field value.

The defaulting procedure also sets the settlement sequence (SROKBSL. SLSTSQ) field value, if it is not provided in the interface file. The settlement sequence is assigned according to the remaining amount of the found SRODTA documents. The rule is that the Payment-like documents (credit notes) are sequenced to be settled before Invoice-like documents (invoices).

Document	Assigned settlement sequence; SLSTSQ
Indicated documents not found in SRODTA	0
Credit notes (Payment-like documents)	1
Invoices (Invoice-like documents)	2

If the Payment-like documents are settled at first, then in the case of underpayment, the document which will be settled as the last one will be either settled partially, or the Hidden discount document will be created and it will be fully settled.

8. Settlement data validation procedure

The procedure is not defined for this option. There is no specific, user defined validation, which should be performed before the settlement data is passed to the settlement description creation procedure <-> usr_InvListSettlmntDescCreate. The settlement data is therefore not stopped for corrections on the defined Settlement data editing panel. For any interface payment, successfully created in the SRODTA, the corresponding settlement is created (with or without errors) and editable from the standard manual registration panel – A/R settlement workbench. The settlement data, which did not pass the validation, is accessed on the FSR04517, which can be reached directly from the A/R settlement workbench, FSR04501 panel.

Note: The standard validation of an indicated settlement document is always performed by the standard settlement creation procedure ASWFARSetDocSettlmntFromIntrf, which creates the SROVPH, SROVPX file records based on the received settlement description (based on the received SROKBSH and SROKBSD file records). As the procedure enables multi-currency and multi-debtor settlements they will be created.

9. usr_InvListSettlmntDescCreate

This procedure creates the settlement description <-> creates records in the settlement description files SROKBSH and SROKBSD. It is done based on payment data structure (main document) and settled documents list from SROKBSL file.

The payment data structure determines the SROKBSH record, while the SROKBSL records determine the corresponding records in SROKBSD. This procedure copies SROKBSL records directly into SROKBSD.

If the SROKBSL.SLDSOP field value is blank the Document settlement option = 1 (Settle) is defaulted.

*DOC_LIST3

1. Overview

This method is basically a copy of *DOC_LIST with the following difference:

The default Document settlement option, if not provided in the interface file, is 3 (Settle fully) for *DOC_LIST3, while for *DOC_LIST it is 1 (Settle).

Settlement option	Default document settlement option
*DOC_LIST	1=Settle
*DOC_LIST3	3=Settle fully

Choosing this option determines that the Hidden discount document is not created for the last settled document, as each document should be fully settled.

The assignment of the default Document settlement option is done by the Settlement description creation procedure. The base option’s procedure usr_InvListSettlmntDescCreate, is for *DOC_LIST3 replaced by its customized version usr_InvListFullySettleDftDescCreate.

2. Predefined set-up

The preloaded set-up of the *DOC_LIST3 settlement option is the following. The customized procedure, which replaces the one defined for the base settlement option, is marked in red in the attached table.

Field name/Description	Value
Settlement option SROSTOT.STSETO	*DOC_LIST3
Base settlement option SROSTOT.STBSTO	*DOC_LIST
Settlement option number SROSTOT.STSOPT	84
Settlement option description SROSTOT. STSTDS	Document list – fully settle
Data preloading conversion procedure SROSTOT. STSDPC	usr_InvListSettlmntDataPrelConv
Payment defaulting procedure SROSTOT.STPADP	usr_InvListPaymentDataDefault
Data validation procedure SROSTOT.STSDVP
Settlement data editing program SROSTOT.STSDEP	FSR498
Description creation procedure SROSTOT.STSDCP	usr_InvListFullySettleDftDescCreate
Selection option SROSTOT.STSELO	*STDSELCTN
Workbench display SROSTOT.STSWDS	N
Auto-balance method SROSTOT.STSABM	01
Exch rate on doc level SROSTOT.STEROD	N

3. Settlement data interface files

Refer to the section Settlement data interface files for the *DOC_LIST settlement option.

4. Settlement data editing program

Refer to the section Settlement data editing program for the *DOC_LIST settlement option.

5. Settlement info data structure declaration

Refer to the section Settlement info data structure for the *DOC_LIST settlement option.

6. usr_InvListSettlmntDataPrelConv

Refer to the section usr_InvListSettlmntDataPrelConv for the *DOC_LIST settlement option.

7. usr_InvListPaymentDataDefault

Refer to the section usr_InvListPaymentDataDefault for the *DOC_LIST settlement option.

8. Settlement data validation procedure

Refer to the section Settlement data validation procedure for *DOC_LIST settlement option.

9. usr_InvListFullySettleDftDescCreate

This procedure creates settlement definition <-> creates records in the settlement description files SROKBSH and SROKBSD. It is done based on payment data structure (main document) and settled documents list from SROKBSL file.

The payment data structure determines the SROKBSH record, while the SROKBSL records determine the corresponding records in SROKBSD. This procedure copies SROKBSL records directly into SROKBSD.

If the SROKBSL.SLDSOP field value is blank the Document settlement option= 3 (Settle fully) is defaulted.

*DOC_LISTM

1. Overview

The *DOC_LISTM, similar to the *DOC_LIST and DOC_LIST3 settlement options, is dedicated for import rather than manual registration. It should be chosen if an imported payment is to be settled with a provided list of documents.

The fields available in the settlement interface file (SROKBSP) to identify the paid documents are: document type, document number, bank reference number and document reference number. Either document number, or document type and number, or bank reference number, or document reference number should be loaded. If more than one reference is provided then the document found must match all the given references. Otherwise the settlement will be stopped and an error code will be assigned.

This method is suitable if the provided payment and settlement information is incomplete and the system should not only complete the missing payment information (the payment’s debtor), but also determine the settlement sequence and the document settlement option in a way which minimizes the manual data maintenance. Additionally, the method is applicable, if these references loaded into the interface, which do not indicate any document in the transactions file SRODTA, do not need to be corrected and it is acceptable to omit them at settlement creation.

The default values are applied for the imported payment only if the following conditions are fulfilled:

• The applied template is set with the field Init from existing set to YES.
• The corresponding interface file field value is blank.
• The constant value, for the corresponding field in the template indicated at transfer, is not defined.
• The initialization code of the field is NOT set to NI (No init) for the template, which was indicated at transfer.

If a document is found for a given reference, but it differs from the payment’s debtor (the one provided in the interface file or defaulted by the system, from the first found settlement document), then this document will be omitted, in the same way as if it would not indicate any existing document. In other words, the cross-debtor settlement is not applicable for this method. This is to minimize the risk of accidental settlements, for this more automated method.

The settlement sequence and document settlement option defaulting process depends on the payment and settled documents remaining amount. For details refer to the sections usr_InvListMatchPaymentDataDefault and Examples; Settlements created with *DOC_LISTM.

If a reference, provided in the settlement interface file, does not indicate any document in the transactions file SRODTA (SRODTA.DTREFX cannot be assigned by the Payment defaulting procedure), it is excluded from the settlement process. It is omitted by the Settlement description creation process performed by the procedure usr_InvListMatchSettlDescCreate. No error code is assigned by the system if a referenced document is not found, and therefore omitted. It means that the user will not be notified and the incorrect references will not be available for corrections.

2. Predefined set-up

The preloaded set-up of the *DOC_LISTM settlement option is the following. The customized procedures, which replace the ones defined for the base settlement option, are marked in red in the attached table.

Field name/Description	Value
Settlement option SROSTOT.STSETO	*DOC_LISTM
Base settlement option SROSTOT.STBSTO	*DOC_LIST
Option number SROSTOT.STSOPT	85
Settlement option number description SROSTOT. STSTDS	Doc list – omit not matched
Data preloading conversion procedure SROSTOT. STSDPC	usr_InvListSettlmntDataPrelConv
Payment defaulting procedure SROSTOT.STPADP	usr_InvListMatchPaymentDataDefault
Data validation procedure SROSTOT.STSDVP
Settlement data editing program SROSTOT.STSDEP	FSR498
Description creation procedure SROSTOT.STSDCP	usr_InvListMatchSettlDescCreate
Selection option SROSTOT.STSELO	*STDSELCTN
Workbench display SROSTOT.STSWDS	N
Auto-balance method SROSTOT.STSABM	01
Exch rate on doc level SROSTOT.STEROD	N

3. Settlement data editing program

Refer to the Settlement data editing program in the *DOC_LIST section.

4. Settlement info data structure declaration

Refer to the Settlement info data structure in the *DOC_LIST section.

5. usr_InvListSettlmntDataPrelConv

Refer to the usr_InvListSettlmntDataPrelConv in the *DOC_LIST section.

6. usr_InvListMatchPaymentDataDefault

This defaulting procedure determines the payment’s debtor and transaction currency, as well as the settlement sequence and the document settlement option. The following fields in the native files will be completed by the system:

• SRON483.NVDENO
• SRON483.NVTCUR
• SROKBSL.SLSTSQ
• SROKBSL.SLDSOP

Note: The defaulting procedure is run only if the parameter Init from existing is set to YES for the applied template.

The payment’s default values are returned by this procedure in the parameter pPaymentDS:

• Debtor number.
  The value is retrieved from the SRODTA record indicated by the first SR1KBSL record, for which the corresponding SRODTA record exists.

  Note: If the reference is not unique, then the first found document is considered.

• Transaction currency.
  The value is retrieved from the first found SRODTA record indicated by the SR1KBSL record. The value is returned as the default currency if all the documents indicated in SR1KBSL and found in SRODTA are updated with this transaction currency (SRODTA.DTTCUR).

The default field values returned by the procedure will be applied for the imported payment only if the following conditions are fulfilled:

• The interface file field value is blank.
• The constant field value is not defined for the template, which was indicated at transfer.
• The initialization code of the field is NOT set to NI (No init) for the template, which was indicated at transfer.

If an indicated document is found in SRODTA its reference number is updated in the SROKBSL record as the SROKBSL.SLREFX field value. It is done to ensure that the document that is used by the Payment defaulting procedure is the one which will be settled by the Settlement description creation procedure. It can be considered as a defaulting process of the Reference number field value.

If a document is found for the given reference, but it belongs to another debtor than the one loaded or defaulted for the payment (defaulted from the first found settlement document) then it will be omitted, and the search is continued. It is done to disable the cross-debtor settlements, in order to minimize the risk of accidental settlements, for this more automated method.

The settlement sequence and the document settlement option are determined by the relation between the payment amount and the sum of remaining amount of the documents that should be settled. Separate rules apply for Overpayment (the sum of payment amount and the remaining amounts of all the found settlement documents is less than zero) and for Underpayment (the sum of payment amount and the remaining amounts of all the found settlement documents is greater than zero). If any of the indicated settlement documents has another currency than the payment, the system cannot classify the settlement as Overpayment or Underpayment. However, the system makes the settlement sequence and document settlement option assignment, as described below.

1. Default document settlement option and settlement sequence.

The default values are assigned according to the following rule:

Document	Underpayment (or match) SUM < = 0	Overpayment SUM > 0
Invoices (Invoice-like documents)	SettlSequence = 2 (second) DocSettlOption = 1 (settle)	SettlSequence = 1 (first) DocSettlOption = 3 (fully)
Credit notes (Payment-like documents)	SettlSequence = 1 (first) DocSettlOption = 3 (fully)	SettlSequence = 2 (second) DocSettlOption = 1 (settle)

Where:

SUM = (remaining amount (or paid amount) of the found referenced document) + payment amount)

Note: The same rule applies for zero payments.

2. Overpayment – default document settlement option and settlement sequence.

If the imported payment amount plus the sum of the found invoice-like and the found payment-like documents is less than zero then:

• At first the invoice-like documents are settled. The document settlement option= 3 will be assigned by the system.
• After that payment-like documents are settled. The document settlement option= 1 will be assigned by the system. It means that the last payment-like document(s) will be either not settled (the settlement will end up in error) or the last payment-like document will be partially settled (the settlement will be successfully created without being stopped).
3. Underpayment – document settlement option and settlement sequence.

If the imported payment amount plus the sum of the found invoice-like and the found payment-like documents is greater than zero then:

• At first payment-like documents are settled. The document settlement option= 3 will be assigned by the system.
• After that invoice-like documents are settled. The document settlement option= 1 will be assigned by the system. It means that the last invoice-like document(s) will be either not settled (the settlement will end up in error) or the last invoice-like document will be partially settled (the settlement will be successfully created without being stopped) or, if the for the last invoice-like document the Hidden discount conditions are fulfilled, then it will be fully settled and the Hidden discount document will be created (the settlement will be successfully created without being stopped).
4. Undetermined – default document settlement option and settlement sequence.

If the transaction currency of a settlement document differs from the payment’s currency then, it is not determined if an overpayment or underpayment is imported. In this case the payment-like documents are settled first and then the invoice-like ones. All the settlement document are be settled with the document settlement option = 3 (fully settle).

Document	Default values
Credit notes (Payment-like documents)	SettlSequence = 1 (first) DocSettlOption = 3 (settle fully)
Invoices (Invoice-like documents)	SettlSequence = 2 (second) DocSettlOption = 3 (settle fully)

7. Settlement data validation procedure

Refer to the section Settlement data validation procedure for *DOC_LIST.

8. usr_InvListMatchSettlDescCreate

This procedure creates settlement definition <-> creates records in the settlement description files SROKBSH and SROKBSD. It is done based on payment data structure (main document) and settled documents list from SROKBSL file. The payment data structure determines the SROKBSH record, while the SROKBSL records determine the corresponding records in SROKBSD.

SROKBSL records are copied directly into SROKBSD with exception for the records without any SLREFX assigned (neither by the Payment data defaulting procedure nor loaded in the interface file). They are omitted by this creation procedure. It indicates that the user will not be notified and any error code will be assigned. It is assumed that the references not indicating any document in SRODTA are obsolete and not important.

If the SROKBSL.SLDSOP field value is blank, then the document settlement option = 3 (Settle fully) is defaulted.

9. Examples; Settlements created with *DOC_LISTM

As for this option it is important to understand how the defaulting process of the settlement sequence and document settlement option is performed. Therefore some examples of the possible results will be described in this section.

1. Assumptions for the described examples

The following documents exist in the SRODTA file (their remaining amounts are listed).

FKI  1   400SEK FKI  2   200SEK FKI  3   300SEK FKI  4   100SEK FKC 5  -100SEK FKC 6  -200SEK

Documents with numbers: 11, 12, 13, 14, 15, 16 do not exist in SRODTA.

Let’s assume, for the purpose of the examples, that the references are loaded as the document number field values only (there is no functional difference if any other reference is loaded instead).

There is no difference in the way zero- and non-zero payments are treated. However, the attached examples describe them separately, just to show the settlement result.

Note that the non-balanced payment amount is not set “on account” as for *DOC_LISTM (as well as for the *DOC_LIST3) the Auto-balance method field value is set to 01 indicating that the remaining, non-balance payment amount should not be set “on account”.

2. Example 1; SUM = 0;

SUM = the sum of remaining amounts (paid amounts) of the found referenced documents + payment amount

Information loaded into the payment interface file

• Payment amount  -700SEK

The following references are loaded into the settlement interface file (let’s assume for the purpose of the example, to simplify the example, they are loaded as the document number field values):

1	(Remaining  400SEK)
2	(Remaining  200SEK)
3	(Remaining  300SEK)
4	(Remaining  100SEK)
5	(Remaining -100SEK)
6	(Remaining -200SEK)

All references are found and are used by the settlement program for settlement creation.

No error assigned, the payment is fully settled; all the invoices are fully settled.

3. Example 2; SUM = 0

SUM = the sum of remaining amounts (paid amounts) of the found referenced documents + payment amount

Information loaded into the payment interface file:

• Payment amount  -700SEK

The following references are loaded into the settlement interface file (let’s assume, to simplify the example, that they are loaded as the document number field values):

1		(Remaining  400SEK)
12	Instead of 2	(Remaining  200SEK)  Omitted
3		(Remaining  300SEK)
4		(Remaining  100SEK)
5		(Remaining -100SEK)
16	Instead of 6	(Remaining -200SEK)  Omitted

The payment and the identified documents are fully settled.
References 12 and 16 are omitted at settlement creation. The user is not notified. No error code is assigned to notify that an incorrect reference is sent.

4. Example 3; SUM < 0

SUM = (remaining amount (or paid amount) of the found referenced document) + payment amount) < 0;

Information loaded into the payment interface file:

• Payment amount  -700SEK

The following references are loaded into the settlement interface file (let’s assume, to simplify the example, that they are loaded as the document number field values):

1		(Remaining  400SEK)
1		(Remaining  200SEK)
3		(Remaining  300SEK)
14	Instead of 4	(Remaining  100SEK)  Omitted
5		(Remaining -100SEK)
6		(Remaining -200SEK)

Payment amount + Sum of the remaining amounts = -100SEK < 0 -700 (PAY) – 100 (FKC) – 200 (FKC) + 400 (FKI) + 200 (FKI) + 300 (FKI) = -100 (< *ZERO)

The settlement is successfully created, the listed documents are settled; the Credit note 6 is partially settled (-100 remain as an open amount).

Reference 14 is omitted at settlement creation. The user is not notified. No error code is assigned to notify that an incorrect reference is sent.

5. Example 3a; SUM < 0 and zero payment

SUM = (remaining amount (or paid amount) of the found referenced document) + payment amount) < 0;

Information loaded into the payment interface file:

• Payment amount  0SEK (zero payment)

The following references are loaded into the settlement interface file:

4	(Remaining  100SEK)
6	(Remaining -200SEK)

Payment amount + Sum of the remaining amounts = -100SEK < 0 – 200 (FKC) + 100 (FKI) = -100 (< *ZERO)

The settlement is successfully created, the listed documents are settled; the Credit note 6 is partially settled (-100 remain as an open amount).

6. Example 3b; SUM < 0 and zero payment

SUM = (remaining amount (or paid amount) of the found referenced document) + payment amount) < 0;

Information loaded into the payment interface file:

• Payment amount  0SEK (zero payment)

The following references are loaded into the settlement interface file:

12	Instead of 2	(Remaining  200SEK)  Omitted
4		(Remaining  100SEK)
15	Instead of 5	(Remaining -100SEK)  Omitted
6		(Remaining -200SEK)

Payment amount + Sum of the remaining amounts = -100SEK < 0 – 200 (FKC) + 100 (FKI) = -100 (< *ZERO)

The settlement is successfully created, the listed documents are settled; the Credit note 6 is partially settled (-100 remain as an open amount).

Reference 12 and 14 are omitted at settlement creation. The user is not notified (No error code is assigned to notify that an incorrect reference is sent).

7. Example 3c; SUM < 0; zero payment;

Information loaded into the payment interface file:

• Payment amount  0SEK (zero payment)

The following references are loaded into the settlement interface file:

4	(Remaining  100SEK)
5	(Remaining -100SEK)
6	(Remaining -200SEK)

Payment amount + Sum of the remaining amounts = -100SEK < 0 – 100 (FKC) – 200 (FKC) + 100 (FKI) = -200 (< *ZERO)

The settlement is balanced with the help of the ERR document, the error code is assigned. The invoice FKC 6 is not settled. It must be handled on the settlement interface panel FSR04517.

8. Example 3d; SUM < 0 and zero payment;

Information loaded into the payment interface file:

• Payment amount  0SEK (zero payment)

The following references are loaded into the settlement interface file:

12	Instead of 2	(Remaining  200SEK)  Omitted
4		(Remaining  100SEK)
5		(Remaining -100SEK)
6		(Remaining -200SEK)

Payment amount + Sum of the remaining amounts = -100SEK < 0 – 100 (FKC) – 200 (FKC) + 100 (FKI) = -200 (< *ZERO)

The settlement is balanced with the help of the ERR document, the error code is assigned. The invoice FKC 6 is not settled. It must be handled on the settlement interface panel FSR04517.

Reference 12 is omitted at settlement creation. The user is not notified that the reference is omitted.

9. Example 4; SUM < 0

Information loaded into the payment interface file:

• Payment                  Remaining -700SEK

Settlement documents

1		(Remaining  400SEK)
12	Instead of 2	(Remaining  200SEK)  Omitted
3		(Remaining  300SEK)
14	Instead of 4	(Remaining  100SEK)  Omitted
5		(Remaining -100SEK)
16	Instead of 6	(Remaining -200SEK)  Omitted

Payment amount + Sum of the remaining amounts < 0 – 700 (PAY) – 100 (FKC) + 300 (FKI) + 400 (FKI) = -100 (< *ZERO)

There is no “settlement balance” left to settle FKC 5. The settlement is created, and balanced with the help of ERR document, an error code is assigned.

The settlement for FKC 5 must be manually handled in the settlement interface panel FSR04517.

References 12, 14 and 16 are omitted at settlement creation. The user is not notified No error code is assigned to notify that an incorrect reference is sent.

10. Example 5; SUM > 0

Information loaded into the payment interface file:

• Payment                  Remaining -700SEK

1		(Remaining  100SEK)
12	Instead of 2	(Remaining  200SEK)  Omitted
3		(Remaining  300SEK)
4		(Remaining  400SEK)
15	Instead of 5	(Remaining -100SEK)  Omitted
16	Instead of 6	(Remaining -200SEK)  Omitted

Payment amount + Sum of the remaining amounts > 0 – 700 (PAY) + 100 (FKI) + 300 (FKI) + 400 (FKI) = 100 (> *ZERO)

The FKI 4 is partially settled, the FKI4 remaining amount will be 100 SEK.
Reference 2, 15 and 16 are omitted at settlement creation. The user is not notified. No error code is assigned to notify that an incorrect reference is sent.

11. Example 6; SUM > 0

Information loaded into the payment interface file:

• Payment                  Remaining -700SEK

1		(Remaining  400SEK)
2		(Remaining  200SEK)
3		(Remaining  300SEK)
4		(Remaining  100SEK)
15	Instead of 5	(Remaining -100SEK)  Omitted
6		(Remaining -200SEK)

Payment amount + Sum of the remaining amounts > 0 – 700 (PAY) – 200 (FKC) + 400 (FKI) + 200 (FKI) + 300 (FKI) + 100 (FKI) = 100 (> *ZERO)

The FKI 4 is not settled. The settlement is balanced with the help of ERR document. Settlement for FKI4 must be manually handled on the Interface settlement panel (FSR04517).

Reference 15 is omitted at settlement creation. The user is not notified. No error code is assigned to notify that an incorrect reference is sent.

*DOC_LST30 – example method

1. Overview

The document presents this method as an example method. It is build with the help of the standard plug-ins. It is not preloaded. It is similar to the *DOC_LIST3 (*DOC_LIST) method, however slightly more automated. For this method the usr_InvListMatch30SettlDescCreate is defined as the Settlement description procedure. It determines that:

2. The references loaded into SROKBSP, which do not indicate any documents in the transaction file SRODTA (for which the SRODTA.DTREFX was not assigned by the Defaulting procedure) are automatically omitted at the settlement creation process (without notifying a user as no error code is assigned for this reason).
3. If the document settlement option is not provided in the interface file, then the default option is applied at settlement creation. It is the document settlement option DSOP = 30. The DSOP=30 settles a document as the DSOP=3, unless the settlement balance is equal zero. In the latter case the document settlement is directly set to the status 4=Cancelled (the user is not notified, as the settlement is not stopped as erroneous for this reason).
4. Set-up example

The customized procedure, which replaces the one defined for the base settlement option, is marked in red in the attached table.

Field name/Description	Value
Settlement option SROSTOT.STSETO	*DOC_LST30
Base settlement option SROSTOT.STBSTO	*DOC_LIST
Settlement option number SROSTOT.STSOPT	87
Settlement option description SROSTOT. STSTDS	OmitNotMatchedCancelIfBalanced
Data preloading conversion procedure SROSTOT. STSDPC	usr_InvListSettlmntDataPrelConv
Payment defaulting procedure SROSTOT.STPADP	usr_InvListPaymentDataDefault
Data validation procedure SROSTOT.STSDVP
Settlement data editing program SROSTOT.STSDEP	FSR498
Description creation procedure SROSTOT.STSDCP	usr_InvListMatch30SettlDescCreate
Selection option SROSTOT.STSELO	*STDSELCTN
Workbench display SROSTOT.STSWDS	N
Auto-balance method SROSTOT.STSABM	01
Exch rate on doc level SROSTOT.STEROD	N

*DOC_LSTM3 – example method

1. Overview

The document presents this method as an example method. It is build with the help of the standard plug-ins. It is not preloaded. It is similar to the *DOC_LIST3 (*DOC_LIST) method, however slightly more automated. For this method the usr_InvListMatchSettlDescCreate is defined as the Settlement description procedure. It determines that:

• The references loaded into SROKBSP, which do not indicate any documents in the transaction file SRODTA (for which the SRODTA.DTREFX was not assigned by the Defaulting procedure) are automatically omitted at settlement creation process (without notifying a user, no error code is assigned for this reason).
• If the document settlement option is left blank in the interface file then the default one is applied. It is the standard document settlement option 3=Settle fully.
2. Set-up example

The customized procedure, which replaces the one defined for the base settlement option, is marked in red in the attached table.

Field name/Description	Value
Settlement option SROSTOT.STSETO	*DOC_LIST3
Base settlement option SROSTOT.STBSTO	*DOC_LIST
Settlement option number SROSTOT.STSOPT	86
Settlement option description SROSTOT. STSTDS	OmitNotMatchedSettlefully
Data preloading conversion procedure SROSTOT. STSDPC	usr_InvListSettlmntDataPrelConv
Payment defaulting procedure SROSTOT.STPADP	usr_InvListPaymentDataDefault
Data validation procedure SROSTOT.STSDVP
Settlement data editing program SROSTOT.STSDEP	FSR498
Description creation procedure SROSTOT.STSDCP	usr_InvListMatchSettlDescCreate
Selection option SROSTOT.STSELO	*STDSELCTN
Workbench display SROSTOT.STSWDS	N
Auto-balance method SROSTOT.STSABM	01
Exch rate on doc level SROSTOT.STEROD	N

*DOC_LISTE

1. Overview

The option *DOC_LISTE is based on the *DOC_LIST. It is mainly dedicated for manual registration of transactions, with the assumption that at first all the documents which should be settled are indicated on a dedicated editing panel (FSR498) and after that the payment document is created and settled. However, it may also be used for transactions import, the interface data should then be corrected on the FSR49801 panel.

The multi-currency and multi-debtor are not allowed by the validation procedure defined for this option.

If the paid documents are manually registered on the FSR49801 Doc list based settlement info entry panel the settlement will be performed in the registration sequence.

The default document settlement option 1 (Settle) is used to settle an indicated document.

The field values, which can be defaulted from the paid documents, are the following:

• Debtor number.
  The value is retrieved from the SRODTA record indicated by the first document to be paid.

  Note: If the reference is not unique the first found document is considered.

• Transaction amount.
  The calculated value is the sum of the remaining amounts of all the documents indicated to be paid (which passed the validation).
• Transaction currency.
  The value is retrieved from SRODTA record indicated by the first document to be paid (which passed the validation).
2. Predefined set-up

The preloaded set-up of the *DOC_LISTE settlement option is similar to the *DOC_LIST. The difference is that for *DOC_LISTE the Settlement data validation procedure is defined. It indicates that the settlement data must be entered and corrected on the defined editing panel: FSR49801 Doc list based settlement info entry.

Field name/Description	Value
Settlement option SROSTOT.STSETO	*DOC_LISTE
Base settlement option SROSTOT.STBSTO	*DOC_LIST
Option number SROSTOT.STSOPT	83
Settlement option number description SROSTOT. STSTDS	Doc list settlmnt with editor
Data preloading conversion procedure SROSTOT. STSDPC	usr_InvListSettlmntDataPrelConv
Payment defaulting procedure SROSTOT.STPADP	usr_InvListPaymentDataDefault
Data validation procedure SROSTOT.STSDVP	usr_InvListSettlmntDataValidate
Settlement data editing program SROSTOT.STSDEP	FSR498
Description creation procedure SROSTOT.STSDCP	usr_InvListSettlmntDescCreate
Selection option SROSTOT.STSELO	*STDSELCTN
Workbench display SROSTOT.STSWDS	N
Auto-balance method SROSTOT.STSABM	01
Exch rate on doc level SROSTOT.STEROD	N

3. Settlement data editing program

On the dedicated editing panel: FSR49801 Doc list based settlement info entry the following fields are enabled to indicate documents to be paid:

• Document type and number
• Document number
• Bank reference number

For an indicated document its Paid amount may be entered, if it differs from the document’s remaining amount.

If the data is manually registered on the FSR49801 panel then the program performs the validation of the registered data, and writes the corresponding records into SROKBSL native file (including the reference number of the found document).

After all the paid documents are entered and written into the SROKBSL, and is pressed to confirm that the entry process has been completed, the program calls the defaulting procedure: usr_InvListPaymentDataDefault and then the validation procedure usr_InvListSettlmntDataValidate for the registered set of data.

If the data is imported then it is already preloaded into the SROKBSL native file and the FSR498 program shows the SROKBSL records, including the error codes assigned by the validation procedure run at the loading process. The data with the error code assigned are displayed first on the list, unless a specific settlement sequence is entered in the settlement interface SROKBSP file (it is never overwritten). The erroneous data can be changed or deleted. After is pressed to confirm that the maintenance process has been completed, the program calls the defaulting procedure: usr_InvListPaymentDataDefault and then the validation procedure usr_InvListSettlmntDataValidate for the registered set of data.

For the indicated document its paid amount may be entered, if it differs from the document’s remaining amount.

The data registered on this panel is validated by the defined validation procedure defined for this method: usr_InvListSettlmntDataValidate.

4. Settlement info data structure

Refer to the section Settlement info data structure for *DOC_LIST.

5. usr_InvListSettlmntDataPrelConv

Refer to the section usr_InvListSettlmntDataPrelConv for *DOC_LIST.

6. usr_InvListPaymentDataDefault

   Refer to the section usr_InvListPaymentDataDefault for *DOC_LIST.

7. usr_InvListSettlmntDataValidate

The validation performed for the paid document registered on this panel requires:

• One of the identification fields must be entered; either document type and number, or document number, or the bank reference number.
• If the payment is not created yet, then the debtor and transaction currency for the paid document is retrieved from the first document that should be paid. The next paid document must belong to the same debtor and must have the same currency as the defaulted ones.
• The paid documents must be the invoice-like documents (remaining amount > zero).
• If the payment is already created, all the paid documents must have the same transaction currency and debtor as the registered payment.
8. usr_InvListSettlmntDescCreate

Refer to the usr_InvListSettlmntDescCreate for *DOC_LIST.

Manual settlement method *MANUAL

1. Overview

The option *MANUAL is created to define manual settlement (the settlement created on the existing, A/R settlement workbench, panel) in the same way as the other settlement options applicable for the new Work with open batches routine. All the plug-in procedures are blank, as there is no need to interpret/extract the settlement interface data.

Note: As the A/R settlement workbench panel/program is common for the Work with open batches and the Enter financial transactions routines, the *MANUAL settlement option set-up applies for both routines.

2. Preloaded set-up

The preloaded set-up of the *MANUAL settlement option is the following:

Field name/Description	Value
Settlement option SROSTOT.STSETO	*MANUAL
Base settlement option SROSTOT.STBSTO
Option number SROSTOT.STSOPT	81
Settlement option number description SROSTOT. STSTDS	Manual settlement
Data preloading conversion procedure SROSTOT. STSDPC
Payment defaulting procedure SROSTOT.STPADP
Data validation procedure SROSTOT.STSDVP
Settlement data editing program SROSTOT.STSDEP
Description creation procedure SROSTOT.STSDCP
Selection option SROSTOT.STSELO	*STDSELCTN
Workbench display SROSTOT.STSWDS	Y
Auto-balance method SROSTOT.STSABM
Exch rate on doc level SROSTOT.STEROD	N

Predefined procedures/programs

In this section all the predefined procedures, of different plug-in types, are enumerated. The list should be kept updated, as it can be suitable if:

• a new settlement option is to be created based on an existing method,
• an existing option should be customized/modified.

Any existing procedure valid for a base option can basically be used for any option defined with this base.

Settlement data preloading conversion procedure

Name of the Settlement data preloading conversion procedure	Valid for the base settlement option	Declared constant name for the option’s category
usr_BankRefSettlmntDataPrelConv	78 *DOC_BRNO	BANKREFSETPGMSOPT
usr_StdSettlmntDataPrelConv	79 *DOC_TYPNO	STDSETPGMSOPT
usr_InvListSettlmntDataPrelConv	82 *DOC_LIST	INVLISTSOPT

1. usr_BankRefSettlmntDataPrelConv

Refer to the section usr_BankRefSettlmntDataPrelConv.

2. usr_StdSettlmntDataPrelConv

Refer to the section usr_StdSettlmntDataPrelConv.

3. usr_InvListSettlmntDataPrelConv

Refer to the section usr_InvListSettlmntDataPrelConv.

Payment defaulting procedure

Name of the Payment defaulting procedures (Plug-in type constant name <-> ST05)	Valid for the base settlement option	Declared constant name for the option’s category
usr_BankRefPaymentDataDefault	78 *DOC_BRNO	BANKREFSETPGMSOPT
usr_StdPaymentDataDefault	79 *DOC_TYPNO	STDSETPGMSOPT
usr_InvListPaymentDataDefault	82 *DOC_LIST	INVLISTSOPT
usr_InvListMatchPaymentDataDefault	82 *DOC_LIST	INVLISTSOPT

1. usr_BankRefPaymentDataDefault

Refer to the section usr_BankRefPaymentDataDefault.

2. usr_StdPaymentDataDefault

Refer to the section usr_StdPaymentDataDefault.

3. usr_InvListPaymentDataDefault

Refer to the section usr_InvListPaymentDataDefault.

4. usr_InvListMatchPaymentDataDefault

Refer to the section usr_InvListMatchPaymentDataDefault.

Settlement data validation procedure

Name of the Settlement data validation procedures (Plug-in type constant name <-> ST06)	Valid for the base settlement option	Declared constant name for the option’s category
usr_BankRefSettlmntDataValidate	78 *DOC_BRNO	BANKREFSETPGMSOPT
usr_StdSettlmntDataValidate	79 *DOC_TYPNO	STDSETPGMSOPT
usr_InvListSettlmntDataValidate	82 *DOC_LIST	INVLISTSOPT

1. usr_BankRefSettlmntDataValidate

Refer to the section usr_BankRefSettlmntDataValidate.

2. usr_StdSettlmntDataValidate

Refer to the section usr_StdSettlmntDataValidate.

3. usr_InvListSettlmntDataValidate

Refer to the section usr_InvListSettlmntDataValidate.

Settlement data editing program

Name of the Settlement data editing programs (Plug-in type constant name <-> ST08)	Valid for the base settlement option	Declared constant name for the option’s category
FSR496	78 *DOC_BRNO	BANKREFSETPGMSOPT
FSR493	79 *DOC_TYPNO	STDSETPGMSOPT
FSR498	82 *DOC_LIST	INVLISTSOPT

Settlement description creation procedure

Name of the Settlement description creation procedures	Valid for the base settlement option	Declared constant name for the option’s category
usr_BankRefSettlmntDescCreate	78 *DOC_BRNO	BANKREFSETPGMSOPT
usr_StdSettlmntDescCreate	79 *DOC_TYPNO	STDSETPGMSOPT
usr_InvListSettlmntDescCreate	82 *DOC_LIST	INVLISTSOPT
usr_InvListFullySettleDftDescCreate	82 *DOC_LIST	INVLISTSOPT
usr_InvListMatch30SettlDescCreate	82 *DOC_LIST	INVLISTSOPT
usr_InvListMatchSettlDescCreate	82 *DOC_LIST	INVLISTSOPT

1. usr_BankRefSettlmntDescCreate

Refer to the section usr_BankRefSettlmntDescCreate.

2. usr_StdSettlmntDescCreate

Refer to the section usr_StdSettlmntDescCreate.

3. usr_InvListSettlmntDescCreate

Refer to the section usr_InvListSettlmntDescCreate.

4. usr_InvLisrFullySettleDftDescCreate

Refer to the section usr_InvListFullySettleDftDescCreate.

5. usr_InvListMatchSettlDescCreate

Refer to the section usr_InvListMatchSettlDescCreate.

6. usr_InvListMatch30SettlDescCreate

The creation procedure usr_InvListMatch30SettlDescCreate creates settlement description <-> copies from the native file SROKBSL to SROKBSH/SROKBSD only for the records for which the reference number has been assigned by the Defaulting procedure. It means the records that point to the documents existing in transactions file SRODTA.

References which do not point any documents in the transaction file SRODTA are omitted at the settlement creation process, without notifying a user.

If the document settlement option is not provided in the interface file, then the default option is applied. It is the Document settlement option DSOP = 30.

The Document settlement option 30 (Settle fully for non-zero balance) is predefined and preloaded at system installation as follows:

Document settlement option	30
Description	Settle fully if non-zero balance
Allowed for batch	Y
Unsettle first	N
Settlement condition check	usr_DocFullySettleBalCond
Document settlement	usr_DocFullySettleMethod
Manual settlement condition check
Debit note condition check
Difference documents condition
Document info display

The document settlement option 30 settles a document almost in the same way as DSOP = 3 (Settle fully) with the following difference.

If the settlement balance is equal to zero then the next document indicated in the interface file SROKBSP will not be settled. It is omitted (although it was found in the transactions file SRODTA). It automatically receives the document settlement status 4 (Cancelled). The user is not notified and the settlement is successfully completed, if no other errors exist.

The procedure usr_DocFullySettleBalCond is the one, which checks the condition and classifies a document as the one to be omitted by the settlement process.

If, for example, for the settlement option *DOC_LIST3 the procedure usr_InvListMatch30SettlDescCreate will replace usr_InvListFullySettleDftDescCreate, which is currently preloaded, then the settlement will be created in the following way.

• All the documents, which do not indicate any document in the transaction file SRODTA, are omitted. The user is not notified that a reference was omitted.
• If a document settlement option is left blank in the interface file then the default one is applied. This option settles an indicated document as the Document settlement option 3 (Settle fully), unless the settlement balance is equal to zero. In the latter case the document is ignored and the document’s settlement automatically receives status 4=Cancelled. The user is not notified.

Related topics

• Setting up the Open batch environment