Glicu = 0 with sp22

We installed on December 2003, sp22 in a custom path code. Also, applied all the ESUs mentioned in SP22 documentation (JD20876, JD21107 and JD21050)
All test were suceesfully.
Yesterday we´ve deployed sp22 in our production environment, and found that any GL transaction from any module (G/L, A/P, A/R, etc.) save abnormally records in F0911 table. For example, the batch number (GLICU field) is equal to zero.

Steps to reproduce the error:
1) Add a JE with P0911
2) Note that the application shows the batch number
3) Save the JE, (JE number is showed)
4) Return to Work with Journal Entries form
5) Click FIND and nothing is showed
6) Open UTB, (or any SQL query program), select F0911 table, with company, document number and document type, and the JE appears with the batch number = zero.


OneWorld XE, Update 6, SP22_N1, Oracle, NT

Are there any errors/problems/unusual entries in the jde.log or jdedebug.log?

Peter: thansk for your response.

There were not errors in any process during SP22 instalation.
During the JE record process, there aren´t any problem or error message.
Jdedebug is disablesd, but jde.log shows the following:


1540/1696 Thu Jan 15 00:50:48 2004 combined.c344
RDEL0000045 - Could not open tables for reliable event delivery (F90703 and F90704). Reliable event delivery will be disabled

1540/628 Thu Jan 15 00:51:35 2004 Gt_msg.c1501
GEN0000003 - DoSendMessage Error: User 6002 does not exist in the address book file (F0101)

Those messages wasn´t present in SP19.1

TIA, Luis
OneWorld XE, Update 6, SP22_N1, Oracle, NT

What the jde.log shows is generally interesting and can point to the need for the jdedebug.log. That is the case in your situation. Turn debugging on in the JDE.ini and reproduce the problem and then check the jdedebug.log.

Peter: thanks again!

I´ve turn debugging on, and find the folloging in jdedebug.log:

1) The INSERT script into F0911, shows that GLICU = 0 (is this normal at this point?)
Jan 15 01:17:27 ** 1292/2324 ORACLE DBInitReq conn=039A94B0 requ=05F02338 JDEENTER1 (B733) new
Jan 15 01:17:27 ** 1292/2324 INSERT INTO PRODDTA.F0911 (GLKCO, GLDCT, GLDOC, GLDGJ, GLJELN, GLEXTL, GLPOST, GLICU, GLICUT, GLDICJ, GLDSYJ, GLTICU, GLCO, GLANI, GLAM, GLAID, GLMCU, GLOBJ, GLSUB, GLSBL, GLSBLT, GLLT, GLPN, GLCTRY, GLFY, GLFQ, GLCRCD, GLCRR, GLHCRR, GLHDGJ, GLAA, GLU, GLUM, GLGLC, GLRE, GLEXA, GLEXR, GLR1, GLR2, GLR3, GLSFX, GLODOC, GLODCT, GLOSFX, GLPKCO, GLOKCO, GLPDCT, GLAN8, GLCN, GLDKJ, GLDKC, GLASID, GLBRE, GLRCND, GLSUMM, GLPRGE, GLTNN, GLALT1, GLALT2, GLALT3, GLALT4, GLALT5, GLALT6, GLALT7, GLALT8, GLALT9, GLALT0, GLALTT, GLALTU, GLALTV, GLALTW, GLALTX, GLALTZ, GLDLNA, GLCFF1, GLCFF2, GLASM, GLBC, GLVINV, GLIVD, GLWR01, GLPO, GLPSFX, GLDCTO, GLLNID, GLWY, GLWN, GLFNLP, GLOPSQ, GLJBCD, GLJBST, GLHMCU, GLDOI, GLALID, GLALTY, GLDSVJ, GLTORG, GLREG#, GLPYID, GLUSER, GLPID, GLJOBN, GLUPMJ, GLUPMT) VALUES ('00001','JE',4000489.000000,104015,1.000000,' ','4',0.000000,'G',104015,104015,11546.000000,'00001',' 01010303.411111.002 ','2','00464083',' 01010303','411111','002 ',' ',' ','AA',1.000000,20.000000,4.000000,' ','GUA',0.000000,0.000000,0,7000000.000000,0.000000,' ',' ',' ','PRUEBA SP 7',' ',' ',' ',' ',' ',0.000000,' ',' ',' ',' ',' ',0.000000,' ',104015,0,' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',0,' ',' ',' ',' ',0.000000,0.000000,0.000000,' ',0.000000,' ',' ',' ',0.000000,' ',' ',104015,'LUISC',0.000000,0.000000,'LUISC','EP0911','LCARRIZO',104015,11727.000000)

2) there aren´t any "Return value is 2"

It´s hard to me to find any other abnormally in jdedebug.log. Would you like me to email it to you? (4 eyes may see better than 2)

Regards, Luis

Interesting but really expected. What you need to find in the jdedebug.log are the F0911 Doc and Batch business functions. The F0911 insert will be in one of them. Also is there a F0011 insert/update it should also be in one of the business functions? In the jdedbug.log there is a data dump on entry and exit of business functions. This can also provide some information.

The first one is related to the SP, but causes no problems, the second one is not SP related - it has to do with the AB# assignment to the User you use and it would be the same for the given User/Environment regardless of the SP. Could cause issues in GL, though, as a lot of settings are usually made at the AB level. Try using a different User to do the same transaction - one you usually use in Production, or similar.

My two cents...

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm