Re: Customer-Supplied Parts

We have this on 405 CD.

We use a separate item class, and MRP planner code, for the customer
supplied items, since our cost is zero, and we have reports listing items
with missing costs, and want to exclude these.

Consider MRP reports driving PUR+SFC requirements. We need to supply the
customer with info on our inventory of their parts, and need for
replenishment, and we don't want MRP telling us to replenish these parts the
normal way, thru PUR or SFC. Using a separate item class and planner code
helps with this, but there really needs to be some field in the item that
uniquely identifies the customer involved, since we have this scenario with
more than one customer.

In addition to customer account, there needs to be a vendor account on the
same outfit. It can help some people if that's the same number in both
systems. However, I have a GL modification that tries to match reference #
with customer or vendor name, in which it helps not to have same # in both
systems.

When we receive these parts from the customer, we don't want the receiving
to be going through the PUR ACP process, or the RMA customer returns
process, just like we don't want inter-facility inter-company inventory
transfers going through AP or AR.
The actual transaction is much like an "A" miscellaneous inventory
adjustment, with some special reason code, but we have made special
inventory transactions, copied off of "A" to track this activity.

Our LL is for location inside BPCS vs. location outside BPCS when it is
within our overall company, where the reason code is WHAT location.
I suggest you consider something similar for receiving such product from
this customer, where the reason code is which customer.
Using a different transaction code means that the record of the transaction
can go to a different GL account. Even though the entry might be zero
dollars, you have a record of the volume of activity.
Reason codes may not be as important to you as to us. We have modified
GLD230 to back track detail to assist auditors and forensic examination of
our books.

Our auditors advised against using an excessive number of different kinds of
transaction codes for different circumstances, since that increases risk of
human error using wrong code. However, there needs to be enough information
with the transaction, to back track what happened, in case GL adjustments
needed.

-
Al Mac

Happy I remain this functional: Wake up each morning; roll out of bed; feet
touch floor; I can stand up (sometimes need to push with arms); walk; get to
toilet; all familiar systems do their thing.

-----Original Message-----
From: Bailey, Dick
Subject: [BPCS-L] Customer-Supplied Parts


We assemble machines basically to our design but often
special-designed to order. One customer is supplying some parts to be
assembled into the product, but we don't normally do this.

It's enough different parts and a large enough number of machines
that we want to track the parts the way we'd do if we had purchased them.

What's a good way to handle this? (We're on BPCS 8.0)

Dick Bailey
MCFA, Inc