ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Evo-ERP and DBA Classic >> Items >> IN-B collisions
http://www.istechforum.com/YaBB.pl?num=1248878684

Message started by GasGiant on 07/29/09 at 07:44:44

Title: IN-B collisions
Post by GasGiant on 07/29/09 at 07:44:44

Although we have been using DBA/Evo since 2003, we are just now growing to the point where we have multiple users attempting to add/edit Items at the same time. Here are some things we've noticed lately...

Purchasing is creating an Item as they write a PO, so Engineering can't save changes in IN-B.

Customer service is editing a Sales Order, so the Sys Admin gets errors while running IN-N-B to add Items to locations.

It is very hard to tell if users are trying to access the same record in these cases, but I suspect that, at least in the first case, they are not. Is there any chance we'll move to record locking instead of table locking for Item changes? Has this been done? Am I all wet? How can I avoid the problem?

Title: Re: IN-B collisions
Post by Dennis Wilkinson on 08/03/09 at 06:01:59

Collin, I most organizations I have worked with and consulted with, there is a primary person / function responsible for specific tasks. For example, the Engineering dept is typically the only group that adds, changes, modifies a part number and for a number of good reasons: a)correct item class (this is where the cost is assigned in most cases), b) maintain correct item number format (many parts have some intellegence/logic built in), c)proper catagory or user defined search fields, d) Proper drawing & ECN control, etc. Various people entering typically do not always follow consistancy and this creates problems that seem not to get fixed as volume increases.

This is also true with Vendor Codes and Customer Codes. Typically Accounting assigns Customer codes and Vendor codes because there are multiple needs within these codes (Proper ship to's, bill to's, atten: Accounts Payable, GL Accounts, Class codes, etc. Most Customer & Vendor codes serve dual purposes, both from Sales / Purchasing & Accounting.

By establishing a specific person or function to maintain certain records, you ensure better consistancy AND reduce the conflict of crashing into each other during the various entries. Typically, the volume of new parts, vendors, customers that are added each day is not so much that it requires many people to enter.

These are just my thoughts and experiences.

Dennis

Title: Re: IN-B collisions
Post by Dave Miller on 08/03/09 at 06:50:20

We have also assigned certain people to input certain critical data. Item entry is one, as any mistake or inconsistency can create sorting, lookups, and other problems. Consequently, we have not experienced the problem you are encountering.

Title: Re: IN-B collisions
Post by GasGiant on 08/03/09 at 10:43:02

We do have assigned roles, but there is now too much work and it is being split up. Non-stock items are added by the purchasing agent. Electrical and mechanical engineering split the duties of caring for stock items. Then there is a production support person who works with the MRP info and locations. It is no longer practical to have one person doing all IN-B work. The more we have moved toward lean mfg, the more important it will be to have this work dispersed. The data entry and maintenance is being placed into the most competent hands in each case.

That is all the defense of our methods in which I will indulge. My questions remain.

Title: Re: IN-B collisions
Post by cathyh on 08/03/09 at 11:59:06

We have also split the IN-B duties between our Purchasing/Inventory manager who enters all purchased parts, both inventoried and non-inventoried, and our employee in Product Development department, who enters all the manufactured parts that require among other things drawing and rev information.
We have not seen any conflicts- but we are not entering parts all that often either.

Title: Re: IN-B collisions
Post by lburns on 08/04/09 at 07:50:53

Collin,

I am with you here - we have grown and have multiple people responsible for data in each area. We see it in IN-B, PO-A, SO-A etc. Not to mention the accounting side...could it be that we are or have outgrown DBA/EVO once we have gotten to a point where more than one person may need to be assigned to entering information within specific menus?

Laurie

Title: Re: IN-B collisions
Post by Lynn_Pantic on 08/04/09 at 08:07:54

If multiple people are using IN-B at the same time to create part numbers but are not simultaneously trying to create or edit the SAME part number, there should be no conflict. Same thing with other files such as Sales and Purchase orders. The programs lock the records (individual parts or orders) not the files.

Title: Re: IN-B collisions
Post by GasGiant on 08/04/09 at 08:12:12

Compared to the way SO-A used to be, big improvements have been made. Now we only have problems if two people are trying to work with the same SO at the same time. We've seen one PO-A issue with two people getting the same PO number at the same time, but I think a fix is in the works for that. However, with IN-B I don't think that collisions have ever been addressed. I may be wrong.

As for outgrowing the software, we have evaluated that. We weighed the value of improvements against the cost of moving up to something like SAP Business One, and so far we have found that the $250,000 cost, coupled with the disruption to our business, is no where near the worth it for the potential benefits... yet.

We have instead preferred putting time, effort, and money into improving our processes and adding a custom web interface (like Evo2Web) to help with "business intelligence" and "data mining" tasks. Forming the tool to our use is much better than attempting to mold our process to fit the restrictions of the tool. :-)

Title: Re: IN-B collisions
Post by GasGiant on 08/04/09 at 08:15:32

Lynn_Pantic wrote:

That has not been our experience. We get locks in BKICMSTR/MTICMSTR when we try to save IN-B if another user has saved anything in IN-B and left the window open. And no, the item numbers are not the same.

Title: Re: IN-B collisions
Post by lburns on 08/04/09 at 09:01:36

Collin and Lynn -

This has been our experience as well. If anyone is in IN-B and someone else wants to go into IN-B (different part numbers) we get a lock message and have to wait or go hunt down the user who has it open...

Laurie

Title: Re: IN-B collisions
Post by Lynn_Pantic on 08/04/09 at 15:01:21

I just duplicated a lock on BKQTTEMP but not MTICMSTR/BKICMSTR. We are looking into it.

Title: Re: IN-B collisions
Post by Lynn_Pantic on 08/05/09 at 08:30:16

We did duplicate and fix some issues in T7INB, specifically record locks remaining when a user has saved a part and is sitting on a blank IN-B screen and another user tries to save a different part. I have an updated file available. The 5/25/09 update is required.

Laurie, we have made a lot of record locking improvements since the version you are on but you need to install the updates to take advantage of the fixes.

Title: Re: IN-B collisions
Post by lburns on 08/11/09 at 05:52:31

Lynn,

I realize there have been many improvements since the version we are on however the GM here will not allow another update to be loaded due to the problems we have had and the bugs that have presented themselves post past updates so I am left making the best with what I have...

Laurie