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.
Document control
| 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
1. Object summary
| 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
| 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
3.1 Process flow
Show the user-visible steps and every exit to an error path; Example
for INT-AP-003 below.
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
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
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:
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
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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
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.