| Author |
 Topic  |
|
Barney Stone
Administrator
USA
6269 Posts |
 Posted - 07/08/2009 : 08:21:24 AM
|
Sean -
That feature has been in the program since version 5.8. See the system parameter LogMultiRecordEditorChanges. |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
 |
|
|
chris@fbl.bz
New Member
USA
6 Posts |
Posted - 10/26/2009 : 1:29:11 PM
|
Hello,
I agree that this is a huge problem and should be a big priority along with multi box shipments.
If there is an order error, sometimes inventory will go out of sync. There is no record of this. If you run all the separate reports, you will still never figure it out.
In MOM, there was a simple report that showed all inventory transactions whether it was a manual adjustment, a sale, receipt of a PO or a return. It would label which type of transaction each was. It would show the adjustment amount, and then the new balance. So if something got screwed up, you would be able to see that the balance was incorrect somewhere and figure out where the mistake was.
I don't remember there being any inventory disappearing with MOM, but if it did, you would be able to figure out where it went wrong since the inventory balance would help you track where it went wrong.
This is needed for any company that tracks a lot of inventory. Things are bound to go wrong and there is no other way to figure this out without spending hours and days on it. |
|
|
|
mckane
Member
205 Posts |
Posted - 10/30/2009 : 5:27:13 PM
|
chris ,
This is still definitely a problem plaguing Stoneedge. We do an inventory count every quarter and get all of them in-synch and then we run SEOM for 3 months and 10-15% of items are out of whack. No run-time errors or known issues for us. The build we have is stable, however, something within SE is misfiring and not adding or deducting values correctly.
We have to do a complete inventory count every quarter because of this issue - things just get so out of whack.
For a while we thought we were just crazy... but we pick and pack by barcode and our error rates on packages are below .2%. We do everything by barcode, and as we've gotten more efficient and effective and precise in our handling of inventory, the out-of-whack-ness of QOH has continued to be a problem. We have video cameras in the warehouse to prevent shrinkage. We're really quite certain SE is misfiring.
Our warehouse manager will sporadically find issues and come to me. She'll say "I swear to you that I removed 3 of these from inventory yesterday and they are right back in stock". That's happened quite a few times. She will SWEAR to me that she did it and that the next day, it's off again. So I had her start logging on a piece of paper whenever she made manual changes to items. Sure enough, every once in a while she would have a note on her paper of a change she made, and yet the inventory values in the QOH would not reflect the change. Attmepts to recreate are not successful, but she has the note, and a record of attempting to make the change.
The first critical step would be for SE to have a record of EVERY transaction with the QOH in the Inventory Table. That's critical. We need to be able to see the user and the application that made the change, and the order or PO that is corresponds to. Otherwise, this issue is a needle in a haystack. Everything needs to be logged. There's so much going on, with downloads and revisions to orders, and over 20,000 SKUs that it is nearly impossible to debug this and find where SE is misfiring. I've long suspected it's on the order import process and when you manually modify the QOH of an item.... then again, there could be problems elsewhere.
barney and kevin - is this still slated to address in early 2010?? We are anxious for a cure, for sure. At the very least, it would be nice to get a log of every change and some tranparency into that, with a time stamp, and the order that the change corresponds to, the application that made the change, and the employee that made the change. |
Edited by - mckane on 10/30/2009 5:28:14 PM |
|
|
|
mckane
Member
205 Posts |
Posted - 11/12/2009 : 2:51:05 PM
|
Hmmm... any update on this?
We did an inventory count of the entire warehouse late last week. Over 15% of items were off and nearly all of them were off in the same way: Stoneedge said we had more in stock that were really actually on the shelf. Thousands of items. Most were just off by 2 or 3.
Today we got a
""ODBC - update on a linked table 'Inventory' failed."
Several times during a download.
I believe that there is a problem with the download/import processing of orders where it does not reduce inventory from the inventory table when it should. I believe it is sporadic.
Are there any plans to address this? Or to log all changes to the inventory table for later audit?
We'd really really really love to get to the bottom of this once and for all.
|
|
|
|
Barney Stone
Administrator
USA
6269 Posts |
Posted - 11/12/2009 : 5:35:54 PM
|
Yes, McKane, we are working on major improvements to the whole order import process. They are nearing completion now, and should be in Beta testing by year end.
And yes, we will be adding more change tracking to the inventory system, although most of our users are not having anywhere near the problems you have. |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
|
|
|
mckane
Member
205 Posts |
Posted - 11/12/2009 : 5:47:08 PM
|
That's great news.
The order importer will be a big step.
The inventory revamp as well (especially with some tracking/auditing).
Thanks for the info. I'll keep eyes open for the new order importer.
|
|
|
|
mckane
Member
205 Posts |
Posted - 11/13/2009 : 02:25:41 AM
|
Out of curiosity - the rest of you who are experiencing issues, what versions are you running...
US: SE 5.607
SQL Server 2000
Windows Small Business Server 2003
Based on Barney's recommendation, we'll be upgrading to SQL Server 2008 and to a more recent version of the SE Order Manager as well. |
|
|
|
chrisjohnson
Member
USA
177 Posts |
Posted - 11/13/2009 : 08:08:31 AM
|
quote:
[i]Originally posted by mckane[/i]
[br]Out of curiosity - the rest of you who are experiencing issues, what versions are you running...
US: SE 5.607
SQL Server 2000
Windows Small Business Server 2003
Based on Barney's recommendation, we'll be upgrading to SQL Server 2008 and to a more recent version of the SE Order Manager as well.
We use:
Enterprise 5.612 (however we will be upgrading to the 5.9 series soon - probably the next version)
Access 2003
Our SEOM program runs on Server 2003 Terminal server and two WinXP desktops
SQL Express 2005 on Server 2003
We also have had unexplained inventory issues. For example, we had an issue recently where we had received 36 items into inventory (prior to this we had 0), had orders for 36 items in a 3 week period, however SEOM had our count at 3. A physical count proved we had 0. There have been a number of these unexplainable inventory counts being out of sync on multiple products. |
|
|
|
Barney Stone
Administrator
USA
6269 Posts |
Posted - 11/13/2009 : 10:01:38 AM
|
quote:
[i]Originally posted by mckane[/i]
[br]Out of curiosity - the rest of you who are experiencing issues, what versions are you running...
US: SE 5.607
SQL Server 2000
Windows Small Business Server 2003
Based on Barney's recommendation, we'll be upgrading to SQL Server 2008 and to a more recent version of the SE Order Manager as well.
We do not recommend using SQL Server 2000. Our Enterprise users have found that SQL Server 2005 and 2008 work much better. We are also not crazy about Small Business Server. Depending on which features you use (Exchange, SQL Server, etc.), it can overload the computer it is running on. It's OK for smaller companies, but higher volume users should run SQL Server on its own dedicated server. |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
|
|
|
chris@fbl.bz
New Member
USA
6 Posts |
Posted - 11/13/2009 : 1:20:32 PM
|
quote:
[i]Originally posted by mckane[/i]
[br]Out of curiosity - the rest of you who are experiencing issues, what versions are you running...
US: SE 5.607
SQL Server 2000
Windows Small Business Server 2003
Based on Barney's recommendation, we'll be upgrading to SQL Server 2008 and to a more recent version of the SE Order Manager as well.
I am using SQL Server 2005 on its own machine and running OM 5.612 |
|
|
|
mckane
Member
205 Posts |
Posted - 11/13/2009 : 1:53:55 PM
|
| We are using windows small business server, but we don't use it for anything but Stoneedge SQL. No exchange, not a DNS server, etc. So for all intents and purposes, it's running as a standalone. |
|
|
|
Erik-RMC
New Member
17 Posts |
Posted - 11/17/2009 : 12:46:55 PM
|
We are having basically the same issues as Mckane still. We do constant inventory and have to adjust items all the time. It seems to always say we have more than we actually do. I think it could be tied to the PO receiving part of things. We had one large PO from one manufacturer where it double received about half the PO. I had to go in myself and fix all the inventory on those SKU's. It then would revert back to the wrong count a few days later mysteriously so I would change it again. Other than the inventory issues which are a pretty major problem we are fairly happy with Stone Edge overall. We switched from MOM about a year ago and never had these inventory issues with them. If we did get off a little I could go back and see the log of changes and see where the problem was which was usually user error. I don't think this is user error but with no log of changes to inventory there is no way to tell as others have already stated.
If there are plans to fix this please let me know. We are in the Beta program but haven't updated since February because quite frankly we are happy with the version we are using for the most part. |
|
|
|
markgrigsby
New Member
USA
10 Posts |
Posted - 11/20/2009 : 10:21:56 PM
|
| We have been live on SEOM for only a few months, but our inventory is already messed up. We run a very tight ship and keep inventory levels very close to what we know we need, so we need an inventory management system to do its job. We have 0 shrinkage because we have no employees. If we knew inventory would get so messed up in SEOM, we wouldn't have bought it in the first place. |
|
|
|
mckane
Member
205 Posts |
Posted - 11/21/2009 : 03:00:00 AM
|
More info from me:
Server Info:
Small Business Server 2003
SQL 2000
Workstations: Access 2003
Stoneedge Version: Enterprise 5.607 (No consistent run-time errors. Seems stable.)
Use Stoneedge to create purchase orders and to receive inventory?: Yes
Shopping Cart: Yahoo (and we use the option to send the order to SE and then download it from SE)
I think it could be really helpful to look at what import you are using to get orders in. As mentioned above, we use the Yahoo SE importer.
Anything else I'm missing that might be important to check for consistency?
This is a battle we've fought with the SE software for quite some time and I'm relieved to see that we aren't the only ones experiencing significant inventory problems. Let's keep the dialog open and see if we can't at least find a common identifier among all of us. |
Edited by - mckane on 11/21/2009 03:09:54 AM |
|
|
|
mckane
Member
205 Posts |
Posted - 11/21/2009 : 03:08:58 AM
|
chrisjohnson -
This is EXACTLY the same issue we're seeing as well. We just received 24 of an item last week. We sold all 24, but stoneedge had our inventory count at 2. We looked back at it and we had indeed sold 24, but for some reason SE didn't remove 2 of them from inventory. It's impossible to track down why or where stoneedge didn't remove the items. In our case we actually ended up selling 26 of them (becuase SE said we had 2 left to sell) and then 2 customers had to be called and refunded etc. It's terrible for the customers and it's a battle we fight regularly.
We've got to get to the bottom of it. |
Edited by - mckane on 11/21/2009 03:10:04 AM |
|
|
|
Jared
Advanced Member
USA
1560 Posts |
Posted - 11/21/2009 : 03:16:14 AM
|
| Although I realize this is not a solution to the issue at all, Mckane, but have you looked at adding a trigger in SQL for changes to your Inventory QOH? This has helped us track down numerous inventory problems (some caused internally, some by StoneEdge) - at a minimum, it allows us to see exactly what went wrong and know we aren't just going crazy :) |
Jared |
|
|
|
mckane
Member
205 Posts |
Posted - 11/21/2009 : 03:40:45 AM
|
quote:
[i]Originally posted by Jared[/i]
[br]Although I realize this is not a solution to the issue at all, Mckane, but have you looked at adding a trigger in SQL for changes to your Inventory QOH? This has helped us track down numerous inventory problems (some caused internally, some by StoneEdge) - at a minimum, it allows us to see exactly what went wrong and know we aren't just going crazy :)
Jared -
Do you have that code or instructions for a trigger we could set up? I'm assuming you mean a trigger with a log of everything that's done to that table/column in stoneedge. I don't personally know how to set up triggers in SQL so any help you could send would be really helpful. I think a trigger in SQL is a good idea... but I'd think it would need to identify what program/user/machine reduced inventory.
Also, keep in mind, that the issue we are talking about here is that stoneedge is not reducing inventory when it should be reducing it. Presumably, it's never hitting the database to remove it or it's erroring out. I don't know if a trigger is going to give us any good info on this.
Stoneedge could really use an inventory log.. so that any time the program attempts to modify inventory, it writes to a log and stores the sku changes, the qty difference, the user, the machine, and the order (or purchase order) associated with the change. If there's a way to do that with a trigger, that would be marvelous! I have long suspected that the order importer is to blame and that it marks inventory as "shipped" without removing it from inventory sometimes. That's just my hypothesis based off of antecdotal info.
Anything you've got (with any trigger) would be better than operating in the dark like we are now, though. Let me know. Thanks!
|
|
|
|
Jared
Advanced Member
USA
1560 Posts |
Posted - 11/21/2009 : 04:05:41 AM
|
Tim gives pretty good instructions for setting up the trigger here:
http://www.stoneedge.net/forum/topic.asp?TOPIC_ID=5586
Just need to create the table and install the trigger - this adds a table write on every inventory change, but we haven't noticed any performance problems from it at all. You'll get everything you asked for above except for the related order number... if you combine that with the inventory report (or your own custom report) here:
http://www.stoneedge.net/forum/topic.asp?TOPIC_ID=4101
And match up events by the exact timestamp (the notes table helps with this too), we've been able to track down all of the problems we've had... again, I agree - a built in inventory log will give us all more information and allow us to better track problems, but any additional information we can provide to StoneEdge will help them address these inventory issues, so these additional tracking steps might help us all track down sporatic bugs :) |
Jared |
|
|
|
Barney Stone
Administrator
USA
6269 Posts |
Posted - 11/23/2009 : 4:19:52 PM
|
| We had a developer's meeting about these issues this morning. We are going to start working on a logging system, but it will not be available for at least 2-3 months because it will have to go into the forthcoming 6.x series. In the meantime, we would like to spend some time analyzing some of your data files so we can try to figure out what is happening. We will need a copy of your data file, a list of a few SKUs that have had QOH issues, and approximately what range of dates were involved. We will also have to know what version(s) of the Order Manager were involved, and whether you use any custom code, either within or outside of the Order Manager, that might affect your inventory. If you are interested in working with us on this, please contact Kevin Smith, kevin at stoneedge.com. |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
|
|
|
mckane
Member
205 Posts |
Posted - 11/24/2009 : 03:39:26 AM
|
We'd be willing to help with this. I'm encouraged that you'll be looking at it and building the tracking into SE.
The inventory tracking and then auditing will really help with transparency withing the system. It will be much easier to track down bugs or issues when we can see the history of a sku (and then compare it to the actual POs and Orders and quickly find discrepancies).
|
|
|
|
Erik-RMC
New Member
17 Posts |
Posted - 11/24/2009 : 1:06:56 PM
|
I'd love to help but as a retailer we are going into the busiest time of the year so going might be slow.
|
|
|
|
Chuck Griffith
Member
218 Posts |
Posted - 11/24/2009 : 1:36:14 PM
|
Here is a query that I wrote to list all recorded inventory transactions. It can help find some human errors but it can't find any computer errors. One reason for not detecting computer errors is that it doesn't have beginning-of-the-year inventory balance from which to start counting from. It just has to assume zero so any final totals are only valid for products sold entirely within the years on the database. This next calendar year I will roll totals into a spare inventory field and count from there. Frankly though, I would bet money that most errors are human errors and most of those occur during receiving. I've instituted some receiving forms that have helped reduce that but they are burdensome and probably brushed off occasionally.
SELECT [Order Details].SKU AS LocalSKU, iif(isnull([Order Details].DateShipped),Date(),[Order Details].DateShipped) AS [Date], [Order Details].OrderNumber, -[Order Details].QuantityShipped AS Quantity, [Order Details].Status AS Type FROM [Order Details] WHERE ((([Order Details].Adjustment)=False) AND (([Order Details].DropShip)=False) AND (([Order Details].QuantityShipped)>0)) Union SELECT POHistory.LocalSKU, POHistory.Date, POHistory.PONumber AS OrderNumber, POHistory.Quantity, "Received" as Type FROM POHistory WHERE (((POHistory.Type)="R"))
UNION SELECT InventoryAdjustments.SKU AS LocalSKU, InventoryAdjustments.Date, 0 AS OrderNumber, InventoryAdjustments.Change AS Quantity, InventoryAdjustments.Reason AS Type FROM InventoryAdjustments
UNION SELECT Returns.SKU AS LocalSKU, Returns.Date, Returns.OrderNumber, Returns.AddedToQOH AS Quantity, "Return" AS type FROM Returns WHERE (((Returns.AddedToQOH)>0));
If there is a new inventory audit trail, one thing it won't detect is a *missing* adjustment. Not much you can do about that.
What about "unit of work" and transaction rollback? I've mentioned this before but never got a reaction about whether it is used or maybe if it can't be used for some reason. Using this could help eliminate missing adjustments although I wouldn't want to bet my retirement funds on how easy it would be to implement.
I would be glad to turn over our data files for examination at any time. Since one can't predict where something is going wrong, I would think both a before and after data picture would really be needed. I would be glad to do a weekly archive so that any range of info can be accessed. Is there an export-to-SE function for the enterprise version?
|
|
|
|
kevin
Administrator
USA
2668 Posts |
Posted - 11/24/2009 : 2:09:44 PM
|
There is not an export for Enterprise, however, a full db backup would be sufficient. By having a starting point (before) and a result (after) I should be able to identify the bulk of the adjustment actions between the two. By reviewing receiving, sales and manual adjustments and the system's error log, I may be able to identify a pattern.
My review of the data will not require any time on your part other than to generate the backups. I will do the review in our office so your business processes are not impacted. A week between the db snapshots should be sufficient. If you are a high volume merchant, a couple of days may be good - less data to review. |
Kevin Smith
Stone Edge Technologies, Inc.
920 Germantown Pike
Suite 112
Plymouth Meeting, PA 19462
610-994-3699 x112
kevin at stoneedge dot com |
|
|
|
ChicagoTS
New Member
USA
42 Posts |
Posted - 11/25/2009 : 09:58:08 AM
|
My client is running 5.612 and have had numerous issues with inventory being "off". They are pushing me to find a new solution but I'm onsite today to upgrade them to 5.9 in the hopes that it will address some of their other issues. The lack of an audit trail for inventory is a huge issue for me/them and I might be able to get you some of the data. They have 5000+ products and add hundreds weekly so it can get messy.
I'm assuming 6.0 will have some associated upgrade cost to it Barney? Getting this feature might be worth that cost but I'll have a hard time convincing my client when they see this inventory issue as a bug...
|
______________________
CTS
Dean Brady
|
|
|
|
Barney Stone
Administrator
USA
6269 Posts |
Posted - 11/25/2009 : 11:14:01 AM
|
Dean -
We are giving this issue top priority. Kevin is our top programmer, and he is studying data from a couple of users now. It's a time-consuming process, but hopefully he will find something in the next day or so. In the meantime, there have been many changes since 5.612, so hopefully going to the latest release will solve some of your client's issues.
If you can provide us with a backup file from date A and another from a later date B, and a list of a few SKUs that had their quantity go off during that time period, please contact Kevin about getting the files to him.
Updates are included in our annual support contracts. If your client has a current support contract when version 6 is released, there is no other cost for the update. |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
|
|
|
Topic |
|
Inventory count
