Terbiye Production Flow Cockpit.
From a 15-minute legacy report to an 8-second production decision screen — a SAP S/4HANA visibility cockpit that tells every textile finishing team member exactly where each document is, which operation just finished, and where it goes next.
| Doc No | Piece | Prod. Order | Last Operation | Work Center | Next Operation | Customer | Plan Del. | Doc Qty (m) | Process Qty | Status |
|---|---|---|---|---|---|---|---|---|---|---|
| TRB-2025-0312-001 | 001/01 | 000060001244 | SCOUR-1 — Scouring & Desizing | TRB-BOYA-01 | DYE-01 — Dyeing Line 1 | 501277 — IKEA | 15.05.2025 | 2.400 m | 2.380 m | — |
| TRB-2025-0312-002 | 001/02 | 000060001245 | DYE-01 — Dyeing Line 1 | TRB-BASK-02 | PRINT-RD — Reactive Print | 501285 — CUSTOMER-A | 17.05.2025 | 1.850 m | 1.820 m | — |
| TRB-2025-0319-001 | 001/01 | 000060001312 | SIZE-1 — Sizing Pass | TRB-KASR-01 | SCOUR-L — Scouring Line | 501291 — FABR-INT | 20.05.2025 | 3.100 m | — | — |
| TRB-2025-0401-001 | 001/01 | 000060001389 | FINISH-1 — Final Finishing 1 | TRB-KLT-01 | QUALITY — Inspection | 501277 — IKEA | 22.05.2025 | 1.950 m | 1.940 m | RWK — Rework |
| TRB-2025-0401-002 | 001/02 | 000060001401 | PRINT-RD — Reactive Print | TRB-APRE-02 | APRE-SN2 — Apre Son Hat 2 | 501301 — CUSTOMER-B | 24.05.2025 | 2.200 m | 2.190 m | — |
The shop floor was waiting 15 minutes for an answer.
Terbiye — the textile finishing process — is where raw greige fabric is transformed through a precise sequence of operations: sizing, scouring, dyeing, printing, finishing, quality check. Each step determines the next. Each document moves through a defined path. Miss one step, and the whole production line loses visibility.
The existing SAP report technically provided this information. But the screen took approximately 15 minutes to open. Not because the data was wrong, but because the data model was never designed for the pace of a production floor.
A report that opens in 15 minutes isn't a real-time tool. It's a historical log. Operators stopped trusting it. Supervisors stopped using it before decisions. The screen that was supposed to be the cockpit had become the last resort.
"Which docs are coming to me today, what operation are they on, and where do they go next?"
These are not complex analytical questions. They are basic operational questions that need answers in seconds, not minutes. A production line running at full tempo cannot pause for a screen to load.
A screen that takes 15 minutes to open on a production floor is technically functional — but operationally, it is not good enough.
Three layers. One decision screen.
The existing report was not rebuilt from scratch — it was reimagined at the data model level. The root cause of the 15-minute load was not the ALV screen itself. It was the way data was being assembled: nested loops, repeated queries, and computation happening in ABAP that belonged in the database.
The solution reorganised this into three coordinated layers: a performant SAP GUI ALV screen for daily shop-floor use, a CDS-based data model that pushes joins and business logic to the S/4HANA in-memory layer, and a Fiori analytical experience for supervisors and planning teams.
Daily operations cockpit — for SAP GUI users on the shop floor.
An ALV-based screen was built for classic SAP GUI users. Shop-floor operators and planning teams can access document, order, operation, customer, quality, date and rework status — all from one screen, instantly.
- Hotspot navigation from production order to CO03
- Order detail descriptions viewable via popup
- User-level layout and ALV variant support
- Production vs. planning material distinction made visible
- Last completed and next operation shown on the same screen
- Rework and repair statuses surfaced meaningfully within the production flow
- Production flow sequencing within the same group
The backbone of performance — moving computation to the database layer.
The primary driver of performance improvement was the shift to a CDS-based data model. Instead of processing data through redundant loops at the application layer, computation was moved into a layered view structure that harnesses S/4HANA's HANA in-memory engine.
- Base View: core join of production, document, operation, material and customer data
- Composite View: business rules, planning/production material split, rework logic
- Composite View 2: segment and customer enrichment, full user-facing dataset completion
- Aggregation View: process quantity totals calculated in a dedicated layer via HANA SUM
- Query View: UI annotations and selection field definitions for Fiori and analytics consumption
Same data model, modern production visibility.
The project was not left as a SAP GUI report alone. The CDS data model was designed for Fiori consumption from the start. Users can track the production flow in a visual, guided interface — without reading through rows of a classic report.
- Filterable list view and analytical query structure
- Drill-down logic and chart-based production visibility
- Breakdown by plant, storage location and operation
- Cross-dimension navigation via breadcrumb structure
CDS view hierarchy — computation at database level.
The architecture was designed to answer one question: where is the work being done? In ABAP loops, or at the database? By restructuring data access into a layered CDS view hierarchy, each layer has a single responsibility — and computation happens where S/4HANA is fastest.
Aggregations that previously ran as nested ABAP loops are now handled by a dedicated aggregation view. Business rules (planning vs. production material, rework logic, delivery date resolution) live in the composite layer — not scattered across procedural code.
Modern production visibility — same data model, different face.
The CDS Query View was designed with Fiori consumption in mind from the start. Every field carries its UI annotation — line item position, selection field order, aggregation behavior, labels. The result is a Fiori List Report that is generated directly from the same data model that powers the ALV screen.
Supervisors and planning teams get a filterable, drillable, graphical interface. Shop-floor operators get the familiar SAP GUI. Both run on the same underlying CDS hierarchy — consistent data, two channels.
| Doc No | Prod. Order | Last Operation | Next Operation | Work Center | Quality | Customer | Plan Del. | Doc Qty (m) | Process Qty |
|---|---|---|---|---|---|---|---|---|---|
| TRB-2025-0312-001 | 000060001244 | KASAR-BAYI | BOYA-01 | TRB-BOYA-01 | A1 | IKEA | 15.05.2025 | 2.400 | 2.380 |
| TRB-2025-0312-002 | 000060001245 | BOYA-01 | BASKI-RD | TRB-BASK-02 | A1 | CUSTOMER-A | 17.05.2025 | 1.850 | 1.820 |
| TRB-2025-0401-001 | 000060001389 | APRE-SN1 | QUALITY | TRB-KLT-01 | B2 | IKEA | 22.05.2025 | 1.950 | 1.940 RWK |
| TRB-2025-0401-002 | 000060001401 | BASKI-RD | APRE-SN2 | TRB-APRE-02 | A1 | CUSTOMER-B | 24.05.2025 | 2.200 | 2.190 OK |
A waiting screen became a decision tool.
"The value here isn't just 'the report got faster.' The real value is that the production line's daily visibility got faster."
Measurable results.
Everything the production line needs — on one screen.
The cockpit was designed with one principle: don't show data for its own sake. Every field on screen answers a question a finishing-line operator or planner actually asks. The goal is not to surface raw data — it is to make the right decision fast.
End-to-end development ownership.
End-to-end development ownership across the full scope — from root-cause analysis of the performance problem, through data model redesign, to building two distinct consumption channels — all owned end to end.
-
Performance root-cause analysis — Diagnosed why the existing report took 15 minutes to open. The bottleneck: nested loops and repeated SELECT statements at the ABAP layer.
-
CDS view architecture design & development — Built the Base, Composite ×2, Aggregation and Query layers from scratch. Each layer has a single responsibility.
-
ABAP ALV cockpit development — Built the OOP-based ALV screen including hotspot navigation, popup, toolbar, layout variant and rework flow handling.
-
Fiori consumption layer preparation — Designed the @UI annotations and selection field structure on the Query View for Fiori List Report consumption.
-
Production & planning material business rules — Solved the COBRB order settlement chain for rework orders, the planning/production material CASE logic and rework flow separation at the data model level.
-
Operation sequence & next-operation calculation — Resolved the next-operation within an order and the cross-group AUFNR → first operation chain using an O(1) hashed table structure.
-
Performance improvement measurement — Benchmarked old vs. new architecture open times to produce the 15 min → 8 sec result as a measurable, reported metric.
-
Selection screen & display design for production use — Filters, column layout and operational conveniences (popup, hotspot, variant) were defined in close collaboration with the production floor team.
Custom tables: zpp_008_t_dokhdr (doc movements), zpp_006_t_log (grup/mtart), zpp_033_t_log (customer order), zpp_020_t_trbtyt (confirmation), zqm_010_t_log (quality decision), zpp_8_rework_log (rework). SAP standard tables joined: aufk, afpo, afko, afvc, afru, mara, makt, kna1, crhd, crtx, cobrb, qpct. CDS views: ZPP_025_I_TERBIYE_BASE → ZPP_025_I_TERBIYE_COMP → ZPP_025_I_TERBIYE_COMP2 / ZPP_025_I_TERBIYE_LMNGA → ZPP_025_C_TERBIYE_QUERY / ZPP_025_I_TRB_CHART_BASE. Order type ZP14 = rework order; COBRB chain used for planning material resolution. Operation list O(1) lookup: HASHED TABLE lt_next_op WITH UNIQUE KEY aufnr vornr.
More case studies.
Textile finishing was one screen. Twelve full-scale SAP deliveries are documented across the projects page — each with architecture, business rules and measured impact.