Self Service Procurement

Get Involved. Join the Conversation.


    Requisition Import: Understanding how the parameter Error...
    Topic posted April 12, 2019 by AshokBlack Diamond: 60,000+ Points, tagged Requisition Import, Tip 
    77 Views, 2 Comments
    Requisition Import: Understanding how the parameter Error Processing works
    Requisition Import: What is the significance of the import parameter Error Processing?

    Customers / Support

    This one is rather interesting. You would think obvious but I was answering a couple of forum posts / bugs on this recently. I thought it would not be a bad reminder on explaining an important feature in importing requisitions.


    The customer in this case came to us with an issue that the system was disobeying their command on creating requisitions even when they had set Error Processing to All.


    What does the import parameter Error Processing do?

    It determines how to create or not create requisitions when the system encounters any validation issues while processing requisition lines.

    What are the supported values for this parameter?

    The supported values are: All or Partial. 

    All indicates that the system will only create requisitions only if all the lines from the interface header pass validation

    Partial indicates that the system will create requisitions even if some lines from the interface header pass validation.


    What customers and support  need to know are the following guiding principles:

    1. The import parameter Group By has a role to play in how this works

    2. If the Group By parameter is applied, then the system creates 'batches' of requisition headers under which to group requisition lines and then applies the value All or Partial.

    Let us discuss this with an example:

    When creating an import batch, let's say the customer provided a requisition header reference of 1 as the header interface id for example.

    Now using this reference, the customer has provided several lines all pointing to this id

    Let's assume (as was in the customer case I dealt with) that the import parameter Group By was set to Location (Deliver-to Location). This means the system will group all requisition lines with the same location and process them under one requisition header.

    Now imagine the batch imported contained multiple locations. Stands to reason multiple requisition header batches will be created, right?

    The customer in this case actually provided one location for ALL requisition lines but did not provide Location for ONE record.

    Customer expectation: It should fail all the lines and hence no requisitions ought to be imported

    Designed actual behavior: If the group by attribute does not contain a value, now that is not part of the set of requisition lines to be processed. So the system cannot possibly know the intent of the customer was to group it using the same location as all others.

    So the system processed all other lines into one header even though Error Processing was set to All and rejected this one line.

    We explained this to the customer and it was understood.

    Take away:

    Remember the correlation between Group By and Error Processing and when you find that the number of requisition headers created were less or more than you expected, this is one of the first things you can review to see how it might have done what it did.

    Let me know if this article helps / clearly understood. Would be happy to receive and implement feedback on this.



    • Lokeswara Raju Chamarti

      We have a similar user case, but our requirement is to validate all the requisition lines and import the requisitions for all the requisition lines in the batch across the requisition headers only if all line passed validation with out errors. If there is any error in any line, don't process any line so that all lines in the batch can be re-processed. In the current interpretation of the error handling, If we set error processing as 'All', system will import some requisitions and not import other requisitions. User need to remove all the successfully processed requisitions from the import file and create a delta file to be able to fix and re-process the error-ed requisitions. This process of creating the delta files to re-process error is very cumbersome process, especially if the number of lines in the import file is very high.

      For a Retail customer with Project driven supply chain, We are currently using the Planning central to create the supply recommendations based on the external forecast and enriching the planned order information with Project and task references and importing the supply suggestions as Requisition. Typical import file size is on an average more than 50,000 lines. If there are errors, we are forced to create multiple delta file for each run to fix the remaining errors. This is non-productive and error prone process. Post the import, it is very difficult to reconcile if all the requisitions lines got imported successfully or not as the file got split to multiple delta files.

      It is easier to fail all lines in the batch and only import if all the errors are resolved. This will eliminate the need to create delta files and also reconcile the data from source file and Imported requisitions. Importing duplicate requisition due to user errors in creating delta file is huge risk.

      The Error processing should have option to validate by Batch, Requisition, Requisition line. All and Partial is misleading. 'All' to me the all lines in the import file and not all lines in one requisition group. 

    • Ashok

      The way it is designed, there is an implicit presumption that the user is aware of the batch processing idea. But I do see your point. We could think of adding a tool tip for instance, if that would help users understand it better when submitting the report.

      But I see your requirement additionally as simply allowing an entire load (batch) to fail if even one record fails. Can you create an idea for this in the Ideas Lab? Let us see if this gains traction among the customer community.