Purchase orders are getting uneven for the requests
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I have created an order guide for all Network Equipment's. When I try to go through the request via Sourcing Request task and choose purchase option for all the requested items keeping same Destination Stockroom and Vendor values then sometimes multiple Purchase orders are getting created and sometimes single Purchase order is created with multiple POL items.
Can anybody has faced this kind of issue before?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @R_52 ,
This behavior can occur OOB depending on whether the Purchase Orders satisfy the PO consolidation conditions.
Since you are sourcing the items through:
Request
-> Source Request Items task
-> Source Request
-> Purchase
the important option to verify is:
Consolidate PO
Having the same Vendor and Destination Stockroom alone does not guarantee that all requested items will go to the same Purchase Order.
When Consolidate PO is selected, ServiceNow looks for an existing Purchase Order that has:
1. The same Request
2. The same Vendor
3. Status = Requested
If a matching PO exists:
Existing PO
-> New Purchase Order Line Item is added
If no matching PO exists:
-> A new Purchase Order is created
So the expected result should be:
REQ
-> PO0001
-> POLI Item A
-> POLI Item B
-> POLI Item C
provided all items use the same Vendor, belong to the same Request, Consolidate PO is selected, and PO0001 is still in Requested status.
I would check the following on one working request and one failing request.
1. Verify Consolidate PO
When sourcing each requested item, make sure:
Consolidate PO = checked
If this is not selected, ServiceNow is allowed to create another Purchase Order.
2. Compare the generated PO records
Open:
proc_po.list
For the multiple POs created from the same request, compare:
- Request
- Vendor
- Status
- Created time
The Vendor should be the exact same reference/sys_id, not only the same display name.
3. Check the PO status
This is especially important.
The existing PO must still be:
Requested
when the next item is sourced.
For example:
Item A sourced
-> PO0001 created
-> Status = Requested
Item B sourced
-> Consolidate PO checked
-> PO0001 found
-> POLI added to PO0001
But if some Flow, UI Action, integration, or customization changes PO0001 to:
Ordered
before Item B is sourced, PO0001 no longer qualifies for consolidation.
Then ServiceNow creates:
PO0002
This could explain why the behavior appears inconsistent.
4. Verify all items belong to the same parent Request
An Order Guide normally creates multiple RITMs under a Request.
Make sure the Purchase Orders are being sourced from items under the same parent Request.
The OOB consolidation check is based on the same Request and Vendor.
5. Destination Stockroom
Keep Destination Stockroom consistent as you are currently doing, but note that the documented PO consolidation lookup is primarily based on:
Same Request
+
Same Vendor
+
PO Status = Requested
+
Consolidate PO selected
Therefore, Destination Stockroom being the same is not sufficient by itself.
6. Check custom automation
If the above values are identical but separate POs are still created, check whether you have customization around:
proc_po
proc_po_item
especially:
- Business Rules
- Flows
- UI Actions
- Script Includes
- Integrations
Pay particular attention to anything that changes the PO from Requested to Ordered immediately after creation.
7. Simple test
I would test with only two catalog items:
Item A
Item B
Both under the same Request.
For both use:
Vendor = Vendor A
Destination Stockroom = Stockroom A
Consolidate PO = true
Source Item A first.
Verify:
PO0001
Status = Requested
Then source Item B.
Expected result:
PO0001
-> POLI for Item A
-> POLI for Item B
No PO0002 should be created.
If this works, the OOB functionality is behaving correctly and you can compare the failing request against this test.
If it still creates PO0002 while PO0001 has the same Request, same Vendor, Requested status and Consolidate PO was checked, then I would reproduce it in sub-production with OOB configuration before changing any Procurement scripts.
ServiceNow documentation confirms that the Consolidate PO option is specifically intended to place items from the same vendor on the same request into the existing Requested Purchase Order.
Related ServiceNow Community discussion also confirms that Consolidate PO results in a new PO Line being associated with the existing PO instead of creating another PO.
Hope this helps!
If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.
Kind Regards,
Abhishek Pal