# 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. ## Nachtrag 2026-05-29 Umsetzung SAP Gateway Und Web SAP/DDIC: - Struktur `ZSTR_PRODSPARTE_OUT` wurde fuer den Gateway-Entity-Type verwendet. - `PAPH1`, `WWPFA` und `WWPSP` duerfen in SE11 nicht vorausgesetzt als globale Datenelemente typisiert werden. - Pragmatische Typisierung ist moeglich: - `PAPH1`: `CHAR 5` - `WWPFA`: Laenge wie `CE11000-WWPFA` - `WWPSP`: Laenge wie `CE11000-WWPSP` - Textfelder: z.B. `CHAR 50` - Aktivierungsfehler bei `ZSTR_PRODSPARTE_OUT` waren durch nicht vorhandene/aktive Datenelemente fuer `PAPH1`, `WWPFA`, `WWPSP` verursacht. SAP/ABAP: - `ZCL_PRODSPARTE_PROVIDER` wurde als globale Klasse in SE24/quelltextbasiert angelegt. - `Z_PRODSPARTE_REPORT` und `Z_PRODSPARTE_MAP_BUILD` wurden als Reports angelegt. - `Z_PRODSPARTE_MAP_BUILD` hat `ZPRODSPARTE_MAP` befuellt. - Beispielhafte Mapping-Luecken aus dem ALV-Test: - `0509 Multistat` nicht zugeordnet - `0540 Multistat` nicht zugeordnet - `0519 Multistat` zugeordnet zu `0007` / `0001` - Diese Luecken werden spaeter fachlich geprueft; technisch funktioniert der Provider. SAP Gateway: - Bestehender Service wird weiterverwendet: - `ZPOWERBI_EINKAUF_SRV` - Service Root: `http://travt762.sap.trafag.com:8000/sap/opu/odata/sap/ZPOWERBI_EINKAUF_SRV/` - Es wurde ein zusaetzlicher Entity Type aus `ZSTR_PRODSPARTE_OUT` erstellt: - Entity Type: `ProductDivisionRef` - Entity Set: `ProductDivisionRefSet` - Der bestehende Sales-EntitySet bleibt separat: - `FinanzdataSchweizOeSet` bzw. generierte Methode `FINANZDATASCHWEI_GET_ENTITYSET` - Diese Methode muss weiter aus `ZSCHWEIZ` lesen und darf nicht durch Produktsparten-Code ersetzt werden. - Produktsparten-Code gehoert in die separat generierte/redefinierte Methode: - `PRODUCTDIVISIONR_GET_ENTITYSET` - Test-URL: - `http://travt762.sap.trafag.com:8000/sap/opu/odata/sap/ZPOWERBI_EINKAUF_SRV/ProductDivisionRefSet` - OData-Feldnamen aus dem Gateway sind CamelCase: - `Matnr` - `Maktx` - `Paph1` - `Paph1Text` - `Wwpfa` - `WwpfaText` - `Wwpsp` - `WwpspText` - `IsAssigned` - Erfolgreicher Testdatensatz aus Gateway: - `Matnr = VCP1000` - `Maktx = VC TRANSMITTER` - `Paph1 = 9999` - `Paph1Text = Zubehoer` - `Wwpsp = UNASS` - `WwpspText = Nicht zugeordnet` - `IsAssigned = false` Wichtige Gateway-Korrektur: - Fehler `/IWFND/MED/170` trat auf, weil Service und EntitySet ohne Slash zusammengesetzt wurden. - Falsch: - `.../ZPOWERBI_EINKAUF_SRVProductDivisionRSet` - Richtig: - `.../ZPOWERBI_EINKAUF_SRV/ProductDivisionRefSet` Webprogramm / Datenmodell: - `SalesRecord` und `CentralSalesRecord` wurden um folgende Felder erweitert: - `ProductHierarchyCode` - `ProductHierarchyText` - `ProductFamilyCode` - `ProductFamilyText` - `ProductDivisionCode` - `ProductDivisionText` - `ProductMappingAssigned` - SQLite-Schema wurde erweitert: - Neue Installationen erhalten die Felder in `CentralSalesRecords`. - Bestehende Datenbanken erhalten die Felder per `DatabaseSchemaMaintenanceService`. - `CentralSalesRecordService` schreibt und liest die neuen Felder. - `ConfigTransferService` erhaelt die Produktfelder beim Preserve bestehender `CentralSalesRecords`. - Excel-Export fuehrt die neuen Produktfelder im Blatt `Sales` direkt nach `Product Group`. - Finance-Spalten im Export verschieben sich dadurch nach hinten; Tests wurden angepasst. - Manual-Excel-Import und Auto-Match kennen die neuen Feldnamen ebenfalls. Aktive lokale Web-Konfiguration: - Standort: - `Schweiz/Oesterreich` - `TSC = ZSCHWEIZ` - `SourceSystem = SAP` - SAP Service URL: - `http://travt762.sap.trafag.com:8000/sap/opu/odata/sap/ZPOWERBI_EINKAUF_SRV/` - SAP-Quellen: - Alias `Z`: bestehender Sales-EntitySet - Alias `P`: `ProductDivisionRefSet` - Join: - `Z.Matnr = P.Matnr` - Feldmappings: - `ProductHierarchyCode <- P.Paph1` - `ProductHierarchyText <- P.Paph1Text` - `ProductFamilyCode <- P.Wwpfa` - `ProductFamilyText <- P.WwpfaText` - `ProductDivisionCode <- P.Wwpsp` - `ProductDivisionText <- P.WwpspText` - `ProductMappingAssigned <- P.IsAssigned` Lokaler Neustart / Validierung: - Lokaler Webprozess wurde neu gestartet. - App antwortet lokal mit HTTP 200 auf `http://localhost:55416/`. - Neue Spalten sind in `CentralSalesRecords` vorhanden. - Validierung: - `dotnet test TrafagSalesExporter.sln --verbosity minimal --artifacts-path C:\TMP\trafag-test-artifacts-productmapping` - Ergebnis: `79/79` Tests gruen. Naechster fachlicher/technischer Schritt: - Standort `ZSCHWEIZ` im Export Dashboard einmal neu laufen lassen. - Danach pruefen: - Sind Produktfelder in `CentralSalesRecords` gefuellt? - Stimmen Join-Treffer fuer bekannte Materialien? - Wie viele Zeilen bleiben `UNASS` / `Nicht zugeordnet`? - SAP-seitig muss `FINANZDATASCHWEI_GET_ENTITYSET` auf den alten `ZSCHWEIZ`-Select-Code zurueckgesetzt sein, falls er versehentlich mit Produktsparten-Code ueberschrieben wurde.