I found out this bug when a customer bought an item on the site.

I have a number of items that have many attributes and each sub-item has a unique SKU. My issue is that when a customer buys a sub-item, it is the stock of the main SKU, not the sub-item's SKU, that gets reduced. Although the correct item and Attributes are shown in the invoice, the wrong SKUs are listed for the items - the invoice always lists the default SKU as the sub-items SKUs. This of course results in wrong stock levels and possible delivery errors.

Comments

kyutums’s picture

kyutums CreditAttribution: kyutums commented

For example,

Default SKU: CSR001
Other SKUs:
50ml	CSR001
100ml	CSR002

If the customer buys the 100ml item (CSR002), the SKU that gets reduced in terms of stock is CSR001, not CSR002. I always thought that if the user chose the 100ml option, it is the stock of CSR002 that will be reduced.

kyutums’s picture

kyutums CreditAttribution: kyutums commented
Priority: Critical » Normal

Additional info: The invoice also shows the wrong SKU - only the default SKU is listed, not the sub-item's SKU.

rszrama’s picture

rszrama CreditAttribution: rszrama commented

fwiw, this definitely looks like a bug. Thanks for the report. : )

kyutums’s picture

kyutums CreditAttribution: kyutums commented

Found a workaround. :)

For the default SKU, use an SKU that is not in the normal SKUs. For example, my previous default was CSR001, and my resulting stock SKUs are CSR001 and CSR002. I just changed my default SKU to CSR001default, and kept my stock SKUs as is.

Now, the stocks are being reduced for the correct SKUs. :)

kyutums’s picture

kyutums CreditAttribution: kyutums commented

Anyone know if this is fixed in RC6?

TR’s picture

TR CreditAttribution: TR commented
Status: Active » Closed (duplicate)

Although they're newer, I'm going to mark this as a duplicate of #717408: Option SKUs not displayed in saved order and not used in stock tracking and #734050: Alternate Skus not displaying in saved order because those threads have discussions and solutions. To summarize, it's your configuration (as you found out in #4). Preventing this from happening would be nice, but requires an architectural change to make SKUs unique that's not going to happen in Ubercart 2.x. Hopefully we'll be able to re-engineer this for Ubercart 3.x.