Skip to Content

The blog talks about  handling old / Pos which may no longer be needed and have to be transaction completed .

This is a step before actually archiving the POs and contracts. So basically the business should first be transaction completing them if there is no more GR and Invoice expected and letter archiving them as needed. The details mentioned here are related to mass transaction complete and change the status of the PO/ Contracts from backend via an ABAP report .

This however is possible to do via front-end by just clicking on the complete button.

The reason for doing transaction completed  can be many from an operational perspective

  1. You need to ensure no one is using those POs as they are already Gr’d and invoiced
  2. Lets consider an example where  these POs are linked to the contract. The contract value was 10000 USD and PO value was of 1000 USD. The remaining contract amount available after the PO is ordered is 9000 USD. However if the  PO was actually on Gr’d for 500 USD it should return back the 500 USD balance amount. This happens when we transaction complete the PO. So the amount left to use in contract after the PO is transaction completed would be 9500 USD. This is a best practice to ensure you make use of contracts efficiently.
  3. The program I created can be made as a batch job to see if a PO has not been updated for last 1 year or the requester/recipient is no longer available and no one else has been identified to take its ownership and is lying with the admin team it should just be transaction completed.
  4. It helps a lot in reporting making the reports look better as well as ensure you are able to forecast the expected invoice and balance amount in a much better way
  5. The reason for doing this via a program code is also the reason that these are Old Pos and if you try to transaction complete them from the backend they will have errors in terms of WBS being locked, users who have left the org and these checks needs to be fixed before you can actually ‘Transaction complete’ it from the portal. If however we do as a batch program it skips those checks and is easier to close off these POs without wasting time on trying to fix the data errors

Now that we discussed transaction completed there may be a case where you need to make changes in a PO which was either manually transaction completed incorrectly or was incorrectly updated by the batch job or was put on hold for sometime but is needed again. So to handle such a case I also created another program  to update the table entries to change the status of the PO  from being transaction completed to change back to ordered status.

Pl find details about how the solution was implemented.

Transaction completed status is  ‘I1023’
Call Function Module ‘BBP_PD_PO_GETDETAIL’  ”    To read the details of the PO

Ensure you read the version correctly if the PO has been ordered multiple times there will be change version of the. Check if a change version exists if yes then use GUID for change version of PO

p_guid = ls_version-guid.
p_guid = ls_header-GUID .

Call the below function module again with the p_guid of the latest version you found above


IF sy-subrc eq 0 . " lv_object_type EQ /sapsrm/if_pdo_obj_types_c=>GC_PDO_PO.
WITH KEY stat = /sapsrm/if_pdo_status_c=>GC_PDO_ORDERED
inact = ' '.
IF sy-subrc NE 0.
lv_not_ordered = 'X' .

WITH KEY stat = /sapsrm/if_pdo_status_c=>GC_PDO_CLOSED
inact = ' '.
IF sy-subrc EQ 0.
lv_tc = 'X' .

Ensure the Po is not Awaiting approval or transaction completed already

if lv_not_ordered is not initial or   lv_tc is not INITIAL.
*      MESSAGE i047(bbp_pd) WITH text-001. "Transaction completed only for status ordered
ls_po_error = ls_po.
APPEND ls_po_error to lt_po_error.

If the PO is in the right status of Ordered proceed with the change of status and Don’t forget to call Commit FM. Also note in SRM you need to update the Final_entry and Final_inv indicator which will update the delivery completion indicator in the ECC system

select * from bbp_pdigp INTO table lt_pdigp  for ALL ENTRIES IN lt_guid_pdigp
where guid = lt_guid_pdigp-guid.
UPDATE bbp_pdigp
SET Final_inv = 'X'
final_entry = 'X'
WHERE guid = ls_pdigp-guid.


You may also want to use the class /sapsrm/cl_pdo_bo_po and method /sapsrm/if_pdo_bo_po~complete_po to be able to complete the PO

This is the same class and method which is called when you click on Complete PO from the portal side. There is however a lot of buffer data it calls from the portal execution and hence you may need to copy the actual code and the FM instead of calling the class directly.

Somewhere inside the class it also checks for Value and Qty of invoice. This was not part of my business requirement so I haven’t really used this logic.

** if sy-subrc = 0.
** lv_conf_val = ls_actval-val_cf_e.
** lv_conf_qty = ls_actval-quan_cf_e.
** lv_inv_val = ls_actval-val_iv_e.
** lv_inv_qty = ls_actval-quan_iv_e.


When you do transaction complete  it will be nice to do a check to ensure

  • Delivery completed Flag has been ticked for the PO
  • User is not able to do any more GR for the PO
  • Status on the portal has changed to Transaction completed



Reverse transaction Complete

Now , coming to the next part is to make changes to reverse  the already existing  Transaction completed POs and make its status as Ordered again. Pass GUID to get the status

objnr_tab = lt_obj
status    = lt_status.

* remove status which are not in scope based on Global parameter values
DELETE lt_status WHERE stat NOT IN lr_stat.  “i,e check transaction completed status exists and delete all the others 


no_workflows = ‘X’
jest_ins     = lt_jest_ins    “not filled
jest_upd     = lt_jest_upd    “filled   with the status you need
jsto_ins     = lt_jsto_ins    “not filled
jsto_upd     = lt_jsto_upd    “not filled
obj_del      = lt_obj_del.    “not filled


Ensure you get the updated status again to ensure that the work has been completed successfully/.



* get updated status of all objects AFTER the reset
REFRESH: lt_jcds, lt_status.
only_active          = ‘X’
get_change_documents = ‘X’
objnr_tab            = pt_obj
status               = lt_status
jcds_tab             = lt_jcds.

With this now the PO would again open up and you can place an order and create a change version or be able to do GR for the PO.


That’s it on this blog.

Hope I have been able to help those using SRM and trying to handle the transaction completion status of the POs.

I also took some help from the below links

Thanks for taking time to read my blog and please let me know if you have some comments or other ways on how you have handled a similar scenario




To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply