ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Evo-ERP and DBA Classic >> Manufacturing >> Material issues
http://www.istechforum.com/YaBB.pl?num=1054229648

Message started by tcook on 05/29/03 at 11:34:08

Title: Material issues
Post by tcook on 05/29/03 at 11:34:08

When entering finished production and issuing materials, sometimes a record will lock and the transaction appears that it did not complete, because the finished production does not show on hand.  If you run transaction reports on the components, it issues the material up to the record that was locked.  It took many tries at this before this was figured out.  So the person issuing material would just keep trying every so often not knowing that every time part of the  BOM was being issued, causing our inventory records to be off.  Has anyone else had this problem?  It seems like if it could not complete the transaction,  it should not save it.  We have some BOM's with 200 parts,   it is very time consuming to check the materials when this happens!

Tara Cook
APA, Inc.

Title: Re: Material issues
Post by aricon on 05/29/03 at 14:19:04

Tara,

I have a client that this happens to on a semi0regular basis and it frustrates the hell out of them.  However, there is really not much that can be doner due to the base structure of DBA and the fact that it uses Pervasive as strictly a transactional manager and not a relational.

Title: Re: Material issues
Post by Lynn_Pantic on 05/29/03 at 15:15:45

Actually, there might be some things that could be done to at least minimize the problem.  One possibility would be that whenever a component inventory master record was locked, store the transaction info in a temporary file and move on rather than stop and abort the process.  Then the work order could be processed and costed correctly and the temporary file posted at a later time to update the inventory.  There are drawbacks to this approach but perhaps less than the current logic.  I will look into it further.

Title: Re: Material issues
Post by aricon on 05/29/03 at 16:32:18

One major concern I see with that is: what if there is a system lock-up either on the client system or the server or a power-failure or other interruption of processing?

The data held in the array would be gone and this could mean significant hard-to-recreate data entry.

OR, you start to create a BUNCH of new structures to store the data in as temp tables and then append to the existing tables which would then become Master tables.

Neither option is super-pretty.... :-[

Title: Re: Material issues
Post by Lynn_Pantic on 06/05/03 at 13:50:26

OK, how does this sound?  There is already a file named WOEMAT which is a parallel file to the WOMAT work order material transaction file and is used for the import program.  We could use that file here as well.  

As the components are processed, either in WO-G Kit/List issue or WO-I Backflush, before a given component is processed, all the necessary records in the various files will be locked.  If they can be, the component processes.  If not, the component is not processed and the information is stored in WOEMAT for later processing.  Move on to the next component.

The cost from the incomplete transaction will be posted to the WORKORD file so the Finished production is fully costed.  The Close Work Order capability in WO-I and WO-J will check for unposted material and prevent closing the work order if material hasn't been fully posted.  I think this already happens to prevent closing a work order with unposted imported material transactions.

At the end of the day, somebody in production or inventory control would run a posting routine that posts all the WOEMAT records and clears the file.  See any gaping holes in the logic?  Only one I can think of is Lot/Serial control - we would need to determine when that posting would occur - at the original attempt or the end-of-day cleanup posting.  But for people who do not use lot or serial control, I think it is pretty straightforward.

Title: Re: Material issues
Post by aricon on 06/05/03 at 16:12:11

Here's a wild idea...

Take this to the full conclusion - create a set of duplicate structures for the entire set of DB's.  That would reduce the locking problem in almost every program to near zero.

It would also have another benefit - open ability to import to any file.  Something that DBA is sorely lacking.

Obviously for the second benefit to be fully available it would also be neccessary to create an import mapping table.

This might also have a 3rd possible usage - for archiving.  Instead of a direct export from a live file, for archiving you could archive to these files and have them situated on another drive, or even another server in the network.  This could significantly enhance the speed and reliability of the "live" and current data.

ISTech Support Forum » Powered by YaBB 2.1!
YaBB © 2000-2005. All Rights Reserved.