In posts to BPCS-L it is important to mention the version of BPCS you using.
This is because what can be done, and how to do it, varies greatly by version.
As a general rule, you want a system that will have minimal hassle for
people to have to manage what has to be done, low risk of messing up, easy
to audit. It seems to me that in your situation you are placing an
enormous amount of trust in the customers honestly accounting for your
product, that they have not yet used.
You probably need to include a system of confirming they received the
product, because if they are expected to store it for X months, then tell
you what they used, if a delivery does not arrive, or is miscounted, you
don't want to be arguing 6 months later what actually got to them.
It is bad enough when something was shipped 2 weeks ago, and we are trying
to reconcile what the customer says they got vs. what our records say.
You may need to have some system to audit the value of what you have sent
them, that they have not yet used. There's all kinds of places where
errors can occur & other people not believe the errors.
We ordered a $ 10,000 reel of wire from a supplier. It fell off the truck
in transit to us & arrived in unusable condition. We documented this with
the truck driver & sent it back to the supplier & called them asking for a
replacement reel. The supplier sent us an invoice for the reels, within 24
hours of each shipment. It was not obvious to our accounting dept that
this was a replacement shipment for one that had been rejected. We paid
the $ 10,000 twice even though we had only recieved one reel.
I have a program that compares what was received, what was paid for, what
was ordered, the costs quoted, etc. to identify anomalies ... what I call
"3 way mismatch" ... and that is how our company found out that this
happened. My software finds all kinds of stuff that BPCS users swear
cannot possibly happen, until I show them the evidence.
So we contact the vendor and ask for a refund. They have no record that we
returned the reel. We supply them with our documentation of this. They
turn it into their insurance company, because the damaged reel is no good
to them. Their insurance company rejects the claim because this was the
fault of the truck company.
So then we file claim with truck company. Truck company has no record
that this ever happened. We supply them with our documentation. They turn
it into their insurance company. Whole process takes over 6 months before
we see our money back.
My point is that you have to have excellent record keeping system to prove
what happened, to account for your assets, that may not always be under
your control.
I am familiar with "consignment" where we have customers that supply us
some of the raw materials to make their products. We use a special item
class & have them as cost zero (because they are zero cost to us), so that
when we roll up costs, what we see is the cost of what we do to make the
end part. The special item class is so that when people are questioning
parts with missing costs, or me writing programs to list suspicious parts,
we know that item class is supposed to have all items cost zero.
I am not familiar with Pay based on customer usage.
When we ship something to a customer, we "expect" to be paid in full,
within the time frame specified by the A/R terms, but we know some
customers pay according to their own systems. In fact, some of what shows
up in A/R as over 90 days, is actually over 2 years, so "over 90 days" is a
mite misleading.
However, there has been past discussion here (I not remember what keywords
to use vs. the archives) where there is an issue associated with the
transfer of ownership.
Let's suppose you have a chemical storage facility with chemicals supplied
by some other company. Until you actually use the materials in the storage
container, the excess inventory belongs to the supplier, but is on your
property.
So how do they know how much has actually been used?
Do they have some kind of meter that they read via Internet?
Where is the inventory recorded? It is on your property, but it does not
belong to your company, until actually consumed in production.
Are the containers clearly marked "property of" that other company?
There is an opposite situation.
There is a capability in BPCS to handle "outside vendor" work, or "outside
operations".
This is where in your series of manufacturing steps, at some point a half
made product goes off site to some vendor to do some special work to it,
then returns to your factory.
This can present some inventory control challenges. That unfinished work
product is the property of your company, but it is not physically on your
site. So how do you know what the true quantity is, track scrap at the
outside site, when need to replensish what are raw materials to them.
We have some reports that look at the quantity to be made, the quantity
completed at the operation step where the product returns to us, the
quantity at operation where we send them a kit of materials to do their
thing, and the math gets the quantity that should be currently WIP on their
site. This ends up on a report, listing all the work they doing for us, so
they can check our numbers, to identify any place with a disagreement.
Also at time of physical inventory, we have a crew visit their site, to
count our inventory that is at their location.
You may have to do something similar with your customers, so you can show
your auditors, and others, precisely how much of your property is
supposedly sitting at your customer site.
We have a special work center for the outside vendor, where piece work is
used for the costing, instead of the customary people or machine rates. In
full blown outside operations, there are different kinds of orders attached
to each other, such as a purchase order to the outside vendor to return the
next production level, and a shop order to deliver the work-in-process to
the outside stages.
Our factory also has "safety stock" of some customer items stored at our
facility, so that if they want up to some quantity, we can ship out same
day, in which the customer order created to ship it, combined with the
minimum on-hand, triggers MRP to replenish that stock. We have had lots of
problems with customers that forget to tell us when they no longer need us
to store this kind of excess.
I wish we had a system to send the customers some statement.
"Here's what we are holding for you, what its $ value is, that you pay when
you need it, or you pay when you no longer need it"
In other words, if and when they realize they no longer need us to store
the stuff, they still owe us the value.
Maybe have to pay some "interest" on excess storage time.
The purpose of the statement would be to remind them what parts they had
talked us into storing for them.
You might take a look at customer order types.
You can get at nice chart of what they all are, if you go into ORD300 or
ORD500 on any order, find where is the field for order type, place cursor
on the type, then F1 help ... BPCS help is cursor sensitive ... where the
cursor is on the screen, when you press help key, what help info you get,
has something to do with where the cursor was, when pressing help (F1 is
universal help key on IBM platform, and in BPCS software).
There may be a combination there that is a good fit to your situation.
When type-1 orders are sent to the customers, we relieve the item ordered
from inventory, record that the customer requirements were fulfilled,
capture cost of item shipped, add to sales totals the amount billed the
customer, track receivables. It is a familiar pattern.
But sometimes we want to charge the customer some $, but not update any
inventory, like a credit memo, or charge them for some kind of expediting
hassles.
Special Charges are an alternate way of doing this.
We have a bunch of different special charge codes for different scenarios,
so that the correct place in General Ledger is updated, according to the
text associated with the type of special charge.
This is stored in the IIC item class file.
We use 2 letters of alphabet to designate classes of items.
We use 2 digits to designate special charges.
I don't know if this is standard to BPCS or just how we implemented it.
There's also how BPCS uses "customer orders" when we have multiple
facilities & one facility is making parts to be shipped to another
facility. These are called "resupply orders." A special customer order
type is used, so we do not have to have the accounting hassle of facility-1
getting bills from facility-2 & having to handle the payables on one end
and receivables at the other end.
There's also some add-on packages available from 3rd party vendors to help
BPCS companies do stuff that falls outside the standard capabilities of BPCS.
You might ask what arrangements your company has for BPCS tech support.
Each place that does tech support has a wealth of extra documentation
available.
In my case, i have to get boss approval before a call to tech support,
because if we do not call them, we do not get a bill, so the boss has to
get convinced that the need justifies the call.
Some companies have tech support where they pay a humongous sum of $ each
year & get unlimited tech support, within some parameters.
Al Macintyre
Ya know, giving a guy a fish is a good thing.
Teaching him how to fish is better.
Thanks for teaching me, and letting me have the chance to learn.
Bill
On Wed, Nov 19, 2008 at 2:23 PM, <macwheel99@xxxxxxxxxx> wrote:
> While waiting for good reply here, take a look on your system for a file
> called BPCSDOC.
>
> You can find it with PDM where the library is *LIBL default.
>
> BPCSDOC is a source member file, where each member is a different
> BPCS "manual". There should be one prefixed SSARUN for each application
> module of BPCS.
>
> One problem is that the one on customer orders is too large to view via
> standard PDM SEU, so we have had to break ours into pieces to make it
> manageable.
>
> The first on-line "manual" in BPCSDOC that you should study hard is called
> SSALOG00 or the logic manual, which helps you navigate the rest of
> the "documentation" ... scarce yes, hard to find yes, but SSALOG00 provides
> a road map to documentation you probably did not know was on the system.
>
> The on-line documentation is not as good as what comes in manuals, and
> available from tech support, but it is better than nothing.
>
> On Tue, 18 Nov 2008 08:19:09 -0600, Bill Brosch wrote
> > Hi all.
> >
> > New to BPCS and have a few questions. I've got a project about doing
> > customer consignment inventory & billing. As we were laying out
> > the "normal" consignment process & checking it in the test system,
> > we came across something called Pay as Built. Now it sounds like
> > this could be just what we are looking for,
> >
> > Here's the rest of the background (short version):
> > We will take an order, zero bill it, and ship the product to the
> customer.
> > The customer will use some of it, issue a notification of the
> > portion that they have used, and then have us bill them for that
> > part of the shipment. Rinse & repeat.
> >
> > Question then becomes: Is this the Pay as Built, or should we be
> > looking at a different part of the system. Second, as I've got no
> > real knowledge of the system, and doc is very scarce, how would I
> > set this up as required above.
> >
> > Any help is deeply appreciated.
> >
> > Bill
midrange.com
