CIG offers a tool for customizing the transactions. For more information, please check the
link. However, due to certain complexities for Requisition sent from P2P, customization for this transaction came with limitation. Through this blog post I would like to inform that the limitation has been overcome and the customization for ‘Budget Check’ and ‘Revert To Earlier Version’ transactions via Mapping tool is addressed.
Audience for this blog post: You must have access to CIG and know its basic functionality around integration. Also, you must have worked on P2P and have sufficient knowledge on customization.
Released on: 21Sep2021.
What happened?
The three transactions – BudgetCheck, RequisitionSubmit and RevertToEarlierVersion have similar structure wrt the data. Hence a common interface RequisitionExportRequest was built to handle all the three documents. Customization may vary for each of those, therefore a common document type – RequisitionExportRequest was unable to fulfill the requirement.
Can you elaborate technically?
Every document is associated with a Schema, and every schema is set up with only one Root element in the framework. Mapping tool builds customization XSLT based on the schema.
RequisitionBudgetCheckExportRequest(Budget check), RequisitionRealTimeBudgetExportRequest(Requisition submit) and RequisitionRevertBudgetToEarlierVersionExportRequest(Revert Requisition to previous version) had the same internal structure with different root element. Hence a single XSLT handled the standard transformation from P2P to AddOn.
Mapping tool can only work for one of the transaction as the schema is dependent on root element. Assuming Requisition submit to be majorly used, RequisitionRealTimeBudgetExportRequest was configured as the root element and the same was supported on Mapping tool.
What’s the solution now?
Migration was the solution to overcome the issue here. There are 2 kinds of customization, hence migration is handled differently.
1. Buyer mappings(manual customization): This has been migrated to all three kinds.
2. User mappings(mapping tool) : This is migrated only to RequisitionRealTimeBudgetExportRequest.
This migration is only for projects on CIG AddOn SP6 and above versions.
What changes will the customer see or experience?
On Mapping tool, three new transactions will be seen. Among the three, RequisitionExportRequest has been migrated to RequisitionRealTimeBudgetExportRequest. Also, deployment has been carried out during the migration. Similarly, Manual customization provided by the Engineering team, has been migrated and deployed.
Note: RequisitionExportRequest will still be seen on Mapping tool, but please avoid using it after migration. It will not have any affect.
Why does the mapping tool show RequisitionExportRequest even after the migration?
Every customer/consultant working on a CIG project may not be aware of this migration. In such case, removing RequisitionExportRequest raises more unnecessary questions on its absence. However, using it will have no impact, because it becomes a stale object. Meaning, any customization therefore will have no impact since customization was already migrated to specific document types.
In short:
RequisitionExportRequest was a single document type on CIG that handled BudgetCheckt, RequisitionSubmit and RevertToEarlierVersion. To support customization for such a case came with complexities but not anymore. Migration activity resolved the issue addressed through the blog post.
Follow my profile to get latest updates. Also, check-out this link for QA on
SAP Ariba Cloud Integration Gateway
Please provide feedback on the post and any thoughts for improvement. Let’s make the content helpful to every reader.
