# WRICEF Object Specification: [Object ID] [Object name]

> Combined functional and technical specification for one development
> object in a packaged-application project: a workflow, report,
> interface, conversion, enhancement or form (WRICEF). It links the
> object to the approved gap, describes the business requirement and
> functional design, the type-specific design, the technical design and
> its clean core rating, data mapping, error handling, security,
> non-functional needs, test cases, transport and deployment, and
> operational handover. WRICEF is an object classification used by
> systems integrators on SAP and other ERP programmes (SAP Activate
> names WRICEF identification and design as Explore phase work for
> private cloud and on-premise projects). Replace every `[bracketed]`
> value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write one specification per object. Several objects that always move
  together (an interface and its error report) may share one, but each
  keeps its own ID.
- The functional consultant writes sections 1 to 4 and the developer
  sections 5 to 11; both review the whole document. Do not start build
  until sections 1 to 4 are approved.
- Section 4 has one subsection per WRICEF type. Keep the subsection for
  your type and delete the others.
- An object exists only because a gap was approved: section 2 must cite
  the fit-gap ID and decision.
- Related documents: Fit-Gap Analysis (`architecture/fit-gap-analysis`),
  SAP S/4HANA Solution Design (`architecture/sap-s4hana-solution-design`),
  Integration Design (`architecture/integration-design`), Data Migration
  Strategy (`architecture/data-migration-strategy`), Functional
  Specification (`requirements/functional-specification`), Test Case
  Specification (`quality/test-case-specification`).
-->

## Document control

<!-- Guidance: Identify the object, its type and complexity and the release it belongs to. A change to the business requirement or the clean core level is a new major version; a technical correction is a minor version. -->

| Field | Value |
|---|---|
| Document ID | [WRS-001] |
| Object ID | [INT-AP-003] |
| Object name | [Scanned supplier invoices to draft invoices] |
| WRICEF type | [W / R / I / C / E / F] |
| Complexity | [Low / Medium / High / Very high] |
| Fit-gap ID and decision | [FG-NNN], [FGD-NNN] |
| Target system and release | [Product, edition, release] |
| Delivery release | [R1] |
| Version | [0.1] |
| Status | [Draft / Functional approved / Technical approved / Built / Tested / Deployed] |
| Owner | [@functional-consultant] |
| Approvers/reviewers | [@process-owner], [@solution-architect], [@dev-lead], [@security-reviewer] |
| Developer | [@developer] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Scope | Decision | Date |
|---|---|---|---|---|
| Process owner | [@name] | Sections 1 to 4 | [Approve / Reject] | YYYY-MM-DD |
| Solution architect | [@name] | Sections 4 to 6, clean core level | [Decision] | YYYY-MM-DD |
| Development lead | [@name] | Sections 5 to 11 | [Decision] | YYYY-MM-DD |
| Security reviewer | [@name] | Section 8 | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft of functional design |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Functional and technical design approved |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added duplicate check after integration test defect DEF-221 |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Object summary](#1-object-summary)
2. [Business requirement](#2-business-requirement)
3. [Functional design](#3-functional-design)
4. [Type-specific design](#4-type-specific-design)
5. [Technical design](#5-technical-design)
6. [Data and mapping](#6-data-and-mapping)
7. [Error handling, logging and monitoring](#7-error-handling-logging-and-monitoring)
8. [Security and authorisations](#8-security-and-authorisations)
9. [Non-functional requirements](#9-non-functional-requirements)
10. [Test cases](#10-test-cases)
11. [Transport and deployment](#11-transport-and-deployment)
12. [Operations and support handover](#12-operations-and-support-handover)
13. [Traceability and sign-off](#13-traceability-and-sign-off)
14. [Glossary and references](#14-glossary-and-references)

## 1. Object summary

<!-- Guidance: Give a reader the whole object in one table. Questions: what type is it, how complex, which processes does it touch, what is its clean core level? Pitfall: complexity chosen to fit the budget rather than the design. -->

| Item | Value |
|---|---|
| One-line description | *Example:* Receive scanned supplier invoices from the capture provider and create draft supplier invoices for review |
| Process | *Example:* PRC-011 Supplier invoice with three-way match |
| Users affected | *Example:* 25 accounts payable clerks in 4 companies |
| Frequency and volume | *Example:* Continuous, 600 invoices per day, peak 1,500 at month end |
| Clean core level | *Example:* A (released API, Integration Suite) |
| Build effort | *Example:* 10 person-days (estimate range 8 to 12) |
| Dependencies | *Example:* Capture provider sandbox, supplier master migrated, communication arrangement set up |

### 1.1 WRICEF types used in this project

| Code | Type | Covers | Typical specification focus |
|---|---|---|---|
| W | Workflow | Approvals, notifications and multi-step tasks between people or systems | Steps, agents, deadlines, escalation |
| R | Report | Lists, analytical views and extracts for users | Selection, layout, calculations, authorisation |
| I | Interface | Data exchange with another system, in either direction | Pattern, protocol, mapping, error handling |
| C | Conversion | One-time or repeated migration of legacy data | Source, mapping, load method, reconciliation |
| E | Enhancement | Added or changed logic at a supported extension point | Trigger, logic, extension point, side effects |
| F | Form | Printed, emailed or electronic documents | Layout, data, channel, languages |

### 1.2 Complexity rules

| Complexity | Guideline (*Example*) | Effort band |
|---|---|---|
| Low | One source, simple mapping, no new logic beyond validation | Up to 5 person-days |
| Medium | Several sources or rules, error handling, one external system | 5 to 15 person-days |
| High | Complex logic, several systems or high volume | 15 to 40 person-days |
| Very high | New application or algorithm, many systems, strict performance | Over 40 person-days; split if possible |

## 2. Business requirement

<!-- Guidance: Explain why the object exists in business words. Questions: what gap does it close? What is the cost of not building it? Why were the standard and simpler options rejected? Pitfall: describing a technical solution as the requirement. -->

| Item | Value |
|---|---|
| Fit-gap reference | *Example:* FG-005, decision FGD-002 |
| Need | *Example:* Supplier invoices arrive as paper and PDF; clerks retype them, causing delays and errors |
| Expected benefit | *Example:* Remove manual keying for 80% of invoices; cut posting time from 2 days to same day |
| Options rejected | *Example:* Second capture product (duplicates current contract); manual upload (no saving) |
| Mandatory drivers | *Example:* None legal; internal control requires an audit trail from image to posting |
| Acceptance criteria | *Example:* A scanned invoice appears as a draft within 5 minutes with supplier, amount, currency, tax and order reference filled; the image is linked |

### 2.1 Business rules

| Rule ID | Rule | Source |
|---|---|---|
| BR-001 *(Example)* | An invoice with an order reference is matched to the order; without one it goes to the non-order queue | AP policy section [n] |
| BR-002 *(Example)* | A duplicate is an invoice with the same supplier, invoice number and amount within 12 months | AP policy |
| BR-003 *(Example)* | Invoices above USD 50,000 need a second reviewer before posting | Delegation of authority |
| [BR-NNN] | [Rule] | [Source] |

## 3. Functional design

<!-- Guidance: Describe what the object does from the user's view: trigger, inputs, processing steps, outputs and exceptions. Pitfall: leaving exceptions to the developer, who then invents business rules. -->

### 3.1 Process flow

Show the user-visible steps and every exit to an error path; *Example*
for INT-AP-003 below.

```mermaid
flowchart LR
    A[Capture provider extracts invoice] --> B[Integration flow receives document]
    B --> C{Supplier found and data valid?}
    C -- No --> E[Error queue for AP clerk]
    C -- Yes --> D{Duplicate per BR-002?}
    D -- Yes --> E
    D -- No --> F[Create draft supplier invoice and attach image]
    F --> H{Order reference present per BR-001?}
    H -- No --> N[Non-order queue]
    H -- Yes --> I{Amount above USD 50,000 per BR-003?}
    N --> I
    I -- Yes --> R[Second reviewer approves]
    I -- No --> G[Clerk reviews and posts]
    R --> G
```

### 3.2 Trigger, inputs and outputs

| Item | Description |
|---|---|
| Trigger | *Example:* New document from the capture provider (push) |
| Inputs | *Example:* Invoice header, lines, tax, PDF image, capture confidence per field |
| Processing | *Example:* Validate supplier, company, currency; apply BR-001 to BR-003; create draft |
| Outputs | *Example:* Draft supplier invoice with image link; status message back to the provider |
| Exceptions | *Example:* Unknown supplier, closed period, duplicate, low capture confidence: send to error queue with reason |

## 4. Type-specific design

<!-- Guidance: Keep only the subsection for your object type and delete the rest. Each subsection lists the questions the type must answer. Pitfall: generic text that would fit any object. -->

### 4.1 Workflow (W)

| Item | Design |
|---|---|
| Business object and event that starts it | [Object, event] |
| Steps and agents | [Step, agent rule (role, org unit, amount), parallel or sequential] |
| Deadlines and escalation | [Deadline per step, escalation target] |
| Substitution and absence | [Rule] |
| Notifications | [Channel, content, recipients] |
| Tool | [Standard flexible workflow / platform workflow service / process automation tool] |

### 4.2 Report (R)

| Item | Design |
|---|---|
| Purpose and users | [Who decides what with this report] |
| Standard alternatives checked | [Standard apps or analytics content shown and why rejected] |
| Selection criteria | [Fields, mandatory or optional, defaults] |
| Output layout | [Columns, sorting, totals, drill-down] |
| Calculations | [Formula per derived field] |
| Data sources | [Released views or tables] |
| Delivery | [Interactive app, scheduled extract, analytics story] |

### 4.3 Interface (I)

| Item | Design |
|---|---|
| Source and target | *Example:* Capture provider (source), ERP (target) |
| Direction and pattern | *Example:* Inbound, asynchronous push |
| Protocol and format | *Example:* HTTPS REST with JSON; image as base64 or link |
| Middleware | *Example:* Integration platform, one integration flow |
| Target API | *Example:* Released supplier invoice API (check the vendor's API hub for the current version) |
| Volume and timing | *Example:* 600 per day average, 1,500 per day peak, 5-minute latency target |
| Idempotency | *Example:* Provider document ID stored as external reference; repeats are ignored |
| Reference specification | Integration Design (`architecture/integration-design`) entry INT-AP-003 |

### 4.4 Conversion (C)

| Item | Design |
|---|---|
| Migration object | [Object name, for example open supplier items] |
| Source systems and extract | [System, extract method, cut-off] |
| Load method and tool | [For SAP: SAP S/4HANA Migration Cockpit with staging tables or direct transfer; other tool] |
| Cleansing and enrichment | [Rules, owners] |
| Load sequence and dependencies | [Objects that must load first] |
| Reconciliation | [Counts, totals, samples: see Data Migration Reconciliation Report (`project/data-migration-reconciliation`)] |
| Mock loads | [Number and dates] |

### 4.5 Enhancement (E)

| Item | Design |
|---|---|
| Standard behaviour | [What the product does today] |
| Required behaviour | [What must change and when] |
| Extension point | [Released extension point, business add-in, event or API] |
| Side effects | [Other processes that use the same point] |
| Switch | [How to deactivate the enhancement without transport, if possible] |

### 4.6 Form (F)

| Item | Design |
|---|---|
| Document and trigger | [For example customer invoice, on billing document creation] |
| Channels | [Print, email, electronic invoice network, archive] |
| Layout | [Mock-up reference, logo, sections, page breaks] |
| Data fields | [Field list with source] |
| Languages and countries | [Languages; country texts; legal mentions] |
| Output determination | [Rules for when and to whom] |

## 5. Technical design

<!-- Guidance: Describe how the object is built so another developer could maintain it. Questions: which technology and extension technique, why, which clean core level, which objects are created? Pitfall: relying on unreleased internal objects without recording the risk. -->

### 5.1 Technology and clean core rating

| Item | Value |
|---|---|
| Technique | *Example:* Side-by-side integration flow; released API on the ERP |
| Clean core level | *Example:* A (SAP levels A to D; for other packages use the vendor's upgrade-safe criteria) |
| Justification for any level B, C or D | *Example:* Not applicable |
| Alternatives considered | *Example:* On-stack custom API (rejected: released API exists) |

### 5.2 Components

| Component ID | Component | Kind | Package or namespace | Purpose |
|---|---|---|---|---|
| CMP-01 *(Example)* | IF_AP_SCAN_INVOICE | Integration flow | [Package] | Receive, validate, map and call the API |
| CMP-02 *(Example)* | VM_AP_COMPANY | Value mapping | [Package] | Map provider company codes to ERP company codes |
| CMP-03 *(Example)* | AP_SCAN_ERRORS | Error queue view | [Package] | List rejected documents for clerks |
| [CMP-NN] | [Name] | [Kind] | [Package] | [Purpose] |

### 5.3 Processing logic

Write the logic as pseudocode in the order it runs, naming each error
reason used in section 7. *Example*:

```text
receive document from provider
  if external reference already processed: acknowledge, stop
  validate mandatory fields; on failure: error queue (reason MISSING_FIELD)
  map company and supplier; on failure: error queue (reason UNKNOWN_SUPPLIER)
  check duplicate per BR-002; on match: error queue (reason DUPLICATE)
  call supplier invoice API as draft, attach image
  on success: store external reference, acknowledge provider
  on technical error: retry 3 times with backoff, then alert
```

### 5.4 Configuration needed

| Item | Value | Environment |
|---|---|---|
| *Example:* Communication arrangement for the invoice API | [Arrangement ID] | Test and production |
| *Example:* Technical user with API role only | [User] | All |
| [Item] | [Value] | [Env] |

## 6. Data and mapping

<!-- Guidance: Map every target field: source, rule and default. Questions: which fields are mandatory in the target? What happens to unmapped source fields? Pitfall: mapping only the happy path and discovering mandatory target fields in testing. -->

### 6.1 Field mapping

| Map ID | Target field | Mandatory | Source field | Rule | Default |
|---|---|---|---|---|---|
| MAP-01 *(Example)* | Company code | Yes | header.companyId | Value map VM_AP_COMPANY | None: error |
| MAP-02 *(Example)* | Supplier | Yes | header.vatId | Look up supplier by tax number | None: error |
| MAP-03 *(Example)* | Document date | Yes | header.invoiceDate | ISO date to target format | None: error |
| MAP-04 *(Example)* | Gross amount | Yes | header.total | Decimal, 2 places | None: error |
| MAP-05 *(Example)* | Currency | Yes | header.currency | ISO 4217 code | Company currency |
| MAP-06 *(Example)* | Purchase order | No | lines[].poNumber | First non-empty value | Empty |
| MAP-07 *(Example)* | External reference | Yes | documentId | Copy | None: error |
| [MAP-NN] | [Field] | [Y/N] | [Source] | [Rule] | [Default] |

### 6.2 Value mapping

| Source value | Target value | Owner |
|---|---|---|
| *Example:* ACME-DE | DE01 | [@ap-lead] |
| *Example:* ACME-FR | FR01 | [@ap-lead] |
| [Value] | [Value] | [@owner] |

## 7. Error handling, logging and monitoring

<!-- Guidance: Separate business errors (a user fixes data) from technical errors (support fixes the system). Name who sees each error and how fast. Pitfall: errors visible only in middleware logs, which no business user reads. -->

| Error ID | Error | Type | Detected by | Handling | Notified | Target time to resolve |
|---|---|---|---|---|---|---|
| ERR-01 *(Example)* | Unknown supplier | Business | Validation step | Error queue with reason; clerk fixes master data and reprocesses | AP clerks | 1 working day |
| ERR-02 *(Example)* | Duplicate invoice | Business | Duplicate check | Error queue; clerk confirms or rejects | AP clerks | 1 working day |
| ERR-03 *(Example)* | Target API unavailable | Technical | API call | 3 retries with backoff, then alert | Integration support | 4 hours |
| ERR-04 *(Example)* | Authentication failure | Technical | API call | No retry; alert | Integration support, security | 2 hours |
| [ERR-NN] | [Error] | [Type] | [Where] | [Handling] | [Who] | [Time] |

Logging: record external reference, status, timestamps and error reason
per message; never log full bank details or personal data beyond what
support needs. Monitoring: [Integration monitoring tool], alert rules
[names], dashboard [link].

## 8. Security and authorisations

<!-- Guidance: State who can run, see and change what, and how data is protected in transit and at rest. Questions: which technical users exist and what can they do? Does the object open a path around segregation of duties? Pitfall: technical users with broad roles because it was quicker in development. -->

| Item | Design |
|---|---|
| User access | *Example:* Clerks see the error queue for their companies only |
| Technical user | *Example:* Dedicated communication user limited to the invoice API; certificate-based authentication |
| Segregation of duties | *Example:* Object creates drafts only; posting stays with clerks, so the approval control is unchanged |
| Data in transit | *Example:* TLS 1.2 or higher on every hop |
| Data at rest | *Example:* Images stored in the document store with retention per policy |
| Personal data | *Example:* Supplier contact names only; covered by the existing record of processing |
| Audit trail | *Example:* Draft links image, external reference and creating user |

## 9. Non-functional requirements

<!-- Guidance: Give measurable targets the developer can test. Pitfall: "fast" and "reliable" without numbers. -->

| NFR ID | Quality | Requirement | Verification |
|---|---|---|---|
| NFR-01 *(Example)* | Latency | 95% of documents appear as drafts within 5 minutes | Integration test with timestamps |
| NFR-02 *(Example)* | Throughput | 1,500 documents in 8 hours without backlog | Volume test |
| NFR-03 *(Example)* | Reliability | No document lost; every document ends as draft or in the error queue | Reconciliation of provider count to ERP count |
| NFR-04 *(Example)* | Upgradeability | Uses released APIs only; passes upgrade regression test | Regression suite per release |
| [NFR-NN] | [Quality] | [Requirement] | [Method] |

*Example* throughput check: 1,500 documents in 8 hours is 187.5 per
hour, about 3.1 per minute, well within the API's tested rate.

## 10. Test cases

<!-- Guidance: Cover the acceptance criteria, each business rule and each error. Name the level: unit, functional unit test, integration, user acceptance. Pitfall: testing only the happy path with clean data. -->

| Test ID | Level | Scenario | Data | Expected result | Covers |
|---|---|---|---|---|---|
| TC-AP-010 *(Example)* | Functional | Valid invoice with order reference | Supplier S1, order 4500001 | Draft created, image linked, within 5 minutes | Acceptance, BR-001 |
| TC-AP-011 *(Example)* | Functional | Invoice without order reference | Supplier S2 | Draft in non-order queue | BR-001 |
| TC-AP-012 *(Example)* | Integration | Duplicate within 12 months | Repeat of TC-AP-010 | Error queue, reason DUPLICATE | BR-002, ERR-02 |
| TC-AP-013 *(Example)* | Functional | Amount above USD 50,000 | Supplier S1, USD 62,000 | Draft flagged for second reviewer | BR-003 |
| TC-AP-014 *(Example)* | Integration | Unknown supplier | Tax number not in master | Error queue, reason UNKNOWN_SUPPLIER | ERR-01 |
| TC-AP-015 *(Example)* | Integration | Target API down | Stop API in test | 3 retries then alert | ERR-03 |
| TC-AP-016 *(Example)* | Performance | Peak volume | 1,500 documents | All processed within 8 hours | NFR-02 |
| TC-AP-017 *(Example)* | User acceptance | Month-end batch from real scans | 200 anonymised scans | Clerks confirm drafts are correct | Acceptance |
| [TC-ID] | [Level] | [Scenario] | [Data] | [Expected] | [Covers] |

Test planning and acceptance follow the UAT Plan (`quality/uat-plan`).

## 11. Transport and deployment

<!-- Guidance: List every artefact that must move and the order. Questions: which transport or deployment tool, which manual steps, how to roll back? Pitfall: configuration steps done by hand in production and never documented. -->

| Step | Artefact | Tool | Environment order | Manual step | Rollback |
|---|---|---|---|---|---|
| 1 *(Example)* | Communication arrangement and technical user | Manual configuration with checklist | Test, then production | Yes: certificate upload | Deactivate arrangement |
| 2 *(Example)* | Integration package | Cloud transport service | Development, test, production | No | Redeploy previous version |
| 3 *(Example)* | Value mappings | Integration package | With step 2 | Production values checked | Previous version |
| 4 *(Example)* | Monitoring alert rules | Monitoring tool export | Test, then production | No | Disable rule |
| [n] | [Artefact] | [Tool] | [Order] | [Manual] | [Rollback] |

Transport request or package IDs: [IDs]. Deployment window and freeze
dates follow the Cutover Plan (`project/cutover-plan`).

## 12. Operations and support handover

<!-- Guidance: Give support what they need on day one: what normal looks like, what to check when it fails, who owns the data. Pitfall: handover that consists of a link to this document and nothing else. -->

| Item | Value |
|---|---|
| Support group | *Example:* Integration support (level 2), AP key users (level 1 for business errors) |
| Normal behaviour | *Example:* 400 to 900 documents per day; under 3% to the error queue |
| Health checks | *Example:* Daily count reconciliation between provider and ERP; alert on queue older than 1 day |
| Known limits | *Example:* Multi-currency invoices with mixed tax rates go to the error queue by design |
| Runbook | [Link to runbook] |
| Owner after go-live | [@application-owner] |

The handover follows the Operations Handover (`ops/operations-handover`).

## 13. Traceability and sign-off

<!-- Guidance: Link the object to the gap, the requirement rules and the tests, and record build and test completion. Pitfall: sign-off before integration testing, so defects reopen the specification without a version change. -->

| Requirement or rule | Design section | Component | Test case | Result |
|---|---|---|---|---|
| Acceptance criterion *(Example)* | 3.2, 4.3 | CMP-01 | TC-AP-010, TC-AP-017 | [Pass / Fail] |
| BR-001 *(Example)* | 2.1, 5.3 | CMP-01 | TC-AP-010, TC-AP-011 | [Result] |
| BR-002 *(Example)* | 2.1, 5.3 | CMP-01 | TC-AP-012 | [Result] |
| BR-003 *(Example)* | 2.1, 3.1 | CMP-01 | TC-AP-013 | [Result] |
| NFR-02 *(Example)* | 9 | CMP-01 | TC-AP-016 | [Result] |
| [ID] | [Section] | [CMP] | [TC] | [Result] |

| Milestone | Name | Date |
|---|---|---|
| Functional design approved | [@process-owner] | YYYY-MM-DD |
| Technical design approved | [@dev-lead] | YYYY-MM-DD |
| Build complete, unit tested | [@developer] | YYYY-MM-DD |
| Integration test passed | [@test-lead] | YYYY-MM-DD |
| User acceptance passed | [@process-owner] | YYYY-MM-DD |
| Deployed to production | [@release-manager] | YYYY-MM-DD |

## 14. Glossary and references

<!-- Guidance: Define the terms a new team member needs and list the documents this specification depends on, with versions. -->

### 14.1 Glossary

| Term | Meaning |
|---|---|
| WRICEF | Workflows, Reports, Interfaces, Conversions, Enhancements, Forms; some teams use RICEFW or RICEF for the same set |
| Clean core level | SAP's A to D rating of how upgrade-safe an extension is |
| Released API | Interface the vendor commits to keep stable across releases |
| Extension point | Place in vendor code designed for customer logic |
| Integration flow | Middleware artefact that receives, transforms and routes messages |
| Value mapping | Table that translates codes between systems |
| Staging tables | Database tables used to stage data for the migration tool |

### 14.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| SAP Learning, Discovering SAP Activate: Explore phase overview, learning.sap.com | Checked 2026-10-23 | WRICEF identification and design in Explore |
| SAP News, "Extend SAP S/4HANA Cloud the Right Way: Clean and Clear", news.sap.com | 2025-08-12 | Clean core levels A to D |
| SAP Business Accelerator Hub, api.sap.com | Check current API version | Released APIs and events |
| Fit-Gap Analysis (`architecture/fit-gap-analysis`) | This library | Source of the gap and decision |
| [Project development standards] | [Version] | Naming, packages, code review |

## Standard and licence note

Structure aligned with the WRICEF object classification used in
systems-integrator practice on ERP programmes and with the Explore
phase deliverables of SAP Activate, using only phase, type, tool and
level names. No SAP methodology content or third-party specification
templates are reproduced; all text, examples and tables are original
and written for this collection. Check the current vendor
documentation before use. SAP, SAP Activate and SAP S/4HANA are
trademarks of SAP SE or its affiliates; this template is not affiliated
with or endorsed by them. Template licence: MIT.