× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Bogus Location Transactions
  • From: MacWheel99@xxxxxxx
  • Date: Fri, 2 Jun 2000 04:24:08 EDT

> From: Dick_Bailey@MCFA.COM (Bailey, Dick)

>   Al:
>  
>  I'm glad you figured out your problem - because we haven't seen creation of
>  extra bogus transactions.

Well we thought we had figured it out, but it seems no theory survives more 
than a few hours.  About 4 different people, myself included, have come up 
with theories that seemed to match the data, then we did some data mining to 
try to definitively prove it one way or the other, and do test environment 
replication, only to find out the theory did not wash.

The latest theory about negative transactions was because of this pattern ... 
all of the hits had negative reject transactions associated with them, but it 
turned out that the negative rejects were just more of the bogus transactions 
- one per incident - a symptom not a cause.

Jerry was looking at audit trails & noticed that for every one of the hits he 
looked at, BPCS was acting like it thought that input was under lot control 
... now where would it get that idea ... we ran checks ... 100% item masters 
are NOT lot control ... 100% shop orders are NOT lot control ... 100% 
transactions are NOT lot control ... we have a few other files still to check.

We had been running queries of FLT labor tickets based on ticket # input 
sequence & ITH inventory history based on time the transaction was posted, 
complicated of course by some transactions back dated a day or two.  This was 
shooting down most of our theories.  Of course we are assuming this data is 
reliable.  I have seen some programs get the time from the initialization 
subroutine then run for many hours with the same time.

We now have 30 or 40 valid transactions identified each of which are linked 
to 2-3 other bogus unwanted transactions on bogus invalid locations.

I have been looking at the source code without success to identify some flaw 
in the logic that would explain this.
Negative quantities accepted by SFC600 but not JIT600.
Quite a lot of testing is for fields zero or not zero, but I do not see much 
for negative like negative hours.

We did a physical inventory only a month ago in the facility whose inventory 
got trashed by all this & I suggested we look at the items in the variances 
there to see if there seemed to be any correlation.  Discussion of my 
suggestion illuminated another issue I was not aware of - that facility that 
just had its physical is already having lots of problems with running out of 
some material & having very excess other material, not counting the garbage 
from the last 2 days.

I said that I can think of 3 possible explanations for this.

1. Software bug that was never a serious problem before, but as we move to 
leaner manufacturing operations, it becomes more critical.  Software bug(s) 
as yet unidentified.

There was a question about what was magic about May 31 that would cause a 
software bug to suddenly cause us this much trouble & I pointed out that due 
to our enhanced focus on standard-actual discrepancy analysis, a new degree 
of checking transactions just started & it was that process that found this 
problem ,,, it could have been going on all along with us oblivious to it.  
That angle is also being looked into.

2. The usual suspects ... we're doing some stuff wrong & have not really 
identified what we are doing wrong, with misreporting, not properly posting 
all labor, engineering changes that did not go through correct channels so 
stuff out of sync, humans have errors & not report them, just struggle to do 
best they can.

3. Physical inventory is responsible for corrupt inventory.  
This is perhaps the least popular of my speculations.

You figure people doing labor & inventory reporting every day probably know 
that job pretty good & their error rate is some tiny fraction of 1%, but when 
we do physical inventory some place only once a year, that is unfamiliar 
territory & errors in the process are probably several percentage points.

For example, in past years we have purged 100% shop orders for a facility to 
be inventoried so there are zero open over the thresh hold, on the theory 
that we avoid complications of inventory not yet back flushed to shop orders 
open during physical & inventory tied up in shop orders open for which there 
is no real WIP, but this year they told me that there was no WIP so this was 
not a problem & at the same time there was no need to purge the shop orders 
open on that facility, which to me is a contradiction in terms, but other 
people were calling the shots on that decision.

So I also have a suggestion to see if the items with the very bad inventory 
happen to coincide with items either consumed by or produced by shop orders 
open during the physical for supposedly no WIP.

Al Macintyre  ©¿©
http://www.cen-elec.com MIS Manager Programmer & Computer Janitor
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.