---
title: "Configuration and Report Specification Template (IDK-12)"
date: 2026-09-21
description: "Ready-to-use template IDK-12: Configuration and Report Specification for IFS Cloud projects, aligned with the IFS implementation methodology."
author: "Dariusz Mysliwiec"
categories:
  - name: "Implementation docs kit"
    url: "https://www.ifs-erp.com/implementation-docs-kit.md"
---

# Configuration and Report Specification Template (IDK-12)

Template IDK-12, version 1.0. Phase: Establish Solution.

 ## How to use this template

 
- Use one specification per configuration or report in the CRIM log (template [IDK-10](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/10-crim-log)): custom fields, custom events, page configurations, lobbies, workflows, quick reports and operational reports. Integrations and modifications use template [IDK-11](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/11-functional-specification-integration-modification).
- Fill sections 1 to 3 for every object. In section 4, keep only the block that matches the object type and delete the others.
- Build starts only after the customer project manager has approved in section 9. Changes after approval go through change control.
- Keep it short. A good configuration specification fits on a few pages and can be read by the process owner.
- Replace every `[...]` field. Delete the rows marked `Example:` before approval.

 | Field | Value |
| --- | --- |
| Template ID | IDK-12 |
| Phase | Establish Solution |
| Owner | Application consultant or customer technical analyst |
| Approver | Customer project manager |
| Qualification gate | Solution Established |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Business need and standard alternative](#1-business-need-and-standard-alternative)
- [2. Object and context](#2-object-and-context)
- [3. Logic in plain language](#3-logic-in-plain-language)
- [4. Object detail](#4-object-detail)
- [5. Permission sets affected](#5-permission-sets-affected)
- [6. Test cases](#6-test-cases)
- [7. Update-safety note](#7-update-safety-note)
- [8. Deployment](#8-deployment)
- [9. Approval](#9-approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| CRIM log ID | [ID] |
| Object type | [Custom field / Custom event / Page configuration / Lobby / Workflow / Quick report / Operational report / Other] |
| Solution area and process | [Area, process, link to process model] |
| Author | [Name, role] |
| Builder | [Name, role] |
| Status | [Draft / In review / Approved / Built / Tested / Accepted] |
| Storage location | [Link] |

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [Name] | First draft |   |
| [x.y] | [YYYY-MM-DD] | [Name] | [Change] | [Name] |

 ## 1. Business need and standard alternative

 | Item | Description |
| --- | --- |
| Business need | Example: Goods receivers must see at arrival whether a purchase order line needs a supplier certificate, so that goods without one go to the quarantine location |
| Requested by | [Name, business role] |
| Book of Rules reference | [Document, decision ID] |
| Standard alternative considered | Example: Note text on the purchase order line was shown. It is free text, cannot be searched or made mandatory, and is often left empty. |
| Why a configuration is justified | [Text] |
| Consequence if not delivered | [Text] |

 ## 2. Object and context

 | Item | Description |
| --- | --- |
| Object name | [Name following the project naming convention] |
| Naming convention reference | [Link. Agree a prefix so customer objects are easy to find at update time.] |
| Page, entity or report the object belongs to | Example: Purchase order line entity, shown on the purchase order page and on the arrival registration page |
| Configuration context (page configurations) | [Global, or the named context and the rule that maps users or sites to it] |
| Sites and companies in scope | [List] |
| Business roles that use it | [Roles] |
| Related CRIM objects | [IDs] |

 ## 3. Logic in plain language

 Describe what the object does so that the process owner can confirm it. One short paragraph or a numbered list.

 Example:

 
1. A buyer ticks "Certificate required" on the purchase order line when the part belongs to a regulated part group.
2. The goods receiver sees the field, read-only, when registering the arrival.
3. When the field is ticked and no certificate is attached, a notification goes to the quality role.

 [Your text]

 ## 4. Object detail

 Keep the block that applies. Delete the rest.

 
### 4.1 Custom field

 | Item | Value |
| --- | --- |
| Entity | [Entity name as shown in entity configuration] |
| Field name and label | Example: `CERT_REQUIRED`, label "Certificate required" |
| Data type and length | Example: Boolean |
| Persistent or read-only (calculated) | [Persistent / Read-only, with the expression for read-only fields] |
| Default value | [Value] |
| Mandatory | [Yes / No, and from which status] |
| Value list or reference | [Enumeration values or referenced entity] |
| Pages where the field is placed | [Page, group, position] |
| Needed in reports, lobbies, integrations or migration | [List, with CRIM IDs] |
| Translations needed | [Languages] |

 
### 4.2 Custom event and event action

 | Item | Value |
| --- | --- |
| Entity and table the event listens to | [Name] |
| Fires when | [New record / Modified record / Removed record, and on which attributes] |
| Condition | Example: Certificate required is true, and the line status changes to arrived |
| Action type | [E-mail / Streams message / Execute online SQL / REST call / Other] |
| Recipients or target | [Role-based address or distribution, not a named person] |
| Message content | [Subject and body, with the substitution fields used] |
| Expected frequency | `[agree in project]` |
| What happens if the action fails | [Text. An event action that raises an error can block the user's transaction. State the intended behaviour.] |

 
### 4.3 Page configuration

 | Item | Value |
| --- | --- |
| Page | [Page name and navigator entry] |
| Change | Example: Add custom field to the line group, hide two unused fields, make the confirmed date column visible by default |
| Configuration context | [Context] |
| Conditional formatting or mandatory rules | [Rule] |
| Before and after screenshots | [Link] |
| Interaction with user personalisation | [Note whether users' own saved layouts are affected] |

 
### 4.4 Lobby

 | Item | Value |
| --- | --- |
| Lobby page name | Example: Buyer start page |
| Audience | [Business roles] |
| Page parameters | [For example site, buyer, date range] |

 | Element | Type | Data source | Filter and grouping | Drill-down target | Refresh expectation |
| --- | --- | --- | --- | --- | --- |
| Example: Unconfirmed lines | Counter with list | Purchase order lines | Released lines without confirmation, by buyer, older than `[agree in project]` days | Purchase order lines page with the same filter | On page load |
| [Element] | [Type] | [Data source] | [Filter] | [Target] | [Expectation] |

 Performance note: [Expected row counts per data source, and any data source that needs an index or a narrower filter].

 
### 4.5 Workflow (Business Process Automation)

 | Item | Value |
| --- | --- |
| Workflow name | [Name] |
| Purpose | [Validation / Enrichment of data / User interaction / Background process] |
| Trigger | [Projection and action or entity operation that starts it, and timing relative to the standard logic] |
| Steps | [Numbered list or BPMN diagram link] |
| Data read and written | [Projections, entities, fields] |
| Messages shown to the user | [Text and language] |
| Behaviour on failure | [Whether the user's transaction is stopped, and the message shown] |
| Volume expectation | `[agree in project]` |

 
### 4.6 Quick report

 | Item | Value |
| --- | --- |
| Report name and category | [Name, category] |
| Type | [SQL statement / Query designed in the client] |
| Parameters | [Name, type, default, mandatory] |
| Columns | [Column, source, format] |
| Selection logic in plain language | Example: All open purchase order lines where the promised date is earlier than today, for the sites the user is allowed to see |
| Data sources | [Views or projections. State how site and company access is respected.] |
| Expected row count and run time | `[agree in project]` |
| Output use | [On screen / Export / Scheduled] |

 
### 4.7 Operational report

 | Item | Value |
| --- | --- |
| Standard report used as the base | Example: Purchase order print-out |
| Layout name | [Name] |
| Changes to layout | [Logo, address block, columns added or removed, terms text] |
| Additional fields needed | [Field, source. Note whether the report data must be extended, which raises the tailoring level.] |
| Languages | [List] |
| Paper format and output channel | [Format, print, e-mail, archive] |
| Legal or customer-mandated content | [Text and the person who confirmed it] |
| Layout mock-up | [Link] |

 ## 5. Permission sets affected

 | Permission set | Change | Reason | Security owner informed |
| --- | --- | --- | --- |
| Example: [Buyer role permission set] | Grant access to the lobby page and its data sources | Buyers open it as start page | [Name, date] |
| Example: [Goods receiver permission set] | Read access to the custom field, no edit | Field is maintained by buyers only | [Name, date] |
| [Permission set] | [Change] | [Reason] | [Name, date] |

 Test with an end-user login that holds only the listed permission sets. An object that works for an administrator proves nothing.

 ## 6. Test cases

 | Test ID | Class | Login role | Preconditions and data | Steps | Expected result | Result, tester, date |
| --- | --- | --- | --- | --- | --- | --- |
| Example: T1 | Common | Goods receiver | Purchase order line with "Certificate required" ticked | Open arrival registration for the line | Field is visible and read-only | [Pass / Fail], [Name], [YYYY-MM-DD] |
| Example: T2 | Normal exception | Buyer at another site | Same line | Open the purchase order | Order is not accessible, in line with site access |   |
| [ID] | [Common / Normal exception / Specific exception] | [Role] | [Data] | [Steps] | [Expected] |   |

 Included in SAT script: [ID].

 ## 7. Update-safety note

 | Item | Description |
| --- | --- |
| Tailoring level | Configuration, unless section 4.7 requires extended report data |
| Standard objects this configuration depends on | [Pages, entities, fields, views, report] |
| What must be re-verified at each release update | Example: Field still placed correctly on both pages, event still fires, test cases T1 and T2 |
| What may break and how it would be noticed | [Text] |
| Owner of re-verification after go-live | [Customer role] |
| Retirement condition | [When standard covers the need, this object is removed] |

 ## 8. Deployment

 | Item | Description |
| --- | --- |
| Built in environment | [Environment] |
| Moved by | [Configuration package, named and versioned / manual steps listed here] |
| Target environments and order | [Test, SAT, production or reference environment] |
| Post-deployment steps | [Publish, approve, synchronise, grant, refresh] |
| Cutover plan entry needed | [Yes / No] |
| Step-by-step guides to update | [Guide IDs] |

 ## 9. Approval

 Build may start once the customer project manager has approved. The process owner confirms that section 3 matches the agreed way of working.

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer process owner (logic confirmed) | [Name] | [Approved / Approved with comments / Rejected] | [YYYY-MM-DD] |   |
| Customer project manager | [Name] |   |   |   |
| Technical solution manager (reviewed) | [Name] |   |   |   |

 Acceptance after test:

 | Role | Name | Test evidence reference | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer process owner | [Name] | [Link] | [YYYY-MM-DD] |   |

 Comments and conditions: [text]

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.