Rollen & Verantwortlichkeiten

PIE liefert einen festen Satz an Rollen. Berechtigungen entwerfen Sie nicht selbst: Jede Person bekommt die Rolle, die zu ihrer Aufgabe passt, und die Plattform erzwingt sie bei jeder Anfrage auf dem Server. Diese Seite erklärt, wer im Gesamtprozess was tut. Die vollständige Matrix je Ressource steht in der generierten Referenz Rollen & Berechtigungen.

So funktionieren Rollen

• Jeder Benutzer hat eine Rolle in einer Organisation. Die Rolle bestimmt, was die Person sehen und ändern darf; die Organisation bestimmt, wessen Daten es sind. Ein Benutzer kann nie auf Daten einer anderen Organisation zugreifen, egal mit welcher Rolle.
• Die App folgt der Rolle. Menüeinträge erscheinen, wenn die Rolle die Seite nutzen darf, und eine Schaltfläche erscheint nur, wenn die Rolle die Aktion ausführen darf. Wer nur lesen darf, sieht die Seite weiterhin — ihm werden lediglich keine Schaltflächen angeboten, die abgelehnt würden. Das ist eine Erleichterung: Der Server prüft jede Anfrage erneut.
• Abnehmer sehen nur, was ihnen freigegeben ist. Eine Abnehmerrolle liest Produkte der Produzenten, die den Zugriff freigegeben haben, sonst nichts (siehe Mandantentrennung & Freigaben).
• Rollen gehören zur Seite der Organisation. Eine Produzenten-Organisation nutzt die pip_*-Rollen, eine Abnehmer-Organisation die pic_*-Rollen. Eine Organisation, die beides ist (Typ both), hat Produzenten-Benutzer für den eigenen Katalog und Abnehmer-Benutzer für das, was sie erhält.

Produzentenrollen

pip_admin — Organisations-Administration

Die einzige Produzentenrolle, die Aufbau und Zielgruppe bestimmt:

• Personen und Zugriff — lädt Benutzer ein und entfernt sie, vergibt Rollen, verwaltet Freigaben (welcher Abnehmer welche Produkte sieht), API-Schlüssel, Webhooks, SSO und die Anmelderichtlinie der Organisation.
• Struktur — legt Kategorien samt Schemata, Referenzentitätstypen, Qualitätsprofile, Workflow-Definitionen und Genehmigungsregeln an und bearbeitet sie.
• Ausgehende Wege — legt Kanäle und deren Auslieferungs-Konnektoren, Markenportale, GS1-Zuordnungen und die GDSN-Datenpool-Verbindung an.
• Datenschutz und Geld — Datenschutzwerkzeuge (Betroffenenanfragen, Aufbewahrung, Verarbeitungsverzeichnis), Audit-Protokoll, Tarif und Abrechnung, KI-Einstellungen.
• Alles, was ein Editor darf, und zusätzlich Produkte archivieren und löschen.

pip_editor — Produktdaten-Bearbeitung

Erledigt die tägliche Produktarbeit, aber nichts, was ändert, wer etwas sieht oder wie die Organisation aufgebaut ist:

• Legt Produkte an, bearbeitet und veröffentlicht sie, pflegt Assets, Zutaten und Beziehungen, lokalisiert Inhalte und prüft KI-Anreicherungsvorschläge.
• Erstellt Kataloge (Vorlagen und Ausgaben) und Digitale Produktpässe, veröffentlicht Produkte in Kanäle, die eine Administration eingerichtet hat, und nach GDSN über die von der Administration konfigurierte Verbindung.
• Bearbeitet ihr zugewiesene Workflow-Aufgaben.
• Liest, ändert aber nicht: Kategorien und Schemata, Qualitätsprofile, Markenportale, Kanäle und Konnektoren, GS1-Zuordnungen, die GDSN-Verbindung, Freigaben, Benutzer und Organisationseinstellungen. Diese Seiten bleiben im Menü, damit der Editor sieht, wie alles eingerichtet ist; die Schaltflächen zum Ändern werden nicht angeboten.
• Darf Produkte nicht archivieren oder löschen.

pip_viewer — nur Lesezugriff

Für Personen, die sehen, aber nichts anfassen sollen — Qualitätsmanagement, Auditor, Vertrieb in der Gesprächsvorbereitung. Ein Viewer liest Produkte, Assets, Kataloge, Produktpässe, Kanäle, Portale und die Einrichtungsseiten und kann Analysen und Produktpässe exportieren. Jede Schaltfläche zum Anlegen, Ändern, Veröffentlichen oder Löschen fehlt.

Ein Beispiel für Produzenten

Die Alpenhof Käserei stellt Käse her und beliefert Supermarktketten.

1. Sibylle, die Inhaberin, ist pip_admin. Sie registriert die Organisation, lädt ihre Kolleginnen und Kollegen ein, baut die Kategorie „Käse" mit den Pflichtattributen, legt ein Qualitätsprofil fest („Name, GTIN, Allergene und Nährwerte müssen vollständig sein"), richtet einen Kanal für den Flat-File-Feed der Kette ein und ein Markenportal für die Website.
2. Jonas und Mira sind pip_editor. Sie legen die Produkte an, laden Fotos hoch, tragen Allergene und Nährwerte ein und nutzen die KI-Anreicherung für die deutschen und französischen Beschreibungen. Besteht ein Produkt das Qualitätsprofil, veröffentlichen sie es und publizieren es in den Kanal der Kette. Jonas erstellt außerdem den Herbstkatalog als PDF.
3. Sibylle gibt der Supermarktkette den Zugriff frei auf die veröffentlichten Produkte — vorher sieht der Abnehmer nichts.
4. Dr. Weber, der Qualitätsmanager, ist pip_viewer. Er liest vor einem Zertifizierungsaudit Produkte, Produktpässe und Qualitätsergebnisse und exportiert die Analysen. Einen Wert versehentlich zu ändern ist ihm nicht möglich.
5. Ein Produkt braucht eine neue Allergenangabe. Mira ändert sie und veröffentlicht. Eine Änderung, die genehmigt werden muss, läuft über den Workflow: Mira reicht sie ein, Sibylle (oder wen der Workflow benennt) genehmigt sie. Das alte Produkt zu archivieren oder zu löschen ist Sibylles Schritt.

Abnehmerrollen

pic_admin — Abnehmer-Administration

• Personen und Zugriff — lädt Benutzer ein, vergibt Rollen, verwaltet API-Schlüssel, SSO und Anmelderichtlinie, Abrechnung und KI-Einstellungen.
• Lieferanten einbinden — legt Onboarding-Anfragen für Lieferanten an, prüft und genehmigt deren Einreichungen, definiert Mapping-Vorlagen und die Qualitätsprofile, die eine Einreichung erfüllen muss.
• Daten empfangen — nimmt eingehende GDSN-Nachrichten an oder lehnt sie ab und fragt, wie jeder Abnehmer, Zugriff bei Lieferanten an und nutzt deren freigegebene Produkte.
• Governance — Audit-Protokoll, Datenschutzwerkzeuge und Webhooks.

pic_subscriber — Abnehmer-Benutzer

Die Arbeitsrolle für Category Manager, Datenverantwortliche und Integratoren:

• Liest die Produkte aller Lieferanten, die den Zugriff freigegeben haben — Attribute, Assets, Kategorien und Beziehungen — und sucht lieferantenübergreifend.
• Synchronisiert und exportiert die Daten in die eigenen Systeme und verwaltet Webhooks, die diese Systeme über Änderungen informieren.
• Bearbeitet eingehende GDSN-Nachrichten und kann bei einem Lieferanten Zugriff anfragen.
• Liest, ändert aber nicht: Onboarding-Anfragen und -Einreichungen, Mapping-Vorlagen und Qualitätsprofile. Ein Subscriber hat keinen Zugriff auf API-Schlüssel, SSO oder Abrechnung.

Ein Beispiel für Abnehmer

Die Frischemarkt AG ist eine Supermarktkette.

1. Tobias, Leiter Daten, ist pic_admin. Er registriert die Organisation, lädt sein Team ein und legt eine Onboarding-Anfrage für einen kleinen Lieferanten an, der PIE noch nicht nutzt: welche Felder Pflicht sind und welches Qualitätsprofil die Daten erfüllen müssen.
2. Der Lieferant reicht seine Daten über den erhaltenen Link ein. Tobias prüft die Einreichung, sieht sich die Feldzuordnung in der Vorschau an und genehmigt sie — die Produkte des Lieferanten erscheinen nun im Katalog der Kette.
3. Lena und Murat sind pic_subscriber. Sie durchsuchen die freigegebenen Produkte, filtern nach Allergen oder Zertifizierung und vergleichen Lieferanten. Entwürfe eines Produzenten oder Produkte, die Frischemarkt nicht freigegeben wurden, sehen sie nie.
4. Murat bindet das ERP an. Er richtet einen Webhook ein, damit das ERP benachrichtigt wird, wenn ein Lieferant ein Produkt aktualisiert, und nutzt den Export für die nächtliche Synchronisierung.
5. Wenn eine neue Kollegin dazukommt, kann nur Tobias sie einladen und ihre Rolle wählen.

Organisationen, die Produzent und Abnehmer zugleich sind

Eine Organisation vom Typ both hat beide Rollensätze für die beiden Aufgaben: Ihre Produzenten-Benutzer pflegen den eigenen Katalog, ihre Abnehmer-Benutzer lesen, was Lieferanten freigegeben haben. Eine both-Organisation kann außerdem ein freigegebenes Lieferantenprodukt als Zutat in ein eigenes Produkt übernehmen — ein Schritt auf Produzentenseite für pip_admin und pip_editor; die Lieferantendaten werden in diesem Moment kopiert, spätere Änderungen des Lieferanten warten auf Ihre Prüfung. Wie eine Organisation zu both wird und was das für ihren Tarif bedeutet, steht in Produzieren und einkaufen mit einem Konto.

Plattformrollen

Das PIE-Personal hat eigene, getrennte Rollen, die für die ganze Plattform gelten statt für eine Organisation: Plattform-Administration (Organisationen, Plattformbenutzer, Abrechnung), schreibgeschützte Revision, Support (einem Kunden helfen, mit protokolliertem Identitätswechsel) und Abrechnung. Diese Rollen können Sie Ihren eigenen Benutzern nicht geben. Was jede darf, steht in der Referenz Rollen & Berechtigungen.

Die richtige Rolle wählen

• Geben Sie den meisten Personen die kleinste Rolle, die ihre Aufgabe erfüllt: Editor für alle, die Daten pflegen, Viewer für alle, die nur lesen, Subscriber für die täglichen Benutzer auf Abnehmerseite.
• Halten Sie die Zahl der Administratoren klein — eine Administration kann Daten für andere Organisationen freigeben und API-Schlüssel erzeugen.
• Eine Rolle ändern Sie am Benutzer unter Administration → Team (Produzenten-App) bzw. im Team-Bereich der Einstellungen (Abnehmerportal).
• Heißt es „die Schaltfläche fehlt", prüfen Sie zuerst die Rolle: Eine nicht angebotene Schaltfläche bedeutet, dass die Rolle die Aktion nicht ausführen darf; welche Rolle sie darf, zeigt die Referenzmatrix.