191. Explain ‘Revenue
Account Determination’ in SD.
The billing documents created during
the sales cycle results in automatic postings to GL accounts
on the FI side. In general, ‘Account
Determination’ is based on the following five factors:
1. Chart of accounts
2. Sales organization
3. Account assignment group of the
customer
4. Account assignment group of the
material
5. Account key
The system determines the ‘chart of
accounts’ from the company code in the ‘billing
document,’ and the ‘sales
organization’ is determined from the corresponding ‘sales order.’
The ‘account assignment group’ is
taken from the respective masters of customer/material.
The ‘account key’ helps the user
to define the various GL accounts, and this key is assigned to
the ‘condition type’ (KOFI) in
the ‘pricing procedure.’
These GL accounts are
automatically determined when you make the following configuration in
the system:
1. Assigning an ‘account determination
procedure’ to a ‘billing document type’
2. Assigning this ‘account
determination procedure’ to a ‘condition type’
3. Assigning this ‘condition type’ to
an ‘access sequence’
4. Configuring the ‘condition tables’
Table Description
001 Customer /Material Grp./AccKey
002 Cust. Grp/AccKey
003 Material Grp/Acc Key
004 General
005 Acc Key
Applicatio
n
Conditio
n Type
Chart
of a/c
Sale
s
Org
AcctAs
g Grp
Acc
Asgm
nt
A/c
Key
GL a/c
001 Customer grp/Material Grp./AccKey:
Details
V KOFI COM
P
1000 01 10 ERL 501210000
0
V KOFI COM
P
1000 01 10 ERS 501210000
0
V KOFI COM
P
1000 02 10 ERL 501220000
0
V KOFI COM
P
1000 02 10 ERS 501220000
0
V KOFI COM
P
2000 01 20 ERL 501310000
0
V KOFI COM
P
2000 01 20 ERS 501310000
0
V KOFI COM
P
2000 02 20 ERL 501320000
0
V KOFI COM
P
2000 02 20 ERS 501320000
0
005 Acc Key: Details
V KOFI COM
P
1000 MW
S
247000000
0
V KOFI COM
P
2000 MW
S
247000000
0
Open table as spreadsheet
Figure 47: Revenue account
determination
192. Outline ‘Credit
Management’ in SAP.
‘Credit Management’ helps to determine
credit limits of customers, aids in the creation of ‘credit
check’ policies, as well as
helps companies monitor and evaluate their customers. This is a
cross-functional responsibility in SAP,
covering both the Sales and Distribution and Financial
Accounting modules.
As in the case of any automated process
such as dunning, payment, etc., credit management in
SAP requires certain prerequisites be
defined beforehand:
1. Customer master data has been
created both in SD and FI.
2. Credit control area has been
defined and assigned to a Company Code.
SAP makes use of the concept ‘credit
control area’ for credit management. As explained
elsewhere, the credit control area is
an organizational element defined to which one or more
Company Codes are attached. In the case
of customers defined under more than one Company
Code, they may fall under different
credit control areas. But note that:
􀂃
A Client
can have more than one credit control area, but the converse is not true: one
credit control area cannot be assigned
to more than one Client.
􀂃
A credit
control area can be assigned to more than one Company Code, but the converse
is not true: one Company Code cannot be
assigned to more than one credit control area
.
Figure 48: Client—Credit Control
Area—Company Code—Customer
While defining the credit limit for a
customer:
􀂃
􀂃
You will
define a maximum limit per credit control area (Example: Credit Control
Area AAAA->USD 500,000, Credit
Control Area BBBB ->USD 200,000)
􀂃
You will
define a global maximum limit for all credit control areas put together
(USD 600,000)
3. Credit data (per credit
control area ‘maximum limit’ as well as the ‘total’ for all areas, in
the control data screen) for the
customer has been created.
4. Risk categories have been
defined and assigned to customers.
5. Credit groups (document
credit group) for document types have been defined.
Document credit groups combine order
types and delivery types for credit control.
6. Defined, in SD, at what time (when
order is received or when a delivery is made, etc.) the
credit check should happen.
The credit management process starts
when a sales order is entered in SD. Imagine that this
results in exceeding the credit limit
defined for the customer. Now:
a. The system creates three comparison
totals considering (1) open receivables, (2) sales
order values, value of goods to be
delivered and the billing document value from SD, and
(3) special GL transactions (e.g., ‘down
payments’ and ‘bills of exchange’).
b. Based on (a) above the system
throws an (1) error message and prevents saving the
order or (2) a warning message, and the
system does not prevent saving, but the order is
‘blocked.’
c. The Credit representative, using
information functions (SD information system, FI
information system, credit overview,
credit master list, early warning list, oldest open item,
last payment, customer master, account
analysis, etc.), processes this blocked order
either (1) from the ‘blocked SD
documents list’ or (2) the mailbox, and releases the order,
if necessary.
d. Delivery is created, the billing
document is generated and posted, and A/R is updated.
e. Customer pays the invoice and A/R is
posted.
193. What is a ‘Credit
Check?
A ‘Credit Check’ is defined for
any valid combination of the following:
􀂃
Credit
control area
􀂃
Risk
category
􀂃
Document
credit group
194. Differentiate ‘Static
Credit Check’ from ‘Dynamic Check.’
Under ‘Static Credit Check,’ the
system calculates the credit exposure of a particular customer
as the total of:
􀂃
Open
order (delivery not yet done)
􀂃
Open
delivery (value of deliveries yet to be invoiced)
􀂃
Open
billing documents (not transferred to accounting)
􀂃
Open
items (AR item not yet settled by the customer)
Customer’s credit exposure is not to
exceed the established credit limit.
The ‘Dynamic Credit Check’ is
split into two parts:
􀂃
Static
limit: Total
of open items, open billing, and open delivery values.
􀂃
Dynamic
limit (Open Order Value): The value of all undelivered and partially delivered
orders totalled and stored on a
time-scale in the future (10 days, 1 week, etc.) known as a
‘horizon date.’
During the ‘dynamic credit check,’ the
system will ignore all orders beyond the ‘horizon date.’ The
sum total of ‘static’ and ‘dynamic’
limits should not exceed the credit limit established for the
customer.
195. List the Reports
in ‘Credit Management.’
SAP provides you with the following Reports
in Credit Management:
􀂃
RFDKLI10
Customers
with missing Credit Data
􀂃
RFDKLI20
Re-organization
of Credit Limit for Customers
􀂃
RFDKLI30
Short
Overview of Credit Limit
􀂃
RFDKLI40
Overview
of Credit Limit
􀂃
RFDKLI41
Credit
Master Sheet
􀂃
RFDKLI42
Early
Warning List (of Critical Customers)
􀂃
RFDKLI43
Master
Data List
􀂃
RFDKLI50
Mass
change of Credit Limit Data
􀂃
RVKRED06
Checking
Blocked Credit Documents
􀂃
RVKRED08
Checking
Credit Documents which reach the Credit Horizon
􀂃
RVKRED09
Checking
the Credit Documents from Credit View
􀂃
RVKRED77
Re-organization
of SD Credit Data
196. How does ‘Partial
Payment’ differ from ‘Residual Payment’?
When processing the ‘incoming
payment’ to apply to one or more of the ‘open items’ of a
customer, there may be a situation
where the incoming payment is more than the ‘tolerances’
allowed. In this case, you can still go
ahead and process the payment by resorting either to a
Partial Payment or a Residual payment.
A Partial payment results in
posting a credit to the customer’s ‘open item,’ but leaves the original
item intact. As a result, no open item
is cleared. During partial payment, the system updates the
‘invoice reference’ and ‘allocation’ fields.
In contrast to a partial payment, the Residual
payment clears the particular ‘open item’ against
which the payment is applied. However,
since there are not enough amounts to clear the entire
open item, the system creates a new
open item, which is the difference between the original
invoice item and the payment applied.
Note that the new invoice/open item created by the system
will have the new document date and new
baseline date though you can change these dates.
197. What is ‘Payment
Advice’?
‘Payment Advice’ helps in the automatic
searching of ‘open items’ during the ‘clearing’ process
to find a match for an ‘incoming
payment.’ This is possible because you can use the ‘payment
advice’ number instead of specifying
parameters in the ‘selection screen.’ A typical payment
advice may contain details such as
document number, amount, currency, reason for
underpayment, etc. The payment advices
are of various categories; the first 2 digits of the
payment advice number help to
differentiate one payment advice from another:
􀂃
Bank
advice
􀂃
EDI
advice
􀂃
Lockbox
advice (created during the clearing process, available in the system whether
clearing was successful or not)
􀂃
Manual
advice
􀂃
Advice
from a bank statement
Most of the payment advices are deleted
as soon as the clearing is successful in the system.
198. Describe ‘Lockbox’
Processing.
‘Lockbox’ processing (configured
in the FR-TR module) of incoming payments is used
predominantly in the United States.
Here, the bank receives the checks from customers as
incoming payments, creates payment
advice for each of these customer check payments, and
informs the payee of the payment, in
BAI file format. This lock box file is sent to the payee who
imports the details into the system
using this electronic file. The system updates the payments
into the GL by way of ‘batch input’
processing.
199. How can ‘Reason
Codes’ Help with Incoming Payment
Processing?
‘Reason Codes’ configured in the
system help to handle the ‘payment differences’ of individual
open items in an invoice (either using
payment or advice or in the normal course). To each of the
reason codes, you will define the ‘posting
rules’ and the GL accounts in the IMG.
Once done, when there is a payment
difference against a particular open item, the system looks
for the reason code:
􀂃
When the ‘charge-off
indicator’ has been set for that reason code, then the system
posts the payment difference to a GL
account. When this indicator is not set, then a new
open item is created for the payment
difference.
􀂃
When ‘disputed
item indicator’ has been set, then the system ignores these line items
when counting for the customer’s credit
limit.
200. What is ‘Dunning’
in SAP?
The SAP System allows you to ‘dun’
(remind) business partners automatically. The system duns
the open items from business partner
accounts. The dunning program selects the overdue open
items, determines the dunning level of
the account in question, and creates dunning notices. It
then saves the dunning data determined
for the items and accounts affected. You can use the
dunning program to dun both customers
and vendors. It may be necessary to dun a vendor in the
case of a debit balance as a result of
a credit memo.
Dunning is administered
through a Dunning Program, which uses a dunning key (to limit the
dunning level per item), a dunning
procedure, and a dunning area (if dunning is not done at
the Company Code level).
Figure 49: Dunning Key
T Code F150
201. What is a ‘Dunning
Procedure’?
SAP comes equipped with a number or ‘Dunning
Procedures,’ which you can copy, or you can
create your own:
Figure 50: List of Dunning
Procedures
A dunning procedure controls:
􀂃
Dunning
interval/frequency
􀂃
Grace
days/minimum
days in arrear
􀂃
Number of
dunning levels (at least one level)
Figure 51: Dunning Levels
􀂃
Transactions
to be dunned
􀂃
Interest
to be calculated on the overdue items
􀂃
Known or
negotiated leave, if any, which needs to be considered when selecting the
overdue items
􀂃
Company
Code data such as (a) Is dunning per ‘dunning area’? (b) Is
dunning per
‘dunning level’? (c) Reference
Company Code, (d) Dunning Company Code, etc.
􀂃
Dunning
forms/media
to be selected for the dunning run
Figure 52: Control Information in
a Dunning Procedure
202. What is the ‘Dunning
Area’?
The ‘Dunning Area’ is optional
and is required only if dunning is not done at the Company Code
level. The Dunning area can correspond
to a sales division, sales organization, etc.
203. Describe the ‘Dunning’
Process.
The ‘Dunning Process’ involves
three major steps:
1. Maintaining the parameters for
the dunning run
2. Creating/editing the dunning
proposal generated by the system
3. Printing dunning notices
1. Maintaining Dunning Parameters
As the first step in dunning, you need
to maintain certain parameters, which identify the
current dunning run. Entering the date
of execution and the dunning run identifier is the
starting point, after which you will
continue to maintain other parameters such as:
i. Dunning date to be printed on the notice
ii. Document posted up to
iii. Company Code
iv. Account restrictions (optional)
Now, you can save the parameters and
display the log generated (to see if there were any
errors), the dunning list (list of
accounts and items), and some dunning statistics (blocked
accounts/items, etc.).
2. Creating a Dunning Proposal
Once scheduled, the ‘dunning program’
prepares the ‘dunning proposal’ as described
below:
a. The Dunning Program determines which
accounts to dun:
i. System checks the fields ‘Dunn.procedure’
and ‘Last dunned’ in the
customer master record to determine
whether the arrears date or the date of
the last dunning run lies far enough
back in the past.
ii. Checks whether the account is
blocked for dunning according to the
dunning block field in the customer
master record.
iii. Program processes all open items
relating to the accounts thus released
in (ii) above that were posted
to this account on or before the date entered
in the field ‘Documents posted up
to.’
iv. Program checks all the open items,
as released in (iii) above, in an
account to decide:
􀂃
Is the
item blocked?
􀂃
Is it
overdue according to the date of issue, the base date, the
payment conditions, and the number of
grace days granted?
v. Program then proceeds to process all
open items thus released in (iv):
􀂃
How many
days the item is overdue
􀂃
Which ‘dunning
level’ for a particular open item
vi. The program determines the highest ‘dunning
level’ for the account
based on (v) above. The highest ‘dunning
level’ determined is stored in the
master record of the account when you
print the letters. This ‘dunning level’
determines the ‘dunning text’ and a ‘special
dunning form,’ if defined.
vii. The program then proceeds to check
each account:
􀂃
Does the
customer/vendor have a debit balance with regard to
all open overdue items selected?
􀂃
Is the
total amount to be dunned and the percentage of all open
items more than the minimum amount and
percentage defined in the
‘dunning procedure’?
􀂃
Is the ‘dunning
level’ for the account or the overdue items higher
than it was for the last ‘dunning run’?
If not, are there new open items
to be dunned (with a previous dunning
level of 0)? If not, does the
‘dunning procedure’ for this level
specify that dunning be repeated?
b. The program creates the dunning
proposal list
c. Edit dunning proposal list
i. You can edit the Dunning Proposal
to:
􀂃
Raise or
lower the ‘dunning level’ of an item
􀂃
Block an
item from being dunned
􀂃
Block an
account for the current ‘dunning run’ or remove the
block
􀂃
Block an
account in the master record for dunning or remove the
block
􀂃
Block a
document for dunning or remove the block
ii. You can view the sample print out
to ascertain how the printed notice will
look (a maximum of 10 notices can be
seen on the screen).
iii. You may also display ‘logs’ to see
the changes made in the editing
earlier, as a confirmation of what you
wanted to change in the
systemgenerated proposal earlier. If
necessary, you can go back and
change the proposal.
3. Print Dunning Notices
You can use a ‘single form’ or ‘multiple
forms,’ which will have different text, based on the
‘dunning levels.’ There may also be a
requirement to use a completely different form for
‘legal dunning.’ Once the print option
is activated, the program prints the notices, and the
dunning related information such as ‘dunning
level,’ ‘last dunned,’ etc., are updated in the
customer/vendor masters. SAP provides
the option of optically ‘archiving’ the notices as
the system prints the dunning notices.
There is also a provision to re-start the printing if it
is interrupted before completing the
printing.
204. Can you ‘dun’
customers across ‘Clients’ in a Single ‘Dunning
Run’?
No. All the data processing is carried
out per Client.
205. What
differentiates one ‘Dunning Level’ from Another?
The ‘Dunning Level’ determines
the ‘dunning text’ and (if one is required) a ‘special dunning
form.’ The ‘dunning program’ determines
what ‘dunning level’ should be used in the ‘dunning run.’
The dunning level so determined is
stored in the master record of the account when the ‘dunning
letter’ is printed. The dunning level
may also determine whether there will be some ‘dunning
charges.’
No comments:
Post a Comment