- Ask a Question
- Write a Blog Post
- Login / Sign-up
CO Account Assignment and Attribution with S/4HANA
Co-authored by Birgit Oettinger and Stefan Walz
Welcome to this blog, in which we will provide insights into the new options of multiple CO account assignments and market segment attribution – innovations made possible with the Universal Journal in S/4HANA. The blog explains for which business processes this functionality is supported, which new reporting insights are enabled and which rules for CO account assignment – still – apply. The examples shown are taken out of SAP S/4HANA Cloud, public edition , but the principles also apply for the on-premise solution.
With the Universal Journal, all accounting applications share a common database. All the individual applications are views of the Universal Journal. This not only makes data transfers between the applications and subsequent reconciliations obsolete, but also makes the attributes of one application available to all others. Examples:
- the G/L ledger is also available in Controlling, revenue recognition and market segment reporting, this allows parallel valuations end-to-end.
- the market segments of the margin analysis application are available in G/L and revenue recognition.
- the CO account assignments are also available in G/L and revenue recognition.
Figure 1: the universal journal
With every cost posting to the project (journal entry 1), work in process and realized revenue is recognized and posted (journal entry 2). All postings are account assigned to the WBS element – also the balance sheet journal entry item. The journal entries for cost and event-based revenue recognition (EBRR) postings automatically derive the market segment. Thus, market segment reporting is directly available without the need for settlement or any other additional process steps. The account assignment type – here WBS element – defines the real account assignment in the universal journal.
The detailed information stored in the universal journal (ACDOCA) is the basis for financial reporting. SAP HANA supports performant reporting for all applications by aggregating the individual journal entries. This enables an aggregated reporting for all attributes and a drill-down to the detailed information, the individual journal entry, for all amounts and KPIs.
Figure 2: Product and Service Margin report for a customer project
The user posts expenses and time confirmations, performs a partial billing, and enters manual accruals. Together with these business transactions the system automatically creates additional revenue recognition postings to ensure costs and revenues are matching. All journal entries are account assigned to a project (determined by account assignment type PR). In addition to the project account assignment market segment attributes are updated. Thus, not only project reporting is possible, but also market segment reporting for example for product sold, customers or sales order.
To provide correct and value adding data, the update of additional CO Objects and market segment fields needs to follow clear rules. These rules are predefined by SAP per business process and cannot be changed. The additional attributes are derived by the system and cannot be entered manually. Details will be described in the next sections.
The glossary shows which different types of CO account assignments are described in this blog.
I CO Object as Account Assignment for P&L Postings
With S/4HANA cost elements and G/L accounts were merged. Now the general ledger account type determines how the general ledger account can be used in financial accounting (FI-GL) and management accounting (CO). The cost element is determined by the G/L account type “Primary Costs or Revenue” or “Secondary Costs” These G/L accounts are relevant for management accounting (CO). Postings to such G/L “cost element” accounts require a CO account assignment . P&L G/L accounts of type Secondary Costs control the value flow within Controlling, as they define for which kind of cost allocation methods the different P&L accounts can be used.
In combination with field status groups and validations , the cost element controls CO account assignments.
Only one CO Object can be the real account assignment in one journal entry item. This CO Object is determined via the field Account Assignment Type (ACDOCA-ACCASTY). Financial business transactions executed for a CO Object only consider the costs, which are real account assigned to it. Example for such transactions:
- distribution of overhead costs
- settlement of costs or revenues
- surcharge calculations
- revenue recognition
- commitment management
A real account assignment and a cost element are prerequisites for (market segment) attribution – see following chapters.
With manual account assignments, only one CO Object can be entered at a time. Additional account assignments can only be entered if they are statistical – see chapter III. l.
- ACDOCA-ACCASTY defines the CO Object type of the real account assignment.
- ACDOCA-ACCASTY is called Account assignment type on the UI.
- For P&L journal entry items using cost element and derived ACCASTY, additional to the ACCASTY the ACDOCA-OBJNR is updated, which contains the object number of the real account assignment. Both fields indicate, that the financial business transactions – examples above – run on the CO Object.
Examples for CO Objects and their account assignment types:
For non-operating P&L accounts (G/L accounts w/o a cost element category assigned) no CO objects or market segment will be assigned or attributed.
Figure 3: overview account assignment logic for P/L accounts
II CO Object Account Assignments for Balance Sheet
With the universal journal (ACDOCA) balance sheet journal entry items are automatically account assigned for defined scenarios. It is not possible to account assign balance sheet journal entry items manually.
Account assigned balance sheet postings are available in CO reporting. These CO account assigned balance sheet journal entry items are not relevant for subsequent CO processes like e.g., allocation or settlement (it is planned for asset and valuated project stock postings that they will be relevant for budget availability checks). Additional market segment attributes are derived from the real account assignment and updated in the journal entry item.
Balance sheet accounts differ from P&L accounts in the fact that at the end of the business process, they must have a balance of zero for account assignments and the market segment attributes. Therefore, additional checks are performed if balance sheet accounts are account assigned/ attributed. Example: if we assign an attribute for a goods receipt posting to material inventory but cannot assign exactly to the same attribute for the goods issue, then the balance sheet value for the attribute will not balance to zero and remain visible forever. The reporting is no longer meaningful. “Balance sheet accounts do not forget”.
- ACDOCA-ACCASTY defines the CO object type of the real account assignment.
- Market segment attribution can be updated based on the ACCASTY object.
- ACDOCA-OBJNR is not updated, therefore such postings are not relevant for subsequent CO processes like e.g., allocations. This is different to P&L accounts.
Figure 4: Project – Actuals report with balance sheet values
The following values are available for the project, and for the market segment fields customer 10100001 and the product sold P007 :
- a down payment request of 1,200€
- Accrued Revenue of 960€ and deferred revenue of 120€ – posted with event-based by EBRR.
- a manual accrual of 80€ – posted with the EBRR monitor.
These four balance sheet journal entry items inherit the cost object project SW009 and the related market segment fields.
The business scenario “WIP on a customer project” shows how this potential can be exploited.
We start with the app Balance Sheet/ Income Statement .
Figure 5: WIP amount in the Balance Sheet/ Income Statement report
The report shows a view on the assets selected with the company code 1010 and ledger 0L. From here we drilldown to WIP Accrued Revenue , which shows an amount of 16.008,33€. We mark the amount and navigate to the related report Display Line Items in General Ledger .
Figure 6: WIP amount explained by single journal entry items
The single journal entries sum up to a value of 16.008,33€ – which is exactly the value shown in the Balance Sheet/ Income Statement report. The line items are grouped by customer, product sold and project. Remark: the complete balance sheet amount is assigned to these attributes. With a drilldown to the project, we see the amount of 960€ for project SW009, the value shown in figure 4.
Remark: If a balance sheet journal entry item is account assigned to a market segment (ACCASTY=EO) or the item is attributed with a market segment, it is relevant for margin analysis realignment (details are described in section 4).
Let’s look on the business processes, which update CO account assignments in balance sheet items.
Event-Based Revenue Recognition (EBRR)
All balance sheet postings from event-based revenue recognition – like accrued revenue, manual accruals, or deferred revenues – are account assigned to a CO object:
- Sell from Stock scenarios are account assigned to market segments (account assignment type EO), the same as the subscription scenario available in public cloud Examples can be found in the following blog: margin-analysis-4-sell-from-stock .
- Customer Project scenarios are account assigned to projects (account assignment type PR). For examples see: financial-accounting-for-project-based-sales and financial-accounting-for-customer-projects-part-1-real-time-insights-in-project-based-service-scenario .
- Service scenarios are account assigned to service orders and service contracts (account assignment type SV and SC). Examples new-financial-accounting-for-service-management
Material Inventory with Valuated Project and Sales Order Stock
Sales order or project stock shall be visible in CO reporting. Therefore, inventory postings for this kind of inventories are account assigned.
- Valuated Project Stock is account assigned to the related project (account assignment type PR). Market segment attributes will also be added for these postings.
- Valuated Sales Order Stock will be account assigned to the related market segment (account assignment type EO) on roadmap. Market segment attributes will be derived from the related sales order item.
- There is no ACCASTY update for anonymous inventory available and not planned on roadmap.
Customer Down Payment in Customer Project Scenario
For customer project scenarios, down payment requests can be planned in the sales order item’s billing plan. The down payment request and the received down payment are posted on balance sheet accounts with an account assignment to the customer project (ACCASTY = PR). The system will also derive market segment attributes for these postings.
Event-Based Production WIP
With the new event-based production WIP, WIP postings will be account assigned to the related production order (ACCASTY=OR). In case of valuated project stock, the market segment attribution is provided too.
For details see New in Production Accounting – Event-Based Production Cost Posting | SAP Blogs
Statistical cost elements for balance sheet accounts (cost elements type 90) are not used any longer to enable CO account assignments for balance sheet accounts. In S/4HANA public cloud edition, CO account assignments are updated automatically for the processes described above. On premise customers can still go on using cost element type 90 accounts, if they already did so.
For AP/AR postings no CO account assignment will be derived. This is also currently not planned on the roadmap.
Balance carry forward postings do not keep/ update the account assignments of the initial postings (this applies for S/4HANA public cloud edition). Thus, drilldowns based on account assignments will not work in financial statement reporting after a balance carry forward is posted. But in other reports like e.g., Product and Service Margin or in one of the Display Line Items reports, the balance sheet values can still be analyzed by account assignment.
III Multiple CO Object Assignments in One Journal Entry Item
In general, there can be only one real account assignment in one journal entry item. This one and only will be identified by the account assignment type . But there are several use cases in which multiple CO Objects are assigned to one line item.
III.1 Statistical CO Account Assignments
With using statistical CO Objects there can be more than one CO Object entered on UI. In this case one CO Object is updated as real account assignment the other one as statistical account assignment.
The determination of the real and statistical object is done by the system. Two different cases can be distinguished:
- CO object is defined as statistical. This can only be done for internal orders or WBS elements in their master data. Example: You enter a PM order and a statistical WBS element. In this case the PM order is the real account assignment (ACCASTY = OR) and the WBS element is updated statistically.
- If you enter two non-statistical CO objects, this will only work if one of the CO objects is a cost center. In this case the cost center will be updated statistically, and the other object determines the real account assignment (ACCASTY). Example: You enter a non-statistical order and a cost center. In this case the order is the real account assignment (ACCASTY =OR) and the cost center is updated statistically.
If the order is a statistical order, the cost center becomes the real account assignment (ACCASTY = KS).
- In table ACDOCA there is always just one field for each CO object (e.g., one field for cost center, one field for WBS element). Therefore, it is not possible to assign two CO objects of the same type to one journal entry item, even if one of the CO objects is statistical, this is not possible. Example: you cannot enter an internal order and a statistical internal order
- Besides the statistical scenario it is not possible to enter more than one real account assignment on the UI – for example in a purchase order or supplier invoice only one real account assignment can be entered .
- In case the given combination of CO objects does not fulfill the rules (i.e. the real object cannot be determined) the error message “Account & requires an account assignment relevant to cost accounting” (KI 235) will be raised
Attribution – as described below – and statistical account assignments need to be stored and handled differently as statistical postings are relevant for budget checks (like real account assignments), whereas simple attributions are not relevant for budget checks. Therefore we distinguish these postings in ACDOCA:
- The account assignment type of the real CO Object is stored in the field ACDOCA-ACCASTY
- The fields ACDOCA-ACCASTY_N1 to N3 are used to distinguish statistical account assignments from real account assignments. Example: a journal entry item is account assigned to an internal order and a statistical WBS element. Result:
- real account assignment = ACCASTY = OR,
- statistical account assignment = ACCASTY_N1 = PR and
- the IDs of the internal order and the WBS element are updated in the related ACDOCA fields.
Let’s look at an overview of these rules.
Figure 7 overview of account assignment rules
III.2 Attributed CO Account Assignments
There is another option to manually apply multiple CO objects in one journal entry item. If a market segment is the real account assignment, there is the option to enter additional CO objects in the market segment pop-up. Like e.g., a WBS element and/ or an order. The account assignment type will be market segment (ACCASTY=EO) and in addition the order and the WBS element are attributed in the posting line.
Let’s look on an example, in which we account assign an expense account in the app Post General Journal Entries
Figure 8: manually post a journal entry that is account assigned to a market (profitability) segment.
For the journal entry item with the expense account 50301000 we assign a market segment as the real account assignment. We get the “Profitability Segment” (= market segment) pop up as shown in figure 9.
Figure 9: pop up for profitability (= market) segment attributes
On this pop up, values for e.g., sales order, order, cost center and WBS element can be entered.
The app Display Line Items – Margin Analysis can be used to analyze the journal entry:
Figure 10: app Display Line Items – Margin Analysis
You see the entered cost objects in the journal entry. The journal entry item is posted with account assignment type EO.
You can see these attributed costs for example in the project reporting:
Figure 11: Project – Actuals with attributed costs
Real and attributed/statistical costs are distinguished with the flag “WBS element is statistical” .
For several scenarios market segment attribution is provided automatically by system. This is done for the complete end-to-end processes, including balance sheet journal entries. To ensure data consistency, the following rules must be followed:
- The link to the object, which carries the market segment information, must be stable. This anchor object is assigned to all postings and used as reference object in case of realignment. Examples for anchor objects: In the customer project scenario, it is the WBS billing element. This is also valid for valuated project stock. The link from the WBS element to the billing element is stable. The market segment is derived from the settlement rule in the billing element or from the assigned sales order item. In the service order scenario, it is the service order item. This also applies for the Service with Advanced Execution scenario (service order with assigned PM order).
- Market segment reporting selects postings that use the market segment as the real account assignment and in addition attributed postings are also selected. The system ensures that the margin for the market segment is correctly updated with attributes. If only costs and no revenues would be attributed with a customer project, this would have a negative impact on the margin for the project/ market segment. An attribution can only be made, when it is ensured, that the matching revenues – or cost adjustments – are attributed as well.
Therefore, market segment attribution is only provided for revenue carrying objects, for which event-based revenue recognition (EBRR) is active. With the assignment of the market segment to the original journal entries a settlement to market segment/ profitability becomes obsolete.
The following scenarios are supported:
- customer project all customer projects in professional service scenario
- r evenue carrying EPPM projects (alias “Mario” projects) with a uniquely defined sales order item, that defines the market segment, derived from the settlement rule in the WBS billing element.
- service order and service contract
- Service with Advanced Execution (service order with assigned plant maintenance (PM) orders) in this scenario the PM order has a unique service order assigned, which defines the market segment.
Figure 12: overview of options for multiple CO Object assignments
IV Update Market Segment Fields in Journal Entries
The single attributes of a market segment are reflected as fields in the Universal Journal (table ACDOCA). This is also valid for margin analysis extensibility fields.
Fields exclusively used by CO-PA are stored in a separate area in ACDOCA. Examples for such fields are product sold, customer group, product sold group, and the margin analysis extensibility fields. For the latter the Manage Substitution/Validation app is available to derive the attributes. With this app you can create a derivation rule by selecting the business context and event “market segment”.
However, there are also fields in the market segment that are also used in other business processes. In this case the same fields are updated by these business processes and by market segment attribution. Examples for such fields are customer, sales order (and item), and the CO objects WBS element, order, service order and service contract. This allows an aggregated reporting for e.g., a project – see figure 11 – with postings, which are direct account assigned like e.g., goods issues and time confirmations, and attributed postings that originate for example from a production order, which is assigned to the project in case of valuated project stock.
Let us look first at an example, that describes the update in case of a market segment as real account assignment (ACCASTY = EO), the sell from stock business process
Figure 13: update market segment fields in sell from stock scenario
When the sales order item is created, a market segment object is generated. For the market segment determination some attributes are taken directly from the sales order item, e.g., customer and product sold. Others are derived from the customer master e.g., industry, country, and customer group. With the extensibility of margin analysis, you can also add your own market segment attributes.
The goods issue for the outbound delivery posts with reference to the sales order item. If margin analysis is active, the real account assignment is the market segment (ACCASTY=EO), which is assigned to the sales order item. The attributes of the market segment are updated in the Universal Journal.
In difference to the cost-based CO-PA solution the G/L accounts for COGS and billed revenue must be defined as cost elements for margin analysis.
More information about this scenario can be found in this blog https://blogs.sap.com/2022/09/06/margin-analysis-4-sell-from-stock-in-s-4hana/
Figure 14: market segment derivation in customer project scenario
In the customer project scenario, a fixed rule defines the derivation of the market segment. The example shows a time confirmation posting to the WBS element SW06.1.1 and the matching EBRR journal entry, which posts realized revenue and WIP on the billing WBS element SW06.0.1. The system checks if a unique sales order item is assigned to the WBS billing element. If this unique assignment is given, the market segment is derived automatically with every posting to the project – including revenue recognition postings. The product sold is derived from the sales order item. The customer, the sales organization, and the division are derived from the sales order header. If margin analysis extensibility is active, extensibility fields are also derived and stored in the market segment! These attributes are only stored in the journal entries, in difference to the sell from stock scenario described above, the market segment is not stored on the sales order item, but the assigned WBS billing element.
A reporting example is shown in figure 2.
The same rules also apply for the service management scenario.
The market segment attribution is by default active in S/4HANA public cloud. In on premise, it must be activated via the IMG activity “Activate Derivation for Items without Profitability Segment.”
Realignment of Market Segment Attributes in Universal Journal
The market segment attributes are derived and updated in the journal entry with every posted document. But the attributed objects can change over time. For example, a different product group is assigned to the material master, or the derivation logic of a market segment field is changed. To keep the data consistent and up to date, a realignment is offered for the market segment attributes (app Run realignment – Profitability Analysis ). This app changes the market segment attributes in already posted documents – this applies for real account assigned and attributed market segments. It is the only use case where already posted journal entries are changed. Of course, compliance is ensured. This is why only fields that are not relevant for statutory reporting are updated. For example, profit centers or segments are not changed during this realignment. A separate reorganization tool is offered for profit center changes.
Here a summarization of what we described before:
More information about all the described scenarioscan be found in the S/4HANA Controlling book https://www.sap-press.com/controlling-with-sap-s4hana-business-user-guide_5282/
We hope you enjoyed the blog and gained new insights and ideas.
Feedback is highly appreciated.
thanks for this interesting blog.
I am wondering how attribution could be use to better report on the billed material in a professional service scenario and derive the product hierarchy from the billed material.
It's an on-premise installation. Time and material billing using resource related billing. The billable WBS is linked to a sales order item. No settlement rule on WBS. Following the above described logic, in attribution the sales order item and its material, customer,... is used to derive the characteristics. Such we can in KEDR only use the "sold material" to derive the product hierarchy.
But we need to report on the different materials being billed or rather the product hierarchy assigned to the billed materials (and not the material on the sales order item).
Interestingly for revenue accounts in ACDOCA the billed material is stored in ACDOCA-MATNR and the Material from sales order is stored in ACDOCA-MATNR_COPA. But in KEDR the billed material is not available.
It seems a bit strange the attribution "promises" to analyze more details, but through the set-up to read the stable link between sales order item and billable WBS, you get always the same characteristics, which limits the ability to analyze data.
Any thoughts on this?
- Share Right click and copy the link to share this comment
thanks for sharing experiences.
Yes there are two fields in ACDOCA for the Material/Product. ACDOCA-MATNR reflects the used, consumed or billed material. It is a line item information and defined by the single business process (material movement or billing). ACDOCA-MATNR_COPA is a market segment field and derived and updated by the margin analysis application.
In the customer project scenario with time time and expense billing, there are mulriple billed products used, thus there are billed revenues posted on mutliple billed products. we cannot assign all costs and business process on the project ( e.g. overheads, manual accruals) to the different billed products. as we need to map costs and revenues for market segments, the billed material cannot be a market segment field in this scenario. There can be only one product used as attributed market segment, which we can derive for example from the assigned sales order item.
if there are mutliple market segments required with multiple product sold, you need to settle to mutliple market segments ( which works currently only with result anaylsis and not with EBRR)
nevertheless the billed product can be used - like many other business process fields - in the app subsitution and validation as parameter for a market segment derivation.
Enter the destination URL
Or link to existing content
Blog about all things SAP
ERProof » SAP CO » SAP CO Training » SAP CO Account Assignment
SAP CO Account Assignment
Normally, when a financial document is entered in SAP FI module , user has the option of entering the cost center in the financial document. However, when documents are entered from different modules or a cross-module financial transaction occurs, such as from MM or SD , there is no option of entering the cost center in the document. In this situation, the SAP system will derive the cost center through automatic SAP CO account assignment, substitutions, or through default settings made in the primary cost element.
Automatic SAP CO Account Assignment
The automatic account assignment has to be configured in the transaction code OKB9 . For posting made in external accounting, such as for price differences, exchange rate differences, etc., the SAP system automatically checks entries in the OKB9 settings and derives the cost center.
If you do not enter a CO object (order, cost center, or project) in external accounting postings made in FI, MM or SD modules and the posting is cost relevant, then the automatic account assignment checks the relevant cost center and makes the posting.
Here are examples of automatic account assignments:
- Banking fees, exchange rate differences and discounts in FI
- Minor differences and price differences in MM
The account assignment objects that can be maintained in the transaction OKB9 are:
- Cost center
- Profit center (profitability segment)
Normally, the automatic account assignment runs on the company code level along with the CO object. However, if the user wants to make the posting on the business area level, valuation area level or profit center level, it is also available in OKB9 settings. So basically it includes the following levels:
- Company code level
- Business area level
- Valuation area level
- Profit center level
The above 3 excluding the company code level are used in cases when the account assignment is needed below the company code level.
Here are the prerequisites of activating automatic SAP CO account assignment:
- Activation of the cost center accounting
- Creation of cost centers
- Maintenance of cost elements
Additionally, you can also create orders and profit centers as per the business requirements.
Settings in Transaction OKB9
Let’s discuss settings that are possible for automatic SAP CO account assignment in OKB9 transaction.
Start SPRO transaction and navigate to the following path:
Controlling – Cost Center Accounting – Actual Postings – Manual Actual Postings – Edit Automatic Account Assignment (OKB9)
Alternatively, you can start OKB9 transaction directly from the command bar.
- If you want to have the setting on the company code level only, then enter the company code and the cost element along with the corresponding CO object, i.e. a cost center, an order or a profit center.
- If you want to have the settings on the valuation area level, then enter the company code and the cost element and chose the ‘valuation area’ option in the account assignment detail as ‘1’.
- Similarly, if you want to have the settings on the business area or profit center level, then choose the option ‘2’ or ‘3’ respectively.
If you have chosen account assignment detail ‘1’ or ‘2’, then click on ‘Detail per business area/valuation area’ on the left sidebar.
Default SAP CO Account Assignment
In order to determine the correct CO account assignment, the SAP system performs several checks in the following sequence. First it checks the document which a user is posting. If the cost center is empty in the document, then the system checks if any substitutions are maintained for the particular G/L account . Next, if the substitution is also missing, then the system moves on to the OKB9 settings for automatic SAP CO account assignments. Finally, if these settings are also missing, the SAP system checks master data of the primary cost element (G/L Account) under the tab of Default Account Assignment . You can display this master data using the transaction KA03 .
You can maintain the cost center and the order in the master data of the primary cost element.
So, basically the order of checks the system makes is:
- Financial document – Cost center
- Substitutions – transaction OKC9
- Automatic account assignments – transaction OKB9
- Default account assignments – transaction KA03 / KA02
Lastly, if any of the above is not maintained, then the SAP system throws an error ‘Account X requires an assignment to a CO Object’ and doesn’t allow posting of a document.
SAP CO Account Assignment using Substitution
In cases where you don’t need OKB9 or default account assignment, the user can go for user exits where a specific G/L account is mentioned under the company and the value in the cost center is substituted by the cost center given in the substitution.
The transaction for maintaining the substitution is GGB1 .
Usage of substitutions for SAP CO account assignment is justified by the business requirement and usually SAP CO account assignment requirements are fulfilled by OKB9 or default account assignments.
Did you like this tutorial? Have any questions or comments? We would love to hear your feedback in the comments section below. It’d be a big help for us, and hopefully it’s something we can address for you in improvement of our free SAP CO tutorials.
Go to next lesson: SAP Adjustment Postings
Go to previous lesson: SAP Profit Center
Go to overview of the course: Free SAP CO Training
4 thoughts on “SAP CO Account Assignment”
it is helpful material i ask for more clear details for using substitution method for Account Assignment. thanks in advance
Sir, I am not receiving the training mails from yesterday 7/1/2019. I have completed my training till here(SAP CO Account Assignment) please do send the rest of the training emails for SAP CO. Hope you will do the needful.
I am getting the same error “Account 500911 requires an assignment to a CO object”. In OKB9, we have given company code, Cost element and ticked the check box ‘Indicator: Find profitability segment using substitution’ (V_TKA3A-BSSUBST) and not filled anything like cost center, order and profit center. in OKC9 we have created substitution. All the process happening through Idoc Message Type SINGLESETTRQS_CREATE and inside BAPI BAPI_SINGLESETTREQS_CREATEMULT triggering and raising this error. Cost center is not maintained in 1. Financial document – Cost center 2. Automatic account assignments – transaction OKB9 and 3. Default account assignments – transaction KA03/KA02 But we have substitution in transaction OKC9 to determine cost centre.
Where woulbe be the issue?
Leave a Reply Cancel reply
Do you have a question and want it to be answered ASAP? Post it on our FORUM here --> SAP FORUM !
Your email address will not be published. Required fields are marked *
Save my name, email, and website in this browser for the next time I comment.
Account xxxx Requires an Assignment to a CO Object
Hello CO Experts, When a document is being posted, system gives a message that A/c xxxx requires an assignment to a CO object. It is basically requiring you to enter a cost center or other CO object (like sales order, production order etc.) this is because a cost element is created for the P&L account. Accounting have created several P&L accounts without cost elements in the past and so they are able to post documents without cost center but assign profit center to the documents directly. To my understanding cost elements have to be created for every P&L accounts so that the cost / revenue is carried over to controlling. What are the impacts of P&L accounts created without cost elements and how possibly can we fix this issue? Please advise.
Popular Topics in Enterprise Software
This topic has been locked by an administrator and is no longer open for commenting.
To continue this discussion, please ask a new question .
Read these next...
Spark! Pro series - January 4th 2024
Today in History: 1847 Samuel Colt sells his first revolvers to the U.S. government Samuel Colt rescues the future of his faltering gun company by winning a contract to provide the U.S. government with 1,000 of his .44 caliber revolvers. Before Col...
What annoying tech issue would you love to find a creative solution to?
Engineers love to fix everything. What's something that you would absolutely love to fix?I'll go first.My number 1 most annoying tech problem in the whole world is.....Every time a tech (usually not me) signs into someone's PC with an Administrator accoun...
Temperature Monitoring solutions
Hi AllWanted to know if anyone uses temperature and humidity sensors for server room/data center temperature monitoring? Would like to explore options in this category!
Can DMARC et al be used with free mail such as Yahoo, Gmail and AOL?
I am setting up DMARC, DKIM and SPF for my clients' private domains. But some of my clients use Gmail and Yahoo as their business email. Since DMARC is implemented in DNS, and I am not going to get access to any of those domains, have these companies ...
Snap! -- Volcanic Moon Io, Plane Bad Luck, Nanotryannus, Graphene Semiconductors
Your daily dose of tech news, in brief. Welcome to the Snap! Flashback: January 3, 1983: Time Names Computer "Man of the Year" (Read more HERE.) Bonus Flashback: January 3, 1999: Mars Polar Lander Launched (Read more HERE.) You need to...
2335851 - SuccessFactors SAP ERP : The CO account assignment object belongs to company code A, not B [Valid Only for USA]
Your are observing the following symptom:
When running replication, an error is listed in SLG1:
The CO account assignment object belongs to company code A, not B Message No. KI100
- SuccessFactors BizX, SAP ERP
- Employee Central Payroll (ECP, EC Payroll)
KI100, KI 100 , KBA , LOD-SF-INT-PAY , please use LOD-EC-GCP-PY* , LOD-SF-INT , Integrations , LOD-EC-GCP-PY , Payroll Integration EC to Employee Central Payroll , LOD-EC-GCP-PY-EDR , Employee Data Replication , Problem
About this page
Search for additional results.
Visit SAP Support Portal's SAP Notes and KBA Search .
Posting Acquisitions for Fixed Assets
After completing this lesson, you will be able to:
- Post acquisitions for fixed assets
Classification of Acquisition Methods
Lisette has prepared an overview of the different methods for posting the acquisition of an asset from a business partner:
This method is used if there is an incoming invoice without reference to a purchase order.
In this method, you post an automatic offsetting entry to a clearing account (but without reference to a purchase order or supplier). This method if either of the following situations:
- The invoice has not yet been received, but you must post the acquisition.
- The invoice was posted against a clearing account in accounts payable, without assignment to an asset.
This method is performed in procurement with reference to a purchase order. The assets are posted and capitalized during the Goods Receipt – Invoice Receipt process.
When posting the acquisition of an asset by settlement of a work breakdown structure (WBS) element, costs are first posted to an expense account with the account assignment WBS element. When the project is complete or at period end, the WBS element is settled: the WBS element is credited with the asset capitalization costs and the relevant asset is debited.
Integrated Asset Acquisitions (with Accounts Payable)
Kevin received the invoice for the 3D printer. He now has the task of posting the invoice. In this case, the asset and vendor are to be entered in one transaction. Therefore, Kevin wants to analyze the posted FI document. Watch him navigate through the system to learn more:
After performing the tasks, Kevin asks Lisette what she thinks is the most important part of the FI document posting.
- The postings in the general ledger (in the universal journal) are always ledger-specific.
- The posting to the universal journal is always done at the time of invoice posting.
- All important information for assets, such as the asset number, asset capitalization date, and so on, is recorded in the universal journal.
Kevin wants to take a closer look at the document.
First, from the point of view of Asset Accounting.
From the point of view of Asset Accounting, the acquisition posting is debited to the asset balance sheet account and credited to the technical clearing account. The balance sheet account and the technical clearing account are reconciliation accounts. Reconciliation accounts cannot be posted directly. They are posted via the asset (for example, the 3D printer).
The determination of the balance sheet account depends on the asset class. For example, the asset class Machinery is linked to a different asset balance sheet account than the asset class Building .
Next, Kevin looks at the FI document from an account’s payable perspective.
In the context of integrated asset acquisition, the gross amount of the incoming invoice is posted to the respective supplier account within accounts payable.
In addition, there's a reconciliation account (Payables) in the balance sheet that automatically summarizes supplier postings. These reconciliation accounts are assigned in supplier master records. The offsetting entry is posted to the technical clearing account. The balance of this account is always zero.
The input tax is posted directly to the input tax balance sheet account.
Transaction Type Functions
Kevin asks Lisette, why a transaction type had to be entered during the acquisition posting:
Within Asset Accounting, the transaction type classifies the business transaction (for example, acquisition, retirement, or transfer). Because it also controls various system actions when posting business transactions, it determines how the transaction is processed in the system.
For asset postings, the system automatically proposes a suitable transaction type. You can also override the proposed type and enter it manually.
The system positions each business transaction to a column of the asset history sheet based on the transaction type.
The transaction type influences the posting made. For example, the transaction type determines whether the asset is capitalized or deactivated:
- If the asset is capitalized during the transaction, a capitalization date is entered in the master record.
- If the asset is deactivated during the transaction, a deactivation date is entered in the master record.
For retirement or transfer posting transactions, the transaction type determines whether these are posted with revenue (asset sales) or without revenue (asset scrapping).
The following are some useful examples of transaction types:
- 100 External asset acquisition
- 105 Credit memo in invoice year
- 200 Retirement without revenue of prior-year acquisitions
- 250 Retirement without revenue of current-year acquisitions
- 210 Retirement with revenue of prior-year acquisitions
- 260 Retirement with revenue of current-year acquisitions
- 300 Retirement transfer of prior-year acquisition from capitalized asset
- 320 Retirement transfer of current year acquisition
- 330 Acquiring transfer of current year acquisitions
Asset Value Date
Asset Value Date : The asset value date is the value date of an asset transaction from an Asset Accounting point of view. It can deviate from the posting and document date and be in posting periods that are already closed for Financial Accounting. However, the posting year and asset value date year must be the same.
Because the asset value date can have a direct influence on the amount of depreciation, the system creates a default value whenever possible. For example, if the document date is older than the posting date, the document date is proposed as the asset value date.
Capitalized On : You can enter the capitalization date manually when you create the asset master record. The system uses this date as the default asset value date when you make the first acquisition posting.
If you do not enter a capitalization date in the asset master record, the system automatically adopts the asset value date of the first acquisition posting as the capitalization date.
When a capitalizing transaction type is used, the system inserts the asset value date of the first acquisition posting in the capitalization date field (Capitalized On) in the asset master record.
First Acquired On : The date of initial acquisition on the relevant master record is also derived from the asset value date. The initial acquisition date is retained even if the first acquisition is reversed.
Further acquisitions or other transactions cannot be entered before the initial acquisition date.
Depreciation Start Date : The system determines the start period for depreciation calculation from the asset value date and the period control method specified in the depreciation key of the transaction category. The depreciation start date is the first day of the start period. Similarly, the system determines the book value of an asset at the point of retirement.
Each transaction on a capitalized asset triggers the automatic calculation of depreciation on the posting amount. The asset value date, corrected by the period control of the depreciation key, is the key factor in determining the depreciation start date.
For example, if the asset value date is February 5th and the period control of the depreciation key is "pro rata at period start date", the depreciation start date is set to February 1st.
Post an Integrated Asset Acquisition and Analyze the Value
After Kevin has informed himself about the important date entries, he wants to activate the 3D printer himself. Help him post an integrated asset acquisition and analyze the value.
Post an acquisition and analyze.
Kevin watches the video to understand the app.
Now it’s your turn. Help Kevin posting the company Car in the Post Asset Acquisition and Quantity Adjustment app.
Post Asset Balances Against Expense and Analyze
After checking the documents, Kevin realizes that the acquisition value of the company car is incorrect. The accessories of the company car (such as the new winter tires) were posted as an expense (travel costs account).
Now it’s your turn. Help Kevin post the asset balances against expense in the Post Asset Acquisition and Quantity Adjustment app.
Credit Memos (Received)
Post credit memo and analyze.
To follow Lisette’s explanation about the how to post the credit memo with the correct transaction type, follow her along the system by watching the following screencast.
In this example, Accounts Payable has already entered the credit memo. The following posting exists: Vendor on debit side against clearing account on credit side. Therefore, use the Post Asset Acquisition and Quantity Adjustment app.
Now practice yourself. Now practice yourself.
The Quantity Function
- Low-value Asset (LVA) is a special type of asset. In this example, depreciation is carried out completely in the year of the acquisition.
- If you enter a unit of measure in the master record, the quantity becomes a required entry field when the asset is capitalized.
Create Asset Master Data with Quantity, Post, and Analyze
Get some insights by following Lisette and Kevin on their way through the system.
Help Kevin manage fixed assets and post the 30 chairs in the Post Asset Acquisition and Quantity Adjustment app.
Log in to track your progress & complete quizzes