Bad inventory keeping

[Brewhaus]

We just went through to update our inventory counts against our accounting (which uses a direct import of our orders, so the counts should match), and roughly half of the item counts are incorrect in AC. Some are over, others under. Has anyone else had issues with AC's inventory tracking?

[compunerdy]

/raises hand

Which is why I asked for a audit trail system so we could figure out the issue.

[AbleMods]

Create a SQL trigger on the ac_Products and ac_ProductVariants tables. You could monitor for any changes to instock field and log it to an extra SQL table for auditing.

[Robbie@FireFold]

Sounds like you could make that a project Joe. I'd be in! We need it badly.

[Brewhaus]

Okay, I am glad to know that I am not alone, but at the same time it is imperative to have it working correctly. We just oversold a one-time item as a result, and when we reduced the customer's order quantity it did not alter the in-stock count as it should.

[combra]

Okay, I am glad to know that I am not alone, but at the same time it is imperative to have it working correctly. We just oversold a one-time item as a result, and when we reduced the customer's order quantity it did not alter the in-stock count as it should.

How do you have your order statuses set up? (Configure>Order Statuses). You might want to check there. I've never had an inventory issue with AC.

-Brandon

[Brewhaus]

The only change that we made to the configuration out of the box was to Destock with a status of Order Printed.

[compunerdy]

I have every one set to destock and still run into issues somehow.

Joe..this would be a good module for you to offer. I know its easy for someone like you to do what you described but some of us arent as talented

[AbleMods]

Joe..this would be a good module for you to offer. I know its easy for someone like you to do what you described but some of us arent as talented

I was doing some thinking along those lines earlier this week. The wall I ran into is, when working with triggers, there's no way to tell WHERE the request came from that altered the field value.

I can tell you WHEN it was changed, but that's of little use in tracing down HOW it was changed. You need to know what module, what page or what store function caused the stock quantity to change. At this low level in the database, that's difficult if not impossible to tell.

Methinks my suggestion might not prove as useful as I thought

[Robbie@FireFold]

Wow what a downer! I really need the ability to see where/what was changed. Would make life at FireFold much better.