# Produktsparten-Mapping Group Sales Report

Stand: 2026-05-27

## Anlass

Fuer die Zuordnung der Artikel aus dem Group Sales Report zu Produktbereichen wurde abgestimmt, die Zuordnung von TR AG als fuehrende Referenz zu verwenden.

Ziel ist, Artikel bzw. Materialnummern aus dem Group Sales Report in einem ersten Schritt folgenden Elementen zuzuordnen:

- Produkthierarchie
- Produktfamilie
- Produktsparte

## Vorgeschlagene Fachlogik

1. Materialnummer aus dem Group Sales Report lesen.
2. Materialnummer gegen Artikelstammdaten der TR AG aufloesen.
3. Produkthierarchie direkt aus den Artikelstammdaten uebernehmen.
4. Produktfamilie und Produktsparte anschliessend ueber eine separate Mapping-Tabelle ableiten.
5. Artikel ohne Treffer in den TR-AG-Stammdaten automatisch unter `Sonstige/ohne Zuordnung` fuehren.

## Mapping-Tabelle

Nach aktuellem Verstaendnis definiert die separate Mapping-Tabelle die Zuordnung von Produktgruppen bzw. Produkthierarchie-Bereichen zu Produktfamilien und Produktsparten.

Moegliche technische Regeln, die fachlich zu bestaetigen sind:

- exakte Codes
- Prefix-Regeln
- Von/Bis-Ranges
- Prioritaet bei ueberlappenden Bereichen
- Gueltigkeit nach Datum oder Version

Kendra kann laut Aufgabenbeschreibung weitere Details zur bestehenden Logik und zur konkreten Umsetzung geben.

## Aktueller technischer Stand Im Projekt

Im aktuellen Datenmodell existieren bereits:

- `Material`
- `ProductGroup`

Noch nicht explizit vorhanden sind:

- `Produkthierarchie`
- `Produktfamilie`
- `Produktsparte`

Relevante aktuelle Modelle:

- `Models/SalesRecord.cs`
- `Models/CentralSalesRecord.cs`

Hinweis aus der Code-Sichtung:

- SAP-Seed-Mapping nutzt aktuell `Z.Matnr` fuer `Material`.
- SAP-Seed-Mapping nutzt aktuell `Z.Prodh` fuer `ProductGroup`.
- Ob `Z.Prodh` fachlich bereits der gewuenschten Produkthierarchie entspricht, muss bestaetigt werden.

## Empfohlene Umsetzung

Die Produktspartenlogik sollte als eigene sichtbare Mapping-Schicht umgesetzt werden, nicht als versteckte Sonderlogik in Finance oder Management Cockpit.

Sinnvolle technische Bausteine:

- TR-AG-Artikelstamm-Quelle fuer Materialnummer -> Produkthierarchie.
- Mapping-Tabelle fuer Produkthierarchie/ProductGroup/Range -> Produktfamilie und Produktsparte.
- Fallback-Kategorie `Sonstige/ohne Zuordnung`.
- Export-/Excel-Spalten fuer die drei neuen Klassifikationen.
- Pruefansicht fuer nicht zugeordnete Materialnummern.

## Nachtrag 2026-05-28 SAP-/ABAP-Zielbild

Nach weiterer Analyse mit Andreas-/SAP-Kontext ist das fuehrende Zielbild:

- SAP TR AG bleibt Quelle der Wahrheit fuer die Artikelzuordnung.
- Die Dashboard-App baut die KEDR-/KE30-Ableitungslogik nicht direkt in C# nach.
- Stattdessen wird eine flache Referenztabelle aus SAP bereitgestellt:
  - `MATNR`
  - `MAKTX`
  - `PAPH1`
  - `PAPH1_TEXT`
  - `WWPFA`
  - `WWPFA_TEXT`
  - `WWPSP`
  - `WWPSP_TEXT`
  - `IS_ASSIGNED`
- Das Dashboard mappt spaeter Umsatzzeilen ueber `Material`/`MATNR` gegen diese Referenz.
- Falls die Materialnummer nicht in der Referenz enthalten ist oder keine eindeutige Ableitung existiert, wird die Zeile unter `Nicht zugeordnet` gefuehrt.

SAP-Felder / Annahmen:

- Materialnummer: `MATNR`
- Produkthierarchie aus Vertriebssicht: `MVKE-PRODH`
- CO-PA Merkmal fuer erste Produkthierarchieebene: `PAPH1`
- Produktfamilie: `WWPFA`
- Produktsparte: `WWPSP`
- Reale Ableitung kommt aus CO-PA/KEDR und ist in `CE11000` sichtbar.

ABAP-Artefakte wurden als Arbeitsstand im Repo abgelegt:

| Datei | Zweck |
| --- | --- |
| `docs/abap/ZCL_PRODSPARTE_PROVIDER.abap` | Globale Provider-Klasse fuer ALV und spaeter OData |
| `docs/abap/Z_PRODSPARTE_REPORT.abap` | ALV-Testreport, ruft Provider-Klasse |
| `docs/abap/Z_PRODSPARTE_MAP_BUILD.abap` | Baut `ZPRODSPARTE_MAP` aus eindeutigen CO-PA-Kombinationen |
| `docs/abap/README_PRODSPARTE.md` | Hinweise zu DDIC-Objekten und Pruefpunkten |

Vorgeschlagene SAP-Architektur:

1. `Z_PRODSPARTE_MAP_BUILD` liest eindeutige Kombinationen `PAPH1 -> WWPFA -> WWPSP` aus `CE11000`.
2. Mehrdeutige `PAPH1` werden protokolliert und nicht in die Mapping-Tabelle geschrieben.
3. Eindeutige Zuordnungen werden in `ZPRODSPARTE_MAP` geschrieben.
4. `ZCL_PRODSPARTE_PROVIDER` liest verkaufsrelevante Materialien aus `MVKE`, Texte aus `MAKT`/`T179T`/`T25A0`/`T25A1` und verbindet sie mit `ZPRODSPARTE_MAP`.
5. `Z_PRODSPARTE_REPORT` dient als ALV-Test.
6. Ein spaeterer SAP-Gateway/OData-Service ruft dieselbe Provider-Klasse auf.

Bewusst korrigierte Punkte im ABAP-Arbeitsstand:

- Provider-Logik ist global auslagerbar, nicht nur lokale Reportklasse.
- `MAKT` wird per `LEFT OUTER JOIN` gelesen, damit Materialien ohne Text nicht verschwinden.
- `VTWEG` ist optionaler Selektionsparameter.
- Bei mehreren Vertriebswegen gewinnt aktuell bewusst der kleinste `VTWEG`; dies ist noch fachlich zu bestaetigen.
- Fallback setzt technischen Code `UNASS`, Text `Nicht zugeordnet` und `IS_ASSIGNED = abap_false`.
- Mapping-Build schreibt die Tabelle nicht leer, falls keine eindeutigen Saetze aufgebaut wurden.

Noch zu pruefen:

- Ist `PAPH1 = MVKE-PRODH(5)` im Trafag-System exakt korrekt?
- Sind `T25A0` und `T25A1` die richtigen Text-/Customizingtabellen fuer Produktfamilie und Produktsparte?
- Ist `CE11000` der richtige CO-PA-Einzelposten fuer den relevanten Ergebnisbereich?
- Ist der Fallback-Code `UNASS` in Feld `WWPSP` zulaessig/lang genug?
- Soll `VTWEG` zwingend vorgegeben werden, statt den kleinsten Vertriebsweg zu verwenden?
- Welche VKORG ist fuer TR AG im produktiven Lauf massgebend?

## Offene Fragen Fuer Andreas / Kendra

| Frage | Warum wichtig |
| --- | --- |
| Woher kommt der fuehrende TR-AG-Artikelstamm technisch? | Datenquelle und Aktualisierung festlegen |
| Welches Feld ist die eindeutige Materialnummer? | Normalisierung, fuehrende Nullen, Varianten |
| Ist `Z.Prodh` die gewuenschte Produkthierarchie? | Bestehendes Mapping evtl. wiederverwendbar |
| Wie sieht die bestehende Mapping-Tabelle aus? | Datenmodell und Importlogik festlegen |
| Werden Ranges, Prefixe oder exakte Werte verwendet? | Matching-Regeln eindeutig implementieren |
| Was gilt bei ueberlappenden Ranges? | Prioritaet / deterministisches Ergebnis |
| Soll die Zuordnung historisiert werden? | Reproduzierbarkeit alter Reports |
| Soll `Sonstige/ohne Zuordnung` nur im Report erscheinen oder auch in Daten persistiert werden? | Datenmodell und Auditierbarkeit |

## Abgrenzung

Dieser Task ist keine Finance-Soll/Ist-Regel. Die Klassifikation kann spaeter Finance- und Management-Auswertungen ergaenzen, sollte aber fachlich getrennt von Net-Sales-Abgrenzungen bleiben.