I wrote a custom RFC that reads specific data from table BKPF and returns it.
The function module works very well when I test it in SAP GUI, but when I used it from a .NET application via the .NET Connector 3.0 driver I got ' I' value (with 3 spaces) in BUKRS instead of 'IP01'.
I tried several codepage in the connection parameters but nothing changed.
FUNCTION ZONW_IMPORT_ECRM.
*"----------------------------------------------------------------------
*"*"Interface locale :
*" IMPORTING
*" VALUE(MAX_ROWS) TYPE I DEFAULT 0
*" VALUE(WHERE_TAB) TYPE WHERECONDS OPTIONAL
*" VALUE(COMPANYCODE) TYPE BKPF-BUKRS DEFAULT 'IP01'
*" VALUE(CURRY) TYPE BSEG-GJAHR DEFAULT SY-DATUM
*" EXPORTING
*" VALUE(RETURN_CODE) TYPE I
*" TABLES
*" RETURN_TABLE STRUCTURE BKPF
*"----------------------------------------------------------------------
CLEAR RETURN_TABLE. REFRESH RETURN_TABLE.
****** Creation du type de la table ECRM
TYPES: TT_ECRM TYPE STANDARD TABLE OF BKPF.
****** Creation d'une table interne
DATA: IT_ECRM TYPE TT_ECRM,
CURRM TYPE BKPF-MONAT,
PREVM TYPE BKPF-MONAT,
PREVY TYPE BKPF-GJAHR.
****** Initialisation des variables
IF CURRY IS INITIAL.
CALL FUNCTION 'GET_CURRENT_YEAR'
EXPORTING
BUKRS = COMPANYCODE
IMPORTING
CURRM = currm " Current Fiscal Month
CURRY = curry " Current Fiscal Year
PREVM = prevm " Previous Fiscal Month
PREVY = prevy. " Previous Fiscal Year
ENDIF.
****** Récupération des données
" La requete de sélection
SELECT BUKRS
BELNR
GJAHR
BLART
BLDAT
BUDAT
CPUDT
CPUTM
AEDAT
USNAM
XBLNR
DBBLG
STBLG
BKTXT
HWAER
BSTAT
UP TO MAX_ROWS ROWS
INTO CORRESPONDING FIELDS OF TABLE IT_ECRM
FROM BKPF
WHERE BUKRS = COMPANYCODE
AND GJAHR = CURRY
AND (WHERE_TAB).
RETURN_TABLE[] = IT_ECRM[].
ENDFUNCTION.
It's the function body, as mentioned earlier it returns some lines from the table BKPF and it works fine when tested in SAP GUI, but when invoked through the .NET Connector the value of BUKRS returns ' I' instead of 'IP01'.
After a look at the structure of BKPF it seems that there is a difference between the structure I found in SAP (MANDT, BUKRS, ...) and the one I get when I look at the table.Metadata.LineType in .NET.
{STRUCTURE BKPF{BUKRS:CHAR4, MANDT:CHAR3, BELNR:CHAR10, GJAHR:NUM(4), BLART:CHAR2, BLDAT:DATE, BUDAT:DATE, MONAT:NUM(2), CPUDT:DATE, CPUTM:TIME, AEDAT:DATE, UPDDT:DATE, WWERT:DATE, USNAM:CHAR12, TCODE:CHAR20, BVORG:CHAR16, XBLNR:CHAR16, DBBLG:CHAR10, STBLG:CHAR10, STJAH:NUM(4), BKTXT:CHAR25, WAERS:CHAR5, KURSF:BCD[5:5], KZWRS:CHAR5, KZKRS:BCD[5:5], BSTAT:CHAR1, XNETB:CHAR1, FRATH:BCD[7:2], XRUEB:CHAR1, GLVOR:CHAR4, GRPID:CHAR12, DOKID:CHAR40, ARCID:CHAR10, IBLAR:CHAR2, AWTYP:CHAR5, AWKEY:CHAR20, FIKRS:CHAR4, HWAER:CHAR5, HWAE2:CHAR5, HWAE3:CHAR5, KURS2:BCD[5:5], KURS3:BCD[5:5], BASW2:CHAR1, BASW3:CHAR1, UMRD2:CHAR1, UMRD3:CHAR1, XSTOV:CHAR1, STODT:DATE, XMWST:CHAR1, CURT2:CHAR2, CURT3:CHAR2, KUTY2:CHAR4, KUTY3:CHAR4, XSNET:CHAR1, AUSBK:CHAR4, XUSVR:CHAR1, DUEFL:CHAR1, AWSYS:CHAR10, TXKRS:BCD[5:5], LOTKZ:CHAR10, XWVOF:CHAR1, STGRD:CHAR2, PPNAM:CHAR12, BRNCH:CHAR4, NUMPG:NUM(3), ADISC:CHAR1, XREF1_HD:CHAR20, XREF2_HD:CHAR20, XREVERSAL:CHAR1, REINDAT:DATE, RLDNR:CHAR2, LDGRP:CHAR4, PROPMANO:CHAR13, XBLNR_ALT:CHAR26, VATDATE:DATE, XSPLIT:CHAR1, PSOTY:CHAR2, PSOAK:CHAR10, PSOKS:CHAR10, PSOSG:CHAR1, PSOFN:CHAR30, INTFORM:CHAR4, INTDATE:DATE, PSOBT:DATE, PSOZL:CHAR1, PSODT:DATE, PSOTM:TIME, FM_UMART:CHAR1, CCINS:CHAR4, CCNUM:CHAR25, SSBLK:CHAR1, BATCH:CHAR10, SNAME:CHAR12, SAMPLED:CHAR1, EXCLUDE_FLAG:CHAR1, BLIND:CHAR1, OFFSET_STATUS:CHAR2, OFFSET_REFER_DAT:DATE, PENRC:CHAR2, KNUMV:CHAR10}}
I just tried with another client-dependent table that exists in my basis system: HRH1222. In this case DDIF_FIELDINFO_GET returns all 11 fields including the MANDT field at position 0001. So everything ok here. And NCo 3.0 is using the output of DDIF_FIELDINFO_GET for constructing its structure information.
A possible explanation what might be the problem in your case: I heard that a certain consulting company (Tata Consulting?) has in a few customer projects modified the standard SAP function module DDIF_FIELDINFO_GET to suppress "unwanted" fields. Among these fields were fields that could carry passwords -- and the MANDT field!
If you have such a modification in your backend, that would explain the behavior we see here...