Re: BPCS 6.1 - Switch from Pick Confirm to Ship Confirm

Thanks Alister, for your write-up.  I had worked with BPCS 405cd a long time ago and seem to think this issue was easier to handle in 405cd than in 6.1.  Did CEF (Session Manager) exist in 405cd?  I don't recall using it there; here it seems to muddy the waters quite a bit.  Finance took full control of CEF and set everything up in it before I started here.  I have not run across where the G/L accounts are assigned to the individual transactions in what I call "regular" BPCS.  Maybe in CEF somewhere?

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: Friday, May 15, 2015 13:03
To: 'BPCS ERP System'
Subject: Re: [BPCS-L] BPCS 6.1 - Switch from Pick Confirm to Ship Confirm

I am now retired from 405 CD,  no longer have BPCS access, writing from memory.  Plus I recognize some 505CD solutions don't translate well to 6.1.

Some BPCS screens are complex, invite human error.
Fortunately, BPCS order processing uses work members named after work station, patterned on the master files not updated until shipping person completed, so it was possible to have them exit, then we clear their work area, and reset BPCS flags what step they on, and start over, without the OOPS. We had a program to reset the order in-use flags.
This could not work for the people who insisted on one humongous batch for an entire day's work.

GL batch with COGS, generated by shipping, can be delayed in posting, and can be edited, without needing modification.
Within BPCS 405CD we could adjust the  rules for what shipping transactions going to what GL Journal types, and adjust the rules for that journal detail, so that we end up with one COGS transaction for each customer order shipment.  We used SH journal prefix for this purpose.
Then we can pick and choose which COGS batch to post when, first editing them in BPCS to alter date for the Gen Led.
Very tedious, thanks to high volume shipments data to navigate.  Also it is impractical to slide across GL fiscal periods.
I think the inventory transaction to GL was in same GL Journal batch as the COGS transaction, but a delay in posting that is not a problem, since the inventory quantities are accurate irrespective of what's happening with GL.

We also had the end month unfinished business challenge.
One way that could be handled was to have an end of month set of GL "clean up" adjustments, then at start of next month have a bunch of reversals of those adjustments.  That way, end month GL looked nice to finance, without messing up the rest of the business, while the adjustment journals showed a clear trail to auditors what all unfinished each end month, that they were interested in.  

Finance main complaint was volume of inventory on-hand at month end with negative quantities, because 2nd shift transactions were entered by next day clerical personnel, and we had float in processing labor tickets, where it was not unusual to have shipping posted before the parts production entered.
There were also some bugs, where we had inventory, without all the files populated, so it did not show up on some reports. I called some of these inventory with null costs, because there was no record for them in the cost master file.

Our management had added complication that they wanted no audit trail to tell customers about our mistakes, other than those a customer found out about independently.  So we were doing a lot of futzing  "outside BPCS cycles" like editing B transaction before invoicing, editing orders, adjusting inventory, and GL transactions before they got posted.

Alister Wm Macintyre (Al Mac)