Get Involved. Join the Conversation.


  • Nitin Katare

    Since we are talking about solutions, using of a DFF (on the Requisition) and having it copied over to the PO can also work (based on profile options to DFF copy set to yes)

    Although, the question posed by Suman earlier still stands.

  • Nitin Katare

    Will revert early next week once I get some more information. Thanks!

  • Mohammad Arif Zaffar
    Thanks for the comment.
    Will it come in future releases or we do not have any information for it for now?
    Further any idea when can we get export and import option for PO approval rules
  • Nitin Katare

    Ability to create dynamic approval groups is currently not supported in Fusion Cloud. Given the scenario you listed above, you would need to create 25 approval rules.

  • Piyush Bihany

    Hi Siva

    "Backing Requisition exists" attributes is available as a Requisition Header attribute.

    In case a new line is added to any PO, which is already backed by a requisition, then the same will follow the approval rule, considering as Backing requisition does exists for the PO.




  • Piyush Bihany

    Attachment from Requisition line appears on PO line

  • Piyush Bihany


    As a workaround, requester can add a text attachment for category To buyer at each requisition line, and the same get attached to the PO lines and are available to the buyer on PO.


  • Suman Guha


    1. PO's not calling any OM service at this time. Rather OMs listening to business events and compensating for po changes based on PO references that are carried on the sales order.

    2. If we do introduce drilldown capabilities in the future, it would be based off some internal system key and not a business key/free form text field like Customer Sales Order number is.




    Suman - had a call with Shrikant Nene today and he mentioned that any field that OM is internally populating is NOT exposed in the mapper, and that's why customer sales order is not present in the mapper.

    We will work with an ER for this.

    But just to re-validate 2 points

    1. When PO is calling any OM service for all events originated from PO (e.g. Promise date update, Shipping etc), it's using which field to get to the SO number? Is it using the DOO_DOCUMENT_REFERENCES.DOC_ID ? Because surely it's not using SALES_ORDER_NUMBER  on POR_REQUISITION_LINES_ALL as it's a freetext field. I believe so, but just trying to confirm.

    2. This is a futuristic question, but even with the ER, could changing the SALES_ORDER_NUMBER  on POR_REQUISITION_LINES_ALL via mapper create any issue in future when there would potentially be functionality to view an SO from PO ? For example, if on the PO page the SO number field had a hyperlink to go the PO, conceptually, should it use the SALES_ORDER_NUMBER value (which is changed by mapper), or should it use the same uniform reference mentioned above (say DOO_DOCUMENT_REFERENCES.DOC_ID). I think the latter, but wanted to confirm before we pursue the ER. Or if this question is too futuristic to answer now, let me know too.

    I think these 2 would be the last of our question, post this we would see how to (and if) pursue the ER.



  • Suman Guha

    Thanks for sharing this. Feel free to follow-up with support to log a bug with the product so that development can analyze why you cannot simply finally close without needing this convoluted process.

  • Jess Mullenix

    Here is current workaround (see attached documentation)

  • Suman Guha

    The degree of uptake of Planned POs and Scheduled releases within EBS was pretty limited which is why the functionality was not carried forward to the cloud solution. There isn't a migration recommendation for such documents as such. Depending on demand and targeted use case, it's something that we can revisit in the future.

  • Suman Guha

    Your options would be

    1) not to interface these orders into cloud procurement at all and do the integration of financial transactions directly to GL from the external system.

    2) interface them as Confirming Orders with email and/or B2B communication turned off and for supplier portal users to clearly understand that these are not new orders for fulfillment.


  • PravinKumar Munnaluri

    The original PO document will sent to supplier from External system and oracle PO will be duplicate order. Legally this is not correct process . Hence we want to hide the interface purchase order from supplier portal. Please suggest.



  • Suman Guha

    Invoice Matching would still require supplier collaboration including hold resolution, payment status queries where the portal would be of value. Am not understanding the concern with exposing orders in the portal. The orders should be in appropriate status to prevent duplicate shipments.