Google+ SAP Controlling Event Based Posting - SAP ABAP

SAP Controlling Event Based Posting

For each CO posting, the system creates a document, to which a unique number is assigned. One of the CO project team shows you how he grouped the CO business transactions and then assigned them to document number ranges.To check the FI/CO interface, you post some documents on a preliminary basis.You want to display the data on the cost centers using different reports. Investigate the reports reports contained in the standard system.You explain the various reporting tools to the other members of the CO project, to show their flexibility.

Posting documents from HR and MM are often very extensive. Try to devise as easy ways as possible to correct faulty account assignments in CO.As yu require information on future payment commitments in your cost center, consider the use of commitments.You want to enter all activities, which you provide for a customer, on a cost object. You  can use this to create the billing documents.

Document Number Assignment 

The various activities that change an object (such as, a cost center, or an order) appear in the R/3 system as business transactions. You need to define number intervals for all business transactions that  generate CO documents. It is possible to copy document number  intervals from one controlling area to another.There are two steps to issuing number intervals for documents : 
- You group more than one transaction together. If you want to assign a different number interval to each transaction, you can create a group for each transaction.
- You assign the group to an internal or external number interval. This enables you to use one group of number intervals for similar transactions.
You define number intervals for CO documents independently of fiscal year. The document numbers can be assigned in ascending order. SAP recommends that you create different number interval groups for actual and plan transactions.This ensures that reorganization programs that run separately for actual and planning data also reset the number intervals separately.

Event-Based Postings: Integration

You can enter primary costs either directly in Financial Accounting (as for an invoice in Accounts Payable) or they can be generated from other applications (as for a goods movement in Materials Management) and then transferred to FI. These business transactions (events) generate FI documents that are required for purposes of external reporting within  accounting. These documents are stored in a central document file for external accounting documents. FI documents contain at least two line items and must balance to zero.Line items are also written in Controlling for these business transactions if they are also posted to CO account assignment objects (such as cost centers). The CO posting is often a one-sided entry, as only the income statement postings are posted to CO. The line items record the business transaction from a cost controlling standpoint, and are managed in a CO line item file. In addition, the R/3 System summarizes all line items to form totals records, which in turn are stored in a CO totals record file.



Account Assignment Logic - Posting to Cost Center
Cost and revenue postings in CO can trigger subsequent true and statistical postings:
- True postings can be processed, and can be allocated or settled with other controlling objects. Only true postings (and only one) can be made to CO. This is where the information is, that is used transferred to FI for reconciliation purposes.
- Statistical postings are only used for information purposes. You can make as many statistical postings as you wish.
The account assignment object determines whether a posting is statistical or true, in other words, the account assignment is either a true or statistical object. For example, the master data of an overhead cost order are used to determine whether the order is true or statistical. Only true postings are made for a true order, and likewise, only statistical postings are made for a statistical order. The cost center is the exception to this rule. You can make true and statistical postings for a cost center.

If you want to post CO costs, you need to use the source document  to identify the corresponding true CO account assignment object. You can enter additional statistical objects, or the system can derive them. In this simple example, the cost center is entered into the FI document, so that the true CO posting can be made.The system transfers the profit center from the master data for the cost center, for the statistical posting.You always make statistical postings to the profit center.

Account Assignment Logic - Posting to Cost Center and Order

During posting, only a true account assignment object can be transferred. The only exception to this rule is the account assignment to a cost center, and an additional, true account assignment object. In this case, the system always updates the cost center statistically. If you specify a true order and a cost center in the posting row as described in the example above, then the true posting is made for the overhead cost order. Statistical postings are entered for the cost center and the profit center.However, if the order is only statistical, then it is posted to as such, and the cost center receives true postings.
 
You can analyse statistical postings to cost centers in the Cost centers: Actual/Plan/Variance report (scroll down in the report).You can only assign one object type to each posting row. This means that you cannot post the same transaction row to more than one cost center, or order, and so on.

Account Assignment Logic - Revenue Postings

Revenues can only be posted as true postings to a profitability segment, sales order, sales project, or to a true order that can have revenues. Revenue postings to the profit center are statistical, the same as for cost postings.Revenues can also be recorded as statistical values on cost centers .

Default Account Assignments and Automatic Account Assignments

You can define automatic account assignments or default account assignments for postings to primary cost elements. The R/3 System then automatically includes the specified (additional) account assignment for the primary postings you make. You define automatic and default account assignments for cost elements that you always post to a particular cost center. You can also define the assignment of an overhead order or profit center to a cost element. Whether automatic or default,the account assignments are default values that can be overwritten in the application.

Automatic of default account assignments are required for primary cost elements used in automatically-generated postings such as prices differences, exchange rate differences, and discounts.

You enter the default account assignment in the cost element master record. Here, you enter the account assignment at controlling area level and at account level.You enter automatic account assignments in Customizing in the activity "Automatic Account Assignment". You can enter the account assignments at different levels:
- Controlling area, account, and company code
- Controlling area, account, company code, business area and/or valuation area 
- Profit center
 
When the system is deriving the information, it determines the most detailed account assignment, so it reads the entries in Customizing first. If the system does not find any data here, then it uses the master data for cost elements. The assignment objects defined for automatic account assignments therefore take priority over the additional account assignments for the default account assignment.

Validation

You can increase the accuracy of the CO data by using valdiation and substitution. In validation and substitution, the R/3 System che cks whether the data entered meets one or more of the conditions that you defined. These checks take place during data entry, thereby ensuring that only valid data is posted.

You create validations and substitutions for the controlling area and for a particular event. An event is a particular point in transaction processing. The following events have been defined for the CO component:
- The "line item" (0001) event uses data from the CO document header (COBK) and the CO coding block (COBL). It controls the posting in both external accounting and in CO.
- The "document header" (0100) event uses data from COBK and affects only manual CO postings such as repostings or activity allocations.
- The “CO internal posting: Sender/Empfänger“ (0002) event is only used for CO internal postings,and is used for checking sender-receiver relationships in periodic allocations.
 
You use validation to carry out validity checks on objects such as cost elements or cost centers. If the conditions you specified for executing business transactions are not met, the R/3 System displays a user-defined message. This could be a warning, error, or information message, or the system stops your posting with immediate effect.


You can also carry out validation checks when making  substitutions. However, if your condition is met for a substitution, the R/3 System substitutes the values with others defined by you, without informing the user of this change.An additional event - the order event (0010) is defined for substitutions. This is used only for
collective processing of order master data.If you have defined a substitution that contradicts a validation condition, the system informs you of this by displaying a message. We can therefore say that validation has priority, or is "stronger" than substitution.
Automatic Commitment
Commitments are payment obligations that are not entered into the accounts, but at a future date lead to actual costs. They are incurred in the purchasing function, in the "Materials Managment" component:
- The internal communication for a purchasing request is known as a purchase requisition (from the ordering party to the purchaser). A purchase requisition is a provisional obligation, that can be changed at any time. You do not need to assign a CO object to a purchase requisition row. If you do not do so, then the commitment is not displayed in CO.
- A purchase order is a contractual agreement specifying that goods or services from a vendor will be taken under certain, agreed conditions Therefore, a purchase order is a binding obligation, as it is based on a contractually fixed agreement. For a purchase row that is assigned to a cost element, you need to specify a CO object, so the commitment is also displayed in CO.

If you create a purchase order with reference to a purchase requisition, the commitment is reclassified (as a purchase order commitment) in CO.The commitment is reduced by processing goods receipts against the purchase order. Actual costs are posted to the CO object. This business transaction is continued until the purchase order is processed, and the commitment amount is zero. You need to activate commitments management in the controlling area in CO. Additionally, the cost center may not be locked for commitments (locking indicator).Commitments are not reduced when you create an outline agreement. These are only incurred when you create the contract release order (contact), or goods release order (scheduling agreements). 

No comments :

Post a Comment