×
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.
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
As an Amazon Associate we earn from qualifying purchases.
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.