Re: GXR & GLH

You are facing two different issues :

GLH is the history of general ledger journal entries and cannot be deleted like
that.
Perhaps you may distinct two categories of records : LH record and LS records.
LH records ARE the generale ledger.
LS records are only detailled records of aggregated journal entries for memory
purposes, and may be deleted if your accounting peoples allow it (carefull :
deleting those records will prevent you for reconciliation of subsystem and
general ledger).

To avoid to many records in this GLH file (or table as you call them in Unix),
you should perhaps set up your inventory accounts or journal code with the
summary without detail flag on. Thus you will drop a little the number of
records, the detail history of inventoty transaction beeing stored in ITH.


GXR : this is the link between the general ledger and the subsystem. It is
required for reconciliation purposes and drill down capabilities.
Once your accounting peoples are done with the monthly and yearly
reconciliation, and if they agree to loose the drill down capabilities, you may
delete the previous year. A good trick is to feed the reference fields of the
journal entry with adequat value (customer number, invoice references...), so
you keep nevertheless the subsystem reference, although you clear GXR.
If you use multi sequences event, you may find in GXR non usefull datas (check
the ledger). Those may be deleted.

Be sure you have no specific developpment using thoses files.

To conclude : datas are required, there is no way to clear the files (tables)
but they may be deleted through SQL after a while if your database is Ok and
declare so by the accountants.
Be aware that you need backup for auditor's verification and fiscal as well.
And take into account your add ons and work around to BPCS as well
(datawarehouses, ....).

I hope this helps.

Michel  MAUREL




Mark Curtis wrote:

> 6.0.04  HP-UX / Informix
>
> Folks,
>
> About 1/3rd of my total dB space (i.e. 6Gb of 18Gb) is taken up by two
> tables, GXR & GLH and I have been informed by SSA that there are no purge
> programs with BPCS for these tables.
>
> We have been running for around 13 months on 6.0.04 and whilst I can still
> accommodate these tables I need to put into place a long term strategy to
> ensure that these tables do not just continue to grow.
>
> Has anyone out there had similar problems with these tables ?  If so did you
> get a solution out of SSA or write your own SQL to purge data from them ?
>
> Any help or assistance would be much appreciated.
>
> Regards
> Mark Curtis
> IT Director
> Hafele U.K. Limited
> Office : +44 (0)1788 542020
> Direct : +44 (0)1788 548557
> Fax    : +44 (0)1788 548599
> Mobile : +44 (0)973 121135
> email  : mailto:mark.curtis@hafele.co.uk
> Web    : http://www.hafele.co.uk
>
> +---
> | 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
> +---

--
Toute  information contenue dans ce courrier electronique est
confidentielle et destinée uniquement à l'usage de la ou des personnes
ou entités spécifiées en destinataires ou autorisées. Si le lecteur de
ce message ne figure pas dans la liste des destinataires, il est porté à
son attention que tout usage, copie ou diffusion de ces informations est
strictement interdite.


+---
| 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
+---