Error: RE Qty. transferred exceeded 1 PC in BAPI_GOODSMVT_CREATE

[Former Member]

Hi,

We are doing a reversal for a work order using the movement type 'Z62' which is a customised movement type for a material from the syclo mobile. While doing the reversal, we are getting this error in the return table paramater of the BAPI "BAPI_GOODSMVT_CREATE".

Example: The work order number is 2000001181, the material number is 50014360, movement type 'Z62', Quantity 1, GM_CODE is '05'. For this scenario we are getting the above error.

We also tried with the following option as well with the BAPI_GOODSMVT_CREATE. Example: The work order number is 2000001181, the material number is 50014360, movement type '262', Quantity 1, GM_CODE is '03'. For this scenario we are getting the same error only. We are not able to post the material document succesfully through the BAPI call.

When we create a material document for the above test case in SAP manually, we are able to post the material document for the movement type '262' as well as for 'Z62'.

We are doing the reversal and not the cancel of the material document which is being posted already in SAP. We are sending the details of the material and the work order at the item table parameter and the GM_CODE as '05' at the header level. We tried with the GM_CODE '03' as well.

For both GM_CODE we are getting the same error as "RE Qty. transferred exceeded 1 PC". The materials against which we are doing the reversal are already consumed in another work order. We want to reverse the consumed material with the new work order number. The work order number is alone is different but not the material number and the quantity.

If we try to do the same with the BAPI: BAPI_GOODSMVT_CREATE we are facing issue.

Please let us know the best way to pass the movement type 'Z62' which is similar to the movement type '262' in functioanlity in the backend in the BAPI to create the material document.

Thanks,

Mohan.

[Former Member]

Hi

That error should mean there aren't the quantity you need to transfer in the wharehouse

Max

[Former Member]

Hi Max,

Thanks for your reply.

We are able to post the material document successfully for the above scenario in SAP manually.

Please clarify my doubt. If we don't have the stock in the warehouse, whether we will get the same error while posting the material document in SAP or we wont get that error? manually.

If we are able to post it successfully in SAP manually, then how can we avoid this error using the BAPI_GOODSMVT_CREATE.

Please specify if there is/are any more fields need to be send along with the existing values.

Thanks,

Mohan.

[Former Member]

No

You should have the same error in both situations: the behavior of bapi is the same of transaction,

If you can post it manually, it could mean some data are not transfering to the bapi or bapi doesn't support that posting: how do you call the bapi?

Max

[Former Member]

Hi Max,

The values which we are passing to the BAPI are as follows:

*IS_GOODSMVT_HEADER*

PSTNG_DATE -- System Date from Mobile

DOC_DATE -- Same

IV_GOODSMVT_CODE

GM_CODE --- '05'

IT_GOODSMVT_ITEM

MATERIAL --- 50014369

PLANT --- 1200

STGE_LOC --- C001

BATCH --- USADO/NEUVO

MOVE_TYPE --- 262 / Z62

ENTRY_QNT --- 1

ENTRY_UOM --- PC

ORDERID --- 20001181

RESERV_NO --- Material's Reservation number

ACTIVITY --- Task ID of the order

RES_ITEM --- Material reservation item number

XSTOB -- This flag will be set to true 'X' if the movement type is '262' and blank for rest of the movement types

We used the transaction 'MB1C' for posting the material document manually in SAP.

IT_GOODSMVT_SERNO

MATDOC_ITM

SERIALNO

UII

These are the values which are being passed from the client to SAP. This BAPI is called when we do the goods issue (Consumption) in the mobile device.

We tried with the GM_CODE - '03' as well. At this point of time also, we are getting the same error. We tried doing the material document posting for 'Z62' it is getting converted into '261' or '262' movement type in MIGO transaction in SAP. Because of this only, we changed the GM_CODE to '05'. In MB1C, we are able to post the material document with the movement type as such what we are passing from the client.

Please let me know, if there is any change that needs to be done in the way we are calling the BAPI for posting the Material document.

Thanks,

Mohan.

[Former Member]

Hi Experts,

We debugged the standard BAPI to find the reason for the issue "Error: RE Qty. transferred exceeded 1 PC ", we found the following.

In the standard FM "MB_CHECK_MATERIAL_STOCKS", there is a form 'VERFUEGBARKEITSRECHNUNG' inside which the internal table content varies for the manual posting and during the posting from client.

We debugged while posting the material document manually as well. When we are doing the posting manually, the internal table 'VFBL[]' has only two rows of entry called MCHB-CSPEM and MARD-SPEME.

But when we try to do the posting from the client, the same internal table 'VFBL[]' has four rows of entries as shown below.

MCHB-CSPEM -- 1st row

MARD-SPEME -- 2nd row

MRES-ENMNG -- 3rd row

MRES-BDMNG -- 4th row

We are not sure from where the 3rd and 4th row got appended to the internal table. When we delete the 3rd and 4th row during run time, the material document is getting created successfully.

Please let us know, where this internal table is getting populated and based on what condition. Please let us know how to fix this issue.

<removed by moderator>

Thanks,

Mohan.

Edited by: Thomas Zloch on Oct 20, 2011 9:44 PM

[former_member220430]

Hi Mohan,

Sorry to reply to this old thread but I have only found a few on this topic and I encounter the same issue currently. The only difference is that the additional rows in my case are EKLA-LWSBB and EKLA-LWMNG. Have you found out where the additional rows come from?

Cholen

[satyadev41]

Is the issue resolved ? I'm facing the same issue. we are doing Post Goods Issue(PGI)  through Call transaction VL02N using BDC data. When the manual PGI is done (in VL02N) using the same BDC data we are able to do PGI succesfully. I found the same difference in entries in the internal table VFBL. Below are the entries

MCHB-CLABS

MCHB-CVMLA

MARD-LABST

MARD-VMLAB

EKPO-WAMNG

Please help us to resolve if this issue is solved.