Baanboard.com

Go Back   Baanboard.com > Forum > Baan Quick Support: Functional & Technical > Finance, Invoicing and Integration

User login

Frontpage Sponsor

Main

Poll
For ERP LN feature pack upgrade, what method of install are you using?
Installation Wizard into existing VRC
37%
Installation Wizard into new VRC
39%
Manual into existing VRC
3%
Manual into new VRC
21%
Total votes: 38

Baanboard at LinkedIn


Reference Content

Reply
 
Thread Tools Display Modes
  #1  
Old 6th March 2007, 21:16
r_nagu's Avatar
r_nagu r_nagu is offline
Senior Member
 
Join Date: Mar 2002
Location: ~
Posts: 231
r_nagu is on a distinguished road
Baan: BaaN IV - DB: Oracle 8 - OS: UNIX
Create Recurring Transactions (tfgld1202m000)
Baan: Other/Unknown

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
Reply With Quote
  #2  
Old 7th March 2007, 14:45
EdHubbard's Avatar
EdHubbard EdHubbard is offline
Guru
 
Join Date: Mar 2002
Location: Malvern, England
Posts: 309
EdHubbard is on a distinguished road
Baan: 4c4 MCR - DB: MS SQL Server 2000 - OS: Windows 2003 Server
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!
Reply With Quote
  #3  
Old 7th March 2007, 15:16
Sai_krishna Sai_krishna is offline
Member
 
Join Date: Jan 2002
Location: Pune
Posts: 95
Sai_krishna is on a distinguished road
Baan: IV,V,LN - DB: Oracle,SQL - OS: NT,UNIX
Original Batch

Hi,

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

Regards
Sai Krishna
Reply With Quote
  #4  
Old 13th March 2007, 21:13
Scott2001 Scott2001 is offline
Senior Member
 
Join Date: Dec 2001
Location: Michigan, USA
Posts: 192
Scott2001 is on a distinguished road
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.)
Reply With Quote
  #5  
Old 14th March 2007, 01:16
Sai_krishna Sai_krishna is offline
Member
 
Join Date: Jan 2002
Location: Pune
Posts: 95
Sai_krishna is on a distinguished road
Baan: IV,V,LN - DB: Oracle,SQL - OS: NT,UNIX
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
Reply With Quote
  #6  
Old 14th March 2007, 03:40
Scott2001 Scott2001 is offline
Senior Member
 
Join Date: Dec 2001
Location: Michigan, USA
Posts: 192
Scott2001 is on a distinguished road
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
Reply With Quote
  #7  
Old 15th March 2007, 08:43
Sai_krishna Sai_krishna is offline
Member
 
Join Date: Jan 2002
Location: Pune
Posts: 95
Sai_krishna is on a distinguished road
Baan: IV,V,LN - DB: Oracle,SQL - OS: NT,UNIX
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
Reply With Quote
  #8  
Old 15th March 2007, 19:18
Scott2001 Scott2001 is offline
Senior Member
 
Join Date: Dec 2001
Location: Michigan, USA
Posts: 192
Scott2001 is on a distinguished road
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".)
Reply With Quote
  #9  
Old 17th March 2007, 02:49
Sai_krishna Sai_krishna is offline
Member
 
Join Date: Jan 2002
Location: Pune
Posts: 95
Sai_krishna is on a distinguished road
Baan: IV,V,LN - DB: Oracle,SQL - OS: NT,UNIX
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
Reply With Quote
  #10  
Old 17th March 2007, 06:28
Scott2001 Scott2001 is offline
Senior Member
 
Join Date: Dec 2001
Location: Michigan, USA
Posts: 192
Scott2001 is on a distinguished road
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
Reply With Quote
  #11  
Old 24th April 2007, 09:36
mtho33 mtho33 is offline
Junior Member
 
Join Date: Apr 2007
Posts: 12
mtho33 is on a distinguished road
Baan: Baan Vc - DB: Oracle - OS: Winn 2003
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.
Reply With Quote
Sponsored Links
  #12  
Old 24th April 2007, 21:58
Scott2001 Scott2001 is offline
Senior Member
 
Join Date: Dec 2001
Location: Michigan, USA
Posts: 192
Scott2001 is on a distinguished road
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
Reply With Quote
  #13  
Old 26th April 2007, 15:37
mtho33 mtho33 is offline
Junior Member
 
Join Date: Apr 2007
Posts: 12
mtho33 is on a distinguished road
Baan: Baan Vc - DB: Oracle - OS: Winn 2003
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.
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Integration transactions by Project/Order mostrightfuture Finance, Invoicing and Integration 5 3rd April 2006 06:28
Automatic Transactions at GL Module rini pudjiastut Finance, Invoicing and Integration 2 11th December 2003 03:20
Problem in Create Financial Transactions for Service Orders sasa888 Project & Services 3 20th November 2002 17:26
Audit trail from Finance to distribution Nazeem Finance, Invoicing and Integration 14 11th October 2002 05:18


All times are GMT +2. The time now is 17:13.


©2001-2017 - Baanboard.com - Baanforums.com