CRM and CX Blogs by Members
Find insights on SAP customer relationship management and customer experience products in blog posts from community members. Post your own perspective today!
cancel
Showing results for 
Search instead for 
Did you mean: 
maciej_jarecki
Contributor
Introduction:

Most of companies are exchanging huge amount of data between systems as data is an information and to execute any business process is more then mandatory. Connecting systems in SAP world is usually executed via SAP middleware like SAP PI/PO or any newer and renamed version of it like CPI. These systems are very powerful and sophisticated but not each industry needs it. Example of such an industry is Retail business that received number of data mainly from single source which is POS system. Increasing usability of SAP CAR system across companies and business processes that SAP CAR is involved in caused more effort spent on the maintenance and support.

Objective:

SAP CAR receives POS transactions related to number of processes mainly sales but as well good movements operations or finance transactions. Each POS transaction is a set of data that is processed by tasks. Tasks are processed independently but sometimes during the execution of any task error can occur due to the wrong data which needs to be changes and because the task dependency some of them need to be reversed first.

Selection of the task depends on the Customization of POS transactions and for here we use following assignment.


The focus of this article is to describe when you can do a change of POS transaction data based on task status and what is the procedure of reversing/ canceling the task.

Both configuration parameters are set on task definition level.

Cancelation procedure:


When checkbox is selected then reversal/cancelation means the task needs to get status ready to be cancelled first. Task is executed and same code of task is executed with information it’s reversed execution and as well system process values with opposite sign.

Changeability of data for task:


Describes when data can be changed.

  • Always changeable – No restriction to change a data

  • Only changeable if task has status ready – in this case we can change data only if task is in status ready neither rejected nor cancelled nor processed etc.

  • Changeable if Task Not Processed or Canceled – data of POS transaction can be changed when task status is ready or rejected.


Example:

For the purpose of this article I created four dummy tasks. Each of them has a different value in regards to mentioned before parameters and on top of it one is with “type of task” is set to manual trigger as it has special way of processing the cancelation.

Task 1 – No reverse required, and data is always changeable


Task 2 – No reverse required but data can only be changed if task status is ready


Task 3 – To cancel the task reversal process is required and changeability is the less restricted to status of ready or rejected.


Task 4 – it’s like Task 3 with the single difference of Type of task processing set to Manual Processing


Cancelation:

If reversal is required for a task as wrote before task needs to get first canceled. With cancelation system executes same piece of code as for regular task but with information it’s reversal and with values multiple by -1 to get opposite sign. Special feature is manual task that can be changed to canceled without request of cancelation.