Finishing Quality Performance Report.
A custom SAP quality performance analysis report built for the textile finishing process. The report consolidates production orders, quality control lots, material master data, quality notifications, defect records and approved quality logs into a single analytical screen — calculating first-quality, second-quality, rejection, defect-source breakdown and percentage-based metrics so quality and production teams can act on measurable data instead of scattered records.
Turning quality records into a performance screen.
The finishing process — terbiye — is where raw textile fabric is dyed, printed, washed and treated into its final form. Quality decisions made at this stage determine whether the output ships as first-quality, gets downgraded to second-quality, goes to retail surplus, or is rejected entirely. The stakes are high, and the data that captures these decisions was spread across multiple SAP objects.
This report exists to answer a set of critical questions in one place: how much first-quality came out of this material? How much was lost to second-quality, rejection or surplus? Which production orders are driving the loss? And where did the defects come from — finishing, weaving, sewing or holes?
It is not a simple list dump. The report joins six data layers through an object-oriented singleton class, filters for only approved quality decisions, deduplicates historical log entries to prevent inflated metrics, classifies defects by their process source, and calculates ratio-based quality performance indicators — all on a single ALV Grid screen with two reporting modes.
Why it was built.
Quality data lived in six different places.
Production orders held one piece of the picture, quality control lots another, material master records a third, quality notifications and defect logs a fourth and fifth, and the custom quality log tables a sixth. Getting a unified quality performance view for the finishing process meant navigating between SAP objects and manually cross-checking — slow, error-prone, and impossible to spot patterns at speed. No single screen could answer "what happened to this material's quality?"
One quality performance screen, two analysis modes.
A custom report that joins all six data sources through an OOP singleton architecture, filters for approved-only quality decisions, deduplicates historical logs, classifies defects by their process origin (finishing, weaving, sewing, holes), and calculates percentage-based quality metrics. Accessible in both material-level summary and production-order detail views — so the same report serves management overview and operational root-cause analysis.
What the report delivers.
Six data sources, one singleton class, two reporting modes — and a set of calculated quality metrics the business couldn't see before.
Six-source data consolidation
Production orders, quality control lots, material master, quality notifications, defect records and custom quality log tables — joined in one query flow.
Approved-only filtering
Only formally confirmed quality decisions enter the calculation. Draft, incomplete or unapproved quality movements are excluded — the report shows the real, finalized quality picture.
Log normalization
When the same quality movement has multiple historical versions, the report keeps only the latest confirmed entry — preventing duplicate records from inflating the metrics.
Defect source classification
Quality defects are categorized by process origin — finishing, weaving, sewing or holes — so the team knows which department to act on, not just that a defect exists.
Dual reporting modes
Material-level summary for a management overview of quality across products. Production-order-level detail for operational root-cause analysis. Same engine, two perspectives.
Memory export for downstream reporting
The calculated dataset can be exported to memory — turning this report into a data source for other reporting layers and analytical processes, not just a standalone screen.
How the data flows.
A singleton main class orchestrates the entire flow: data retrieval from six source layers, log normalization, quality metric calculation, defect classification — and finally, presentation through an ALV Grid with a dynamically generated field catalog.
The logic that makes it trustworthy.
A quality report is only useful if the numbers can be trusted. These rules ensure the metrics reflect reality — not raw data artifacts.
Approved-only quality log filtering
The report only considers quality log entries that have been formally approved through the business process. Draft records, partially completed entries and unapproved quality movements are excluded. This means the report always reflects the finalized quality picture — not an in-progress snapshot.
Historical version deduplication
The same quality movement can generate multiple log entries over time — corrections, re-approvals, process updates. The report groups these by their document number or tracking reference, keeps only the latest confirmed version per record type, and discards all older entries. Without this, every historical correction would double-count in the totals.
Expanded second-quality definition
Second-quality isn't just the classic "II. Kalite" decision. The report also counts retail surplus and rejection decisions on the loss side. This gives a complete quality loss picture — not just the narrow second-quality category, but everything that didn't ship as first-quality.
Four-way defect source classification
Defects from quality notification records are mapped to their process origin through defect class codes: finishing-sourced, weaving-sourced, sewing-sourced and hole defects. This classification is critical in textile manufacturing — knowing the source determines which department takes corrective action.
Dual aggregation modes
When material-level mode is selected, the report summarizes quality across all production orders for each material — an executive view. When production-order mode is selected, the same calculations break down to individual order level — an operational view. Two perspectives from one engine.
Ratio-based quality metrics
Beyond raw quantities, the report calculates second-quality percentage, single-defect percentage, defect-source distribution (finishing / weaving / sewing / holes as percentages), and defect-per-meter density ratios. This lets the team analyze performance by rate, not just by volume — making comparisons across different production scales meaningful.
What I built.
From the OOP class architecture through the business rule engine to the ALV output — the full quality analytics report, end to end.
- OOP singleton class architecture — a main class with include-separated data, class and method layers, orchestrating the entire report through a clean object-oriented structure.
- Six-source data integration — joining production orders, quality lots, material master, quality notifications, defect records and custom log tables into one dataset.
- Quality log normalization engine — deduplication logic that resolves multiple versions of the same quality movement to the latest confirmed entry.
- Defect classification mapping — four-way defect source categorization (finishing, weaving, sewing, holes) from quality notification defect codes.
- Quality metric calculations — first/second-quality quantities, rejection, surplus, single-defect counts, percentage distributions and per-meter quality density ratios.
- ALV Grid presentation — dynamic field catalog from a custom structure, docking container, zebra layout, toolbar customization and ALV refresh mechanism.
- Selection screen with F4 search helps — multi-parameter filtering by material, date, design, variant, production order, batch, customer, print/dye code and more.
- Memory export mechanism — enabling other reports and analytical processes to consume the calculated quality dataset without re-running the data pipeline.
The impact.
Quality data that was scattered across production orders, quality lots, notifications, defect records and custom log tables became visible from one screen. The finishing team could see exactly how much first-quality, second-quality, rejection and surplus came out of each material and each production order — with defect sources classified and percentages calculated. Manual cross-checking between SAP objects dropped. Quality problems could be traced to their process origin — finishing, weaving, sewing or holes — so the right department got the action item. And because the report's dataset could be exported to memory, it became a reusable data source for downstream analytical processes.
The core value: I didn't just build an ALV report — I built a quality performance screen where approved, deduplicated, classified and calculated metrics let the production and quality teams make decisions based on reliable data.
See the other flagship deliveries.
This is one of four featured SAP developments. The Osman Akça logistics platform, the IKEA SPI forecast suite and the QM Power BI analytics sit right alongside it.