on 09-18-2015 1:13 PM
Hi All,
We are facing this incorrect cost distribution in one of the POs in our production system.
Scenario : We have a PO which has condition types ZFR1 and ZFR2 as shown below,
Once the PO is created, a series of GR and GR reversal happened - GR 1 posted, GR1 reversed, GR 2 posted, GR 2 reversed and GR 3 posted on the same day(all for value 2,800,000.00 , i.e. the PO value picked from info rec). Some 2 months later IR was posted with the same value 2,800,000.00.
Now the issue is that each GR doc is having different value in corresponding accounting document,
GR1
Reversal of GR1
GR2
Reversal of GR2
GR3
Issue1: Why are the accounting entries for GR and corresponding GR reversal differ, for ex GR1 has
TEK GL account value
PRD/gl account 111113 (22400 -)
ZFR/ gl account 111114 (22400 -)
ZFR/ gl account 111113 (22400).
But GR1 reversal has
PRD/gl account 111113 (22400),
ZFR/ gl account 111113 (22400)
ZFR/ gl account 111114 (22400 -)
Issue2: In the 2nd GR why/how the system calculated the value as 67200(this is 3*22400) for ZFR ?
Issue3 : GR reversal of GR2 has different values
GR2
PRD/gl account 111113 (67200 -)
ZFR/ gl account 111114 (22400 -)
ZFR/ gl account 111113 (67200).
But GR2 reversal has
PRD/gl account 111113 (112000), ...........................(i.e 22400*5=112000)
ZFR/ gl account 111113 (22400)
ZFR/ gl account 111114 (112000 -)
Issue 3 : Same case with GR3
PRD/gl account 111113 (246400 -)..............................(i.e 22400*11=112000)
ZFR/ gl account 111114 (22400 -)
ZFR/ gl account 111113 (246400).
Hi,
PO which has condition types ZFR1 and ZFR2
The G/L account 111114 (with ZFR) credited on GR posting and GR reversal posting
The G/L account 111113 (with ZFR) debited on GR posting and GR reversal posting
I am not sure why the same G/L account 111113 is assigned to PRD and ZFR in OBYC.
As G/L account 111113 in debited and credited with PRD keys, the same characters not happening with G/L account 111114 with ZFR key?
You need to find logic(debited and credited) missing ZFR key in t.code:OBYC with for G/L account 111114.
As you using two condition types ZFR1 and ZFR2 in PO-why system posting all with only ONE ZFR key for both(GR posting and GR reversal)?
Check design details for condition types ZFR1 and ZFR2 with accounting key setting's(all) for both in t.code: OBYC with G/L account for debit and credit.
Regards,
Biju K
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Bijay,
Below are the OBYC settings for ZFR and PRD,
The postings are happening for both the ZRF(not only for one ZFR) keys one by one.
GR1
111114 22400- ZFR
111113 22400 ZFR
Reversal GR1
111113 22400 ZFR
111114 22400- ZFR
GR2
111114 22400- ZFR
111113 67200 ZFR and so on..
How is the system calculating these value(67200, 112000, 246400 etc).
Hi,
You ZFR key assigned to G/L account 111113 (debit) and G/L account 111114(credit) in OBYC.
But why you having two G/L accounts for ZFR key?
1st understand the design behind of your account posting related incorrect cost distribution for two condition types ZFR1 and ZFR2
2ndly check, why your business designed two condition types ZFR1 and ZFR2
3rdly check - why your two condition types ZFR1 and ZFR2 assigned to same ZFR key in MM pricing procedure
4thly check- positions of two condition types ZFR1 and ZFR2 in MM pricing procedure( any routine for special calculation)
You could use ZFR key for condition type ZFR1 and ZFF key(new key) for condition type ZFR2- cross check with business
You need to analyze as you only view your system, involve FI/CO team for better analysis and finally go for best decision, correction-if any!
Regards,
Biju K
When the invoice is posted ? What about purchase order history ? Is your condition type ZFR1 and ZFR2 used for delivery cost ?
By the way, there are lots of OSS notes and KBA (along with lots of discussion) exist in service market place which explains the logic of goods receipt reversal. Have you checked that ?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
94 | |
11 | |
11 | |
6 | |
6 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.