OVH POST INACTIVE GL POSTING

[Xchristi]

Hi All,

I am quite new in QAD EE 2018, our company is in the showroom phase in Hungary. In 1.4.1 Item master data I fill out the Overhead cost after the rebkfl.p I got INACTIVE GL accounts in postings as RCT-WO transaction OVH POST. The other four cost elements (Material, Labor, Burden, Subcontract) does not generate kind of this INACTIVE postings. Where should I do the necessary settings to avoid this? OR the issue is, that the Overhead is known as fixed burden or fixed overhead that's why its cost will appear in every RCT-WO transaction additional? (the rest of the postings are correct: RCT-WO postings are generated by the sum of the 5 cost elements multiplied by the produced quantity, MIRROR and MTHD CHG postings are correct as well)

 

[Luis GomezDelCampo]

Hi Xchristi...
Where to maintain the accounts related to the OVH? First check Product Line Maintenance or, if in use, Item Site Purchasing Accounts (Overhead Applied Acct-Sub-CCtr is maintained there).
Are the actual accounts inactive? You need to check GL Account Maintenance (or sub or cctr) accordingly.
Overhead is a cost assigned whenever an item is created or received. It is independent of actual manufacturing or purchasing costs. It is ASSIGNED as an expected cost that needs to be accumulated in the "Overhead Applied" Account every time that it is received or built, based on the cost associated to that item/site. Once the item is received/made, that overhead is part of its cost.

OVERHEAD APPLIED basically is something like: "well, you said that you want to accrue 1USD of OVH-TL (Overhead this-level) whenever this item is added to inventory". It serves as a tally to be compared against a series of expenses incurred and likely bundled together (or as in some specific cases such as a royalty or fee "on making").

Bare in mind that when receiving an item with OVH-TL, the OVH-TL is excluded from the TOT-STD during the PPV calculation; handled separately.

Let's start with an item that has no OVH. Say item is 31 USD in standard cost. When you RCT-PO with POPrice=35, you will get:
INVENTORY = +31 (STD=31)
OVH APPLIED = 0 (OVH=0)
UNVOUCHERED RECEIPTS = -35 (PO Price=35)
PPV = +4 (POPrice - (STD - OVH)) that is (35 - (31 - 0))... unfavorable PPV.

Now, say 1USD of that is in fact OVH. Same POPrice of 35:
INVENTORY = +31 (STD=31)
OVH APPLIED = -1 (OVH=0)
UNVOUCHERED RECEIPTS = -35
PPV = +5 (POPrice - (STD - OVH)) that is (35 - (31 -1))... unfavorable PPV.
See? OVH-TL (this level) is not expected to be part of the cost when comparing to "PO Price" and therefore is removed to calculate the PPV.

Another example that would result in favorable PPV. Say the PO Price is 28:
INVENTORY = +31 (STD=31)
OVH APPLIED = -1 (OVH=1)
UNVOUCHERED RECEIPTS = -28
PPV = -2 (POPrice - (STD - OVH)) that is (28 - (31 -1))... favorable PPV.

In case of production receipts same criteria is used. OVERHEAD APPLIED is triggered during the RCT-WO of FG as inventory absorbing the OVH-TL being valued within the total Standard Cost.

A RCT-WO does not create MTHD-CHG just because of OVH-TL. Just as with PO Receipts, the OVH-TL is first removed from variance calculations.

IIRC, reporting scrap does not generate OVH APPLIED (as it will not increase inventory).