Professional Documents
Culture Documents
DOCUMENT DETAILS
Prepared By
Version
Created Date
Number of Pages
DOCUMENT CONTROL
APPROVAL
Table of Contents
1 Introduction ....................................................................................................................................................................... 9
1.1 Management Executive/Summary .............................................................................................................................. 10
1.2 Basic Documents ........................................................................................................................................................ 10
1.3 Project Charter............................................................................................................................................................ 11
1.4 Project Scope/Scope Document ................................................................................................................................. 12
1.5 Significant Changes to the Current Status .................................................................................................................. 13
2 Business Process Modeling ............................................................................................................................................ 16
2.1 Cross Process related topics ...................................................................................................................................... 16
2.1.1 Information Carrier Model .............................................................................................................................. 16
2.2 Process Model Level 1, Core and Support processes <Financial Accounting>........................................................ 17
2.2.1 Flow Chart: .................................................................................................................................................... 18
2.3 Process Model Level 2, Process groups <Accounts Payable Accounting> .............................................................. 19
2.3.1 Flow Chart: .................................................................................................................................................... 20
2.4 Process Model Level 3, Business Process 1 Process Vendor Invoices ................................................................... 21
2.4.1 Short Description of the Process ................................................................................................................... 21
2.4.2 Business Requirements ................................................................................................................................. 22
2.4.3 Written Explanation........................................................................................................................................ 24
2.4.3.1 Process of Logistics Invoice Verification of Vendor: ...................................................................................... 24
2.4.4 Linked Processes .......................................................................................................................................... 40
2.4.5 Inputs (Event Triggers, entities, parameters) ................................................................................................. 40
2.4.6 Outputs (Process Results) ............................................................................................................................. 40
2.4.7 Process specific User Roles & Requirements for the Authorization Concept ................................................ 40
2.4.8 Quantification ................................................................................................................................................. 41
2.4.8.1 Transaction and Data Volumes ..................................................................................................................... 41
2.4.8.2 Frequency of the Processes .......................................................................................................................... 41
2.4.9 Measurable KPIs ........................................................................................................................................... 41
2.4.9.1 Status of KPIs before the Project ................................................................................................................... 41
2.4.9.2 Target KPIs .................................................................................................................................................... 42
2.4.10 Improvements to the Process Compared to As-Is Status .............................................................................. 42
2.4.11 Functional Deficits/Gaps ................................................................................................................................ 42
2.4.12 Notes on Further Improvements .................................................................................................................... 42
2.4.13 Development Considerations ......................................................................................................................... 42
2.4.14 FRICE Considerations ................................................................................................................................... 42
2.4.14.1 Forms Considerations ............................................................................................................................... 42
2.4.14.2 Reports Considerations ............................................................................................................................. 43
2.4.14.3 Interface Considerations ........................................................................................................................... 43
2.4.14.4 Data Conversion Considerations ............................................................................................................... 43
2.4.14.5 Enhancements Considerations ................................................................................................................. 43
2.5 Process Model Level 3, Business Process 2 Handle Vendor DR/CR Notes ............................................................ 43
2.5.1 Short Description of the Process ................................................................................................................... 43
2.6.8 Process specific User Roles & Requirements for the Authorization Concept ................................................ 66
2.6.9 Quantification ................................................................................................................................................. 67
2.6.9.1 Transaction and Data Volumes ..................................................................................................................... 67
2.6.9.2 Frequency of the Processes .......................................................................................................................... 67
2.6.10 Measurable KPIs ........................................................................................................................................... 67
2.6.10.1 Status of KPIs before the Project .............................................................................................................. 67
2.6.10.2 Target KPIs ............................................................................................................................................... 67
2.6.11 Improvements to the Process Compared to As-Is Status .............................................................................. 68
2.6.12 Gaps in the process Coverage ...................................................................................................................... 69
2.6.13 Organization change for further Improvements ............................................................................................ 69
2.6.14 Development Considerations ......................................................................................................................... 69
2.6.15 FRICE Considerations ................................................................................................................................... 69
2.6.15.1 Forms Considerations ............................................................................................................................... 69
2.6.15.2 Reports Considerations ............................................................................................................................. 69
2.6.15.3 Interface Considerations ........................................................................................................................... 69
2.6.15.4 Data Conversion Considerations ............................................................................................................... 69
2.6.15.5 Enhancements Considerations ................................................................................................................. 69
2.7 Process Model Level 3, Business Process 4 Handle Vendor Letter of Credit .......................................................... 70
2.7.1 Short Description of the Process ................................................................................................................... 70
2.7.2 Business Requirements ................................................................................................................................. 70
2.7.3 Flow diagram ................................................................................................................................................. 71
2.7.4 Written Explanation........................................................................................................................................ 73
2.7.5 Linked Processes .......................................................................................................................................... 74
2.7.6 Inputs (Event Triggers, entities, parameters) ................................................................................................. 74
2.7.7 Outputs (Process Results) ............................................................................................................................. 74
2.7.8 Process specific User Roles & Requirements for the Authorization Concept ................................................ 74
2.7.9 Quantification ................................................................................................................................................. 75
2.7.9.1 Transaction and Data Volumes ..................................................................................................................... 75
2.7.9.2 Frequency of the Processes .......................................................................................................................... 75
2.7.10 Measurable KPIs ........................................................................................................................................... 75
2.7.10.1 Status of KPIs before the Project .............................................................................................................. 75
2.7.10.2 Target KPIs ............................................................................................................................................... 75
2.7.11 Improvements to the Process Compared to As-Is Status .............................................................................. 76
2.7.12 Functional Deficits/Gaps ................................................................................................................................ 76
2.7.13 Notes on Further Improvements .................................................................................................................... 76
2.7.14 Development Considerations ......................................................................................................................... 76
2.7.15 FRICE Considerations ................................................................................................................................... 76
2.7.15.1 Forms Considerations ............................................................................................................................... 76
2.7.15.2 Reports Considerations ............................................................................................................................. 76
2.7.15.3 Interface Considerations ........................................................................................................................... 76
1 INTRODUCTION
This document states all of the conceptual results of the project SAP H. These project results were devised
and decided on by the project team and the Business Process Owner during the Business Blueprint project
phase. This is the main concept document of the project. The content of this document forms the basis and
the guidelines for the subsequent realization phase. This document aims to describe the future business
solution for SAP.
Any additional explanations that are only relevant when the project is in progress are given in the various
project management plan documents, which the project management team will provide on request.
The following Business Team form part for the outcome of the Business Blue Print.
ABC SAP
Team
Leader Name Role E-mail
1
Key Users
1
2
3
4
5
The following basic documents describe the foundations of the project work that affected the initial
designs and concepts of the project. The information here is a selection of the most important
information. The complete information is available on the shared project file server at
\\10.3.24.51\SAP_Project\SAPH\2000- Business Blueprint\2100-Business Blue Prints
ABCs current computer system has evolved through in-house development since two decades and
many individual island systems exist to carry out the business process.
Data communications among the applications are very restrictive and are not supporting the business
requirements adequately and are not integrated.
As part of its Computerization strategy, ABC Company has made the decision to replace its existing
systems with an ERP - my SAP integrated software.
The focus of benefits will be to provide common business systems across ABC that will:
Enable more effective use of resources
Support business growth
Leverage administration costs
The primary benefits expected to accrue from the SAP implementation are:
Reduction of paper work that promote concept of paperless office.
Identify the profitability of an activity and associated costs.
Flexible, evolving and responsive business environment.
Simple and shortened close at month and year-end.
Reduction of administrative overhead, enabling staff to concentrate on analysis rather than
transactional issues.
Provision of an integrated solution to the shortfalls of the current systems.
Information sharing across the company.
Provision of a feed of enterprise transaction data to any future data repositories and decision
support tools such as the Business Intelligence.
High quality reporting resulting from improved data collection, database and reporting tools.
Introduction of Executive Information System (EIS) reporting for more informed decision-making.
Broadly to mention
This section summarizes the project scope that was agreed between the customer and the contractor.
This scope goes beyond the tasks that the service provider SAP has been assigned and includes all
project tasks that ABC must complete internally for itself.
The scope is subject to a strict change procedure. The process for changing the scope is described in
Project Scope Document ID.
To explain the scope as precisely as possible, several dimensions were chosen for examining the
scope, some of which may overlap: Specifically, the scope is examined in terms of the processes, IT
functions, technology, organization, method, and deliverables.
- Project staff will provide support for the end users during the first month after the go-live
Process Scope:
The following processes are examined in the area of maintaining Accounts Payables Accounting by
ABC Company Finance Department:
Vendor Master
Payment Terms
Advance to Vendor
LC Process
Retention to Vendor
Vendor Master: Vendor Groups are not maintained in current Accounting Software
Payment Terms:
Currently, the following Payment Terms are being used by ABC. ABC will open the L/C for Import
and Bank Guarantee in case of Domestic against Vendor.
Cash in Advance
Telex Transfer
Payment on Delivery
L/C Sight
Normally the payment terms are against the delivery, 30, 60, 90 or 180 days. Payment terms vary
material- wise, service-wise as well as vendor-wise. For some vendors and sub-contractors, the
terms of payments are back to back.
Payments terms start from the delivery date. In case imports vendors payment terms start from date
of Bill of Lading.
VENDOR INVOICE PROCESS AND VENDOR PAYMENTS: Vendor Invoices are paid through L/C
mostly. For making payments to vendor, CFO/ Financial Controller/ Accounts Payable
Manager/Project Manager Approval is required on original vendor invoice, and Accounts Manager
(A/P), Financial Controller and C.F.O approval required on payment voucher. If there is any
discrepancy in the vendor invoice, ABC Company returns the invoice to vendor for modification.
Retention money is applicable for some Vendors as per the Payment Terms
In case of domestic purchases, if any shortage, breakage of material, ABC Company returns
material along with invoice copy to vendor. Vendor will send revised invoice copy and replace the
material. In some cases vendor will be issued the Dr/Cr note.
Advance to Vendors: Advance payment is made after receiving the acceptance letter from vendor.
In some cases ABC Company requires a L/C from the vendor for making advance payment.
Accounts Payable Report: Accounts Payable reports are prepared in Venus Accounting Software
and MS Excel Spreadsheet.
Present all processes that the business blueprint examines in a structured format using three process
model levels. Handle the processes according to the various criteria.
Often, the structured descriptions of processes on the lower levels contain process variants that only
deviate from the main process in minor details, but which can later affect subsequent processes. In such
cases, decide whether it makes sense to include the variants in the process model.
2.2 PROCESS MODEL LEVEL 1, CORE AND SUPPORT PROCESSES <FINANCIAL ACCOUNTING>
This document explains the design of the Financial Accounting module. The document will describe how
Accounts Payable Master Data is maintained and used in FI and other all Integrated modules like CO,
MM, SD, PP, HR etc.,
The document will act as a single source of material for all future design including General Ledger Master
Data and Business Processes in SAP for project Project SAP H of Finance Department.
FINANCIAL ACCOUNTING
The Accounts Payable application component records and manages accounting data of all Vendors. It
is also an integral part of Materials Management.
All postings in Accounts Payable are also recorded directly in the General Ledger. Different General
Ledger accounts are updated depending on the transaction involved (for example, Receivables, down
payments, Retention etc). The system contains a range of tools that ABC can use to monitor open
items, such as account analyses, due date lists, and a flexible automatic payment program.
There are a range of tools available for documenting the transactions that occur in Accounts Payable,
including balance lists, journals, balance audit trails, and other SAP standard reports.
Accounts Payable will be having the close integration with the Materials Management component.
FINANCIAL ACCOUNTING
The main aim of any invoice verification process is to ensure that vendors are paid the correct amount at
the right time (not too late but also not too early). The process should have a high incidence of first-time
matching to ensure that as little time as possible is spent trying to manually match invoices that appear
to be incorrect. It is important to include as few steps as possible in the process, considering that the
process of handling payments does not in itself add value to the company.
It is important to keep these steps to a minimum and the SAP processes achieve this goal.
This process defines the procedure of recording payables for non PO related supplier invoices.
Company receives vendor invoices that are not issued against a purchase order. Recording liability for
the companies purchases with a supplier, on receipt of supplier invoice with reference to an approval
document authorizing the purchase of such items.
It is also possible to post invoices from FI without the necessity of purchase order. That can be used to
fulfill the requirement of postings like miscellaneous payments, employee-related payments, travel agent
payments, hotel bills, and consultancy payments.
The objective of Manage Account Payable (Vendor Invoices) is to ensure that all liabilities towards
vendors are recorded and paid accurately and in a timely manner as per Company policies,
procedures and contractual agreements.
The requirements are:
Single system to handle all Invoice transactions.
Single point of entry for all invoices to the Company
Reduction in paper invoices where practically possible through enabling technology.
Allow for payment outside the normal payment run
Automate postings of Difference in Exchange rate
Automate the clearing of vendor accounts and post banking ledger entries
Communicate payment details to banks
Allow payments to vendors with multiple bank accounts
Ensure all controls and checks have been performed when validating the Payment Proposal
Ensure segregation of duties between PO, GR, Invoice Entry and Payment Processing
Ensure that the PO process is used where a material or service is acquired
Ensure that once paid, an invoice is flagged to prevent any duplicate payment
Ensure that there is actual match between PO, GR/SR and Invoice.
Ensure tolerance levels have been defined properly
Identify due payments as and when required
Provide control reports to check for Overdue, Blocked and Parked invoices
Provide facility to reverse wrong entries made
Trigger
Point
Invoice Verification
Accounts Payable Accountant
Goods Receipt in
Materials Management YES Invoice Verification NO (FI Invoice)
(MM) Module with reference to
HI_MM_XX_XX Purchase Order
Schedule / Process
Clear Vendor
Accounts
Vendor Payment
Manager
Payable
Down Payments
HI_FI_AP_03_03
Post Vendor Invoice HI_FI_AP_03_04
HI_FI_AP_03_06
Recommendation for invoices to be received and processed centrally (Finance Division) wherever
possible
All LIV invoices must be associated with a PO number, otherwise the invoice is returned to the
vendors. If this is not common practice already, Organization Units should communicate this to their
vendors prior to go-live of this Blueprint. During the early stages of go-live or if returning invoices
with no PO is not an option due to logistical restrictions, then these invoices may be tracked via
Delivery note number. This situation should only exist during an interim period and thus is not
recommended as a medium to long term approach.
Validations ensure that invoices against vendors are only processed via LIV; hence an error is
issued if the invoice processor attempts to process the invoice within FI
Company code dependant validation may force the invoice processor to enter the House Bank (i.e.
the bank to pay from) upon invoice processing. Otherwise, the House Bank is selected
automatically based on payment method and currency while executing the automatic payment
program. The reason for the mandatory input of the House Bank at the time of invoice processing
would be to drive the Cash Requirements report, which would not provide information by House
Bank if the field is left blank.
A duplicate invoice validation should take place at the time of postings invoices. The check should
compare the invoice with posted documents where the vendor and reference (invoice number) are
the same. Hence, the invoice date and currency are removed from duplicate invoice check. Upon
finding a match, a warning message is issued listing the matching document(s)
Small differences tolerance, if required, should be active for all company codes, but the amount of
small difference allowed are left to the discretion of the Organization Units. These are meant to
take into account any rounding issues or decimal variances between the receipts and the invoice
value. The price difference tolerance, which allows update during invoice processing of the cost
(receipt) lines, should also be active for all company codes. Here, the lower limit is set by the
Organization Unit and allows for the reduction of the cost line (receipt) in cases where the invoice
price is lower than the receipt even though this situation is not common. However, the upper
tolerance should be set to 0 for all Organization Unit. Hence, if the invoice is out of small difference
tolerance and is higher in value than the receipt (due to price), then an error is issued and the
invoice must be held.
Vendor Retention is handled through standard SAP functionality via special retention payment
terms. When these payment terms are used, the vendor line is split into two open items, each
assigned to different payment terms defaulted from the special retention payment term.
For example a 10% retention payment term may result in one line item for 90% of the vendor value
available for immediate payment and another line item for the remaining value available for payment
after 45 days. The second line item may even be defaulted as blocked for payment. These
characteristics are specified against the special retention payment term.
OR
Development Logic will be decided after SAP note will be raised to meet ABC requirement
Discounts at invoice level are also handled via payment terms and are automatically booked as
revenue. Contract level discounts (e.g. volume discount) relating to materials and services though are
normally effected against the price directly.
Return Invoice
to Vendor
Receive No
invoice
PO number Register Invoice via
from
available? LIV
Trade Yes
(MIRO)
vendor
Post Invoice
Yes
File invoice
3 way matching hard copy
(PO: GR/SR: Inv) Within Post Invoice with
for audit
Achieved? tolerance small differences
Matching Invoice
Once an invoice is received with a valid PO number on it, it is processed through LIV. Invoice details are
recorded as follows:
Payment:
Baseline date Optional This defaults from document date, but may be updated if required. It
Upon entry of the associated PO number or receipt, the available receipted items appear for matching. In
cases where the invoice matches exactly with the receipts or to within a small tolerance, then the invoice is
posted directly and is available for payment through the next automatic payment run depending on the
invoice payment terms. Hence the three way matching provides sufficient control over invoice processing
with no further approvals necessary before payment.
Note that the actual invoice tolerance limit is determined by each Organization Unit; but is generally kept to a
small value or percentage to cater for any slight variances resulting from rounding or currency exchanges.
The invoice accounting entry is to credit the vendor and debit the GR/IR or SR/IR accounts. Other
automatic accounting entries may result depending on the invoice for example small differences. In
cases where the invoice is processed in a different currency than the PO or fixed exchange rate is not
selected on the PO, then realized exchange differences may also result from the invoice posting.
In cases where the invoice does not match with the receipts (i.e. out of tolerance), then an error message is
issued and posting terminates.
Incorrect Unplanned
receipt delivery
Receipt
Receipt
available
unavailable
After investigation with the relevant department (mostly depicted by the purchasing group), if the invoice is
not a valid one, then the held invoice is deleted completely (transaction MR8M) and the hard copy returned
to the vendor. A Standard SAP report (transaction MIR5) for deleted held invoices can be used later for
reporting deleted / cancelled held documents for audit purposes.
If the invoice is a valid one, then there are either issue with the receipts or with delivery costs. Issues with
unplanned delivery costs are covered below.
If the receipts are not available (or not sufficient quantity posted), then the requesting department records
the receipts after confirmation of work done (either Goods Receipt or Approved Service Receipt) prior to the
re-matching of the held invoice. In-line with common business practice, it is assumed here that the POs
have been recorded and issued to the vendor prior to receiving the invoice. During early go-live, a transition
period may be necessary in order to record all outstanding POs with outstanding Goods Receipt.
Once accurate receipts are available, the held invoice may be matched manually or automatically (see
activity / sub-section Process Matching of Held Invoices).
If the receipts are available, but do not portray the correct values, then the issue is either with quantity or
price. For variances on the quantity, then either the invoice is incorrect; or the receipt. Either way, the
invoice is either returned to the vendor or the correct quantities are received (i.e. a top up of the quantities
as it is highly unlikely that more was receipted than is being invoiced. In any case, if such a scenario were
to occur, then the receipt must be reversed and reposted with less quantity).
If the mismatch is due to price, then the user has the option either to reverse the receipt, update the PO and
contract prices and then re-post; or adjust the price on the PO and contract without reversing the receipt,
which incidentally may be disallowed anyway in the case of stock materials that have already been issued.
In the latter case, held invoice matching can only occur through the automatic matching program (see
Process Matching of Held Invoices).
When dealing with stock related purchasing; stock quantities and handling charges need to be addressed.
Firstly, if a stock invoice is processed against a goods receipt where price variances exist (i.e. invoice does
not match with receipts), then the invoice must be held. Regardless whether the price variance is higher or
lower and assuming the invoice in this case is validated to be correct, the PO and contract prices are
updated to reflect these actual rates. This ensures that the prices on contracts and the PO are in-line with
the agreed rates so that subsequent planning and business with the vendor is more accurate and efficient.
After this update, if the invoice price is lower in value but within the Price Difference (PP) lower tolerance,
then the receipt line value on the invoice is reduced and the invoice posted as per normal. The resulting
accounting entry automatically reduces the stock value and material MAP (Moving Average Price) to the
invoice amount.
(In case of in-sufficient stock coverage i.e. if the available stock quantity is lower than the invoice quantity,
then the variance is posted instead to the price difference account, which in turn is manually cleared as part
of month end) Note that in the unlikely event that the difference here is larger than that defined by the PP
price lower variance tolerance, then an error will result and the goods receipt is either reversed and re-
posted as described in (a) below, or matched through the automatic matching program as detailed in (b)
below.
If the invoice is higher in value, then the user has two options:
a) Reverse the goods receipt and re-post with the correct rates. This allows direct invoice matching. Note, in
cases where material quantity in stock is less than the goods receipt quantity, then the goods receipt cannot
be reversed and hence option (b) below must be followed
b) Wait for the next scheduled execution of the automatic matching program which matches invoice price
with PO price and adjusts any variance from the GR. Here, the stock value is automatically adjusted as well
as an increase in the MAP in cases where stock qty is higher than invoice qty. Otherwise, the variance is
posted to the price difference account and manual clearing is required (provided that sufficient tolerance
limits are set in PP).
Import delivery charges are planned in PO conditions. These eventually become a part of material landed
cost. The LIV process shall handle the payment/ verification of these delivery charges
In line with accounting policies, material valuations must include handling fees so that stock valuations and
goods issues include these costs as well as material price. In some Organisation Units, handling fees may
amount to a significant percentage of the material price.
In this respect, the optimal solution is for the material MAP to include material handling fees as well as the
pure material price. Some material contracts include handling charges within the material price in which
case no special handling is required. Otherwise, the solution is to define freight and customs condition types
when setting up the contracts and POs. These represent an estimate of the handling fees and are posted at
the same time of the goods receipt (GR/IR style accounts). These conditions allow for the entry of a different
vendor than that on the main PO in cases where the freight or customs vendors are different than the PO
vendor. Note that later during invoice processing, the defaulted vendor information from freight and customs
conditions may be updated directly by the user. Hence, there is no hard control over the vendor that is used
to post freight and customs invoices.
Upon posting of the material good receipt with freight and customs conditions, the following elements result:
a) The MAP, and hence stock valuation, reflects price and handling fees
b) The estimate cost is realised at the time of receipt against material account
c) Open items are generated against the freight and customs GR/IR accounts awaiting invoice matching and
subsequent payment. Any difference between estimate & actual is posted to material stocks / price
difference accordingly, at the time of LIV.
d) Instead of estimate freight & customer charges, if actual charges are required to be a posted at the time
of GR then, LIV for freight & custom duty should be posted before GR
Assuming the invoice arrives with a valid PO number, if there are no good receipts available, and then the
PO is held for further processing as per normal. In cases where the payment is urgent and cannot await a
good receipt, then a down payment request is processed and approved for payment. Otherwise, or once a
goods receipt is available, then:
a) If the invoice matches exactly the invoice is posted and is ready for payment during the next automatic
payment run
b) If the invoice is lower then the receipt line is reduced directly and the invoice is processed. Correcting
accounting entries result to reduce the P&L previously posted by the freight condition estimate. Note that in
this case, reverse and re-post is not an option as the freight conditions are generally determined as
percentages and not as fixed values. The amount with which the cost line can be reduced is managed by
the PP lower limit tolerance. If the cost line requires adjustment over and above the maximum allowed
amount, then the cost line is cleared as is and a correction subsequent credit memo is processed.
c) If the freight invoice is higher or second invoice then it is not possible to update the receipt lines as per
(b). This is because the upper limit tolerance (PP) is set to 0 for reasons previously explained. Reversing
the goods receipt is also not an option. Thus, the unplanned delivery field is used to record the difference
between the invoice and receipted lines.
The posting / accounting entries for unplanned delivery cost will depend upon the system settings in
customizing. Whether on material or separate G/L account?
ABCContracting Company has to decide during Realization phase that whether unplanned delivery cost be
posted on:
Assuming the material invoice has been posted or is the same as the freight invoice, then unplanned
delivery can be used. The maximum allowed variance from the material line (or use of unplanned delivery)
can be controlled by company code by building appropriate custom transaction if no standard SAP
transaction exists for this. Note that if the freight invoice is a second or third that relates to the same item,
then the total invoice amount is entered as unplanned delivery assuming it is within the company code limits
to be set by the custom table. This is because the original line item would have been cleared by the first
processed invoice.
Also, the invoicing party field may be modified by the user directly in cases where the invoice vendor is
different to that stipulated by the freight condition.
If a down payment request exists against the invoice, then it is matched before the next scheduled automatic
payment run.
The change to the limits may be temporary in cases of one-off situations. Note that accounting entries
resulting from unplanned delivery adjust the stock value (or cost for direct purchasing) where the total qty in
stock is higher than the invoice qty. Otherwise, the difference is posted to the price difference account
awaiting clearing at month end.
Inter-company Invoice
Inter-company invoicing is a possibility from both LIV and FI, and is only relevant to Organization Units
where multiple company codes (or legal entities) are active. Inter-company invoicing may be required
for ABC in future, due to the following business requirements:
a) External Vendor payment is contractually restricted to a single company code regardless of which
company code the work is done. In this case, the invoice is posted as per normal against the vendor, but
against the paying company code (as in PO) rather than the company code where the Goods/Service
receipt was posted.
b) For vendors that perform work against multiple company codes, inter-company invoicing facilitates single
source payment for all work done for the Organization Unit hence allowing improved management of total
vendor liability by Organization Unit (across company code).
An invoice against the company code where the costs are originally charged to:
Debit GR-IR (for sub-sequent matching with receipts during automatic clearing)
Credit Inter-company Vendor (payment to be made to inter-company company code)
The vendor here represents the company code where the vendor line is booked for subsequent payment
The net effect of the transaction is that the company code where the work is done owes the inter-company
company code and not the trade vendor. This payment may be settled without any restricted payment terms
and at the discretion of the Organisation Unit depending on legal inter-company regulations. In turn, the
trade vendor payment is then consolidated with any other outstanding payments due to the vendor from a
single company code.
Held invoice are matched with receipts once available. This can be done manually upon confirmation that
the reason for holding has been resolved;
Manual Matching
Based on the output of Held Invoice report, held invoices are accessed through transaction code MIR4 by
specifying the MM LIV number listed in the report output (or MIR6 for a held invoice listing). In the case
where matching is achievable, the document is moved to change mode (from display mode) and posted.
Process: LIV Invoice against Blanket PO (or no GR PO)
Blanket POs are used within Blueprint where required for low value high volume item purchasing e.g. office
equipment, flowers etc... Due to their nature, no receipting is required, allowing invoices to be posted
directly against the PO line items. This is also an equivalent process to any standard PO where the receipt
flags have been manually deactivated on the PO. Though this is not recommended, it may be applicable to
certain low value POs where receipting is not practical.
Upon receipt of an invoice against a blanket PO, the invoice is processed manually using MIRO. Invoice
amounts are limited to the PO value ceiling and are processed without a payment block. In other words,
invoices received within the PO value ceiling are approved for payment. Due to this risk, it is important that
the use of blanket POs is restricted to a small community of users who utilise the functionality for low value
items.
Note that since the use of blanket POs (or no GR POs) does not involve receipting, then any accruals
relating to services procured in this manner need to be posted manually as there is no mechanism for
creating service entry sheets which are the trigger to automatic accrual generation.
Post Invoice
(Automatic Block F)
Upon receipt of the invoice, if a PO number is associated with the invoice, then the invoice must relate to an
MM vendor and should be processed through LIV. Otherwise if it is a valid FI only invoice, then it is posted
using transaction FB60. Due to the expected low volume of such invoices, they are posted directly to the
ledgers before approval; hence FI parking functionality is NOT used or can be used in some cases by ABC.
During posting, the invoice can be blocked through a blocking indicator block A FI Invoice. The
designated invoice approver(s) then have the responsibility of reporting against the blocked invoices, and
approving their payment by removing the payment block indicator. The list of blocked invoices may be
easily generated by executing transaction code FBL1N "Vendor Line item Display" and specifying the
blocking indicator in the selection criteria. Note that if the Invoice approvers record the FI invoices
themselves, then no blocking takes place and the posting is assumed approved for payment.
Inter-company invoices also can be handled by FI invoices. These invoices are generated by the Finance
Department. The payments are settled through the next scheduled execution of the payment program.
For single source vendor payment or payment by loan from another company code, inter-company FI
invoices can be used in a similar manner to that described above Inter-company Invoicing of this paper.
Invoice Processing depend on the particular business requirement and vendor relationships, variations to
invoice processing exist within the blueprint as summarised in the diagram below:
Start
Concern Department
Collect Invoice
for purchases
Approval by
department
Manager/
Prepare PC
Receive
supplier
invoice, PC
Verify supplier
invoice & PC
Accounts Payable Finance Department
Approval by
No Yes
AP Manager
FB60 Payable
doc.
End
Printing/filing
End
1 Receive Manual Daily Concern The invoice from the supplier for any
Invoice and department purchases without a PO will be received by
PC from buyer the buyer (employee of any department).
concern The invoice shall be supported with required
department approval documents from the department
manager, before forwarding it to AP
accountant.
2 Approval by Manual Daily Concern Upon receipt of purchased items the
concern department purchase invoice should be approved by the
department buyer department manager, to enable the
manager recording of companies liability in
accounting books.
2 Conduct Manual Daily AP The received documents should be
Physical Accountant physically checked for the consistency
check authorized approvals.
The accounts department based on the invoices received from the vendors will process vendor invoices.
The following entry will be passed on approval.
Dr. Expenses Account
Cr. Vendor Account
There is a direct link to GL Accounting, Accounts Receivable Accounting, and Cash Management.
And indirect link to all integrated modules likes CO, SD, MM, PM, PS, PP etc., to this General Ledger
Accounting.
Receive Supplier Invoice along with the copy of Bank Guarantee/Letter of Credit.
2.4.7 Process specific User Roles & Requirements for the Authorization Concept
2.4.8 Quantification
In Terms of Quantification the Transaction and Data Volume will be considerably high and the frequency
of the transaction will be daily during the working hours.
Separate Transactions will be used in SAP for Invoice with Purchase Order and Invoice without
Purchase Order. The Data Volume will considerably high.
Change AS IS TO BE in SAP
Impact
Summary
Process of Currently the Vendor Automated LIV Process which matches based on Goods
Vendor Invoice is being prepared and Services Received
Invoice in Excel Sheet/Word
Tolerance limits can be placed for Invoice Verification
Document.
Invoices not matched and outside the tolerance (Invoice
The Matching of the
amount against PO amount) limit will be parked,
Invoice is being done
investigated and then processed later.
manually against the
Purchase Order. All open items get cleared once payment is made
For Invoice without
The incorrect documents posted through other modules will
purchase order, a manual
be reversed by respective modules only.
JV is being passed in the
current Venus System.
NIL
NIL
2.5 PROCESS MODEL LEVEL 3, BUSINESS PROCESS 2 HANDLE VENDOR DR/CR NOTES
Recovery in value of shortages, contamination, damages, penalties etc. is done from the transport
vendors in the event of accidents, lost vehicle etc. No debit note is required to be raised on the
transporters for normal shortages, because in such cases only net amount is posted to the
transporters A/c.
Recovery of certain service charges from the vendors in lieu of certain services provided.
Recovery of Insurance Premium / Freight & Transportation charges etc. paid on behalf of
vendors
Claims recovery
Trigger
Need to create a
Point
Debit / Credit Note in
FI
Accounts Payable Accountant
1
Process Vendor YES NO (FI Dr / Cr Note)
Invoice Create a Debit / Credit
HI_FI_AP_03_01 Note with reference to
Purchase Order ?
Process Vendor
Invoice
HI_FI_AP_03_01
2
Verify & Park
Vendor Debit /
Credit Note in FI
Schedule / Process
Vendor Payment
Accounts
Manager
3
Payable
HI_FI_AP_03_03
Post Vendor Debit /
HI_FI_AP_03_06
Credit Note in FI
If No:
Create a
Debit/Credit
Note via FI
module
A debit memo is a transaction that reduces Amounts Payable to a vendor because; you send damaged
goods back to your vendor.
In SAP Vendor Debit notes are handled with Document type KG.
Debit/Credit note will have to be raised on Vendors for various reasons like return of goods, subsequent
debit, adjustment of short payable etc.,
Although, there is no direct link of these processes with other processes but these master records
become pre-requisite for certain processes.
Raising of a Debit/Credit Note with reference to Purchase Order (for Material / Service)
Raising a Debit/Credit Note without reference to PO (FI Credit Note)
2.5.8 Process specific User Roles & Requirements for the Authorization Concept
2.5.9 Quantification
In terms of Quantification, the posting of DR/CR Notes for Vendors will be considerably less.
The Transaction and Data Volumes is very less in number in respect of Vendor DR/CR Notes.
The frequency of the Vendor DR/CR Postings will be as and when required as per the Business
requirement.
Vendor DR/CR Currently Vendor Vendor DR/CR note is linked to MM Module and an
Notes DR/CR Notes are automatic entry gets passed through the integrated
manually as JV in
Venus System. Facility of posting DR/CR note through FI also possible.
Document Currently the In SAP there are two ways to reverse a document. 1.
Reversal Journal Entry is Individual Reversal and 2. Mass Reversal.
being posted
manually in Venus
Documents originated at different modules will be
System.
reversed from respective module only.
Open Item Currently in the Vendor Accounts which are maintained in SAP can be
Clearing Existing Venus managed through this Clearing functionality.
system there is no
facility of Vendor
Period end (Daily, Monthly, Quarterly, Half Yearly and
Clearing.
Annual) schedules to Vendor Accounts can be taken
directly from the system (list of Vendor open items after
manual clearing is done).
This process defines the procedure of effecting down payments to suppliers. As per the agreed
payment terms with the supplier, ABC pays advances to suppliers after creating a PO and receiving a
Bank Guarantee/LC from the Vendor. The advances are paid on the Down Payment request of
Procurement department with reference to the PO terms. Advances are issued by the accounts payable
department to the supplier and recorded in the supplier account and the same shall be cleared at the
time of supplier invoicing.
The following Business Requirements of ABC will be fulfilled with the below:
Revenue & Capital Advance should be appropriately noted. (At the transaction level)
It should be paid against approved Purchase Order (including contracts) as per the terms agreed.
Only in rare cases with specific approval, the advance payment will be made to the vendor without
reference to the purchase order.
Advances should be cleared against running bills/Final Invoice as applicable. In some cases, a particular
% (say 10%) advance is given for total contract. Billing is done in parts; in such cases that particular
% (in our case 10%) of advance will be required to be cleared from subsequent Billing.
Special GL indicator will assist in displaying Guarantees Vendor Wise/Down Payment wise.
Integration of GL with sub ledgers (AP) will ensure in displaying Guarantees as Contingent Liability
(Footnote of the Balance sheet) but, not as the item of P&L or Balance Sheet
Noted Item is the item shall not cover under P&L account or Balance Sheet
All types of Guarantees will be having two special G/L Indicator G for Guarantee.
Such Guarantees will be cleared upon the due date or closing date as per terms of agreement
User dept will be releasing Retention money as per Contractual terms & conditions.
Start
1 2
Accounts Payable Accountant
3 NO
Whether terms of the PO
matches with the request
YES
Process Vendor
payment YES 4 NO
Accounts
Manager
STOP
Payable
END
Process Steps
Step # Departmen User Role Process Description SAP Module
t
4 Finance AP Manager Validate the details and approve the same for FI
payment. If not the request can be deleted in
system
Down payment request will be raised by Central Procurement Department and clearing in the system shall
be made by Finance Department
System should show details of any advances paid against the same purchase order.
Down payments are made to various types of vendors i.e. Procurement/ Services/ Contractors/
Transporters/ Foreign/ Inter Company etc.
2.6.4.2 Guarantees:
Guarantees will be treated as Noted Items. . Guarantees made / received with Procurement / Service /
Sub-Contract Vendors as per agreed/ approved terms & conditions. These Guarantees will be cleared at
the end of the Contract / Agreement.
Guarantees are provided by the Banker upon the request of ABC from the Overdraft / Credit Limit of the
Company. So, it will not affect the Books of Accounts. It is just a Contingent Liability
2
MM Users
1 Central Procurement
Vendor makes a Dept. raise the request
request for outside the system to
Guarantee against provide the Guarantee to
a valid PO No. Vendor as per
agreement
Accounts Payable
5
Accountant
3 Prepare required
Whether terms of the document for
PO matches with the Banker and make
request a request to
provide Guarantee END
6
4 YES Bank Provides
Accounts
7
Manager
Payable
STOP
Guarantee request will be initiated by Vendor with concerned Procurement Department for the respective PO / SO / Contract
Guarantee request will be raised by Central Procurement Department at outside of the system
Finance Department will prepare required documentation and place a request with the Banker to Open a Letter of Credit/Guarantee
Receives the Guarantee form from the Banker & submit the same to particular Vendor by Finance Department
Vendor Guarantee will be recorded as a Noted Item and recorded with a special G/L Indicator
Guarantees are made to various types of vendors i.e. Procurement/ Services/ Contractors/ Transporters/ Foreign/ Inter Company etc.
Guarantees will be cleared in the system, as per or after the completion of term/ agreement
2.6.4.3 Retention:
Retention money deducted from Vendors running bills as per the terms of contract is required to be
released with last invoice on completion of work satisfactorily.
1 2
Vendor makes a Central Procurement
request for Dept. raise the
Guarantee against request outside the
a valid PO No. system to provide
the Guarantee to
Vendor as per
Accounts Payable
agreement
Accountant
5
Prepare required
document for
3
Banker and make
Whether terms of the END
a request to
PO matches with the
provide Guarantee
request
6
4 YES Bank Provides
Accounts
7
Manager
Payable
STOP
When Invoice verification done thru FI Invoice only or LIV (MM), user can select the amount or percentage
of retention for that particular Invoice.
The full Invoice amount (including retention amount) has to enter in Invoice verification transaction
Whenever the Invoice document posted, with the taking the reference of that posted document number a
back-end document will be posted by system automatically (This Development is doing to fulfil the special
requirement of ABC Company Limited, which are mentioned in the following)
If, User selected 5% on the Invoice Verification Screen and posted the document then the following entry will be
posted by system in back-end:
2) Vendor a/c . Dr 25 /
The back-end Document will be the FI document and posts with a special G/L Indicator R (Retention) with
a blocking indicator
In Vendor Account the Retentions will appears in another tab than normal Items tab. And normal open items
will appear as excluding retention amounts
In Balance Sheet Retention Payable item will appear separately under current liabilities (This is the special
requirement of ABC)
Normally Retention money is released in full or partly after completion of specified period or defect liability
period along with the final bill.
If the Contract with the vendor permits, retention money may also be released on submission of Letter of
Credit/Bank Guarantee (BG) during execution of the job / before expiry of defect liability period.
In case of any defect in quality of goods or services delivered by the vendor, the retained money is not
refunded /refunded partly to the vendor. The amount not refunded is treated as credit to relevant expenses
where original amount was debited and this will be recorded manually.
Finance Manager in Finance Dept. will remove Payment Block in the system for releasing the money.
The following Special GL Indicators are used for ABC for Handling
Advances/Deposits/Guarantees/Retention.
A K Advances
D K Security Deposits
G K Bank Guarantees
R K Vendor Retention
Create Down
Start payment request
F-47
Retrieve pending
Check PO terms
requests
FBL1N ME23N
AP Manager
No Yes
approval
Accounts Payable Finance Department
Post down
Inform payment
Procurement Paymnt
F-48 Doc
End
Print Check/
Check Bank Transfer
Bank transfer
Print Bank
Print Check
Transfer
FBZ5 FBZ5
Bank transfer
Check delivered delivered to bank
Printing/filing
to buyer
Procurem
ent
Process
1 Create down F-47 Daily Buyer A supplier down payment request shall be
payment created with reference to a PO, as per the
request agreed terms. The request so created
appears in supplier account automatically for
further processing to be done by AP
accountant.
2 Retrieve FBL1N Daily AP This report details the number of down
pending Accountant payment request existing against each
requests supplier due for payment
2 Check PO ME23N Daily AP Each payment request will be created with
terms Accountant reference to a PO. The AP accountant shall
check the PO for the compliance of terms
mentioned in the PO.
3 Approval by Manual Daily AP manager A final approval to release payment shall be
AP manager given by the AP manager. For any issues the
AP manager shall hold the approval and the
same shall be informed back to the
procurement department.
4 Post down F-48 Daily AP Upon approval of AP manager a down
payment Accountant payment entry will be posted to the suppliers
account. SAP classifies the down payments
as special GL transaction recorded in a
separate GL determined by the system
automatically.
6 Print a FBZ5 Daily AP A check or a bank transfer shall be printed
check/bank Accountant subsequently for each down payment posted.
transfer form
7 Check Manual Daily AP The down payment check printed shall be
delivered to Accountant signed and delivered to the buyer. A copy of
buyer the same shall be filed for record.
8 Bank transfer Manual Daily AP Bank transfer form shall be delivered to bank
form Accountant on daily basis.
delivered to
bank
9 Printing/filing Manual Daily AP Checks and bank transfer copies printed and
Accountant filed for official record.
2.6.8 Process specific User Roles & Requirements for the Authorization Concept
4 Finance AP Manager Validate the details and approve the same for FI
payment. If not the request can be deleted in
system
2.6.9 Quantification
In Terms of Quantification the Transactions and Data Volume in respect of Down Payment
Requests/Down Payments/Deposit/Guarantees/Retention will be considerably high
Automation of postings.
Advances/Deposit/G Currently the Journal Down Payment Request automatically gets generated
manually in Venus
Down Payment Request will be converted to Down
System.
Payment and post to Financial Accounting.
Advances/Deposits/Guarantees/Retention will be
handled in SAP through a Special GL Indicator.
All the Retentions of Vendors are uploaded using data migration program during the Go-Live phase
2.7 PROCESS MODEL LEVEL 3, BUSINESS PROCESS 4 HANDLE VENDOR LETTER OF CREDIT
This scenario describes the process of importing goods into your country using a letter of credit for
payment.
Noted Items:
Special G/L transactions are also used to manage noted items. These are postings that are not
displayed in your accounts but are only to remind you of outstanding payments due or to be made. This
special document does not update the account balance: it is merely managed as a line item in the open
item account and the special G/L account. Because of it should always mark the Line item display option
for these G/L accounts.
User should be able to decide the amount limit for which Automatic payment run should be done.
Vendor Start
1 NO
Request to 2
end
open Letter of Approved L/C?
Credit
YES
4
Receive & Request the Banker 3
Accounts
Manager
Payable
5
Clear the L/C when
closed with using
different posting key
end
As an importer, ABC request a quotation from the exporter for the products/ goods want to purchase.
This may or may not include transportation and insurance costs.
Once ABC receive the quotation, it creates a purchase order based on the offer ABC received from the
exporter.
The exporter creates a pro forma invoice and sends it to ABC.
Upon the receiving of the vendor pro forma invoice (finance / procurement dept.) procurement
department requests the finance department via various communication channels to open a Letter of
Credit.
ABC open a letter of credit with the opening bank in the country of destination (Import country). This
involves informing the opening bank of the documents which ABC require from the exporter. As an
importer company not only need the documents required by customs, but also the documents that are
required by any other agencies regulating concerned good.
ABC creates a Letter of Credit in SAP as a Noted Item (single line item).
Noted Item will not update the Books of Accounts. The entry will be as follows:
ABC get import Letter of Credit to provide its vendors with the banks undertaking that they will receive
payment upon delivery of those documents specified in the Letter of Credit within a stipulated time. For
ABC, as an importer, using a Letter of Credit reduces the risk of having to pay in advance for products/
goods or pay for any products or services that are not consistent with the product descriptions in the
Letter of Credit.
With Letter of Credit, the vendor does not need to ask for shipments to be secured by cash in advance
and ABC may obtain better pricing if the vendor is assured of a Letter of Credit.
The opening bank sends the Letter of Credit to the advising bank in the exporter's/ Vendors country.
The advising bank advises the exporter that a Letter of Credit has been opened in their favor.
The exporter/ vendor ships the merchandise in accordance with the terms stipulated in the Letter of
Credit.
The exporter gives the documents proving that the shipment was made in conformance with the letter of
credit to the advising bank.
The advising bank pays the exporter based on the documents received.
The advising bank transfers the documents to the opening bank and receives payment.
The opening bank gives the documents to ABC (the importer). ABC clear the concerned Noted Item
ABC submits those documents to the clearing house agent to release the shipment.
And ABC performs the MM- GR process in SAP.
Letter of Credit process has no direct link with the Financials. It will be treated as a Noted Item for
Information and control in the Financial Books.
Company Code
Chart of Accounts
Vendor Groups & Accounts
House Banks & Bank Accounts
Special G/L Indicator for LC Noted Items
2.7.8 Process specific User Roles & Requirements for the Authorization Concept
2.7.9 Quantification
In Terms of Quantification the transaction of Letter of credit posting will be as per the Business
Requirement as and when required.
The Transaction and Data Volume is comparatively less as and when Business requires.
Letter of Credit Currently Letter of All Letter of Credits will be posted into 1 G/L account
Credit are being
At the time of posting PO reference will be given so,
maintained
with that reference Opened Letter of Credits can be
Manually in a
tracked
Register
Open Letter of Credits can be monitored with the status
as Open or Close
This process defines the process of Plan/Schedule Vendor Payments Automatically in the SAP
System.
User should be able to define which vendors should be covered in automatic payment run.
User should be able to decide the amount limit for which Automatic payment run should be done.
Automatic payment run should also be done with respect to a specified date, say document entered
from and up to a particular date.
Automatic Payment run will be done at Company code / vendor account / at line item level.
Run Proposal
Accountant
Accounts
Payable
1 2 3
Enter Available amounts and Run Proposal with Pass information to AP Manager
validate Ranking order Bank Automatic Payment with Proposal Run ID
wise Program NON-SAP
Accounts
Manager
Payable
5
4 Send Proposal List to 6 Process
Generate First Generate Final Vendor
Run Proposal and approving authority & Edit Proposal and
Proposal List Proposal List Payment
generate Receive approved schedule for Payment
Proposal List List Program Run HI_FI_AP_03_
NON-SAP 06
If there are several house banks that to use for payment transactions and have limited funds in these
accounts, 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 it has to enter the order in which the bank accounts are selected
Once the parameters for the proposal run are completed, it can schedule for the payment proposal or
immediately can be done.
It is possible to make changes when editing the payment proposal. It can make changes to the payment
(payment method, house bank) and the items paid (block indicator, cash discount). All changes made
affected only in the payment proposal. No changes are made to the source documents
2.8.8 Process specific User Roles & Requirements for the Authorization Concept
2.8.9 Quantification
In terms of Quantification the transaction will be on a daily basis as per the requirement of the Business.
The Data Volume will be comparatively less for ABC.
Plan/Schedule Vendor Currently in the Proposal is the guide line to co-ordinate with available
Payments existing system funds in the organization.
there is no system Based on importance or Payment terms the payment can
for planning Vendor be selected or editing can be done.
Payment
Approval authority will be the final
System should not allow payment run if the total amount of payment covered by the
payment run exceeds the clear balance in the bank a/c and/or overdraft limit unless it is
authorised by a higher authority.
Supplier/Procurement
Initiate payment
Start request
F-59
Prepare payment
due list
FBL1N
AP Manager
No Yes
approval
Payments
posting by
Hidada
Hold/ inform
concern dept.
Clear Advances
Accounts Payable Finance Department
Clear Invoices
Post
F-53 intercompany
Payment payments
document F-53
Post payments
Payment
document
F-53
Print Check/
Check Bank Transfer
Bank transfer
Printing/filing
End
Automatic
payment run
GR/IR Data
System to generate a
proposal list of all the
vendors bills as per
the criteria by user
YES
Generate Automatic
Payment Payment
Advice Program
Posting to vendors
A/c, Printing of
cheque / For Bank In case of net NO
Transfer, generate transfer
whether E-
Letter
signatured ?
YES
Signing of END
Cheque / E- Post to vendors
signature ledger and also
credit by bank to
the vendor
Handover to
Vendor
Payment document will be posted using automatic payment functionality for Banks specified
above.
Mode of payments will be Cheque, Bank transfer, Bank for payment against documents, or
through LC (letter of credit).
o Vendor Payments (Normal items, Down payment, release of Retention money, etc)
o Lease Rent
o Compensations
o Staff payments
Initially ABC will be using Manual Payment Process. But the Automatic Payment Program
Set up also will be available for future use.
Finance Dept. will ensure to use correct payment terms, payment method, House banks &
check lots etc. for accurate payments.
Reimbursement to staff will be against Cash Journal, payment vouchers or direct bank credit
(if employees bank accounts are maintained).
Customer Refund/payment if any will be exceptional in nature & will be made only on specific
request/advice from Marketing.
Advances paid if any will be recovered from subsequent billing as explained in LIV process
Manual Payment/Payment Proposal/ exception list will be analysed & edited by Finance Dept.
if required.
Final payment document will be posted manually or by Automatic Payment Problem &
payment list will be printed.
Cheques will be manually written initially and in future cheques printed on pre-printed Bank
Cheque Stationery (pre-printed as a crossed a/c payee cheque) for cash withdrawals (i.e. for
self) the pre-printed a/c payee crossing will be manually opened.
Payment list & Cheque Register will be printed & signed by Cash officer.
Cheques will be signed by authorised signatories along with payment list/ cheque
register.
Cheque register will be available from the system. Payment vouchers will be signed
by Cashier & Payee wherever received directly.
Signed cheques together with Payment advice would be handed over /despatched to
Vendors /Staff etc.
As and when required the single payment can do through manual payment process even in
Future.
AP Manager enters the required data and select against/ reference line items and make the
payment for manual payment process
A payment against an invoice clears or settles the outstanding invoice amount in the vendor
account. System will display the list of open items or unsettled invoices from the vendor
account, for which the payments are due. Specific open items can be selected based on the
various parameter such as bill amount, due date, document ref no. etc. System will pass the
following entry on posting the payment against open item.
Vendor a/c Dr
Partial Clearing
There are instances of terms of the purchase that allow payment to be made to the vendor in
installments over a period of time. In these cases the outgoing payments made to the vendor may
not settle the invoice in full but only partially. If the Partial Clearing is used, system will post a line
item in debit for the payment made. The system however, will not clear the invoice till the entire
invoice amount is cleared and all such line items are shown as open items till the time it is fully
cleared.
However the disadvantage of using partial clearing method is that both the items i.e. the invoice
and the part payment in the above example remain open items. Hence the ageing analysis shows
skewed results as the invoice amount credit is shown from the date of the invoice date and the
part paid amount is shown as debit paid from the payment date.
Residual Clearing
Residual clearing is also used for clearing open items in case of part payment etc. In case of
residual clearing the system clears the open line item to the extent of payment made and
generates a new line item for the balance payable. The default baseline date for the new
document will be Residual document date; however, the date may be changed to any other date.
There may be some vendors for whom certain % of the Purchase order value will be retained as
retention money and will be released only after a period of time. The Purchase Order shall
capture this information. The retention money shall be transferred from the normal balances to the
special GL balances in the vendor account. The system will also keep a track of all these
retention moneys and the due dates when they become payable. The retention money will be
distinguished by the use of a special G/L indicator. The financial entry will be as follows:
For example - There is a vendor invoice of SAR 10,000/-. A part payment of SAR 9,000 is made
for the invoice and SAR 1000/ is to be keep as retention money.
Whenever the retention money is to be released, the vendor a/c (with special GL indicator) will be
debited.
In case of foreign currency transactions the difference in the invoice amount and the payment
amount will be accounted to either the exchange rate gain / loss account. The standard accounts
for loss and gain as defined in the Chart of Account shall be used for this purpose.
The following is an example of booking of import invoice in USD, its corresponding payment entry
and booking of the exchange rate fluctuations.
OR
Payment Entry @ 3.69 SAR: 1 USD
2.9.9 Process specific User Roles & Requirements for the Authorization Concept
Step # Department User Role Process Description SAP T Code
Module
2.9.10 Quantification
In terms of Quantification this process transactions and data volume will be considerably high.
Vendor Payment Currently there is Proposal is the guide line to co-ordinate with
Process no Automatic available funds in the organization
Payment Program Based on importance or Payment terms the
in the Venus payment can be selected or editing can be do
System.
Integration of GL with sub ledgers (AP) will ensure
The Checks are
in displaying open items as on a particular run
handled manually.
date
2.10 PROCESS MODEL LEVEL 3, BUSINESS PROCESS 7 PROVIDE VENDOR ACCOUNT CONFIRMATION
This process defines the procedure of sending supplier account statements to suppliers.
Supplier accounts are updated with down payments, invoices, payments and clearing
transactions on real time basis. All such information is sent to supplier in a required, pre
defined and organized format. Supplier account statements are sent on periodic basis or as
requested by the supplier. A statement may be a supplier transaction history for a required
period, monthly account statement or an open item (due items) statement. Supplier account
statement may facilitate in updating a supplier of his till date transaction, periodic account
reconciliation.
1
Automatic Manual
Vendor Account
Clear Automatic /
Accounts Payable Accountant
Generate Final
Vendor Account
Balance
Confirmation
3
Passed information
to AP Manager for
Review & Approve
NON-SAP
Accounts
Manager
Payable
4
Reviewed and
Approved the
same NON-SAP
2.10.8 Process specific User Roles & Requirements for the Authorization Concept
4 Finance & AP Manager Open item clearing will F-44 Manual Account
Accounts be done from the Vendor clearing,
account.
F.13 Automatic
clearing
2.10.9 Quantification
In terms of Quantification prescribed transactions needed to be executed and the Data
Volume will be considerably high.
Vendor Account Currently in the Open items analysis & clearing by User Dept.
Confirmation Venus system, no
Regular analysis/monitoring/clearing of Vendor open items
Account
will ensure correct outstanding in vendor account
Confirmation
reports are being
generated.
Reports
AccountPa
Manager
yable
1 2 5
3 4 6 7
Displaying Displaying / Displaying
Vendor Vendor Vendor Other SAP
Vendor Changing Vendor
Master Data Special G/L Ageing Standard
Document Vendor Line Account
List Transactions Report Reports
Journal Items Balances
Vendor Items
Master Data
PaymentTransactions
2.11.8 Process specific User Roles & Requirements for the Authorization Concept
Step # Department User Role Process Description SAP Mod T Code
2.11.9 Quantification
In terms of Quantification prescribed transactions needed to be executed and the Data
Volume will be considerably high.
Accounts Payable Currently in the Open items analysis & clearing by User Dept.
Reports Venus system, no
Regular analysis/monitoring/clearing of Vendor open items
Accounts Payable
will ensure correct outstanding in vendor account
reports are being
generated. Vendor Ageing Reports
3 SOLUTION TRANSFORMATION
The use of FI vendors in the Blueprint should be strictly controlled and be limited to
Utility Bills (Gas, Water & Electric) only where fixed contracts with vendor does not
exist
Audit Fees (Nominated without a contract)
Zakat
Payment of Dividends
By specifying more than one ordering address and Invoice Address in the vendor master
record, the partner functions screen would allow options to select which Ordering Address
and/or Invoice Address to use whilst creating the PO.
Vendors registered and pre-qualified outside of SAP. This would ensure Single repository
of Information, with single point responsibility for vendor master data maintenance
Vendor numbers will be generated internally using SAP (Vendor Account groups will be
given number range)
There are four major Vendor groups recommended for use within the Blueprint:
FI vendors would be created for vendors that invoice without three way matching (no PO
GR/SR stage)
The aim is to standardize the creation of Vendor Master Records for ABC Company.
Fore more details of technical & functional, kindly refer the MM Master Data Blueprint
Vendor Management
EBPro
Vendor Vendors
qualification Purchase
materials /
services
Manage
Identification vendor
Receive &
Of Vendors Vendor invoices
put away
master materials
Payment maintenance
Methods
Vendor
Bank performance
Details Block/Unblock
Vendor Master analysis
Record
The Vendor Master will contain all data relating to Vendors, for both goods and services. Apart from
the name and address of a vendor, the vendor master record will contain data regarding the currency
and payment terms, as well as names of important contact persons.
A Vendor Master Record consists of three sections of data: General Data, Company Code Data, and
Purchasing Organisation Data. The General Data part will consist of all the data which applies across
all companies such as address details, contact information, bank account details. Company Code
Data contains data that are unique per company such as house banks (from which to obtain
payment), payment methods (bank transfer, bank draft, cheque). Purchasing Data will be maintained
per Purchasing Organisation, which will include all information relevant to Contracting and
Procurement, such as contacts, delivery terms etc.
Once the data is converted, control is required to ensure that legacy data is complete and converted
successfully. It will then be used to compare uploaded records with legacy data.
Below are a few guidelines on how the data should be verified for this data object:
a) For Company Code Extension - Execute transaction MKVZ to generate the vendor list.
b) For Assign Customer to Vendor Master - Execute transaction MKVZ to generate the vendor
list
Transaction S_ALR_87012086 to generate the vendor list for a specific company code.
3.1.6 Roles
S_ALR_87012103 List of vendor line This report gives the list of line
items items per vendor account. The
details include the document
(invoice) number, reconciliation
account, posting dates and
amount. (This is similar to report
List of vendor open items, but it
has different selection options, i.e.
the clearing date range)
S_ALR_87012104 List of cleared vendor This report gives the list of cleared
items items per vendor account. The
details include the document
(invoice) number, reconciliation
account, posting dates and
amount.
S_P99_41000099 Payment List This report gives the details about
Payment Proposal Run for the
specified date and identification
feature.
4 SYSTEM LANDSCAPE
Final Authorization matrix will be given at the time of User Acceptance Testing
5 GLOSSARY
Term Explanation
Residual Payment Clears the invoice and the payment to create a new open item
5.1 APPENDIX
NIL
5.2 REFERENCES/BIBLOGRAPHY
NIL