Is there any reason not to have decimal inventory?

Well, inventory isn't supported at all in core.

I'm open to the idea of decimal inventory; it has a number of problems associated with it (introducing rounding errors and additional data requirements, see below). I did think about it when working on this, but decided that simpler was better.

It would mean that you would have to not only have a field on the product that listed the amount of inventory, but have a second field that said how much inventory this product accounts for, and have that default to 1.

Essentially, lots of added complexity, not clear how many people get the benefit.

My thoughts are to have decimal inventory be a secondary module. Decimal inventory is most useful on Raw materials, liquids, and fabrics. Those materials have additional rules and best practices on how they are handled and stocked. Decimal inventory products need more controls, rules, and limitations than other product types. It seems best to keep those additional rules sets out side of the initial module and be added in with a secondary module when needed.

Here are some examples of what I mean.

Let’s say you sell fabric. Your customers will order your BLUE-LINEN-01 in units of meters (keeping it international). You would set up the product type with some limitations. You want your customers to have the ability to order the length of fabric they want, but it's not feasible to allow your customers to order any decimal units they want. Yes, they may only need 10.4m of BLUE-LINEN-01, but it causes you more overhead in allowing that type of transaction. Instead you may allow HALF units or quarter units to be sold. That’s a Limitation on Units of Measure (UOM).

In addition your reams of BLUE-LINEN-01 are 50m long, so this limits the total amount a customer can buy on a single line item. If your customer wants 100m of fabric, too bad you don't have that. (Maybe you can make a special order with your manufacturer.) That’s a Limitation on the quantity ordered.

There is an analog component to Decimal Inventory Products. It’s harder to get an accurate measure of units sold. You may not want the system to handle the stock levels for these items. Things like raw materials, liquid, fabric or other measurable substances have to be measured out. Your customer orders 10m of BLUE-LINEN-01 but you cut off 10.02m of fabric. Then the next order you cut of 8.1m, followed by 6.08m, 7.04m, and so on. At the end of the day you could be off by 5m! In fact you expect to be, because ONE you’re not perfect, and TWO you want to give the customer just a little more slack. So, there is a Limitation of Accuracy.

In fact most operations wouldn’t trust a system where stock was handled in this manner. Stock levels would checked at the end of the day, week, month, or whatever the cycle, in order to get a more accurate number of the actual stock on hand.

There is also the issue were multiple products come from the same SUPPLY, or SUPPLY product. A company would sell items SIX-1_5ML-BRW and EIGHT-12_5ML-BRW that both contain the same SUPPLY product. These two items wouldn't have stock levels. The SUPPLY product, SPC-STUFF, would have a stock field and would be used to monitor the stock on hand. At the end of every day the tanks where SPC-STUFF is stored would be measured, and then the stock level would be adjusted. This is a Limitation of Measure.
Hope this is helpful.

Commerce Line Item stores quantities to two decimal places, but by default, form validation prevents decimal values from being entered. Since stock changes will often arise from line items, it seems like it would make sense to follow the same convention for stock (except, of course, that this would require more work, but work I'd be willing to contribute).

see Commerce_stock Roadmap for the idea of using a sub module system where the current integer stock system will be a single sub module 'simple stock' and other sub modules can be developed like 'decimal stock'

I can't say I know anything about the history. I discovered it by reading commerce_line_item_schema() in commerce_line_item.install.

Closing the issue as this is not a real issue with the current version of stock and we can look at this for version 2 again if needed, we have a link from the roadmap so we can get back to this if needed.

Conversation with rszrama in IRC:

it is indeed arbitrary, but it is there to support fractional quantities
<rszrama> rfay: all you have to do to have fractional quantities is tweak the form so it doesn't validate for integers
<rfay> rszrama, hmm. So Commerce might be able to support fractional quantities? Stock has tried not to do that :-)
<rszrama> rfay: yeah, Commerce definitely does support it; we just don't offer a UI based way to change the forms to support it
<rszrama> rfay: it's kinda like multiple order types; we support it, but we don't offer any practical way to use it through the UI

@videographics as stated by the roadmap, the idea of version 2 is to create a framework that uses sub-modules to implement the specific stock check.
The result I believe will be a very small sub module “simple stock” implementing the decimal stock. This will act as an example to other sub-modules like a potential decimal stock without the need to branch the main stock module.

However I will be very happy to look into an implementation of a decimal stock as part of the basic “simple stock” module or a second “decimal stock” module if you or anyone can provide an example site that utilises decimal quantities.

Hi @videographics,
The Commerce Stock V2 module will not make any assumptions about the stock, will not do any of the checking, inc/dec of stock or the storing of stock.
The current stock handling functionality will move into a sub module "simple stock" and it will be easy to create new sub modules, however i think it would be better to add decimal support for it if we can.
If you can get an example site or good instructions on how to set one up that has a decimal add to cart formatter it would help as I will need something to test it on.
The actual work on the “simple stock” module is going to be towards the end of the work as the framework needs to be in place first, so we got some time ( I am hoping to start work on V2 in the next two weeks if 1 is stable).

@videographics - i think i got you and that's why i set the issue back to open.
I opened the issue up so everyone can see it and hopefully someone with the need and some time can help out.

@guy: Has there been any progress on this? Our customer wants to sell curtains so I might have the time to work on a decimal submodule. Is it decided yet how the submodules will be able to hook into the 2.0 module?

For curtains we need the following functionality (summing up what's been said so far):
We need a decimal_stock field.

Its settings page:

• Unit (e.g. m). This will be attached after the display of commerce_price. Not required.
• Precision (e.g. 0.3) - the customer can buy only (smallest_quantity + n*Precision) quantity of the product (where n is a nonnegative integer). Not required.
• Smallest quantity (defaults to Precision). Not required.

Display:

• After the price attach the unit. E.g. $50/m
• Write a help text below the quantity field such as "You can buy only multiples of 0.3m."

As for the Limitation of Accuracy in #3 I don't think you can do anything about it but set the stock level by hand every now and then.

What else do we need?

I don't really understand rfay's suggestion in #1 saying "have a second field that said how much inventory this product accounts for, and have that default to 1." Is this about product bundles? Or can you give an example?

@czigor - while version two is not ready it has most of the functionality you probably need.
it uses rules to validate the add to cart and will soon use rules for determining the enabled/disabled of the add to cart form.
as far as a decimal sub module the situation is:
i am happy to try and get the main module out with decimal stock instead of an integer one as i think it can serve both cases.
what i really need is an example (copy or setup instructions) of a working site using decimal values to test this on.
as things are you can add your own field to a product and create stock checking rules with out the need for a special module.

I don't need any non-integer stock but I do see in the past with UC there were people who needed a weight-based stock. It might be simpler to design a frame of sorts were users can hook in with their specific stock needs.

As far as comment #10, it sounds like what I had to do once with UC Tax module. It was also designed to check for an integer and the hardcode in .module was set to something like >0. Since it was for a personal site and of a limited use case, I just changed what I needed to something like >-100. Changing the actual modules is bad practice so it definitely isn't a solution, but if you provide your own patch you can continue to apply the patch when you update the module (at least until the submodule is added.) If this is for a client you'll have to wait for a submodule since they won't know to continue applying the patch and it will break their functionality when they update the module.

@RKS see #14

Yeah, sometimes I don't read. Sorry to put my nose in.

I created a small contrib module which is supposed to make decimal quantities possible.

http://drupal.org/project/commerce_decimal_quantities

Bug reports are welcome!

@czigor, that's great ill check it out

this is now supported in version 2