DESCRIPTION
This program prints payment notices for customers and vendors. Depending on the transaction, notifications purely about the clearing procedure when posting an incoming payment or about partial payments, difference notifications (debits in the case of underpayments or credits in the case of overpayments), or inquiries about the purpose of payments can be created.
As a rule, the print program is only carried out directly during system configuration for testing purposes. Otherwise, the call is carried out automatically by means of higher-level correspondence programs.
PRECONDITION
Before you can print payment notices within the correspondence function, the following requirements must be met.
ConfigurationMake the basic settings for correspondence in the "Financial Accounting Global Settings" Implementation Guide. More detailed information about the standard settings is given below in this documentation.
Defining formsForms must be defined and activated in the system so that you can print the required letters. The standard system provides a form that you can copy and adapt to meet your own requirements.
In the standard system, the form F140_PAY_CONF_01 is used.
RESET N1
The following restrictions apply to the creation of payment notices:
Only postings which are created by means of functions in which a payment amount is set in at least one customer or vendor item of the clearing document are supported. The corresponding functions are at present "Internal transfer posting with clearing", "Incoming payments", "Fast entry of incoming payments", "Outgoing payments", "Down payments","Bills of exchange on request", and "Bill of exchange payments". For a payment amount to be determined by the system for these functions, all bank accounts, bank subaccounts, bank clearing accounts or bank charges accounts, and reconciliation accounts for posting bills of exchange to which postings are made within the framework of these functions must be flagged as cash flow-relevant in the G/L account master record.
If a negative total payment amount results for a customer or vendor, this is interpreted in the standard system as a clearing within the framework of an incoming payment to another account. In the standard system, the fact that money is paid out to a customer or vendor is not taken into consideration. Thus in this case, the customer or vendor would receive a clearing notification when the payment is received. If you require a confirmation for an outgoing payment, you should create a new correspondence type. You then assign a customer-specific form to this correspondence type by changing the text correspondingly. You should, however, be careful that payment notices are not issued twice due to rules or entries in the master record for requesting payment notices.
Cross-company code transactions are not supported.
Even for head offices with local processing, payment notices are addressed to the head office and not to the branch. In the case of document extracts sent to one-time customers, business transactions can be posted in a document for one customer only.
With clearings between customers and vendors, a payment notice addressed to the customer is created for each customer/vendor pair if the corresponding flag is set in the master records.
Correspondence types for payment notices with an individual text, or with additional date specifications cannot be requested automatically - that is, by selecting one of the fields for payment notices in the customer master record, or by making an entry in the table which controls payment notices.
OUTPUT
A payment notice is created for each customer or vendor, or customer/vendor pair in a document. If the payment transaction contains a payment on account item, a reply slip can be issued with the open items of the account(s) involved. A separate spool request is created for each company code. For test purposes, the reply slip can be displayed on the screen. If you do not specify for the print program on which printer the correspondence should be printed, the program may take the printer specified in the user master of the user who started the program, or the printer specified when the job is scheduled.
If minor errors occur during the program run, that is errors that do not lead to a program termination, these are listed after the run in an error list. If you want these error lists to be printed on a certain printer, you should specify a printer for the log in the print program or the print program variant. If you do not make this specification, the program reacts as above (as for the printer for the correspondence). If the program is run online, the error list is displayed on the screen. If, however, the program is scheduled as a job, the job request name for the error list is composed of the identifier F140ER, the printer name and maybe the correspondence type and/or the company code.
If the print program is carried out directly and a printout issued, then a log with the spool requests created is issued for each program run. If you do not specify for the print program on which printer the log should be printed, the program may take the printer specified in the user master of the user who started the program, or the printer specified when the job is scheduled. If the program is carried out online, the log is displayed on the screen. If the program is planned as a job, the spool request name of the log is made up of the identifier F140, the printer destination, the date of creation and the program ID KORD. If the print program is started by a higher-level correspondence program, the log entry is made by means of the higher-level program (trigger for correspondence).
Information on the Standard Form and the Text Symbols You Can Use
INCLUDE FI_RFFO_SAPSCRIPT_LAYOUT_SET OBJECT DOKU ID TX
Information on the form layout
Information on the text symbols
INCLUDE FI_RFFO_SAPSCRIPT_MAINTAIN OBJECT DOKU ID TX
EXAMPLE
Customizing for payment notices is explained below using of the standard system, with examples of customer-specific enhancements.
Customizing:
Make the settings for correspondence in the "Financial Accounting Global Settings" Implementation Guide. There you maintain the suboptions in accordance with the following guidelines.
Note:
For tables in which a default entry without a company code is allowed,
the default entry is accessed if no entries for a specific company code exist. If you do not want this, you should only make table entries in cases where the company code is predefined. For the relevant tables, there is a note further down on the default entry company code blank.
The correspondence types, forms, and standard texts which start with a Z are examples of customer-specific objects which are not delivered in the standard system.
For payment notices dependent on reason codes, configuration is explained using the example of reason code 050 and the corresponding correspondence type SAP50.
1. "Financial Accounting Global Settings": Settings for correspondence:
For payment notices, the settings are to be made as follows.
1.1. Examples of the correspondence types:
SAP01 Payment notice with line items
X Document necessary
SAP02 Payment notice without line items
X Document necessary
SAP03 Payment notice to sales department
X Document necessary
SAP04 Payment notice to accounting department
X Document necessary
SAP05 Payment notice to legal department
X Document necessary
SAP50 Payment notice with difference 050
X Document necessary
ZAP01 Payment notice individual text
X Document necessary
X Individual text
ZAP02 Payment notice on account double invoice
X Document necessary
X Individual text
ZAP03 Payment notice residual item double credit memo
X Document necessary
X Individual text
ZAP11 Notice for payments on account
X Document necessary
Number of date details.... 1
Date 1 name... Reply date
1.2. Examples of program assignment:
The entries are to be left blank for single or explicitly for all company codes, or are to be left blank as a default for company code.
CCode CorID Program Variant Default text
----------------------------------------------------
0001 SAP01 RFKORD00 SAP01
0001 SAP02 RFKORD00 SAP02
0001 SAP03 RFKORD00 SAP03
0001 SAP04 RFKORD00 SAP04
0001 SAP05 RFKORD00 SAP05
0001 SAP50 RFKORD00 SAP50
0001 ZAP01 RFKORD00 ZAP01 ZF140_PAY_CONF_01
0001 ZAP02 RFKORD00 ZAP02 ZF140_PAY_CONF_02
0001 ZAP03 RFKORD00 ZAP03 ZF140_PAY_CONF_03
0001 ZAP11 RFKORD00 ZAP11
1.3. Examples of default texts:
The default texts must be stored as a standard text with the text ID FIKO. For the use of individual texts, a standard text must always exist and be entered during program assignment. A standard text must contain at least one comment line (format line = /*). Default texts can be maintained in the detail screen of program assignment via Goto -> Text editor or, in the initial menu via Tools -> Word processing -> Standard text.
With transaction SO10, you can check whether standard texts exist in the client in which you need them. The text ID is FIKO. With the transaction SO10, you can copy standard texts from other clients (Menu -> Utilities -> Copy from client).
Everyone wanting to use the text ID FIKO requires the authorization. The authorization object for which the authorization must be defined is called "standard text". In the standard system, it is contained in the profile S_SACHBEARB, and authorizes for every text ID. However, everyone needs at least the authorization for the text ID ST and FIKO.
In the standard text, you may only use the paragraph formats which are defined for the relevant form.
If you enter a language for the correspondence request into which the default text is not translated, you receive a blank text editor to enter the text.
Default text ZF140_PAY_CONF_01, TEXT-ID FIKO
Format Text area
/* Text for individual payment notice
AF
Default text ZF140_PAY_CONF_02, TEXT-ID FIKO
Format Text area
/* Text for payment notice on account double invoice
AF Our invoice 0000000000 from 00/00/0000 was already
AF settled by you on 00/00/0000.
LZ
AF We have therefore credited you the amount. Please
AF clear this amount with your next payment.
Default text ZF140_PAY_CONF_03, TEXT-ID FIKO
Format Text area
/* Text for payment notice residual item duplicated credit memo
AF Our credit memo 0000000000 from 00/00/0000 was reduced by you
AF to USD 0.00 with your payment of 00/00/0000
LZ
AF Please pay the outstanding credit memo amount.
If you want to enter individual text passages at several positions in the form, you can create the default text analog to the following example:
Default text ZEXAMPLE, TEXT-ID FIKO
Format Text area
/* Example of several individual text passages
/: IF<(> RF140-ELEMENT<)> = 'XXX'.
/* Text in the text element XXX
AF Text 1
/: ENDIF.
/: IF<(> RF140-ELEMENT<)> = 'YYY'.
/* Text in the text element YYY
AF Text 2
/: ENDIF.
XXX and YYY represent numbers of text elements
This option cannot be applied, however, in windows that do not contain events (text elements indicated by numbers).
If, however, you want to use individual text passages in, for example, the INFO window as well as in the MAIN window, you must complete all text elements in your form for which individual text passages are to be issued according to the following example:
Text element in INFO window
Format Text area
/E XXX
/: DEFINE <(> RF140-ELEMENT <)> ="XXX"
/: INCLUDE <(> RF140-TDNAME <)> OBJECT BKORM ID FIKO LANGUAGE
<(> RF140-TDSPRAS <)>
Text element in MAIN window
Format Text area
/E YYY
/: DEFINE <(> RF140-ELEMENT <)> ="YYY"
/: INCLUDE <(> RF140-TDNAME <)> OBJECT BKORM ID FIKO LANGUAGE
<(> RF140-TDSPRAS <)>
Individual texts are then created from default texts for each correspondence request. The names of these texts are made up of the identification code F140, the user ID, the date of request, and the time of the text creation. These texts can be changed with the maintenance transaction for correspondence requests.
1.4. Examples of the forms:
The entries are to be left blank either for individual company codes or explicitly for all company codes, and/or as a default for company code.
CCode Program Fo Form
--------------------------------------
0001 RFKORD00 F140_PAY_CONF_01
0001 RFKORD00 IB F140_PAY_CONF_03
0001 RFKORD00 IR F140_PAY_CONF_04
0001 RFKORD00 IV F140_PAY_CONF_02
0001 RFKORD00 50 F140_PAY_CON_050
0001 RFKORD00 IT ZF140_PAY_CONF_1
0001 RFKORD00 ZR ZF140_PAY_CONF_2
With transaction SE71, you should check whether the standard forms exist in the client in which you need them. If standard forms do not exist, you can copy the missing forms from client 000 with the transaction SE71 (Menu -> Utilities -> Copy from client).
You can create your own forms by copying the standard form and changing the layout set text (generally in the MAIN window). Your forms must start with a "Y" or a "Z". The form name should contain the identification code "F140".
Your own forms or standard forms in clients not equal to 000 might have to be adapted during release changeovers according to the standard form in client 000.
If you need the standard form or a form created by you in languages for which no translation exists, you can translate the forms using the transaction SE63.
In the standard form for payment notices, preparations are made for the use of individual texts or the direct use of a standard text in the following text elements:
Form Window Text elements
F140_PAY_CONF_01 MAIN 550, 555, 556, 557, 560,
561, 562, 565, 566
In principle, however, you can use the individual texts at any position of a form.
Examples of form modifications:
Form ZF140_PAY_CONF_1
a.) Create the form ZF140_PAY_CONF_1 and copy
the form F140_PAY_CONF_01 into the form ZF140_PAY_CONF_1.
b.) Modify the text elements 550, 555, 556, 557, 560, 561,
562, 565 and 566 in the window MAIN similarly to the following example:
Format Text area
/E 550
/* No difference postings
/: INCLUDE <(> RF140-TDNAME <)> OBJECT BKORM ID FIKO LANGUAGE
<(> RF140-TDSPRAS <)>
During output, the variable RF140-TDNAME receives in each case the name of the individual text belonging to a correspondence request. The variable RF140-TDSPRAS contains the entry language or the output language of the text. The whole letter is output in this language.
Additional date details are provided for each correspondence request in the variables RF140-DATU1 and RF140-DATU2 for the form printout. You can integrate these variables in the required place of the ZF140_PAY_CONF_2 form which you are going to create.
Example for including document long texts:
If you have entered texts for a document and want them to be printed in the correspondence, proceed as follows:
# Copy the standard form into an individual customer form.
# Determine the window and, if necessary, the text element in which you want to print the document text.
# Determine which data is available when printing the window or text element by using the program documentation (for example, tables BKPF, BSEG, BSID, BSIK, RF140 fields)
# Determine the text ID for the document long text which you want to print (for example, 001) in the "Define text ID for documents" step in the "Financial Accounting Global Settings" Implementation Guide.
# Then insert two lines similar to the following lines at the required position on the form.
/: DEFINE TEXTNAME := ' BKPF-BUKRS(*) BKPF-BELNR(*RF0) BKPF-GJAHR '
/: INCLUDE TEXTNAME OBJECT BELEG ID 0001 LANGUAGE RF140-SPRAS
1.5. Sender details:
The entries are to be left blank either for individual or explicitly for all company codes, or are to be left blank as default for company code.
CCode Program TXTID Header text Footer text Signature
Sender
-----------------------------------------------------------------------
0001 RFKORD00 ADRS_HEADER ADRS_FOOTER ADRS_SIGNATURE
ADRS_SENDER
With the transaction SO10, you should check whether standard texts exist in the client in which you need them. The text ID is ADRS. If standard texts do not exist, you can copy the missing texts from client 000 with the transaction SO10 (Menu -> Utilities -> Copy from client).
If, on account of company stationery, you do not require individual specifications - such as the header text and the footer text - you can leave the respective fields in the table blank. Normally, however, at least the standard text for the signature is needed. You should, however, make a default entry (company code = blank and name of the print program) in the table to avoid error messages if you do not want to use texts.
1.6. Call options:
The entries are to be left blank either for individual or explicitly for all company codes, or are to be left blank as default for company code.
CCode Type of correspondence DocEnt. Pmt DocDsp Act
-----------------------------------------------------------------------
0001 SAP01 Payment notice with line items X
0001 SAP02 Payment notice without line items X
0001 SAP03 Payment notice to sales department X
0001 SAP04 Payment notice to accounting department X
0001 SAP05 Payment notice to legal department X
0001 SAP50 Payment notice with difference 050 X
0001 ZAP01 Payment notice indiv.text X
0001 ZAP02 Payment notice on account double invoice X
0001 ZAP03 Payment notice double credit memo X
0001 ZAP11 Notice for payments on account X
1.7. Correspondence sort variants:
You must store at least one sort variant for the correspondence for payment notices.
You determine the order in which the payment notices are issued using these sort variants.
Sort variant Name
Order Field name Name Offset length
K1 Sorting by postal code
1 LAND1 Country 3
2 HPSTL P.O.box post.code otherwise post.code 10
3 KOART Account type 1
4 KONTO Account 10
K2 Sorting by account number
1 KOART Account type 1
2 KONTO Account 10
K3 Sorting by document number
1 BELNR Document number 10
2 GJAHR Fiscal year 4
All objects are sorted first by company code, and then in the sequence of fields specified in the sort variant being used.
To display a list of the fields by which an object can be sorted, select 'Possible entries' (F4). This contains a selection of fields from the master record tables KNA1, KNB1, and LFB1. The fields KOART, KONTO, KTOGR (KNA1-KTOKD or LFA1-KTOKK), and KTOZE (KNB1-KNRZE or LFA1-LNRZE) are filled in accordance with the account type, which is taken from the master record tables. The fields "Document number" and "Fiscal year" are only filled in the case of document-related correspondence, such as payment notices.
You can extend this list of selectable fields in order to meet your requirements. To do so, you can use a repair correction to import fields from the following tables, that are not yet in table RF140V, into table RF140VZZ: KNA1, KNB1, LFA1, and LFB1. When doing so, you must take care to use the field names and data elements from the standard tables, as the fields in table RF140VZZ are supplied using the names from the master records. After you have added these fields, you must activate table RF140VZZ. The sort fields are then supplied in accordance with their names, and in a pre-defined sequence as follows:
The sort fields are drawn first from the KNA1 or LFA1 data, and then from KNB1 or LFB1.
For this reason, fields that have the same name in tables KNA1 and KNB1, or LFA1 and LFB1 may be overwritten.
1.8 Sort variants for line items:
You can define sort variants for the items cleared by means of a payment or for the open item list of the reply for a payment on account, and/or sort variants for a list of residual items or partial payments.
You can use the sort variants for line items to determine the sequence in which the line items are displayed.
Sort variant Name
Sequence Field name Name Offset length
P1 Document date, ref.or doc.no.
1 BLDAT Document date 8
2 HBELN Ref.no.otherwise doc.no. 16
3 BUZEI Item 3
P2 Sp.G/L ind.,doc.date, doc.no.
1 UMSKZ Special G/L indicator 1
2 BLDAT Document date 8
3 HBELN Ref.no. otherwise doc.no. 16
4 BUZEI Item 3
P3 Document date, document number
1 BLDAT Document date 8
2 BELNR Document number 10
3 BUZEI Item 3
P4 Document date, reference
1 BLDAT Document date 8
2 XBLNR Reference 16
3 BUZEI Item 3
Objects are always sorted initially by company code and thereafter in the sequence of the fields in the sort variant being used.
To obtain a list of the fields by which the objects are sorted, select "Possible entries" (F4). This contains a range of fields from the document tables BKPF and BSEG. The field HBELN contains the reference number in case this is needed; otherwise it contains the document number.
You can extend this list of selectable fields in order to meet your requirements. To do so, you can use a repair correction to import fields from tables BKPF and BSEG that are not yet in table RF140W, into table RF140WZZ. When doing so, you must take care to use the field names and data elements from the standard tables, as the fields in table RF140WZZ are supplied using the names from the documents. After you have added these fields, you must activate table RF140WZZ. The sort fields are then supplied in accordance with their names and in a pre-defined sequence as follows:
The sort fields are drawn first from the BKPF data, and then from the BSEG data.
For this reason, fields that have the same name in tables BKPF and BSEG may be overwritten.
2. Payment notice:
You make the following settings in the "Accounts Receivable and Accounts Payable" Implementation Guide under "Outgoing Payment Notices".
2.1. Control:
If correspondence requests are to be made automatically for incoming payment, you can make the specifications outlined below.
For each company code, you can store rules for the creation of payment notices. In addition to this, you can distinguish the entries according to tolerance groups for customers. Tolerance groups are entered in the customer master records.
If you store a rule for a company code without specifying a tolerance group, then - if no rule is found for the tolerance group of the customer for whom the payment is made - the table entry without tolerance group is accessed by default. If you do not want this, you should only store rules which are specified precisely by means of company code and tolerance group.
Sample entry in the selection screen for a particular company code:
CCode Tolerance group ------------
0001
Sample entry in the detail screen for a certain company code:
Pmnt notice for ---- Notification required ---- Acc.to difference
X Residual item SAP02 X
Partial payment
X Payment on acct SAP01
If a payment notice is always to be created, please maintain the customer master record as follows:
Payment notice to...
X Cust. (with AP) X Sales department
or and/or
X Cust. (w/o AP) X Accounting department
and/or
X Legal department
On selecting the field "Cust. (with CI)", the correspondence type SAP01 is requested. On selecting the field "Cust. (w/o CI)", the correspondence type SAP02 is requested. On selecting the field "Sales department", the correspondence type SAP03 is requested. On selecting the field "Accounting department", the correspondence type SAP04 is requested. On selecting the field "Legal department", the correspondence type SAP05 is requested.
If you select one of the two fields in the master record, a rule stored under the "Control payment notices to be created automatically" step is ignored.
Correspondence types for payment notices with time details cannot be used for automatic requests. That is, the correspondence types SAP01 to SAP05 which are requested if you select the customer master record fields, and all correspondence types which are stored in the "Control payment notices to be created automatically" step, do not need any additional time details.
2.2. Examples of program variants:
Program RFKORD00
SAP01 Correspondence sorting K1
Cleared items X
Reply X
Output to printer Define printer (for
each company code
if necessary)
Log to printer Define printer for error
list (for each company
code if necessary)
SAP02 Correspondence sorting K1
Output to printer Define printer (for
each company code
if necessary)
Log to printer Define printer for error
list (for each company
code if necessary)
SAP03 Form set IV
Correspondence sorting K1
Cleared items X
Output to printer Define printer (for
each company code
if necessary)
Log to printer Define printer for error
list (for each company
code if necessary)
SAP04 Form set IB
Correspondence sorting K1
Cleared items X
Output to printer Define printer (for
each company code
if necessary)
Log to printer Define printer for error
list (for each company
code if necessary)
SAP05 Form set IR
Correspondence sorting K1
Cleared items X
Output to printer Define printer (for
each company code
if necessary)
Log to printer Define printer for error
list (for each company
code if necessary)
SAP50 Form set 50
Correspondence sorting K1
Cleared items X
Output to printer Define printer (for
each company code
if necessary)
Log to printer Define printer for error
list (for each company
code if necessary)
ZAP01 Form set IT
Correspondence sorting K1
Cleared items X
Reply X
Output to printer Define printer (for
each company code
if necessary)
Log to printer Define printer for error
list (for each company
code if necessary)
ZAP02 Form set IT
Correspondence sorting K1
Cleared items X
Output to printer Define printer (for
each company code
if necessary)
Log to printer Define printer for error
list (for each company
code if necessary)
ZAP03 Form set IT
Correspondence sorting K1
Cleared items X
Output to printer Define printer (for
each company code
if necessary)
Log to printer Define printer for error
list (for each company
code if necessary)
ZAP11 Form set ZR
Correspondence sorting K1
Cleared items X
Reply X
Output to printer Define printer (for
each company code
if necessary)
Log to printer Define printer for error
list (for each company
code if necessary)
3. Reason codes:
You also define the reason codes in the "Accounts Receivable and Accounts Payable" Implementation Guide in the "Define Reason Codes" activity under the "Incoming Payments" business transaction. After entering the required company code, maintain the reason codes as in the following example:
RsC Short text Long text CorrT A S
---------------------------------------------------------------------
050 Cash disc.period Cash disc.period exceeded SAP50
Documentation extract taken from SAP system, Copyright (c) SAP AG
Includes used within report:
INCLUDE RFKORI00.
INCLUDE RFKORI01.
INCLUDE RFKORI10.
INCLUDE RFKORI70.
INCLUDE RFKORI71.
INCLUDE RFKORI80.
INCLUDE RFKORI90.
INCLUDE RFKORI91.
INCLUDE RFKORI92.
INCLUDE RFKORI93.
