Inventory Valuation Report showing 0 (zero) on Unit Cost

Yes it is related to the currency. Try to increase the currency decimals in user preferences, f.i. 6.

Joe

Maybe even more decimals.

Joe

It makes me confused, I tried using new COA USA, and try the same test using USD as home currency. It works fine with The end date 27-11-2017. Hmmm?

The sql in the function getAverageCost() defined in the file reporting/rep301.php (Inventory Valuation Report) is like:

SELECT move.*, IF(ISNULL(supplier.supplier_id), debtor.debtor_no, supplier.supplier_id) person_id
FROM 1_stock_moves move
     LEFT JOIN 1_supp_trans credit ON credit.trans_no=move.trans_no AND credit.type=move.type
     LEFT JOIN 1_grn_batch grn ON grn.id=move.trans_no AND 25=move.type
     LEFT JOIN 1_suppliers supplier ON IFNULL(grn.supplier_id, credit.supplier_id)=supplier.supplier_id
     LEFT JOIN 1_debtor_trans cust_trans ON cust_trans.trans_no=move.trans_no AND cust_trans.type=move.type
     LEFT JOIN 1_debtors_master debtor ON cust_trans.debtor_no=debtor.debtor_no
WHERE stock_id=102
  AND move.tran_date < '2017-11-27' 
  AND standard_cost > 0.001 
  AND qty <> 0 
  AND move.type <> 16 -- ST_LOCTRANSFER
ORDER BY tran_date;

This means that when the purchase invoice is made on 2017-11-27, the sql above computes the average cost to just before the said date and not including it. If a subsequent date is used for the query, then all is well (save for the irrational value at times not obeying the decimal limit).

@joe: must we correct line 65 in it:

            AND move.tran_date < '$to_date' AND standard_cost > 0.001 AND qty <> 0 AND move.type <> ".ST_LOCTRANSFER;

to be

            AND move.tran_date <= '$to_date' AND standard_cost > 0.001 AND qty <> 0 AND move.type <> ".ST_LOCTRANSFER;

so that it takes into consideration all transaction up until the end of the day and not to just before the date?

The decimals issue can be corrected by appropriately formatting the return value at the end of the said function or where it it used in line 211 in the report although line 229 uses it without assignment when $details is present. The culprit is line 357 in includes/current_user.inc for irrational numbers with large number of decimal places when the value of $dec becomes 14. It is best hard coded to 2.

Ok, I will.

/Joe

This problem still persists in report 301 (inventory valuation report). I am getting zero for unit cost and value for one of the items. When i change to_date from 30/06/2020 to 29/06/2020 the report works fine, no zeros. However report 308 is working perfectly fine with any to_date.
I am using frontaccounting 2.4.8 php 7.2 ubuntu 18.04

thanks for the response. I just checked server shows the right time. I have two locations, say location A and B, for inventory. both locations have 3 units in stock for that item. when I run report 301 without location filter, it works perfectly, without zeros, and shows 6 units with correct price and correct value (price x 6). but when I apply location filter to location A, it shows zeros for price and value of that item. However applying filter to location B shows right quantity (3), unit price and value for that item. The problems is visible with only location A filter.

Although the specific rep301.php has not changed in the meanwhile, some functions it directly / indirectly uses may have been changed post release in other files. No harm in putting in the post release changed files - it does not change the db in any manner and any missing sys_prefs variables entries will get auto populated. Then see if the situation changes.