Determine Account for new condition type ( in Transaction BSV)

[former_member215739]

Dear SAP Community,

We need to defined a new condition type for eco fee.

When we sell or buy special types of material, we have to calculate this fee to the invoice.

Business requirement is:

1) In Good Receipts: this fee should not be added to the material price. Inventory account should be only credited by the pure material account.

2) In Invocie Receipts: this fee should be posted automatically to a P&L Account (89****)

I set up the condition type as following:

- M/06: condition category: B (delivery costs), accruals

- M/08: pricing procedure maintained with account key ZEE for accruals and freight account

- OBYC: account key ZEE with G/L Account 89****

However, in the Purchase order (with position type X) for a material price 100 EUR, I get the following posting document for the good receipts:

How can I make this 5,00 Eur posted to a separated offsetting account? I don't want it to be posted together to 890000.

G/L Account	Description	Amount
890000	Product Cost of Goods Sold	105,00 EUR
190201	GR/NI (WERE) Clearing Account	-100,00 EUR
89****	Eco Fee PnL Account	- 5,00 EUR

When I check in OBYC, the transaction, which leads to the G/L Account 890000, is BSV. What is BSV and when does it appear?

I would be very thankful for your support.

best regards,

Thanh

[former_member215739 · Accepted solution]

Former Member: thank you, I configured it as statistical and removing accruals doesn't work...

and @SAP WARRIOR:

Many thanks for your replies.

- It works if the transaction is BSX. When the item in my purchase order has the account determination category E (Customer individual request), it works as in your link below. That fee doesn't added to the inventory account 310000.

- However, it doesn't work when the transaction is BSV. This transaction BSV appears, when my purchase order item has the account assignment category X ( all aux. acct. assgts.) . And that fee is added to 890000 in MIGO.

The scenario is: I have a Direct Delivery Sales Order, which means: the vendor delivers the goods directly to the customer. I don't receive the goods (Is that the reason, why BSV comes up?)

After creating the direct delivery sales order, I get a purchase requisition number automatically created. Then the PO is also automatically created. This PO item has the account assignment category X. Consequently, in MIGO, the BSV is used... and I have got this problem... 😞 

Please can you explain more about BSV to me, and how can I configure, sothat it works for this case?

Thank you all.

[former_member183424 · Accepted solution]

How your system is posting amount to transaction key BSV ? As I have stated VSV transaction key will be used in subcontracting process only.

Are you using item category L ?

You process seems like a Third Party Ordering Process

Also have a look into the KBA document for uses of transaction key BSV 1872336 - BSV and FRL not triggered in accounting document at goods receipt for subcontracting purch...

[former_member215739 · Accepted solution]

Dear Patra,

Thank you for the reply.

I made some tests. I changed the accounts in BSV but it still keeps posting to the account 890000.

Then I looked at the GBB-OBV, the account 890000 is also there. I changed this. However the MIGO keeps posting to the account 890000...

It'a purchase order with account assignment and the PO item has the account assignment category: X (all aux. acct. assgts.)... It keeps posting to the account 890000 (Product Cost of Goods Sold).

Now I'm confused, what transaction key was implemented in MIGO... sothat it get posted to 890000.

Please help me. Thank you.

[former_member183424 · Accepted solution]

Right, Here no work for transaction key BSV. It is picking from GBB-OBV, because you have maintained the account modification as OBV for account assignment category X in OME9. That's because system is picking the G/L account into purchase order line and then accounting document's line item.

Now coming into your original issue, re-check your settings with regards to the wiki content, specially check again the accrual flag for condition types (ZFR1 and FRA1 as per this wiki) in M/06.

[former_member215739]

Dear Dibyendu Patra,

Thank you very much.

I checked the wiki link Posting planned delivery cost to Non-inventory account - ERP Operations - SCN Wiki

I'm sending this solution with Vendor for the condition type to Business for review.

- For account assignment category X, I have checked that in OME9 , it's assigned to ZZX, and in GBB-ZZX I have the account 890000.

And the posting items in the FI Document is weird.

Best regards,

Thanh

[BijayKumarBarik]

Hi,

No need to work with BSV and any other accounting keys(GBB-OBV). Better work with condition type( keep negative in nature) and setting in of that condition with other condition types in MM pricing procedure. For more refer.

PO Delivery Costs add to Material Cost | SCN

Regards,

Biju K

[former_member314228]

Hi,

BSV is change in stock account which will come into picture during subcontracting process.

Can you let us know which accounts are getting posted during your GR along with transaction keys(WRX,GRX,BSV etc) for further understanding caz BSV should not be hit in your case if its not a subcontracting PR.

Do we have 'L'as item category in PR/PO?

Regards,

Ranjjini

[former_member184536]

Hi

Your requirement can be fulfilled either through Purchase Accounting or through below link

Posting planned delivery cost to Non-inventory account - ERP Operations - SCN Wiki

Regards

Manish

[former_member183424]

BSV ? It should not. It should be BSX (which has been triggered in your accounting document). BSV is used for Change in stock account which is used in subcontracting process.

Anyway, your scenario is quite basic, It has been explained many times in SCN (even by me also).

Just search in Google with the term "delivery cost separate account scn". You will get your answer in first result.

[ajitkumar]

try removing the accrual check mark in Condition  and in the pricing procedure make it as statistical