× 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.



In your talk of INV500, does that mean that you are not tracking the labor at all?

It sounds to me like your sequence of reporting might be different from us.
We do the work, and BPCS is updated to reflect what happened, so there is always a slight lag in our accuracy of shop orders and inventory.
Your way seems excessively cumbersome to me, but then you might think that of ours.


We have several scrap / reject inventory transaction / scenarios.

There is the case when we make something and it is no good and needs to go in the garbage so to speak. There is a transaction to consume the raw materials that went into this waste.
There is the case when we discover some discrete quantity is no good ... we can adjust it out of existence, using a reason code to track how come.
There is the case when we find a problem but it can be repaired. Depending on how long this will take, we can do adjusting entries (with reason codes) to the raw materials needed, without using any shop order # for this, or we can issue a temporary item # with letter R on end meaning REPAIR which will consume the quantity of the regular item that needs repair, and whatever other raw materials needed, and there is a separate shop order just for this, then the item-R is used as a substitution for some of the next parent level.


The structure of ITE file makes it practical for us to add additional transactions that are not pre-supplied by BPCS. But there are some scenarios where a simple transaction don't cut it.

With INV355 you can review what transactions already exist where you can do inventory adjustments against shop orders, to back out what got posted.
Like if you issued 100 from your warehouse 01 and later discovered that 10 of that is defective, you could then do a negative issue transaction (I with a minus sign for example), to take away what should never have been issued.
How often does this happen?
For us, the discovery that some component is defective at WIP time (if should have been caught when entering the building) it is so rare as not to justify any special modification to combine transactional steps.


Discovering we have issued defective materials to a shop order would never happen for us, because we only issue to a shop order what it consumed.
If our people find that 10 of the raw materials cannot be used, that means they cannot make the part that the 10 is to go into, until the defective materials are replaced.
If the raw materials defective and our people not know it, they just used it to make a parent part which is defective ... too late to extract the defective components.


Some of our components are the same material but need to be wound on reels one way or the other, so we use an item # depending on which way it wound. Due to machines that are not ambidextrous, we sometimes have to rewind, meaning one transaction to lower one item # quantity and another transaction to raise another by same quantity. I guess a program could be written that has access to the matching item #s, where someone keys in one of the pair, the other pops up on screen, you enter quantity of reel that got rewound, and less keying needed.

Sounds to me like you may need something similar, if your volume of this scenario justifies it.

We are 405 CD and we do NOT issue shop orders from our raw material stock warehouse.

Our number system is facility
20 30 40 50 containing warehouses whose last digit is the item type normally there
21 31 41 51 warehouses for finished goods type 1 ready to ship out to customers
22 32 42 52 warehouses for WIP item type 2 mainly
27 37 47 57 warehouses for raw materials item type 7
29 39 49 59 warehouses for problem parts needing QC inspection to decide what to do ... scrap, rejects, defective, RMA MRA, need repairs, etc.


Raw material arrives in stock room x7 from purchase order receipts, DRP, and transfers from other facilities. It is transferred to WIP as needed for production, based on the needs associated with a particular shop packet. We also do some kits where a package of raw materials needed for some operation go from stock room to WIP just before the start of some production.

Problem parts arrive in QC warehouse x9 as result of human being discovering problem and transferring it there for QC to decide what to do about it. Customer Returns for Quality reasons also go there.

Using your example ... we are trying to make quantity 100, and have a problem with 10
Now the shop packet going with the 90 that's good includes a notation about the 10 with problem, so the people at the next step know that one way or the other the 10 going to follow.


QC decides whether or not the 10 can be fixed, and how to fix them.
If the 10 can be repaired, they rejoin the other 90 and no further action needed.
In fact, the 10 being repaired might never show up on BPCS transactions or inventory, depending on how fast it is fixed & all BPCS knows is that 10 got done later than 90, and used excessive labor hours.


If the 10 have to be scrapped, then the shop order quantity is increased to 110 because we going to take care of the problem right away, by making 10 more to fill in the hole left by the 10 problem. Our reporting now shows that 90 was made, 10 scrapped, with 10 left to make.

In other words, we usually discover on shop floor pretty fast that there is a problem with an item, and we do something about it, and the paperwork follows the resulting decision and action.

If something got made that was defective, and the people not see that right away, the paperwork has already gone into BPCS claiming that it was made correctly. Since our QC warehouses are non-netable, the fact that we moved the inventory with INV510 (transaction T) means that the on-hand of good stuff has been reduced, and the MRP is calling for us to replenish the stock.

The original shop order that made the defective parts, if not caught at the time with scrap reporting ... we have no interest in tracking down that order and making any adjustments, other than the fact that sometimes it is easier to increase order quantity on an existing shop order by the amount we need to replace, than to release a new shop order for a tiny quantity.

We report our labor and inventory using JIT600
We made 90 and scrapped 10
JIT600 adds 90 to inventory via PR and subtracts 100 raw materials used up and there is an RJ (rejects) transaction tracking the 10


Now I guess you could modify JIT600 job stream to have the RJ transactions go through some other location, but at this point for us, the raw materials are being subtracted. We NEVER create no good inventory through our labor processing, so there is no need to modify to have it end up in the QC warehouse.

There is a screen on JIT600 to make adjustments
for example, perhaps we had to use substitute materials.
The BOM calls for a copper component, but we run low, and the customer has authorized us to use a copper tin alloy substitute that is more expensive but has the same electrical properties ... the labor ticket has notation that this was done, so in the process of entering the data via JIT600, we are able to substitute the copper tin component for the standard copper component. This keeps our inventory accurate with a minimum of hassle.


I suggest you look at the JIT600 screens for your version of BPCS to see if you can substitute a different location for the material, than the standard expected by the FMA file.

If what you want is for the JIT600 job stream to create inventory in your rejects warehouse equal to the quantity reported as scrap by labor, then perhaps you can do a modification there, but I warn you in advance, we have modified our JIT600 job stream and that software is a tangled nightmare, not simple. Much better to adjust your procedures.

When we discover we did some misposting ... we reported 10 as good, which now turns out to be scrap, JIT600 is not supportive of doing negative inventory transactions. We use SFC600 to back out the labor side, and INV500 to back out the inventory side. At this point we are reversing transactions on quantity that should never have been posted.

Dear ALL:

We use BPCS V6.1.01 C/S version.

There is a question about the defected
material handling process during the WIP.

The system is

Warehouse 01 is the raw material stock warehouse, warehouse 31 is the
defected material stock warehouse.

In production process, we issued the shop order(say, quantity 100) from 01
warehouse.
Sometimes, there will be some defected material found (say, quantity 10) in
the production
line. It means we got to reissue the materials (using INV500, "I"
transaction type) to the WIP.
But we have to withdraw the quantity of defected material,quantity 10, to
warehouse 01 and then
re-issue again in order to keep the shop order and stock status correctly.
After that, the warehouse
operator uses INV500 (transaction T) to transfer quantity 10 to the
defected warehouse 31.

Question is:

Is it possible using INV500 to withdraw the defected mateiral to warehouse
31 directly which been
issued from warehouse 01. And in the mean time, also needs to affect the
shop order quantity.

Thanks.


Jingker Cheng

-
Al Macintyre http://www.ryze.com/go/Al9Mac
Find BPCS Documentation Suppliers http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
Part time may get commission from some BPCS vendors for helping them ... I will now say in a post if the product I commenting on is also one potentially involved with this ... not that I have made anything from this yet.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.