Understanding Project-Based Service Procurement in Headquarter-Subsidiary Model (3TQ)

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Define process steps for Project-Based Service Procurement in Headquarter-Subsidiary Model (3TQ)
  • Identify business roles for Project-Based Service Procurement in Headquarter-Subsidiary Model (3TQ)

Process Steps for Project-Based Service Procurement in Headquarter-Subsidiary Model (3TQ)

Applicable Process Steps

You can discover the process steps with the following Bingo game. 

The tables below also recapitulates the process steps of Project-Based Service Procurement in Headquarters-Subsidiary Model (3TQ).

Service Procurement by Headquarter
Process StepDescription
Create Purchase OrderAs the headquarters (HQ), you must implement a project for your customer or complete an internal project. If you would like to implement this project via your subsidiary, you must procure the project services from your subsidiary by creating a purchase order in your headquarter system (for example, SAP ECC, SAP S/4HANA On-premise, or SAP S/4HANA Cloud).
Monitor Purchase Order Items (Optional)You can monitor each item in the Monitor Purchase Order Items application. By default, only overdue items are listed in the app.
Read Purchase Order (Visibility Scenario) (Optional)The project manager at the subsidiary should have the visibility of the purchase order created at the headquarter. This "visibility scenario" is not covered as part of the test script, however, the APIs/CDS views required to execute this scenario is listed at the beginning of the test script (from SAP Best Practices Explorer).
Project Implementation at Subsidiary
Process StepDescription
Create a New Customer ProjectOnce the subsidiary and HQ agree on the project implementation, the subsidiary can proceed with preparation for the project. As a project manager at the subsidiary, you will create a new customer project based on the purchase order created at HQ for the implementation of the project. This process is covered in detail in the scope item Customer Project Management (J11).
Copy a Project as Basis for New ProjectOne method of creating a project is by making a copy of an existing customer project.
Maintain Work Packages and Time-Based PlanningOnce the project is created, you need to define the work packages and time-based planning information.
Maintain Work Package StaffingAfter roles have been assigned to the work packages, the project team can be staffed to specific work packages. If the scope item Advanced Resource Management (1KC) is active, the resource manager will complete the staffing.
Maintain Customer Project BillingThe project manager must also maintain the project billing information.
Capture Service Units (Optional)In this optional step, the usage-based services are captured in a project as a base for billing. The possible use cases are:
  • Billing of licenses over a time period
  • Billing of support tickets raised by the customer
  • Billing of calls to a support hotline
The calls and tickets might be related to a maintenance contract with a base amount of support services. Services exceeding the base amount are additionally billed to the customer.
Time Recording through Manage My TimesheetAs an employee staffed to the project (from the subsidiary), you perform your time recording through the Manage My Timesheet app. More information about recording time against projects is covered in the Time Recording (J12) scope item.
Time Recording for Contingent WorkerThe project might require contract/contingent workers in addition to the in-house experts. The contingent worker(s) must be staffed to the relevant work package(s) to record their time. The system checks on the work item selection and the billing control category based on the purchase order account assignment category when allowing a task to be created in Manage My Timesheet for a contingent worker.
Time Recording for Contingent WorkerThe project might require contract/contingent workers in addition to the in-house experts. The contingent worker(s) must be staffed to the relevant work package(s) to record their time. The system checks on the work item selection and the billing control category based on the purchase order account assignment category when allowing a task to be created in Manage My Timesheet for a contingent worker.
Approval of Working Times (Internal worker)After time recording has been completed and (optionally) approved by managers, a service entry sheet (SES) is automatically created. For each time recording, one SES will be created with one item. Bundling multiple time recordings within one SES is not supported.
Approval of Working Times (Contingent worker)The recorded time of the contingent worker will require approval from the project manager at the subsidiary. The approved data is transferred to the target components for further processing through a background job.
Maintain Customer Project Billing ProposalThe customer project billing proposals can be maintained by the project manager at the subsidiary.
Release Customer Project Billing ProposalThe customer project billing proposal can then be released by the project manager at the subsidiary. The leads to the creation of a Debit Memo Request (DMR).
BillingIn billing, there are 3 possible scenarios:
  • Processing of the existing Debit Memo Requests (DMR), where the DMR created as a part of the previous steps is processed to create the invoice.
  • Processing of Manual Debit Memo Requests, where the Internal Sales Representative creates a manual debit memo request (without reference to any preceding document).
  • Processing of Manual Credit Memo Requests, where the Internal Sales Representative creates a manual credit memo request (without reference to any preceding document).
Create Supplier Invoice at HQThe creation of the billing document at the subsidiary should lead to the automatic generation of the supplier invoice at HQ. HQ should have the visibility to see the debit memo requests and credit memo requires created by the subsidiary before the final billing is done. This removes the possibility of re-work and keeps the subsidiary and HQ on the same page.
Supplier Invoice Management at Headquarter
Process StepDescription
Approve Supplier Invoice (Optional)In this optional step, the supplier invoice is approved by the Accounts Payable Accountant.
Workflow for Approving Supplier Invoice (Optional)Another option is for the supplier invoice to be approved by the Project Manager or Purchasing Manager at HQ.
Release Supplier InvoiceAn approver can release the supplier invoice.
Project Closure at Subsidiary
Process StepDescription
Review Customer ProjectThe customer project KPIs are analyzed. As a project manager at the subsidiary, you can see the Percentage of Completion and set the project status based on the Overall Status, Budget, Staffing, and Execution. HQ can also view the current state of the customer project in the subsidiary's SAP S/4HANA Cloud system.
Set Project Status (Completed)Once the project billing is completed, the project manager at the subsidiary completes the project by setting the status to Completed.
Close Customer ProjectsIn this step, the customer project is closed. Please note, the following business processes must be completed before this step: Event-Based Revenue Recognition (1IL), and Profitability and Cost Analysis (J55).

Business Roles for Project-Based Service Procurement in Headquarter-Subsidiary Model (3TQ)

Access to business applications is controlled by role-based authorization management. You assign Business Roles to Business Users, and the roles provide access to business tasks. Business Users are defined as employees, contractors, or other individuals that need access to the SAP S/4HANA Cloud system.

How to Find Business Roles for a Scope Item

  1. Navigate to SAP Best Practices for SAP S/4HANA Cloud‎ .
  2. Select your country localization from the Version drop-down list
  3. In the Solution Scope section, expand the relevant scope item group
  4. Select a scope item
  5. Download the test script
  6. Navigate to the Roles section of the test script

A Business Role is assigned to a Business User to grant permission to access applications in SAP S/4HANA Cloud.

One or more Business Catalogs have been assigned to a Business Role. Business Catalogs include access to one or more applications, dashboards, or displays of data.

Administrators can control visibility to the data granted through the catalog by applying General Restrictions to Business Catalogs. By maintaining access restrictions, you can define the subset of all existing business objects a user can view (read) or edit (write) when working with a particular business role.

The Business Catalog defines which access categories are available (Value Help, Read, Write), and for which fields restriction values can be maintained. The fields vary per catalog, as they are based on the fields within the apps in the catalog. The Business Role aggregates restrictions for all Business Catalogs.

Administrators define a restriction based on a supported field (e.g. company code, country, controlling area, etc.). Supported restriction fields vary per Business Catalog, as they are based on the fields within the apps in the catalog. You can restrict data access for the Value Help, Read, and Write separately. Read access always includes Value Help access, and Write access always includes Read access.

How to identify the Business Catalog(s) mapped to a Business Role and the Fiori application(s) mapped to a Business Catalog :

  1. Log into the SAP S/4HANA Cloud system.
  2. Select the Manage Business Roles application from the Launchpad.
  3. Select a Business Role.
  4. Select the Assigned Business Catalogs tab to view the standard Business Catalogs assigned to the standard Business Role.
  5. Select a Business Catalog.
  6. Select the Catalog Description tab to view the Functional Description, Authorization Criteria, and Associated Catalogs information.
  7. Select the Applications tab to view the Fiori apps mapped to the Business Catalog.
Note
Please do not edit SAP Standard Business Roles directly. To customize Business Roles, always make a copy of the SAP Standard Business Role or use the option Create From Template in the Maintain Business Roles application.

To apply General Restrictions, an Administrator should first make a copy of the SAP Standard Business Role, or create a new role based on the SAP Standard Business Role Template. For example, if you need to restrict access in the Accounts Payable Accountant Business Role for some users to only Company Code 1710 (United States), and for some users to only Company Code 1010 (Germany), you will create two new Business Roles based on the SAP Standard Accounts Payable Accountant role. You should name the roles accordingly (e.g. Accounts Payable Accountant_1710). In the first business role, you will edit the role and maintain the restriction value(s) for the entire Business Role (i.e. define the Company Code field = 1710). Then, you may edit the individual business catalogs within the role and define the access category (i.e. Value Help, Read, Write) as Restricted. When you create a new Business Role, the Read access is set to Unrestricted and Write access is set to No Access by default. When an access category is Restricted, you must select a specific field value (e.g. Company Code = 1710) or grant unrestricted access. If you leave fields empty within a business catalog, a user will be assigned No Access to the field in the business catalog's granted apps.

Save progress to your learning plan by logging in or creating an account

Login or Register