Re: BPCS archiving -- BPCS-L

Hans,

Did you do this with the Small Blue Archiving software (an early version was
sold to Impress in France last year), or by manually deleting the records?
Impress are entitled to the latest version of the software as they have paid
for it, however Impress France have not  so far replied to our e-mails
offering it to them...

best regards,

Clare

Clare Holtham
Director, Small Blue Ltd - Archiving for BPCS
Web: www.smallblue.co.uk
IBM Certified AS/400 Systems Professional
E-Mail: Clare.Holtham@xxxxxxxxxxxxxx
Mobile: +44 (0)7960 665958
----- Original Message -----
From: <Hans.G.LOEF@xxxxxxxxxxxxxxxx>
To: <bpcs-l@xxxxxxxxxxxx>
Sent: Wednesday, June 04, 2003 5:20 PM
Subject: Re: BPCS-L Digest, Vol 1, Issue 644


>
>
>
>
> To Steve:
>
> Concerning historization of BPCS files we BPCS V 6.1. GA archived the
> following files: ECH, ECL, ECS, ECT, ESN, EIL, IPP, LLH, LLL, LLM, LLX,
> PDA.
>
> Rgds
>
> Hans-Georg Loef
> Impress Metal Packaging
> Central MIS
>
>
>
>
>
> bpcs-l-request@xxxxxxxxxxxx@midrange.com on 03.06.2003 20:12:51
>
> Please respond to bpcs-l@xxxxxxxxxxxx
>
> Sent by:    bpcs-l-bounces@xxxxxxxxxxxx
>
>
> To:    bpcs-l@xxxxxxxxxxxx
> cc:
> Subject:    BPCS-L Digest, Vol 1, Issue 644
>
>
>
> Send BPCS-L mailing list submissions to
>  bpcs-l@xxxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
>  http://lists.midrange.com/mailman/listinfo/bpcs-l
> or, via email, send a message with subject or body 'help' to
>  bpcs-l-request@xxxxxxxxxxxx
>
> You can reach the person managing the list at
>  bpcs-l-owner@xxxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of BPCS-L digest..."
>
>
> Today's Topics:
>
>    1. INV900 Oops (Al Mac)
>    2. RE: INV900 Oops (DeeDee Virgei)
>    3. Re: Deleting BPCS Customer records (RCM) - mixed mode version
>       6.04heavily modified (Al Mac)
>
>
> ----------------------------------------------------------------------
>
> message: 1
> date: Tue, 03 Jun 2003 12:15:12 -0500
> from: Al Mac <macwheel99@xxxxxxxxxxx>
> subject: INV900 Oops
>
> I am looking for suggestions while I struggle looking into some things.
> We are BPCS 405 CD
>
> I work nites and this info was as of what I figured out last nite
>
> Last Friday night most of the EOM was done, finishing up Saturday
> Morning.  I was long gone from the system.  Monday I was informed that
> something went wrong with INV900, know not what exactly.  The hope is that
> we can do June transactions almost like normal, then some recovery effort
> in the next EOM.  What I expect is that there will be NO May totals in the
> system except any reports accounting ran from MTD perspective and from
> files not affected by INV900, so the total sales for JUNE will really be
> MAY plus JUNE combined, and some files will be out of sync with each other
> for MAY JUNE.  Thus it might NOT be SMART for me to run the weekly files
> REORG until I have a better grasp of what files went thru EOM Ok, and
which
> will have a double month next EOM..
>
> This means the new sales reports that I developed last month with Y"all
> help should be considered as trash for now, and the AMP TYCO report will
> not be available for another month.  AMP TYCO is one of our vendors ... we
> send them a monthly report on how much raw materials we ordered on behalf
> of each of our customers, in which the data is computed using combination
> of BOM and Sales History.  Well I consider Sales History to be the same
> value as GARBAGE until I figure out what is Ok.
>
> WRKOBJ INV90* gets at a list of related INV900 major steps
> 8 (eight) enter scroll second screen shows DATE last time that program was
> used
>
> The following were last used end of May (last Friday)
> INV900PM (prompt screen)
> INV900C (Main CL from menu)
> INV903 (I think this is involved in the cycle count clean up at the start
> of INV900)
> INV903O (report associated with cycle count distraction at very beginning
> of INV900C)
>
> The following were last used end of April (a month ago)
> INV900 (main RPG program)
> INV904 (Rel-2 version)
> INV901C (I think this runs close to the end of the whole operation)
>
> According to SSARUN03, the files that INV900 messes with are
> IWM IWI ILI RCM SSM SSH SSD ITH and I know that is not a complete story
and
> that we do use ACR900, but I have lots of clues to explore
>
> Some of these files are updated during the course of daily transactions,
> while some only EOM hits.  I happen to have been messing with RCM Friday
> before EOM due to placement of customers on a report sequenced by customer
> name.
>
> I know from past experience that YTH file contains copy of ITH
transactions
> cleared off in the previous EOM.  Our YTH file is empty of records (DSPFD
> list members ... the date not help me ... my speculation is that when a
> file is cleared, that does not alter the date of last change, it is only
> adding or changing records that updates that).  We used to write off last
> month records to tape, not do that any more, I not remember when that
> policy changed ... that could be why January 2003 is date of last change
of
> YTH.
>
> I have some software off GO CMDSCDE that I not check every week, but from
> it I see that our ITH Inventory History file had
> 1.330 million records as of a week before EOM
> 1.347 million records as of late afternoon of EOM (before final shipping
> and some other transactions) = 17 thousand added in the 4 day week
> 1.347 million records (about 500 more) first thing Monday morning
> 1.350 million records Monday evening (3 thousand added during Monday)
> This tells me that the INV900 did not clear off the records older than our
> SYS800 system parameters (should be 365 days ... I still need to check to
> make sure no one mucked with that) so I know INV900 did not get to
whatever
> step where that happens
> It also tells me we have not lost anything valuable records wise
>
> There are some files updated by EOM that I not sure if they supposed to
get
> updated each day ... some of them supposed to have MTD data like last
> shipment, but I not know when that data goes in
> SSD & SSH Sales History files last updated last Friday EOM
>
> Now unless something other than INV900 updates them, this tells me that
> INV900 successfully got through at least part of a step ... but I still
> need to look at MTD, month 01, etc.
>
> I expect these files to change every day and they were in fact last
updated
> Monday June-2
> IIM Item Master
> ILI Inventory by Item Warehouse Location
> IWI Inventory by Item Warehouse
> RCM Customer Master
>
> I am not sure what all updates these  ... they were last updated Monday
> June 2
> IWM Item Warehouse Master
> SSM Salesperson master
>
> I ran a list DSPFD all files when last changed.  I only looking at some of
> them.
> In most cases the date last used is same as date last changed.
>
> Some weird ... RMAs last changed Mon June-6 but last used Fri May-30
> When I not regularly look at some things, I not know what is (ab)normal
>
> The menu launches INV900C whose CL uses a lot of soft coding, so it not
> obvious what job calls what job.
> -
> Al Macintyre
> BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
>
> >From: Al Mac <macwheel99@xxxxxxxxxxx>
>
> Forwarded from the office
>
>
> >Will do.
> >
> >You may recall that the reason we not want people doing BPCS transactions
> >on the weekend of EOM is that with an EOM date of SATURDAY, that if you
> >finish FRIDAY nite then someone posts transactions DATED in the fiscal
> >period you just closed, BPCS treats those transactions as if they had in
> >fact gone in the month that you just closed ... altering opening balance
> >... which Mike discovered by seeing that Opening Balance of CSTOPS had
> >changed during course of month.
>
> I checked ITH date ranges ... nothing got posted dated Saturday or Sunday.
>
> >But what you describing sounds OPPOSITE scenario.
> >
> >There is another wrinkle ... if someone enters transactions LAST MONTH
but
> >DATES them into the FUTURE, BPCS does not include those transactions in
> >the EOM.  We have had a scattering of that kind of scenario in the past,
> >and I did not know all the implications of such activity.  Using a wrong
> >date on BPCS transactions can occur through human error, where the user
> >not realize what they doing, and they can occur through human
> >misunderstanding of the role of date in BPCS transactions.
> >
> >INV900 normally takes SEVERAL HOURS to do its thing, but Mike did have a
> >change in procedure a few months ago which would have somewhat lowered
the
> >run time, but I still expected it to take several hours.  I did ask him
to
> >track how long various tasks take, and update his check list.  It may be
> >that some things have changed significantly in time duration without his
> >check list reflecting that.
> >
> >It is not just inventory opening balance that INV900 updates, also stuff
> >related to sales history files.
> >
> >What I fear is that the job ended normally in IBM terms but abnormally in
> >BPCS terms such that there might not be an IBM JOBLOG with clues.
>
> There was no job log for me to examine.
>
> >>Al,
> >>
> >>
> >>Mike had mentioned the month end close on INV900 ran quickly.  I don't
> >>believe it ran correctly.  Items show activity in the MTD totals now
when
> >>they should only show an opening balance.
> >>
> >>
> >>I don't think this will have an impact on operations, but it might
create
> >>problems at the end of this month.  Please investigate this when you get
> in.
> >>
> >>
> >>Thank you,
> >>
> >>Tim
> >>
> >>  -
> >
> >-
> >Al Macintyre
> >BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
> >Find BPCS Documentation Suppliers
>
>http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.htmlFrom
>  KASP6281@xxxxxxx Tue Jun  3 13:07:00 2003
> Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38])
>  by linux.midrange.com (8.12.8/8.12.8) with ESMTP id h53I6g9N025243
>  for <bpcs-l@xxxxxxxxxxxx>; Tue, 3 Jun 2003 13:06:56 -0500
> Received: from KASP6281@xxxxxxx
>  by imo-d06.mx.aol.com (mail_out_v36.3.) id i.1e3.a3bfd58 (25305)
>  for <bpcs-l@xxxxxxxxxxxx>; Tue, 3 Jun 2003 14:06:17 -0400 (EDT)
> From: KASP6281@xxxxxxx
> Message-ID: <1e3.a3bfd58.2c0e3d99@xxxxxxx>
> Date: Tue, 3 Jun 2003 14:06:17 EDT
> To: bpcs-l@xxxxxxxxxxxx
> MIME-Version: 1.0
> X-Mailer: 8.0 for Windows sub 6011
> X-MailScanner: Clean
> Content-Type: text/plain; charset="US-ASCII"
> Content-Transfer-Encoding: 7bit
> X-Content-Filtered-By: Mailman/MimeDel 2.1.2+
> Subject: Re: Deleting BPCS Customer records (RCM) - mixed mode version
6.04
>  heavily mo...
> X-BeenThere: bpcs-l@xxxxxxxxxxxx
> X-Mailman-Version: 2.1.2+
> Precedence: list
> Reply-To: SSA's BPCS ERP System <bpcs-l@xxxxxxxxxxxx>
> List-Id: SSA's BPCS ERP System  <bpcs-l.midrange.com>
> List-Unsubscribe: <http://lists.midrange.com/mailman/listinfo/bpcs-l>,
>  <mailto:bpcs-l-request@xxxxxxxxxxxx?subject=unsubscribe>
> List-Archive: <http://archive.midrange.com/bpcs-l>
> List-Post: <mailto:bpcs-l@xxxxxxxxxxxx>
> List-Help: <mailto:bpcs-l-request@xxxxxxxxxxxx?subject=help>
> List-Subscribe: <http://lists.midrange.com/mailman/listinfo/bpcs-l>,
>  <mailto:bpcs-l-request@xxxxxxxxxxxx?subject=subscribe>
>
> Hi Steve.
>
> I would guess that from your comments you have already looked at any
custom
> files that you have created for your "heavy modified" version.  Another
> thought
> would be the quote and RMA files if those are used by your company.  You
> may
> have included those in your order and sales history comments, but I
thought
> that I would explicitly state that.
>
> Do you use item substitution?  There is a file with customer number values
> available as an input called IAI.
>
> Are you using and Promotions and Deals and need to address the files such
> as
> PDB and PDM?
>
> Do you use planning bills that can also be tied to customers?  The files
> such
> as KAO and KPR would need to be investigated.
>
> Do you capture tax data?  There are BPCS tax files such as RTX that need
to
> be accounted for.  Perhaps you use another package like Vertex that needs
> to be
> updated as well.
>
> Do you use OLM?  There may be some transaction files such as LLL, LLH.
LLX,
> AND LLM for the transactions that you have created.  There also may be
some
> notes in the LNT file.  Also there are other cross reference and master
> files
> like LEX and LPS that may have been used.
>
> Since you are in the US, I would guess that you are not using Draft (Cash)
> Management that also has customer references, but if you are, these would
> need
> to be considered.
>
> Also, I would say that you addressed A/R, but does that explicitly include
> ARP?  There are also files in that area that would need to be addressed.
> These
> would include RMX and RND.
>
> As for the archiving of data, I would presume that if you reuse the
> customer
> numbers that the metadata has references to a date range or some other
> identifier if you are going to keep multiple years data for analysis
> whether for
> branding or just trend analysis.
>
> This is all that I can think about right now.
>
> Good luck.
> John Kasper
> JD Kasper & Associates, Inc.
> KASP6281@xxxxxxx
>
> ------------------------------
>
> message: 2
> date: Tue, 3 Jun 2003 14:14:00 -0400
> from: DeeDee Virgei <DeeDee.Virgei@xxxxxxxxxxxxxx>
> subject: RE: INV900 Oops
>
> Hi,
>
> We are on 4.05 CD...  When we run inventory M/E (INV900), INV901C then
gets
> submitted to batch...  Since your INV901C program wasn't used this month
> and
> from the last dates used on your other programs, it looks like during
> submission of your M/E,  the options on the 2nd of screen of INV900 were
> set
> as follows:
> INV900-02 ...
>           Print all Outstanding Cycle Counts        Y      (Y or N)
>
>           Continue with Month End Procedure      N      (Y or N)
>
>
> These are the defaults setting; we have to change them every month to N
> then
> Y...  This being the case, the impact would be pretty much the same as not
> running INV900 at all.  We once forgot to run INV900; ended up running it
> the next evening and had to make some adjustments to some of the
reports...
>
> Hope this helps.
>
>
> DeeDee Virgei
> Nelson Stud Welding, Inc.
> 7900 West Ridge Rd
> Elyria, OH 44036
>
>  -----Original Message-----
> From:       Al Mac [mailto:macwheel99@xxxxxxxxxxx]
> Sent: Tuesday, June 03, 2003 1:15 PM
> To:   BPCS Users Discussion Group
> Subject:    INV900 Oops
>
> I am looking for suggestions while I struggle looking into some things.
> We are BPCS 405 CD
>
> I work nites and this info was as of what I figured out last nite
>
> Last Friday night most of the EOM was done, finishing up Saturday
> Morning.  I was long gone from the system.  Monday I was informed that
> something went wrong with INV900, know not what exactly.  The hope is that
> we can do June transactions almost like normal, then some recovery effort
> in the next EOM.  What I expect is that there will be NO May totals in the
> system except any reports accounting ran from MTD perspective and from
> files not affected by INV900, so the total sales for JUNE will really be
> MAY plus JUNE combined, and some files will be out of sync with each other
> for MAY JUNE.  Thus it might NOT be SMART for me to run the weekly files
> REORG until I have a better grasp of what files went thru EOM Ok, and
which
> will have a double month next EOM..
>
> This means the new sales reports that I developed last month with Y"all
> help should be considered as trash for now, and the AMP TYCO report will
> not be available for another month.  AMP TYCO is one of our vendors ... we
> send them a monthly report on how much raw materials we ordered on behalf
> of each of our customers, in which the data is computed using combination
> of BOM and Sales History.  Well I consider Sales History to be the same
> value as GARBAGE until I figure out what is Ok.
>
> WRKOBJ INV90* gets at a list of related INV900 major steps
> 8 (eight) enter scroll second screen shows DATE last time that program was
> used
>
> The following were last used end of May (last Friday)
> INV900PM (prompt screen)
> INV900C (Main CL from menu)
> INV903 (I think this is involved in the cycle count clean up at the start
> of INV900)
> INV903O (report associated with cycle count distraction at very beginning
> of INV900C)
>
> The following were last used end of April (a month ago)
> INV900 (main RPG program)
> INV904 (Rel-2 version)
> INV901C (I think this runs close to the end of the whole operation)
>
> According to SSARUN03, the files that INV900 messes with are
>  IWM IWI ILI RCM SSM SSH SSD ITH and I know that is not a complete story
>  and
> that we do use ACR900, but I have lots of clues to explore
>
> Some of these files are updated during the course of daily transactions,
> while some only EOM hits.  I happen to have been messing with RCM Friday
> before EOM due to placement of customers on a report sequenced by customer
> name.
>
> I know from past experience that YTH file contains copy of ITH
transactions
> cleared off in the previous EOM.  Our YTH file is empty of records (DSPFD
> list members ... the date not help me ... my speculation is that when a
> file is cleared, that does not alter the date of last change, it is only
> adding or changing records that updates that).  We used to write off last
> month records to tape, not do that any more, I not remember when that
> policy changed ... that could be why January 2003 is date of last change
of
> YTH.
>
> I have some software off GO CMDSCDE that I not check every week, but from
> it I see that our ITH Inventory History file had
> 1.330 million records as of a week before EOM
> 1.347 million records as of late afternoon of EOM (before final shipping
> and some other transactions) = 17 thousand added in the 4 day week
> 1.347 million records (about 500 more) first thing Monday morning
> 1.350 million records Monday evening (3 thousand added during Monday)
> This tells me that the INV900 did not clear off the records older than our
> SYS800 system parameters (should be 365 days ... I still need to check to
> make sure no one mucked with that) so I know INV900 did not get to
whatever
> step where that happens
> It also tells me we have not lost anything valuable records wise
>
> There are some files updated by EOM that I not sure if they supposed to
get
> updated each day ... some of them supposed to have MTD data like last
> shipment, but I not know when that data goes in
> SSD & SSH Sales History files last updated last Friday EOM
>
> Now unless something other than INV900 updates them, this tells me that
> INV900 successfully got through at least part of a step ... but I still
> need to look at MTD, month 01, etc.
>
> I expect these files to change every day and they were in fact last
updated
> Monday June-2
> IIM Item Master
> ILI Inventory by Item Warehouse Location
> IWI Inventory by Item Warehouse
> RCM Customer Master
>
> I am not sure what all updates these  ... they were last updated Monday
> June
> 2
> IWM Item Warehouse Master
> SSM Salesperson master
>
> I ran a list DSPFD all files when last changed.  I only looking at some of
> them.
> In most cases the date last used is same as date last changed.
>
> Some weird ... RMAs last changed Mon June-6 but last used Fri May-30
> When I not regularly look at some things, I not know what is (ab)normal
>
> The menu launches INV900C whose CL uses a lot of soft coding, so it not
> obvious what job calls what job.
> -
> Al Macintyre
> BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
>
> >From: Al Mac <macwheel99@xxxxxxxxxxx>
>
> Forwarded from the office
>
>
> >Will do.
> >
> >You may recall that the reason we not want people doing BPCS transactions
> >on the weekend of EOM is that with an EOM date of SATURDAY, that if you
> >finish FRIDAY nite then someone posts transactions DATED in the fiscal
> >period you just closed, BPCS treats those transactions as if they had in
> >fact gone in the month that you just closed ... altering opening balance
> >... which Mike discovered by seeing that Opening Balance of CSTOPS had
> >changed during course of month.
>
> I checked ITH date ranges ... nothing got posted dated Saturday or Sunday.
>
> >But what you describing sounds OPPOSITE scenario.
> >
> >There is another wrinkle ... if someone enters transactions LAST MONTH
but
> >DATES them into the FUTURE, BPCS does not include those transactions in
> >the EOM.  We have had a scattering of that kind of scenario in the past,
> >and I did not know all the implications of such activity.  Using a wrong
> >date on BPCS transactions can occur through human error, where the user
> >not realize what they doing, and they can occur through human
> >misunderstanding of the role of date in BPCS transactions.
> >
> >INV900 normally takes SEVERAL HOURS to do its thing, but Mike did have a
> >change in procedure a few months ago which would have somewhat lowered
the
> >run time, but I still expected it to take several hours.  I did ask him
to
> >track how long various tasks take, and update his check list.  It may be
> >that some things have changed significantly in time duration without his
> >check list reflecting that.
> >
> >It is not just inventory opening balance that INV900 updates, also stuff
> >related to sales history files.
> >
> >What I fear is that the job ended normally in IBM terms but abnormally in
> >BPCS terms such that there might not be an IBM JOBLOG with clues.
>
> There was no job log for me to examine.
>
> >>Al,
> >>
> >>
> >>Mike had mentioned the month end close on INV900 ran quickly.  I don't
> >>believe it ran correctly.  Items show activity in the MTD totals now
when
> >>they should only show an opening balance.
> >>
> >>
> >>I don't think this will have an impact on operations, but it might
create
> >>problems at the end of this month.  Please investigate this when you get
> in.
> >>
> >>
> >>Thank you,
> >>
> >>Tim
> >>
> >>  -
> >
> >-
> >Al Macintyre
> >BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
> >Find BPCS Documentation Suppliers
> >http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
> _______________________________________________
> 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.
>
> ------------------------------
>
> message: 3
> date: Tue, 03 Jun 2003 13:04:15 -0500
> from: Al Mac <macwheel99@xxxxxxxxxxx>
> subject: Re: Deleting BPCS Customer records (RCM) - mixed mode version
>  6.04heavily modified
>
> We on 405 CD mixed mode so you may have some files we not have.
> We heavily modified so we have added some files
> We not using all applications so there may be files we not see that
> relevant to you
> Forecasting, Performance
>
> Look at ESH ESL SSH SSD
> Look at members other than *FIRST in the Customer Order files EC*
>
> It might be useful to review how many files have more than one member,
> related to this topic (most excess related to work stations that not exist
> any more)
> You can get at that with a DSPFD dump to Quer/400 list
>
> Be careful about partial deletes of some records from files.
> Example ... if a file has sequence #s 1 2 3 4 5 for individual records of
a
> related scenario and you delete # 3, a program that reads in sequence
might
> never reach 4 5.
>
> We do mass wipes of several files (records coded for deletion) each year,
> but I wait until I am told that the auditors are finished for the prior
> year before I implement this, just in case they would like to look at some
> of that data that is coded for deletion.
>
> When I don't have anything more important to work on, I delve into file
> clean up (negative costs are probably the most urgent for me right now),
> but have not had much time for that in eons.
>
> We have had problems with ORDERS
> We run out of numbers and return to zero
> There is history still out there on numbers that get reused
> The new order comes pre-supplied (contaminated) with all kinds of stuff
> from the last time we used that order #
>
> We have had problems with ITEMS
> We delete the item ... that item is still in history all over the place.
> We reassign the item ... it comes pre-supplied with irrelevant data that
> confuses people
>
> We have had problems with G/L batches trying to use same Journal as
already
> exists.
>
> We have had problems with REUSABLE VENDOR #s
> Our range of #s for one time checks is a bit small for a year's worth.
>
> I have a program SYFILCOUNT which takes DSPFD dump of all BPCS file
> statistics and correlates information, alphabetically by file, to help me
> prioritize what needs work.
>
> With SQL (the program is not home with me right now, just a copy of the
> report from last nite, so I can't give you the precise code right now)
> I can count how many records in various files have an
> item that is not in IIM
> customer not in RCM
> vendor not in AVM
> etc. to help guide me which files need which kinds of cleanup
>
> I have lots of files I plan to add this kind of thing to
> Many files extract date range ... oldest record is nice to know
>
> Ask your various departments how long they need various kinds of data ...
> some departments only interested in what happened yesterday, some want to
> be able to look at a year's data, some want last 2 years sales price
> history but no other datums that far back
>
> Check those associated with A/R
> Check those associated with history of stuff associated with customers -
> shipments
> Do you have old quotes, RMAs? ... look at EC file members OTHER than
*FIRST
>
> When does stuff go away from sales history files?
> The oldest dates in our SSD and SSH files date back to when we converted
> into BPCS 405 CD
>
> There are some files that BPCS never purges ... ES*
> ESN Notes can exist on Orders, Customers, RMA, Ship-To that no longer
exist
>
> Do you have customer types no longer used?
> We have some item classes for particular kinds of customer business
> (associated with ECS special charges)
>
> When we close out business with a customer, we have to deal with the fact
> that the end items on those customers had an estimated annual usage, which
> when factored into the BOM, meant we storing safety stock on raw materials
> used on that customer needs, so we have mechanisms for identifying what
> changes need to be made to our items retention.
>
> >Hi Steve,
> >
> >Be very careful - all references to those customers would need to be
> >removed - you know how upset BPCS gets otherwise! We are working on an
> >archiving program for customers right now, we already have options for
> most
> >of the other BPCS areas - orders, inventory, etc. If you want to work
with
> >us on this we'd be more than happy. It looks as though you are based in
> the
> >US, in which case Unbeaten Path are selling our BPCS Archiving tool over
> >there now as 'Locksmith'. Let me know if you need any more info,
> >
> >hope this helps,
> >
> >Clare
> >
> >Clare Holtham
> >Director, Small Blue Ltd - Archiving for BPCS
> >Web: www.smallblue.co.uk
> >IBM Certified AS/400 Systems Professional
> >E-Mail: Clare.Holtham@xxxxxxxxxxxxxx
> >Mobile: +44 (0)7960 665958
>
>
>
> >----- Original Message -----
> >From: "Steve Segerstrom"
> >Sent: Tuesday, June 03, 2003 5:13 PM
> >Subject: Deleting BPCS Customer records (RCM) - mixed mode version
> >6.04heavily modified
> >
> >
> > > We are  mixed mode version 6.04 heavily modified
> > >
> > > We are running out of customer number ranges and need to clean up some
> of
> >our old customers (I doubt Montgomery Wards, Handy Andy, etc will be
> back).
> > >
> > > I have a list of customers with no activity for over 4 years ... So I
> >don't really have problems with deleting things that still have activity
> in
> >AR, Sales History, etc. Also have another method to archive.
> > >
> > > Anyway - I am looking at deleting records from ESP (special price),
EIX
> >(customer part xref), ESN (notes) RCM and EST. AR and CDM are taken care
> of.
> >These are not EDI customers....
> > >
> > > Can anyone think of any other files I should look at?
> > >
> > > Thanks.
> > > Steve "trying to be the computer janitor"
> > > Intermatic Inc
> > > (815) 675-7469
> > >
> > >
> > > _______________________________________________
> > > 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.
> > >
> > >
> >
> >_______________________________________________
> >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.
>
> -
> Al Macintyre (macwheel99@xxxxxxxxxxx via Eudora)
> Al's thoughts http://radio.weblogs.com/0107846/
> See Al at http://www.ryze.com/go/Al9Mac
> Cure cancer. http://members.ud.com/about/
> Emergency notification (homeland, weather, etc.)
> http://www.emergencyemail.org/
>
>
>
> ------------------------------
>
> _______________________________________________
> This is the SSA's BPCS ERP System (BPCS-L) digest 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.
>
>
>
> End of BPCS-L Digest, Vol 1, Issue 644
>  **************************************
> The  information  contained  in this e-mail and any attachments is
strictly
>          confidential  and  may be legally privileged. It is intended
> solely for the use of the individual or entity to whom it is addressed. If
>          you are not the named  addressee,  you are hereby notified that
> it is prohibited and may be unlawful  to disclose, copy, distribute,
store,
>          copy the information in any medium or usage for another purpose.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>


----------------------------------------------------------------------------
----


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