Get Involved. Join the Conversation.


  • Jess Mullenix

    Due to security rights many users do not have access to the AP side to view receipts. There should be a way to pull all receipt numbers tied to a PO from the Procure to Pay Real Time section. Currently there is not, it will only show receipts if they are tied directly to an invoice and that does not show the entire picture.



  • Rain Tsui

    In Oracle Fusion Purchasing, attachments needed to be added or updated via CO when a PO is open. However, only attachments with the category "To Supplier" will revise the PO, the change will be communicated to the supplier. The other attachment categories will not revise the PO, and will NOT be communicated to the supplier, and PO will keep a change record.

  • Divya Reddy

    From the data in the pod, looks like something is changed on the distributions on the closed lines and hence its trying to validate the account. Can they check the Review Changes page to see what changed and undo them . They can also try deleting the change order and try submitting again.  Make sure there are no changes on the distribution


  • Suman Guha

    Looks like the SR is still open and support's analyzing the issue.


  • Rohan Kamat

    SR 3-21360850561 : Account generation is not working correctly

  • Ramakrishna Basa

    The application has the ability to automatically set the status to closed for schedules, lines, and entire orders based on controls that are defined by your organization. Once all schedules for a given line are closed, the line is closed. When all lines for a given header are closed, the document is closed.

    The closing controls include:

    • Receipt Close Tolerance Percent

    • Receipt Close Point

    • Invoice Close Tolerance Percent

    A schedule has a status of Closed for Receiving when it satisfies the two receipt close controls. This does not prevent further receipts but begins the steps necessary to automatically close the document. A schedule has a status of Closed for Invoicing when it satisfies the invoice close control. This status will not prevent you from matching an invoice to the purchase order or to the receipt but begins the steps needed to automatically close the document. Both of these statuses can apply to the header, line, and schedule levels.

  • Venkatesh Periketi

    I hope after setting the tolerance % to 0%, I think it will not close.

    i) Set receipt close tolerance percent to 0% so that the schedule would automatically be 'closed for receiving' and/or

    ii) Set invoice close tolerance percent to 0% so that the schedule would automatically be 'closed for invoicing

    Please confirm if this works or do we have any other better option.



  • Manjula Evans


    You can use File-Based Data Import for Blanket Agreements to import updates to this field. Note that by default, this checkbox is selected for service lines.

    Kind regards,

  • Ashok


    I am transferring this post to the Purchasing team for guidance.

  • Ashok

    Haydee and Stacee

    Both of you have reported similar, if not the same behavior. I just had to review it internally to ensure I was not missing anything before I respond. I have done that and here is my response:

    1. Your observations are correct and per designed behavior. i.e. A buyer returning a reinstated line (whether BCEA enabled or otherwise) constitutes a 'Cancel' operation to be invoked on the requisition line

    2. The fact that the original requisition line does not allow Cancel operation either is expected as that line is effectively replaced with the new reinstated line.

    Now, as to why this behavior is such:

    While I wait on some of the folks that were originally involved in this, I believe this is designed so because, what the buyer has done by canceling the Purchase Order line and retaining Unfulfilled Demand is simply expressed his/her intent to process this line again perhaps against a different supplier, different agreement etc. In other words, this line is alive and active only to be made available for a downstream procurement process. The functional assumption is that the line does not need inputs at this stage from the requester because if that was needed, the buyer would have perhaps returned the original line already and had the requester do the needful. So, when the buyer now returns this 'Reinstated' line to the requester, the system simply assumes this line is no longer needed and so cancels it. This explains the behavior you see which is that the error message is displayed when you try to cancel that line again. But then, that is also fairly clear already because the line is in status 'Canceled'.

    If I learn of any other functional reasoning on why this behaves as such, I will revert.



  • Haydee Mercado

    Thanks Ashok. I will await for your further inputs on this one.




  • Suman Guha

    Do you have a SR opened? If so, could you please share the SR#?

  • Rohan Kamat

    We have our TAB Account rule for PO Variance account to generate from PO Charge accounts in all conditions

  • Ashok

    Hi Haydee

    Brilliant stuff! Thank you for taking the trouble and providing these detailed screenshots. What we did not discuss earlier was something I noticed in your screenshots: This is budgetary control enable requisition. I will need to dig a bit deeper to confirm if this is designed behavior for such cases. I was responding without that information from earlier details. For normal requisitions, I don't believe the line is automatically canceled upon return.

    I will revert hopefully today or latest tomorrow. Thanks for your patience.


  • Stefania Rizea

    Can you tell us a sample Request Body to change PO Line DFF value?

    Thank you,