Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Updating IDoc status to 53

Former Member
0 Kudos

Hi,

I've written a Posting program to read the Inbound Idoc and Post the data to VL32N. The Posting program has a logic of adding a new line item to Inbound Delivery(VL32N). In this program i'm using a BDC {Call transaction Method}.

My problem is when we trigger the IDoc from XI, the new line-item is added to the Delivery but the Status is showing as 64 its not showing 53 {After Call transaction, i have updated the IDOC_STATUS table with Status 53 in the Program, still the Status not showing as 53}.

But when i trigger the same IDoc through WE19, its adding a new line-item to the delviery with status 53.

Can i know if i'm missing anything in the configuration/ and any extra logic has to be built in my Posting Program.

Please find the below links,

http://help.sap.com/saphelp_nw04/helpdata/en/78/21761c51ce11d189570000e829fbbd/frameset.htm

Note:

The inbound function module that uses an ALE enabled transaction must pass the IDoc number to the transactionu2019s IDoc memory variable before calling the transaction.

==> Which Memory ID will be used for VL32N.

Is there any problem with the LUW of Call transaction. Please share your comments on it.

Thanks in Advance,

Ajay Kumar Chippa

Edited by: ajay.chippa on Aug 23, 2010 10:23 AM

8 REPLIES 8

Former Member
0 Kudos

it seems the problem occurs when you are triggering Inbound Idoc from XI dirctly.

please check the receiver port once. it should be SAP+sysid ex: SAPP01.

Regards,

Suresh

0 Kudos

Thanks Suresh for your quick response...

The PORT Configuration is correct and the sending/ Receiver Ports are correct.

Pawan_Kesari
Active Contributor
0 Kudos

A setting in Partner profile decides if inbound Idoc when created goes immediately for processing or it stays in system (in status 64) until it is posted by user or backgroud program.

Your Idocs when created using XI system remains in 64 status is normal. You can use transaction BD87 or BD20 to process these IDocs, processing your IDoc means executing function modules for each one of them.

If want to process these Idoc as they come in SAP, you need to change setting in WE20. Double click in the message type in WE20 and on 'Inbound options' table tab choose 'Trigger Immediately' option button.

Regards,

Pawan.

Edited by: Pawan Kesari on Aug 23, 2010 3:15 PM

0 Kudos

Thanks Pawan,

Yes i'm aware of the settings in Partner profile , i have checked the settings and its 'Trigger Immediately'.

As of now also the Call transaction is working but the status is not updated to 53 {Which i'm manually updating it in the Program}.

0 Kudos

Ajay,

Try debugging the function module and check if status 53 is there in status table.

Regards,

Pawan.

0 Kudos

Thanks Pawan,

They are two things to Note.

If i run the IDoc with WE19, Using

1) Standard Inbound : Its updating the Delivery (BDC Call transaction METHOD), but the Status is still 64

2) Inbound Function Module : Its updating the Delivery (BDC Call transaction METHOD), and the Status is 53.

In both the cases its updating the Delivery, but the problem is in Status Updation.

Hope there is something do be done while using the Call transaction in ALE...

Thanks & Regards,

Ajay

Former Member
0 Kudos

Hi,

how is your own program hooked to the SAP Idoc processing?

Is it called in a user exit of the Idoc or as function module assigned to a process code in WE20, a stand alone program?

If so how is your program triggered?

How do you set the status information in your coding?

If you use WE19 in the two ways are you sure the same function module is called?

Although I can only guess what you are doing try to use function modules EDI_DOCUMENT_OPEN_FOR_PROCESS, EDI_STATUS_ADD_BLOCK, EDI_DOCUMENT_STATUS_SET, EDI_DOCUMENT_CLOSE_PROCESS to set messages and status to the idoc. Debug the open function module. Then you can see if it Idoc is still locked at the point of time.

Kind Regards

Michael

Former Member
0 Kudos

When using call transaction within function modules for inbound IDoc processing we have to distinguish between ALE-enabled transactions and other transactions. ALE-enabled transactions have basically logic to update the IDoc status along with the updates triggered via the call transaction (so in the same [LUW|http://help.sap.com/saphelp_nw70ehp1/helpdata/en/41/7af4bfa79e11d1950f0000e82de14a/frameset.htm]).

You can easily see why this is important. Let's take a simple scenario of an interface where we create new sales orders without any proper reference data to identify duplicates via an IDoc interface using call transaction. If we'd do this via a non-ALE enabled transaction, we could first successfully create the sales order on the database (persistent and committed change), but then for some reason our program crashes and the IDoc status update doesn't happen. This is bound to create some duplicate orders until somebody recognizes this situations...

So the expectation is that if you have an ALE-enabled transaction, the IDoc status update will be handled via the called transaction (successful postings). I strongly recommend reading the [ALE Programming Guide - Using Call Transaction|http://help.sap.com/saphelp_nw70ehp1/helpdata/en/78/21761c51ce11d189570000e829fbbd/frameset.htm] to get some insight and to ensure that you set your parameters right.

Furthermore, check your configuration settings for your inbound function module in BD51 (make sure not to choose <em>1 - Individual input</em> if you don't have an ALE enabled transaction, otherwise choose <em>2 - Individual input with IDoc lock in call transaction</em>). I thought there was some easy way to figure out if a transaction was ALE enabled, but I don't remember. However, you can always start an ABAP runtime analysis on (or debug) your IDoc processing and see if the transaction fires the function module IDOC_INPUT_CLOSE (which means it's an ALE-enabled transaction).

A classic example for an ALE-enabled transaction is the mentioned sales order creation/change, i.e. VA01 (idoc_input_orders) and VA02 (idoc_input_ordchg). My guess is that your settings in BD51 are wrong along and/or some of your export parameters of the IDoc function module are not filled correctly.