Human Capital Management Blog Posts by SAP
Get insider info on SAP SuccessFactors HCM suite for core HR and payroll, time and attendance, talent management, employee experience management, and more in this SAP blog.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Refine Retroactive Transaction Processing by Using Retro Request in APM

PhillipButts
Product and Topic Expert
Product and Topic Expert
‎2024 May 24 6:08 PM
0 Kudos
606

Although APM has built in Retro Objects that allow changes in data (changing Ownership of a member for example) to automatically trigger related transactions for reprocessing, there are times when the user will want to select targeted transaction to reprocess manually. The Retro Request Process provides the means to reprocess selected transactions based on the criteria that is specified by the user.

Standard Retroactivity

APM has standard Retroactivity objects that can be configured different entities. CustPolicy, BrokerDetail, BrokerCustomer are a few of the entities that should be configured to trigger retroactivity.

standardretro.png

Figure 1: Standard APM Retroactivity Objects

When configured, selected changes to a record with mark related transactions for reprocessing during Payout in order to pick up the change on the record. In the screenshot of the Audit record below,  the Broker Detail for Broker SC-001 was end dated 1/31/2024 on 5/14/2024. This action should trigger retroactivity for all transactions related to this broker as there may have been transactions/payments that matched to this Broker Detail for coverage periods after 1/31/2024.

 

retro.png

Figure 2: Audit Record

There are times when you want to specify the exact transactions that need to be reprocessed that may or may not be included in the standard Retroactivity objects. APM has a Retro Request feature that allows you to specify transactions to be reprocessed in the next payout.

Retro Request

To configure a Retro Request, Navigate to Manager > Payment Plans > Retro Request Search

Note: This menu item may be hidden but can be added through the Custom Menu.

  • Click the  + to create a new Retro Request
  • The Retro Mark Request Wizard - Step One screen appears as shown below in Figure 3.
  • Enter a Name for the Retro Request
  • Enter a Retro Period in YYYYMM format. This period will be the earliest Premium Period that will get  reprocessed, even if the selected transactions in the next steps are earlier than this period.
  • Enter a Comment that will describe the purpose of the Retro request and why it was needed. 
  • Select Transaction Search (uses Standard Search Screen functionality) or SQL (allows advanced users to create SQL to select desired transactions)
  • In this case Select Transaction Search and Next .retrorequest1.png

Figure 3: Retro Mark Request Wizard - Step 1

  • After you select Next, a Transaction Search Screen will open. Use the Search form to select the Transactions that you want to mark for Reprocessing. In Figure 4 (below), I have filtered on Policy "C031-001" and Premium Periods 202201 through 202405. Note: If the fields you want to filter on are not visible, you can customize the screen to show the needed fields.

retrorequest2.png

Figure 4: Retro Request Search Results screen

  • Select the desired transactions or just select Next to select them all.
  • The Mark Retro Request End screen opens with the Generated SQL that will be used during payout to select the transactions for reprocessing. The number of matching transactions to be marked will also be shown.

retrorequest3.png

Figure 5: Retro Mark Request End

  • Select Complete and the Retro Request Search Screen is displayed with the new Retro Request in Open status. You can select Calculate to confirm the number of transactions that will be reprocessed.

retrorequest4.png

Figure 6: Retro Request Search

  • Click Approve to go the the next screen.
  • Enter a comment in the Comment box and OK to make the Retro Request available for the next Payout.

TIP: The Approve button can be hidden by Security Group so users can have access to create the Retro Request but not have access to approve.

Retro Request - SQL

When creating a Retro Request, the user can select Transactions from a Transaction Search screen ( as shown in he example above) or the user can use SQL to select the desired transactions. A limitation of the Transaction Search method is that the Search is limited to TranHead fields. Although the Transaction Search screen allows you to mark Transactions related to the Writing Agent (through the BrokerNoPrimary field on TranHead),  Transactions tied to a Hierarchy Broker can not be marked using the Transaction Search method since the Broker is a TranHis level field. In this use case, the SQL Retro Request will need to be used.

Repeat the Steps above for creating a new Retro Request but Select SQL as shown in FIgure 7 below.

retrorequest10.png

Figure 7: Retro Request SQL

  • Select Next
  • Fill in the Joins and Where section as indicated by the Tips section at the bottom of the screen
  • Tips
    • Filters are required. Only type in the SQL criteria (code you'd put in the WHERE clause of a SELECT statement; exclude the WHERE).
    • For instance a filter can be: THD.CustomerNo IN (9999, 0000) AND THD.CustPolicyNo = 1111
    • It's not necessary to filter on Premium Period as this will be automatically done via the Retro Period configuration.
    • Use alias THD to reference TranHead columns and THS to reference TranHis columns.
    • If you need to filter by columns from any other tables,j oin those tables in Joins section above.
    • For instance: Left Join Customer C On C.CustomerNo = THD.CustomerNo
  • In Figure 8 below, a join to Broker is added so that the WHERE clause can reference the BrokerId.

retrorequest7.png

Figure 8: Adding Joins and Where Cause to Retro Request

  • Select Next
  • The Retro Mark Request End screen appears with the Generate SQL and the number of matching Transactions.
  • Select Next.

retrorequest12.png

Figure 9: Retro Mark Request End

  • Select Approve and the Retro Request will be processed in the next payout.

Retro Request - Entity

Additionally, a Retro Request can be created a the Broker (Producer), Customer or Policy Level.

  • Navigate to a Broker (Producer Record).
  • If enabled by Security, a Retro request button should be visible at the bottom of the screen.

retrorequest13.png

Figure 10: Retro Request - Entity

  • Select the Retro Request button and fill in the details as shown below. Note: Retro Period is in MM/YYYY format.
  • Select OK.

retorrequest14.png

Figure 11: Retro Request Entity Retro Period

The Entity Retro Request creates an audit record overrides the standard Entity Retroactivity Object with the Retro Period that you define.   This audit will get processed in the next Payout with the rest of the audits

Retroactivity is a key component of APM functionality. The ability to selectivity reprocess impacted transactions based on a configuration change provides confidence that payments are correct or will be easily corrected in the next payout. APM provides several ways to reprocess transactions through the Retro Request functionality.

Feel free to drop a comment or question!

 

Please Follow additional APM resources at:

APM WorkZone Site (Requires invitiation) 

For Invitation Please email phillip.butts@sap.com or dean.patterson@sap.com 

APM Blogs  

APM Help Docs 

Popular Blog Posts