When you add new/ update an item with a *receiving quantity* more than 1, (Let's say 63), so you then do a new receiving of that particular item, you will get the option to select pack as x63 or x1.
So if you select more that 1 Ship pack (receiving quantity), (in this eg. that is, x63) and finish the receiving successfully, your inventory of that item update with increment of 63 and inventory count details also, good.
But when you realize the receiving you just did had a mistake and you go and delete it, the inventory reduction is wrongly calculated.
Instead of decreasing the inventory by 63, it reduces it by 1.
So i fixed it.
Set group_concat_max_len session variable to prevent count totals at the bottom of the tables becoming `1 to null of null items` when database includes significant number of item rows.
per #2788 the Supplier table results from Item->get_all() and Item->get_info() are not used anywhere and causing a bug where the duplicate fields between the items table and the suppliers table (deleted and category) are returning just one value to the results. This creates the undesired effect of expecting items.deleted and items.category but getting values from suppliers.deleted and suppliers.category.
- Created business logic in view to show dropdown if enabled
- Created business logic in controller to calculate key/value pairs of
dropdown
- Adjusted attribute model get_definition values to send values also if
definition_id is -1 or > 0 but not 0 which is what we are now using as
no definition instead of -1
- Added undelete function in Attribute model which could be useful for
adding the ability to restore attributes once deleted.
- Added business logic to Config controller save_general to
create/remove the attribute when the box is checked or unchecked.
This sorts alphabetically:
- Attributes on the Attribute->Item view
- Dropdowns for adding attributes in the Attribute->Item view
- Dropdowns for the attribute values themselves.
