Ai/TrafagSalesExporter/docs/PRODUCT_SPARTEN_MAPPING_2026-05-27.md

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.