The Number of Units that are displayed for a Production Receipt are the cumulative of the components of that item. (tfgld410.nuni)

Example:

I have a BOM where to make one item of A I need 1 item of B and 1 item of C. This means that My production Issue for a production order for one item of A will be one item of B and one Item of C. The production receipt of A should also be one since I am manufacturing only one item of A. However, the session is displaying the receipts as 2 (it is cumulating the quantity of the components B and C).

I have not noticed this before. Pls let me know if this is a functionality or a bug.

Regards

Sai Krishna

This value is having a reference to ticpr300.nuni and the same value is reflected in the session ticpr3501m000 (display standard cost prices by item).

There is also a logic to it. It shows the number of components that make up the finished good.

For ex if to make one unit of A I need two units of B then the material component quantity of A will be two.

This logic works fine as long as it is limited to the cost price components and cost calculation.

The problem starts when the same quantity is given in the finance integration. This is because when U say that the transaction is a production receipt and give a quantity as a reference the user will automatically assume it to be the quantity that is produced and does not know that it is the component quantity. The problem is more acute since there is no other field (in integration) that gives me the quantity of the transaction.

This case can be simulated using any normal production order that has a BOM. This problem is very obvious for the transaction Production receipt since instead of giving the quantity that is produced it gives me the quantity of the components. It is even more confusing when there are production rejects.

Pls let me know Ur opinion on this.

Sai,

This is Baan functionality, not a bug. It does permit you to validate/audit the cost of the financial transaction per the BOM, Routing and order quantity at the time of processing. As you’ve noted, however, the units have no practical value for reporting SFC quantities completed.

Remember that integration transactions in table tfgld410 are recorded by Cost Price Component.

In your example, say 1 unit of item A consists of 1 unit of item B and 1 unit of item C. If the cost of both B and C consist only of Cost Price Component RAW, the cost of A also consists only of Cost Price Component RAW. There will be only one debit transaction line in tfgld410 for the production receipt with Cost Price Component RAW. The Number of Units in tfgld410 is “2” although it may seem “logical” that the units would be “1” because your reference is the completed quantity of item A.

Suppose, however, that the cost of item B consists of Cost Price Components RAW and FRT, and the cost of item C consists of Cost Price Components RAW and LAB. The cost of item A will have 3 Cost Price Components (RAW, FRT and LAB) and the production receipt will have 3 debit transaction lines in tfgld410. It makes sense that each transaction line has a number of “units” but it also makes sense that these units do not add to the completed quantity of item A.

The easiest way to produce the report you require showing the quantity of A completed from the integration transactions table (for production receipt) is to [relationally] look up the quantity delivered from the SFC order recorded in tfgld410.

Scott Johnson

Hi Scott,

Thanks for the reply. I was initially misinformed by BaaN Support that this was a bug even though I felt it was a functionality.
I feel that the ideal situation is that the completed quantity is displayed separately.

Today I got a call frm BaaN Support confirming that this is a functionality and also that this limitation is overcome in BaaNERP.

Sai Krishna

Sai,

Few would disagree with you that "...the ideal situation is that the completed quantity is displayed separately."

It's some consolation that simply posting the Qty Completed to tfgld410 would not by itself solve all reporting issues. Because costs are posted by Cost Price Component, the Qty Completed could be posted to each integration line of the Production/Receipt or only to one (for example, line 1, seq 0). The casual user could still easily misinterpret the data.

Flexibiity is a double-edged sword. The bottom line is that you really need to understand the data.

Scott