H2.8.1 User Documentation Billing

Global Process Management System
User Documentation
Process : F-7 Billing Billing & Credit Risk Management
Approval Date: 01.08.2006 Review Date: 01.02.2007
Written By: Guillermo Atencio Approved By: Andreas Hehle
P 1 I 48
END-USER DOCUMENTATION
BILLING & CREDIT RISK MANAGEMENT
CHAPTER 2
Valid on day of print 20/08/2007 12:55:00 - For internal use only -

9494 Schaan Liechtenstein
Process: F-7 Billing Billing & Credit Risk Management

P 2 I 48
TABLE OF CONTENTS
2.1 Billing..........................................................................................................................4
2.1.1 Billing Overview.............................................................................................................................................4
2.1.1.1 Invoice split criteria MO’s.......................................................................................................... 5
2.1.2 Standard Billing Transactions.......................................................................................................................7
2.1.3 Special Billing types........................................................................................................................................9
2.1.3.1 Cancellation.............................................................................................................................. 9
2.1.3.2 Credits to customers................................................................................................................. 9
2.1.3.3 Invoice correction................................................................................................................... 10
2.1.3.4 Debit memo............................................................................................................................ 12
2.1.4 Invoice List....................................................................................................................................................13
2.1.5 Integration with Accounting........................................................................................................................18
2.1.5.1 Forwarding Data to Accounting and Profitability Analysis (CO-PA)........................................19
2.1.5.2 Errors in the transfer to accounting........................................................................................ 19
2.1.6 User Documentation Pre-Invoicing.............................................................................................................21
2.1.7. User Documentation Territory Change after Invoicing..........................................................................21
2.1.8. ProShop business.........................................................................................................................................21
2.1.9. User Documentation MRS..........................................................................................................................21
2.1.10. HOL User Documentation........................................................................................................................21
2.1.11. User Documentation E-Billing..................................................................................................................22
2.1.12 Requesting and printing Customer correspondence...............................................................................22
2.2 Credit Risk Management........................................................................................24

2.2.1 Credit Risk.....................................................................................................................................................24
2.2.1.1 Credit Risk Category.............................................................................................................. 24
2.2.1.2. Risk category assignment..................................................................................................... 24
2.2.2 Credit Limit Extension based on Risk Category.......................................................................................29
Credit Limit will not be calculated if ….............................................................................................................31
Add Transaction Code...........................................................................................................................................31
2.2.3 Credit Checking Matrix...............................................................................................................................32
2.2.3.1 Points at Which a Credit Check can be carried out................................................................33
2.2.3.2 Overview of Credit Check Types............................................................................................ 33
2.2.3.2 Additional Credit Checks........................................................................................................ 41
2.2.4 Remove Holds on Blocked Sales Documents.............................................................................................44
2.2.5 Blocked Order Review.................................................................................................................................45
2.2.6 Other useful transaction codes....................................................................................................................46
2.2.6.1 Transaction Code F.31 Credit overview.................................................................................46
2.2.6.2 Transaction Code F.33 Credit Management Brief overview...................................................46
2.2.6.3 Transaction Code F.35 Credit Master Sheet..........................................................................47
2.2.6.4 Transaction Code F.32 Customers with missing credit data..................................................47


P 3 I 48
CURRENT CHANGES
Chapter Comment Release

2.1.3.1 Cancellation Added Information about Billing Date of Cancellation H2.2
2.1.3.1 Cancellation Added Information about user exit for invoice list per Sorg. H2.7
2.1.6. Pre Invoicing Added to the Billing Documentation H2.8.1.
2.1.7 Territory Change after Added to the Billing Documentation H2.8.1.
Invoicing
2.1.8 ProShop business Added to the Billing Documentation H2.8.1.
2.1.9 User Documentation Added to the Billing Documentation H2.8.1.
MRS
2.1.10 HOL User Added to the Billing Documentation H2.8.1.
Documentation
2.1.11 E-Billing Added to the Billing Documentation H2.8.1.
2.1.12 Requesting and printing H2.8.1.
Customer correspondence


P 4 I 48
2.1 Billing
2.1.1 Billing Overview

Billing documents (Invoices/credit notes etc) are sales documents used to bill a
customer for a goods delivery or a service. A reference to an existing document must
always be used whenever creating a billing document. Data will be copied from the
reference document to the billing document. For delivery-based billing, the quantities to
be billed, for example, can be taken from the delivery; the prices however are taken from
the underlying order.
For special cases it will also be possible to invoice a business partner out of the FI
module of the R/3 system. This does not require a reference document.
General rules for billing:

1. All business transactions involving the physical shipment of goods to
a customer have to be billed with reference to a delivery out of the SD
module of R/3
2. All business transactions involving postings to gross sales accounts
must be posted to via billing out of the SD module. Otherwise there will
be a problem with the integration to the Hilti sales reporting system
(MRS) Exception being account 700002 “Accrued Gross Sales” that
can be posted to via FI but with additional posting to a profitability
segment
3. All business transactions involving accounts in the range 760xxx have
to be invoiced out of the FI module. Exceptions are:
 Austrian environmental tax)
 Freight charged to customers
 Other surcharges.
4. Intercompany services (accounts 770000) are being posted to via the FI
module
The Finance Manual defines revenue recognition when the enterprise has transferred to
the buyer the significant risks and rewards of ownership of the goods.
All billing documents have the same structure. They are made up of a document header
and any number of items.


P 5 I 48
Picture 1: Billing document structure

The header contains the general data that is valid for the entire billing document. This
may include:
 Customer number of the payer
 Billing date
 Net value of the entire billing document
 Document currency
 Terms of payment and Incoterms
 Partner numbers, such as the identification number of the sold-to party
 Pricing elements relevant for the whole invoice
The items contain the data relevant for each individual item.
This may include:
 Material number
 Billing quantity
 Net value of the individual items
 Weight and volume
 Number of the reference document for the billing document (for example, the number
of the delivery on which the billing document is based)
 Pricing elements relevant for the individual items
Only header information will be transferred into the FI Module. In the order most of the
header information can be changed on a line level, which will lead subsequently to an
invoice split.
2.1.1.1 Invoice split criteria MO’s
Setting in customer master data


P 6 I 48
The order is steered about

a prioritization
Picture2.
Setting by sales order
Picture 3.
 Partner Split:
Sold-to Party, Ship-to Party, Bill-to Party and Contact Person (pooled from the
partner functions in the customer Record/Order)
 Project Split:
Consortium-Arge, Construction Project and General Contractor (pooled from the
partner functions in the customer Record/Order)
 Purchase Order Split:
no Split, D Split from Outbound delivery number (Hilti Outbound delivery number), O
Split from Sales order (Hilti Order number), Purchase Order Number (Purchasing
order number of the customer order )
 Collective Split:
no Split, X Split by Collective # (double click on the Purchasing order number or >
Header Data > Purchase Order Data) see the picture 3 above.
 Product Split:
no Split, X Split by Tools / Consumables – Tools is defined as articles if they are
controlled through a serial number.
 Purchase Order required:
with order entry the optional field turns into a required field.


P 7 I 48
2.1.2 Standard Billing Transactions
 Creating a billing document (manually): VF01

..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF01_Consolidated.doc
You can change the following data before you carry out the billing process:
 Billing type: In general the system automatically proposes the correct billing type. If
you intend to change it, enter the appropriate billing type (for example, if you want to
create a pro forma invoice). Not all billing types are allowed, depending on the
preceding document.
 Billing date: If you do not specify a billing date, the billing date is always copied from
the sales order or the delivery (field Billing date).
 Date of services rendered (for credit or debit memos): For credit and debit memos,
you must be able to refer to previous business transactions since tax must be
determined according to the tax situation at the time the services were rendered.
Determination of sales prices is normally carried out at order entry. There is no new
pricing at the time of billing. Exeptions from this are:
- VAT is redetermined at time of billing
- Freight charges are redetermined at time of billing
- VPRS is at least in some cases not redetermined (leading to Delta
CO-PA / FI) – Check with Martin L. still under way
Please note that normally creation and printing of billing documents (e.g. invoices, credit
memos, etc) for Hilti will be performed through a batch job overnight by using the option
of billing in the background.
 Change a billing document: VF02

The user can make only limited changes. Before the system forwards the billing
document to Financial Accounting, the user can
 change output and texts
 carry out new pricing for the individual items or change the prices manually.
But since the time of creation of a billing document and the time of forwarding it to
accounting are normally the same the possibility of changing a billing document will be in
practice not relevant.
After the system forwards the billing document to Financial Accounting, the user can
only change the output and texts.
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF02_Change_Billing_Document.doc
 Display a billing document


P 8 I 48
The user can display any billing document at any time.

..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF03_Diisply Billing Document
S&D.doc
To display changes to a billing document the user might also go into the environment
menu of the SAP billing function
 Processing Billing Due Lists: VF04

The billing due list contains all sales documents (orders or deliveries) that are due for
billing. The billing due list can be used to create invoices manually. It is also yery usefull
to make simulation billing runs with the billing due list and check possible errors that
prevented sales documents from being billed.
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF05_List of Billing Documents.doc
 List of billing documents: VF05

A list of billing documents by a payer from a certain period can be obtained in the
system.
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF05_List of Billing Documents.doc
 Billing in the background: VF06

Normal billing in Hilti Organizations will be done via nightly batch job. Those can be
created via transaction VF06.
But: The billing batch run will normally not be scheduled by the end user, but by an
operator!
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF06_Create_Background_Jobs_for_Bi
lling.doc
To display a log for a billing run please refer to the following BPP:
Transaction code: V.21
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_V.21_Log of Collective Run.doc
 Display a billing document from Archive: VF07

The user can also display a billing document or changes to a billing document from an
Archive but will not be able to view the following data:
 Document flow
 Output
 Partner details
 Payment card data
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF07_Diisply Archived Billing Document
S&D.doc


P 9 I 48
2.1.3 Special Billing types
2.1.3.1 Cancellation
There are several reasons why a billing document may need to be canceled. For
example, an error might have occurred during billing creation, or billing data might have
been posted to the wrong accounts when it was transferred to the accounting
department.
Be aware that a mere deletion of a billing document might lead to severe problems with
the integration to accounting.
To cancel a bill, the user must create a cancellation document. The system copies data
from the original billing document into the cancellation and offsets the entry in
Accounting. The reference document of the billing document will be reset with the status
“not cleared” and (for example, the delivery for the cancelled invoice) can now be billed
again.
The user has the option of canceling individual items or the entire billing document if
desire. This with the Reason rejection code “98 Cancel request“ which can be entered
on line level or on the header. This function is not possible for:
 transactions involving credit cards

 documents that have not yet been forwarded to Financial Accounting
The cancellation and the new invoice are dated as the original invoice date, so that due
date is not extended. Exception is when the original billing date is in a closed period, so
no posting can be done and the billing date will be on the 1st of the current month.
If an extension of the billing date is wished, there is the possibility of changing manually
the billing date in VF01.
Transaction code: VF11

..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF11_Cancel Billing Document.Doc
2.1.3.2 Credits to customers
Credits to customers can be issued for the following reasons:

1, Customer returns material
2. Prices / delivery quantities have been wrong on the invoice
3. Not transaction related credit (“Credit Note for Value”) e.g. for mass freight corrections
or to settle a dispute
Please note: Credit notes out of the FI module must only be used in cases where there
has been beforehand an invoice out of the FI module.


P 10 I 48
Technically all types of credit memos are based on a special SD order type that partially
steers the behaviour of the transactions afterwards. For cases 1 and 2 there should
always be a reference to the transaction (order, delivery, billing doc) the credit is given
for – exception when reference document is not available, but you loose the value flow
of the order in those cases. Currently there are the following possibilities:
Case Order Type Text

1a ZRCB Credit return to blocked stock
1b ZRCF Credit return to free stock
1c ZRBB Cash return to blocked stock
1d ZRBF Cash return to free stock
2 RK Invoice Correction Request
3 ZRCV Credit Memo for Value
In general the credit requests are created in the ZCCN Customer Care Notification for
complaint handling. Through the action box the following transaction code will be called
to enter the request:
Transaction code: ZCCN

..\LINK TO BPP !!!!!!
Transaction code: VA01

..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VA01_Consolidated_Create_Order.doc
When the user creates a credit or debit memo, he must specify the date on which
services are rendered. This is because credit or debit memos can refer to previous
business transactions, and the taxes in the debit or credit memos must be determined
according to the tax situation at the time the services were rendered.
Once a credit or debit memo request is created, the system creates a billing block. This
block prevents you from billing the credit memo request and can only be removed by an
authorized employee. To review blocked billing documents use transaction V23.
2.1.3.3 Invoice correction
Utilizing the invoice correction option, a combination of credit and debit memo requests
is created in one single document. The full credit is granted for the incorrect billing item
while it is simultaneously debited (automatically created as a debit memo item). The
difference created represents the final full amount to be credited.
For each item in an invoice, two line items are automatically created ; a credit and a
debit item which both contain the same value and quantity, but opposite +/- values. If
you change a debit item (new pricing or quantity change), this will result in a difference


P 11 I 48
amount. If the difference amount is positive, the system creates a credit memo. If the
difference is negative, the system creates a debit memo.
Invoice Correction Debit /Credit

Billing Document Request Memo
Doc # Item
Item 10 # Billing Item 1
Credit 1155 10
Item 20 Credit 1155 20 Billing Item 2

Debit 1155 10
Generate Invoice Correction Request

All invoice corrections are based on the billing document number. To begin, you must
reference the existing billing document that is to be modified. Since you will be creating a
new document according to Complaint handling, refer to Create Order transaction VA01
via the Customer Care Notification.
Through the action box choose the invoice correction request (order type RK) and
reference the original billing document. The system copies the relevant header and item
data from the invoice into the invoice correction request. It will list all the credit items
followed by the relevant debit items. With the selection list on the selection tab, you can
chose only relevant items to be taken into the RK request. This is a required procedure
for batch items where the delivery created additional line items and the original line item
has a zero quantity.


P 12 I 48
To change the necessary debit items, the net value field will display the difference
between the credit and debit item fields as a total value. In credit items, the system
completely credits the incorrect invoice item. You can only change the credit item for
deletion, reason for rejection, billing block, and account assignment. In debit items, you
can enter the correct price or quantity. If necessary, you can delete any unchanged
items before saving the invoice correction request. Upon edit and billing completion, the
system will generate the appropriate debit or credit document.
The invoice correction will only impact pricing, but no quantity delivered nor COGS
postings. Therefore changes in quantity are only for price calculation.
2.1.3.4 Debit memo

You might want to charge the customer e.g. for re-stocking of returns. You can use a
debit memo request for those cases. Please refer to following BPP
Transaction code: VA01

Order type: DR – debit memo request,
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VA01_Consolidated_Create_Order.doc


P 13 I 48
Also here: No COGS posting, only revenue accounts affected.
2.1.4 Invoice List

To facilitate their administrative processes quite some customers wants only to be billed
periodically, despite having received several deliveries in that period. To nevertheless
cope with our accounting standards demanding immediate revenue recognition after the
ownership has been transferred to the customer, we use the so called “Invoice List”
functionality in H2.
Basic concept there is that with each delivery a separate billing document is created in
the system (thus recognizing revenue at the appropriate time), but not send to the
customer. Only at period end the single billing documents are combined into one invoice
list document. Please be aware that at latest at period end the customer must be
invoiced, i.e. the invoice list must be sent out.
 An invoice list represents an individual billing document but no accounting

document. It consists of both a document header and document items. Each item
represents a billing document (invoice, debit or credit memo) that is included in
the invoice list. The header contains an overview of summary information, such
as the net value of all documents in the invoice list, the value of any discounts,
details of taxes, and so on. It also contains information on partners such as sold-
to and payer.
 Invoice lists can be created, at specified time intervals on specific dates, e.g.
weekly or monthly invoices. Several billing documents or invoices can be grouped
together at the end of a period specified in the customer master (sales area data)
to form a new billing document. The invoice list is sent to and settled by a
common payer.
 Invoice List Dates - Identifies the customer's factory calendar that is used during the
processing of invoice lists. A factory calendar for the customer must be defined either
in Customizing for Sales or as part of the master data for Sales (Menu path: Logistics
-> Sales & Distribution -> Master data -> Others -> Billing schedules).
Important:
The usage of an invoice list is defined on customer level (as described above).
This means that a customer can have either single invoices or an invoice list. There is no
mixture possible.
This means also that for every invoice type that is used by an “invoice list customer” an
invoice list must be customized in the system
The standard SAP functionality for invoice list is now also splitting according to split
criteria you have defined on customer master.


P 14 I 48
Nevertheless we have now also implemented an user exit where you can define per
sales organization if you want to split according to the split criteria defined on the
customer master or if you want a split it according to the payer.
Double click as above red rectangle.


P 15 I 48


P 16 I 48
There you see only sales organization 2100 is deactivated!!
When a customer has the flag for an invoice list Date, all invoices will be posted within
the nightly invoicing batch with transaction code VF01 or VF04 (see above). No invoices
will be sent to the customer and a dunning block “A” will be set on the open item. This
will be released when executing the billing list with transaction code VF21 or VF24 (see
below).
If you have customers that are set up in XD03 (customer master display) like in the
following screen shot then you will have the possiblity to schedule a night job to generate
invoice lists.
Just to explain the settings again on customer master:
The field "invoicing dates" needs to be filled always. That field determines the calendar
of a country and indicates the system that e.g. billing just will be done on working days.
The field "invoicing list dates" needs to be filled when the invoice list functionality should
be determined. Leave this field blank when no invoice lists are used (in case of individual
billing only).
Furthermore do not enter in the field "invoicing list dates" the same code as in invoicing
dates , e.g. 01 because then an invoice list will be generated per day and this is wished
just in exceptional cases.
The following table will give you an overview on all billing types and their corresponding
invoice list types


P 17 I 48
Delivery Order Invoice List

Order type activated for sales Delivery
related related Billing
area Type
Billing type Billing type Type
BV - Cash sales OTC BV - BV ZBVL
DR - Debit memo request - - L2 LR
KA - Consignment Pick-up LR - - -
KB - Consignment Fill-up LF - - -
KE - Consignment Issue LF F2 F2 LR
KR - Consignment Returns LR - RE LG
OR - Standard order LF F2 F2 LR
RK - Invoice correction request - - G2 LG
Z001 - Rush order LF F2 F2 LR
ZCRV - Credit memo for value - - ZG2 LG
ZCSC - COD LF ZCSC - ZCSL
ZLOR - Legacy order - - - -
ZLCP - LC plus Order ZLCP ZLCP ZLCP ZLCL
ZRBB - ReturnCashCCBlockStk LR ZRV ZRV -
ZRBF - ReturnCashCCFreeStk LR ZRV ZRV -
ZRCB - ReturnCreditBlockStk LR RE RE LG
ZRCF - ReturnCreditFreeStk LR RE RE LG
ZRO - AMS Repair Order ZAIB ZRO - ZROL
ZWV - HILTI FM Contract LF FV FV
An invoice list can be treated as one document with regards to dunning.
The following transactions are relevant for the creation and maintenance of invoice lists:
 Create Invoice List via manual entry of billing document: VF21

..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF21_Create Invoice List.doc
 Change invoice list: VF22

..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF22_Change Invoice List.doc
 Display Invoice List: VF23

..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF23_Display Invoice List.doc
 Pick billing documents out of work list for Invoice Lists: VF24
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF24_Edit Work Lists for Invoice
Lists.doc
 List of Invoice Lists: VF25

..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF25_List of Invoice Lists.doc
 Cancel Invoice List: VF26

..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF26_Cancel Invoice List.doc


P 18 I 48
 Display Invoice List from Archive: VF27

..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VF27_Display Invoice List.doc
It’s important to understand that the creation of an Invoice List NOT create any
accounting document and either any posting.
Please also have in mind that sometime for errors or mistake some invoices (managed
as Invoice List) has an error log. To solve this issue that could happened and then finally
clean the list of not yet invoice list that never must be print and sent it out please see the
following instruction:
Run VF24
Choose the own Company Code
Execute the job (F8)
Press the button ‘Collective Billing on line’
Press Log button and you will see all the ‘error message’
According the setup of the billing type that never will be print it out please run the
following instruction
Go back to the ‘Create invoice List’ screen and via menu select  Setting  Default
Data and change the configuration type from XXXX to ZLRX.
This new invoice list type will never send out automatically to the customers.
2.1.5 Integration with Accounting

When you create a billing the system automatically transfers the billing data to
accounting, generating various financial postings.
Profitcenter
Document
Accounting
Document
Profitability
Invoice Analysis
VF01
Special Ledger
Cost Accnt
Document


P 19 I 48
2.1.5.1 Forwarding Data to Accounting and Profitability Analysis (CO-PA)
The system will forward billing data in invoices, credit and debit memos to Financial
Accounting and post them to the appropriate accounts. This is maintained with the
revenue Account determination. A variety of criteria is valid for a G/L account, depending
on the key combination. The Account determination is based on several criterias as
follows:
 Chart of accounts
 Sales Organisation
 Customer Account determination Group (e.g. 01 Third, 02 Intercompany, 03 Agents,
04 Employees, 50 Fleet Customers)
 Material Account determination Group (e.g. 01 Commercial, 02 Services, 50 Rental
business, 80 Gift Voucher)
 Accounting Key (ERL, ERS, ERF, MWST etc.)
Pricing Procedures Customer Master Material Master
Condition Type Account Assignment Account Assignment

PR00, KF00, … Group Customer Group Material
Accounting Key
ERL, ERS, ERF ... 01 Third, 02 IC etc. 01 Commercial, …
G/L Account
All billing types are defined in such a way that the offsetting entry is made to the
customer account
The integration to Profitability Analysis is done only via the condition types. In a
customizing table each condition type is assigned to a CO-PA value field. This value field
is then in turn passed on to Business Warehouse where you can analyse ist.
2.1.5.2 Errors in the transfer to accounting

There are two major groups of possible errors, when you do not find an expected
document in accounting
a. The billing run might have failed to produce the billing document
b. The billing document could not be transferred from SD to FI module


P 20 I 48
a. Possible errors in the billing run
You can have a complete overview of sales documents due for billing but not yet billed
via the billing due list (transaction VF04). Mark all entries and press Shift-F5 for a
simulation. In the error log of this simulation (Shift-F1) you will then see all errors listed.
Error Action required Remark

Sales order incomplete, Have sales/marketing Consider checking
e.g. pricing condition complete sales order completeness of sales
missing orders in advance of
billing (transactions
V.02)
Document blocked for Have billing block removed
billing
Order quantity not equal Check document flow in Happens normally only
goods issue quantity sales order; contact with cash sales, where
logistics the goods issue is
posted automatically in
the background. Error
reason is then e.g. that
there was physical stock
in the store but not in
the system.
Billing is deferred No action required – billing
will happen automatically
after the defined time
period.
b. Possible errors in the transfer from SD module to FI

You can check all documents not transferred from SD to FI via transaction code VFX3.
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VFX3_Release Billing Doc for
Accounting 1.doc
The most common errors are as follows:

Error Action required
Master data of the payer have Complete master data
not been maintained (e.g.
account assignment group)
Material master not fully Complete master data
maintained (e.g. account
assignment group material)
Customising of account Send remedy ticket


P 21 I 48
assignment not set up correctly

Customising of SD-COPA Send remedy ticket
interface not set up correctly
Posting period not open for Check correctness of billing date and
revenue account posting open period.
Missing foreign trade data in Have sales & marketing check the
sales document sales order; cancel billing document
in SD and re-bill
2.1.6 User Documentation Pre-Invoicing
Please see following document
H2.7_User_Documentation_Pre_Invoicing.doc
2.1.7. User Documentation Territory Change after Invoicing
H2.8_User_Documentation_Territory_Change_After_Invoice.doc
2.1.8. ProShop business
ProShop\H2.6_ProShop_business.doc
2.1.9. User Documentation MRS
H2.7_User_Documentation_MRS.doc
2.1.10. HOL User Documentation
E-Billing\H2.8_HOL_User_Documentation.doc


P 22 I 48
2.1.11. User Documentation E-Billing
E-Billing\H2.8_User_Documentation_E_Billing.doc
2.1.12 Requesting and printing Customer correspondence
SAP R/3 offers a tool to generate customer correspondence. Upto the GPD H2.2 relase
only the customer statement is implemented as a standard transaction. The
correspondence can be generated as follows:
Periodic processing
The period processing is set up in the master record using the indicator for period
account statement. In the transaction code FD02 company code data 
Correspondence tab  Correspondence  Bank statement. The following selection
possibilities are available:
 1 Weekly account statement
 2 Monthly account statement
 3 Yearly account statement
As a next step the period account statements have to be generated with transaction
code F.27. In the output control select ZH2AS Hilti Customer Statement and chose the
indicator of the master record (see bank statement above).
The print is activated through the Toolbar  System  Own spool request


P 23 I 48
Manual processing
There are two ways to manually request correspondence. One way is described in the
following BPP: Transaction code: FB12
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_FB12_Request Correspondence.doc
Or via transaction code FBL5N  Toolbar  Environment  Correspondence 

Request. Select correspondence ZH2AS Hilti Customer statement and enter detail
specifications (see picture below).
Once correspondence has been requested in the system, the next step is to maintain
and print it to the desired output device (e.g. printer).
To manually request correspondence please refer to the following BPP: Transaction

code: F.64
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_F.64_Maintain Correspondence.doc


P 24 I 48
2.2 Credit Risk Management
2.2.1 Credit Risk
The credit control area is an organisational entity, which grants and monitors a credit
limit for customers. A credit control area can include one or more company codes.
In Hilti there will be a 1:1 relationship between company code and credit control area.
The credit control area defined in the company code of the MO is the default credit
control area in the customer master (XD03). You have to make sure that the credit
control area is identical in the FD32 Credit Management.
For every customer account established, the customer’s credit risk must be determined.
You can assign a risk category to a customer in order to classify and carry out credit
checks on customers according to the risk they represent. The risk category determines
which credit checks are to be carried out as well as the minimum or maximum credit limit
a customer may receive depending on the assigned risk category.
2.2.1.1 Credit Risk Category
Every customer is assigned a risk category that is based on the external and internal
financial information of the customer. Both the risk category and the credit limit are
recalculated automatically based on locally predefined parameters. The Credit Risk
Category impacts the calculation of the credit limit but also the credit check on order
entry.
This risk category is calculated automatically on the basis of several parameters by the
transaction ZFIARRC - Hilti Update Risk Category. It can also be manually overwritten in
FD32 – Customer Credit Management. After implementation of R/3 you may maintain it
manually for a limited period.
BPP ZFIARRC - Hilti Update Risk Category
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_FD32_Credit_Management.doc
2.2.1.2. Risk category assignment
As the risk category heavily impacts the ability to manage risk, it is important to
understand the codes prior to assigning them to an account. The risk class is a
combination of an external rating (e.g. Dunn & Bradstreet) and an internal rating
(customer payment history with Hilti).


P 25 I 48
The two digit risk category is comprised of an alpha and a numeric character. The alpha
character indicates the class based on collected external information (company financial
records, credit report form external company, references from other suppliers, etc).
The numerical character indicates the category based on internal information (related
accounts, past payment history, etc). The combined numbers provide the best insight to
the customers overall risk classification based on both internal and external data.
Risk category external rating: Risk category Internal rating:

A: excellent 1. excellent
B: good 2. good
C: average 3. average
D: marginal 4. marginal
E: poor 5. poor
F: unacceptable 6. unacceptable
G: no rating available 7. no rating available
The customer is assigned establish risk categories comprised of various combinations of

the external and internal risk factors. For example, a customer risk category of C5
indicates the external information was average but the internal information was poor
while A2 indicates excellent external and good internal.
External Rating
You do not necessarily use external information for all customers, only according to the
decision of the MO.
 How to enter the external into the system? – Interface not available?
At the moment there is just the possibility to enter the external data manually (or via
mass up-date). The future procedure will be via an interface (Kreditreform (“global” for
MO D and MO AT), D&B (“semi-global for MO GB”), ORT (locally for MO France).
Internal Rating
The calculation of the internal risk category is based on the following criteria:
 % overdue items / turnover last 12 months
 Dunning level of the customer (from XD03 customer master data)
 average elapsed days last 12 months (weighted average amount/days)
Calculation scheme
12 12
 ( An * arrears n)  ( Bn * arrears n) /  ( An  Bn)

n 1 n 1
A = Total with cash discount (FD32 > Payment history > Average days in arrears with cash discount)
B = Total without cash discount (FD32 > Payment history > Average days in arrears without cash
discount)
Arrears = average arrears with/without cash discount payments.
n = number of months in the past.


P 26 I 48
 number of reversed payments within the last 12 months

Remark:
All internal parameters are “time-limited” which means that the calculation of the
turnover and the average elapsed days will is only taking data from the last 12 months.
Example:
 Open items on customer account which are open for more than 365 days, but no
turnover was reported in the last 12 months, and now the calculation of the %
overdue items / turnover last 12 months is zero.
 Payment history is available, but not during the last 12 months, which means that
the average elapsed days will be zero.
An example of Risk category calculation parameters is shown bellow:
Internal risk % overdues / Dunning level Average elapsed Number of reversed

category turnover last 12 days last 12 payments of last 12
months months months
1 2% 0 10 0
2 2% 1 20 5
3 3% 2 60 10
4
5
6
7
The risk category should be determined top down. The parameters represent upper
limits. If one of the limits is exceeded the next range should be checked.
For example:
e.g. customer x


P 27 I 48
%overdues / turnover last 12 months = 2%

Dunning level = 1
Avg. elapsed days = 22
Number of reversed payments = 3
For the calculation, the ?????? lowest risk = highest number
Risk category will be 3 due to the avg. elapsed days last 12 months.
Internal risk % overdues / Dunning level Average elapsed Number of reversed

category turnover last 12 days last 12 payments of last 12
months months months
1 2% 0 10 0
2 2% 1 20 5
3 3% 2 60 10
4


P 28 I 48
New customers -
Months before intern. rc calc. – is this the flag for the new customers eg 6 months
recommended. Depending on how many information for the calculation is
migrated.
Text fields regarding sources of internal and/or external information can be entered by
pressing the Texts button in the customer credit management screen:
Picture 22: Customer Credit Master Management – Control area texts


P 29 I 48
2.2.2 Credit Limit Extension based on Risk Category
Based on this risk category, an automatic credit limit can be assigned to the customer.
The credit line calculation relies on both local and standard factors.
Credit Limit Calculation Formula
Turn Over Last X Locally Defined X Company Matrix

12 months Factor X
Turnover and Factor X will define how much credit the customer needs in order to cover
his future purchasing requirements from Hilti (based on past purchases). The turn over
is a standard calculation factor. Company Matrix is standard but the percentages are
defined locally.
Customer Sizes are based on number of employees. The size class should be defined
according to the below table, and applies to all MO’s and all trades.
Reference to the field where the number of employees is entered in the Customer
master
No special class for KA (key accounts) or GA (global accounts) will be defined, as

these are size independent. They will be indicated by flags in the customer
master. ????
Size Class Employees

1 0-4
2 5-19
3 20-49
4 50-199
5 >= 200


P 30 I 48
Factor X will also be determined locally. This factor could include the average real days
the customer takes to pay divided by the number of days in a year or the official
payment terms of the customer. Below are some examples that can be chosen to
calculate the factor X (to be defined locally):
 (turnover last 12 months) * (average real days customer takes to pay) / 360
 (turnover last 12 months) * (official payment terms of the customer) / 360
 (turnover last 12 months)* 0.4 (or other)
For example, apply the following values to the calculation as shown in option 1.
 Customer’s turnover last 12 months = 50000

 Average Days to Pay = 75 Days
 Calculation: 50000 x 75 / 360 = 10416
See the below matrix to determine credit limit based on this customer size and risk class.
 Customer’s risk class = B2

 Customer Size = 4
Size Class 1 2 3 4 5
Risk Cat.
A1 150% 185% 220% 260% 300%
..
B1
B2 100% 120%
..
G7 50% 150%
 Calculation: 10416 x 120/100 = 12499
Based on this example, the customer would get an adjusted credit limit of 12499 based
on its company size and risk class.
To ensure every business need is met when defining all parameters, the minimum credit
limit will also be locally defined criteria for each risk category. This limit will be taken, as
soon as the calculated value is lower than the minimum value.
Explain minimum and maximum value


P 31 I 48
For a future release a Region Matrix will be added to the credit limit calculation. Region
Matrix is a local factor that is used to grant customers of certain regions a higher or
lower credit limit.
An example of a Region Matrix is shown bellow:
Credit Region code Region Name Credit Risk %

01 Schleswig-Holstein 100%
02 Hamburg 100%
03 Lower Saxony 100%
04 Bremen 100%
.. .. ..
14 Saxony 80%
15 Saxony-Anhalt 80%
16 Thuringia 80%
.
Based on the same example used before, assuming the customer belongs to Credit
Region 01, credit limit will remain the same as calculated above.
Credit Limit will not be calculated if …..

- Customer marked for exclusion
- Customer blocked by credit management
Minimum of G7 is the default for new customers
Add Transaction Code


P 32 I 48
2.2.3 Credit Checking Matrix
The type and scope of automatic credit checking is influenced by the following:
 Credit Control Area

 Risk category of the customer - (classifying attribute for your customers from the
viewpoint of credit risk which is maintained in FI).
 Credit groups - The document credit group is used to combine different business
processes that are treated in the same way with regards the credit check. Credit
groups are assigned to the sales document types and delivery types, for which a
credit check is to be carried out.
Each item category has been included in the credit functions (check and update of open
credit values).
Based on the customer master data established in the credit management area, a credit-
checking matrix automatically reviews entered orders.
1. Risk Class
2. Credit Limit
3. Credit Check
Picture 23: Credit checking structure


P 33 I 48
2.2.3.1 Points at Which a Credit Check can be carried out
Order
Credit Control
Credit status: Blocked
General
Rule
Subsequent functions in Sales

and Shipping cannot be carried
out as long as order is blocked by
a credit check.
Picture 24: Point at which a credit check can be carried out
Exception: Repairs orders where a credit check will also be carried out at the time of
the delivery and could result in a credit block. Although a credit check for repairs orders
will also be performed at order entry, only a warning message will be generated in case
credit check fails.
2.2.3.2 Overview of Credit Check Types

Picture 25: Credit checks types
Overview of Check Types
Company Code Customer Transaction type
Credit control area Risk Category Credit group
Automatic Credit Control

Static
Dynamic
Document Value
Critical fields
Standard SAP
Next checking date Credit control area
Open items
Oldest open items
Max. dunning level
FI checks
First payment default
Valid on day of printenhancement
H2.1 20/08/2007 12:55:00 - For internal use only -
Reversed payments
Weighted Average elapsed days 9494 Schaan Liechtenstein
Integration Test III
4 FCRag / 10.6.02

P 34 I 48
An automatic control matrix needs to be defined per each risk class in the customer
master data. Different variants within these areas are assigned based on the risk class.
For example, the document value may be less or more based on the risk. The oldest
open item ranges from 120 days on better risk classes to 30 days on poorer risk classes.
The matrix defines, depending on the ‘Yes/No’ answers, whether an order is approved
or declined for shipment.
The rules for the different criteria per risk class (e.g. max. document value for customer
of risk class A1) for the automatic control matrix are to be set locally in the IMG module,
as shown in the attached table:
Picture 26: Credit checking matrix controls


P 35 I 48
To select the required credit check for a specific risk class just click the proper box
besides the name’s field. The following system reactions can be indicated as shown in
the attached table:
Picture 27: Credit checking structure
Please note that system reactions for credit checking to be used should be either A or C.
Do not attempt to use reactions B or D because it will result in an system error and
subsequent orders of sales and shipping will not be able to be performed.
To select the option to block an order after credit check has been performed for an
specific credit check type, just click the proper action box. Otherwise, only a warning
message will be generated and order will not be blocked for credit review.


P 36 I 48
Static and Dynamic Checks

CCA Risk Category Operat. Static X or Dynamic X
A Static B Dynamic
Orders Limit
Orders
deliveries deliveries
Billing docs Billing docs
Receivables Receivables
DEC JAN FEB MAR Time

Actual date
+ 2 Months
Credit horizon + 3 Months

6 FCRag / 10.6.02
Picture 28: Static and Dynamic Credit checks
The customer credit exposure can be divided into static part (open items, open billing
values and delivery values) and dynamic part (open order value).
 The open order value comprises all partially delivered or undelivered orders. It is
accumulated for the material availability date within an information structure in freely
definable units of time or period (day, week, month).
 When defining the credit check, you specify a certain number of the corresponding
periods from which date will be determined in the future.
 This makes sure that sales orders are planned in the future are not taken into
account when determining credit exposure.
The “actual date” in this example is the initial date for determining the open order value
on the credit horizon. The “actual date” is the current date for each week. In an order, it
is the date on which the order is created or changed.


P 37 I 48
Checking Against Maximum Document Values

CCA Risk Category Operat. Max. document value EUR 6.000 X
CUSTOMER: XYZ Corp
Material 10 EUR 2.000

EUR 12.000 Maximum

document value!

7 FCRag / 10.6.02
Picture 29: Credit checks against maximum document value
The sales order or delivery value may not exceed the specific value defined in the credit
check. This value is stored in the currency of the credit control area. It is particularly
applicable if a credit limit has not yet been defined for a new customer. You can initiate
this check using a risk category defined for new customers.


P 38 I 48
Checking Against Changes in Critical Fields

CCA Risk Category Operat. Critical fields X
Payer master record Order
XYZ Corp Customer: XYZ Corp

Copy Terms of X X Cash disc.
2%, 1%
Terms of payment: 2%, 1% to order payment
3%, 2% Cash disc.
Cash disc.
Fixed value date
Additional value days

8 FCRag / 10.6.02
Picture 30: Credit checks against changes in critical fields
Payment conditions, fixed value date and additional fixed value dates are defined as
critical fields. This check is used to monitor changes to this default data in the customer
master record.
Checking Against Next Review Dates

Next check date: X
CCA Risk Category Operat.
+ 10 days
CCA data Order
Customer: XYZ Corp. Customer: XYZ Corp. OK
ed
Next check date: 01, June Entry date: 09, June
d
m en
com
re
Customer: XYZ Corp.
t
No
Change date: 13, June

9 FCRag / 10.6.02
Picture 31: Credit checks against next review date


P 39 I 48
Here, you do not have to specify a number of days. Without these “buffer days”, the
system will carry out the check as soon as it recognizes that the next check date has
been reached
The next credit review date is stored in the credit data in the customer master record.
When you process a document, the next credit review date must not be beyond the
current date.
Checking Against Open Items

Open Items: X
Max. Open items: 20%
Number of days: 30
Account balance XYZ Corp.

Debits EUR 100.000
Credits EUR 70.000
Balance EUR 30.000 = 100%
Line Items XYZ Corp.

Days in arrears Amount
< 30 days 10 EUR 3.000

20 EUR 6.000
30 EUR 5.000
32 EUR 10.000
> 30 days EUR 15.000 =
40 EUR 5.000 50%

10 FCRag / 10.6.02
Picture 32: Credit checks against open items
The relationship between open items that are more than a certain number of days
overdue and the customer balance may not exceed a certain percentage.
Days in arrears apply from the baseline date for payment, in other words if the terms of
payment are 30 days net, then the system only starts to calculate in arrears in 30 days
time.
This type of credit check works in conjunction with two values that you specify in the
adjacent fields:


P 40 I 48
 Maximum % of overdue items in open items

 Number of days which the open items are overdue
The proportion of overdue open items (that exceed the specified number of days) in the
total of open items should not exceed the percentage specified.
Checking Against Oldest Open Items
CCA Risk Category Operat. Oldest open items: 20 days X

Days in arrears Amount
20 days 10 EUR 3.000
20 EUR 6.000
30 EUR 5.000
32 EUR 10.000
40 EUR 5.000

11 FCRag / 10.6.02
Picture 33: Credit checks against oldest open item
Indicates whether the system carries out a credit check based on the age of the oldest
open item.
By specifying the number of days, you can determine by how many days the oldest open
items may be in arrears.


P 41 I 48
Picture 34: Credit checks against maximum dunning level
Checking Against the Maximum Number of Dunning Levels
CCA Risk Category Operat. Max. dunning levels 3

Dunning levels 1 2 3 4
Days in arrears 2 16 30 44
Interest: x x
Customer: XYZ Corp.
Company code: 1000

Dunning levels: 4

12 FCRag / 10.6.02
With this type of credit check, you specify the highest dunning level you want to allow in
the adjacent field. The dunning level is tracked and stored in the credit data in the
customer master record. If this level is exceeded during order or delivery processing, the
system carries out a credit check. Credit check for maximum dunning level is performed
against any open invoices in the customer balance.


P 42 I 48
2.2.3.2 Additional Credit Checks
 Credit checks during header/item processing: By clicking this box in the

document controlling area, it indicates that the system carries out credit checks not
only when you save the document but already when you enter single items or header
data.
 Credit limit seasonal factor: Specifies a percentage tolerance limit up to which a

customer's credit limit may be temporarily extended or reduced. If date range is
assigned to cover the whole year, this credit check field could be easily used to
specify a tolerance level for a certain risk category.
Example:
If you enter 5% in this field and select the < Minus
field, a customer's usual credit limit of 10,000 USD is
extended by a further 500 USD.
 Release documents are still unchecked: specifies a deviation factor or number of

days that will trigger a document already approved or released by credit department
to be re-checked. There are basically two credit checks:
 Credit check: Deviation of document value by x %: Specifies a deviation

factor for documents that have already been approved for credit.
Example
You set the deviation factor at 10%. An order for
10 boxes of a material (price = 100 USD per
box) has a total value of 1,000 USD and is
approved for credit. The customer then calls
and wants to add additional boxes to the order.
If this causes the deviation factor to exceed
10%, the system carries out another credit
check.
 Credit check: Number of days without check: Specifies the number of days
after which a changed document must be re-checked for credit.
Please note that this function is used for checking documents that have
already been released by a credit representative, but that have subsequently
been changed. The system does NOT carry out another credit check if the
following conditions are met:


P 43 I 48
 The value of the changed order is not greater than the value already
approved for credit (inclusive of the deviation factor), AND
 The current date is not greater than the original release date plus the
number of days specified here.
Checking with the Current Payer

Oldest open items: 10 days
Payer: X
Customer: XYZ Corp. (HQ)

Credit account: XYZ Corp. (HQ)
Customer: XYZ Corp. (Branch A) Customer: XYZ Corp. (Branch B)

Credit account: XYZ Corp. (HQ) Credit account: XYZ Corp. (HQ)
XYZ Corp. (HQ) XYZ Corp. (Branch A) XYZ Corp. (Branch B)

Days in arrears Days in arrears Amount Days in arrears Amount
Amount
5 5 EUR 3.000 5 EUR 3.000
EUR 3.000
7 7 EUR 6.000 7 EUR 6.000
EUR 6.000
12 EUR 5.000
Order OK
SP: XYZ Corp. (Branch B)
PY: XYZ Corp. (Branch B)
Checking with All Payers 15
FCRag / 10.6.02
Picture 35: Credit checks against payer Oldest open items: 10 days
Payer: X
The “payer” parameter is relevant when credit data for several customers is managed in
Customer: XYZ Corp. (HQ)
a common credit account.
Credit account: XYZ Corp. (HQ)
The indicator controls whether the system checks the payer in the current transaction or
all customers belonging to (Branch
Customer: XYZ Corp. the common
A) credit account
Customer: XYZwhen carrying
Corp. (Branch B) out FI-relevant
checks (open items, oldest open items, maximum dunning level).
Credit account: XYZ Corp. (HQ) Credit account: XYZ Corp. (HQ)
XYZ Corp. (HQ) XYZ Corp. (Branch A) XYZ Corp. (Branch B)

Days in arrears Days in arrears Amount Days in arrears Amount
Amount
5 5 EUR 3.000 5 EUR 3.000
EUR 3.000
7 7 EUR 6.000 7 EUR 6.000
EUR 6.000
12 EUR 5.000

Order
SP: XYZ Corp. (Branch B) 9494 Schaan Liechtenstein
PY: XYZ Corp. (Branch B)
16 FCRag / 10.6.02

P 44 I 48
Picture 36: Credit checks against all payers

Additional credit checks in the following areas will also be available for H2.1:
 Reversed payment: Any returned checks or promissory notes that have been
reversed from the customer account
 First payment default: New customers must cancel first sales before placing a new
sale order to avoid a credit check to be performed. Only applicable for new
customers.
 Weighted average elapsed days: The number of days the system calculates is an
average value of the days in arrears of all paid items. The days in arrears are
weighted with the posted amount.
Example:
An invoice for 1,000 is paid in 10 days. Another invoice for 3,000 is
paid in 6 days.
The average arrears are calculated as follows:
(10 * 1000 + 6 * 3000) / (1000 + 3000) = 7 days.
2.2.4 Remove Holds on Blocked Sales Documents
When an order is blocked, it must be reviewed to determine if additional sales can be

extended to the customer. The available credit is a key criterion for the decision if an
order is approved or declined for shipment.


P 45 I 48
There is a credit management exceptions report that is ran to show blocked sales
documents. Refer to transaction code VKM1 – Blocked SD Documents by navigation
path Accounting, Financial Accounting, Accounts Receivable, Credit Management,
Exceptions.
Determine the search criteria by which you want to view blocked orders. Following are
the categories on which blocked orders can be viewed:
 Credit Control Area

 Credit Representative Group
 Next Ship Date
 Credit Account
 Risk Category
 Customer Credit Group
Execute the query to generate the list of orders that are currently on blocked status.
From this report, there are multiple navigation options that can be used for more
customer or order detail.
Additional information and procedural steps for review and release of blocked SD
documents can be found in the following BPP (Business Process Procedure):
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VKM1_View_Blocked_SD_Docs.doc
Another useful transaction screen to review SD documents can be found in transaction

code VKM4 – where further search criteria can be applied when searching for an specific
sales order or delivery from a customer. One important feature of the transaction is the
possibility to search for SD documents which have not yet been processed or have been
partially processed, as well, as completed processed. Additional information and
procedural steps for review and release of blocked SD documents can be found in the
following BPP (Business Process Procedure):
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_VKM4_All_Blocked_SD_Docs.doc
2.2.5 Blocked Order Review

Double click on the SD Document number, you are taken to VA02 to view or update the
order details. Double click on the customer account number, the address details will be
displayed. However it is through the main toolbar option of Environment that the most
detailed information can be accessed.


P 46 I 48
Picture 37: Blocked order review menu
Through Document flow, you can see the document, document status, document flow,
and document changes related to Sales and Distribution documents. Released and
Blocked documents will be displayed at the customer level based on the account
number that is chosen.
The next options available from Environment are found in Logistics as well as Finance.
Customer Master returns you to VD02 – Change Customer where General and Sales
Area Data are stored. Customer Master Credit provides access to FD32 for Control
Area Data, Overview, and General Data. Credit Overview is transaction code VKM2.
Open Sales Values will display both open sales orders or open deliveries/billing
documents.
After review, the order can be released for shipping, forwarded for authorization, or can
be rejected.
All of the above features are designed to allow you to monitor accounts and limit risk and
exposure. By determining a customers credit extension worthiness and applying the
appropriate master data; risk category, credit limit, limit per order, etc, the system is able
to assist in risk management.
2.2.6 Other useful transaction codes
Other useful transaction codes related to credit management are:


P 47 I 48
2.2.6.1 Transaction Code F.31 Credit overview
Navigation path: Accounting  Financial Accounting  Accounts Receivable  Credit

Management  Credit Management Info System Overview
Use this transaction to generate a credit data list to display an overview of the customer
master data needed for credit management for a customer.
Additional information and procedural steps for transaction F.31 Credit overview can be
found in the following BPP (Business Process Procedure)
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_F.31_Credit_Overview.doc
2.2.6.2 Transaction Code F.33 Credit Management Brief overview

Management  Credit Management Info System BriefOverview
This report checks the data for the credit limit for completeness, and produces the
corresponding error lists. The credit master sheet enables you to display and print out
the customer master data for a single account, which is needed for the area of credit
management. The early warning list enables you to display and print out customers in
credit management, who are viewed as critical customers in the area of credit checks in
SD.
Additional information and procedural steps for transaction F.33 Credit Management
Brief overview can be found in the following BPP (Business Process Procedure)
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_F.33_Credit_Management_Brief_Overvi
ew.doc
2.2.6.3 Transaction Code F.35 Credit Master Sheet
Navigation path: Logistics  Sales and Distribution  Sales Information System 

Environment  Master data Credit management
Used to display and print the customer master data of an individual account, which is
needed in the area of credit management. It can thus be used for information and
documentation. You can also call up this function in the Accounts Receivable menu from
the line item display or the account analysis.
Additional information and procedural steps for transaction F.35 Credit Master Sheet can
be found in the following BPP (Business Process Procedure)


P 48 I 48
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_F.35_Credit_Master_Sheet.doc
2.2.6.4 Transaction Code F.32 Customers with missing credit data

Management  Credit Management Info System
When establishing a customer account, some fields of data may be unintentionally

omitted. This report will review accounts and determine any that are missing credit data.
This data includes both central data and control area data. Once the customer accounts
are identified, the missing data can be distinguished and the information can be input
Additional information and procedural steps for F.32 Customers with missing credit data
can be found in the following BPP (Business Process Procedure)
..\..\..\Live_Documents\Finance\H2_Transactions_BPP\BPP_H20_F.32_Customers with missing credit

data.doc


H2.8.1 User Documentation Billing

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

H2.8.1 User Documentation Billing

Uploaded by

Copyright:

Available Formats

Global Process Management System

BILLING & CREDIT RISK MANAGEMENT

Valid on day of print 20/08/2007 12:55:00 - For internal use only -

Process: F-7 Billing Billing & Credit Risk Management

2.2 Credit Risk Management........................................................................................24

Valid on day of print 20/08/2007 12:55:00 - For internal use only -

Process: F-7 Billing Billing & Credit Risk Management

Chapter Comment Release

Valid on day of print 20/08/2007 12:55:00 - For internal use only -

Process: F-7 Billing Billing & Credit Risk Management

2.1.1 Billing Overview

General rules for billing:

Valid on day of print 20/08/2007 12:55:00 - For internal use only -

Process: F-7 Billing Billing & Credit Risk Management

Picture 1: Billing document structure

2.1.1.1 Invoice split criteria MO’s

Setting in customer master data

Valid on day of print 20/08/2007 12:55:00 - For internal use only -

Process: F-7 Billing Billing & Credit Risk Management

The order is steered about

Setting by sales order

Valid on day of print 20/08/2007 12:55:00 - For internal use only -

Process: F-7 Billing Billing & Credit Risk Management

2.1.2 Standard Billing Transactions

 Creating a billing document (manually): VF01

 Change a billing document: VF02

 Display a billing document

Valid on day of print 20/08/2007 12:55:00 - For internal use only -

Process: F-7 Billing Billing & Credit Risk Management

The user can display any billing document at any time.

 Processing Billing Due Lists: VF04

 List of billing documents: VF05

 Billing in the background: VF06

 Display a billing document from Archive: VF07

Valid on day of print 20/08/2007 12:55:00 - For internal use only -

Process: F-7 Billing Billing & Credit Risk Management

2.1.3 Special Billing types

 transactions involving credit cards

Transaction code: VF11

2.1.3.2 Credits to customers

Credits to customers can be issued for the following reasons:

Valid on day of print 20/08/2007 12:55:00 - For internal use only -

Process: F-7 Billing Billing & Credit Risk Management

Case Order Type Text

Transaction code: ZCCN

Transaction code: VA01

2.1.3.3 Invoice correction

Valid on day of print 20/08/2007 12:55:00 - For internal use only -

Process: F-7 Billing Billing & Credit Risk Management

Invoice Correction Debit /Credit

Item 20 Credit 1155 20 Billing Item 2

Generate Invoice Correction Request

Valid on day of print 20/08/2007 12:55:00 - For internal use only -

Process: F-7 Billing Billing & Credit Risk Management

2.1.3.4 Debit memo

Transaction code: VA01

Valid on day of print 20/08/2007 12:55:00 - For internal use only -

Process: F-7 Billing Billing & Credit Risk Management

Also here: No COGS posting, only revenue accounts affected.

2.1.4 Invoice List

 An invoice list represents an individual billing document but no accounting

Valid on day of print 20/08/2007 12:55:00 - For internal use only -

Process: F-7 Billing Billing & Credit Risk Management

Double click as above red rectangle.