Cash Forecast2

SAP SCENE
Anna-marie Redpath
CashForecast Guide
Copyright  Anna-marie Redpath 2002
19 Nassim Hill, # 01-04 Nassim Woods, 258482, Singapore
Tel (65) 9735-5264
OR
36 Upper Cliff Road, Northwood, NSW, 2066, Australia
Email: Anna-marie@Sapscene.com
Copyright  A nna-marie Redpath - The information on these pages may not be reproduced or republished in any form without permission and acknowledgement
Table of Contents
I n t r o duc t i on 2
B an k Ter m i n o l o gy i n SA P 3
SAP GL Ban k an d Ba nk r el a t ed A c c o unt s 3
Run n i n g t h e Ca s h Po s it i on o r Fo r e c a s t Enq u i r y 7
U nd e r s t a nd i n g t h e Bu s i n e s s Re q u ir em e n t s9
Dat e s a n d t h e Ca s h Fo r ec a s t 10
Cas h Fo r e c as t T e rm i no l og y 11
Cas h Fo r e c as t Co nf i g ur a t i o n 14
M ai n t ai n i ng t he St ru c t ur e of t h e Ca sh Po s i t i o n an d Fo r ec a st 15
A dd i t i ona l Co nf i g ur a t io n an d Fu n c t i ona l i t y1 8
I n t e g r at i n g M M and SD 18
B l o c k e d I t em s 19
Pl a n n i ng T y p e s 19
Di s t r i bu t i on Fun c t i o n 19
Sp ec i a l GL Tr an s a c t i o n s 21
Rel a t e d Co nf i gu r at i o n o r Fu nc t i o na l i t y 22
Pr e p a r in g Te st d at a f o r Ca s h Po s i t i o n a n d Fo re c a s t 23
Co p y r i g h t  A n n a-m a ri e Red p a t h - T he i n f o r m a t i o n o n t h e s e p a ge s m a y n ot b e r e p ro d u c e d o r r e p u bl i s h e d i n an y
f o r m w i t h o u t p e r m i s si o n a n d a c k n o w l e d g e m e n t
Int roduc t ion
The “Cash position and forecast enquiry” is usually used by the Treasurer or person responsible
for ensuring that the company has adequate funds for expected outgoings.
The Cash Position input data is the known balances:
Postings in cash and bank accounts (any GL account relevant to cash management),the
unreconciled entries in the GL bank clearing accounts (uncashed cheques etc), and
any memo records which may have been manually entered (planning advices) as relevant
to a cash position
cashflows from transactions managed in Treasury Management.
Examples are:
bank balances
outgoing checks posted to the bank clearing account
outgoing transfers posted to the bank clearing account
maturing deposits and loans
notified incoming payments posted to the bank account
incoming payments with a value date.
The Cash Forecast input data is the summary of the expected financial incomings and outgoings
in the subledgers:
Accounts receivable and Payable open items (expected incoming and outgoing
payments),
SD Sales Orders and MM Purchase Orders (expected incoming and outgoing payments),
Special GL transactions as required,
Memo records (planning advices).
Planned payments of wages and salaries,
Planned payables for taxes on sales and purchases.
It is possible to use the one enquiry to cover both position and forecast. The configuration is the
same. For simplicity I will often refer to cash forecast to cover both the cash position and
forecast.
2
Co py r i g h t  A n na -m a ri e Red p at h - Th e i n f o r m a t i on on t h e se p a g e s m a y no t b e r e p ro d u c e d o r
r e pu b l i s h ed i n a n y f or m w i t h o u t p e r m i s si o n a n d a c k n o w l ed g e m e n t
Bank Ter m inology in SAP
In SAP the Banks where the company holds banking accounts are called House Banks.
The SAP system also holds a bank directory, which contains details (name, address etc) of all
banks that the company may have dealings with. So other banks that the company receives
customer payments from or makes vendor payments to, will simply be banks in the SAP bank
directory - they will not be SAP House Banks.
A House Bank is still listed in the bank directory. The bank directory can be loaded electronically
from a file in standard format; or it can be maintained manually whenever a new bank is
referenced. The bank directory is referenced or maintained when direct payment or direct
customer debit details are entered on the vendor or customer master record, or when a new
house bank is created.
The company could have several bank accounts at each house bank. Each bank account may be
assigned a Cash Management Account Name that is a mnemonic name. This can be used instead
of having to refer to the account number.
Each of these bank accounts needs to be represented in SAP. Depending on the purpose of each
account and therefore the required functionality in the system, there may be multiple SAP GL
accounts (a main account and clearing accounts) for each bank account.
SAP GL Bank and Bank relat ed

Ac c ount s
The objectives of the SAP GL Bank and Bank related accounts are:
The main bank account should also reflect the balance as per the last loaded bank
statement (the ideal situation is to load and reconcile the bank statement at least daily)
The related bank clearing accounts will list the items that are unreconciled as per the last
statement or latest processing
The total picture of all these accounts is the situation that the company expects to be in if
all cheques had been cashed, all payments had been cleared, deposits entered etc.
To start off with, lets take a simple scenario where the company has one physical bank account
held at an actual bank. The company makes payments and receives deposits into this bank
account. In SAP Banks where the company has accounts are called the house banks. Other
banks that the company receives customer payments from or makes vendor payments to will
simply be banks in the SAP bank directory - they will not be SAP "house banks".
The company could have several accounts at this house bank. Each account should be
represented in SAP by a separate GL bank account. Depending on the use of that account there
3
may also be related GL accounts in SAP. Configuration and use of these related accounts is
simplified if a standard numbering structure is followed.
Following is a simple example using the standard SAP Chart of Accounts numbering:
SAP
GL Account
GL
name Description
Account
(example)
Number
First Bank The account that should always reflect the transactions and
113100
account balance as per the last bank statement.
This is a clearing account which is

Debited by the bank statement or cashed cheques
upload programs
Credited by the payment program when a payment is
made to a vendor
Uncleared credit items reflect payments that have not been
Outgoing drawn against your bank account (eg: uncashed cheques).
113101
Payments
Uncleared debit items would be a worry if they happened,
since they would represent a payment issued from your bank
account without prior knowledge or entry of it in the SAP
system.
If you had multiple outgoing payment methods (local cheques,

telegraphic transfers etc), you could have multiple of these
accounts with appropriate names of course.
This is a clearing account which is

Debited by the cheque deposit program when a
cheque is received at the company and that receipt is
recorded in the system
Cheques Credited by the bank statement by the entries
Received or representing the received cheques deposited at the
113108 bank
Incoming
Payments Uncleared debit items reflect payments received that have not
been deposited in the bank account yet.
Uncleared credit items could be payments made by customers

directly into the bank account and hence you may have no
matching entry in the system yet.
4
This is an optional clearing account that need not be bank
specific. It is
Credited by the cheque deposit program when a
cheque is received at the company and that receipt is
recorded in the system
Debited when that received payment is allocated to
the customer open items, as the contra entry of
Unallocated allocation transaction
113117 Customer
Uncleared debit items could be a real worry! Check for fraud!
Payments
Uncleared credit items should represent payments (cheques)
received (and possibly deposited already), but have not yet
been allocated to the customer open items. Ideally this should
happen automatically, but sometimes manual intervention is
required. For this reason, you may want to consider reporting
this account with your customer control account to accurately
reflect the total debt outstanding.
Each different bank account should have it’s own set of clearing accounts, following the standard
numbering. Following a standard numbering structure will greatly simplify configuration of the
Treasury Basic Functions. So a second bank account could be named and numbered as follows:
Number Account name
113200 Second bank Account
113201 Outgoing Payments - second bank
Cheques Received or Incoming Payments -

113208
second bank
5
Simplified example of how postings are made using standard SAP bank clearing accounts:
Bank Account
113100 Vendor Customer
150 100 100 Invoice 100 Invoice 150 150
Balance 50
Outgoing Payments Incoming Payments Unallocated Customer Payments

113101 113108 113117
100 100 150 150 150 150
Payment to vendor
Debit Vendor 100
Credit Outgoing Payments 100
Cheque Received (Cheque Deposit Process)

Debit Incoming Payments 150
Credit Unallocated Customer Payments 150
Payment allocation process (session created by Cheque Deposit Process)

Debit Unallocated Customer Payments 150
Credit Customer 150
Bank Statement Upload (eg day 1)
Deposit Slip (Cheques etc)

Debit Bank Account 150
Credit Incoming Payments 150
Bank Statement Upload (eg day 2)
Payment (Cashed Cheque)

Debit Outgoing Payments 100
Credit Bank Account 100
6
Running t he Cash Posit ion or Forec ast
Enquir y
Following are some guidelines on running the enquiry. Note that you will not get useful results
from the Enquiry unless
it has been appropriately configured for your data,

the master data has been populated, and
useful transaction data has been posted since the configuration and master data setup (or
the update program run.
For demonstration purposes it is a good idea to get some realistic data from the treasurer (bank
accounts & names, representative amounts etc) so that the users can relate to the figures. You
could consider posting transactions to represent the days current real situation - with a little bit of
preparation, this is not that hard. See ’Preparing Test Data’.
Menu: Treasury > Basic Functions > Status > Cash Position or Forecast
The purpose of most of the parameters can usually easily be determined by going to the
parameter entry screen (follow the menu path above) and for each parameter pressing :
Field help (F1 or ?) from the field, to see the SAP explanation or description of standard
possible entries
list of values (F4 or drop down arrow).
The key parameters are described below:
Parameter Explanation
Defines the
scope of the enquiry (what accounts and what transactions) and the
initial presentation or summarisation of the data.
Grouping
It is possible to use just one grouping for a complete enquiry. Usually there
should be groupings called perhaps :
’Banks’ for the cash position and
’Total’ for a complete cash position and forecast
Usually today’s date, however could be used to take a look into the future
Display as of without scrolling across, and/ or for training or demonstration purposes
when the test data is not up to date.
Display Type ’Balances’ will show the expected balances over the requested time period.
7
Parameter Explanation
’Delta’ will show only the expected changes over the requested time period.
’Delta with Balances’ will show a total balance for all lines and then the
expected incoming and outgoing changes
This can be changed on the fly within the enquiry.
Determines whether the balances or deltas amounts are shown summarised

by day/ s, week/ s or months. Allows the user to take a detailed short term
Increment view or a longer summarised view.
This can be changed on the fly within the enquiry.
Optional. Used to select ONLY the transaction amounts where the

Planned
transaction currency = the entered currency. Otherwise all transaction
Currency
amounts will be displayed.
Display in Optional. The currency in which you wish the display to be made.
FC/ LC and
LC/ FC Optional. The rate types to be used for foreign to local conversions an dvice
exchange versa.
rate
Optional. Specify whether expected amounts should be ’distributed’ by the

Distribution configured percentages to more accurately indicate the spread of expected
funds.
Once you have entered suitable parameters and executed the transaction, you will first see a
summarised display controlled by the grouping you have selected. The level of summarisation is
controlled by the ’summarisation terms’ in the grouping configuration. For example this could be
a line for each bank showing the total of all balances at that bank.
By ’double clicking’ on a line, the screen will then display the ’groups’ for that bank. For GL
accounts (cash position) this is the bank account level. For the cash forecast this could be the
expected amounts by classified customer or vendor.
By ’double clicking’ on a line, the screen will then display the ’planning levels’. This is sort of a
summarisation by transaction type. For the cash position, this is likely to be at the clearing
account level, since each clearing account represents a transaction type (eg: uncleared cheques).
For the cash forecast this could be sales orders, purchase orders etc.
Double clicking further should take you to a line item display or further detailed report.
8
Explore all the menu options that you have available within the execution of the enquiry. Their
functioning is usually fairly self explanatory. If you are having difficulty relating to the display,
you may wish to post some data and see how the effects are reflected in the cash forecast. See
’Preparing test data’.
Underst anding t he Business

Requirem ent s
Before you can configure the SAP system to provide an effective cash forecast, it is important to
gather and understand the following business requirements:
Business Requirement Question Affected Configuration
What fund holdings does the treasurer need to see? what bank GL Account Master
accounts, "on call" accounts etc records
TR Cash Management
How should these be grouped or named?
Account Name
What sort of incoming and outgoing financial transactions

(cheque, EFT, telegraphic transfers, direct debit etc) does the
TR Planning Levels
company have ? This knowledge is also required for payment
program and bank statement functionality
Do customer and/ or vendor payment transactions differ (in a way

that is of interest to the treasurer) by type of vendor/ customer ? Is
TR Planning Group
it possible to identify and categorise the customer or vendor by
on AR Customer and
this type ? For example: perhaps certain customer types pay their
AP Vendor Master
bills less reliably than others ? or you may want to classify overseas
vendors separately from domestic vendors
Does the company have an understanding of the likelihood of

payment under the various methods and are they able to identify TR Percentage
how to ’spread’ the expected amounts over time for the best Distribution by
overall net expected incomings and outgoings ? (see specific planning level
configuration area for more details)
What would be a meaningful level of detail or summarisation of all

of the above information for the initial view of the cash forecast?
(You may find that the treasurer will need to work through some TR Groupings and
demonstrations with realistic data before this can be reasonably Structure
identified. Try setting up a variety of groupings initially to
demonstrate what is possible and facilitate a decision.
9
Dat es and t he Cash Forec ast
The cash position and forecast enquiry will report the incoming and outgoing financial amounts
by the "planning date". The planning date is the date at which the specified amount is expected to
be paid or received. Depending on the type of transaction, the planning date will be derived from
other information as follows:
Module Term Explanation
The value date should be specified on the line items which are
posted to the GL bank and bank clearing accounts. It is the date
at which the transaction is expected to be effected at the bank.
For example the value date specified for a batch of cheques
GL Value Date entered via the cheque deposit transaction should be the date at
which is expected that the batch will be deposited at the bank.
This may not be the same date as the posting or document dates.
It is usual that the field status group for bank related accounts will
have value date as a mandatory field.
The Payment date is determined by the payment terms, possibly

adjusted by payment history (if the ’record payment history’
option has been selected in the credit management section of the
customer master. If a customer normally takes up the cash
discount 1 option, then the baseline date plus the number of days
to cash discount 1 will determine the planning date. It is
AR & Payment important to understand payment terms and how payment
AP Date history works. Refer to the appropriate AR, AP and credit
management sections.
The Planning date can also be switched on for entry to allow

manual override of the system defaulted date. Click on ’more
data’ in the line item to see the planning date if it has been
switched on (on the planning group field).
Planning On payment advice’s or memo records, the planning date is

TR
Date entered directly.
10
Cash Forec ast Ter m inology
First let us look at the cash position and forecast terminology. Then we will look at how to pull
the whole thing together. Note that you will also need to have at least a rudimentary
understanding of the related configuration areas.
Ensure that you understand the planning levels and groups below. It is awkward terminology and
codings, however they are central to the Cash Forecast. A transaction will not contribute to the
Cash Position and Forecast unless it is coded by planning level and planning group. This coding
or flagging will be achieved through the master data setup and configuration as indicated.
Terminology Explanation
This is one of those not very exciting pieces of configuration that just has
to be there, but doesn’t seem to add a lot of value. Basically you should
Source
have 4 codes for bank, subledger, MM and SD. The bank source symbol
Symbol
should be flagged as cash ’position’ and the others as ’forecast’ related.
Planning Levels will then be allocated to these source symbols.
These indicate the type of business transaction and it’s origin, and
therefore it’s degree of reliability (a bank balance is very reliable, whereas a
expected incoming amount based on a sales order from a dubious
customer is lot less reliable.)
The Planning levels are specified:

on the GL Account master records for accounts of interest to the
cash position
by transaction type for memo records
(Planning) by allocation to a source symbol (indicating MM or SD).
Levels
Standard SAP has the following planning levels:
level F0 for bank accounts
level F1 for customers and vendors
levels B1 to Bn for bank clearing accounts
level CP, for example, for confirmed payment advice notes
level UP, for example, for unconfirmed payment advice notes
level NI, for example, for noted items
levels M1 to Mn for updating data from MM
levels S1 to Sn for updating data from SD.
Planning Groups allow one to analyse Cash Forecast further by classifying
Planning customers and vendors. It would be meaningful to classify them in a way
Groups that related to their likelihood of paying or perhaps nature of payment.
The Planning group is specified on the Customer or Vendor Master

11
Record.
Standard SAP uses the examples:

O1 Domestic vendors
O2 Foreign vendors
O3 Affiliated companies: vendors
O4 Major suppliers
I1 Bank collection: customers
I2 Domestic customers
I3 Foreign customers
I4 Risk customers
The planning groups are allocated to planning levels.
Note that for GL accounts, the GL Account Number is effectively the

planning group (ie: one cannot specify a planning group on GL accounts).
This is important to remember when we come to the Cash position and
Forecast structure configuration.
Used in the execution of the enquiry to select the scope and initial
presentation of the data. Groupings are basically just a combination of the
Grouping
planning levels and groups above that are defined in the structure
configuration.
Summarisation terms are used to summarise planning levels and groups

Summarisation for the groupings (isn’t terminology wonderful - summarising and
Term grouping all over the place!). This will become clearer through the
examples below.
12
We talked briefly about the planning levels indicating the ’reliability’ of the
expected incoming or outgoing flow of funds.
For example:
a bank balance is 100 % reliable - we already have the funds,
an uncashed cheque may be 95 % likely to be cashed tomorrow,
a AR invoices for a bad customer group may be 70% likely to be
paid on time, 20 % two days late and maybe 10 % not at all
If these statistics are known, they can be used to configure a ’distribution’
of the value amounts for an optional alternate display, which may give the
viewer a better overall idea of net expected fund flows.
You can do this by specifying in percentages, how much of an amount

planned within a certain period is to be listed in the display for the cash
Distribution
management position or liquidity forecast, and when should the amounts
(optional)
be shown.
In this way you include the uncertainty for some items of the expected
date of payment.
For Example, an analysis of unconfirmed payment advices may show that

50 % of total amounts actually come in on the expected day, 30 % come
in later and 20 % a day earlier. You could then configure this distribution
for unconfirmed payment advices:
50% on the expected day,
30% one day later,
20% one day earlier.
Note that the user has control over whether the distribution is used or
not, by specifying a parameter on the cash forecast screen.
13
Cash Forec ast Configurat ion
Ensure that you have read and understood the terminology and business requirements sections
before starting this section. The Cash Position and Forecast Enquiry Configuration is actually not
that hard to setup if you have an understanding of your company’s business requirements.
Most of the configuration steps are fairly straightforward, you should be able to complete them
fairly easily, using the SAP help if necessary. I shall present two checklists of the configuration you
need:
the essential configuration for a basic cash position and forecast (GL and subledger),
the additional configuration to include MM and SD, payment advices and special GL
transactions.
The piece of configuration that requires a decent explanation is the ’Structure’ of the Cash
Forecast. This is presented in more detail with some examples. I suggest you develop a number
of variations for demonstration purposes, with some good test data.
Essent ial Configurat ion and Mast er Dat a Set up Chec k list
Menu Path Comment
IMG > Treasury > Cash Management >

see explanation in terminology
Basic settings > Define Source Symbols
This may already have been done in GL, AR

and AP.
The GL Account Groups must have the

IMG > Treasury > Cash Management > banking fields mandatory or optional.
Master Data > GL & Subledger > Define
Account Groups & Field Status Group The AR and AP Account Groups must
have planning group as mandatory
The field status group for GL Bank

accounts should ’value date’ as mandatory.

Master Data > Define Planning Levels

Master Data > Define Planning Groups
Ensure that all accounts required in the Cash

Accounting > Financial Accounting >
position have the appropriate account
General Ledger > Master records > Change
group, planning level and field status group
14
Menu Path Comment
Ensure that all customer and vendor master

Accounting > Financial Accounting >
records required in the Cash forecast
Accounts receivable & Payable > Master
(normally all) have a planning group
records > Change
specified
IMG > Treasury > Cash Management > Give all bank accounts a mnemonic name.
Structuring > Define Cash management This may already have been done as part of
Account Names the bank setup for other bank related areas.
This is the key piece of configuration that

will control the appearance of the cash
Structuring > Groupings > Maintain
position and forecast. See below for
Structure
examples of how to set it up.

Define headings for the cash position and
Structuring > Groupings > Maintain
forecast
Headings
M a i n t a i n i n g t h e St ru c t u r e o f t h e Ca s h Po s i t i o n a n d Fo r e c a s t
Menu Path: IMG > Treasury > Cash Management > Structuring > Groupings > Maintain
Structure
This is the main piece of configuration that you will find yourself coming back to as you refine the
display of the Cash Position and Forecast. There are some key points here that tend to confuse
people:
Both planning levels and groups are linked to the structure using the same configuration - each in
their own lines. The only difference is that the ’type’ column will indicate whether levels or
groups are being specified in that row.
The "summarisation term" is key to controlling the first display screen of the Cash Position and
Forecast. You can control the level of detail that appears by linking more or less levels and
groups to a summarisation term.
You can define multiple groupings referring to the same levels and groups
If a level or group is not linked to a grouping, then it will not appear in the Cash Position and
Forecast when that grouping is used.
For GL purposes, the group is the account number (10 digit number)
Wildcards (+’s) can be used to reduce the number of lines that have to be specified. Note that in
the example below by using less wildcards you can achieve more detail in the initial display.
15
Grouping Configurat ion Ex am ple 1: Highly Sum m arised
Summarisation
Grouping Type Selection
Term
++ (all
SUMTOTAL E **
levels)
SUMTOTAL G 00001131++ First Bank
SUMTOTAL G 00001132++ Second Bank
SUMTOTAL G O+ Vendors
SUMTOTAL G I+ Customers
Following are descriptions or explanations (for the above configuration) of the screens you
should see as you drilldown through the cash forecast
Ex am ple 1: Ex pec t ed Cash Forec ast Display w it h as of dat e = t oday and daily inc rem ent
Today Today + 1 Today + 2 etc....
<total of all postings with

<... value date = <... value date =
value date = today, in GL
First Bank tomorrow, today + 2,
accounts starting with
...00001131xx> ...00001131xx>
00001131xx>

Second value date = today, in GL
tomorrow, ... today + 2, ...
Bank accounts starting with
00001132xx> 00001132xx>
00001132xx>

planning date = today, in AP <... planning date = <... planning date
Vendors
accounts with a planning tomorrow...> = tomorrow...>
group starting with an ’O’>

planning date = today, in AR <... planning date = <... planning date
Customers
accounts with a planning tomorrow...> = tomorrow...>
group starting with an ’O’>
16
Ex am ple 1: Drill dow n on First B ank sum m arisat ion line
Groups: First
Today Today + 1 Today + 2 etc....
Bank
First Bank
Primary Account
value date = today, in GL <... value date = <... value date =
<Cash Mgt name
accounts related to a tomorrow, today + 2,
of an account
physical bank account. Eg: ...000011311x> ...000011311x>
physically at the
starting with 000011311x>
bank>
First Bank <total of all postings with

Secondary value date = today, in next
tomorrow, today + 2,
Account <Cash set of bank accounts
...000011312x> ...000011312x>
Mgt name> starting with 00001132x>
Ex am ple 1: Drill dow n on First B ank Prim ary Bank Ac c ount Line
Levels: First Bank

Primary Bank Today Today + 1 Today + 2 etc....
Account

value date = today, in GL
F0 Bank Balance tomorrow, today + 2,
account with planning level
...0000113100> ...0000113100>
= F0. eg: 113100>

B1 Outgoing value date = today, in GL
Payments account with planning level
...0000113101> ...0000113101>
= B1. eg: 113101>

B2 Incoming value date = today, in GL
Payments account with planning level
...0000113108> ...0000113108>
= B1. eg: 113108>
Drill Down to….
Line Item Display on selected

account
Ensure that you have test data that appears in a simple working grouping and then experiment
and try different options on the same test data. It is the best way to learn what the possibilities are
and to provide a variety of display options to your user.
17
Addit ional Configurat ion and
Func t ionalit y
Once you have the above essential configuration working happily, you can then expand your
prototype to include the following transactions and functionality.
I n t e g ra t i n g M M a n d SD
Purchase Order and Sales Order Amounts could be included in the cash forecast as expected
future outgoings and incomings. These would obviously need to appear separately from the AR
and AP open items as they have a lesser degree of certainty about their timing or reliability of
actually happening (ie: a different planning level). You may want to define a distribution function
to more accurately display their expected effect..
Int egrat ing MM and SD Chec k list
Menu Path Comment
IMG > Treasury > Cash Management > Basic settings > see explanation in
Maintain Source Symbols terminology
IMG > Treasury > Cash Management > Master Data > define the levels you want to
Define Planning Levels use for MM and SD
allocate the planning levels

that you have defined to the
’internal code’ for the MM
IMG > Treasury > Cash Management > Master Data >
and SD transactions (eg: 1=
Define Planning Levels for Logistics
Purchase Requisition,
2=purchase order, 101=
Sales Orders etc)
Ensure that the options to

IMG > Treasury > Cash Management > Tools > Define
integrate SD and MM have
Production Startup
been selected.
18
Bloc k ed It em s
Items that are blocked for payment in AP or AR will appear under a separate planning level which
is built up from the letter ’X’ and the payment blocking indicator. This is necessary because there
is uncertainty about whether they will be paid at all, or when they will be paid.
Menu Path Comment
Refer to Accounts Payable help for more

information on blocked items and how to
Structuring > Maintain Blocked Levels
process them.
Pl a n n i n g T y p e s
Planning Types are basically different types of memo records. They are a way of entering
knowledge which is not yet ’formal’ into the system for planning purposes (For example a
payment advice). Since these are not yet formal transactions and often the amounts and dates are
approximate, they are shown under separate planning levels in the Cash Forecast. Planning Types
are also covered under general FI as there are ways of integrating their functionality with the
standard AR and AP processes. (For example, archiving a payment advice once the actual
payment goes through).
Menu Path Comment

Refer also to Accounts Payable and
Structuring > Manual Planning > define
Accounts Receivable help for more
number ranges, and then define planning
information on payment advices.
types
Di s t r i b u t i o n Fu n c t i o n
The Distribution function can be used to provide an optional alternate display, which may give
the viewer a better overall idea of net expected fund flows. Note that the user has control over
whether the distribution is used or not, by specifying a parameter on the cash forecast screen.
To configure a ’distribution’ of the value amounts for a planning level, you need an idea the
statistics surrounding the ’reliability’ of the expected incoming or outgoing flow of funds.
For example:
a bank balance is 100 % reliable - we already have the funds,

an uncashed cheque may be 95 % likely to be cashed tomorrow,
a AR invoices for a bad customer group may be 70% likely to be paid on time, 20 % two
days late and maybe 10 % not at all.
19
This knowledge is used to specify how much of an amount planned within a certain period is to
be listed in the display for the cash management position or liquidity forecast, and when should
the amounts be shown. In this way you include the uncertainty for some items of the expected
date of payment.
For example, an analysis of unconfirmed payment advices may show that 50 % of total amounts
actually come in on the expected day, 30 % come in later and 20 % a day earlier. You could then
configure this distribution for unconfirmed payment advices:
50% on the expected day,

30% one day later,
20% one day earlier.
Menu Path Comment
The Distribution is defined per planning

IMG > Treasury > Cash Management > level that you want to distribute. The
Structuring > Define Distribution Function specifications relative to the planning date of
any item with that planning level.
Ex am ple of Dist ribut ion of Unc onfirm ed Paym ent Advic e
+/ -
Level Days Percentage
sign
UA 0 50
UA + 1 30
UA - 1 20
20
Sp e c i a l GL T r a n s a c t i o n s
Special GL transactions (Down payments or bills of exchange, etc) in AP or AR will appear under
a separate planning level. Note that there are naming conventions for these too - ’F’ followed by
the special GL indicator used on the line item. Refer to R/ 3 Library under AR and AP.
Menu Path Comment
Refer to Accounts Payable and Accounts

Receivable help for more information on
special GL transactions and how to process
IMG > Treasury > Cash Management > them. They are transactions for specific
Structuring > Special GL Transaction Levels functionality. They appear on the customer
and vendor accounts, but are shown
separately from the normal control accounts
in the GL.
21
Relat ed Configurat ion or Func t ionalit y
Configuration or Master data Item Comment
The Planning Level field should be mandatory for

GL master record account group for
the account group (eg: FIN) to which the cash
bank related accounts
management related accounts are allocated.
GL field status group for financial

Value date should be mandatory.
(bank) GL accounts
Any account which you wish to see in the Cash

position, must be created with the ’financials’
Chart of Accounts
account group that has the planning level field
mandatory.
Any account which you wish to see in the Cash

GL Accounts at Company Code
position, should be created with the field status
Level
group that has the value date field mandatory.
Planning Group should be mandatory.

AR and AP master record account
To provide ’distributed’ expected amounts, ’Record
groups
Payment History’ field should be switched on for
customers.
AR/ SD Credit managment master May wish to create so that payment history can be
records viewed.
May wish to run the cashed cheques analysis to

AP Check cashing Analysis
provide the ’distributed’ expected amounts for AP
The payment term on a transaction will determine

AR and AP Payment terms
the planning date.
AP Payment program configuration Bank setup and value date defaults
TR cheque deposit transaction Value Date entry will determine planning date.
TR Bank Statement Processing Updates status of bank and bank clearing accounts
Updates status of cheques issued (and therefore

TR Cashed Cheques Upload
bank clearing accounts)
22
Preparing Test dat a for Cash Posit ion
and Forec ast
The data on which the cash position and forecast is based, is usually populated by a variety of
programs which are complex to setup and prepare data for (For example: payment program,
cheque deposit, bank statement etc).
So it is desirable to be able to ’mimic’ the results of these programs so that one can test or
demonstrate the workings of the cash position and forecast.
The following guidelines assume that:
you have some understanding of the bank and bank clearing accounts explained earlier
in the Treasury section
you know how to post basic GL, AR and AP transactions and create master data.
First determine the value dates and planning dates that you wish the data to appear under and
then ’back calculate’ to determine posting or document dates and payment terms that will cause
the necessary planning dates.
23
St eps t o Prepare ’essent ial c onfigurat ion’ Test Dat a for Cash Posit ion and Forec ast
The opening balance is usually setup at conversion time and

the contra entry posted to a ’conversion account’ (the total of
which should net to zero once all balances have been
converted).
GL Document entry:
Creating a Bank Balance
Debit (PK=40) Bank
Credit (PK=50) Conversion account
Alternatively you could create balances by postings receipts,
and then loading a bank statement showing the deposited
receipt as below.
Essentially mimicking the cheque deposit program.

Create expected deposits in
the clearing account Accounts Receivable > Incoming payment:
’Incoming payments’ Debit Incoming Payments
Credit Unallocated Receipts (or Customer Account)
Essentially mimicking the payment program.
Created expected payment
in the clearing account Accounts Payable > Outgoing Payment:
’Outgoing payments’ Debit Vendor
Credit Outgoing Payments
Create or choose a set of customers you have already setup
with the planning groups in their customer master records.
Create expected receipts
Now post (backdated if necessary) AR invoices against these
for different customer
customers.
planning groups, with
different payment terms Accounts Receivable > Invoice
and posting / document
dates. Debit Customer
Credit Revenue (choose an account which allows
manual postings - you may need to create one)
Create or choose a set of vendors you have already setup
with the planning groups in their vendor master records.
Create expected payments
Now post (backdated if necessary) AP invoices against these
for different vendor
vendors.
planning groups with
different payment terms Accounts Payable > Invoice
and posting / document
dates. Debit Expense a/ c (you will probably need a cost
centre to use here)
Credit Vendor a/ c
24

Cash Forecast2

Uploaded by

Copyright:

Available Formats

You might also like

Cash Forecast2

Uploaded by

Document Information

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

Cash Forecast2

Uploaded by

Copyright:

Available Formats

SAP SCENE

SAP GL Ban k an d Ba nk r el a t ed A c c o unt s 3

The Cash Position input data is the known balances:

SAP GL Bank and Bank relat ed

This is a clearing account which is

If you had multiple outgoing payment methods (local cheques,

This is a clearing account which is

Uncleared credit items could be payments made by customers

Number Account name

113200 Second bank Account

113201 Outgoing Payments - second bank

Cheques Received or Incoming Payments -

 150  100 100 Invoice 100 Invoice 150  150

Outgoing Payments Incoming Payments Unallocated Customer Payments

 100 100  150  150  150  150

Cheque Received (Cheque Deposit Process)

Payment allocation process (session created by Cheque Deposit Process)

Bank Statement Upload (eg day 1)

Deposit Slip (Cheques etc)

Payment (Cashed Cheque)

it has been appropriately configured for your data,

This can be changed on the fly within the enquiry.

Determines whether the balances or deltas amounts are shown summarised

This can be changed on the fly within the enquiry.

Optional. Used to select ONLY the transaction amounts where the

Optional. Specify whether expected amounts should be ’distributed’ by the

Underst anding t he Business

Business Requirement Question Affected Configuration

What sort of incoming and outgoing financial transactions

Do customer and/ or vendor payment transactions differ (in a way

Does the company have an understanding of the likelihood of

What would be a meaningful level of detail or summarisation of all

Module Term Explanation

The Payment date is determined by the payment terms, possibly

The Planning date can also be switched on for entry to allow

Planning On payment advice’s or memo records, the planning date is

The Planning levels are specified:

The Planning group is specified on the Customer or Vendor Master

Standard SAP uses the examples:

Note that for GL accounts, the GL Account Number is effectively the

Summarisation terms are used to summarise planning levels and groups

You can do this by specifying in percentages, how much of an amount

For Example, an analysis of unconfirmed payment advices may show that

Menu Path Comment

IMG > Treasury > Cash Management >

This may already have been done in GL, AR

The GL Account Groups must have the

The field status group for GL Bank

IMG > Treasury > Cash Management >

IMG > Treasury > Cash Management >

Ensure that all accounts required in the Cash

Ensure that all customer and vendor master

This is the key piece of configuration that

IMG > Treasury > Cash Management >

SUMTOTAL G 00001131++ First Bank

SUMTOTAL G 00001132++ Second Bank

SUMTOTAL G O+ Vendors

SUMTOTAL G I+ Customers

150 100 100 Invoice 100 Invoice 150 150

100 100 150 150 150 150

Cheque Received (Cheque Deposit Process)

Payment allocation process (session created by Cheque Deposit Process)

Deposit Slip (Cheques etc)

Payment (Cashed Cheque)

it has been appropriately configured for your data,

a bank balance is 100 % reliable - we already have the funds,

50% on the expected day,