15.3.11

SAP Note 24883 - CMF: Determination of value/planning date

Symptom:

How is the value date or planned date determined in cash management and forecast?
How is the customer's payment history taken into account?
How can you influence this process?

Other terms

Cash Management

Solution

When you post to G/L accounts, customers or vendors, the value date or planned date is determined or proposed as follows:

1) G/L accounts:

The value date is taken. If no value date is entered, the posting date is used (see Note 435673).

2) Vendors:

Table T042 defines how much cash discount the vendor must offer before payment takes place on cash discount day 1. If the cash discount percentage rate that is offered is sufficient or is determined in table T042, meaning payment always takes place with cash discount terms 1, then you plan with cash discount day 1 and the planned amount is reduced accordingly.
Otherwise, you plan with the due date for net payment.
As of Release 4.5A, the check cashing time that was defined in the vendor master record is taken into account additionally for vendors if the payment method is a check payment method. If there is no payment method entered in a line item, the check cashing time will only be taken into account if it is only check payment methods that are defined in the vendor master record.
(You can maintain the check cashing time in the vendor master record either manually or using report RFSRUE10.)
(You cannot use a similar logic for the other payment methods (that is an evaluation of T042V-ANZTG with which the payment program determines the number of days until the value date) since the bank account used for the payment is not yet known.)

If purchase orders are updated into cash management and forecast, either the cash discount days 1 or the net days are added to the delivery date. This depends on the purchase order conditions. If nothing is entered or changed there, the default values of the term of payment (stored with the vendor in purchasing (transaction MK02)) apply . The term of payment stored with the vendor in Accounting (transaction FK02) does not apply here.
(For purchase orders, function module PAYDAY_DETERMINATION is not used for the date determination.)

3) Customers:

In the master record of the customer, you can define whether the payment history is to be updated for this customer (for example, this does not make sense for customers for which you have a collection authorization). If the switch is set, the information about whether this is a cash discount or net payment and the number of days in arrears are stored in table KNB4 for every clearing.
If the payment history is recorded for the customer, then the last three periods are evaluated. All net payments and cash discount payments are totaled. If the cash discount payments (the number of clearings is unimportant) exceed the total, then you assume a payment with cash discount day 1 for this document also and the planning date and planning amount are determined accordingly. Therefore, the average days in arrears of the cash discount payments for the last three periods are also determined and taken into account for the planning date. Hence the planning date results from either:
baseline date for payment + cash discount days 1 + average days in arrears of cash discount payments for the last three periods
or:
baseline date for payment + net days + average days in arrears of net payments for the last three periods.
The amounts are weighted when determining the average number of days in arrears. The period itself is not weighted, that is, all three periods are treated identically. Only the last three periods from KNB4 are evaluated, since the short-term payment history must be taken into account.
If there is no data for the customer in KNB4 (because updates are not supposed to take place or no invoice was cleared), it is assumed that the customer with cash discount day 1 will pay without days in arrears.
This logic occurs in function module PAYDAY_DETERMINATION and is used by both cash management and forecast and cash budget management.

When orders are updated to cash management and forecast, the system uses the billing date determined by SD, which is generall based on a cash discount payment (see Note 559841). In this case, the payment history for cash discount payments is taken into account.

4) Credit memos (for customers and vendors)

A credit memo only takes terms of payment (days/percentage) into account if it is an invoice reference or if the credit memo is indicated as value-dated ('V' in the invoice reference field). Otherwise, the amount is updated in cash management and forecast according to the entered payment baseline date (BSEG-ZFBDT).

5) General information:

If the planning date that was determined is unclear, we recommend that you set a break point in function module PAYDAY_DETERMINATION and call the transaction.

For orders and purchase orders, installment payment conditions (split payment conditions) cannot be distributed to several dates by percentage rates according to the terms of payment, instead every schedule line is assigned to one particular date.

6) How can you influence this process?
  • For customers and vendors, you can use the screen control in view V_T035 to set the planning date and the planning level to be overwritten during posting.
  • As of Release R/3 Enterprise (4.70), there is the option for FI documents for customer and vendor line items to deviate from the planning date determination described above. For every planning group (-> view V_T035), you can specify for the planning date to be fixed to the cash discount1 due date or to the due date for net payment. Consequently you can also hide a customer's payment history without having to deactivate the payment history update in the customer. See the F1 help in view V_T035 for more information.
  • When displaying cash management position and liquidity forecast, the amounts on one level can be distributed across several days or postponed by a few days (view V_T038V).
  • When displaying the liquidity forecast, the payment dates can be taken into account (view V_T035Z).

No comments:

Post a Comment