Accounts Payable: Global Process Management System

Global Process Management System
User Documentation
Process : F-4 Accounts Payable Accounts Payable
Approval Date: 01.08.2006 Review Date: 01.02.2007
Written By: Andreas Hehle Approved By: Andreas Hehle
P 1 I 89
Accounts Payable
Valid on day of print 17/07/2006 12:11:00 - For internal use only -

9494 Schaan Liechtenstein
Process: F-4 Accounts Payable Accounts Payable

P 2 I 89
Inhaltsverzeichnis
...........................................................................................................1
Accounts Payable................................................................................................1
4 Accounts Payable................................................................................................5
4.1 Master Data........................................................................................................ 5
4.1.1. Account Groups............................................................................7
4.1.2. Vendor Numbering.......................................................................9
4.1.3. Authorization for Vendor creation...............................................10
4.1.4. Naming Conventions..................................................................10
4.1.5. Content of the Vendor Master Record........................................11
4.1.6. Creating a Vendor Master Record..............................................21
4.1.7. Change a vendor master record.................................................23
4.1.8. Display a vendor master record..................................................23
4.1.9. Displaying Changes to Vendor Master Records.........................25
4.1.10. Blocking a Vendor Account........................................................25
4.1.11. Marking a Master Record for Deletion........................................27
4.1.12. Compare vendor master data.....................................................27
4.2 Process voucher..............................................................................................27
4.2.1. Invoices and credit memos without PO (without reference):......31
4.2.2. Invoice posting...........................................................................31
4.2.3. Credit memo...............................................................................32
4.2.4. Parking Documents....................................................................32
4.2.4.1. Park/edit invoice.....................................................................33
4.2.4.2. Park/edit credit memo............................................................33
4.2.4.3. Payment request....................................................................37
4.2.4.4. Invoice general (in exceptional cases only)............................38
4.2.4.5. Posting Documents in Foreign Currency................................39
4.2.4.6. Travel expense.......................................................................39
4.2.4.7. Posting of manual price deviation..........................................41
4.2.4.8. Complex posting (input tax customs for imported materials)..47
4.2.5. Invoices and credit memos with PO (with reference):................47
4.2.5.1. Incoming Invoice....................................................................48
4.2.5.2. Park invoice (related to PO)...................................................56
4.2.5.3. Subsequent Credits................................................................56
4.2.5.4. Quality management..............................................................57
4.2.5.5. Fright cost calculation concept...............................................57
4.2.5.6. Display Invoice document......................................................58
4.2.5.7. Cancel document...................................................................58
4.2.5.5.1 In Finance.................................................................58
4.2.5.5.2 In Logistic.................................................................61
4.2.5.8. Blocked invoices.....................................................................61
4.2.5.9. Release blocked invoices (MRBR):........................................65

P 3 I 89
4.2.6. Evaluated Receipt Settlement (ERS).........................................69

4.3 Outgoing Payments.........................................................................................73
4.3.1. Executing the Payment Program................................................73
4.3.2. Planning and Parameter Specifications.....................................75
4.3.3. Creating the Payment Proposal.................................................75
4.3.4. Evaluating the Exception List.....................................................77
4.3.5. Running the Payment and Payment Medium Programs............78
4.3.6. Payments to HAG or IVV............................................................80
4.4 Down payments...............................................................................................81
4.4.1. Down Payment Requests (F-47)................................................83
4.4.2. Clearing Down Payments (F-54)................................................84
4.4.3. Security Deposit.........................................................................86
4.5 Financial Information System.........................................................................87
4.6 GR/IR Clearing Account Maintenance...........................................................88


P 4 I 89
Current changes
Naming conventions for postings IC-
Service Received
Release blocked invoices
Account group ZPRO
Freight cost calculation concept
Quality management
Security deposit
Payment blocks (additional information)
Evaluated Receipt Settlement H2.8.1
Complex posting (input tax customs)
4 Accounts Payable
4.1 Master Data
Vendor master data creation
Objective
To gain knowledge about:
 Account group
 Number range
 Authorisation
 Naming convention
 Content of a vendor master data
 Maintaining data
You must create a master record for each account that you require. The master record
controls how business transactions are recorded and processed by the system.
The concept of vendor master data describes how to create, display, change, block,
and delete vendor master data. A request to create a vendor master record is initiated


P 5 I 89
by purchasing or accounting. Case by case, it has to be decided whether and how a

new vendor account shall be opened.


P 6 I 89
Data migration
With our implementation of the new SAP R/3 system we also have the strategy to have
Hilti world wide one global vendor master.
That means that every implementing or already implemented Market Organisation and
of course Headquarter & plants have to migrate their vendor master data to P11/100.
But before this could happen you have to clean the data in the “old” system and check
it against H2 vendor naming convention, if it’s already created from an other Market
Organisation and so on.
4.1.1. Account Groups
A master record depends on the account group. The account group cannot be changed
after the master record has bee created.
Following account groups are defined and available:
Table 1: Account Group with description
Account Description
group
ZCPD One time account (6 000 000)
Centrally created vendor number (global) for:
 One time purchase orders
 One time invoices, for which the vendor is not created in the system
Note: If vouchers from a „one time vendor” are entered several times, this
one time vendor has to be changed to a normal one (with account group
ZVEN!)

P 7 I 89
ZEMP All employees which have travel expense

ZHIL All Hilti internal vendors (e.g. HAG, IVV, Plants, MO’s) Frango numbers
ZVEN All Hilti external vendors (e.g. Allied vendors, DP-vendors, MRO-vendors,
national vendors...)
ZPLA All Hilti internal ship from addresses (external alphanumeric number)
ZPRO All Hilti material producer used for “origin declaration”
Account group ZCPD and ZHIL will be created and then maintained centrally by
Hilti AG!
For account group ZVEN there is a difference between local vendor and global vendor.
Each vendor, which is a direct productive (DP) vendor or delivers more than one Hilti
Marketorganisation has to be created centrally in Hilti AG.
Request_for_NEW_HAG_Vendor_en.doc
Request_for_NEW_LOCAL_Vendor_en.doc


P 8 I 89
4.1.2. Vendor Numbering
Table 1: Authorisation with description
Account group Range Created by

ZCPD 6 000 000 System internal
ZEMP 7 000 000 to 7 999 999 System internal

ZHIL 1 000 to 9 999 User (external)
ZVEN 1 000 000 to 5 999 999 System internal
ZPLA H(Country code) User (external)
+Plantnumber z.B. HAT0010
ZPRO 1 000 000 to 5 999 999 System internal
The system ensures that the numbers assigned are always unique. With internal
assignment, the system selects the next number from the interval. With external
assignment, the system prevents you from entering the same number twice.
A vendor account has the same number for all company codes!


P 9 I 89
4.1.3. Authorization for Vendor creation
Table 3: Authorisation with description
Account group Requester Authorisation Responsibility Process

ZCPD Purchasing / Basic data can be created Corporate According Vendor
One time account Finance only centrally. Purchasing / creation
Finance
ZEMP Human Basic data can be created Local HR / According HR
Employees Resource in general locally. Finance Employee creation
ZHIL Corporate Basic data can be created Corporate According
Hilti intern Logistics only centrally. Purchasing / Vendor creation
vendors / Finance Finance
ZVEN Corporate and Basic data will be created Corporate According
Hilti extern local strategic according the process Purchasing / Vendor creation
vendors purchasing „Check for local vendor Finance
/ Finance creation“
ZPLA Corporate and Corporate According
local purchas. Logistics Vendor creation
ZPRO Corporate Corporate According
purchasing. Purchasing Vendor creation
4.1.4. Naming Conventions
It is very important that everyone, who is authorised to create a vendor, is following a

guideline because of unique search function and to avoid double creation of the same
vendor.
Vendor naming convention.doc


P 10 I 89
4.1.5. Content of the Vendor Master Record
A vendor master record contains:

 Vendor’s address (name, postal code, city, country, region, language, and
phone/fax numbers
 Control data (Authorization, VAT reg.no. for EU countries, Industry key,..)
 Bank details (Country, Bank key, Bank account)
 Account information (reconciliation account, Sort key, Cash mangmt. group)
 Payment transaction (methods and terms of payment, check double inv.)
 Correspondence (dunning procedure, dunning clerk, accounting clerk) and
 Purchasing data (Order currency, terms of payment, Incoterms, Pricing date
cat., purchasing group)
 Partner functions (ordering address, vendor, invoice presented by, goods
supplier)
The master record is used not only in Accounting but also in Materials Management.
You have two different possibilities to create a new vendor:
a) create a vendor centrally or
b) create a vendor in MM (purchasing view) and in FI (accounting view) seperatley
For all cases, with which purchasing is involved, there must be an immediate
information flow between the Purchasing department and the Finance
department to ensure that Finance can add their information without delay.
For more information about the purchasing view please see the documentation
of SC Purchasing about vendor creation.


P 11 I 89
How is the Data Organized?

Master records are divided into the following areas so that each company code and
each purchasing organization can store their own information for doing business with
vendors.
1. General data
This is data that applies to every company code and every purchasing
organization in the Hilti group. The general data includes the vendor’s address,
control tab and the bank details.
2. Company code data
This is data that is specific to an individual company code. This data includes
Account information, Payment transaction, Correspondence.
3. Purchasing organization data


P 12 I 89
This is data relevant to the purchasing organization of our company (purchasing

data, partner functions). Also the invoice verifications are stored in this section.
Special Fields in Vendor Master Records

The following fields in vendor master records have special functions:
 Search Term: Vendor Master Records
 Alternative Payee
 Affiliated Companies: Vendor Master Records
 Clearing Between a Customer and Vendor
 Group: Vendor Master Records
 Accounting Clerk: Vendor Master Records
Search Term: Vendor Master Records


P 13 I 89
If you do not know a vendor account number, you can search for the vendor master
record using certain fields in the master record. The most famous search term is to use
the vendor's name. Our system uses the search term field, which is independent of the
name and address fields, for this type of search. A search term is required since the
vendor's name for search functions is formulated differently from how it is formulated in
the address.
There exist rules on how to enter this field to keep it consistent. The search term
usually consists of only the most important parts of a vendor’s name.
For more information see again chapter 4.1.1.4
Alternative Payee
The payment program can make payments to a vendor other than the one to which the
invoice was posted. Payment is made to an alternative payee, which must be specified
in the master record.
If you specify an alternative payee in both areas (general and company), the
specification in the company code area has priority.
To always make vendor payments to an alternative payee, proceed as follows:

Create a 2nd vendor master record for the alternative payee. Block this account for
posting.
Specify in the 1st vendor master record the account number of the alternative payee in
the “Alternative payee” field within the “payment transaction” section of the vendor
master record.


P 14 I 89
When making payments to this vendor, the payment program will always access the
name and address of the alternative payee.
In some instances it may be better to specify a payee in the document. To do this, you
have to activate this function by selecting the payee in document indicator in the
general data area. When you enter documents for this account, the system displays a
field in which you can enter an alternative payee.
If you activate the “individual spec.” button you can when you are entering a document
pay to another “vendor” if it is an exception case! A pop up menu will be displayed
where you can enter the data. This pop up is like the CPD account!!)
If you enter a document you get a separate field on the payment tab.


P 15 I 89
The system always uses the payee, which is most specific. This means that when you
enter a payee in a document, it has priority over payees specified in the master record.
Another possibility is if you have several alternative payees you can put it into a table in
the master record.


P 16 I 89
If you post a document you have the possibility on the payment tab to select under
payee the correspondent vendor.
To get the following result
Press first the “permitted payee”. A pop up menu will be displayed where you can enter
several payees
If you are processing a document you can choose on the payment tab the
correspondent payee.


P 17 I 89
Affiliated Companies: Vendor Master Records (only relevant between Hilti

organizations!)
If invoices are sent to companies, which are members of your consolidation group, you
have to include these companies in consolidation. All payables and receivables
originating from business transactions within the corporate group have to be
eliminated. To enable the system to eliminate these revenues, you need to specify a
standard, corporate-wide company ID (same number as Company Code!) in the
Trading partner field in every vendor master set up for an affiliated company. The
consolidation system uses this number to identify inter-company revenues and
expenses for consolidation purposes.
Clearing Between a Customer and Vendor

If a vendor is also a customer, or vice versa, you can have the payment program and
the dunning program clear the vendor and customer open items against each other.
You can also select the customer line items when you display the vendor line items for
this account.
Before clearing items between a vendor and customer account, you must
create a customer master record for the vendor.
Customer:
During the creation process of a customer master please enter the vendor account
number on the vendor field in the control section of the general data on the customer
master record. Activate the field “Clearing with vendor” on the company code data
(payment transaction tab).
Save the customer master. The system automatically updates the vendor master
record! The new created customer number will be automatically filled in into the
customer field in the control section of the general data of a vendor master record.


P 18 I 89
The only things which an AP clerk has to do is, to activate the field “Clearing with
customer” on the company code data (payment transaction tab).and add on the
vendor master record the payment method “V”.
Each company code can decide separately whether it wants to clear the
customer with the vendor or not.
Assigning Master Records to Dunning & Accounting Clerks

Assign a specific dunning/accounting clerk to vendors for processing their master data.
In most MO’s the dunning and accounting clerk is the same person!
The dunning/accounting clerk’s name is then printed in any correspondence with the
vendors. Dunning lists and payment proposal lists are sorted by clerk.
Enter the accounting clerk’s ID in the master record.
You have to enter 01 or 02,... depending on which clerk should be mentioned on the
letter. This number is always followed by the personal ID. Therefore, whenever there is
a job rotation you have to inform your IT department to change the user ID!
Picture 1: dunning clerks for e.g. Austria (SAP customizing)
Functions for Maintaining Vendor Master Data

The following functions are available for processing vendor master records:
 Create (XK01, FK01)
 Change (XK02, FK02)
 Display (XK03, FK03)
 Block/unblock (XK05, FK05)


P 19 I 89
 Mark for deletion/remove mark (XK06, FK06)
Selecting Screens to Display Vendor Master Data

You can select certain individual screens when you want to display or change
information in the vendor master record (screen selection). Instead of having to go
through every screen, you go directly to the necessary screen.
4.1.6. Creating a Vendor Master Record
Both the accounting and purchasing departments have access to a vendor master
record.
 Create/Change/Display data centrally (general data, company code, and
purchasing data) all transactions beginning with X (XK01, XK02,..)!
 Create/Change/Display accounting data only (general and company code data) all
transactions beginning with F (FK01, FK02,...)!
 Create/Change/Display purchasing data (general and purchasing data) all
transactions beginning with M (MK01, MK02,..)!
Your authorizations determine the functions you have to use.

You can create/change/display either the general data (name, address) and company
code data (the accounting data), or the entire vendor master record (with purchasing
data).
People in the purchasing department can change/display the data about general data
and purchasing data.


P 20 I 89
Vendor master records are used by both the Accounting component and the
Purchasing component. Before you create a vendor master record in Accounting, you
need to make sure that the master record is not already created in Purchasing. You
can use the system’s search facilities to do this. You can also switch on the automatic
duplication check to ensure that users do not create the same master record twice.
Creating a vendor master record centrally involves entering data for both
Accounting and Purchasing in one step.
Special Features in Data Entry

When you create a vendor master record, you must enter certain data in special entry
screens. This is data you need to enter in exceptional cases only. This data includes:
 Bank data, in cases where there is no bank master data yet
 Dunning procedures
 Texts
 Documents
 The system also offers a special selection function for entering payment methods.
Entering Bank Details

For each vendor, you can specify as many banks as required. To pay a vendor by bank
transfer using the payment program, you must enter the vendor's bank country, bank
key, and bank account number in the vendor master record. For control purposes, the
system then displays the bank name data.
When you enter a vendor's bank address, the system checks whether master data
already exists for this bank. If not, the system displays the maintenance screen for


P 21 I 89
bank master data. You maintain a vendor's postal giro accounts in exactly the same
way as other bank accounts.
Entering a Payment Method

You can enter payment methods in the payment transactions screen for company code
data. Each payment method is represented by a single letter or number.
If you already know the characters for payment methods, enter one or more in the field
Payment methods.
If you do not know the characters, choose the possible entries button (F4) in order to
display the values you can enter. Select the payment methods you require from this
list.
The system transfers the selected payment methods to the field Payment methods.
You can overwrite these specifications.
If you enter a specific payment method in the item to be paid, then this specification
has priority over the entry, which has been made in the master record. You may also
enter payment methods, which are not listed in the master record in the item.
Entering a Dunning Procedure

For ZVEN, ZCPD and ZEMP, you have to enter a dunning procedure called ZVEN for
your vendor in the screen for correspondence. This dunning procedure is used for the
standard dunning area. If you connect a vendor with a customer you also have to
change the dunning procedure to ZSTX!
We do not support the account group ZHIL with the dunning procedure!!!
4.1.7. Change a vendor master record
Transaction code: XK02 Change vendor centrally

Link to BPP


P 22 I 89
Transaction code: FK02 Change vendor accounting

Link to BPP
4.1.8. Display a vendor master record
Transaction code: XK03 display vendor centrally

Link to BPP
Transaction code: FK03 display vendor accounting
Link to BPP


P 23 I 89
4.1.9. Displaying Changes to Vendor Master Records
When you change a master record, the system logs these changes and generates
change documents. For each field, it stores the time of change, the name of the user,
and the previous field contents.
You can display all the changes for the following:
 A certain field
 A master record
 For several vendor master records
 The following changes are displayed separately:
Overwritten field contents
Any bank details and/or dunning areas entered after the master record was
created
Any bank details and/or dunning areas that have been deleted
You can use following transactions if you want to see all changes, which were made on
this vendor account.
Transaction code: XK04 Vendor account change centrally

Link to BPP
Transaction code: FK04 Vendor account change accounting
Link to BPP
4.1.10. Blocking a Vendor Account
Within Accounts Payable, you can block a vendor account for posting. You have to
block a vendor master record before you can mark it for deletion. You would also block
a vendor that you use only as an alternative payment recipient, so that nobody can
post to it by mistake.


P 24 I 89
There are several fields in the vendor master record available to you. You can set the
following blocks:
 Posting block for certain company codes or for all company codes
 Purchasing block for certain purchasing organizations or for all purchasing
organizations.
It describes how to block a vendor account and blocking an account for the accounting
department only.
You can cancel a vendor account block at any time by removing the relevant indicator.
Only block an account if there are no more open items on the account. If an
account is blocked, you cannot clear any open items in it.
Blocking a Vendor Account for Payments

To block a vendor master record for the payment program or for manual payments, you
have to change the vendor master record. When you block the vendor account for the
payment program, the payment program still processes the open items in the account
during the payment run, but it does not pay any open items from the blocked accounts.
You can display a list of vendors blocked from the payment program.
To block a vendor for the payment program, enter a block key in the vendor master
record. These keys represent reasons for blocking. You use them to show why an
account was blocked.
Transaction code: XK05 Block/unblock vendor centrally

Link to BPP
Transaction code: FK05 Block/unblock vendor accounting
Link to BPP


P 25 I 89
4.1.11. Marking a Master Record for Deletion
After you mark a vendor master record for deletion, you can still post to the vendor
account. This is necessary, since you might still need to clear open items. When you
post, the system issues a warning that you are posting to an account that is marked for
deletion.
Transaction code: XK06 Mark for deletion vendor centrally

Link to BPP
Transaction code: FK06 Mark for deletion vendor accounting
Link to BPP
4.1.12. Compare vendor master data
You can check if the Finance data or Purchasing data is missing on an existing vendor.
The system will create a report, on which you can see by vendor, which view is
missing.
Transaction code: F.48 compare vendor master

Link to BPP
4.2 Process voucher
Objective
Check each incoming invoice and credit memo formally and post it according to the
content. There are two different ways for entering incoming invoices:
 With purchase orders (PO)(recommended - should cover the vast majority of all
invoices/business cases!)


P 26 I 89
Purchase of material
Material price: EUR 1,26/pc
Quantity: 100 piece
Info record: EUR 1,10
VAT: 20%
Goods receipt
Invoice receipt
Inventory 130000 C/S Price Variance 300812 Vendor 100000

2 0
126 16
132
Goods Receipt
GR/IR 290300 Input Tax 164000
110 110 22
Invoice
Advantage:
 Closed value cycle

 All business cases are covered (items & services)
 Easy handling to create purchase order
 Up-to-date information available (reminders, payments, reports)
 Low process costs
 Automatic accruals
 System calculates currency and price differences
 Etc....

P 27 I 89
 Without purchase orders – everything is manual and out of the system!!

E.g. for tax invoices, for fees like authorisations, work permits, telephone,
Purchase on work permits

Price: 1000 EUR
Social charge
- others 43210
0
1000 Vendor 1000000
1000
Invoice
Disadvantage:
 High process costs for each invoice

 No overview of turnovers
 No vendor concentration
 High running time
 Lost cash discount
 Loss of Hilti image caused by late payments
 Reminder receives Finance before invoice
 Incomplete balance and income statement (not all commitments from hilti are
included unpaid invoices, open orders,..)

P 28 I 89
 Release invoice manual with guiding principles

 No data in the system
 Accrual problem
Each incoming invoice has to be checked formally:

 Name & address (invoice with vendor data)
 Tax code/ tax amount (according to ship from & ship to)
 Tax identification number (specially for EU countries)
 Invoice amount (unit * price)
 Total amount (tax + net amount + charges)
 Payment terms (discount possibilities)
 Currency
And logical control:

 Whether it is a reasonable subject...
 Check of double booking/double invoicing by the vendor
 Whether it is not linked to a purchase order based on the subject text
General information about Input Tax in Vendor Line Items

The deductible portion of the input tax can be reclaimed from the tax authorities.
 Tax on purchases is deducted from amounts in G/L account items and not from
amounts in vendor items. Tax on purchases is input tax and is posted to a tax
receivable account.
Most countries have more than one tax rate on purchases. The tax return must include
a separate line for each rate. You must therefore enter a different tax code for each tax
rate.


P 29 I 89
If you need more Information about taxes please see chapter 6.8 Finance
Accounting
4.2.1. Invoices and credit memos without PO (without reference):
These transactions (FB60; FB65) are not considered to be best practice and therefore
should only be used in rare cases. Best practice business cases should be done within
Logistics -> Material Management (MM) -> Invoice Verification (MIRO)
When you choose one of these transactions (FB60, FB65 and F-43) there is no
link to a purchase order!! => no data is available and it is a manual procedure!
Naming conventions for expense account postings

When you enter a document you have always to fill out the text field on G/L line item
because this field is an information for the cost centre responsible person.
You always have to fill in the vendors name and a reference text. (E.g. Swiss
Telecom period 03/2002)
Naming conventions for postings IC-Service Received

When you enter a IC-document you have always to fill out not only the text field on G/L
line also you have to fill out the assignment field on vendor site and on G/L site
because this field is an information for further reporting and IC-reconciliation.
E.g.


P 30 I 89
4.2.2. Invoice posting
Objective
Check and post incoming invoices according local requirements.
Transaction code: FB60 post invoice
Link to BPP
4.2.3. Credit memo
Objective
Check and post incoming credit memos according local requirements.
Transaction Code: FB65 post credit memo.
Link to BPP
4.2.4. Parking Documents
Objective
Enter and store (park) incomplete documents for later completion.
Parked documents can be completed, checked, and then posted at a later date - if
necessary by a different accounting clerk.
When documents are parked, data (for example, transaction figures) is not updated.
Data from parked documents can however be used for analyses by the system. For
example, amounts from parked invoices can be used for payment requests and parked
invoices can be paid punctually without loss of discount.


P 31 I 89
Substitution is not supported in document parking. Substitution takes place via the
posting transaction after you generate an accounting document from the parked
document. You cannot park special G/L indicators for down payments.
You can also check the document for completeness (optional). For example, the
system checks whether the document balance is zero, and whether entries have been
made in all required entry fields (such as posting key and account number).
The authorisation checks carried out for document parking are basically the same as
those made for standard document entry and processing. This is sufficient to enable
you to assign authorisations, which differentiate between clerks who only have parking
authorisation and those who can post documents too.
No tolerance checks are carried out.
The system then carries out checks for erroneous entries. You can use account
assignment models when parking documents, but not reference documents.
Batch input is possible for parked documents.
4.2.4.1. Park/edit invoice
Objective
Park incoming invoice according local requirements and than contact the person who is
responsible for the invoice to get the information you need. After you have received the
information you require, you complete the parked document and post it.
Transaction Code: FV60 park/edit invoice:

BPP is the same as for FB60


P 32 I 89
4.2.4.2. Park/edit credit memo
Objective
Park incoming credit memos according local requirements and than contact the person
who is responsible for the credit memo to get the information you need.
Transaction Code: FV65 park/edit credit memo

BPP is the same as for BPP FB65.
Displaying Parked Documents
Transaction code FBV3 display parked document.

Link to BPP
Displaying Changes to Parked Documents (FBV5)
Changes to parked documents are logged and can be displayed both before and after
the document is posted.
The system then branches to a list of the changes made to the parked document. If
changes were only made when the document was parked and not once it was posted,
the system informs you, searches automatically for the changes to the parked
document, and lists them.
Posting Parked Documents (FBV0)
Using the standard transaction, you can post parked documents individually or use a
list selection. If you post several parked documents using a list, the system issues a list
after you have finished. This list show, which documents were successfully posted.


P 33 I 89
From this list, you can then carry out any necessary post-processing to parked
documents that could not be posted due to missing information such as a cost
accounting assignment. You can also create a batch-input session to post the parked
documents.
The data in parked documents is deleted when they are posted, a document is written
to the document database, and the appropriate data, (transaction figures etc.), is
updated. The number of the parked document is transferred to the posted document.
With this Transaction you can also delete the parked document.
Changing Parked Documents
You can change a parked document and complete it step by step. A large number of
header and item fields can be changed during this process, including the amounts.
You can make changes to:

 Individual documents
 Individual items
 Several documents simultaneously using a list
 Other values via the line items
However, you cannot change the currency and company code.
The internal system change rules governing document entry are not used in document
parking.


P 34 I 89
The old document number cannot be re-used when changes are made to the
document header, for example, to the posting date or fiscal year (by changing the
posting date).
Changing Documents
You can change documents that have already been posted. To do this, certain
conditions imposed by the system have to be complied with. This is necessary because
random document modifications can lead to problems, hampering reconciliation.
The system prevents the data in certain fields of a posted document from being
changed. These are fields such as the posting amount, account, posting key, fiscal
year, and tax amount. Because they fields have updated certain account balances
during posting, these fields cannot be changed.
All document changes are logged. This also applies to changes to sample and
recurring entry original documents.
Transaction code: FB02 change document

Link to BPP
Displaying Documents
Transaction code FB03 display

Link to BPP
Display vendor account
Objective


P 35 I 89
Call up vendor account to see vendor related information. You can see all open credits
and debits.
Transaction code: FBL1N Display/change line items

Link to BPP
4.2.4.3. Payment request
Payment requests are particularly useful for paying parked invoices on time and with
maximum cash discount, even when the invoice is not actually posted until after the
payment. Payment requests enable you to use a partial payment for an invoice that has
already been posted. If you do this, the invoice is blocked for payment and a payment
request is entered for the partial amount.
Payment requests are stored as noted items. This means that no transaction figures or
other totals are updated.
If payment requests, partial payments or credit memos have already been entered for
the line item you selected, the total of these amounts will also be displayed for your
information. The remaining amount is defaulted on the entry screen. If no such
amounts have been entered, the screen shows the total amount of the item in question.
Result
After posting, payment is triggered by the payment program.
You can cancel payment requests that cannot be executed any more by using the
Reverse document function, as long as they are blocked by a payment run or the
invoice has already been paid.


P 36 I 89
What is a payment Request?
Payment requests are noted items with which

 A complete or partial payment of parked invoices
 A partial payment of posted invoices
can be processed by the payment program.
You initiate the payment of a parked invoice if the invoice is correct as regards to the
invoice amount and the due date, but a posting has not yet taken place because the
offsetting accounting entries are still to be determined. To avoid lost cash discounts,
you pay before the invoice is posted.
Processing Payment Requests

When entering a payment request, you specify the number of the invoice to which the
payment should refer. Provided credit memos, partial payments or other payment
requests already exist for this invoice, the respective amounts are displayed in an
overview. The remaining amount is proposed for the payment request. You can
overwrite the amount as well as the other proposed data (payment method, house
bank, etc.). Posting keys, special G/L indicators and special G/L accounts for the
posting are defined by the system and are not entered.
The payment request is taken into account by the payment program in exactly the
same way as an invoice. The payment request is cleared after the payment run and a
partial payment is posted to the vendor account or customer account for the respective
invoice. If the invoice is paid in a later payment run, the respective partial payment is
cleared automatically.
Transaction code: F-59 Payment request

Link to BPP


P 37 I 89
4.2.4.4. Invoice general (in exceptional cases only)
This transaction is only used in exceptional cases. If you use this transaction you also
have to know the posting keys. E.g. Invoice about Input turnover tax.
Transaction code F-43 Invoice - general.

Link to BPP
4.2.4.5. Posting Documents in Foreign Currency
When you post a vendor invoice in a foreign currency, the system stores the amount in
both local and foreign currency for each line item.
For example, if you post a document on August 25, but the last exchange rate in the
system setting is from August 22, the system uses the exchange rate from the entry on
August 22.
To specify the foreign currency for your document, enter the appropriate currency key
in the Currency field in the document header.
Enter a posting date and the currency key in the document header. The system
automatically transfers the exchange rate valid on the posting date.
You can enter the amount in each line item in both local and foreign currency. By doing
so, you are indirectly specifying the exchange rate.
4.2.4.6. Travel expense
Objectives


P 38 I 89
Post incoming travel expenses to the correct G/L accounts and employee accounts.
Process flow
Technical background
We will have two different server one only for HR (P03) and one which includes
everything (MM, FI, HR, SD, PP,...) (P11). There will be an interface called ALE which
sends all master data from HR (P03) to HR (P01). From the HR (P03) all employee
master data which have the flag for “travel preveleges” (Matchcode for that is “0”) will
be send automatically by the system into a Batch Input report. The transaction which
runs in the background is PRAA. You can find this transaction under
Easy access menu  Accounting  Financial Accounting  Travel Management 

Person-related master data  PRAA Create Vendors
The system could do that daily! The AP clerk then calls up the Batch Input report,
select the respective report and execute it. In the background this Batch Input report
creates vendor master data with the account group ZEMP!
You can find this transaction under
Easy access menu  System  Services  Batch Input  Sessions
After that this person has to check the status of this report. Was it successful or faulty?
If it was faulty the person has to go into that report to see what’s wrong. After the error
was found and analysed the AP clerk has to inform HR department that they correct
the master data and the person can then at the same time delete the faulty report.
When HR department has updated the faulty employee master data, they have to
inform the AP clerk again so that he/she can execute the batch Input report again.


P 39 I 89
Update employee master data
Same procedure as the creation process!

Update the employee master data daily, because HR has the latest information on
employees. AP clerk calls up the Batch Input report. The system then automatically
updates the data in finance.
Post travel expenses to the defined expense accounts inclusive tax. With tax code V0!
The expenses will be paid with the normal payment program.
The HR department also informs the AP clerk when an employee has left Hilti so that
the employee account can be blocked and deleted in finance.
Link to BPP
4.2.4.7. Posting of manual price deviation
For some reasons it could be that you have to post manual price deviation to pay this
difference to the vendor.
First of all you have to check on the material master which valuation class the material
has and if you are an MO or HQ/plants because the account determination is different.
In this case I have done an example for HQ/plants.
Start transaction MM03


P 40 I 89
Press enter
Enter the plant number
Press Enter


P 41 I 89
See valuation class
Go to the account determination to see which account you have to choose.


P 42 I 89
For that please start Transaction FB60
Enter following
Press enter
Enter Text


P 43 I 89
Klick on Profit segment
Enter the material which had a wrong price


P 44 I 89
Press Continue


P 45 I 89
Simulate it and save it
4.2.4.8. Complex posting (input tax customs for imported materials)
Complex_Posting_input_tax_customs.doc
4.2.5. Invoices and credit memos with PO (with reference):

(also called Logistics Invoice Verification)
Objectives
To have a closed value flow.
Logistics Invoice Verification is part of Materials Management (MM). It is situated at the
end of the logistics supply chain that includes Purchasing, Inventory Management, and
Invoice Verification. It is in Logistics Invoice Verification that incoming invoices are
verified in terms of their content, prices, quantities. When the invoice is posted, the


P 46 I 89
invoice data is saved in the system. The system updates the data saved in the invoice
documents in Materials Management and Financial Accounting.
In Materials Management, Logistics Invoice Verification has the following

features:
 It completes the material procurement process, which started with the
purchase requisition and resulted in a goods receipt.
 It allows invoices that do not originate in materials procurement (such as
services, expenses, course costs) to be processed.
 It allows credit memos to be processed, either as invoice reversals or return
deliveries.
An invoice can be processed in Logistics Invoice Verification in various ways:
Invoice Verification Online
You receive an invoice and enter the information contained in it in the system,
comparing the data (such as quantities and values) suggested by the system with that
in the invoice and making any necessary corrections. You then post the invoice. In the
system, a distinction is made between the following two types of invoices:
Invoices with purchase order reference
All the items in a purchase order can be settled. With purchase-order-based Invoice
Verification, all the items of a purchase order can be settled together, regardless of
whether an item has been received in several partial deliveries.
Invoices with goods receipt reference

Each goods receipt is settled separately.
4.2.5.1. Incoming Invoice


P 47 I 89
This is a document from an invoicing party containing the payments to be made based
on business transactions performed in Purchasing and Inventory Management. An
incoming document can be an invoice or a credit memo.
A key information is the invoice reference, which enables you to clearly refer the
invoice to a business transaction. If such a reference exists, the system proposes the
appropriate values when verifying the invoice, for example:
 Agreed terms of payment
 Quantities to be invoiced
 Amounts expected for each item
If the vendor invoice contains different information, you can overwrite the proposed
data. The system checks whether your entries are allowed and it displays a warning or
error message if anything is incorrect.
Every document receives a document number by which it can be uniquely identified.
Invoice Verification requires the following:

 Purchasing document
 Material document
 Accounting document
 Master Data
Purchasing Document
A purchasing document contains information such as the vendor number, the purchase
order date, the terms of delivery, the material number, and the order quantity.
Material Document
A material document is created when a goods receipt is posted. It includes the posting
date, the quantity delivered, and perhaps also the delivery note number and the


P 48 I 89
purchase order number that the goods receipt refers to. It documents the quantity-
based changes.
Accounting Document
An accounting document is created when a goods receipt (unless the goods receipt is
not valuated) or an invoice is posted. It contains details of the individual postings with
the account number, posting key, and the amount. It documents the value-based
changes.
The advantage of this procedure is that the purchase orders, goods receipt notes and
invoices are all in the system.
Transaction Code: MIRO Enter Invoice

Link to BPP
We have to distinguish if the goods receipt has already been posted when you are
entering an invoice or not!!
 If the goods receipt has not been posted the system will post the difference first
to the GR/IR account and with the Goods receipt posting the system will then
post the difference to the price variance account (300812).
 If the goods receipt has already been posted the system will then post the
difference to the price variance account (300812) within the invoice posting.


P 49 I 89
Post invoice
Simulate it.
Post it


P 50 I 89
Incoming Invoice with planned freight costs
Objective
Post an incoming invoice including freight charges.
Post invoice
Enter first screen


P 51 I 89
Go to G/L account


P 52 I 89
Simulate the document
and post it
Incoming Invoice with unplanned freight costs
Post invoice


P 53 I 89
Go to details tab and enter under unplanned Delivery costs the net amount!!
Simulate it

P 54 I 89
Post it
If you post afterwards the Goods receipt the difference (EUR 50) will be posted to the
price difference account (300812)!
4.2.5.2. Park invoice (related to PO)
Objective
Park invoices related to a purchase order if information is still missing.
Transaction code: MIR7 Park Invoice.
4.2.5.3. Subsequent Credits
This business case can only be used when the purchase order price is not equal to the
invoice price and the vendor has committed an error.
Objective
Pay to the vendor only the correct amount.
Process


P 55 I 89
After receiving the invoice we have to post it. The invoice will be automatically blocked
if there is a price difference. The purchaser will be informed automatically and has to
check the whole purchase order to give feedback to Accounts Payable. When the error
was made by the vendor, AP will post a subsequent credit in the system to correct the
purchase order and issue the invoice, which will be sent to the vendor. After that the AP
clerk releases the original invoice.
The Invoice amount minus the subsequent credit will be paid via the payment program
to the vendor.
Other scenario would be that we get form the vendor a credit note concerning the price
difference!
4.2.5.4. Quality management
There are two possibilities to return materials.
1. Use the same purchase order

Purchaser has to send the material back (goods issue) and tell the vendor either
he should again deliver the quantity with the expected quality or he should send
a credit note.
2. Create a “Return purchase order” (purchaser)
and do a goods issue and tell the vendor he should send a credit note.
4.2.5.5. Fright cost calculation concept
With Go-Live Headquarter & Plants (Release H2.4.0) we introduced a new freight cost
concept.
There are three process variants to handle freight invoices:


P 56 I 89
1) receiving an electronic file D818 from the carrier

2) same concept as above but the carrier can’t send it electronically
3) manual postings
Because of tax reasons you always need the invoice also in paper form.
Please read more under
D818_Ablauf_SAP_R_3.doc
4.2.5.6. Display Invoice document
Objective
Display function for documents, which were posted in MM. Detailed document
information can be obtained by entering a logistics document number.
Transaction code: MIR4 Display invoice document.
4.2.5.7. Cancel document
4.2.5.5.1 In Finance
Objectives
Reverse documents that have been entered incorrectly, thereby also clearing the open
items.
A document can only be reversed if:

 It contains no cleared items
 It contains only vendor and G/L account items


P 57 I 89
 It was posted in Financial Accounting

 All entered values (such as cost centre, tax code, etc.) are still valid
If a line item from a source document has been cleared, a reversal can only be carried
out after the clearing is reset.
Documents from MM must be reversed with functions in that component

because the reversal function in FI does not reverse all the values required.
The document and the reverse document increase the account transaction debit and
credit figures by the same amount.
After a document has been reversed, the balance of the account affected is shown as if
the document had never been posted.
Negative Postings
Reverse and adjustment postings can also be marked as negative postings. Negative
postings are used to reduce the transaction figures in G/L and vendor accounts. This
allows you to give the transaction figures (following the reversal) the status they would
have had without posting the reversed document and its reversal document. This type
of reversal is called a negative posting.
Reversal
You must specify the reasons for the reversal transaction. For each reason, you specify
whether negative postings are to be generated. The reversal reason is noted in the
header of the reversed document. This additional information cannot be accessed in
reversals that take place via invoice verification (MM).


P 58 I 89
If the reversed document had already been re-valuated, additional line items are
generated during reversal for resetting the foreign currency valuation. The system
automatically marks these items as negative postings.
If the reversed document already contains negative postings, then the corresponding
line items in the reversal document are not negative postings.
Accrual/deferral documents for reverse postings

You must enter a reason for a reverse posting when entering an accrual/deferral
document. The reason for the reverse posting is noted in the accrual/deferral document
and used as a reversal reason during resetting. You can enter any reversal reason for
which a reversal with an alternative posting date can be carried out.
Residual items
The system marks residual items as negative postings. This prevents debit and credit
transaction figures increasing simply because of the creation of residual items.
Outstanding payables and receivables that the system generates according to an

amount entered in the field Difference postings are also automatically marked as
negative postings.
Reversing Documents
If the reverse document cannot be posted to the same period of the original document,
enter the posting date and the posting period of the reversing document.
If the document to be reversed is a check payment, you will also have to specify a void
reason code. You can display permitted void reason codes with the possible entries
button. Reasons 1-3 can only be used by the system.
Choose Enter.


P 59 I 89
The system generates a reverse document, creating debit and credit amounts.
Transaction code: FB08 individual reversal

Link to BPP
4.2.5.5.2 In Logistic
Objective
Cancel a document that was wrongly posted in Logistics Invoice Verification.
This function can only be used if the invoice or credit memo was posted in MM.
Transaction code: MR8M cancel invoice document

Link to BPP
Further also the accounting document must be cleared in FI on the vendor account.
Use transaction code F-44 account clearing for that.
Link to BPP
4.2.5.8. Blocked invoices
Invoices can be blocked either automatically or manually.

When you enter an invoice, the system suggests the values that it expects an invoice to
contain as a result of the purchase order or goods receipt. If the invoice item differs
from the default values, you must determine the reason for the variance by contacting
the purchasing or goods receiving department or the vendor.
An invoice can be blocked for payment due to one of the following reasons:
 Variance in an invoice item
 amount of an invoice item
 stochastic block (sample check, not used at the moment!)

P 60 I 89
 manual block
If a tolerance limit is exceeded, you receive a system message. You can post the
invoice in the system, but it is automatically blocked for payment if an upper tolerance
limit is exceeded.
Very important to know is also that the currency and the tolerance limits are dependent
on company code.


P 61 I 89
Tolerance limits which exists in SAP (e.g. Austria Company code 3051, currency EUR):
Tolerance key Lower limit Upper limit Absolute Value Percentage

AN Do not check
AP Do not check
BD Check limit 3,00
BR Check limit Check limit 25%
BW Check limit Check limit 5%
DQ Check limit Check limit 0,00 0,00%
KW Check limit Check limit 200 20%
PP Check limit Check limit 100 10%
PS Check limit Check limit 200 20%
AN: amount for item without order reference

AP: amount for item with order reference
BD: Form small differences automatically
BR: Percentage OPUn variance (IR before GR)
BW: Percentage OPUn variance (GR before IR)
DQ: Exceed amount quantity variance
KW: Var. From condition value
PP: Price variance
PS: Price variance: estimate price
When you post an invoice that gets blocked, two things happen:
 The account postings resulting from the invoice are made.
 In the vendor line of the accounting document, the system enters an R in the
field Payment block so that Financial Accounting cannot make payment for the
invoice.
If the invoice is blocked, all the items are blocked, even if the invoice only displays
variances in one item.


P 62 I 89
When an invoice is blocked, the period in which the vendor grants a cash discount may
expire.
You can have different blocking reasons:
It can be that several blocking reasons exist for one invoice.

Only “R” is relevant with purchase orders (tolerance limits) all the other payment
blocks are manually. That means per document or per vendor master account
you set this payment block (*, A, B, D, M, N, P, V) individually.


P 63 I 89
4.2.5.9. Release blocked invoices (MRBR):
Process:
The purchaser has to view and check periodically (at least one time in the week) by
himself the blocked invoice list! He/she has only the authorisation to display the
transaction MRBR. Because he/she is responsible for blocked invoices!!
So they have to clarify the problem with the warehouse, carrier or the vendor!!
After that he/she has to inform AP department via SAP-e-mail so that they can do the
next steps. (e.g. maintenance posting, release MRBR,..).
The AP responsible person gets a message via pop-up menu.
Double click on this express document


P 64 I 89
Click on the file “Release blocked invoices”


P 65 I 89
Now the AP responsible person can start the transaction MRBR if it’s only a price
difference to release this invoice!
If it is a quantity difference then you have first to do the transaction MR11 to do the
maintenance posting and afterwards do the MRBR transaction.
Before you release the blocked invoice you have to make sure that there is no
difference anymore between goods receipt and invoice receipt!! If there is still a
difference the purchaser has to tell the FI-department to post it off. Then the AP-clerk
has to do a maintenance posting!
After that you can call up this transaction (MRBR) and release the invoice.
Since the total invoice amount is to be paid and not individual invoice items, the
blocking indicator is set in the vendor line of the accounting document. As a
result, all the items in an invoice can only be released at the same time!!!
If you release this invoice, you can select the field Move cash discount date on the
initial screen of the invoice release transaction and retain the agreed cash discount.
You can also control the release of invoice items blocked due to price using a workflow.


P 66 I 89
In Logistics Invoice Verification, invoice items are blocked due to price variances.
Financial Accounting cannot pay these invoices.
If a price block is defined for invoice items, the system can inform the buyer
responsible for the purchase order automatically via workflow. This means that he or
she sees a work item in his or her inbox, which he or she can use to verify the blocked
invoice items and then process them as follows:
 Change the purchase orders

 Release the invoice items by deleting the blocking reason
 Flag the invoice items as cannot be clarified
The workflow ends when the price blocks in the invoice items are no longer valid
because the order prices have been changed, or when the invoice item is released
because the blocking reasons have been deleted.
If you flag price blocks in the invoice items as cannot be clarified, the system creates a
work item for the accounts payable clerk. The accounts payable clerk then explicitly
ends the workflow.


P 67 I 89
4.2.6. Evaluated Receipt Settlement (ERS)
Document missing waiting for info from HNA.


P 68 I 89
Recurring Entries
Please see general chapter.
Internal transfer postings
Use
You can use this function to post vendor against vendor or G/L against G/L.
e.g. invoice was mistaken posted to a CPD account instead of the vendor account
You can use the system to carry out transfer postings with or without clearing.
Enter and post the document as usual.
Without clearing:
It is the same procedure as F-43.

Enter and post the document as usual.
Normally you use the account clearing function without creating a posting. However,
the system may have to make automatically transfer postings in some cases.
Transaction code: F-42 transfer posting without clearing

Link to BPP
With Clearing:


P 69 I 89
Transfer posting with clearing is the transaction for account clearing in the standard
system. You cannot use any other transaction for account clearing. You can, however,
make changes to the transfer posting with clearing transaction.
The system has to make clearing entries for each transaction except account clearing.
To do this, it requires posting keys for the corresponding clearing procedure.
Open Items
Open items reflect unfinished transactions. For example, a vendor invoice that has not
been settled remains in the vendor account as an open item until it is paid.
The open items of an account can only be cleared once you post an identical offsetting
amount to the account. In other words, the balance of the items assigned to each other
must equal zero.
During clearing, the system enters a clearing document number and the clearing date
in these items. In this way, invoices in a vendor account are indicated as paid, and
items in a bank clearing account are indicated as cleared.
The SAP System offers different ways to clear open items. In a single clearing
transaction, you can process several accounts, different account types, (G/L, vendor,
customer), accounts from different company codes, and special G/L transactions.


P 70 I 89
 You can clear only open items that are posted to accounts that are managed
on an open item basis. Open item management is automatically set for customer
and vendor accounts.
You generally use the payment program to clear invoices. Manual clearing of open
items is therefore not usually necessary. However, you will sometimes have to clear
items manually if, for example, you receive a refund from your vendor or you have set
up a direct debit procedure.
Transaction code: F-51 transfer posting with clearing

Link to BPP
Clearing Functions in Accounts Payable
You can use the following functions for clearing open items manually:
Posting transaction Business transaction Choose

Outgoing payment Debit memo Document entry -> Outgoing
payment -> Post
Internal transfer posting Invoice cleared due to a Document entry -> Others ->
product defect Internal transfer posting -> With
clearing
Incoming payment Refund from a vendor, e.g. Document entry -> Others ->
annual quantity discount Incoming payment
The system also supports the automatic entry of bank postings for outgoing payments
by importing bank statement data using the Electronic Bank Statement function.
Selecting and activating down payment requests during clearing triggers the system to
post a corresponding down payment. This saves you from having to enter the down


P 71 I 89
payment manually, as well as from having to switch between two transactions to

process incoming payments.
Clearing Between a Customer and Vendor
If you select a customer who is also a vendor when processing a clearing transaction,
such as an incoming/outgoing payment or account maintenance, the system also
selects the open vendor items automatically, provided that:
 The vendor number was entered in the customer master record and
 The Clearing with vendor indicator has been set.
The same rule applies if you select a vendor that is also a customer during a clearing
transaction.
When you are clearing items, the system checks the authorisations for the customer
account as well as the vendor account.
4.3 Outgoing Payments
Objective
Settle open items on vendor accounts with payment.
4.3.1. Executing the Payment Program
The payment program processes domestic and foreign payments for vendors. It
creates payment documents and supplies data to the payment medium programs.
These payment medium programs print either a payment list, payment forms (for
example, checks) or create data carriers such as magnetic tape or floppy disks.


P 72 I 89
The system contains payment medium programs and forms for the most common
payment methods. It can also create payments on disk. Note that payment forms and
file formats vary from country to country and sometimes also from bank to bank.
The payment medium program stores data in the SAP print administration and (where
DME is used) in the DME administration. From there, data is picked up separately per
form/data carrier and output to the printer or data carrier.
Processing Open Items


P 73 I 89
4.3.2. Planning and Parameter Specifications
If you have several house banks that you can use for your payment transactions and
have limited funds in these accounts, you will have to plan the cash balances available
for each bank account and specify the ranking order by which the program is to use
these accounts. In addition, because there are several house banks available to the
payment program you have to enter the order in which the bank accounts are to be
selected.
Before a payment run, you need to specify which company codes, account types, and
accounts to include in the payment run. Furthermore, you have to enter the desired
posting date, the possible payment methods, and the date of the next payment run.
There are also some other optional specifications that you can make.
Attention!! The payment methods sequence is very important within the

parameter settings. We recommend to use following sequence: VUL (e.g.
Austria)
4.3.3. Creating the Payment Proposal
Once the specifications for the payment run are complete, you can schedule the
payment proposal. In a window, you either enter the desired start date and time or
arrange for immediate execution. The status display shows the currently performed
steps.
If the payment proposal is created, the system first checks the results, reading the
proposal log and recording any exceptions in it.


P 74 I 89
By displaying or printing the payment proposal list or by editing the payment proposal,
you can get an overview of the payments proposed by the program.
Editing the Payment Proposal
You can divide payment proposal processing between different clerks. To do this, you
must specify the accounting clerk ID stored in the master record after accessing
payment proposal editing.
It is possible to make changes when editing the payment proposal. You can make
changes to the payment (payment method, house bank) and the items paid (block
indicator, cash discount). All changes you make affect only the payment proposal. No
changes are made to the source documents.
Executing the Payment Run and Payment Medium Programs
Once you have accepted the payment proposal or have finished editing it, you can
schedule the payment run. The job created for the payment run will contain either only
the payment program as one step or an extra step for each payment medium program
and each variant. In the latter case, you need to specify which variants to use for each
payment medium program prior to scheduling the payment run. In scheduling the run,
you specify the desired start time and select the print programs option.
If you want to run only the payment program first, you can schedule the print programs
for a different time in a separate job.
Process Flow
The figure below shows the theoretical procedure to create a payment proposal.


P 75 I 89
Checking the Log

After you have created the payment proposal, you should call up and read the log.
The log informs you of possible configuration errors. In this case, no payment is
possible. You must correct the errors, delete the payment proposal, and carry out a
new payment proposal.
If you enter criteria for an additional log during parameter maintenance (for example,
payment method selection in all cases), the log will be more extensive and processing
will take longer. An additional log is only to be defined in exceptional situations or for
testing purposes.
4.3.4. Evaluating the Exception List


P 76 I 89
In addition to the proposal list, you can display or print out an exception list. The
exception list displays blocked items and all open items, which the payment program
did not propose for payment.
The exception list contains:

 Blocked items
 Special G/L transactions
 Items that could not be settled despite being due
The reason for the exception is shown by an error number. The list includes an error
text for every error reason.
Editing Payments
You can use the following functions to help you edit payments:
 Sort
 Search
 Change line layout
 Totals display
The system displays a dialog box in which you can choose whether to edit every
payment (all clerks) or only those for which you are responsible (clerk ID code).
The payments selected are then listed on the next screen (list level 1). One line item is
displayed per payment. If there are any exceptions for an account (for example,
blocked items), an additional line item appears in the list.
4.3.5. Running the Payment and Payment Medium Programs
Once you have edited and accepted the proposal, you can plan the payment run.
Several programs are used in creating the payments:


P 77 I 89
The payment program creates the payment documents and prepares the data for
printing the forms or creating the tape or disk.
Various payment medium programs use the data prepared by the payment program to
create forms or files for the data media.
Basic Procedure
You can choose from the following options when carrying out the payments:
 You can schedule the payment program first, and then once the run is completed
successfully, you can schedule the payment medium program.
 Or you can schedule the payment program and the payment medium program at
the same time.
 Or you can execute the payment program first, and then once the run is completed
successfully, you can execute the printout online.
Checking the Payment Log and Payment List

Prior to printing the forms, you should view the payment log and check over the
payment list to make sure that the payment run was completed successfully.
To check the payment run, read the payment log and check the payment list before you
print the forms.
You can use the search and sort functions in this display to get a quick overview of the
payments. Moreover, you can display a history of the changes made to the payment
proposal, which will show which clerks made which changes.
Executing the Payment Medium Programs Separately


P 78 I 89
Always ensure that the payment run and ensuing postings have been successfully
completed before starting the payment medium program. In the status display, you can
see how many documents were created and how many of them have already been
posted.
Payment Release Process
Authorisation
You can differentiate between one, two, and three-level release. This enables between
one and three people to be involved in the release procedure, thus supporting both
dual and triple control.
Refund to customer
Process description can be found in chapter AR

Important steps for the AP clerk are:
 Get information from AR
 include the customer account into the normal payment cycle and pay it
 send information back to AR
Bank statement
To finish the payment cycle you have to download the bank statement from our house
bank into our system.
Transaction code: FF67 Manual Bank statement

Link to BPP
Dunning


P 79 I 89
Please see chapter in AR.
4.3.6. Payments to HAG or IVV
Payments_to_HAG_or_IVV.doc
4.4 Down payments
Objective
Post down payments and after receiving the final invoice post it and clear all down
payments, which were made and related to the invoice.
Process flow
Each kind of down payment must be related to a purchase order. The big advantage is
that we have everything linked together (from purchase order via down payment
request, payment until asset explorer). At any time you can see the actual status.
The steps before you create a purchase order are described in chapter 5.3.1.1:
3. Create PO (The purchaser has to enter a notice into the PO under

“Notice for invoice control”. That means he has to enter the plan for
partial invoices with the amounts and sign it with the actual date and the
department. Then the purchaser sends an e-mail to Accounts Payable.
4. Create down payment request (according the information we get from
the purchaser)
5. Post final invoice (after we have received it from the vendor we post it
against the PO)
6. Clear down payments (after the final invoice is posted we clear all down
payments which are related to this PO)


P 80 I 89
Special G/L transactions are special transactions in accounts payable that are
displayed separately in the general ledger and the sub-ledger. This may be necessary
for reporting or for internal reasons. For example, down payments must not be
balanced with payables for goods and services. Consequently, they are treated as
special G/L transactions in the General Ledger (FI-GL) and Accounts Payable (FI-AP)
application components.
This is achieved by posting to alternative reconciliation accounts, instead of posting to
the reconciliation accounts for payables.
The following special G/L transactions are available:


P 81 I 89
These special procedures are displayed separately from other payables on the balance
sheet either for legal reasons, such as with down payments, or for control reasons,
such as with guarantees received.
4.4.1. Down Payment Requests (F-47)
Objective


P 82 I 89
Enter vendor down payment requests to make a down payment automatically using the
payment program and get the link from PO to asset explorer.
Down payment requests are so called noted items:

These are postings that are not displayed in your accounts but are only to remind you
of outstanding payments to be made. You can process them with the payment
program.
These are special documents that serve as a reference for posting a down payment.
They do not update the account balance.
When entering a down payment request, you enter the information required for the
payment. For example, you must enter a target special G/L indicator. The special G/L
indicator is used later to post the down payment. The system requires this indicator to
determine the correct special G/L account for down payments. Via the master record of
this down payment account, the system determines which fields are relevant for
entering a down payment request and how entries are treated.
The corresponding fields are ready for input. Therefore, the last posted down payment
accounts determine the specific adaptation of screens and not the request accounts.
The payment program only process down payment requests if you specify this
explicitly.
When you enter a down payment request, the Block indicator and Due date fields are
always ready for input. The fields are used in order to release and schedule a down
payment for posting by the payment program.
Transaction code F-47 down payment request

Link to BPP
Reversing a Down Payment Request


P 83 I 89
Reverse down payment requests manually at any time, without posting a down
payment. Use standard transaction for reversals.
More information you will find in chapter ??.
Changing/Displaying functions
Changes to a down payment request by changing the document or the line items by
using the document change functions.
4.4.2. Clearing Down Payments (F-54)
When you enter an invoice, the system issues a warning message that there is an
outstanding down payment. In doing so, the system indicates that a down payment
commitment exists. You can then decide immediately whether or not to clear the down
payment.
If you want the payment program to clear down payments, you must specify the special
G/L indicators when you define your company code specifications for the payment
program. When you post the final invoice you have to block the invoice with the defined
blocking reason M. Reason? This block indicator prevents the down payments from
being cleared straight away. By cancelling the block indicator with the document
change function, you release the down payment for clearing. You can also enter a due
date for the down payment. This specifies from which date the payment program can
then clear the down payment.
The payment program clears by subtracting the down payment amount from the
corresponding invoice amounts and by paying the difference. The program clears the
down payment automatically. With the gross procedure, the program also creates the
offsetting entry for tax and corrects the input tax account.


P 84 I 89
You make a down payment for 30’000 (see the figure below)
1. Post down payment request.
2. Do the payment run.
3. Post goods receipt
4. After receiving the closing invoice, you post the payable to the vendor account
via an offsetting entry to a balance sheet account. The system posts input tax
5. Do the down payment clearing
6. Do the payment run (The payment program balances the down payment with
the invoice and carries out all the necessary postings.
Changing/Displaying/Reversing a Down Payment

As with any other document, you can also change/display or reverse down payment
documents.


P 85 I 89
4.4.3. Security Deposit
After the clearing you have to block the invoice for payment if the purchaser told you
that we are going to pay not the full amount at this time because the final check
concerning the asset was not done. Therefore we have to remit the vendor only a
partial amount.
You can do that when you start transaction F-59 enter the SAP document number for
the vendor invoice and save it. Afterwards execute payment run that the vendor gets
his partial amount. After the purchaser had informed you that the final checking is ok
you can release the original invoice which was blocked with “M”. The system identifies
within the payment run that there was a partial payment and deduct this from the
invoice amount so the system automatically pays only the difference.
4.5 Financial Information System
Objective
Run reports to analyze transactions during a period.
The financial information system enables you to run evaluations for accounts payable.
Within the accounts payable information system, you can analyze individual operational
areas as required.
Reports for Accounts Payable Accounting
 Vendor Balances
 Vendors: Items
 Master Data


P 86 I 89
 Payment transactions
Under these topics you can choose several reports.
Generating Evaluations for Vendors
An evaluation is a data-set you select and summarize according to predefined rules.
In a generation run, the system retrieves for each evaluation the necessary information
from the databases and stores it as either a drilldown list or a sorted list in a table.
When you display the evaluation at a later stage, the system only needs to access this
table.
All totals are displayed in the currency of either the client (at client level), the company
code (at company code level. If conversion is required, the system does this
automatically, using the exchange rates defined in the system that are valid on that
date.
By selecting Settings -> Change from a drilldown list, you can choose between the
original currency (group currency, company code currency, and credit control area
currency) and an analysis currency that you can define.
4.6 GR/IR Clearing Account Maintenance
Objective
Clear GR/IR account to a zero balance.
Reasons why this account could have differences:


P 87 I 89
 If the quantity invoiced is larger than the quantity received, the system then expects
further goods receipts for this purchase order to clear the balance.
 If the quantity received is larger than the quantity invoiced, the system then expects
further invoices for this purchase order to clear the balance.
You can also clear differences for delivery costs.

 If no more goods or invoices are to be received, you must clear the balance
manually.
This can be done in different ways:

 You can return the extra goods to the vendor.
 You can cancel the invoice and post a corrected invoice or a credit memo for the
surplus quantity posted.
 You can clear the GR/IR clearing account manually.
Prerequisites
The GR/IR clearing account is usually cleared at the end of a period or fiscal year for
those order items that no further goods receipts or invoices are expected for.
Procedure
Daily or at least weekly there should be a check on the GR/IR account because of
differences between goods received and quantity invoiced.
If there is a difference on the account you have to contact via e-mail the purchaser that
he/she has to check the purchase order and its content.
After you had got the feedback from the purchaser, we have to clear the GR/IR account
manually as following:


P 88 I 89
Account Maintenance Document
This is a document that displays the quantities of the debit or credit of a material in
GR/IR clearing account maintenance.
If you clear quantity differences between the goods receipt and invoice receipt for a
purchase order using account maintenance, the system produces an account
maintenance document.
Displaying/Cancelling Account Maintenance Documents
Function Menu path What you should know

Display account Logistics  Materials Management  You can branch from the account
maintenance Logistics Invoice Verification  GR/IR maintenance document display to
document Account Maintenance  Display/Cancel the accounting documents
Account Maintenance Document
Enter the document number or select the The account maintenance
document number required. document is also updated in the
Choose Continue. purchase order history.
Cancel account Logistics  Materials Management  The account maintenance
maintenance Logistics Invoice Verification  GR/IR document was cancelled. As a
document Account Maintenance  Display/Cancel result, the original difference on
Account Maintenance Document the GR/IR clearing account is
restored. You can now correct the
Enter the document number or select the GR/IR clearing account again by
document number required. means of more goods receipts or
by clearing it manually.
Choose Continue
Choose Edit  Reverse document.


P 89 I 89
Enter the posting date. You can maintain the

document header text (as a comment on the
reversal).
Choose Save.
GR/IR Account Maintenance: Account Movements
The offsetting entry to clear the GR/IR account is the same as the posting made when
you enter an invoice for a purchase order.
Material with Standard Price

The offsetting entry is posted to a price difference account.
Purchase Orders Assigned to an Account

The offsetting entry is made to the cost or fixed asset account shown in the account
assignments in the purchase order.
Transaction code: MR11 Maintain GR/IR Clearing Account

Link to BPP
After that step you have also to clear the GR/IR account. To do this start the “automatic
clearing” transaction, enter the correspondent GR/IR account and activate the GR/IR
account special process button and execute the program.


Accounts Payable: Global Process Management System

Uploaded by

Document Information

Original Description:

Original Title

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

Accounts Payable: Global Process Management System

Uploaded by

Copyright:

Available Formats

Global Process Management System

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

Process: F-4 Accounts Payable Accounts Payable

4.2.6. Evaluated Receipt Settlement (ERS).........................................69

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

4.1 Master Data

Vendor master data creation

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

by purchasing or accounting. Case by case, it has to be decided whether and how a

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

4.1.1. Account Groups

Table 1: Account Group with description

Process: F-4 Accounts Payable Accounts Payable

ZEMP All employees which have travel expense

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

4.1.2. Vendor Numbering

Table 1: Authorisation with description

Account group Range Created by

ZEMP 7 000 000 to 7 999 999 System internal

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

4.1.3. Authorization for Vendor creation

Table 3: Authorisation with description

Account group Requester Authorisation Responsibility Process

4.1.4. Naming Conventions

It is very important that everyone, who is authorised to create a vendor, is following a

Vendor naming convention.doc

Process: F-4 Accounts Payable Accounts Payable

4.1.5. Content of the Vendor Master Record

A vendor master record contains:

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

How is the Data Organized?

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

This is data relevant to the purchasing organization of our company (purchasing

Special Fields in Vendor Master Records

Search Term: Vendor Master Records

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

For more information see again chapter 4.1.1.4

To always make vendor payments to an alternative payee, proceed as follows:

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

To get the following result

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

Affiliated Companies: Vendor Master Records (only relevant between Hilti

Clearing Between a Customer and Vendor

Valid on day of print 17/07/2006 12:11:00 - For internal use only -

Process: F-4 Accounts Payable Accounts Payable

Assigning Master Records to Dunning & Accounting Clerks

Picture 1: dunning clerks for e.g. Austria (SAP customizing)