Picking confirmation using IDOC

Hi,
I have to create pick confirmation from WMS to SAP. I'm uing SHPCON message type and DELVRY03 basic type and idoc_input_delvry FM from my development. very this is fine i have got all fields reqired in basic type the problem is
1. IF WMS don;t send any pick quantity for line item or if it sends '0' quantity the line item has to be deleted from the Delivery.
2. If in case pick qty is more than the delivery qty it should generate an error.
3.Thre is a concept called Batch split in Outbound delivery. What it the functionality of the batch split.
Can any one come accross these kind of scenario plz help me.
Thanks & Regards,
Naren.

i think u r going to generate the 51 status for the conditions in ur idoc
for 1 and 2 .
Pick quantity is not maintained for the table . The reference for this is the Delivered Quantity.
Goto delivery (vl02n) and enter a delivery now see the delivery qty for a particular item .
say 16 for Del qty now keep pick qty as 0.
and save .
now see the over all pick status . this will be 'A'.
repeat the same process and now keep pick qty as 4 .
and save .
now see the over all pick status . this will be 'B'.
this becomes 'C' means completely picked if the pick qty is eq 16 in this scenario.
i cannot pick 17 as this is out of scope error will be triggered.
Pickup the segment which is populating the pick qty and keep the options above u
and compare it with delivered qty.
for 3 ..
refer this..
Let me put it this way.
The process is suppose a sales order is there
and that is scheduled
16 on dec 29
24 on dec 30
if i create a delivery as of today ie dec 29
then the pick qty is 16
and i create a delivery on dec 30 ie tommow
then the pick qty is 24.
total quantity for that item is 40 (break
16+24).
For this break up u need to look into Vbep
Entries .
This is the process of scheduling where in two
deliveries are created for one sales order .(as
example).
regards,
vijay.

Similar Messages

Enhancement for picking confirmation inbound idoc

Hi Friends,
I'm using Message type SHPCON , Basic Type Delvry03 and process code DELV for picking confirmation. where as i have to extend the basic type for a field LIPS-UECHA ( Batch split Indicator) which is not avilable in basic type. which userexit or badi i have to use to plopoualte this filed data in to SAP? Can any one help.
Thanks&Regards,
Naren.

Hi,
You exttend the basic IDOC type DELVRY03. To which Segment you want to add this under E1EDL24 or E1EDL37. Change the process code inorder to fetch the data from the application.
WE31 to add the field to the segments and create a new segment
WE30 extend the basic type and add the newly created segment
WE82 to add the extended basic type to Message type.
change the process code.
Regards
Kannaiah

Picking Confirmation using DELVRY03

Hi,
I am trying to post an inbound IDOC using handling units. But the IDOC fails with an error message " There is already a handling unit 112345680000001063 posted for GR without stock " . When I try to do the PACK using the same HU in VL02N it allows me to do it but fails when I try to do the same using IDOC. Am I missing some information in the IDOC ? Pls help
I am using basic type as DELVRY03, Message type as SHPCON and FM as Idoc_input_delvry.

i think u r going to generate the 51 status for the conditions in ur idoc
for 1 and 2 .
Pick quantity is not maintained for the table . The reference for this is the Delivered Quantity.
Goto delivery (vl02n) and enter a delivery now see the delivery qty for a particular item .
say 16 for Del qty now keep pick qty as 0.
and save .
now see the over all pick status . this will be 'A'.
repeat the same process and now keep pick qty as 4 .
and save .
now see the over all pick status . this will be 'B'.
this becomes 'C' means completely picked if the pick qty is eq 16 in this scenario.
i cannot pick 17 as this is out of scope error will be triggered.
Pickup the segment which is populating the pick qty and keep the options above u
and compare it with delivered qty.
for 3 ..
refer this..
Let me put it this way.
The process is suppose a sales order is there
and that is scheduled
16 on dec 29
24 on dec 30
if i create a delivery as of today ie dec 29
then the pick qty is 16
and i create a delivery on dec 30 ie tommow
then the pick qty is 24.
total quantity for that item is 40 (break
16+24).
For this break up u need to look into Vbep
Entries .
This is the process of scheduling where in two
deliveries are created for one sales order .(as
example).
regards,
vijay.

Production order confirmation thru IDoc , IDoc has been processed twice

Hi Experts,
Good day.
I have a problem with my Production orders confirmation using IDoc automatic processing.
I have an IDoc that has successfully confirmed a Production order, the Idoc has a status of 53.
However, after a month, the Idoc has been used again on a different Production order confirmation, and the IDoc resulted again to status 53.
Could you kindly confirm if this a SAP standard behavior or an error? If this is an error, is there any available SAP notes that I can use.
Here is the spec of our system:
ECC 5.00 - SP SAPKH50015
Please kindly provide us your idea on this.
Thank you very much.
Kind regards,
Rosalinda Ines Aben
PP Support

Hi Rosalinda, i have the same problem. You found some solution ?
Thanks a lot !!!.
Federico Cicerchia

Outbound Picking Confirmation Idoc - which one?

Hi all,
I havea client who desires to send a picking confirmation notice to their customer once a order is picked. In essence, it seems similar to an Delivery notification, for which we are using idoc DELVRY01/SHPCON.
Is this Idoc suitable for a picking notification, or is there a better one? I have spotted WMTCID03 (confirm Transfer Order) but the details in this idoc are insufficient for the clients requirements?
Any thoughts would be greatfully appreciated. Points awarded for a suitable answer.
Cheers,
Steve

The client dropped the requirement.

Delete non-picked items in delivery using iDoc

Hello gurus,
I'm integrating SAP ECC and external WM solutions using iDocs. The outbound delivery is created in SAP ECC and sent to WMS using DESADV iDoc. The picking is performed in WMS and the list of shipped items with batch numbers are returned to SAP and Goods Issue is posted. iDoc WHSCON is supposed to be used for that purpose.
The problem is that in case if not all the line items were shipped it's necessary to delete them from the delivery because otherwise GI will not be posted. But the non-picked items no longer exist in the response iDoc WHSCON so it's even impossible to set QUALF=DEL for these items. WMS sends back only actually shipped items in iDoc, and not the deleted ones.
Do you have any solutions for overcoming this problem?
Maybe there is any BAPI or iDoc qualifier that will allow to delete all items from the delivery so that they will be recreated by the same iDoc? Or there is any checkbox in SAP that will automatically delete unpicked items during posting of GI?
Thanks!

hi
in this both error comes ,
1)E VL 609 20 Delivery has not yet been put away / picked (completely)
a) picking quantity not entered , in delivery , first you enter the picking quantity ,
you create the 2 lines for sale order , so create for one line item for delery , go to vlo1n enter shipping point , sale order number line item number 1 to 1 enter press enter system will take only one item in delivery then you enter the picking quantity , and pgi ,
in delivery two line item only line item enter picking quantity and another line item not enter the picking quantity , it not possible to pgi , both line item you enter the picking quantity ,
you create the same delivery number for 2line item , so first complete the 1st line item pgi and , go to vl02n and enter , click on menu bar out bound deliverrs-delivery sale order -enter sale order number and line item , and do the pgi ,
2)VL 608 20 Delivery has not yet been completely processed by WM
you process activate the wm , so you can do the lt03 , then it will come vlo2n and check the picking quantity it will come auto matically

Vendor confirmation tab update using idoc ORDERS02

Hi all,
This is the first time i am working on idocs.
I have a requirement where i have to update the vendor confirmation tab in ME22n(Purchase order), I am using IDOC type ORDERS02. and i am using segment E1EDP20 to update quantity,date and reference no. This is working fine.
Now i need to update 2 more fields in the tab i.e confirmation category(EKES-EBTYP) and Date category of delivery date in vendor confirmation(EKES-LPEIN).But i dint find these fields in segment E1EDP20.
My question is whether these 2 fields are available in any other segment?
or should i extend the segment E1EDP20 ?is it the correct segment to be extended...
Please provide the inputs....<removed by moderator>
Regards,
Greeshma.
Edited by: Thomas Zloch on Feb 22, 2012

Hi,
I have a questions for you and that will help me provide better solution .
a) Is vendor providing you the Confirmation category or are you expecting to get this information from Vendor ?
There are many points at which this information can be entered in ME22N.
1. When the Vendor Acknowledege your PO(If the Acknowledgment required is selected) .
2. When the Vendor request a change in schedule due to his own priorities .
3. When the Vendor actually does a goods issue and you are ready to do a Goods receipt.
In all these cases you update the system with confirmation category .In most cases this is the last phase of PO processing where you do the goods receipt and simultaneoulsy update the confirmation category. You are geting the quantity and the date updated from your schedule lines currently and since Schedules lines does not contain the confirmation category you are not getting it in E1EDP20.Confirmation category in most business scenarios is a mere stastical data rather than concrete data like schedule lines.
Depending on 1/2/3 you should be approching the solution. 1.If you want to update the confirmation category during the Order acknowledgment Use BAPI_PO_CHANGE and call it from the PI or middleware or(3) if during the Goods receipt then call the Exit of MIGO to get the PO populated if not exit then write a custom program to see all the Goods receipt and update the PO confirmation category accordingly (Remember this is a statstical data ). Although i highly doubt that the confirmation category will be provided by vendor it is the Buyer who will be determining it and that is why it is not there in the Standard Idoc.I shall not prefer the IDOC extension.
You can have a discussion with your Functional/Customer to figure out the best approcah. Word of Caution : Analyze before you extend an Idoc .
Thanks,
Anjaneya .
Edited by: Anjaneya Bhardwaj on Feb 24, 2012 7:33 AM

Picking not done for a serialized material using Idoc type SHPCON/DELVRY03

Hi All,
I am using Idoc of type SHPCON/DELVRY03 to do the picking for an outbound delivery.
The value 'PIC' is populated in the qualifier of segment E1EDL18 . In order to update the batch number of the material in a delivery the qualifier of segment E1EDL19 is populated with value 'BAS' .
To update the serial numbers for a serialized material in an outbound deliverfy , BDC for transaction vl02n is used. Also the segment E1EDL24 is populated with material no. POSNR and other details , then segment E1EDL11 is having the value of serial no. Similarly for other serial number there is one more segement E1EDL24 with same material no. but E1EDL11 with other serial number.
The issue is that after the Idoc is successfully processed , picking quantity is updated only for one serial number for a serialized material of the outbound delivery. The picking quantity for other serial number is not updated . Initially the delivered quantity for the serialized material was 2 but after processing the Idoc the picking qunatity updated is 1 ( for one serial number only ).
Please provide any pointers on this.
Thanks & Regards,
Tanushri.

The firs thing I would do is verify the config. Make sure the message type of the created IDocs matches the message type to which the filter is applied in the distribution model. If everything looks ok, place break-points at the following locations:
In FM MASTER_IDOC_DISTRIBUTE, on the call PERFORM DIST_MODEL_READ_FOR_MESTYP. This subroutine reads the filters from the distribution model. Verify the values in internal table RECEIVERS_AND_FILTERS are correct.
In FM MASTER_IDOC_DISTRIBUTE, in FORM IDOC_SELECTION_AND_SERVICES, on the call to FM IDOC_DATA_APPLY_FILTER_VALUES. This function should return the filtered results. IDOC_DATA contains the data segments of your IDoc and CONDITION_BLOCKS contains the filter.
When you run BD21, you should hit these break-points.

User-exit / BAdi for Pick Confirmation

Does anyone know any user-exit/BAdi that can be used on 'Pick confirm all entries' option in Delivery change (VL02N) in ECC6.0 environment.
Thanks

Hi,
Try out from the following user exits-----
Transaction Code - VL02N                    Change Outbound Delivery
Exit Name           Description
V02V0001            Sales area determination for stock transport order
V02V0002            User exit for storage location determination
V02V0003            User exit for gate + matl staging area determination (headr)
V02V0004            User Exit for Staging Area Determination (Item)
V50PSTAT            Delivery: Item Status Calculation
V50Q0001            Delivery Monitor: User Exits for Filling Display Fields
V50R0001            Collective processing for delivery creation
V50R0002            Collective processing for delivery creation
V50R0004            Calculation of Stock for POs for Shipping Due Date List
V50S0001            User Exits for Delivery Processing
V53C0001            Rough workload calculation in time per item
V53C0002            W&S: RWE enhancement - shipping material type/time slot
V53W0001            User exits for creating picking waves
VMDE0001            Shipping Interface: Error Handling - Inbound IDoc
VMDE0002            Shipping Interface: Message PICKSD (Picking, Outbound)
VMDE0003            Shipping Interface: Message SDPICK (Picking, Inbound)
VMDE0004            Shipping Interface: Message SDPACK (Packing, Inbound)
No of Exits:         17
Regards,
Prashant.

Creation of PO using IDOC's

Hi,
I am trying to create a PO, using IDocs, in the SAP system. The IDoc will come from a non-SAP system - hence, this is an inbound interface.
Can someone please tell me which Message Type / IDoc Type I should use?
As well, I need to create Characteristics for the Purchase Order. So, I need an IDoc that allows me to create these.
Two options (using existing IDocs):
1. ORDERS/ORDERS05
I have read some of the help documentation and some of the messages posted on this forum and found that the ORDERS/ORDERS05 is used for outbound PO IDocs, and inbound SO IDocs.
Can someone please confirm or correct me? So, this option is OUT.
2. PORDCR/PORDCR05
Apparently, PORDCR/PORDCR05 can be used for inbound PO. However, it does not contain segments for Characteristics. Hence, I will need to extend the IDoc. However, there aren't any useful user-exits to handle the creation of Characteristic values!
Any ideas or suggestions will be greatly rewarded .
Thanks
Bobby

on your points
#1is correct.
#2 yes, if you need any other functionality you need to extend the IDOC. alternately look at BAPI_PO_CREATE* BAPIs to see if they fulfil your requirements

'Picking request file' and 'Picking confirmation file'...

Hi,
Suppose the business scenario like this:
After delivery created in SAP system, then the system generate an 'Picking request file' to 3rd party shipper service provider.
And then 3rd party shipper service provide will generate an 'Picking confirmation file' to our SAP system.
Upon receiving the picking confimation, then further invoice or PGI will be done.
In your previous experience, what kind of data exchaging mechanism is used for this kind of exchanging??
And what the exact content or data in your case for these 2 documents??
One is Picking request..
One is Picking confirmation...
Thank you very much.

You can explore using EDI
u2022 943: Receiving Schedule
u2022 944: Receiving Confirmation
regards
Biju

Partial Pick Confirming Sales Order

Hi Folks,
I have a requirement where I have to Pick Confirm and Ship confirm Sales Order through API.
1. When the quantites to be picked are same as quantity ordered the code seems to work just fine.
But suppose in my example my quantity in SO line is 50 and I want to partially Ship confirm the lines lets say 20 quantites.
then which API i need to use?
The approach I am following is while pick confirming I am passing 20 quantites only and the ship confirming it.
I researched and found that we can use the following API to update shipping attributes 'WSH_DELIVERY_DETAILS_PUB.Update_Shipping_Attributes' but when I run it (I tried before and after Pick confirm) the API runs fine but no changes are getting affected and the code Pick confirms all the quantity.
Could some please help me with this.
Please find the codes for pick confirm and updating shipping attributes
Pick confirm code
DECLARE
lv_order_num number := 700145812;
vMoveOrderLineId NUMBER;
p_pick_conf_qty NUMBER;
pStatus VARCHAR2(100);
pMsgData VARCHAR2(4000);
v_movehdr_rec INV_MOVE_ORDER_PUB.TROHDR_REC_TYPE;
v_movehdr_val_rec INV_MOVE_ORDER_PUB.TROHDR_VAL_REC_TYPE;
v_moveln_tbl INV_MOVE_ORDER_PUB.TROLIN_TBL_TYPE;
v_moveln_tbl_p INV_MOVE_ORDER_PUB.TROLIN_TBL_TYPE;
v_moveln_zero_tbl INV_MOVE_ORDER_PUB.TROLIN_TBL_TYPE;
v_moveln_zero_tbl_p INV_MOVE_ORDER_PUB.TROLIN_TBL_TYPE;
v_moveln_tbl_d INV_MOVE_ORDER_PUB.TROLIN_TBL_TYPE;
v_moveln_tbl_o INV_MOVE_ORDER_PUB.TROLIN_TBL_TYPE;
v_moveln_val_tbl INV_MOVE_ORDER_PUB.TROLIN_VAL_TBL_TYPE;
v_mold_tbl INV_MO_LINE_DETAIL_UTIL.G_MMTT_TBL_TYPE;
v_mold_tbl_p INV_MO_LINE_DETAIL_UTIL.G_MMTT_TBL_TYPE;
l_mold_tbl INV_MO_LINE_DETAIL_UTIL.G_MMTT_TBL_TYPE;
l_moveln_tbl INV_MOVE_ORDER_PUB.TROLIN_TBL_TYPE;
l_trolin_rec INV_MOVE_ORDER_PUB.TROLIN_REC_TYPE;
l_trolin_tbl INV_MOVE_ORDER_PUB.TROLIN_TBL_TYPE;
l_return_status VARCHAR2(240);
l_msg_count NUMBER;
l_msg_data VARCHAR2(2000);
l_move_hdr_id NUMBER;
l_move_order_no NUMBER := 0;
v_return_values VARCHAR2(2000) := FND_API.G_TRUE;
v_move_hdr_rec INV_MOVE_ORDER_PUB.TROHDR_REC_TYPE;
v_move_hdr_val_rec INV_MOVE_ORDER_PUB.TROHDR_VAL_REC_TYPE;
v_api_pick_confirm NUMBER;
cv_fail VARCHAR2(100) := 'Fail';
cv_success VARCHAR2(100) := 'Success';
g_user_id number;
g_resp_id number;
g_resp_appl_id number;
p_user_name varchar2(100) := 'SYSADMIN';
p_resp_name varchar2(100) := 'Order Management Super User';
p_mo_apps varchar2(100) := 'ONT';
CURSOR c_mmtt_recs(vMoveOrderLineId NUMBER) IS
 SELECT transaction_header_id,
 transaction_temp_id,
 source_code,
 source_line_id,
 transaction_mode,
 lock_flag,
 last_update_date,
 last_updated_by,
 creation_date,
 created_by,
 last_update_login,
 request_id,
 program_application_id,
 program_id,
 program_update_date,
 inventory_item_id,
 revision,
 organization_id,
 subinventory_code,
 locator_id,
 transaction_quantity,
 primary_quantity,
 transaction_uom,
 transaction_cost,
 transaction_type_id,
 transaction_action_id,
 transaction_source_type_id,
 transaction_source_id,
 transaction_source_name,
 transaction_date,
 acct_period_id,
 distribution_account_id,
 transaction_reference,
 requisition_line_id,
 requisition_distribution_id,
 reason_id,
 lot_number,
 lot_expiration_date,
 serial_number,
 receiving_document,
 demand_id,
 rcv_transaction_id,
 move_transaction_id,
 completion_transaction_id,
 wip_entity_type,
 schedule_id,
 repetitive_line_id,
 employee_code,
 primary_switch,
 schedule_update_code,
 setup_teardown_code,
 item_ordering,
 negative_req_flag,
 operation_seq_num,
 picking_line_id,
 trx_source_line_id,
 trx_source_delivery_id,
 physical_adjustment_id,
 cycle_count_id,
 rma_line_id,
 customer_ship_id,
 currency_code,
 currency_conversion_rate,
 currency_conversion_type,
 currency_conversion_date,
 ussgl_transaction_code,
 vendor_lot_number,
 encumbrance_account,
 encumbrance_amount,
 ship_to_location,
 shipment_number,
 transfer_cost,
 transportation_cost,
 transportation_account,
 freight_code,
 containers,
 waybill_airbill,
 expected_arrival_date,
 transfer_subinventory,
 transfer_organization,
 transfer_to_location,
 new_average_cost,
 value_change,
 percentage_change,
 material_allocation_temp_id,
 demand_source_header_id,
 demand_source_line,
 demand_source_delivery,
 item_segments,
 item_description,
 item_trx_enabled_flag,
 item_location_control_code,
 item_restrict_subinv_code,
 item_restrict_locators_code,
 item_revision_qty_control_code,
 item_primary_uom_code,
 item_uom_class,
 item_shelf_life_code,
 item_shelf_life_days,
 item_lot_control_code,
 item_serial_control_code,
 item_inventory_asset_flag,
 allowed_units_lookup_code,
 department_id,
 department_code,
 wip_supply_type,
 supply_subinventory,
 supply_locator_id,
 valid_subinventory_flag,
 valid_locator_flag,
 locator_segments,
 current_locator_control_code,
 number_of_lots_entered,
 wip_commit_flag,
 next_lot_number,
 lot_alpha_prefix,
 next_serial_number,
 serial_alpha_prefix,
 shippable_flag,
 posting_flag,
 required_flag,
 process_flag,
 error_code,
 error_explanation,
 attribute_category,
 attribute1,
 attribute2,
 attribute3,
 attribute4,
 attribute5,
 attribute6,
 attribute7,
 attribute8,
 attribute9,
 attribute10,
 attribute11,
 attribute12,
 attribute13,
 attribute14,
 attribute15,
 movement_id,
 reservation_quantity,
 shipped_quantity,
 transaction_line_number,
 task_id,
 to_task_id,
 source_task_id,
 project_id,
 source_project_id,
 pa_expenditure_org_id,
 to_project_id,
 expenditure_type,
 final_completion_flag,
 transfer_percentage,
 transaction_sequence_id,
 material_account,
 material_overhead_account,
 resource_account,
 outside_processing_account,
 overhead_account,
 flow_schedule,
 cost_group_id,
 demand_class,
 qa_collection_id,
 kanban_card_id,
 overcompletion_transaction_id,
 overcompletion_primary_qty,
 overcompletion_transaction_qty,
 end_item_unit_number,
 scheduled_payback_date,
 line_type_code,
 parent_transaction_temp_id,
 put_away_strategy_id,
 put_away_rule_id,
 pick_strategy_id,
 pick_rule_id,
 common_bom_seq_id,
 common_routing_seq_id,
 cost_type_id,
 org_cost_group_id,
 move_order_line_id,
 task_group_id,
 pick_slip_number,
 reservation_id,
 transaction_status,
 transfer_cost_group_id,
 lpn_id,
 transfer_lpn_id,
 pick_slip_date,
 content_lpn_id
 FROM MTL_MATERIAL_TRANSACTIONS_TEMP
 WHERE move_order_line_id = vMoveOrderLineId;
l_moveln_fidx NUMBER;
l_moveln_lidx NUMBER;
n_mvln_cntr NUMBER;
l_Index NUMBER := 1;
v_records_in_mmtt NUMBER := 0;
REC C_MMTT_RECS%ROWTYPE;
BEGIN
select user_id
 into g_user_id
 from fnd_user
 where user_name = p_user_name;
select responsibility_id, application_id
 into g_resp_id, g_resp_appl_id
 from apps.fnd_responsibility_vl
 where responsibility_name = p_resp_name;
Apps.FND_Global.Apps_Initialize(g_user_id, g_resp_id, g_resp_appl_id);
MO_GLOBAL.INIT(p_mo_apps);
for mol in (select wda.delivery_id,
 wda.delivery_detail_id,
 wda.parent_delivery_detail_id,
 wdd.source_code,
 wdd.inventory_item_id,
 wdd.organization_id,
 wdd.ship_from_location_id,
 wdd.ship_to_location_id,
 wdd.requested_quantity,
 wdd.requested_quantity_uom,
 wdd.move_order_line_id,
 wdd.org_id,
 mtrl.quantity,
 mtrl.quantity_delivered
 from wsh_delivery_details wdd,
 wsh_delivery_assignments wda,
 oe_order_lines_all ol,
 oe_order_headers_all oh,
 mtl_txn_request_lines mtrl,
 mtl_txn_request_headers mtrh
 where wdd.source_line_id = ol.line_id
 and wdd.delivery_detail_id = wda.delivery_detail_id
 and ol.header_id = oh.header_id
 and wdd.move_order_line_id = mtrl.line_id(+)
 and mtrl.header_id = mtrh.header_id(+)
 and oh.order_number = lv_order_num) loop
 vMoveOrderLineId := mol.move_order_line_id;
 p_pick_conf_qty := mol.quantity - nvl(mol.quantity_delivered,0);
 SELECT COUNT(move_order_line_id)
 INTO v_records_in_mmtt
 FROM MTL_MATERIAL_TRANSACTIONS_TEMP
 WHERE move_order_line_id = vMoveOrderLineId;
 IF v_records_in_mmtt > 1 THEN
 pStatus := cv_fail;
 pMsgData := 'Wrong number of records in MMTT for the MOVE_ORDER_LINE_ID : ' ||
 vMoveOrderLineId;
 DBMS_OUTPUT.PUT_LINE('Multiple records in MMTT for move_order_line_id = ' ||
 vMoveOrderLineId);
 v_api_pick_confirm := 0;
 GOTO end_of_pkcnf;
 ELSIF v_records_in_mmtt = 0 THEN
 --means that the delivery is already pick confirmed
 pStatus := cv_success;
 DBMS_OUTPUT.PUT_LINE('No records in MMTT for move_order_line_id = ' ||
 vMoveOrderLineId ||
 ' hence it is already pick confirmed');
 v_api_pick_confirm := 0;
 GOTO end_of_pkcnf;
 END IF;
 SELECT mtrh.header_id, mtrh.request_number
 INTO l_move_hdr_id, l_move_order_no
 FROM mtl_txn_request_headers mtrh, mtl_txn_request_lines mtrl
 WHERE mtrh.header_id = mtrl.header_id
 AND mtrl.line_id = vMoveOrderLineId;
 DBMS_OUTPUT.PUT_LINE('Obtained MTRH.HEADER_ID = ' || l_move_hdr_id ||
 ' MTRH.REQUEST_NUMBER = ' || l_move_order_no ||
 ' for move_order_line_id = ' || vMoveOrderLineId);
 INV_MOVE_ORDER_PUB.GET_MOVE_ORDER(p_api_version_number => 1.0,
 p_init_msg_list => FND_API.G_FALSE,
 p_return_values => v_return_values,
 x_return_status => l_return_status,
 x_msg_count => l_msg_count,
 x_msg_data => l_msg_data,
 p_header_id => l_move_hdr_id,
 p_header => l_move_order_no,
 x_trohdr_rec => v_move_hdr_rec,
 x_trohdr_val_rec => v_move_hdr_val_rec,
 x_trolin_tbl => v_moveln_tbl,
 x_trolin_val_tbl => v_moveln_val_tbl);
 COMMIT;
 DBMS_OUTPUT.PUT_LINE('Return status of INV_MOVE_ORDER_PUB.GET_MOVE_ORDER = ' ||
 l_return_status);
 IF l_return_status != FND_API.G_RET_STS_SUCCESS THEN
 pStatus := cv_fail;
 pMsgData := 'Failed to get move order inv_move_order_pub.get_move_order for MOVE_ORDER_LINE_ID : ' ||
 vMoveOrderLineId;
 GOTO end_of_pkcnf;
 END IF;
 OPEN c_mmtt_recs(vMoveOrderLineId);
 FETCH c_mmtt_recs
 INTO rec;
 CLOSE c_mmtt_recs;
 v_mold_tbl(1).transaction_header_id := rec.transaction_header_id;
 v_mold_tbl(1).transaction_temp_id := rec.transaction_temp_id;
 v_mold_tbl(1).source_code := rec.source_code;
 v_mold_tbl(1).source_line_id := rec.source_line_id;
 v_mold_tbl(1).transaction_mode := rec.transaction_mode;
 v_mold_tbl(1).lock_flag := rec.lock_flag;
 v_mold_tbl(1).last_update_date := rec.last_update_date;
 v_mold_tbl(1).last_updated_by := rec.last_updated_by;
 v_mold_tbl(1).creation_date := rec.creation_date;
 v_mold_tbl(1).created_by := rec.created_by;
 v_mold_tbl(1).last_update_login := rec.last_update_login;
 v_mold_tbl(1).request_id := rec.request_id;
 v_mold_tbl(1).program_application_id := rec.program_application_id;
 v_mold_tbl(1).program_id := rec.program_id;
 v_mold_tbl(1).program_update_date := rec.program_update_date;
 v_mold_tbl(1).inventory_item_id := rec.inventory_item_id;
 v_mold_tbl(1).revision := rec.revision;
 v_mold_tbl(1).organization_id := rec.organization_id;
 v_mold_tbl(1).subinventory_code := rec.subinventory_code;
 v_mold_tbl(1).locator_id := rec.locator_id;
 v_mold_tbl(1).transaction_quantity := rec.transaction_quantity;
 v_mold_tbl(1).primary_quantity := rec.primary_quantity;
 v_mold_tbl(1).transaction_uom := rec.transaction_uom;
 v_mold_tbl(1).transaction_cost := rec.transaction_cost;
 v_mold_tbl(1).transaction_type_id := rec.transaction_type_id;
 v_mold_tbl(1).transaction_action_id := rec.transaction_action_id;
 v_mold_tbl(1).transaction_source_type_id := rec.transaction_source_type_id;
 v_mold_tbl(1).transaction_source_id := rec.transaction_source_id;
 v_mold_tbl(1).transaction_source_name := rec.transaction_source_name;
 v_mold_tbl(1).transaction_date := rec.transaction_date;
 v_mold_tbl(1).acct_period_id := rec.acct_period_id;
 v_mold_tbl(1).distribution_account_id := rec.distribution_account_id;
 v_mold_tbl(1).transaction_reference := rec.transaction_reference;
 v_mold_tbl(1).requisition_line_id := rec.requisition_line_id;
 v_mold_tbl(1).requisition_distribution_id := rec.requisition_distribution_id;
 v_mold_tbl(1).reason_id := rec.reason_id;
 v_mold_tbl(1).lot_number := rec.lot_number;
 v_mold_tbl(1).lot_expiration_date := rec.lot_expiration_date;
 v_mold_tbl(1).serial_number := rec.serial_number;
 v_mold_tbl(1).receiving_document := rec.receiving_document;
 v_mold_tbl(1).demand_id := rec.demand_id;
 v_mold_tbl(1).rcv_transaction_id := rec.rcv_transaction_id;
 v_mold_tbl(1).move_transaction_id := rec.move_transaction_id;
 v_mold_tbl(1).completion_transaction_id := rec.completion_transaction_id;
 v_mold_tbl(1).wip_entity_type := rec.wip_entity_type;
 v_mold_tbl(1).schedule_id := rec.schedule_id;
 v_mold_tbl(1).repetitive_line_id := rec.repetitive_line_id;
 v_mold_tbl(1).employee_code := rec.employee_code;
 v_mold_tbl(1).primary_switch := rec.primary_switch;
 v_mold_tbl(1).schedule_update_code := rec.schedule_update_code;
 v_mold_tbl(1).setup_teardown_code := rec.setup_teardown_code;
 v_mold_tbl(1).item_ordering := rec.item_ordering;
 v_mold_tbl(1).negative_req_flag := rec.negative_req_flag;
 v_mold_tbl(1).operation_seq_num := rec.operation_seq_num;
 v_mold_tbl(1).picking_line_id := rec.picking_line_id;
 v_mold_tbl(1).trx_source_line_id := rec.trx_source_line_id;
 v_mold_tbl(1).trx_source_delivery_id := rec.trx_source_delivery_id;
 v_mold_tbl(1).physical_adjustment_id := rec.physical_adjustment_id;
 v_mold_tbl(1).cycle_count_id := rec.cycle_count_id;
 v_mold_tbl(1).rma_line_id := rec.rma_line_id;
 v_mold_tbl(1).customer_ship_id := rec.customer_ship_id;
 v_mold_tbl(1).currency_code := rec.currency_code;
 v_mold_tbl(1).currency_conversion_rate := rec.currency_conversion_rate;
 v_mold_tbl(1).currency_conversion_type := rec.currency_conversion_type;
 v_mold_tbl(1).currency_conversion_date := rec.currency_conversion_date;
 v_mold_tbl(1).ussgl_transaction_code := rec.ussgl_transaction_code;
 v_mold_tbl(1).vendor_lot_number := rec.vendor_lot_number;
 v_mold_tbl(1).encumbrance_account := rec.encumbrance_account;
 v_mold_tbl(1).encumbrance_amount := rec.encumbrance_amount;
 v_mold_tbl(1).ship_to_location := rec.ship_to_location;
 v_mold_tbl(1).shipment_number := rec.shipment_number;
 v_mold_tbl(1).transfer_cost := rec.transfer_cost;
 v_mold_tbl(1).transportation_cost := rec.transportation_cost;
 v_mold_tbl(1).transportation_account := rec.transportation_account;
 v_mold_tbl(1).freight_code := rec.freight_code;
 v_mold_tbl(1).containers := rec.containers;
 v_mold_tbl(1).waybill_airbill := rec.waybill_airbill;
 v_mold_tbl(1).expected_arrival_date := rec.expected_arrival_date;
 v_mold_tbl(1).transfer_subinventory := rec.transfer_subinventory;
 v_mold_tbl(1).transfer_organization := rec.transfer_organization;
 v_mold_tbl(1).transfer_to_location := rec.transfer_to_location;
 v_mold_tbl(1).new_average_cost := rec.new_average_cost;
 v_mold_tbl(1).value_change := rec.value_change;
 v_mold_tbl(1).percentage_change := rec.percentage_change;
 v_mold_tbl(1).material_allocation_temp_id := rec.material_allocation_temp_id;
 v_mold_tbl(1).demand_source_header_id := rec.demand_source_header_id;
 v_mold_tbl(1).demand_source_line := rec.demand_source_line;
 v_mold_tbl(1).demand_source_delivery := rec.demand_source_delivery;
 v_mold_tbl(1).item_segments := rec.item_segments;
 v_mold_tbl(1).item_description := rec.item_description;
 v_mold_tbl(1).item_trx_enabled_flag := rec.item_trx_enabled_flag;
 v_mold_tbl(1).item_location_control_code := rec.item_location_control_code;
 v_mold_tbl(1).item_restrict_subinv_code := rec.item_restrict_subinv_code;
 v_mold_tbl(1).item_restrict_locators_code := rec.item_restrict_locators_code;
 v_mold_tbl(1).item_revision_qty_control_code := rec.item_revision_qty_control_code;
 v_mold_tbl(1).item_primary_uom_code := rec.item_primary_uom_code;
 v_mold_tbl(1).item_uom_class := rec.item_uom_class;
 v_mold_tbl(1).item_shelf_life_code := rec.item_shelf_life_code;
 v_mold_tbl(1).item_shelf_life_days := rec.item_shelf_life_days;
 v_mold_tbl(1).item_lot_control_code := rec.item_lot_control_code;
 v_mold_tbl(1).item_serial_control_code := rec.item_serial_control_code;
 v_mold_tbl(1).item_inventory_asset_flag := rec.item_inventory_asset_flag;
 v_mold_tbl(1).allowed_units_lookup_code := rec.allowed_units_lookup_code;
 v_mold_tbl(1).department_id := rec.department_id;
 v_mold_tbl(1).department_code := rec.department_code;
 v_mold_tbl(1).wip_supply_type := rec.wip_supply_type;
 v_mold_tbl(1).supply_subinventory := rec.supply_subinventory;
 v_mold_tbl(1).supply_locator_id := rec.supply_locator_id;
 v_mold_tbl(1).valid_subinventory_flag := rec.valid_subinventory_flag;
 v_mold_tbl(1).valid_locator_flag := rec.valid_locator_flag;
 v_mold_tbl(1).locator_segments := rec.locator_segments;
 v_mold_tbl(1).current_locator_control_code := rec.current_locator_control_code;
 v_mold_tbl(1).number_of_lots_entered := rec.number_of_lots_entered;
 v_mold_tbl(1).wip_commit_flag := rec.wip_commit_flag;
 v_mold_tbl(1).next_lot_number := rec.next_lot_number;
 v_mold_tbl(1).lot_alpha_prefix := rec.lot_alpha_prefix;
 v_mold_tbl(1).next_serial_number := rec.next_serial_number;
 v_mold_tbl(1).serial_alpha_prefix := rec.serial_alpha_prefix;
 v_mold_tbl(1).shippable_flag := rec.shippable_flag;
 v_mold_tbl(1).posting_flag := rec.posting_flag;
 v_mold_tbl(1).required_flag := rec.required_flag;
 v_mold_tbl(1).process_flag := rec.process_flag;
 v_mold_tbl(1).error_code := rec.error_code;
 v_mold_tbl(1).error_explanation := rec.error_explanation;
 v_mold_tbl(1).attribute_category := rec.attribute_category;
 v_mold_tbl(1).attribute1 := rec.attribute1;
 v_mold_tbl(1).attribute2 := rec.attribute2;
 v_mold_tbl(1).attribute3 := rec.attribute3;
 v_mold_tbl(1).attribute4 := rec.attribute4;
 v_mold_tbl(1).attribute5 := rec.attribute5;
 v_mold_tbl(1).attribute6 := rec.attribute6;
 v_mold_tbl(1).attribute7 := rec.attribute7;
 v_mold_tbl(1).attribute8 := rec.attribute8;
 v_mold_tbl(1).attribute9 := rec.attribute9;
 v_mold_tbl(1).attribute10 := rec.attribute10;
 v_mold_tbl(1).attribute11 := rec.attribute11;
 v_mold_tbl(1).attribute12 := rec.attribute12;
 v_mold_tbl(1).attribute13 := rec.attribute13;
 v_mold_tbl(1).attribute14 := rec.attribute14;
 v_mold_tbl(1).attribute15 := rec.attribute15;
 v_mold_tbl(1).movement_id := rec.movement_id;
 v_mold_tbl(1).reservation_quantity := rec.reservation_quantity;
 v_mold_tbl(1).shipped_quantity := rec.shipped_quantity;
 v_mold_tbl(1).transaction_line_number := rec.transaction_line_number;
 v_mold_tbl(1).task_id := rec.task_id;
 v_mold_tbl(1).to_task_id := rec.to_task_id;
 v_mold_tbl(1).source_task_id := rec.source_task_id;
 v_mold_tbl(1).project_id := rec.project_id;
 v_mold_tbl(1).source_project_id := rec.source_project_id;
 v_mold_tbl(1).pa_expenditure_org_id := rec.pa_expenditure_org_id;
 v_mold_tbl(1).to_project_id := rec.to_project_id;
 v_mold_tbl(1).expenditure_type := rec.expenditure_type;
 v_mold_tbl(1).final_completion_flag := rec.final_completion_flag;
 v_mold_tbl(1).transfer_percentage := rec.transfer_percentage;
 v_mold_tbl(1).transaction_sequence_id := rec.transaction_sequence_id;
 v_mold_tbl(1).material_account := rec.material_account;
 v_mold_tbl(1).material_overhead_account := rec.material_overhead_account;
 v_mold_tbl(1).resource_account := rec.resource_account;
 v_mold_tbl(1).outside_processing_account := rec.outside_processing_account;
 v_mold_tbl(1).overhead_account := rec.overhead_account;
 v_mold_tbl(1).flow_schedule := rec.flow_schedule;
 v_mold_tbl(1).cost_group_id := rec.cost_group_id;
 v_mold_tbl(1).demand_class := rec.demand_class;
 v_mold_tbl(1).qa_collection_id := rec.qa_collection_id;
 v_mold_tbl(1).kanban_card_id := rec.kanban_card_id;
 v_mold_tbl(1).overcompletion_transaction_id := rec.overcompletion_transaction_id;
 v_mold_tbl(1).overcompletion_primary_qty := rec.overcompletion_primary_qty;
 v_mold_tbl(1).overcompletion_transaction_qty := rec.overcompletion_transaction_qty;
 v_mold_tbl(1).end_item_unit_number := rec.end_item_unit_number;
 v_mold_tbl(1).scheduled_payback_date := rec.scheduled_payback_date;
 v_mold_tbl(1).line_type_code := rec.line_type_code;
 v_mold_tbl(1).parent_transaction_temp_id := rec.parent_transaction_temp_id;
 v_mold_tbl(1).put_away_strategy_id := rec.put_away_strategy_id;
 v_mold_tbl(1).put_away_rule_id := rec.put_away_rule_id;
 v_mold_tbl(1).pick_strategy_id := rec.pick_strategy_id;
 v_mold_tbl(1).pick_rule_id := rec.pick_rule_id;
 v_mold_tbl(1).common_bom_seq_id := rec.common_bom_seq_id;
 v_mold_tbl(1).common_routing_seq_id := rec.common_routing_seq_id;
 v_mold_tbl(1).cost_type_id := rec.cost_type_id;
 v_mold_tbl(1).org_cost_group_id := rec.org_cost_group_id;
 v_mold_tbl(1).move_order_line_id := rec.move_order_line_id;
 v_mold_tbl(1).task_group_id := rec.task_group_id;
 v_mold_tbl(1).pick_slip_number := rec.pick_slip_number;
 v_mold_tbl(1).reservation_id := rec.reservation_id;
 v_mold_tbl(1).transaction_status := rec.transaction_status;
 v_mold_tbl(1).transfer_cost_group_id := rec.transfer_cost_group_id;
 v_mold_tbl(1).lpn_id := rec.lpn_id;
 v_mold_tbl(1).transfer_lpn_id := rec.transfer_lpn_id;
 v_mold_tbl(1).pick_slip_date := rec.pick_slip_date;
 v_mold_tbl(1).content_lpn_id := rec.content_lpn_id;
 v_mold_tbl(1).transaction_quantity := p_pick_conf_qty;
 v_mold_tbl(1).primary_quantity := p_pick_conf_qty;
 v_mold_tbl(1).shipped_quantity := p_pick_conf_qty;
 INV_PICK_WAVE_PICK_CONFIRM_PUB.PICK_CONFIRM(p_api_version_number => 1.0,
 p_init_msg_list => FND_API.G_FALSE,
 p_commit => FND_API.G_FALSE,
 x_return_status => l_return_status,
 x_msg_count => l_msg_count,
 x_msg_data => l_msg_data,
 p_move_order_type => 3 -- PickWave - Order
 p_transaction_mode => 1 -- 1:On-Line, 2:Concurrent, 3:Background
 p_trolin_tbl => v_moveln_tbl_d,
 p_mold_tbl => v_mold_tbl,
 x_mmtt_tbl => v_mold_tbl,
 x_trolin_tbl => v_moveln_tbl_o,
 p_transaction_date => SYSDATE);
 COMMIT;
 DBMS_OUTPUT.PUT_LINE('Return status of INV_PICK_WAVE_PICK_CONFIRM_PUB.PICK_CONFIRM = ' ||
 l_return_status);
 IF l_return_status != FND_API.G_RET_STS_SUCCESS THEN
 pStatus := cv_fail;
 pMsgData := 'Failed to pick confirm move order inv_pick_wave_pick_confirm_pub.pick_confirm for MOVE_ORDER_LINE_ID : ' ||
 vMoveOrderLineId;
 GOTO end_of_pkcnf;
 END IF;
 v_api_pick_confirm := 1;
 dbms_output.put_line('Status of the Pick Confirm is : ' ||
 l_return_status);
 <<end_of_pkcnf>>
 NULL;
end loop;
END;
Updating Shipping attributes
DECLARE
--Standard Parameters.
p_api_version NUMBER;
init_msg_list VARCHAR2(30);
p_commit VARCHAR2(30);
--Parameters for WSH_DELIVERY_DETAILS_PUB.update_shipping_attributes.
source_code VARCHAR2(15);
changed_attributes WSH_DELIVERY_DETAILS_PUB.ChangedAttributeTabType;
--out parameters
x_return_status VARCHAR2(10);
x_msg_count NUMBER;
x_msg_data VARCHAR2(2000);
x_msg_details VARCHAR2(3000);
x_msg_summary VARCHAR2(3000);
-- Handle exceptions
vApiErrorException EXCEPTION;
BEGIN
-- Initialize return status
x_return_status := WSH_UTIL_CORE.G_RET_STS_SUCCESS;
-- Call this procedure to initialize applications parameters
FND_GLOBAL.APPS_INITIALIZE(user_id => 0,
 resp_id => 21623,
 resp_appl_id => 660);
source_code := 'OE';
changed_attributes(1).delivery_detail_id := 9317811; -- delivery_detail_id
changed_attributes(1).shipped_quantity := 0; -- quantity to update
changed_attributes(1).cycle_count_quantity := 30;
--Call to WSH_DELIVERY_DETAILS_PUB.Update_Shipping_Attributes.
WSH_DELIVERY_DETAILS_PUB.Update_Shipping_Attributes(p_api_version_number => 1.0,
 p_init_msg_list => init_msg_list,
 p_commit => p_commit,
 x_return_status => x_return_status,
 x_msg_count => x_msg_count,
 x_msg_data => x_msg_data,
 p_changed_attributes => changed_attributes,
 p_source_code => source_code);
 commit;
IF (x_return_status <> WSH_UTIL_CORE.G_RET_STS_SUCCESS) THEN
 RAISE vApiErrorException;
ELSE
 dbms_output.put_line('The shipped quantity is updated with ' ||
 changed_attributes(1)
 .shipped_quantity || ' for the delivery detail ' ||
 changed_attributes(1).delivery_detail_id);
END IF;
EXCEPTION
WHEN vApiErrorException THEN
 WSH_UTIL_CORE.get_messages('Y',
 x_msg_summary,
 x_msg_details,
 x_msg_count);
 IF x_msg_count > 1 THEN
 x_msg_data := x_msg_summary || x_msg_details;
 DBMS_OUTPUT.PUT_LINE('Message Data : ' || x_msg_data);
 ELSE
 x_msg_data := x_msg_summary;
 DBMS_OUTPUT.PUT_LINE('Message Data : ' || x_msg_data);
 END IF;
WHEN OTHERS THEN
 DBMS_OUTPUT.PUT_LINE('Unexpected Error: ' || SQLERRM);
END;
Thanks

Hi,
Goto VTFL.Select you valid combination.
Click on item.Select yout item category there.Goto details.
Select the Pos/neg quantity field as "+".
Maintain the billing quantity as "A".
Maintain VBRK/VBRP as "001".
Save.
Goto VOV7 and select your item category.Details.
Select completion rule as "B" and billing relevance as "F".
Save.
Pls go through the follwing threads that are posted by me earlier.
[Invoice split|Re: Invoice split]
[Splitiing of invoice|Re: Invoice split]
Regards,
Krishna.

Issue In Posting Proof Of Delivery Using Idoc using Message Type STPPOD

Hi ,
(The details I have attached in the below file.)
We are trying to perform proof of delivery with respect to a outbound delivery via IDOC using idoc inbound function module IDOC_INPUT_STPPOD.
Everything is working fine except when it is creating a new stock movement document on confirmation of proof of delivery, the newly created stock movement document is not reflecting the actual received quantity instead it is showing the the Actual Delivery quantity.
For clicking on the button - "Proof of Delivery Confirmation " (green wright symbol) and change the overall POD status as completed ( depending on this status C the stock movement document gets created) we did a custom coding in the customer exit of IDOC_INPUT_STPPOD.
The details I have attached in the below file.
I am not able to understand where I am making mistake due to which, the quantity on the stock movement document after proof of delivery confirmation is not reflecting the actual received quantity.
Can you please suggest what necessary coding changes I need to perform to make it work properly.
Regards
Saifur Rahaman

Hi Thripura,
In DELVRY03 Idoc type,there is a segment E1EDL37 containing Shipment Header Information.As a header segment,there are 6 segments under this,which contains other details.Please see the below details.
E1EDL37                        Shipping unit header
    E1EDL39                        Control segment for shipping units
    E1EDL38                        Shipping unit header descriptions
    E1EDL49                        Express Delivery Company's Tracking Connection Data
        E1EDL50                        Express Delivery Company - Additional Data
    E1EDL44                        IDoc: Shipping unit item (delivery)
        E1EDL46                        Serial Numbers HU
Regards,
VSN

Create Sales order from Internal Purchase Order using IDOC

Hello Friends,
I have requirement to create Sales Order from Internal Purchase Order Using IDOC.
Backgorund, we have already configured IDOC orders05 to create Sales Order from external Purchase order from Inbound IDOC, and it is working fine.
Now we have new requirement to create Sales Order from our own Purchase order, i.e. When PO is created in one plant corresponidng sales order automatically must needs to create in another Plant with respect PO.
I m trying to design a solution for above problem as follows,
1.create an Inbound Idoc from PO, by creatiing one new message type on PO save.
2.Process that Inbound IDOC same as it is from external PO.
3.Once processed Sales order will create.
Please help me in step 1. to create Inbound IDOC from PO.
If you want any further clarification please write me.
Thanks,
Mahesh

I had done a similar scenario before and we achieved it through SAP XI. The problem is with the control record. When we create a ORDERS IDOC from a PO the control record will be for outbound transmission. We sent the file to XI and XI resent it back with some data parsing and a new inbound control record. This way it went neat outbound and inbound.
I'm not sure what kind of architecture you have. If you have to do it within your ECC/R/3, then you could create the outbound IDOC to a new port and write a fresh RFC to pick it up from the same folder and create a new control record for inbound processing.
I haven't tried this; but there is a "processing w. trigger (inbound)" option on the outbound process code. May be you can explore into that a bit more.
I'm sure there could be better approaches to handle this within ECC so if you stumble on any, do write back. I would like to know to update my knowledge .

Stock Transfport Order Creation using IDOC

Hello Everybody,
I am trying to create a Stock Transport Order using IDOC's. All configuration for the STO has been done and I have no problems creating these orders using ME21N.
Now I need to create STO using IDOC. I am using Message Type ORDERS and Basic Type ORDERS05, but I am not sure what Process Code to use in the Partner Profile configuration in order to pick up proper processing module....
Any help would be appreciated,
Than you in advance
Felix

I ended up writing my own processing FM for this and used BAPI_PO_CREATE1 to post the PO

Picking confirmation using IDOC

Similar Messages

Maybe you are looking for