This guide is intended to support anyone involved in the development of a service with a fee. It is an extension of the CRSM functional guide found here - RDIMS-#16482323-TRANSPORT CANADA COST RECOVERY SERVICE MANAGEMENT ONBOARDING GUIDE 

In order to reduce the effort required to develop an automated solution for services with fees and standardize the implementation, there are 7 main areas where TC has focused on to support the programs and service development teams:

1. Collecting Fixed Fees

2. Service Request Performance Calculation and Approval

3. Remission Determination, Calculation and Approval with Integration to Oracle Financials

4. Invoice Calculation and Approval with Integration to Oracle Financials

5. Collecting Non-Fixed Fees

6. Service Data Analytics

7. User Experience – Online Service

Each of these areas are supported by a combination of 3 libraries of common business capabilities:

• Common Online Payment Service (COPS)

• myTC Account

• Cost Recovery Service Management (CRSM)

Key Contacts for Core capabilities:

• Common Online Payment Service (COPS) – Michel Brault

• myTC Account (MTAPI) – Michel Larose

• CRSM (SIAPI, SPAPI, TMAPI) – Krista Miller

While this guide will focus on CRSM capabilities, it will reference COPS and myTC Account.
Detailed guidance can be found here:

• COPS Functional Guide - TBC

• myTC Account Functional Guide - TBC

Collecting Fixed Fees

Fees are split in this document between fixed and non-fixed fees. They are separated in order to best represent where they would fit into the process. For Non-Fixed Fees, the guidance will follow after an invoice has been approved.

Integration Steps

1. Service Inventory – Ensure the service and service fees are registered with SVC codes in the Service Inventory

2. myTC Account – Register the service in myTC Account and link it to Service Inventory Service

3. Service Inventory – Get the SVC codes from Service Inventory based on specific service and service attributes

4. myTC Account - Register the Service Request

5. COPS – Navigate Requester to COPS with the SVC Codes (* See "Alternate Payment Channels" below)

6. myTC Account – Link the Payment ID to the Service Request API

Alternate Payment Channels

It is not mandatory that the requester pay through COPS; they can pay through any supported payment channel supported by Finance. What is critical is the Receipt Number is captured and Step 4 and 6 still need to be completed to link the receipt to the service request.

Service Request Performance Calculation and Approval

Service Request Performance measures how well a specific request for a service performs relative to the service standard and determines whether the service standard was met or not.
Each service must first be registered in the Service Inventory Explorer where all service fees and standards will be tracked. A service standard is typically written as an elapsed time between two statuses within a service request.
e.g. Service Standard for Service X = TC will issue the certificate within 10 business days upon receiving the request

The key elements that need to be extracted from this statement is the limit - 10 Business Days, and also the two statuses that represent the start and stop, in this case Submitted and Fulfilled.
For each request for a service, a Service Request will be created within myTC Account and the status of the Service Request will be updated to create a Service Request Timeline which will be the key data to calculate the Service Request Performance.
e.g.

• Service Request #1152 for Service X was submitted on March 15th 2020 @ 1300 UTC

• Service Request #1152 Status was changed to In Progress on March 16th 2020 @ 1450 UTC

• Service Request #1152 Status was changed to On-Hold on March 17th 2020 @ 1450 UTC

• Service Request #1152 Status was changed back to In Progress on March 18th 2020 @ 1450 UTC

• Service Request #1152 Status was changed to Fulfilled on March 26th 2020 @1330 UTC

When the Service Request is ready to determine Service Request Performance, a call will be made to the API which will grab the key elements of the Service Standard from the Service Inventory and compare those elements against the Service Request Timeline for this specific request.
For this example since the standard spans from Submitted to Fulfilled, the In Progress status change is not required with the exception of subtracting any on-hold days.
e.g. Total Business Days = March 26th – March 15th = 11 days – (Weekend and Statutory Holidays) – (on hold) = 8 days

Statutory holidays and weekend days are subtracted to determine business days. In this case, 2 days were removed for the weekend. Also, any on-hold days would also be subtracted; in this case 1 day.
With a standard of 10 days in this example, the Service Standard was met with 8 days for the request.

Each calculation will get the appropriate approvals and will be stored within Service Performance.

Service Request Performance conceptual model

Integration Steps

1. Service Inventory – Register the Service in the Service Inventory with the Service Standard broken down by Statuses

2. myTC Account – Register the myTC Account Online Service and link to Service Inventory Service

3. myTC Account– Create the Service Request (if not done already)

4. myTC Account - Update the Status up to the specified Service Standard Stop status
   API: Service Request Status

5. Service Performance – Calculate the Service Request Performance against the Service Standard
   API: Service Request Performance (POST)
   Inputs: Service Request ID
   Outputs: Service Request Performance model

6. Service Performance – Retrieve Service Request Performance details
   API: Service Request Performance (GET)
   Inputs: Service Request ID
   Outputs: Service Request Performance model

Remission Determination, Calculation and Approval with Integration to Oracle Financials

Remission Determination analyses the approved Service Request performance and whether the Fee is Remittable in order to determine whether remission is required. It also calculates the remission amount based on the fee.

A flag in the Service Inventory will determine which fees are remittable. The next step is to determine if the Service Standard Performance was exceeded by 25%. In the example above if we were to push the Fulfilled Status to March 28th for a total elapsed Business Days of 11, we would have not met the Service Standard but since 11 does not exceed the standard by 25% remission is not required. If the total elapsed business days was 13 for example, then remission would be required since the standard was exceeded by 25% and assuming the fee was remittable. Each remission calculation will get the appropriate approvals and be stored within Service Performance. For approved Remission calculations, the remission will be automatically processed with integration to Oracle Financials.

Service Request Remission model

Integration Steps

1. Service Inventory - Set the Fee Remittance Flag within the Service Inventory

2. Service Performance – Calculate the Remission for a Service Request
   API: Service Request Remission (POST)
   Inputs: Service Request ID
   Outputs: Service Request Remission model

3. Service Performance – Retrieve Service Request Remission details
   API Name: Service Request Remission API (GET)
   Inputs: Service Request ID
   Outputs: Service Request Remission model

4. Service Performance – Approve Service Request Remission calculation
   API: Service Request Remission (PUT)
   Inputs: Service Request ID and TC Network ID (TC Approver)
   Outputs: Service Request Remission model

Invoice Calculation and Approval with Integration to Oracle Financials

For Services that implement up-front fixed fees, there is no requirement for invoice calculations, but several services will need the ability to calculate an invoice based on hours and potentially even based on any service outputs completed. The specifics of the fee will be stored in the Service Inventory and will include the hourly rates, caps, etc. It will also include the SVC # which are products in Oracle Financials.
e.g. Service X fee is $105 per hour regular time – SVC345

In addition to hourly rates there is also some that may require an additional fee when a specific service output is completed:
e.g. For Service X, there is an additional fee of $100 whenever Service Output W is completed – SVC346

For service output fees there may also be limits, one per day, one per request, etc.

For each Service Request, Time and Service Output entries will be required in order to calculate the invoice. These entries are separate from the Service Request Timeline which is used for Service Request Performance and only captures the timeline for when the status changes. Time and Service Output entries will have the following format:
Time/Service Output Entry:
e.g. Inspector 6653 spent 4 hours on March 20th 2020 (regular time) fulfilling Service Request #1152 and (optional) Service Output W was also completed

The Service Output is optional but if indicated, it is linked directly to a time entry and many Service Outputs can be linked to a single Time Entry.
For invoice calculations Time Entries are analyzed for the Service Request as well as any required Service Output entries:
e.g. Invoice for Service Request #1152 = 4 x $105 (SVC345) + 1 x $100 (SVC346) = $520
Each invoice would get the appropriate approvals and when approved it would be generated in Oracle Financials and the invoice number would be stored under the users account. The user would be notified to then pay online.

Time Management Conceptual Model

Integration Steps

1. Service Inventory – Register Service Attributes, Fee Details, and SVC Codes, Service Outputs, Service Activities, Type of Time (regular, OT – Double, OT Time and Half, Stand-by), Fee Type (Fixed up front, Fixed after assessment, time based fee, etc.)

2. myTC Account – Account Created (Customer link will be here)

3. myTC Account – Service Request Registered and linked to Account

4. Service Inventory – Get Service Activities, Service Outputs and Types of Time

   • API: Service Activities (GET)

   • Input: Service Attribute ID

   • Output: List of applicable Service Activities

   • API: Service Outputs (GET)

   • Input: Service Attribute ID and Service Activity ID

   • Output: List of applicable Service Outputs

   • API: Types of Time (GET)

   • Input: None

   • Output: List of all Types of Time

5. Time Management – Create Time, Hours and Service Output Entries linked to Service Request

   • API: Time Entry (POST)

   • Inputs: Service Request ID, Date, Activity, TC User (TC Network ID), Comment, Status

   • Outputs: Time Entry model

   • API: Time Entry/Hours (POST)

   • Inputs: Time Entry ID, Time, Type of Time, isBillable

   • Outputs: Hour Entry model

   • API: Time Entry/Service Output (POST)

   • Inputs: Time Entry ID, Service Output ID

   • Outputs: Service Output Entry model

6. Time Management – Retrieve Time, Hours, and Service Output Entries

   • API: Time Entry (GET)

   • Inputs: Time Entry ID

   • Outputs: Time Entry model with Hours and Service Outputs included

7. Time Management – Approve Time, Hours, and Service Output Entries

   • API: Time Entry (PUT)

   • Inputs: Time Entry ID, Approver TC Network ID

   • Outputs: Time Entry model with Hours and Service Outputs included

8. Service Performance – Request Invoice Calculation (by optional date range)

   • API: Invoice/Summary (POST)

   • Inputs: Service Request ID, Start Date (optional), End Date (optional)

   • Outputs: Invoice Model (Invoice Summary ID, Service Request ID, Total, Payment Items)

   • Payment Items (Payment Item ID, Invoice Summary ID, SVC #, quantity)

9. Service Performance – Request Invoice Number

   • API: Invoice/Invoice Number (POST)

   • Inputs: Invoice Summary ID

   • Output: Invoice Number from Oracle Financials

Collecting Non-Fixed Fees

Non fixed fees are collected through the Online Invoice Payment System and will call COPS in order to process the payment online.

Integration Steps

1. myTC Account – Get Invoice Number from Approved Invoice from Oracle Financials

2. myTC Account – Get Customer Number from Account which came from Oracle Financials

3. OIPS – Navigate User to OIPS to process payment

Alternate Payment Channels

In step 3, it is not mandatory that the requester pays through OIPS, they can pay through any supported payment channel supported by Finance.

Service Data Analytics

Service Data Analytics will analyse all services in order for TC to ensure fees and service standards are set appropriately and as well as meet any reporting requirements to TC and TBS. All the integrations steps included in this document are designed to ensure that TC can quickly and standardize the retrieval for the following key areas for each service:

User Experience

In order to improve the user experience there are 3 main outputs that each service is required to ensure it is met:

1. Online Request for Service – ensure there is an online page that is available for users to initiate and submit request for services and is located by the standard service initiation page

2. Online ability to view status – ensure there is the ability for user to get the status of a request online

3. Online ability to provide feedback – ensure there is the ability for user to provide feedback on a particular feedback
   All of these outputs are supported by the myTC Account platform, and have been integrated into the CRSR application as a sample for developers.