T24: Error in EB.ACCOUNTING

[twee]

Hi,
Currently i'm working on a batch routine to run EB.ACCOUNTING. While
running the batch, there are a few errors (with exact same
description) for some internal accounts. The errors like this:

_B.IT.UNUSED.LOAN.JOURNAL_B.IT.UNUSED.LOAN.JOURNAL_2_21 AUG
2008_11:08:59_Fatal error in EOD.ACCOUNT.VERIFY error
AC.RTN.AMT.MISSACCOUNT USD193
0100010018 TRANS REF FT.UNCOMM.JB.USD contract:ID0010018

I thought it was because we hit EB.ACCOUNTING too many times , but
when we only run it for those accounts which make errors, the errors
still happen.

I already check the accounts and there was nothing wrong. And when we
use some other internal accounts with same category and currency but
for other company, EB.ACCOUNTING can run well without any error.

I have some questions :
1. How can I solve this error
2. How can I get success/error message (like when we use OFS)
3. Can I get the stmt.entry id created by EB.ACCOUNTING
4. There is a V variable in the routine, what does it mean and why it
should be initialised for this program to run well

Thank you

Regards,
Pratiwi Weyanti

[Srinivas]

Hi,

 

For the point 1, there might be some problem at the contract level.

 

For the point 2, You can find out whether the processed ofs message is success or failure by checking the status as  '1' or '-1' in the processed ofs message.

 '1' indicates success and '-1' indicate failure of the message. By using field function u can extract and find out the value. This value wil be there in the begining of the ofs message .

 

For the point 3, you can get the statement entry ids with EB.ACCOUNTING.

Extract the statement entry id from the common varibale STMT.ENTRIES.WITH.IDS.

eg :

 

CALL EB.ACCOUNTING("FT",'SAO',R.CATEG.ARRAY,'')

IF R.CATEG.ARRY NE '' THEN

   STMT.ID = LOWER(STMT.ENTRIES.WITH.IDS<1,AC.STE.STME.NO>)

   CALL JOURNAL.UPDATE('')

END

 

The above example will solve the problem .

 

For the point 4, if you mail the routine we can check it out .

 

Thanks & Regards,

Yadav.

 

--
SrinivasYadav. G
Mobile No: 00966 - 564991072

[twee]

Thank you Srivinas for your help, this is what i get this far :
point 1:
I already get the solution. I should have put the amount in
AMOUNT.FCY because it is not in local currency
point 2:
I want to find out whether EB.ACCOUNTING is run successfully ,
not OFS.
point 3:
I already put

STMT.ID = LOWER(STMT.ENTRIES.WITH.IDS<1,AC.STE.STME.NO>)

But when I compile, it seems there is no global variable as
STMT.ENTRIES.WITH.IDS. This is the warning :
Warning: Variable AC.STE.STME.NO is never assigned!
Warning: Variable STMT.ENTRIES.WITH.IDS is never assigned!
point 4:
The routine like this:

AC.F = 'SAO'
V= AC.STE.DATE.TIME
CALL EB.ACCOUNTING('FT',AC.F, R.STMT, '')

if we use this routine as authorize routine in screen, we don't need
this V variable initialized. But if I use it in Batch, the error
message is like this:
** Error [ ARRAY_SUBS ] **
Array subscript out of range , Line 306 , Source ACCOUNTING.AUT
Trap from an error message, error message name = ARRAY_SUBS
Line 306 , Source ACCOUNTING.AUT


Regards,
Pratiwi Weyanti

[Srinivas]

Hi Twee,

 

point 2:

   Yes you can know by checking the common variable TEXT.

eg :

 

R.STMT = LOWER(R.STMT)

CALL EB.ACCOUNTING('AC','SAO',R.STMT,'')

IF TEXT EQ '' THEN

   DISPLAY "eb accounting success"

END

 

TEXT is a common variable which is set to 'NO' on error

 

point 3:

    Include the file layout I_F.STMT.ENTRY in your program, the error message won't appear.

 

point 4:

    Assign the variable 'v' with this value 'C$SYSDIM' in the routine and the array R.STMT used in ur case must be converted to lower delimited arrray before passing it to EB.ACCOUNTING.

 

Let me know if any error comes by means of above solution.

 

Thanks & Regards,

Yadav.

 

On 21/08/2008, twee <pratiwi...@gmail.com> wrote:

[Pawel (privately)]

Hello Twee,

Temenos guys are not reading this list. Otherwise you would read similar comment. ;)

It will be very hard to help you, because you did not give us full picture. You did not show us prepared accounting entries, account records, etc. Therefore do not expect much help.

1. You should not use EB.ACCOUNTING if you do not know this core function. EB.ACCOUNTING is low level accounting function, which may _easily_ screw your books. Why are not you using DATA.CAPTURE entries or FUNDS.TRANSFER? I know that it is slower, but you will be sure that developed code is portable between T24 releases and that everything is right (you will surely not corrupt books).

2. You should not probably perform additional accounting in AUTH routine, but later in online or by OFS.PUBLISH mechanism. Think of transaction boundary and rewrite your code.

3. It seems to me that JOURNAL.UPDATE is forbidden in local code since T24 R07. What will you do with your program if you migrate to newer version? Your code will not compile.

4. V can be set to anything greater than 7 in API call. Core function will put accounting entries ids into R.NEW(V-7) (I gave 7 from top of my head, may be mistaken). Please notice that R.NEW(V-7) is normally STMT.NOS field in most T24 applications that perform accountings. Expect two values in R.NEW(V-7) - similar to these that you see in STMT.NOS fields of financial applications. Please keep in mind that you may not want to change R.NEW.

5. Definetely contact with Temenos before using EB.ACCOUNTING. There are other options for bulk (eg. clearing) accountings than EB.ACCOUNTING.

6. Number of your internal account seemed to have invalid length. Perform your accounting using DATA.CAPTURE, then see which fields are populated, take snapshot of STMT.ENTRY/CATEG.ENTRY and try with your code if you _must_.

Kind regards
Pawel

[Narayan]

Twee,

V is a GLOBAL variable which must be set before you call
EB.ACCOUNTING... During ONLINE stage, V will have a value, but since
yours is a COB one, you need to assign a value, which depends upon how
your a/cing entries are raised.... Like Pawel says... if you have a
option, dont use EB.ACCOUNTING...

Narayan

On Aug 21, 7:56 pm, "Pawel (privately)" <pprivat...@wp.pl> wrote:
> Hello Twee,
> Temenos guys are not reading this list. Otherwise you would read similar comment. ;)
> It will be very hard to help you, because you did not give us full picture. You did not show us prepared accounting entries, account records, etc. Therefore do not expect much help.
> 1. You should not use EB.ACCOUNTING if you do not know this core function. EB.ACCOUNTING is low level accounting function, which may _easily_ screw your books. Why are not you using DATA.CAPTURE entries or FUNDS.TRANSFER? I know that it is slower, but you will be sure that developed code is portable between T24 releases and that everything is right (you will surely not corrupt books).
> 2. You should not probably perform additional accounting in AUTH routine, but later in online or by OFS.PUBLISH mechanism. Think of transaction boundary and rewrite your code.
> 3. It seems to me that JOURNAL.UPDATE is forbidden in local code since T24 R07. What will you do with your program if you migrate to newer version? Your code will not compile.
> 4. V can be set to anything greater than 7 in API call. Core function will put accounting entries ids into R.NEW(V-7) (I gave 7 from top of my head, may be mistaken). Please notice that R.NEW(V-7) is normally STMT.NOS field in most T24 applications that perform accountings. Expect two values in R.NEW(V-7) - similar to these that you see in STMT.NOS fields of financial applications. Please keep in mind that you may not want to change R.NEW.
> 5. Definetely contact with Temenos before using EB.ACCOUNTING. There are other options for bulk (eg. clearing) accountings than EB.ACCOUNTING.
> 6. Number of your internal account seemed to have invalid length. Perform your accounting using DATA.CAPTURE, then see which fields are populated, take snapshot of STMT.ENTRY/CATEG.ENTRY and try with your code if you _must_.
> Kind regards
> Pawel
> Dnia 21-08-2008 o godz. 17:09 Srinivas napisał(a):Hi Twee,
>
>  
>
> point 2:
>
>    Yes you can know by checking the common variable TEXT.
>
> eg :
>
>  
>
> R.STMT = LOWER(R.STMT)
>
> CALL EB.ACCOUNTING('AC','SAO',R.STMT,'')
>

> IFTEXTEQ '' THEN

>
>    DISPLAY "eb accounting success"
>
> END
>
>  
>

> TEXTis a common variable which is set to 'NO' on error

>
>  
>
> point 3:
>
>     Include the file layout I_F.STMT.ENTRY in your program, the error message won't appear.
>
>  
>
> point 4:
>
>     Assign the variable 'v' with this value 'C$SYSDIM' in the routine and the array R.STMT used in ur case must be converted to lower delimited arrray before passing it to EB.ACCOUNTING.
>
>  
>
> Let me know if any error comes by means of above solution.
>
>  
>
> Thanks & Regards,
>
> Yadav.
>
>  
>
> On 21/08/2008,twee<pratiwi...@gmail.com> wrote:
>
>
> Thank you Srivinas for your help, this is what i get this far :
> point 1:
>     I already get the solution. I should have put the amount in
> AMOUNT.FCY because it is not in local currency
> point 2:
>     I want to find out whether EB.ACCOUNTING is run successfully ,
> not OFS.
> point 3:
>     I already put

>           STMT.ID= LOWER(STMT.ENTRIES.WITH.IDS<1,AC.STE.STME.NO>)

>     But when I compile, it seems there is no global variable as
> STMT.ENTRIES.WITH.IDS. This is the warning :

>            Warning: VariableAC.STE.STME.NOis never assigned!

[twee]

Dear All,

*point 2:*
I already tried it and it works. But on previous error because of I
didn't input the amount.fcy, the routine stopped after error and i
can't get the calue of TEXT variable.

*point 3:*
I already include the file layout I_F.STMT.ENTRY in my program,
but there is no AC.STE.STME.NO in the file layout. I already changed
it to , but there is still 1 warning :

Warning: Variable STMT.ENTRIES.WITH.IDS is never assigned!

Is there something else I must include?

*point 4:*
Ok, so I can initialised V variable with anything (above 7)? Because
I've seen routines just initialized it with number, e.g. V= 11

To Pawel,

I'm trying to explore EB.ACCOUNTING because it is suggested by our
consultant. Because it is a lot faster than OFS. And the only thing I
have to make sure is the entries is balance, is it correct?

For "You should not probably perform additional accounting in AUTH
routine", I quoted this from Temenos consultant :

T24 does not allow mainline subroutine to call EB.ACCOUNTING.
So you can create new Table and in the authorize routine call
EB.ACCOUNTING.
Since you call EB.ACCOUNTING in the Table then R.NEW always set.
And after I said that we need this to be run on batch, he said that it
is possible and i should try. I don't have any documentations about
EB.ACCOUNTING, and it's hard for me to contact this consultant. That's
why your posts help me a lot.

And I want to ask you , what is the connection between JOURNAL.UPDATE
and EB.ACCOUNTING. I don't use JOURNAL.UPDATE within my routine.

This is EB.ACCOUNTING routine I use to check all the suggestions (If
it is a success in this routine, then I'll combine it with my other
logic and calculations:

SUBROUTINE TRY.EB.ACC

$INCLUDE GLOBUS.BP I_COMMON
$INCLUDE GLOBUS.BP I_EQUATE
$INCLUDE GLOBUS.BP I_F.STMT.ENTRY

GOSUB INIT
GOSUB PREP.STMT

RETURN

INIT:
R.STMT = ''
DL.STMT.ENTRY=''

RETURN

PREP.STMT:

ID.COMPANY = 'ID0010011'
FOR CNT=1 TO 2
DL.STMT.ENTRY<AC.STE.OUR.REFERENCE> = ''
DL.STMT.ENTRY<AC.STE.TRANS.REFERENCE> = 'FT-BATCH'
DL.STMT.ENTRY<AC.STE.SYSTEM.ID> = 'LD'
DL.STMT.ENTRY<AC.STE.BOOKING.DATE> = TODAY
DL.STMT.ENTRY<AC.STE.VALUE.DATE> = TODAY
DL.STMT.ENTRY<AC.STE.CURRENCY.MARKET> = '1'
DL.STMT.ENTRY<AC.STE.CURRENCY> = 'IDR'

IF CNT =1 THEN ;* DEBIT
DL.STMT.ENTRY<AC.STE.ACCOUNT.NUMBER> = '0000001244'
DL.STMT.ENTRY<AC.STE.CUSTOMER.ID> = '100100'
DL.STMT.ENTRY<AC.STE.COMPANY.CODE> = ID.COMPANY
DL.STMT.ENTRY<AC.STE.PRODUCT.CATEGORY> = '6000'
DL.STMT.ENTRY<AC.STE.TRANSACTION.CODE> = '14'
DL.STMT.ENTRY<AC.STE.AMOUNT.LCY> = '-213'
END ELSE
DL.STMT.ENTRY<AC.STE.ACCOUNT.NUMBER> = '0000001252'
DL.STMT.ENTRY<AC.STE.CUSTOMER.ID> = '100100'
DL.STMT.ENTRY<AC.STE.PRODUCT.CATEGORY> = '6000'
DL.STMT.ENTRY<AC.STE.COMPANY.CODE> = ID.COMPANY
DL.STMT.ENTRY<AC.STE.TRANSACTION.CODE> = '64'
DL.STMT.ENTRY<AC.STE.AMOUNT.LCY> = '213'
END

R.STMT<-1>=LOWER(DL.STMT.ENTRY)

NEXT CNT

AC.F = 'SAO'
V= AC.STE.VALUE.DATE

CALL EB.ACCOUNTING('LD',AC.F, R.STMT, '')

RETURN

END


Thank you .

Regards,
Pratiwi W.

[saravanan thangavelu]

Hi,

the one thing in this discussion is about a common variable V. According to my knowledge V is common variable which contains the total number of fields in an application (in your case its your local table). So it has nothing to do with your EB.ACCOUNTING ( may be i am wrong). But one thing i am sure that if you change the common variable V then it will through you the error "Array Subscript out of range". Because this  variable will be updated in your field definitions of your local table.

My question is why you are setting V= AC.STE.VALUE.DATE? this will change the V to VALUE.DATE field number of STMT.ENTRY, so V will now equal to 11.(I dont remeber the exact field number). So you will get the error Array subscript out of range.

The second thing it is not AC.STE.STME.NO it is AC.STE.STMT.NO. and in your case STMT.ENTRIES.WITH.IDS is DL.STMT.ENTRY. So put Y.STMT.ID = DL.STMT.ENTRY<AC.STE.STMT.NO>. this will give you the STMT.ENTRY.ID.

And in case of error dont check for TEXT check ETEXT. this will only get update if case of error.

hope this will help you.
 
--
Regards,
saravanan.T

[twee]

Hi,

If I use EB.ACCOUNTING online (I put it in auth routine of screen), I
don't have to initialize V variable. But when I use EB.ACCOUNTING as
a batch routine and I don't initialize the V variable, there will be
an error message like this:

** Error [ ARRAY_SUBS ] **
Array subscript out of range , Line 306 , Source ACCOUNTING.AUT
Trap from an error message, error message name = ARRAY_SUBS
Line 306 , Source ACCOUNTING.AUT

I set V= AC.STE.VALUE.DATE just to give V a value so EB.ACCOUNTING can
process well.

I already tried to put Y.STMT.ID = DL.STMT.ENTRY<AC.STE.STMT.NO>, but
it doesn't return any value.
I just received an email from Temenos consultant about
STMT.ENTRIES.WITH.IDS:
" The common variable STMT.ENTRIES.WITH.IDS in I_ACCT.COMMON of
GLOBUS.BP keep id of stmt entry "
I already tested it in my routine, and it works. I only need to add :
$INCLUDE GLOBUS.BP I_ACCT.COMMON

Regards,
Pratiwi W.

[mike ryder]

Well I must agree with Pawel from a previous post.

do not use EB.ACCOUNTING if you are not completely familiar with the
way it works - it is a very dangerous routine for the uninitiated and
should only be used by very experienced developers. Your responses
show that you do not have that experience and you are very likely to
corrupt your general ledger.

Temenos provide a whole raft of processes for creating accounting
entries for use in local development. You should ask your consultant
to provide you with an alternative and safe methodology.

Regards
Mike

[Santosh]

For point No.2 if you want to know whether its successful or not....do like this....

 

Just assign TEXT= '' just before calling EB.ACCOUNTING. after calling the EB.ACCOUNTING check the TEXT = 'NO' or if it has any value then in that case erroenous values are passed in the EB.ACCOUNTING and accounting is not done as per your inputs. So if TEXT NE '' then that is fail. If TEXT = '' THEN successful case.

 

For point No.3 Include the I_F.STMT.ENTRY and I_F.CATEG.ENTRY files. Once you include it wont show any errors.

For point No.4 Please do this: V = C$SYSDIM. It wont throw any error. Dont do anything else to V variable. System takes care everything

 

Let me know if you need any details.

--
Mobile: 966-567493144

[Nasar]

Hi,

 

Please check the file EB.FINANCIAL.SYSTEM  is defined properly in your system. If you use EB.ACCCOUNTING and the Credit and debit amounts not match system will raise the balance entries based on the account defined in this file.

 

See below the helptext for this file.

 

EB.FINANCIAL.SYSTEM

This new table will allow the balancing options to defined for financial system. A default record of T24 will be used for defining standard system behaviour.

Here we can choose the option to raise the self balancing entries by different SYSTEM.ID and POSITION.TYPE

When balancing entries are raised during the Close of Business the system will write to the EB.EOD.ERROR file

 

rgd