admin/Ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
41d663254eca25a5d37b7c88c22d8613b3585c16
Ai/TrafagSalesExporter/docs/PRODUCT_SPARTEN_MAPPING_2026-05-27.md
T

14 KiB
Raw Blame History

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.

Nachtrag 2026-05-29 Zentrale Spartenzuordnung

Fachliches Ziel aus Finance-Input:

  • Die Produktsparten-/Produktfamilienzuordnung der anderen Laender-ERPs ist nicht fuehrend.
  • Fuehrend ist die Trafag-AG-/SAP-Referenz aus dem eigenen SAP-System.
  • Jede Umsatzzeile aus CentralSalesRecords wird ueber ihre Materialnummer gegen die TR-AG-Referenz geprueft.
  • Wenn die Materialnummer im TR-AG-Stamm vorhanden ist, wird die dortige Produktzuordnung angezeigt.
  • Wenn die Materialnummer nicht im TR-AG-Stamm vorhanden ist, gilt der Status Nicht im TR-AG-Stamm.
  • Wenn die Materialnummer im TR-AG-Stamm vorhanden ist, aber dort UNASS/nicht zugeordnet ist, gilt der Status Nicht zugeordnet.

Umsetzung im Web:

  • Neuer Reiter in Management Analyse:
    • Zentrale Spartenzuordnung
  • Der Reiter arbeitet auf dem bestehenden Finance-Filter:
    • Jahr
    • Land
    • Waehrung
  • Die Referenz wird aus zentral gespeicherten Zeilen mit Produktfeldern gebildet.
  • Der Abgleich erfolgt ueber normalisierte Materialnummer:
    • Land-ERP-Material links
    • TR-AG-Referenz-Material plus Produktzuordnung rechts
  • Angezeigte Statuswerte:
    • Zugeordnet
    • Nicht zugeordnet
    • Nicht im TR-AG-Stamm
    • Material fehlt

UI-Inhalte:

  • Kennzahlen:
    • Materialien
    • Zugeordnet
    • Nicht zugeordnet
    • Nicht im Stamm
    • Material fehlt
    • TR-AG Referenz
  • Laenderuebersicht:
    • Land
    • TSC
    • Materialanzahl
    • Zugeordnet
    • Nicht zugeordnet
    • Nicht im Stamm
    • Material fehlt
    • Trefferquote
  • Detailtabelle:
    • Status
    • Land
    • TSC
    • Land-Material
    • Land-Text
    • TR-AG-MATNR
    • PAPH1
    • Produktfamilie
    • Produktsparte
    • Zeilen
    • Finance-Wert

Technische Dateien:

  • Models/ManagementCockpitModels.cs
    • neue Modelle fuer Produktzuordnungs-Summary, Laenderzeilen und Detailzeilen.
  • Services/ManagementCockpitService.cs
    • baut die TR-AG-Referenz aus Produktfeldern.
    • prueft gefilterte Finance-Zeilen ueber Material.
    • erzeugt Summary, Laenderabdeckung und Detailzeilen.
  • Components/Pages/ManagementCockpit.razor
    • neuer Reiter Zentrale Spartenzuordnung.
  • TrafagSalesExporter.Tests/ManagementCockpitServiceTests.cs
    • Test fuer Treffer, fehlende Referenz und UNASS.

Validierung:

  • dotnet test TrafagSalesExporter.sln --verbosity minimal --artifacts-path C:\TMP\trafag-test-artifacts-central-product-assignment
  • Ergebnis: 80/80 Tests gruen.

Wichtig:

  • Die Sicht ist zunaechst eine Pruef-/Analyseansicht.
  • Sie veraendert noch keine bestehenden Umsatzzeilen der anderen Laender.
  • Persistente Anreicherung aller CentralSalesRecords kann spaeter folgen, wenn die Treffer-/Fehlerquote fachlich akzeptiert ist.
Reference in New Issue View Git Blame Copy Permalink