Insert into corresponding fields of table do not retrive data

[Former Member]

Hi, maybe you can help me, here's a little of background...

I made a program that use two Call Transactions, for these I used batch input, I use the J1B1 for "Nota Fiscal Creation" This is the invoice that Brazil used as a legal requirement, and the FB01 to post the accounting document.

The problem is the follow...

I read some fields from the tables of the "Nota Fiscal" in order to set my accounting document, so when I use the statement INTO CORRESPONDING FIELDS OF TABLE, the sy-subrc is 0, however the data is not retrieving in my internal table, and the key that I using exist on the table.

here's the example:

SELECT DOCNUM ITMNUM NBM NFNETT

INTO CORRESPONDING FIELDS OF TABLE XDETAIL

FROM J_1BNFLIN

WHERE DOCNUM EQ NUMREF.

On the Development environment the all process run correctly, however on QA, this is not working, just if I enter on debug mode and I check every internal table after the select into statement.

Do you know what can be happening ?

[Former Member]

Hi, maybe you can help me, here's a little of background...

I made a program that use two Call Transactions, for these I used batch input, I use the J1B1 for "Nota Fiscal Creation" This is the invoice that Brazil used as a legal requirement, and the FB01 to post the accounting document.

The problem is the follow...

I read some fields from the tables of the "Nota Fiscal" in order to set my accounting document, so when I use the statement INTO CORRESPONDING FIELDS OF TABLE, the sy-subrc is 0, however the data is not retrieving in my internal table, and the key that I using exist on the table.

here's the example:

SELECT DOCNUM ITMNUM NBM NFNETT

INTO CORRESPONDING FIELDS OF TABLE XDETAIL

FROM J_1BNFLIN

WHERE DOCNUM EQ NUMREF.

On the Development environment the all process run correctly, however on QA, this is not working, just if I enter on debug mode and I check every internal table after the select into statement.

Do you know what can be happening ?

[GuyF]

If I understand you correctly, the field NUMREF is from the internal table XDETAIL. In that case, you need to change the WHERE to

"WHERE DOCNUM EQ XDETAIL-NUMREF."

Let me know if this helps, or if I misunderstood you.

[Former Member]

Hi Guy F.

Well, maybe I don't explain very well that part...

The NUMREF is a variable where I have the document number, and comes from previous validations, the statement DOCNUM EQ NUMREF is working OK.

The Issue is that this statement do not retrieving data, however the data exists on the J_1BNFLIN table where the DOCNUM is equal to the NUMREF that I sending, and the fields that I use on the select already exists on the internal table.

When I run the program on debug mode the SY-SUBRC for this statement is 0, but is not retrieving my internal table XDETAIL.

[GuyF]

The fact that SY-SUBRC is 0 simply means that there were no errors in the SELECT query, not necessarily that it's managed to select anything.

If you say that it worked in the DEV environment, maybe you should make sure that there is data in J_1BNFLIN in the QA environment?

If you could write the structure of the internal table XDETAIL I might be able to help you more.

[Former Member]

Ok, here's the structure...

TYPES: BEGIN OF TXDETAIL,

DOCNUM LIKE J_1BNFLIN-DOCNUM,

ITMNUM LIKE J_1BNFLIN-ITMNUM,

MATNR LIKE J_1BNFLIN-MATNR,

DESCRIPTION LIKE ZMSRBUSCASE-DESCRIPTION,

PRCTR LIKE BSEG-PRCTR,

NBM LIKE J_1BNFLIN-NBM,

NFNETT LIKE J_1BNFLIN-NFNETT,

BLART LIKE ZMSRBUSCASE-BLART,

PSTKYCUST LIKE ZMSRBUSCASE-PSTKYCUST,

PSTKYACCNT LIKE ZMSRBUSCASE-PSTKYACCNT,

SAKNR LIKE ZMSRBUSCASE-SAKNR,

PSTKYIPI LIKE ZMSRBUSCASE-PSTKYIPI,

SAKNRIPI LIKE ZMSRBUSCASE-SAKNRIPI,

PSTKYICMS LIKE ZMSRBUSCASE-PSTKYICMS,

SAKNRICMS LIKE ZMSRBUSCASE-SAKNRICMS.

TYPES: END OF TXDETAIL.

DATA: XDETAIL TYPE STANDARD TABLE OF TXDETAIL WITH HEADER LINE.

The DOCNUM ITMNUM NBM NFNETT, are the fields that I need to read at this point, on the QA environment the data exist on the J_1BNFLIN table.

First the program create the "Nota Fiscal" (Brazilian invoice) and fills the J_1BNFDOC and J_1BNFLIN tables, Header and detail, for this document that I created, I read it (here's when I read the J_1BNFLIN and try to move it to XDETAIL ), to generate the Accounting document on the FI (BKPF - BSEG).

So, If I run the program in debug mode, and I open the XDETAIL table after the statement that I mention before, it retrieve data, and the all process can continue OK, however if I run the program without debug, the process is ended after the Select into statement, because the data wasn't retrieving.

From me point os view the statement are OK, because this work on the DEV environment and on debug mode, but I really don't know why on DEV works and QA doesn't work, and the data exists both environment !

[GuyF]

That's really weird. When you debug and run through the entire program, is it showing the data in the end? If it isn't, try to find if there's something that's deleting the data.

Other than that, I'd change the order of the SELECT query, so that the FROM is before the INTO. Maybe try to change the definition of the internal table from LIKE to TYPE, and at the end, instead of a period, put a comma -

TYPES: BEGIN OF TXDETAIL,

DOCNUM LIKE J_1BNFLIN-DOCNUM,

ITMNUM LIKE J_1BNFLIN-ITMNUM,

MATNR LIKE J_1BNFLIN-MATNR,

DESCRIPTION LIKE ZMSRBUSCASE-DESCRIPTION,

PRCTR LIKE BSEG-PRCTR,

NBM LIKE J_1BNFLIN-NBM,

NFNETT LIKE J_1BNFLIN-NFNETT,

BLART LIKE ZMSRBUSCASE-BLART,

PSTKYCUST LIKE ZMSRBUSCASE-PSTKYCUST,

PSTKYACCNT LIKE ZMSRBUSCASE-PSTKYACCNT,

SAKNR LIKE ZMSRBUSCASE-SAKNR,

PSTKYIPI LIKE ZMSRBUSCASE-PSTKYIPI,

SAKNRIPI LIKE ZMSRBUSCASE-SAKNRIPI,

PSTKYICMS LIKE ZMSRBUSCASE-PSTKYICMS,

SAKNRICMS LIKE ZMSRBUSCASE-SAKNRICMS,

END OF TXDETAIL.

Try to talk to your BASIS people, and make sure that the definitions for the DEV and QA environments are the same. When I work they changed something in one of the environments by accident, and things that used to work stopped. Maybe that's what happened where you work.

I wish I could be more helpful, but I can't find a reason why it shouldn't work.

[former_member194669]

Hi,

Check patch level/service pack applied in both enviornment.

aRs