Product Variants and Inventory Control

[niall08]

Am I wrong in this..?

When a product variant choice has it's inventory "in stock" level set to 0, it is removed from the ac_ProductVariants table, and so doesn't appear in the Inventory Report under Manage > Inventory any more???

[mazhar]

No it system doesn't remove. Its listing it even in stock value is zero.

[niall08]

Mazhar,
This is weird.. some of my variants ARE still in the ac_ProductVariants table with stock level of 0 - while others, when edited through the product page, disappear from the table when their stock level is set to 0 - have you encountered that behaviour before?

I'll be honest - I am having a NIGHTMARE with this inventory control - yes, the client wants some bespoke additions, but I just can't seem to make any headway here..

And the bizarre behaviour of the disappearing variants isn't helping..

[mazhar]

What's your application version information?

[niall08]

The build is:

PLATFORM: ASP.NET
VERSION: 7.0.1
BUILD: 11667

AjaxControlToolkit: 1.0.10301.0
CommerceBuilder: 7.1.11235.0
CommerceBuilder.AbleCommerceTax: 7.1.11310.0
CommerceBuilder.AustraliaPost: 7.1.0.0
CommerceBuilder.AuthorizeNet: 7.0.9764.0
CommerceBuilder.CanadaPost: 7.0.0.0
CommerceBuilder.CCH: 7.0.0.0
CommerceBuilder.Configuration: 7.0.10576.0
CommerceBuilder.CyberSource: 7.0.9764.0
CommerceBuilder.DataClient.Api: 7.0.1.1
CommerceBuilder.DataClient.Csv: 7.0.34.0
CommerceBuilder.DHL: 7.1.11307.0
CommerceBuilder.DHLInternational: 7.1.11307.0
CommerceBuilder.ECB: 7.0.0.0
CommerceBuilder.FedEx: 7.0.9725.0
CommerceBuilder.FRBNY: 7.0.0.0
CommerceBuilder.GoogleCheckout: 7.0.10052.0
CommerceBuilder.InternetSecure: 7.0.9764.0
CommerceBuilder.LinkPoint: 7.0.9764.0
CommerceBuilder.Paradata: 7.0.9764.0
CommerceBuilder.PayFlowPro: 7.0.10061.0
CommerceBuilder.PayJunction: 7.0.9764.0
CommerceBuilder.PayPal: 7.1.10840.0
CommerceBuilder.Protx: 7.1.10124.0
CommerceBuilder.Services: 7.0.10576.0
CommerceBuilder.SkipJack: 7.0.9764.0
CommerceBuilder.UPS: 7.0.10041.0
CommerceBuilder.USPS: 7.0.9728.0
CommerceBuilder.Web: 7.0.10576.0
ComponentArt.Web.UI: 2007.1.1566.3
CyberSource.Base: 2.0.0.0
CyberSource.Clients: 5.0.2.0
CyberSource.Clients.XmlSerializers: 5.0.2.0
CyberSource.WSSecurity: 2.0.0.0
CybsWSSecurityIOP: 1.0.0.0
edtFTPnet: 1.2.4.0
FredCK.FCKeditorV2: 2.5.2912.21007
ICSharpCode.SharpZipLib: 0.85.5.452
LinkPointTransaction: 1.0.1797.29766
log4net: 1.2.10.0
Microsoft.Practices.EnterpriseLibrary.Common: 2.0.0.0
Microsoft.Practices.EnterpriseLibrary.Data: 2.0.0.0
Microsoft.Practices.ObjectBuilder: 1.0.51205.0
Microsoft.Web.Preview: 1.2.61025.0
NVelocity: 7.0.8530.0
PaygatewayNET: 3.0.0.0
paypal_base: 4.2.1.0
PFProCOMLib: 1.0.0.0
PFProdotNET: 0.0.0.0
RealAuth: 1.0.0.0
RealExGateway: 1.0.0.0
RealExTest: 1.0.0.0
Validators: 1.0.0.0
WebChart: 1.1.1.6
wwHoverPanel: 1.85.0.0

I've done some playing around - the product that was misbehaving had was not having the individual option SKUs stored in the ac_ProductVariants table - they had been entered as modifying the price of the product, but with the price set to £0.00 - this price was not being stored in the ac_ProductVariants table either.

When one of these variants had their stock level set to 0, the record for that option was being deleted from the ac_Products table.

I've removed the Sku Modifier through the "edit options" form, and edited the variant contents, adding the SKUs for the options there, and adding the product price to each of the option price fields.. And hey presto - I can now set the stock level to 0 without the record being deleted..

Yes, the client had entered the data - but is this the expected behaviour for the variant in the back-end?