>> The terms of payment enable system to calculate the Cash Discount and due date for paying the invoice.

>> In order to do the a/m the system needs the fol data

i. Baseline date: date from which date starts
ii. cash discount terms
iii. cash discount percentage rates

>> When you process a doc you enter the terms of payment so that the system can calculate the required conditions of payment.

>> The terms of payment are:

i. Defined/entered in coy code segment, sales area segment or purchasing org segment of a customer/vendor master record.
ii. proposed when you post document
iii. entered manually

>> The terms of payment default when you post an invoice all depends on where the invoice was created, FI (terms defaulted from coy code seg), SD(terms defaulted from sales area segment) or MM ( terms of payment from purchasing organization segment are defaulted)- further copying of these terms from SD or MM to FI is done automatically.

>> Dunning & payment programs access these terms of payment

>> Generally no terms of payment are proposed at the time of creating a credit memo: There are however options to post credit memo:

o Invoice related credit memo :linked to original invoice, invoice and credit memo due on same date
o Non Invoice related credit memo with payment terms entered at time of posting documents, only if ‘V’ is entered the payment terms will take effect. These credit memos are due on baseline date

>> The day limit in payment terms is the calendar day to which the payment terms are valid, using day limit you can store single or multi part terms of payment in terms of payment key

>> The account type defines the subledger in which terms of payment can be used. If you want to use terms of payment for both vendors and customers, you should define these using separate terms of payment keys and then only use them for one account type accordingly. This prevents any change that you make in terms of payment for your customers to effect your vendors.

>> Using block keys which can be entered in line items or accounts, you can block line items or accounts for payment or collection .The block key can also be entered in terms of payment.

>> Payment method, predefined by systems for many countries, can also be entered in line items or accounts, like payment blocks, payment methods can be entered in terms of payment.

>> A block key and payment method defined in a payment term will be defaulted in line item when the payment term is used.

>> Baseline date is the starting date the system uses to calculate the invoice due date.

>> Possible default values for baseline date in payment terms are

o No default
o Posting Date
o Document date
o Entry Date

>> You can enter up to three cash discount periods.

>> To calculate cash discount, you enter a percentage rate in terms of payment. You also enter the no of days that % is valid.

>> The days and months specified in terms of payment are used in conjunction with the baseline date to calculate the correct cash discount amount for the payment date.

>> The day limit is the baseline date upto which the payment term version applies

>> Day limits enable date-specific terms of payment in one terms of payment key.

>> You can define several versions of terms of payment with each version having a different day limit

>> The following terms of payment require the specification of a delimit:

o documents with invoice date upto 15th of the month are payable on the last day of the following month
o Documents with a later invoice date are payable on the 15th of the month after.

>> An invoice can be paid over several months using an instalment plan, where the total invoice amount is divided into partial amounts due on different dates. The system carries out the split automatically if instalment payment is defined in the terms of payment. to do this select instalment payment and DONOT assign cash discount periods or cash discount percentage rates.

>> Define an instalment number, a percentage rate and terms of payment for each instalment.. The percentage rates specified must total 100%, the system creates a line item for each instalment specified. The line item amounts correspond to the percentages of the total amount, while the total of the line item amounts corresponds to the total amount.

>> For each coy code or tax jurisdiction code, specify which value the system is to use as a cash discount basethis setting belongs to the global parameters of a coy code.

>> The cash discount amount is entered either manually or automatically by the system using the rates in the terms of payment. You can still change the cash discount after you post the invoice.

>> When you clear an open item in a customer or vendor account, the cash discount is automatically posted to the account for ‘cash discount expense’ or ‘cash discount revenue’.

>> Incase of instalment payment, following steps are taken:

o create payment term without any cash discount%, only select instalment check
o define instalment number, a % rate and terms of payment for each instalment
o % must be 100%
o the system creates a line item for each instalment specified

>> Incase cash discounts are used in the gross procedure fol accounts are used

o Cash discount revenue account
o Cash discount expense account

>> If you post a vendor invoice with a document type for the net procedure, the amount posted to the expense or balance sheet account is reduced by the cash discount amount. The same amount is also posted to a cash discount clearing account to clear the posting.

>> When you use the net procedure the cash discount amount is automatically posted when the invoice is posted.

>> When the invoice is paid the system carries out a clearing posting to the cash discount clearing account

>> If the invoice is paid after the cash discount deadline the cash discount loss is posted to a separate account

>> THE CASH DISCOUNT CLEARING ACCOUNT MUST BE MANAGED ON AN OPEN ITEM BASIS.

>> Incase cash discounts are used in the net procedure fol accounts are used

o Cash discount clearing account
o Cash discount loss account

> System provides function to reverse G/L, customer & vendor doc either individually or in a mass reversal.

> There are two ways to reverse a doc entered incorrectly:
i. Normal Reversal Posting :Auto, 0 bal, post incorrect debit to credit & vice versa causing an inc in transaction figures
ii. Negative Posting: manual, 0 bal, removes traces, also posts incorrect debit to credit n vice versa but does not add posted amount to transaction figures, it subtracts transaction figures so brings doc in original state before incorrect posting.

> A reversal reason must be entered which explains the reversal & also controls if reversal date is allowed to differentiate from original posting date.

> Docs with cleared items cannot be reversed until it is first reset

> Normally system uses normal reversal posting, but if negative postings are used following prerequisites must be fulfilled:

i. The coy code allows negative postings
ii. The reversal reason must be defined for negative postings.

> Negative postings can also perform transfer postings of incorrect Line Items. The item is removed from wrong account by a negative posting and posted to correct account by a normal posting. But this can only be done if a document allows a negative posting.

> In the Doc header of reversed document, the doc number of reversal is also mentioned, along with reversal reason

> In Doc header of reversal doc the doc number of reversed doc is available without any reversal reason. (reversal reason can be found in reversed doc not reversal doc)

· Conditions for doc field changes
a. Posting pd must be open
b. Line item is not cleared
c. Line item either debit in customer or credit in vendor
d. doc not a credit memo for invoice
e. doc not a credit memo for down payment

· Document change rules can be made on following criteria:
a. Account type: A,K,D,M,S
b. Transaction class: eg special G/L (down pymt)
c. Company Code

> Help in preventing input errors as values appear automatically

> User logon id has properties like language, date format, decimal notation applicable system wide

> You can have CPU date proposed as value date

> Using editing options the screens can be configured for fol areas:
i. Doc entry: users hide fields not relevant eg cross coy transact, foreign currency-you can also use
special editing options for single screen transactions.
ii. Doc display: using list viewer user can select diff display optns
iii. Open items: using line layout displays& posting options for open item processing, user can enter the
amount of partial payments or balance of new open item

> (simple docs in FI):Some sources of value defaulted by system for doc entry:
i. `User master Records
ii. Parameter memory
iii. System Data
iv. Account Master Record
v. Accounting functions

In Tolerance Groups you can enter upper limits for the fol:
i. Total amount per document
ii. Amount per customer/vendor item
iii. Cash discount which a user in a tolerance gp can grant.

When setting limits the currency used is local currency of Coy Code.

You can create as many tolerance groups as you like.

Each employee must be assigned to one tolerance group

A Tolerance group can be assigned to one or more Coy Code.

If user not assigned to any tolerance group then default tolerance group valid for them

For employees with specially high/low limits—special tolerance gp created and assigned to their logon id’s.

System usually proposes the current date as posting date

To prevent documents from being posted to an incorrect posting period, you can close certain posting periods.

You open a posting period by entering a range in the posting period variant that encompasses this period. You
can have as many periods open as desired.

As many periods as required can be open simultaneously, however, only two period intervals can be open at
the same time during closing.

Posting Periods assigned to the Company Code or several coy codes can use the same posting period variant

In defining posting period variant ‘+’ is valid for all account types.

Posting Periods can be handled differently for different account types.

At line item level the system checks the account type of the posting key to ensure that the period is open for
assigned account types.

A Posting Period Variant must contain at least one line with the entry Valid for all accounts.

The account Range in the posting period variant consists of G/L accounts.

Posting period variant that contains the open periods has to be maintained manually.

The authorization group applies to the first period interval. This can also be an interval with normal posting
periods.

R/3 uses one posting transaction for several different postings, e.g : G/L acc posting, Customer/Vendor invoice
posting, Vendor/customer credit memo postings.

If you do not define a doc type the system proposes the standard e.g. KR for vendor invoices.

Open items list can be seen by pressing open item button.

Documents in R/3 include a doc header and 2-999 line items.

A document remains a complete unit in the R/3 system until archived.

Controlling info may also be included in doc header

SAP records at least one doc for every biz transaction and each doc receives a unique doc number.

Every Doc uniquely identified by fol Fields:
i. Doc No
ii. Coy Code
iii. Fiscal Year

Two important control keys for documents are:
o Document Type (to control document header)
o Posting Keys (for line items)

Doc Type controls the doc header & is used to classify the business transactions to be posted, it is the key to
differentiate and classify business transactions.

Most imp control functions of doc types are ;
i. Number ranges for doc numbers;
ii. Account types permitted for postings

Doc Types defined at client level and valid for all coy codes. It controls the following:
i. which accounts to be posted
ii. number range
iii. field status of document header text and reference
iv. Whether invoices are posted with net procedure.

If no reversal document type is specified, the reversal doc has the same doc type as original doc.

You specify a number range for each doc type. However, you can use one number range for several doc
types.

You can copy the intervals of document number ranges from one coy code to another or copy intervals from
one fiscal year to other.

Every Coy Code may define its own Doc number ranges or doc number ranges created per coy code

Doc Number range can be internal or external. The internal range can be year specific or year independent.

Doc no ranges must never overlap.

External number ranges may be alphanumeric

System saves the last document used from number range in field Current number.

Doc number range must be defined for the year in which it is used.
i. Up to a future fiscal year :no restart
ii. For each fiscal year :restart

Defined at Client level and most imp con functions for a posting key are;
i. Determine which account type can be posted to
ii. Side of account (debit or credit posting)
iii. Field status of additional details or layout of entry screen
iv. Specifies whether the line item is connected to a payment transaction or not. (helps analyzing payment
history/notices)
v. Whether posting is sales relevant and sales figures need to be updated.

Std posting keys for customer/vendor invoices are
i. credit- 50 customer –31 Vendor
ii. debit- 01 customer – 40 Vendor

Standard posting keys for G/L account postings are;
i. 40 Debit posting key
ii. 50 Credit, posting Key

Field Status of document fields is influenced by Field status group and posting key and is determined by three factors:
i. Account type (S,K,D)
ii. Field status of posting key
iii. Field status of account.

As a general rule the account specific field status for G/L accounts

Field status with highest priority applies, Exceptions to this rule are:

o An activated biz area must be ready for input
o Entries in tax fields only possible if G/L account is tax relevant.
o Field Status group controls the field display during document entry.
o For each group of G/L accounts you have to define the status of every document entry
field.(required/optional/hidden)
o You assign field status groups to the respective G/L accounts in the G/L account master records. Each G/L
account has a field status group

If a doc is posted to a sub ledger account the field status group of the reconciliation account is used.

All the field status groups are summarized in one field status variant which is assigned to coy codes (mandatory)

Required, hidden, optional is priority. Hide + Required=Error

By changing the field status definitions of posting keys and field status group, the field status can be made
transaction dependant and account dependant.

Subledgers don’t have field status group and therefore a lot of posting keys are used.

In G/L postings differentiation is mainly made via different field status groups, therefore only two posting keys
40 & 50 are needed for G/L postings.