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


  • Subject: Re: The end of the month
  • From: MacWheel99@xxxxxxx
  • Date: Wed, 27 Oct 1999 03:23:16 EDT

>From Al Macintyre

Thanks for stimulating info to consider ... our end month process is totally 
different from yours & I am wondering what if anything we might be doing 
wrong.

We are on BPCS 405 CD of AS/436 V4 R3 mixed mode using modules ACP ACR BIL 
BOM CAP CST DOC GLD INV JIT MPS MRP ORD PUR SFC SYS

We are studying CIM but not yet using it.
We had not intended to use DRP but thanks to SSA help line found we had to do 
a nibble with it for managing re-supply orders.
We do not have ROBOT, AS/Set, or TAA TOOLS.

We load JOBQ with separate steps so that if anything bombs we can freeze JOBQ 
on what has not started yet until we resolve the earlier bombed step.

>  From:    barlova@biotika.sk (Barlova)
>  
>  We have BPCS v.6.04. We would want to run the month closing in the night by
>  command SBMJOB. At the month closing runs these programs: 
>  1. INV920
>  2. ACR900
>  3. INV903
>  4. PUR900
>  5. ACP900
>  We know to start the first program "INV920" but we don´t know to start next
>  programs because we don´t have source programs. So we don´t know which
>  parameters we have to pass to these next programs. All programs could run
>  in the BATCH. If someone has experiences with the month closing, send us
>  your advices. Thanks.    

Earlier BPCS_L thread said that V6 is not supposed to have source programs - 
instead AS/Set answers some questions.

Every evening steps that are run after weekly re-org on the night of weekly 
re-org
MRP500 MRP600 individually for every facility.

When it is an end-of-month nite, the MRP500 & 600 are LAST things run after 
EOM check list completion.

Two nites a week CST600 which we believe contains CST500 & CST510 built in, 
and CAP600 after MRP & CAP500 between MRPs
One nite a week CST900 before the MRP

Our weekly re-org steps.
We use a custom menu with steps in the sequence needed to run.
Query lists # hard deleted records per file times record length from DSPFD & 
if the total is up to 2 meg wasted disk space we run SYS120 on all files.
Query lists suspected bogus information that may need fixing, such as active 
ECL records with no corresponding active ECH records & if there are any, we 
use a custom program to soft delete the orphans, after getting the reference 
list for people to check out.
INV972 SFC990 ORD990
Copies of the ORD990 & ORD991 reports are distributed to sales ... some will 
be screw-ups they already know about, but scenarios new to them they check 
out to see if customer order needs to be re-entered
SYS990 INV971 ACR970 ACR972 MRP990 BOM900

All of this goes pretty fast except SYS120 ... stay off other sessions & file 
access for about an hour while it runs & BOM900 will also take an hour to 
execute.

Because of the updates run regularly each week, much of that is not deemed 
neccessary during end-of-month.

End-of-year & when we have physical inventory, that complicates end-of-month, 
but normal end-of-month consists of the following updates ... with a bunch of 
Query reports & vanilla BPCS reports thrown in at various stages.

ACP900 ACR900 INV920 INV900 INV970 
SYS800 to update last month end close date - I could not imagine putting that 
on a JOBQ
PUR900 GLD540 GLD520 GLD530 GLD510 GLD105 CAP900 JIT900

> From: cipe@club-internet.fr (Francois Charbon)
>  
>  This is a suggestion :
>  
>  1. Daily batch procedure (if you do not use interactive processes)
>  1.1. INV920
>  1.2. BIL500
>  1.3. CDM
>  Comments : INV920 and BIL500 (BIL540) have an impact on CEA. It is 
suggested to make daily controls.

We do not use CDM.  We do BIL500 late every day when shipping is completed 
... everyone working same time zone.  Is there a reason you run INV920 daily? 
... We run ours monthly because accounting likes to look at monthly reports, 
not interested in "month so far."

>  2. Intermittently purges
>  2.1. CIMPATH
>  2.2. JIT900
>  2.3. ACP900
>  Comments :
>  JIT900 : can be run as far as you want. It sets up some files to 0 (fields 
> used in JIT300)
>  ACP900 : although this program is qualified of "Monthly closing", it does 
> not affect any monthly result. This program is to purge invoices and 
associated
>  payments of ACP.C

Does it matter which sequence JIT900 ACP900 get run in or where in the flow?  
Notice ours totally different placement than yours.  Is your 1 2 3 4 counting 
a listing of what needs to be done, or is the sequence important?

>  3. Weekly closing
>  CAP900
>  Comments : CAP900 closes the week for the planning established using CAP. 
It 
> is suggested to run it each week.

Is it advisable to run CAP500 CAP600 after CAP900 but before next month 
activity?
  
>  4. Monthly closing
>  4.1 Daily closing (INV920, BIL)
>  4.2 FOR
>  4.3. Closing of Mfg orders :
>  4.3.1. SFC900
>  4.3.2  CST900
>  4.3.2.1 CST510
>  4.3.2.2 CST910
>  4.3.2.3 CST900
>  4.3.3 PRF
>  4.4 PUR900
>  4.5 CDM900
>  4.6 ACR900
>  4.7 INV
>  4.8 MLT910 et MLT920
>  4.9 CEA

>  Comments :
>  => The daily closing should be done before to start the monthly closing.
>  => FOR900 : Purge and record of actual, forecast of the period and then 
roll 
> to the previous period. (refer to FOR100).
>  Suggestion : It seems necessary to complete the FOR900 with the followings 
(
> to run AFTER FOR900) :
>  a) FOR910 : update of previous period (use ITH to update JFB)
>  b) FOR915 : AFTER FOR900 (use ECL to update JFB)
>  c) FOR920 : Update the period with the forecast. To be run AFTER FOR900
>  d) FOR930 : AFTER FOR910/915/920 (update JFC and JFI from JFB)
>  Note : FOR020 updateq also JFC et JFI but is not limited to the current 
> period.  It updates also history and forecasts.
>  Closings of FOR are without links with other moduls. However, if you use 
SPM,
>  then FOR920 and FOR930 cannot be run
>  Also, be sure that the history form MPS, MRP and ORD are not purged before 
> to run FOR (otherwise the files will be empty).

I am unaware of any history from MPS & MRP other than planned orders.

Our System Parameters say to keep histories active no more than one year, but 
we are finding records in ECL that are more than one year after done with.  
We use blanket orders heavily in which customer wants X quantity this week 
next week almost in perpetuity, then after shipping invoicing those order 
lines are now soft deleted ... when do they go away?  Do they hang out there 
until a year after we close the ECH order?  Currently we have 16,000 records 
in our ECL of which 4,000 are active & 12,000 are soft deleted.  What 
end-of-fiscal step makes the old ones leave our system?  Are we missing a 
step like BIL900?

>  => SFC900 (closing of shop orders).
>  This program cannot be run if you use CST900.
>  => CST900
>  The followings should be run :
>  a)CST510 : allocations (must be run BEFORE CST900).

Is CST510 contained within CST600 so CST600 should be run before CST900 ... 
always ... should we always run CST600 before running CST900?

>  b)CST910 : CEA.
>  c)CST900 : update CMF, closing of shop orders (and purge).
>  It is not necessary to run CST910 (if you do not generate accounting 
entries)
> .
>  If you run it, it should be run AFTER CST510 (because the program uses FLT;
>  this file is updated with CST510) and BEFORE CST900.
>  In theory, you should run CST900 whenever you want. But if you use CST510
>  (allocations) the program should be run at the end of the period.
>  => PRF
>  1)PRF900
>  2)SFC905
>  PRF900 : performance measurement. Must be run BEFORE SFC905 (save of labor 
tickets in case closing by SFC900 is done).

We run CST600 twice weekly (Tues/Thurs) rolling up standard costs, with the 
understanding that current shop order activity is not involved in this, that 
CST500 & CST510 are included in the flow ... are we mistaken about what is 
included & the notion that CST600 is independent of current production orders?

We normally run CST900 1-2 times a week (Wed/Fri) but since physical 
inventory is imminent in one facility, we've been doing it nitely for a while 
on that facility ... we drive our shop orders down to none in a facility for 
physical, then re-release based on the altered WIP reality.

Since CST900 accesses labor & inventory history, it might be advisable to 
complete CST900 before starting INV900 or SFC905.

>  => PUR
>  Suggestion : Run PUR210, PUR220, PUR240 before PUR900.
>  PUR 900 purges all the requisitions completed of the period. Update totals 
> of period and year-to-date and the ZAP (totals are recorded in HVH).
>  When you run PUR900, take care of the option which closes the receipts 
lines
>  (Do not use it if you 3W-match)
>  => CDM900 : updates ADP, DSO. Do not run CDM620 before CDM900. It is 
> included in the run.
>  => ACR900
>  Must be done only 1 time per month.
>  => INV
>  Suggestion :
>  It should be better if nobody works.

The user who launches INV900 also should be at a menu until it gets done, 
doing nothing else on BPCS.

>  Should be done normally before inventory counting.

If there is any unfinished cycle counting, end-month erases that.

If there is a physical inventory TAGS dump, INV900 recomputes opening balance 
for the month, then variance reports are generated, then the TAGS are dumped 
into the inventory.

>  Before INV903 is run, it is necessary to run INV920 (daily closing)
>  => MLT910 et MLT920 (Depending of your version).
>  
>  Sorry for my bad english.

I understand your English fine ... my questions are because your sequence is 
nothing like ours.

>  François CHARBON

Al Macintyre
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.