Problem with RFC function module from R/3 to CRM

[Former Member]

Hi, i have a RFC function module created in R/3, this is the code:

function Z_CRM_PRODUCTO_INTERLOCUTOR.

*"----

-

---

""Interfase local

*" IMPORTING

*" VALUE(GV_VKORG) TYPE VKORG

*" VALUE(GV_VTWEG) TYPE VTWEG

*" VALUE(GV_MATNR) TYPE MATNR

*" VALUE(GV_KUNNR) TYPE KUNNR_V

*" EXPORTING

*" VALUE(GV_KDMAT) TYPE MATNR_KU

*" VALUE(GV_POSTX) TYPE KDPTX

*" EXCEPTIONS

*" NOT_FOUND

*"----

-

---

UNPACK GV_MATNR TO GV_MATNR.

UNPACK GV_KUNNR TO GV_KUNNR.

select single KDMAT POSTX

into (GV_KDMAT, GV_POSTX) from KNMT

where VKORG = GV_VKORG

and VTWEG = GV_VTWEG

and KUNNR = GV_KUNNR

and MATNR = GV_MATNR.

IF sy-subrc <> 0.

RAISE NOT_FOUND.

ENDIF.

endfunction.

When i call this function from CRM, i do it like this:

CALL FUNCTION 'Z_CRM_PRODUCTO_INTERLOCUTOR'

DESTINATION LV_RFCDEST

EXPORTING

GV_VKORG = lv_vkorg

GV_VTWEG = ORGMAN_H-DIS_CHANNEL

GV_MATNR = ORDERADM_I_WRK-ORDERED_PROD

GV_KUNNR = WA_DATOS_PER-N_PAGADOR

IMPORTING

GV_POSTX = IT_POS_LINE-DESCRIPCION

GV_KDMAT = IT_POS_LINE-material

EXCEPTIONS

not_found = 1.

where:

it_pos_line-descripcion type string

it_pos_line-material type string.

Well, my problem is that when debugging, in R/3 the 2 return values have the correct value, but when they are passed to CRM they have only one position.

As i've been told, it was working ok, but it's being wrong since we made a ¿conversion to unicode?. Maybe I should change the type of return ???

Thanks in advance !!!

[Former Member]

Hello Maria,

Make sure you define your parameters in CRM exactly the same way as in R3, do not use type string here.

So:

it_pos_line-descripcion type C char 40,

it_pos_line-material type C length 35.

Kind regards,

John.

[Former Member]

that's what i suppose but as the consultant told me, some days ago it was working ok. Is it possible ???

I'll change the definitions. thanks a lot !!!!

[Former Member]

Hi Maria,

When changing to unicode these problems arise easily as the length of a field might change. But besides any unicode issues, the type definitions in the calling system and the called system should be exaclty the same to prevent these kind of problems.

Kind regards,

John.