cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Title: SAP Business One – Need Dynamic Account Determination Based on Transaction Type (Purchase vs

zak11
Discoverer
0 Kudos
173

Hi everyone,

I'm facing an issue in SAP Business One regarding account determination for a finished product.

This item is set as a finished product (it can be purchased, sold, and stored). By default, the stock and inventory variance accounts are linked to finished goods. The problem arises when I purchase this product: I want the system to post it using raw material accounts (stock and variance), not finished goods accounts.

I have used the extended account determination to solve this for purchase and sales documents, and that part works fine. However, for stock movements, SAP B1 strictly uses the accounts linked to the warehouse setup, regardless of the item's nature or the transaction context.

My objective is this:

  • When the item is purchased, it should affect raw material stock and variance accounts.

  • When the same item is sold or used in production, it should post to finished goods stock and variance accounts.

Currently, this is not possible due to how stock accounts are determined at the warehouse level in SAP B1.

Has anyone found a solution or workaround to dynamically determine G/L accounts based on the origin of the transaction (e.g., purchase vs. sales/production)? Ideally, the accounting should reflect the correct nature of the transaction while keeping the same item.

Thanks in advance for your help!

Accepted Solutions (0)

Answers (2)

Answers (2)

hdolenec
Active Contributor

I don't think this is a good idea to implement account determination this way. For starters, when you are selling an item, you cannot distinguish an item based on how you got it, meaning that when selling you should know wheter you are selling purchased or produced unit, and post it accordingly to finished goods or raw material. Otherwise you will have an inconsistency in your trial balance and annual financial reports (in a situation where you purchase something as raw material, and then sell it as finished good).

You could theoretically set advanced account determination based on some UDF and then choose how you want each document to be posted, but you will still have the same problem as mentioned above. Some points for best practice in this matter:

  • Purchased item and produced item are never the same. You should always diferentiate them, preferably with separate item master data. If you absolutely must have them under single item code, atleast separate warehouses for raw materials and finished goods. And also block users from simply transferring item from one whse to another.
  • GL accounts for inventory posting should always be set by some application wide criteria. You cannot have inventory posting dependable on individual transactions and some possible values that can be changed by users on each transaction. You should set inventory account determination by either some item master attribute (item code, item group, some other UDF attribute of item master data) or some warehouse attribute (whse code or UDF on whse master data).
Felipe_Lima
Active Participant
0 Kudos

Hi @zak11 ,

Forgive me if I've missed any crucial detail here, but at the top of what has been answered (and I agree 100%), how would you deal with the accounting difference produced by such determination?

Let's start from zero. The G/L is brand new, and so is your physical stock.

Say you buy Item A, and it debits your Raw Materials G/L. When selling it, you credit Finished Goods G/L. When will the first get wiped? Are you manually writing it off? What about your FG, wouldn't it go inverted/negative as there was no previous debit balance in it?

BR,
Felipe

zak11
Discoverer
0 Kudos
Hi Felipe , thank you for your reply , you re right , and I don't know how to figure it out , I thought of creating the same item with different itemcode but it's gonna be complicated for inventory issue , I don't know what should I do in that case
Felipe_Lima
Active Participant
0 Kudos
I think the alternatives proposed on the first answer could be analysed by you seriously. Realistically, I see no other option. Otherwise, you would be relying on manual adjustments and/or funky solutions which can result in a financial/inventory mess.