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



We are on 405 CD.
There was an issue with earlier versions of BPCS that may have been fixed, with respect to requirements past due on arrival, and new parts engineering.

Let's suppose we have a new part new item from a customer.
We scramble to get the BOM and Routings entered, we identify and order the raw materials. The customer wants this ASAP. We enter the customer order in which lead time for raw materials might be 60 days ago, but we only got the part specifications from the customer 10 days ago.

MRP is not going to plan into the past.
If the engineers entered effectivity dates as of the date when they keyed in the specifications, then the 60 days ago goes before the effectivity date of when the parts were originally entered, so MRP plans are incomplete, not including all the components needed. So if SOMEONE not stay on top of us getting going with the new parts, we end up at due to ship date, and some critical component was never manufactured, because of the effectivity date problem. This is why our engineers are SUPPOSED to enter an effectivity date that is some time before the date that the customer first sent us the specifications.

Let's suppose we get a rush order from a customer, and our research says we can make the item, because we have enough safety stock of raw materials, or the customer has authorized us to delay some other order that shares some of the components. MRP is not going to schedule all the subassemblies to be made at accurate lead times into the past, when those dates calculate out to being dates prior to the today date of the MRP planning.

This is why some companies use an MRP planning date of the beginning of last year. We can get "accurate" planning if we lie to the 400 and say the true date is several months ago, then run MRP so that it plans using correct due dates based on the lead times, then tell the truth date to the 400, and rerun MRP, and now we have a list of shop orders and purchase orders that need expediting.

You might also check your BPCS Calendars, to make sure that non-work days (weekends) are not factored into # working days to make the product. This area can be confusing to some people.

If one person thinks 31 days as calendar days in month, but your BPCS shop calendar is not including weekends as work days, then you need to change those 31 days to 20 days (4 weeks @ 5 days) lead time.

Currently using BPCS Version 8.2.01 on iSeries V5R2.

We are having an issue with Shipping Patterns and Lead-time. A release is received from our customer (EDI) and when the release is pulled into the RMS contract in BPCS the shipping pattern will be used. When the release is converted to the order, the lead time is picked up and new dates are calculated but the dates are not correct. The shipping pattern and lead time do not seem to be working as they should.

If the item in the release is a firm requirement, the new calculated date (still off) will be pulled through for scheduling and MPR.

If the line in the release is a forecast item only, the shipping lead time is not brought through to Scheduling and MPR. The customer request date is used when MPS and MRP are calculated. We may have a shipping lead time of 31 days but the system does not consider this and we would not order our components in time to make this build.

It is a good thing that our Materials Department is aware of these issues and ensures that all Customer Orders are covered and production has components when time to build. NOTE: Our Scheduler will not rely on BPCS and has a spreadsheet in which he maintains using information given to him from Customer Service.

The first time this issue was reported to SSA, we were told that BPCS was operating as it should but SSA did create an enhancement BMR. We were persistent and now this BMR has been escalated.

Is there any other companies that are also experiencing this problem and how are you dealing with this issue?

Sincerely,
___________________________________________
Sylvia L. Dufour
Business Analyst
Schukra of North America Ltd.





The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this message and any attachments in error and that any review, dissemination, distribution, copying or alteration of this message and/or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by electronic mail, and delete the original message. Sender employs reasonable precautions to ensure against transmission of viruses and other destructive e-mail attachments; however, it makes no warranties that this message or any attachment thereto is free from viruses. Recipient is responsible for the protection of its own system; under no circumstances shall Sender be liable or any actual or consequential dam! ages that may result from any inadvertent transmission of a virus or other destructive e-mail attachment. Recipient is cautioned not to open any file or attachment about which there is any uncertainty.

--
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.

Delivered-To: macwheel99@xxxxxxxxxxx



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.