Hi,
Anytime we run this session this month to catch recurring transactions for the last month, we are getting an error which says "Original transactions missing" and the session creates an empty batch. I checked the setup in the “Maintain Recurring Transaction Instruction (tfgld1107m000)” session and everything looks to be fine.

Does anyone know what could be the problem?

Appreciate your help.
NS

Have you changed the sharing parameters of table tfgld102?
In a multi-finance setup (if that is what you have) the table needs to be shared in Maintain Logical Tables.

That caught us out some years ago!

Hi,

Check whats happened to the original batch. The transactions of the original batch should be present in tfgld106.

Regards
Sai Krishna

Check to see if the original transactions are still in tfgld102. A key difference between recurring/reversing JVs and "normal" JVs is that the original transaction lines for a recurring/reversing entry remain in gld102 after the original transaction has been finalized.

When you run Create Recurring Transactions, Baan looks at the instructions in tfgld103 for the date/period information and then reads the original lines in tfgld102 to create the recurrance or reversal.

The original lines remain in gld102 until the final recurring/reversing entry has been created. They will not print from the std Baan Print Non-Finalized Transactions report because the report script ignores them. They can be seen via general table inquiry, however, and they will print on an SQL query or other report (e.g. from Cognos, Crystal, Safari, Cyberquery, Access) if you do not code the selection to ignore them.

Scott

(I should have noted the table names and functionality described above are based on Baan IV. I believe the LN functionality is the same but would have to check.)

I guess Baan should check in tfgld106. That is because You cannot create recurring transactions for non finalised transactions. Baan will give the error "original transactions not finalised"

Regards
Sai Krishna

Sai,

Sorry. I responded too fast. I didn't mean to imply that tfgld106 wasn't checked. You are absolutely right that the recurring/reversing transactions can't be created until the originals have been finalized. And without going back to test/look, the error message you give sounds like the one that Baan does (or should) report for that condition.

However, if you check tfgld102, I think you'll find that the non-finalized lines do remain in that table until the last recurrence/reversal has been created. I found that out some time ago when I was writing an external query to report non-finalized transactions in an Excel-friendly format. I discovered the practical way when my non-finalized totals didn't match totals from Baan's Non-Finalized report. It's been a while since I played with it so I did check one of our test companies before replying.

Ed is also correct in cautioning that tfgld102 must be shared in a multi-finance environment.

Now the ball is back in r_nagu's court to let us know what the actual situation is in his case.

Scott

Scott,

In my view this should be a bug. This is because ur trial balance (and other reports) with non finalised transactions shows an incorrect picture.

A transaction should be in either tfgld102 or tfgld106.

Ur comments pls.

Regards
Sai Krishna

It's not a bug. It's system design.

The remaining entry in tfgld102 will not be reported by Print Non-Finalized Transactions because the system recognizes the Recurring/Reversing transaction category and the transaction status.

Trial balance reports summary amounts from the ledger/dimension history tables, not from tfgld106/102. So TB is not effected. (Also note that even if you select the option to include non-finalized transactions, the trial balance report only includes non-finalized amounts from transaction types with Update Mode "Real Time" or "End of Session".)

You are right about the trial balance tables. However the tfgld200 balances are a total of the transactions in tfgld102 or tfgld106. So any additional transaction in these tables will show a wrong balance in the tb unless avoided by design in which case it will not be a bug.

Cheers
Sai

Hi Sai,

The tfgld200-series tables only include non-finalized transactions whose update method is Real Time or End of Session, not Finalization. Program design avoids "double counting" the tfgld102 record of the original recurring/reversing transaction in either Print Non-Finalized or Print Trial Balance. Try it in test. As I said previously, it was a surprise to me when I discovered how it works.

Still looking for a reply from r_nagu to see if any of this discussion helps to resolve his problem.

Scott :)

The comment post by some earlier respondents were correct.
It was standard functionality for recurring transactions to stay in
tfgld102 after the batch was finalized.

After all the recurring transaction lines were all been created then the batch will be removed from tfgld102.

Recurring transaction batch should be the one using a recurring transaction type.

Thanks. I forgot to add that the batch lines are deleted from gld102 when the final recurrence is processed.

The gld102 records are also removed if the remaining instruction lines are deleted via Maintain Recurring Transaction Instructions.

Scott

After the recurring transaction was finalized, the batch remained in tfgld102 and it was called the 'originating batch'. The report should know how to identify an originating batch in gld102 and a recurring batch that was not finalized.

If the report print the 'originating batch', then the bug is with the report.