JamesV
28th November 2001, 06:39
Okay -- please do not laugh at me -- I am a lowly technical guy...
I am trying to understand the pros and cons of turning compression on for financial integration transactions. Given the cost in performance and disk space for non-compressed transactions, what is the real business case for keeping that level of detail.
I know that finance people love detail and hate to purge anything, but how much granular data is really required?
Thanks for the help,
Jim
MariaC
28th November 2001, 08:38
It all depends on the users of the system and what they want to see. I don't know of any sites that actually use compression for finance.
Neal Matthews
28th November 2001, 11:18
We handled this issue by archiving the transactions first.
When we then tried to compress in the archive company no records were removed. I think this was something to do with the way the compression session works as it only appears to compress records where the index keys are identical and in our set up that never ever happens.
However now these records are in the archive company that are a lot more managable and it should be easier to convince Finance that they don't need them. Hopefully we will be able to print them to file and purge them.
Be warned the session otfcor0217 will only run in the history company where the original company is a history company. I spoke to support about this and they told me to use tfgld4210m000 to attempt the compression.
We now use tfgld4210m000 followed by tfgld4220m000 which appears to shift a little more data.
Regards
Neal Matthews
mbezdek
28th November 2001, 15:58
Jim
We have compression turned on and there are definitely pros and cons. The biggest thing is that our GL is not overloaded with such a large volume of transactions. For example, if we generate 50,000 integration transactions we may only actually create 200 GL documents. One of the downsides is, when the compressed transaction comes into GL, it picks up reference information from the first PO, for example, on a Purchase/Receipt integration. So someone initially looking at the document in GL may think that the transaction for that specific PO is incorrect, as the document actually picks up the compressed transactions for all PO's for example. WHat we did is create some custom reports so that if a user wants to see the detail of a particular compressed transaction, the can get that information. We have a few custom reports for this. If you would like any more info on them or some examples I can certainly send them over.
JamesV
28th November 2001, 20:34
mbezdek,
I have been told by Baan finance people that you can always write reports to get the data when the detail has been compressed. It is good to get independent confirmation of this. While I am not looking for a solution, if I could get a copy of the report I could use it as an example when speaking to customers about what they could do instead of keeping all of the detail.
Thank you very much,
-- Jim
(I love this place!)
mbezdek
30th November 2001, 20:34
Jim
I sent over some info and an example of one of the reports that we have created. The one thing to be careful of is how much information they want to be able to pull in (for example, we have on Purchase/Receipt transactions, the Supplier invoice # is pulled in if it has been matched in AP, the customer order that comes in on our PO). The more data that they try to link together the longer it may take to run.
Mike
ralmeida
6th December 2001, 13:11
Hi Jim,
I have consulted in large sites and never seen Power users making use of non compressed transactions in tfgld410/417.. ..at the most they churn out some reports when they r stuck at year closing...but they still want uncompressed transactions..
Ralmeida
JamesV
6th December 2001, 18:14
Thanks everyone for the replies.
Now I know more than I did yesterday -- one of my measures of a good day.
Ralmeida --
When these sites finish year-end, do they then archive, purge, compress or delete transactions?
-- Jim
ralmeida
7th December 2001, 06:04
HI Jim,
I have seen sites who have a good archiving Policy in Place and who have good D/B administrator. Some transactions are also deleted eg. Fully paid invoices.
While some site usually who do not have a good D/B guy simply increase their Ram or transactions overheads when performance detiorates and do not bother to archive or purge transactions.
If u are interested in a archiving Policy i have done for one of my client pls let me know i will mail the same to U.