It used to be commonplace for us to ship product with price zero, because
the quoting process was not yet complete at time of shipment. Noticing zero
invoices, let alone accounting knowing it was wrong, was not easy, and
getting the customer to pay for them was impossible. I added query/400 to
view shipment data, not yet invoiced, so we could catch that kind of thing,
and delay invoicing on suspect shipments, until after correction figured
out, and DFU used to edit BBL file, to get corrected invoicing. I also
added reports for relevant management review ... here are orders soon due to
ship, which have various problems like no price yet, extremely past due,
will be past due if certain bottlenecks not resolved soon, are coded
manufactured but lacking engineering details like BOM or routings, or coded
for MRP planning.
It is not good enough that the customer orders an item that is in your
system, when it is a new item, there's all sorts of input needed to make
sure you can fulfill the item properly.
Another scenario that we are seeing in the slow recovery from the economic
downturn: There are items some customer not ordered from us in years; The
component parts have had dramatic cost increases; The part really ought to
get price requoted. The customer reorders, using the price that was valid
several years ago. The people, or software, handling the order, are
ignorant of the fact this is an ancient item with a price that is not smart.
Then it shows up on our sales reports as something we sold for a loss.
I did a modification to INV300 to show first few entries from price break
file, so that people can see at a glance whether an item is in the price
discount system or not. I added a query/400 inquiry, where people can key
in an item to access price break info, since the vanilla path requires a
person to know in advance which price break system is being used & we have
several.
There are some fields on top of INV300 and other BPCS inquiry fields that we
not using for their stated purposes. We populated the fields with customer
identification, and other more useful contents. This reduced the manual
steps needed for people processing the items.
We have BPCS Customer Order Change History (from Crowe Chizek) so we are
able to see when a new order has been entered, or changed, that is a lead
time violation (often human error entering date).
When we get an item returned by customer for repairs, or revision level
conversion, we stick letter R on end to show which using different BOM,
routings. When we are processing samples of new revision, not yet approved,
we stick letter S on end. But the customer uses same item # irrespective of
where in approval cycle, model change, repairs, substitutions, etc.
We no longer use EDI. We had to abandon it because of the cost of
supporting customers constantly violating EDI standards. We started with
EDI because several customers promised to pay our implementation costs, but
their people were constantly changing rules associated with what they asking
for, then when our sales manager delivered bill-so-far, the
customers-management refused to pay. Early in the process, I told my
management that it was a mistake for us to get EDI I, because what our
customers were doing meant we needed EDI II (which supports rules changes by
clients).
I also suggested my employer get FOX TROT software from
http://www.enablesoft.com/ (My suggestion was not implemented) because we
get customer requirements from a great many different types of sources:
customer web sites; customer reports poured into Excel and other formats;
mountains of paper by fax; snail mail etc. Fox Trot sets up a script for a
PC connected to AS/400/I user logic path to combine what info from what
screens and command keys etc. to automate acceptance of data from any format
to any format, to handle that which is not exceptions to the rules.
Another related problem is turn-over of personnel at trading partner sites,
combined with poor management of paperwork on trading partner agreements,
and an enormous volume of verbal agreements between customer service and
buyers. The customers misremember all the nice stuff we promised to do for
them, and forget all of their obligations. People are trained how to send
orders to vendors, but not told anything about limitations like lead times
and pricing.
Drop ship adds to the nightmare.
In our industry, we also have a major problem with commodity price
inflation.
-
Al Mac
.
-----Original Message-----
From: bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx] On Behalf Of
craigs@xxxxxxxxx
Sent: Tuesday, June 08, 2010 2:15 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: Re: [BPCS-L] ECM Order Validation
Thank you Larry and Al for the response and insight. It sounds like we
will need to have a preprocessor to ECM since we have trading partner
agreement violations and can't live with the extra manual intervention
required with the orphans, etc. I think Larry has verified that with
experience with other clients. Most of the time it is various customers
trying to order before the quoted lead time or at a different price. We
have similar situations that Al mentioned with the customer ordering an
item before it has been validated. Sometimes it just a different variation
of another part. It is awful when there is a change in a product line.
One of our customers orders so timely that sometimes the PO line is due the
same day and we get changes within seconds of the original PO. Our people
scramble so often to determine the price for the customer that we have to
start making the product before we know the cost (laugh). That is one
reason that manual intervention with ECM where we manually update the order
instead of allowing acceptance has no benefit. We have various customers
violating the agreement. We could still accept the date or price even
though it violates the quoted lead time or price if we choose. I worry
that we flag it as good even though it is a violation then ECM would kick
it out from its validation. Then there is the whole 855 EDI acknowledgment
for certain customers where we would need to notify the customer about
accepting with price pending or with a date change. <Sigh> I'm curious
about Larry's client who wrote a preprocessor and brought the orders in
through the release management system. If we tried ECM, would ECM also
allow customer parameterization to allow some customers to validate
differently than others? Some customers we should hold the entire order
until valid. Others, we just post the good lines and deal with the errors
later.
I'm sorry, I know I have loads of questions but I think my main question
is: Can we force ECM to not validate lead times or prices since we are
probably going to end up handling those in our own preprocessor? We don't
want ECM to thwart our validation. How would the release management system
handle this?
Thanks again.
Craig Strong
Al wrote:
----------------------------------
We have customers who fail to update their systems when we have price
changes agreed to. I think software should be able to automatically handle
the price corrections, depending on how complicated your price break rules
are. We also have customers who order say quantity 200 to get the 200 price
break, then call back to change that to 50 right now, other installments,
so the system needs to be able to recalculate the price, notify the
customer, since manual updates on 405 CD does not automatically fix the
price.
The customer # should come from software that matches customer name etc.,
ship-to address vs. BPCS files.
We have had item # problems where:
(a) The customer item # is more than the 15 positions of BPCS so we have to
have some kind of translation , which the software should be able to
automate.
(b) Our contract says new items are not to be built, until customer
engineering has validated our first samples. Sometimes customer buyers do
not wait on this, order the new items anyway. If we build what the buyer
ordered, and if customer QC rejects the parts, we have to bite the cost.
(c) The customer system for tracking vendors is dysfunctional, so we get
orders for parts that some other vendor might make.
-
Al Mac
-----Original Message-----
From: bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx] On Behalf Of
cfgwizard@xxxxxxx
Sent: Monday, June 07, 2010 12:08 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: Re: [BPCS-L] ECM Order Validation
Craig,
I recently had an 8.1/8.3 client that wrote a preprocessor and brought the
orders in thru the release management system . From my recollection they
had
only a few errors to correct but nothing on the scale you describe. They
worked very close with the customer service reps to police these
descrepancies.
That is why it is not clear to me that this is entirely an IT problem. If
the customer is inventing part numbers, customer numbers, and prices, then
perhaps he doesnt understand your trading partner agreement. If he is
getting them from someone in your company you have to find a solution that
addresses the process for maintaining this data in a more timely fashion.
Regards, Larry Costain
-----Original Message-----
From: craigs@xxxxxxxxx
To: bpcs-l@xxxxxxxxxxxx
Sent: Mon, Jun 7, 2010 8:23 am
Subject: [BPCS-L] ECM Order Validation
It has been years since I have posted on this list. I will be reviewing
this list from now on so hopefully I could help someone else too. We are
working with a consultant but it doesn't hurt to get a second opinion or
point of view.
The current scenario is that we are on BPCS 4.05CD and planning to convert
to ERP LX 8.3.3. We have a high volume of EDI that we write to XCH/XCL for
PO processing. We do our own validation before and after writing the X
files. Our experience testing ECM on ERP LX 8.3.3 is that it doesn't
handle invalid lines well and also the ability to send 855 PO
acknowledgments up to internal standards. The errors we would need to
validate would be item errors (not found), price mismatches, warehouse
errors, and lead time violations. Item errors would be the one error we
wouldn't want to get through. Well, ship to and customer number also but
that would be abnormal.
Let's say for example we get a PO for 100 lines and 10 of those have
invalid items that need to be set up. In some cases it could be days for
the item to be determined. The way to get these posted would be to have
ECM post the good lines which would leave the 10 lines out there as orphans
without even a PO header. Then when those items are determined, delete the
lines and add them manually to an order. The consultant mentioned this and
it makes sense because that is how standard BPCS does it in 4.05CD (leaves
orphans). That is why we handle item errors our own custom way which
allows reprocessing. Instead of item errors, say they are lead time
violations. We have our own screen in 4.05CD that would allow accepting
those violations and entering the new scheduled date which, by the way, the
new date would be required to be sent on PO ack's (855's) as well. Also,
price errors would allow being accepted. Again, we would need to be able
to send an 855 with "accept with price pending" if we don't agree to the
price. This would need to set the status for posting from ECM even though
the prices don't match. Also, the ability to reject any of those lines and
send the 855 rejection before those post.
Leaving orphan errors and not allowing revalidation is unacceptable in high
volume situations. The manual entry and manipulation would be a huge waste
and ludicrous. We are considering a preprocessor to ECM which would
fulfill our requirements. We have considered writing the TOHB, TOLB, etc
with a certain status to skip ECM for errors. Then set the status when
good or accepted. We have also considered writing the XCH/XCL (X files) or
similar files like in 4.05CD which would be validated and feed the TOHB,
TOLB, etc. Then there are the adapters for customizing validation but I
think I am talking about handling errors in a customized way that wouldn't
require extra manual manipulation. Then being able to accept/reject (also
with possible 855's for certain customers) before the order is posted.
Any suggestions? Am I missing something? Will ECM really do more than
what we think? Has anyone worked around this that could share, please?
Thank you for any input.
Craig Strong
midrange.com
