Document Splitting

Displaying a document in the entry view and general ledger view is defined in the new G/L accounting and cannot be switched on or off using customizing.

·         entry view         view how document appears in sub ledger or to document creator

·         general ledger view how document appears in general ledger

1.       The entities defined as splitting characteristics (balancing characteristics) are inherited in non account-assigned posting line

2.       Document splitting (also often called online split) ensures that companies can create complete balance sheets for desired objects.

3.       Splitting method 0000000012 is the default procedure provided by SAP, and is usually copied to a client entry (e.g. Z000000012).

4.       Even though balance sheet can be created for objects (characteristics), line items cannot be split in entry view .It only happens in general ledger view

5.       Complete balance sheet can be created for objects (characteristics)only because of Document splitting

·         Since document splitting can be activated for each client and deactivated for each company code, the decision of whether to split the document or not is made at company code level.

·         However, all company codes of a client can only use one document splitting procedure, that is, different   procedures cannot be assigned to different company codes.

o   The inheritance concept: If an account assignment object is unique in a document, it is inherited online in all missing positions. The indicator should always be set when document setting is activated.

o   The default account assignment concept: It is possible to work with default account assignment, that is, if the position is not provided with the necessary object for any reason, then a default value (such as a profit center or segment) can be set automatically.

Document splitting process

1.       Passive Split -During clearing, the entities (such as segments) of the document being cleared are copied to the clearing document without being changed

a.       Step cannot be changed by customer

2.       Active split -For documents, which do not show clearing, splitting rules can be created in customizing .

a.       The document type is the basis for the rule

b.       splitting rules can be created

3.       Creating clearing lines/zero balance formation is always used if, in addition to the total document, the objects to be balanced “within” the document (e.g. profit center, segment) should be balanced to 0.

a.       Can be controlled using “zero balance indicator”

Document splitting characteristics

1.       Document splitting characteristics determine which objects document splitting is used for (where to divide/balance).

2.       Always set the Zero balance indicator if you want to create a financial statement for the characteristic. The balance of the defined entities is then always 0 for every posting ensuring entity balancing.

3.       The Mandatory Field works in addition to field status control in the account or in the posting key and has two meanings:

·         Firstly, it is an extension of the field status for accounts in which the characteristics cannot be “entered” during document entry, and/or for accounts that cannot be controlled using the field status. (Example: Vendor lines should always include a profit center or a segment.)

·         Secondly, it is a check as to whether a business process-equivalent business transaction variant was selected (which determines whether a splitting rule can be found).

o   Mandatory field indicator works in addition to field status control in the account or in the posting key

splitting procedure

·         A splitting procedure, defined in brief, is the total of all splitting rules of all business transactions.

·         As such, the splitting procedure defines how and under which circumstances document splits will be performed.

·         In detail, this means each splitting procedure defines how each item category will be handled in the individual business transactions.

1.       A business transaction is a general breakdown of the actual business processes that SAP provides and is assigned a wide variety of item categories.

2.       A business transaction variant is a specific version of the predefined business transaction provided by SAP and the (technical) modeling of a real business process for document splitting.

3.       An item category is a (technical) map of the posted line items. It describes the items that appear within a document (business transaction). They are derived from, among other things, the general ledger account categories.

4.       An individual splitting rule defines which item categories can/should be split (. item categories to be processed) and at the same time defines which foundation (. base) can be used (. base item categories)

Default Values

Parameter IDs allow users to set default values for fields whose value does not change very often, for example, company code, and currency.

Using the editing options, you can configure your screens for the following areas:

·         Receipt Entry: Users can hide fields that may not be relevant for their jobs, such as foreign currency or cross company code transactions.

·         Document display: Using the List Viewer, the user can select different display options for displaying documents.

·         Open Items: Users can choose line layout displays and posting options for processing open items, in other words, they can enter the amount of a partial payment or the balance of the new open item.

Change Control

Users can change certain fields in the posted documents these rules can either be predefined by the system or be user-specific.

 Certain fields in both the document header and the line items can be changed.

·         Document Header: Only the reference number and document header text can be changed.

·         Line Items: The system does not allow changes to the amount, the posting key, the account, or any other fields that would affect the reconciliation of a posting.

As users make changes to documents, the following information is logged:

·         The field that was changed

·         The new and old values

·         The user who made the change

·         The time and date of the change

We can differentiate between document change rules according to the following criteria:

·         Account Type: The account type allows users to define rules for customer, vendor, and general ledger accounts. (A,D,K,M,S)

·         Transaction Class: Transaction classes are only used for the special G/L transactions bill of exchange and down payment.

·         Company code: If the field is blank, the rule applies to every company code.

The conditions for changing a field are predefined. We can change them as follows:

·         The posting period is still open

·         The line item is not yet cleared

·         The line item is either a debit in a customer account or a credit in a vendor account

·         The document is not a credit memo for an invoice

·         The document is not a credit memo from a down payment

Document Reversal

A document can be reversed by:

·         Normal reversal posting

·         Negative posting

o   When we reverse a document, we have to enter a reversal reason that explains the reversal.

o   Reversal reason also controls whether the reversal date is allowed to be different to the original posting date.

The normal reversal posting causes the system to post the incorrect debit as a credit and the incorrect credit as a debit.

·         The normal reversal posting therefore causes an additional increase in the transaction figures.

The negative posting also posts the incorrect debit as a credit and the incorrect credit as a debit.

·         This time the posted amount is not added to the transaction figures, but is subtracted from the transaction figures of the other side of the account.

The following prerequisites must be fulfilled to enable negative postings:

·         The company code permits negative postings

·         The reversal reason must be defined for negative reversal.

Terms of payment

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

·         It’s a field in company code and sales area segment of customer master data

Terms of payment defines:

·         Baseline date: The date from which the due date is derived.

·         Cash discount terms: The terms by which the cash discount can be taken.

·         Cash discount percentage rate: The percentage rate used to calculate cash discount.

The terms of payment defaulted when posting an invoice depends on where the invoice is created:

·         If the invoice is created in Financials, the terms of payment from the company code segment are defaulted.

·         If a customer invoice is created in Sales order Management, the terms of payment from the sales area segment are defaulted.

·         If a vendor invoice is created in Purchasing Management, terms of payment from the purchasing organization segment are defaulted.

For Invoice related credit memos:

·         Credit memos can be linked to the original invoice by entering the invoice number in the "Invoice Reference" field during document entry. In this case, the terms of payment are copied from the invoice so that the invoice and the credit memo are due on the same date.

·         Other credit memos: Terms of payment in other credit memos are invalid. These credit memos are due on the baseline date. To activate the payment terms on these non-invoice related credit memos, enter a “V” in the "Invoice Reference" field when entering the document.

General Info:

·         The day limit is the calendar day to which the terms of payment are valid.

·         The description for terms of payment includes the an explanation generated automatically by the system which can be replaced by your own explanation of the terms of payment and a Sales Order

·         The account type defines the sub ledger 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.

Using payment term, there is Payment control:

·         Using block keys, which can be entered in line items or accounts, you can block line items or accounts for payment or collection. These block keys can also be entered in payment terms.

·         A payment method (for each country, the system has payment methods defined that you can use in that country) is entered in the line items or the accounts. Like payment blocks, payment methods can be entered in the terms of payment.

The baseline date is the starting date the system uses to calculate the invoice due date. The following rules apply for the calculation of the baseline date:

·         The default values from which the baseline date can be determined are as follows: no default, document date, posting date or entry date.

·         Specifications for calculating the baseline date: Fixed day used to overwrite the calendar day of the baseline date.

·         The number of month(s) to be added to the calendar month of the baseline month.

An invoice can be paid over several months using an installment plan, or a portion of the invoice amount may be retained for payment at a later date. The total invoice amount is divided into partial amounts due on different dates. The system carries out this split automatically if installment payment is defined in the terms of payment. The terms of payment for the line items are the terms of payment defined for the individual installments.

Depending on the national regulations of your country, the cash discount base amount is the net value (total of G/L account and fixed assets line items, taxes not included, for example in the USA)or gross value (including taxes, as is the case in Germany).

Cash discounts account

·         Cash discounts account used in gross procedure

o   Cash discounts revenue account

o   Cash discounts expense account

·         Cash discounts account used in net procedure

o   Cash discounts clearing account

o   Cash discounts expense account

Taxes

There are basically two types of taxation that can be processed in the SAP ERP system:

·         Taxes are levied at a national level, with uniformly defined rates.

·         Taxes are levied at a state/jurisdictional level

The system supports the treatment of taxes as follows:

·         Checks the tax amount entered or automatically calculates the tax

·         Posts the tax amount to tax accounts.

·         Performs tax adjustments for cash discounts or other forms of deductions

National regulations determine whether the tax base amount must be:

·         Net amount (taxable expense or revenue items minus cash discount)

·         Gross amount (taxable expense or revenue items including cash discount)

The tax on sales and purchases is the balance of the sales tax (SAP term: output tax) and prior tax (SAP term: input tax).

·         The output tax is levied on the net value of the goods and is billed to the customer. It is a liability of the company to the tax authorities.

·         Input tax is levied on the net invoice amount and is billed by the vendor. The input tax is a receivable which the company claims from the tax authority.

The tax calculation procedure contains:

·         The order of steps which have to be taken in the tax calculation procedure (the “from step” indicates where the system calls the base value for the “step”).

·         Tax types (condition types) that apply for the country. The system is delivered with the condition types necessary for each type of tax calculation. The tax calculation procedure already covers the correct condition types.

·         Account key/transaction key that covers additional specifications and is used for the automatic account determination for the taxes concerned. Predefined accounts keys are included in the SAP ERP system.

We recommend that you use these standard account keys.

A jurisdiction code is a combination of the codes of tax authorities that tax movements of goods and use their own tax rates.

Tax Postings -The taxes calculated by the system are usually posted via a separate line item to a special tax account. This is the standard scenario.

Taxes with certain transaction/account keys (for example, NVV) are distributed to the relevant expense/revenue item. This is the case for sales tax payables or other non-deductible input taxes.

To enable the automatic tax account determination you have to assign the following data to the account/transaction keys that generate the tax items during posting:

·         Posting keys (40 and 50 are recommended)

·         Rules that determine which fields the account determination is based on (the account determination can be based on the tax code or the account key)

·         Tax accounts

We define tax accounts, that is, accounts to which tax items are posted, in the field Tax Category by entering one of the following signs:

                     < For input tax           >  For output tax

The properties of the tax code define whether or not the tax posted is an input or an output tax.

"Post automatically only" must be selected if you do not want to post tax manually.

All other G/L accounts may have one of the following entries in the “Tax Category” field:

·         “For non-tax-relevant postings (e.g. bank postings)

·         "-" For postings that require an input tax code (for example, reconciliation account for payables from goods and services)

·         "+" For postings that require an output tax code (for example, reconciliation account for receivables from goods and services)

·         "*" For postings that require any tax code

·         "xx" For postings with the predefined tax code xx

The properties of the tax code define whether or not the tax posted is an input or an output tax.

Cross Company Transactions

·         One company code makes purchases for other company codes (Central Procurement)

·         One company code pays invoices for other company codes (Central Payment)

·         One company code sells goods to other company codes

The system creates and posts a separate document in each company code involved. In order to balance debits and credits within these documents, the system generates automatic line items which are posted to clearing accounts, for payables or receivables

The documents which belong to one cross-company code transaction are linked by a common cross-company code transaction number.

The tax is not distributed between the company codes according to their expenses. Therefore, this function may only be used if the transaction itself is not tax-relevant or if the company codes form a taxable entity.

The company codes of a cross-company code transaction may have different local currencies.

The tax calculated is always posted to the company code of the first item. Therefore, to ensure that the tax is posted to the same company code as the invoice, the invoice item must always be entered first.

Clearing accounts must be defined in every company code before a cross-company code transaction may be carried out. The clearing accounts may be G/L accounts, customer, or vendor accounts

To reduce the number of clearing accounts, you can use just one company code as the clearing company code. In this case, you only have to assign clearing accounts to every combination of the clearing company code and the other company codes, (that is three company codes need 2*2= 4 clearing accounts)

When the cross-company code document is posted, the system generates a cross-company code document number to link all of the new documents together.

The document number is a combination of the document number of the first company code, the first company code number, and the fiscal year. It is stored in the document header of all of the documents created for a complete audit trail.

Cross-company code documents can be reversed: To do this, use the reversal function for cross-company code transactions.

Real-time integration mostly affects the following cases:

·         As a result of a posting between controlling objects, a change results for an accounting object (profit center, segment business area or functional area) stored in a controlling object.

·         Costs are posted across company codes in cross-company code cost accounting In this case such postings must also be mapped correspondingly in accounting.

Key date activation defines when CO-FI reconciliation is possible with real-time integration.