Re: Create PO from SO

Are you sure you never worked here at Scovill? Your story is very similar to what happened here which now I get to babysit and try to keep it out of trouble! I inherited this mess about a year and a half ago, with previous BPCS experience (12 years ago) coming from a 405cd shop that was transitioning to 6.1. This shop is running at 6.1 which has been highly customized too. New horrors are being reveled weekly.

Best regards,
Timothy J Knoebel, Sr. iSeries/BPCS Administrator



-----Original Message-----
From: BPCS-L [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On Behalf Of Alister Wm Macintyre (Wow)
Sent: Wednesday, July 22, 2015 14:31
To: 'BPCS ERP System' <bpcs-l@xxxxxxxxxxxx>
Subject: Re: [BPCS-L] Create PO from SO

Once upon a time, we had DRP license, then it was taken away from us during adventures in relations with Infor.
Fortunately, at the time, we were not doing a lot of cross-facility operations which needed it, so other work arounds developed.
I can only make suggestions, based on realities at my former day job, which may or may not help with your current situation.

There are many reasons why some companies do not use MRP effectively, and this has fueled many 3rd party add-ons.

We modified many BPCS programs, and added reports and inquiries to the collection.
There's BPCS programs to launch PO or SO, done between some criteria range.
We modified to expand options on prompt screen, sort sequence of what got generated, and appearance of reports, but 95% of the software ran with vanilla BPCS.

You might look at what's involved in selecting items relevant to generating a bunch of PO or SO.

BPCS items came with planner codes, which tied into order launching. We could opt to only release orders for one particular planner code.
While BPCS planner codes were intended for a particular PERSON managing some orders, we used them for a particular cluster of items to be handled in a consistent way, such as part of the operation go thru a particular outside vendor, where we wanted to group all of them together for consistent processing.

Where we needed planner code person logic was with customers, where we had various people specializing in the needs of customers based on the industry of those customers. We addressed this by using the customer type code to indicate which industry cluster, then modified various BPCS processes and reports to be able to select for a particular customer type, or range of them.

We had items which flip flopped between make/sell because depending on quantity customer needed, and lead time, sometimes it was cheaper for us to make it ourselves, and sometimes it was cheaper to order from some vendor.
This played havock with accurate costing, and types of transactions allowed.

We went to a system of a letter on the end of item, signifying something special unusual going on with that item.

Item 12345P meant that item 12345 is normally manufactured, but in this case we are going to purchase it.
When it came in, we did a pair of inventory adjustments, to subtract which just came in as 12345P and add same quantity as 12345.
Comments in the transactions pointed at some reference # on the other side.

Item 12345R meant that the end result would be item 12345, but it was going to be manufactured differently than normal. The R meant repair-rework.
Item 12345S meant however the item 12345 was to be procured, it was not to go thru BPCS. The S meant sample. These also had item class SA.

There's an INV to alter ITE file = Inventory Transaction Effects.
We added to the collection provided by BPCS.
Our version of BPCS had some bugs, where some programs obeyed vanilla ITE setup, ignored changes we made to ITE file.

There's a corresponding GLD program with rules what to do with the new transactions.
We added new kinds of GL Journals, to track the special exception unusual operations we were adding.

Alister Wm Macintyre (Al Mac)
Formerly doing BPCS modifications.