Account determination for GR/IR clearing account (WRX) as per Purchase order document type
As per standard SAP, system determines G/L account as per defined rule for the account determination. Where, we can’t use the option account modifier for some transaction event keys (like BSX, WRX) at the time goods movement (like goods receipt). As we know, account modifier or valuation modifier is an option to use different G/L account within a transaction event key. Although, you can assign a G/L account as per account modifier for the transaction event key WRX or BSX from OBYC, but system will not determine the G/L account as per your settings, system will still determine the G/L account which is assigned for blank account modifier. It is well possible to use the account modifier for some transaction event keys (like GBB, PRD) in standard SAP. But SAP has given an option for customer requirement. You can determine the G/L account by using the account modifier for the transaction key WRX via some user exit. But, it is not possible to use the account modifier for the transaction event key BSX. SAP has written it as hard code for the account modifier as blank for the transaction event key BSX. System reads the function module ‘MR_ACCOUNT_ASSIGNMENT’ for the account determination process. Here is the coding line for the transaction event key BSX:
The value VORGANGSSCHLUESSEL is equal to transaction event key (T030 – KTOSL) and KONTO_MODIF is equal to account modifier (T030 – KOMOK). You can find it also in the same function module:
So, you can’t use any account modifier for the transaction event key BSX. Also as per the business process, it should be. You should not use multiple G/L accounts for one valuation class for the stock account posting. It can create many problems during the balance sheet finalization.
Now, for the transaction key WRX, in standard, system will determine the G/L account without using the account modifier. But system has given an option to write your own coding to call the account modifier as per your defined rule. System is calling the user exit ‘EXIT_SAPLKONT_011’ to read the customer defined rule during the account determination process. Here is the customer call function:
You can see here, system is clearing the KONTO_MODIF and calling the customer function ‘011’, which means ‘EXIT_SAPLKONT_011’. You can double click on the call function to check the user exit name. So if we will define our own rule for the account modifier by coding in this user exit, then we can determine G/L account with regards to the account modifier as per our requirement.
Now let’s explain about the business requirement:
Suppose your company is using two different processes as standard and subcontracting for same material. We know that one material can have only one valuation class (without using split valuation). So, as per the standard SAP, it should get determine the same G/L account for transaction event key WRX for both standard and subcontracting process. But your organization wants it different. They want to use G/L account ZZZZ for the standard purchase order and G/L account YYYY for the subcontracting purchase order for the GR/IR clearing account (WRX).
You need to find the differences between these two PO types. I am going to use different document type for both processes. NB for the standard purchase order and ZSC for the subcontracting purchase order. As result, system will determine the G/L account ZZZZ for standard PO with document type NB and G/L account YYYY for subcontracting PO with document type ZSC. You can make some changes in your document type. Allow only the item category L for ZSC document type (for subcontracting purchase order) and do not allow the item category L for the document type NB (for standard purchase order). So that user can’t do mistake to choose document type for both processes.
Enhancement and Coding:
As explained, we need to use the user exit EXIT_SAPLKONT_011. The user exit includes the program ZXM08U18. Here, you need to take help from your ABAPer. You need to create this include program from SE38 (tell your ABAPer to do the same). Then you need to write the code accordingly:
IF sy-mandt = ‘400’.
SELECT SINGLE * FROM ekko
WHERE ebeln = i_wrxmod+0(10).
IF ekko-bsart = ‘ZSC’.
e_konto_modif = ‘JWK’.
Here, 400 is client, ZSC is document type for subcontracting purchase order and JWK is the account modifier which will be used to determine the G/L account. If you do not want to include the client, then you can remove the line item. Here, I’ve just defined the different account modifier for the subcontracting process, so that system will consider this account modifier (JWK) for the subcontracting process and blank account modifier for the standard process (as defined in standard program code). Activate the include program.
Now go to OBYC and enable the account modifier option from rule (note: before enable, take a backup of the all entries as because, once you change the rule, you will lose the existing entries). Now assign the G/L account as per your requirement:
Save the entry.
Create two purchase orders, one with document type NB and item category blank for standard purchase process, and create another purchase order with document type ZSC and item category L for subcontracting purchase process.
Post the goods receipt for the standard purchase order and check the accounting entry:
You can see the G/L account 150039 has been determined for the standard purchase order. Now post goods receipt for the subcontracting purchase order and check the accounting entry:
Here you can see the G/L account 150196 has been determined for the subcontracting purchase order.
Note: I have given an example by using the document type. If you want to do it differently (like as by using item category or any other which would be different for standard process and subcontracting process), then you can also do it by changing the coding part.
It is really a good document.
Is it possible to have different GL for PGI for the same material based on Reason for sales order by using this user exit?
Hi Dev ;
It is so beneficial for MM Experts ...
Well, WRX transaction key is not searched by system at the time of PGI.
System posts just Stock account (BSX) Credit and COGS account (GBB-VAX) Debit.
So, this enhancement will not work in this case. As I have explained you can't use account modifier for BSX transaction event key, but you can use the account modifier for the transaction event key GBB. If you want to use different G/L account (for transaction key GBB) for PGI, then you can do it by using different movement type. Check my document Different accounting for different purpose against movement type
it's a common requirement but the standard doesnt allow that, since the schedule line of the SD document can't be determined based on the order reason (and the schedule line determines the movement type).
Maybe someone can make a blog with the customer determination of the schedule line in SD 🙂
Great document. keep it up DV.
If you are telling the ABAPer the code he has to write, why don't you write it yourself? Do you have SE38phobia or something like that?
Sorry if I come on too strong but this dogmatic separation between functional and ABAPers (which I've seen in a lot of places), when functional can write the code, makes my head go bonkers.ABAP is (still) a statement based language so the syntax is very simple.
If you can't write code, don't try. If you can write code, and it's something very simple (like this), do it yourself instead of bothering another person who is busy doing something you can't do. If I had to call an ABAPer each time I needed 5 lines of code done, I would've quit SAP by now.
Come on.. That just a simple sentence.. Do not need to hyper about it.. 🙂 If a functional consultant can write the code then of course he doesn't need technical person.
It pains me whenever I see this SAP idiosyncrasy be propagated. It really hits a nerve. Sometimes it appears as if programming is somehow lesser work that the "brain trust" shouldn't touch, even if it takes 10 minutes and they can do it.
Something that eventually leads good ABAPers to look for functional work in order to get respect.
And to make it clear, I go hyper not because of your post, it's because I see a lot of people say these things with zero malice, but the myths are propagated.
Functional consultants might not have the developers key that I'm sure is needed to do this kind of user exit. Also ABAP changes may need to be done in a separate client where functional folks don' have access. In some public companies separation of duties is enforced sometimes to the point of paranoia, you wouldn't believe.
I believe that are situations like that, but I've never actually seen them. What I have seen are functional consultant refusing to write 10 lines of code in SE38, when they have no problem writing it down in Outlook.
Anyway I admit I went hyper but this is touchy subject. And it's not personal, since I've always done the funcional work, I just think it is a bad way to manage a group of people and I keep seeing good programmers see no choice but to join the functional side, on many many companies.
Just something to add:
one field is needed... why select all fields?
And why using a Table-Statement? You could also do it with a Count-statement, but I would at least prefer this coding-snippet. Just to make sure, the coding is really only processed when the client equals 400.
I do not complain about the if-statement with the client or the hard-coded values. Everybody need to know if this is a way he/she wants to walk on.
Since now you can do,
select single bsart from ekko into @data(lv_bsart)
A lot of the lazy induced * will disappear 🙂 . Eventually. 🙂
Depends on the release... good old world 😆
If I do not want to restrict it for client 400 only, then I need to remove these two lines
IF sy-mandt = '400'.
Isn't it ?
Yes, you are right, but in your code the second if-Statement is always processed.
I don't want to set the focus on the client, I want to just improve your code-snippet, that all the code is just processed, when the client equals 400.
That's it 😉
At first you guys complain that functional folks can't write a few ABAP code lines. But then you complain about the quality of those ABAP lines. Seems a little illogical to me. 😕
I complained about functional not doing code they write, Florian didn't 🙂 . That's the logic 🙂 .
Well, I guess then you two make The Perfect Troll together. 🙂
But this kind of one of the answers why ABAPers should be the ones writing the code - so that there is no stuff like hard-coded client and SELECT *.
Well, to be fair, I have examples in my organization of ABAPers who hard-code stuff, and use select * and FAE and all other kinds of verboten practices.
But, separate of duties is a concern in organizations like ours, and even more of a concern is the cost of developer's keys. We only have a handful of those. On the other hand, we have two functional analysts on our team who are former ABAPers, and I keep threatening to give them developer's keys and they are like "no way!" But they do write the best technical specs, so our 'actual' ABAPers love working with them.
Because ABAPer never hardcode and select * right? 😉
We are awesome tag team! 🙂
Have you ever seen something other? 😛
Excellent documentation. 🙂
Well explained from a functional consultant point of view. Definitely useful !
I am using it to fulfill my requirement . Very nice document.
But my question is, is this mandatory to define the client. Because suppose I have 4 client so I have to write same coding in every client .
I am facing same situation.
Business want diff. GL for WRX Keys.
So as per your saying , need to create new Account Modifier, right?
I am trying it and let you know.
And need chanve
Your solution has worked. Thank you very much.
Very well explained. My best wishes.
Does anybody knows if you can also modify WRX only for the delivery cost condition in the PO?
any help is appreciated!