Re: Month End Year End Data -- BPCS-L

Warning ... this is a long e-mail, with comments on top and in-line below.

If you do not already have a BPCS manual, I suggest you get one. There are several fine publishers. The manuals cost around $250.00 to $350.00 (US) and include lots of info about what files contain what data. We have talked about BPCS documentation in BPCS_L archives.

If your company does not now have some kind of BPCS tech support, I suggest you look into getting this service. It is extremely dangerous to be running an ERP purely on peer advice through a discussion group, even one as good as this.

I am not an expert on Financials, and I know stuff very different across BPCS versions, but let me take a crack at some of this. Be informed that for several months, me (the IT guy) has been doing the End Month stuff for my employer, and recently I got the privilege of doing the End Year stuff (first time for me). Theory is that if something goes wrong computer-wise, you need the IT guy there to take care of it (also I can be reviewing "Why does this or that task take so long? What can I do to speed it up?" Which has led to some conclusions about where it is safe to multi-thread and where not.). If something goes wrong with the totals, top management can then decide whether the situation is serious enough to go back to some backup ...

We have very early in our end-fiscal check list, doing backup onto a tape which will go off-site and not be re-used right away. Several years ago, we did have a case where a decision was made to hang onto that tape (take it out of normal rotation), then several weeks after an End Fiscal, backup the new reality, restore the files as of right before end-fiscal, do some stuff with that reality, then restore the new reality, and continue on. Big pain in the ***** for everyone, but that was doable.

Some other companies, on this list, copy their costs as of end year into frozen standard costs, so that in future fiscal periods they can compare their now costs to what they were at last year end.

BPCS has 3 calendars that I am aware of: Fiscal Calendar controls the posting of other BPCS data into General Ledger. Shop Calendar of when your factories will be working ... used by the Planning Modules. Shipping Calendar used by DRP ... this does not yet affect us.

Oh ... I just got to a certain point in my life ... I was born 8 Feb 1944 My attitude is ... I am glad to have survived this long, and my mind is fully functional, and hope I survive lots more.

you wrote:

Dear All:


Please clarify the following for financial and manufacturing effect for the
month end and year end.


1.  If we execute month end close on Jan 31, 2003  and financial is not yet
finished with their reconciliation for January, what would happen?
Can they still adjust let's say if it is already Feb. 3?

Normally for our month end close, we open the next fiscal period, but leave the just ended month still open for final adjustments for that month. Normally during the year, we have the current month open, and the prior month. Very rarely more than two fiscal months open. Right now we have December, January, February open, and also special period 13 for YEAR adjustments that are not transactions for any one particular month.

Life goes on like usual for the whole company, while the accounting department works on closing the books for the fiscal year. I do not expect them to get done any time soon. Then we will have a visit by some financial auditors, and as a result of their visit, there may be some more adjustments. Preliminary Year End has been run several times. Final Year End is still some distance away.

How about Manufacturing e.g.  purge shop order, purchase history, inventory
transaction history, Please be specific?  Are all this histories retrievable
after it has been purged and where (table/database)?

We run shop order purge on the average of twice a week, sometimes once a week. I would guess that in an average month of 4 weeks, the shop order purge gets run 6-7 times. Usually I do all facilities ... occasionally there is a problem with one facility, and I do a purge of all but them.

I have found that running SYS120 (ought to be done in a restricted BPCS system) in front of CST900 can result in the pair of them running in less time, than if SYS120 was skipped. (We can do BPCS file reorg when not restricted, but what happens is that the most popular files, that most need a reorg reset, just do not get what they need.)

Once a shop order is purged, the data that was in there is GONE except where we have done a "modification" to capture some stuff in query work files, and except where the purge process updates some files related to the cost of making the parts, and except the inventory history and labor history, and except for a file we added that tracks manufacturing history by machine tooling

For purposes of our month end, there are a number of reports that have been created that look at the data that was reported through history, more labor history than inventory history

From perspective of users in entire company, when they looking at history other than through vanilla programs, I think the most popular are the labor history and the billing invoice line item history.

Note that in Query/400 and BPCS that if you have a report that combines several files e.g. Labor History FLT access Clock # CEM to get employee name for the report and if that employee is no longer on the payroll and if someone has deleted that employee from the clock number you run the report for the month, and what that employee did is not included in the totals because only records that match in all files show up there

so as a policy matter ... we code our CEM employee clock # as TERMINATED from payroll, but still a valid record for end fiscal reports

Another related topic ... at the time of shop order purge, CST900 looks at history on shop order coded as closed, and needs to see that all the inventory and labor has been posted that is needed. It does not rely exclusively on the totals in the shop order. If it cannot find some of the reported history on that order, the order does not purge. Therefore your retention of old history, needs to stay in the system longer than the oldest shop order.

For this reason, we do not use the vanilla shop order history purge program, but rather something I have written that, among its other talents, does not wipe out a labor history record if the shop order involved is still open.

You need to review the processes used by your company in the purge process. There are options ... do you want the history that is going away to go to a backup tape, which can become a nightmare to manage, because stuff goes to tape based on when it became older than the history to be retained, and the vanilla BPCS tape file labeling is brain dead. There's also archiving software out there ... check BPCS_L archives for that.

We have found that it is so rare that someone needs access to records from eons ago, that we don't save records from eons ago. We do have end fiscal reports in cartons labeled by which month, and once upon a time I suggested that all the fiscal stuff for each fiscal period go on a CD ROM because in my opinion, the technology of tapes and diskettes go obsolete every few years, while a CD ROM from decades ago can still be read ... but perhaps better make more than one of them, as backup.

Once upon a time, we had a purchasing guy who wanted to track history of cost changes on raw materials longer than everyone else needed all other history saved, so we had a modification of the inventory purge that when the "C" record was due to leave, it got copied to this other file, then there were reports for him that combined the "C" records in current history with the contents of this other file.

2.  If we execute month end close on Feb. 5 2004  for January Book  will it
effect on February or January as a closing month end close.

What is affected is controlled by two major factors. 1. Your fiscal month determines if Feb 1 2 3 4 5 is included in January or in February. 2. Your corporate discipline upon the work force with respect to back dating transactions.

For example: Let's suppose you tell everyone that you will be doing Month End Close on Feb 5, and they need to be caught up on their transactions in advance of month end close, but some co-workers get behind, then after you are all done with month end, they catch up with their posting, and BACK DATE their entry to when it should have gone in, before Feb 5.

If you have closed the prior fiscal period, BPCS will have indigestion if someone tries to post to a period that is not open. In other words, your totals will be whacko. If you have not closed the prior fiscal period, pending accounting adjustments, BPCS will accept these other transactions, that accounting knows nothing about, and BPCS posts them as if they had gone in before month end, changing the relevant month end totals all over the place, different than what is on the reports that accounting thinks of as the official story for month end.

Then when next month rolls around, the month reports will be low by the transactions that went in that month with dates of the prior month.

We have a company rule that needs to be restated occasionally. Thou shalt not back date transactions unless accounting and IT approve of special circumstances. (In other words they know about it.) We have not been as rigorously beating the drums about future dates on transactions, and as far as I can tell, all such input is by mistake. I am not referring to when orders are due, but when the transaction allegedly occurred.

What you need to understand here is that BPCS permits the user to key in any date they please, it just defaults to today. So if someone makes a mistake, and keys in Dec 2004 when they meant to do Dec 2003, or key in Jan 2003 when they meant to do Jan 2004, BPCS lets them ... it is a valid date after all. Now what BPCS financials does with that input might not be valid for you.

3. If we execute month end close on Feb. 5 2004 with still pending January
accounts but no transactions transpired whether inventory/financial done in
February, will it be reflected on January or February Book.

BPCS uses the DATE of transactions that people post, vs. your FISCAL CALENDAR to determine what fiscal period the transactions are supposed to go into. If that is a period prior to current fiscal month, and it is still open, and if accounting is still running various posts to that period, then BPCS will pick up and post the stuff.

As an exercise, to those who have been asleep on these nuances, I suggest you take a look at your GL files of unposted transactions, and run a query of what is in there for dates that are outside what is currently open fiscal periods. If you are anything like us, you will find a bunch of unposted transactions for fiscal periods long since closed, and a scattering of transactions way in the future for fiscal periods that do not exist yet.

- Al Macintyre http://www.ryze.com/go/Al9Mac Find BPCS Documentation Suppliers http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/