Updating Bank details for shared vendors in SAP

Introduction

In SAP the Bank details for the vendor is maintained at the general data level of Vendor master. In case an organization has multiple company codes then it is possible that vendors are shared between different regions and company codes. If the vendors are in different geographic regions then we might have different Bank accounts as well. But due to limitation of maintaining the Bank data at general data level, it is not possible to use different bank accounts for different company codes.

SAP provides the Bank partner type functionality to overcome this limitation. The bank partner type could be assigned to bank accounts in vendor master and same could be used at invoicing. When payment run is done, bank accounts are picked up based on partner type. This process could be manual and could result in payment to incorrect Bank account as well.

In this document I will discuss the process to automate the process of assigning the Bank Partner type. I have successfully implemented the solution at one of the client I worked and sharing the knowledge so that this could be used by all !!

Here is the solution which could help in automating the whole process.

Step 1: Use Company code as the Bank Partner type in vendor master

Step 2: Create a substitution rule at the line item level using t-code OBBH which will pull the company code (BSEG-BUKRS) and vendor number (BSEG-LIFNR) from invoice document to be posted and run a query on table LFBK to fetch Bank partner type (LFBK-BVTYP). If we get a value for field BVTYP from above query then move the same to BSEG-BVTYP. If there is no value fetched for given vendor and company code combination from LFBK, then BVTYP is left blank.

The query would be:

SELECT bvtyp FROM lfbk

UP TO 1 ROWS

INTO lv_bvtyp

WHERE lifnr = bseg–lifnr

AND bvtyp = bseg–bukrs.

ENDSELECT.

IF  sy–subrc = 0

AND lv_bvtyp IS NOT INITIAL.

MOVE lv_bvtyp TO bseg–bvtyp.

ENDIF.

Example:

Post invoice for vendor 132621 in company 1000. As the substitution rule is active, the bank partner type will be populated with value 1000.

When the payment run is done, the bank account for US will be picked automatically

Few points to be noted

1. If two or more company codes have one bank account and other company code have different, then leave Bank partner type blank for the company codes having same account. This was when invoice is create bank partner type will be blank for those company code and correct account could be picked

2. The automation fails in case 2 or more company code have same bank account and another set of two or more company codes have same account which is different from earlier one

Continue reading

Splitting Price Difference with SAP S/4HANA Finance

In this blog, I will explain about the SAP S/4 Finance functionality for “Split of Price Difference “. Normally Semi Finish and Finish Products are managed with price Indicator ‘S’ Standard Price.

Normally Semi Finish and Finish Material Valuated with standard price method value gets calculated from Standard Product Cost Estimation. Standard Product cost estimation is done using production planning master data and Controlling master data like BOM, Routing, Activity Price, Raw Material Price.

In actual scenario, once the production order gets processed and completed we found there is the difference between planned (Standard Cost Estimation) and in actual cost. In SAP this difference gets calculated at the month end using settlement process. Once the settlement completed system pass the accounting entries for the difference value.

Earlier in ECC is get recorded only on one account of “ Price Difference Account” and Costing base COPA is get distributed as per variance categories but not within Finance to GL’s. To get recorded this difference in Finance and get real-time reconciled with SAP COPA, SAP come with functionality Price Difference Split in S/4 HANA.

Configuration Steps required for “Price Difference Split “

1. GL master data need to be created as per different type of variance category.
2. Assign PRD account in OBYC.
3. Define Price Difference Split Profile
4. Assign GL Master to different Variance categories
5. Assign Company Code to Price Difference Split Profile

To get in details how it works we need follow Process steps as enlisted below.

1. COPC (Product costing of Finish Product) to get Standard Price of the Material.
2. Create Master data for BOM and routing in PP.
3. Create Production Order to GRN from production order process (TECO Status of the order).
4. Variance Calculation
5. Order Settlement.

System Configuration with screen shot

1. GL master data: As per requirement created GL Master Data for a different type of variance category.GL master Screenshot

As shown above, GL masters created all 9 different types of the variances.

GL master List Screenshot

2. Price difference account assignment as MM FICO IntegrationScreen Shot for OBYC

3. Price Difference Split Profile: Here we have to define profile for price difference with combination of Chart of Accounts and Controlling Area.

SPRO:

Financial Accounting (New) > General Ledger Accounting (New) > Periodic Processing > Integration > Materials Management > Define Accounts for Splitting Price Differences

Screenshot for Price Difference Split Profile

4. Assign GL with Price Variance Categories: We have created Different GLS Master for each of the price variance will assign that GLS over here to get split single price variance account in this different GLS.For example, for Price Variance, we assigned 52071000 GL

Screenshot for GL assignment with Categories

List of the GL Assignment

Screenshot with all categories assignment with GL’s

5. Price Diff Split and Company Code Assignment: Once we complete with split profile configuration we have to do an assignment of Company code to split profile. In this, we have to give valid from date. From this dating system will start price variance split for company code.

Screen shot for Company code assignment with Price Difference Profile

Now we have done with pre requites system configuration steps, we will processed with process steps to see how its work,

1. Product Costing for Finish Product: I have created Semi Finish product master and completed product costing run for the same using CK40N.

Screen shot for Product Cost for Material

2. BOM & Routing Master : Before go for product costing system should have master data for BOM and Routing in Production Planning,

Screen shot for Bill of Material Master and Routing Master

Routing

3. Production Order Process : Once production order completed and finish product received from order its should be set as TECO Status

Screen shot for Production order Technical Completed

4. Variance Calculation: As the month end activate to calculated variance of the production order and category of the variance we have to run variance calculation for the order.

Tcode: KKS2

Screen shot for Variance Calculation

Once the variance is get calculated we have perform next steps of the process it’s the settlement of the order.

5. Order Settlement: As the month end activity , Production orders need to be settled to record actual cost and variance of the production order. This activity is completed using Tcode KO88

Screen Shot for Order Settlement

Order settlement result shows details for the settlement with sender and receiver details and accounting document details,

Screen Shot for Settlement Receiver and Senders

Accounting Document for Price Difference with settlement generated by system, Document posted with line item for each variance category.

Screenshot for Settlement Generated Accounting for Price Difference with Split

Document

In the above example, System has distributed total price variance in two categories as calculated in variance calculation to Resource-Usage Variance and Output Price Variance.

Continue reading

Central Finance: Challenges in Finance Transformation

There are many business cases for S/4HANA Adoption for existing SAP Customers. However, the journey to S/4HANA Business Suite is fraught with its own challenges which are inevitable – the costs and risks of migrating and upgrading to a new system, especially for those customers, who have built very complex and distributed landscapes spanning across geographies and businesses.

One element of S/4HANA, which has caught the imagination of many of the Global Customers is Central Finance, which has been projected as the “Smartest”, “Fastest”, “Simplest” way to latch on to S/4HANA bandwagon with a quick win of simplified and unified financial reporting structure. The approach of Central Finance, instead of forcing customers to migrate their SAP instances to S/4HANA Application, allows financial documents to be replicated into a new Central Finance instance running on S/4HANA Business Suite. This is particularly true for Customers who have multiple old SAP ERP Instances and non SAP Systems as well. This gives an organization wide financial reporting view, with minimal intervention to the Transaction Processing Source SAP and non SAP Systems. It has been claimed to be a quick win solution for all the Enterprise Customers of SAP, with extremely short turnaround time for adaption.

However, there are series of multiple challenges, which need to be considered in implementation of Central Finance. Some of them can dearly cost the S/4HANA Journey and cost thousands of dollars in terms of effort and missed objectives. Some of the business related challenges and technical product related challenges that I have encountered in my journey on Central Finance Project are below:

1. Organizational Structure: One of the biggest use cases for central finance is to look at harmonized reporting for multiple markets. A logical extension of central finance on S/4HANA is to use the same CFIN System as a future Business System with integrated Finance and logistics transaction system. Therefore, it makes the organizational structure design extremely critical. In one of my projects, the customer in the legacy ERP (Source SAP ERP Systems) was using Business Area, Segment, Profit center etc as key considerations for reporting. Additionally, the Logistics Org Structures like Sales Org were not having in synch in various Source ERP System, as well as non SAP Source system did not have the org object which were relevant from SAP standpoint. As an IT Strategy roadmap, the customer wanted all the markets, where it operated to be on S/4HANA Business Suite and CFIN was the starting point. Additionally, many of the org structures were used in Account Based COPA in CFIN. So the Organizational structure design is a very crucial factor for long term journey and it is critical that design of org structure is thought through in CFIN. This should take into consideration the future logistics org structure as well

2. New GL and Document Splitting in S/4HANA Central Finance: Document splitting and parallel ledgers functionality is one of the key asks from Finance Transformation for a large scale Enterprise level customer. Many of the customers might be using a source system without functionalities like new GL or Document splitting, but would want to use the S/4HANA CFIN with these functionalities. However a source system without Document splitting for eg and a target CFIN System with Document splitting is NOT a functionality which is supported out of box. It takes a real challenge to make sure that all the documents replicated from the source SAP ERP and non SAP Systems have the right level of details to support Document splitting. There are options available like BADI_FINS_CFIN_AC_INTERFACE, which can be used to enable the right rules for populating the account assignments for Document splitting. Some of the examples for Document splitting and parallel ledger usage:

◈ The account assignments for Document splitting can be populated only in some of the line items and let standard Splitting set up take care of offsetting line item (eg, Profit Center and segment update in line items and let vendor line item derive the same from offsetting line item in case of Vendor Invoice Posting).

◈ Some of the FI Document line items can derive account assignment objects for document splitting from areas like material master, cost center etc. The customer specific changes, should not be triggered in case, where standard derivation logic can work

◈ Secondary CO Postings from Source systems, where the profit center is not available in one of the line items, the customer specification needs to be updated

◈ Data from Non SAP systems needs to be enriched with account assignment details for postings in the target central finance system

◈ There are transfer postings between subledgers which fail in the target system if it has document splitting active.

3. Master Data Harmonization: Master data replication of objects like Cost Center, Profit center, GL Accounts, customers, Vendors etc is a challenge. Data harmonization is a key challenge in Enterprise customers with multiple SAP Systems. Some of the challenges in master data set up in Central Finance encountered in my experience are:

◈ Customer Vendor Integration - The central finance function was used in S/4HANA 1610 EM instance, where the customers and vendors are created as Business Partners and the number ranges were overlapping in the source system for Customer and vendor account groups. To tide over the issue, the number ranges for Vendors were changed in the target CFIN System

◈ GL Master Data Replication - The SAP ERP System were substantially old systems, where transactional data existed for more than 15 years. As part of CFIN replication, only few years of historical data was being replicated into the target CFIN System. So the GL Master replication was designed based on the no of years in past where transactional data existed for a GL, that only was replicated into the target system

◈ Profit Center and Segments – One of the outcome of org structure redesign in CFIN was the whole profit center and segment usage in Central finance. The profit center in target CFIN system was tagged to Brand for reporting, while a segment was concentrated around line of business. However, the brands in the source system were limited to profit center with Business area being used for line of business reporting. The usage of different objects for reporting in source and target system entailed usage of complex mapping framework for replication of master data

◈ Material master – The material master usage was also a challenge due to disparate systems. A governance structure was required to be put in place to synch up the master data in the source systems and than have the same replicated in the target system.

◈ Data Services or SLT for Master Data – Harmonization and Business Objectives for Master data usage greatly determined the usage of the technology layer for replication between Source SAP and non SAP Systems to S/4HANA Central Finance Environment. Based on specific requirements like Data Filters for GL Account, Numbering changes etc, it was decided to introduce Data Services as a technology layer between Source and Target system for master data replication in S/4HANA Master Data replication.

1. MDG Layer and Value / Key Mappings: Central Finance offers an integrated MDG layer which can be used to recreate the accounting document in the target system, based on the data replication from the source. Some of the key learnings from my association with the central finance project were:

◈ Mapping Action - The mapping action determines if a transformation is required for any data element. In one of my project, business area was very widely used for financial reporting in the source SAP system. However, the complete reimagining of financial reporting meant that business area was not a key reporting factor in Central Finance. Hence a mapping action was set to clear the business area information from the source data. Essentially, the Mapping action should be designed taking into consideration of what are the key financial reporting parameters and if those parameters will hold true for the business even in case of a completely integrated system of records with finance and logistics transactions happening in the same system some time into future.

◈ Key Mapping - Typically the identifiers for a business object can be different in source and target system, given that Central Finance has the ability to connect to a heterogeneous set of SAP and non SAP systems. Eg, a customer 2212 in a source system may be customer (BP) 500000 in CFIN to harmonize master data. In one of the projectw, the key ask was to manage millions of customer master, vendor, gl etc to name and arrive at a common structure. The current design of central finance does not support automatic mapping of the source and target object number, though there is a standard upload tool to do an excel upload using the transaction code FINS_CFIN_MAP_MANAGE. However, to manage the real time replication of master data in the mapping layer, a custom program was created for each of the object to ensure, that there are no failures in transactions

◈ Value Mapping Structure - The value mapping is used in Central Finance to ensure if any transaction specific value has to be transformed. In some of the projects, the source systems had custom values for objects like Document types, Tax Codes etc. The whole objective of the transformation program was to ensure a standardized approach to finance structure across multiple markets. Eg, the markets used Document type R1 and RX for billing in two different geographies, but the intention in the target central finance system was to ensure that all the geographies, where the business operated should have the same document type for billing transactions. Hence the value mapping functionality was used to ensure that the new system has a standardized approach

2. COPA Transformation from Costing based COPA to Account based COPA: Most of the customers in SAP World use Costing based COPA. However, the preferred approach for reporting in S/4HANA Is Account based COPA. The data replication from the Costing based COPA to Account based COPA is not a standard and out of box functionality in S/4HANA. Some of the challenges encountered have been:

◈ There are scenarios in CB COPA where COPA data and GL postings happen at different time, whereas the expectation on AB COPA is to have the data based in COPA and GL at the same time. This presented it’s own challenges since AB COPA was supposed to be used for all kind of profitability analysis. Some of the design considerations for this transformation included moving key data like Sales Area data, material product hierarchy etc from material master, customer sales area data into central finance. These attributes were used in the derivation rule to ensure that the right attributes are populated. In some of the scenario like post goods issue, the data which is relevant for COPA was pulled through custom enhancements into Central finance.

◈ There are condition types on the billing cycle, which post data into COPA but not into GL. This functionality is not yet supported in AB COPA in S/4HANA. This means that the business had to look at the way, in which some of the discounts and pricing could be extended to Billing cycle

3. Transactional Data Posting: Central finance is supposed to reflect all of transactional financial data into a single place from multiple systems. However, the fine print is not all straight forward. There are not all scenarios which can be replicated into Central Finance. For eg, the transactional postings on Asset Sub ledger and WBS Elements through direct replication is not yet supported in central finance. There are quite a few challenges for customers, who already have SAP Source system which have parallel ledgers implemented. In such cases, the fiscal year differe nce in multiple ledgers presents its own issues. Some of the challenges assigned in Transactional data postings are:

◈ Asset Subledger postings are not supported in S/4HANA Central Finance. The posting on asset sub ledger in the source system have to be replicated on a normal GL Accounts in the target central finance system. We utilized the Key Mapping functionality in MDG Layer in Central Finance to ensure that the postings happened correctly

◈ The Transactional postings on WBS System in the source are not replicated into Central finance. This is mapped as a functionality, which will be addressed in the new releases of Central Finance. A custom enhancement was done in one of our projects to create the postings on other supported cost objects like internal order.

◈ Some of the legal entities had multiple ledgers in the source system with both ledgers having different fiscal year variants (one corresponding to 5-5-4 set up and other being April – March). The specification of the cutover month in source system for balance upload and document replication start due to different fiscal years in leading and non leading ledger meant duplicate data being posted in the non leading ledger, since the balance upload happens based on the fiscal year set up for leading ledger.

◈ A big challenge faced was the replication of the open items on the sub ledger and GL. The original document in source might be open at the time of initial load, but cleared in the period replication started. Such practical issues led to document failures in replication when subsequent actions on open items are not replicated immediately in central finance. These have been resolved through implementation of correction notes and custom code involvement

Continue reading

MM-FI integration: Account determination simulator

MM-FI integration: A conceptual understanding

Now we know how MM and FI are integrated and how the account determination happens. If we want to test inventory account determination, neither you need to do actual material posting in the system nor go through master data and customization to identify the accounts. SAP has delivered account determination simulation tool.

This helps to find how an account is determined while posting stock related transactions. We just need to input plant, material, movement type and select the transaction we would like to check say GR for purchase order, GR for process order etc. Based on above inputs, system would read customization, master data and simulate the account determination process. Apart from above, system would also identify missing account assignments for a given transaction. This would further help to analyze issues in an easy manner.

Go to T-code OMWB and close the initial popup. Click on Simulation button.

Fill in plant, material , movement type and enter. Transaction list would be automatically refreshed based on the movement type. Double click on required type of transaction to be checked say GR and click on Account assignments.

In next screen, we can see the list of all available transactions possible for this movement type, plant and material combination. Some fields like material type, valuation class etc. are derived from material master data. Some fields like valuation area, valuation grouping code etc. are derived from customization of the plant.

In this screen, we can see what all accounts are determined for different kind of transactions.

EG: For Inventory posting, you can see Debit/Credit posting keys and respective G/L accounts. If there are any missing account assignment for a given transaction, this is also highlighted with text as “Missing”.

In above example, you can see this happened for Purchase account and purchase offsetting account. We don’t have any account assignments here as we are not using this scenario. By this way, we can clearly identify the gaps in account assignment without even doing the actual posting.

We can change to different movement types and transaction combinations and see how account determination happens and based on what fields it happens. You can try this in your system for various permutations and combinations.

Second feature available with this tool is, to check the MM-FI integration: Account determination simulator. This would help to identify any conflicts in screen layout rules for the inventory G/L account item during material document posting.

Screen layout for the inventory account item is determined at two levels.

1. From field status group of movement type

2. From field status group of inventory G/L account.

Click on “Check screen layout” button. In Next screen, we can see what is the field status set at movement type level and G/L account level. We should ensure that, there is no conflict between these two field status exist.

EG: We can’t have a field mandatory in one FSG and suppressed in other FSG. Posting would fail in such cases.

Sample output:

Just hover on the small ICON to see if a field is Mandatory/Optional/Suppressed/Display only. Any conflicts found should get reported in the error log in tool bar.

In case of conflicts, priority would be given in the sequence below with the exception of Required and suppressed combination which is not allowed.

1. Suppressed

2. Display

3. Required

4. Optional

Third option provided by this tool is, “where used list of G/Ls”. This would help to Identify in what all scenarios a G/L has been configured in the system.

From the main screen of OMWB, click on where used list of G/L.

Enter company code and valuation area in next screen and execute.

Sample output:

This output shows the list of valuation classes and transaction keys a G/L has been assigned to.

Hierarchy is as below.

Chart of accounts

                |-G/L account

                                |-Valuation class

                                                |-Transaction event key

                                                                |-Account grouping code

Continue reading

MM-FI integration: A conceptual understanding

Most of us are comfortable with SD-FI-COPA integration concepts as it is easy to correlate and understand. But, when it comes to MM-FI integration, many of us find difficulties in understanding the concepts and account determination process. When I was trying to analyze my first issue related to how a stock account is determined in a valuated transaction, I was lost in OBYC. Let us try to understand few terminology used in MM-FI integration concepts. Once we are familiar with the concepts, we will further discuss account determination process in a stock movement related transaction.

Valuation area:

Stock of a material owned by a company is an asset to the company. Valuation area defines the organization level at which materials are valuated.

SAP has provided two options for valuation.

1.Valuation at plant level: All materials are valuated at plant level.

2.Valuation at company code level: All materials in all plants of a company are valuated at company code level.

This setting is defined in t-code OX14.

Valuated stock:

Total valuated stock = Stock in unrestricted use + Stock in transit between storage locations/warehouses of a plant + Stock in quality inspection.

Material type:

This defines the type of material.

EG: Raw material, Finished goods etc.

Material type is defined during material master data creation.

Movement type:

This defines the type of material movement from one place to other. Movement type enables the system to find predefined posting rules determining how the stock and consumption accounts are to be posted. All possible goods movements are already defined by standard SAP

EG: Movement type 101 refers goods receipt

Movement type is entered while posting stock movement related transactions. Most of the time, standard SAP automatically derives the movement type based on transaction code.

EG: If we go to MIGO, default movement type 101 is displayed by system.

Valuation class:

Valuation class is defined for the combination of plant and material (In Accounting 1 view of material master).

Valuation class allows posting of stock values of

1. Materials of same material type to different G/L account (Different valuation class is assigned in different plants for the same material)

2. Materials of different material type to same G/L account (Same valuation class is assigned to materials of different material type)

Note: G/L accounts can be defined at valuation class level along with other parameters.

Valuation grouping code:

Valuation grouping code combines the valuation areas having same business properties for the account determination. This reduces number of entries to be created for automatic account determination for the stock postings.

EG: Valuation area 1 and 2 are required to be posted to same G/L account, these are grouped to valuation grouping code ABC and G/L is determined based on valuation grouping code and valuation class.

Before using valuation grouping code, it needs to be activated in OMWM.

Valuation grouping code is assigned to valuation area in t-code OMWD.

In below example, five valuation areas are assigned to same valuation grouping code.

Account modification/General modification:

This key is used to determine different G/L account for the same kind of goods movement based on origin and target.

EG: During Goods issue, offsetting G/L is determined from transaction key GBB. If business wants to post to different G/Ls for goods issue for cost centers (Movement type 201) and good issues to orders (Movement type 261) for the same material and plant, Account modifier can help here. To understand this better, let us go to t-code OMWN where we define the transaction key and account modification for the movement type.

Transaction key which we see in OBYC is determined based on the movement type. In below screenshot, you can see all parameters are same for movement type 201 and 261 except account modification.

Please read F1 help on different fields in this screen to know more about functionality of each field.

T-code OMWN:

When material document is posted with these movement types, offsetting account is determined from transaction key GBB based on account modifier and valuation class.

From below screenshot, you can see that, different offsetting G/L account can be determined for the same transaction key and valuation class.

By Default, Standard SAP defines account modification keys for below transaction keys. User defined keys can also be defined and respective account determination settings can be maintained.

◉ GBB (offsetting entry for inventory posting)

◉ PRD (price differences)

◉ KON (consignment liabilities)

Below are the modification keys defined by SAP (Extracted from F1 help).

Modifiers for GBB

For the transaction/event GBB (offsetting entry for inventory posting), the following account groupings have already been assigned to the relevant movement types:

◉ AUF: for goods receipts for production orders with account assignment

◉ BSA: for initial entries of stock balances

◉ INV: for expense/revenue from inventory differences

◉ VAX: for goods issues for sales orders without account assignment object

◉ VAY: for goods issues for sales orders with account assignment object

◉ VBO: for consumption from stock of material provided to vendor

◉ VBR: for internal goods issues (e.g., for cost center)

◉ VKA: for consumption for sales order without SD

◉ VNG: for scrapping/destruction

◉ VQP: for sampling

◉ ZOB: for goods receipts without purchase orders

◉ ZOF: for goods receipts without production orders

Modifiers for PRD

If you also activate account grouping for transaction/event PRD (price differences) when you make the settings for automatic postings, the following account groupings are already assigned to the relevant movement types in the standard:

◉ none for goods receipts and invoice receipts for purchase orders

◉ PRF: for goods receipts for production orders

◉ PRA: for goods issues and other goods movements

Modifiers for KON

If you also activate account grouping for transaction/event KON (consignment liabilities) when you make the settings for automatic postings, the following account groupings are already assigned to the relevant movement types in the standard:

◉ none for consignment liabilities

◉ PIP: for pipeline liabilities

How are the account determination attributes determined for each transaction key/event?

Did you observe different set of fields appears for different transaction keys in OBYC while maintaining G/L account? Yes. This is defined in Rules for the transaction key.

EG: Select transaction key AUM in OBYC and click on “Rules” in toolbar.

You can see that general modification and valuation modifier is active.

If you go to G/L account maintenance for this key, you would see the same fields.

Quick snap of MM-FI Integration process:

When we do material posting for a valuated material, below flow happens.

1. Movement type and other attributes like special stock indicator, movement indicator etc are determined based on business transaction like goods receipt for PO, production order etc.(OMWN). This is defined by standard SAP.

2. Transaction key/event and account modifier is identified based on movement type and other standard attributes in step 1 (OMWN)

3. Valuation grouping code activation is checked from OMWM

4. If active, for the given valuation area, valuation grouping code is identified from OMWD

5. For the identified transaction or event, check if valuation grouping code is active or not in OBYC (Click the rules button for the transaction key)

6. Valuation class is determined from material master.

7. Based on the above identified attributes, select the G/L account from OBYC.

If system can’t find any account for the found attributes, stock posting can’t be done and system through clear error stating for which combination of attributes, G/L account is missing. Such errors are mostly seen during go live/while posting to new materials due to missing G/L account maintenance or due to incorrect valuation class in material master data.

Now you know the process, here is the short cut to find out G/L.

Account determination details are stored in table T030. If you want to know based on what details XXX account is determined, simply give that G/L in T030 table in field KONTS. This gives the possible combination of entries where this G/L is assigned. We can further drill down based on the filtered entries.

Continue reading