Topic: random UOM in sales invoice

when i made this sales invoice, the UOM was different than what I assigned to the item.
this came up,
Item Code     Item Description     Quantity     Unit     Price     Discount     Total     Quantity Delivered
SAF612     Safeguard Soap White 60gx162     1     cs     2,410.00     0.00     2,410.00     1
TID662     Tide Powder w/ Freshness of Downy 74gx216     1.00     1     1,690.00     0.00     1,690.00     1.00

The first row is correct but the second row should have the same UOM. I dont have "1" as UOM so I guess this is just a bug. Is there a way to solve this or should I just deactivate the product and make a new one?

2 (edited by apmuthu 11/10/2015 02:01:22 pm)

Re: random UOM in sales invoice

Line 218 of sales/view/view_sales_order.php:

    label_cell($stock_item->units);

is used to display the UOM.

The array $stock_item comes from each element in $_SESSION['View']->line_items.

Hence, unless the unit of measure was not pre-defined or the session got corrupted, the proper UOM should be displayed. It is possible that if session values get corrupted in several places, then you need to check the php's "session save path" setting and if other programs or multiple instances of FA deployments with the same session path are causing conflicts due to overwriting.

The original data storage is based on these session values when the form is submitted. It is hence imperative to make sure that if the correct UOM is chosen on editing a line item and committed by clicking the line item's submit button before proceeding with submission of the order as a whole.

Re: random UOM in sales invoice

Hi apmuthu, I don't know how to check the session values but I think it's not the problem. I checked if the correct UOM appears when I make the sales order but after placing the item code the UOM remains blank. With the rest of the product, the correct UOM appears after you hit tab. When I clicked the add item button, the UOM then became 1. The UOM I assigned to it is bags. There is no problem with the other products having bags as the UOM. Thanks for the help btw.

Re: random UOM in sales invoice

I'm curious about what's actually stored in the database.

Try something like
SELECT description,units FROM 0_stock_master

If the two items have different values for "units", there is a bug where the items are added to the database. If not, there is a problem reading or parsing the data.

Re: random UOM in sales invoice

Which browser and version are you using. Ajax is necessary to fill in the UOM from the stock_master lookup table. If that does not work, then the insert would be as you get now.

Re: random UOM in sales invoice

i checked the value in stock master and it is "1". So, I changed the value in mysql and it is now showing correctly.
im using firefox, fa 2.3.22. Thanks for the help guys.

Re: random UOM in sales invoice

You might want to upgrade to FA v2.3.24+ (snapshot).

Re: random UOM in sales invoice

apmuthu wrote:

Ajax is necessary to fill in the UOM from the stock_master lookup table. If that does not work, then the insert would be as you get now.

Shouldn't errors like this be handled at the database level? I've always regarded MySQL as something of a Mickey Mouse database, but surely it supports foreign key constraints by now?

Re: random UOM in sales invoice

FA does not support Foreign Key Constraints like CASCADES as yet not even in FA 2.4 for now. Foreign Keys are however used in joining tables and extracting requisite data using BEGIN-ROLLBACK/COMMIT-END constructs.

Yes, MySQL is a Mickey Mouse DB and that is why it is popular - low / no learning curve and FREE - does not require a job in an MNC or any degree or qualification / certification to teach and use. MySQL still does not support function based indexing / constraints. It has no record number concept for end user usage and relies on primary keys alone instead. And yet it costed billion(s) to be purchased by the vendors of expensive databases! Governments in India, China and Russia (a lot of developers came in from there) were not consulted (only US / EU permitted them) before the purchase was authorised and certainly no major developer persons were asked their permission either.

Shouldn't there be a ban on sale of Open Source projects?

I do hope FA does not get sold any time soon - if it is going that way, I hope sufficient notice is given to the users / developers to fork and co-exist.