Terms of payment are conditions agreed between business partners for the payment of invoices.

>> 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.
» Read more: Discount and Payment Terms in SAP

First reverse the incorrect doc

> 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)

· Doc change rules can be either user defined or predefined by the system
· Only certain fields are modifiable once a doc is posted
· Incase of Header: reference no and Doc header text modifiable only if posting period is not closed
· Incase of Line items, amount, posting keys and account numbers are unmodifiable. The other are fixed in IMG

· 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

Parameter IDs allow users to set default values for fields whose value does not change very often, e.g coy
code or currency

> 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

The maximum amounts are defined per Coy Code in tolerance groups; here the processing of payment
differences is controlled.

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.

Posting Periods defined in the fiscal year variant

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.

A business transaction can create one or more documents.

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

Posting Key has control functions within the line items it controls

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.