Description
This program prints payment notices for customers and vendors.Depending on the transaction, notifications purely about the clearingprocedure when posting an incoming payment or about partial payments,difference notifications (debits in the case of underpayments orcredits in the case of overpayments), or inquiries about the purpose ofpayments can be created.
As a rule, the print program is only carried out directly during systemconfiguration for testing purposes. Otherwise, the call is carried outautomatically by means of higher-level correspondence programs.

Precondition
Before you can print payment notices within the correspondencefunction, the following requirements must be met.
Configuration
Make the basic settings for correspondence in the "Financial AccountingGlobal Settings" Implementation Guide. More detailed information aboutthe standard settings is given below in this documentation.
Defining forms
Forms must be defined and activated in the system so that you can printthe required letters. The standard system provides a form that you cancopy 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 apayment amount is set in at least one customer or vendor item of theclearing document are supported. The corresponding functions are atpresent "Internal transfer posting with clearing", "Incoming payments","Fast entry of incoming payments", "Outgoing payments", "Downpayments","Bills of exchange on request", and "Bill of exchangepayments". For a payment amount to be determined by the system forthese functions, all bank accounts, bank subaccounts, bank clearingaccounts or bank charges accounts, and reconciliation accounts forposting bills of exchange to which postings are made within theframework of these functions must be flagged as cash flow-relevant inthe 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 theframework of an incoming payment to another account. In the standardsystem, the fact that money is paid out to a customer or vendor is nottaken into consideration. Thus in this case, the customer or vendorwould receive a clearing notification when the payment is received. Ifyou require a confirmation for an outgoing payment, you should create anew correspondence type. You then assign a customer-specific form tothis correspondence type by changing the text correspondingly. Youshould, however, be careful that payment notices are not issued twicedue to rules or entries in the master record for requesting paymentnotices.
Cross-company code transactions are not supported.
Even for head offices with local processing, payment notices areaddressed to the head office and not to the branch.
In the case of document extracts sent to one-time customers, businesstransactions can be posted in a document for one customer only.
With clearings between customers and vendors, a payment noticeaddressed to the customer is created for each customer/vendor pair ifthe corresponding flag is set in the master records.
Correspondence types for payment notices with an individual text, orwith additional date specifications cannot be requested automatically -that is, by selecting one of the fields for payment notices in thecustomer master record, or by making an entry in the table whichcontrols payment notices.

Output
A payment notice is created for each customer or vendor, orcustomer/vendor pair in a document. If the payment transaction containsa payment on account item, a reply slip can be issued with the openitems of the account(s) involved. A separate spool request is createdfor each company code. For test purposes, the reply slip can bedisplayed on the screen. If you do not specify for the print program onwhich printer the correspondence should be printed, the program maytake the printer specified in the user master of the user who startedthe program, or the printer specified when the job is scheduled.
If minor errors occur during the program run, that is errors that donot lead to a program termination, these are listed after the run in anerror list. If you want these error lists to be printed on a certainprinter, you should specify a printer for the log in the print programor the print program variant. If you do not make this specification,the program reacts as above (as for the printer for thecorrespondence). If the program is run online, the error list isdisplayed on the screen. If, however, the program is scheduled as ajob, the job request name for the error list is composed of theidentifier F140ER, the printer name and maybe the correspondence typeand/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 programrun. If you do not specify for the print program on which printer thelog should be printed, the program may take the printer specified inthe user master of the user who started the program, or the printerspecified when the job is scheduled. If the program is carried outonline, the log is displayed on the screen. If the program is plannedas a job, the spool request name of the log is made up of theidentifier F140, the printer destination, the date of creation and theprogram ID KORD. If the print program is started by a higher-levelcorrespondence program, the log entry is made by means of thehigher-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 thestandard system, with examples of customer-specific enhancements.

Customizing:
Make the settings for correspondence in the "Financial AccountingGlobal Settings" Implementation Guide. There you maintain thesuboptions 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 codeexist. If you do not want this, you should only make table entries incases 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 aZ are examples of customer-specific objects which are not delivered inthe standard system.
For payment notices dependent on reason codes, configuration isexplained using the example of reason code 050 and the correspondingcorrespondence type SAP50.

1. "Financial Accounting Global Settings": Settings forcorrespondence:
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 allcompany 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 IDFIKO. For the use of individual texts, a standard text must alwaysexist and be entered during program assignment. A standard text mustcontain at least one comment line (format line = /*). Default texts canbe 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 inthe client in which you need them. The text ID is FIKO. With thetransaction 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 iscalled "standard text". In the standard system, it is contained in theprofile 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 aredefined for the relevant form.
If you enter a language for the correspondence request into which thedefault text is not translated, you receive a blank text editor toenter 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 inthe form, you can create the default text analog to the followingexample:
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 containevents (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 alltext elements in your form for which individual text passages are to beissued 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 eachcorrespondence request. The names of these texts are made up of theidentification code F140, the user ID, the date of request, and thetime of the text creation. These texts can be changed with themaintenance transaction for correspondence requests.
1.4. Examples of the forms:
The entries are to be left blank either for individual company codes orexplicitly 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 formsexist in the client in which you need them. If standard forms do notexist, you can copy the missing forms from client 000 with thetransaction SE71 (Menu -> Utilities -> Copy from client).
You can create your own forms by copying the standard form and changingthe layout set text (generally in the MAIN window). Your forms muststart with a "Y" or a "Z". The form name should contain theidentification code "F140".
Your own forms or standard forms in clients not equal to 000 might haveto be adapted during release changeovers according to the standard formin client 000.
If you need the standard form or a form created by you in languages forwhich no translation exists, you can translate the forms using thetransaction SE63.
In the standard form for payment notices, preparations are made for theuse of individual texts or the direct use of a standard text in thefollowing 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 positionof 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 followingexample:
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 nameof the individual text belonging to a correspondence request. Thevariable RF140-TDSPRAS contains the entry language or the outputlanguage of the text. The whole letter is output in this language.
Additional date details are provided for each correspondence request inthe variables RF140-DATU1 and RF140-DATU2 for the form printout. Youcan integrate these variables in the required place of theZF140_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 inthe 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 inthe "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 explicitlyfor all company codes, or are to be left blank as default for companycode.
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 textsexist in the client in which you need them. The text ID is ADRS. Ifstandard texts do not exist, you can copy the missing texts from client000 with the transaction SO10 (Menu -> Utilities -> Copy from client).
If, on account of company stationery, you do not require individualspecifications - such as the header text and the footer text - you canleave the respective fields in the table blank. Normally, however, atleast the standard text for the signature is needed. You should,however, make a default entry (company code = blank and name of theprint program) in the table to avoid error messages if you do not wantto use texts.
1.6. Call options:
The entries are to be left blank either for individual or explicitlyfor all company codes, or are to be left blank as default for companycode.
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 forpayment notices.
You determine the order in which the payment notices are issued usingthese 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 sequenceof 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 fieldsfrom the master record tables KNA1, KNB1, and LFB1. The fields KOART,KONTO, KTOGR (KNA1-KTOKD or LFA1-KTOKK), and KTOZE (KNB1-KNRZE orLFA1-LNRZE) are filled in accordance with the account type, which istaken from the master record tables. The fields "Document number" and"Fiscal year" are only filled in the case of document-relatedcorrespondence, such as payment notices.
You can extend this list of selectable fields in order to meet yourrequirements. To do so, you can use a repair correction to importfields from the following tables, that are not yet in table RF140V,into table RF140VZZ: KNA1, KNB1, LFA1, and LFB1. When doing so, youmust take care to use the field names and data elements from thestandard tables, as the fields in table RF140VZZ are supplied using thenames from the master records. After you have added these fields, youmust activate table RF140VZZ. The sort fields are then supplied inaccordance with their names, and in a pre-defined sequence as follows:
The sort fields are drawn first from the KNA1 or LFA1 data, and thenfrom KNB1 or LFB1.
For this reason, fields that have the same name in tables KNA1 andKNB1, 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 apayment or for the open item list of the reply for a payment onaccount, and/or sort variants for a list of residual items or partialpayments.
You can use the sort variants for line items to determine the sequencein 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 inthe 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 thedocument tables BKPF and BSEG. The field HBELN contains the referencenumber in case this is needed; otherwise it contains the documentnumber.
You can extend this list of selectable fields in order to meet yourrequirements. To do so, you can use a repair correction to importfields from tables BKPF and BSEG that are not yet in table RF140W, intotable RF140WZZ. When doing so, you must take care to use the fieldnames and data elements from the standard tables, as the fields intable RF140WZZ are supplied using the names from the documents. Afteryou have added these fields, you must activate table RF140WZZ. The sortfields are then supplied in accordance with their names and in apre-defined sequence as follows:
The sort fields are drawn first from the BKPF data, and then from theBSEG data.
For this reason, fields that have the same name in tables BKPF and BSEGmay be overwritten.
2. Payment notice:
You make the following settings in the "Accounts Receivable andAccounts Payable" Implementation Guide under "Outgoing PaymentNotices".
2.1. Control:
If correspondence requests are to be made automatically for incomingpayment, you can make the specifications outlined below.
For each company code, you can store rules for the creation of paymentnotices. In addition to this, you can distinguish the entries accordingto tolerance groups for customers. Tolerance groups are entered in thecustomer master records.
If you store a rule for a company code without specifying a tolerancegroup, then - if no rule is found for the tolerance group of thecustomer for whom the payment is made - the table entry withouttolerance group is accessed by default. If you do not want this, youshould only store rules which are specified precisely by means ofcompany 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 thecustomer 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 SAP01is requested. On selecting the field "Cust. (w/o CI)", thecorrespondence type SAP02 is requested. On selecting the field "Salesdepartment", the correspondence type SAP03 is requested. On selectingthe field "Accounting department", the correspondence type SAP04 isrequested. On selecting the field "Legal department", thecorrespondence type SAP05 is requested.
If you select one of the two fields in the master record, a rule storedunder the "Control payment notices to be created automatically" step isignored.
Correspondence types for payment notices with time details cannot beused for automatic requests. That is, the correspondence types SAP01 toSAP05 which are requested if you select the customer master recordfields, and all correspondence types which are stored in the "Controlpayment notices to be created automatically" step, do not need anyadditional 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 andAccounts Payable" Implementation Guide in the "Define Reason Codes"activity under the "Incoming Payments" business transaction. Afterentering the required company code, maintain the reason codes as in thefollowing example:
RsC Short text Long text CorrT A S
---------------------------------------------------------------------
050 Cash disc.period Cash disc.period exceeded SAP50