Administration on Product Documentation

Rollencenter

Mon, 01 Jan 0001 00:00:00 +0000

Zweck

Das Intercompany-Rollencenter ist der zentrale Einstieg für alle Anwender, die regelmäßig mit IC-Belegen arbeiten. Es bündelt Navigation, Kennzahlen und Aktionen an einer Stelle, sodass typische Aufgaben ohne Umwege erledigt werden können.

Zugriff in Business Central

Das Rollencenter wird über die Benutzer-/Rollenzuordnung in der Benutzerverwaltung oder über „Meine Einstellungen" ausgewählt.

Zum Vergrößern anklicken

Voraussetzungen

Anwender verfügt über die passenden Berechtigungen (siehe Zugriffsrechte).
Intercompany ist auf Mandantenebene eingerichtet.

Tätigkeiten

Einstieg in Partnerpflege, Transaktionsübersichten und Fehlerprotokoll.
Direkte Navigation zur Aufgabenwarteschlange für Retry bzw. Fehleranalyse.
Start typischer Aktionen für Senden, Akzeptieren und Nachbearbeiten von IC-Belegen.

Zum Vergrößern anklicken

Zugriffsrechte

Mon, 01 Jan 0001 00:00:00 +0000

Zweck

BE-terna Intercompany bringt eigene Berechtigungssätze mit, die zusätzlich zu den Standard-IC-Berechtigungen von Business Central vergeben werden. Diese Seite beschreibt die Sets und ihre typische Zuordnung an Anwender.

Zugriff in Business Central

Zugriffsrechte werden über die Berechtigungssätze und die Benutzerverwaltung vergeben.

Voraussetzungen

Administrator-Rechte zur Vergabe von Berechtigungssätzen.
Kenntnis, welche Rollen im Unternehmen mit Intercompany arbeiten.

Tätigkeiten

Passenden Berechtigungssatz an jeden IC-Anwender zuweisen.
Zuweisung bei Rollenwechsel prüfen und anpassen.
Testmandant nutzen, um neue Rollen vor dem Rollout zu validieren.

Felder und Aktionen

Berechtigungssatz	Zweck
`BET ICY BASIC`	Basisrechte für alle IC-Anwender; deckt das Lesen und Arbeiten mit IC-Belegen ab.
`BET ICY SETUP`	Zusätzliche Rechte zur Pflege der Intercompany-Einrichtung und IC-Partner.
Zugehörige Standard-BC-Sets	Müssen parallel vergeben sein, damit Verkauf und Einkauf funktionieren.

Überwachung und Troubleshooting

Fehlende Berechtigungen zeigen sich oft erst beim Akzeptieren eines IC-Belegs. Prüfen Sie in solchen Fällen zuerst die Berechtigungssätze des Nutzers.
Für die Aufgabenwarteschlange und das Fehlerprotokoll werden zusätzliche Standard-Rechte benötigt.

Best Practices

Least Privilege anwenden: BET ICY SETUP nur an wenige Administratoren.
Berechtigungen periodisch auditieren, insbesondere nach Rollouts oder Upgrades.

Inbox und Outbox

Mon, 01 Jan 0001 00:00:00 +0000

Zweck

Die IC-Inbox und die IC-Outbox zeigen alle IC-Transaktionen mit ihrem aktuellen Zustand. Sie sind die primäre Arbeitsfläche für die tägliche Betriebsarbeit: Senden, Akzeptieren, Wiedervorlage, Fehleranalyse.

Zugriff in Business Central

Inbox und Outbox werden über das Rollencenter oder die Suche erreicht.

Voraussetzungen

Intercompany ist eingerichtet, mindestens ein IC-Partner ist aktiv.
Berechtigungen für IC-Transaktionen sind vergeben.

Tätigkeiten

Ausstehende Transaktionen gezielt senden oder akzeptieren.
Fehlgeschlagene Transaktionen analysieren und erneut starten.
Bereits verarbeitete Transaktionen zur Historie einsehen.

Felder und Aktionen

Aktion	Wirkung
Senden (Outbox)	Überträgt die Transaktion an den Partner.
Akzeptieren (Inbox)	Übernimmt die Transaktion im empfangenden Mandanten.
Ablehnen	Markiert die Transaktion als nicht zu verarbeiten.
Erneut versuchen	Startet eine zuvor fehlgeschlagene Verarbeitung neu.

Überwachung und Troubleshooting

Bleiben Transaktionen lange im Status „Offen", prüfen Sie die Aufgabenwarteschlange.
Transaktionen im Status „Fehler" verweisen auf Einträge im Fehlerprotokoll.

Best Practices

Inbox täglich durchgehen, auch wenn automatisches Akzeptieren aktiv ist.
Outbox regelmäßig nach alten „Offen"-Einträgen absuchen – sie deuten oft auf deaktivierte Warteschlangen-Jobs hin.

Transaktionsstatus

Mon, 01 Jan 0001 00:00:00 +0000

Zweck

Jede IC-Transaktion durchläuft mehrere Status. Diese Seite beschreibt die Bedeutung der Status und die typischen Übergänge, damit Anwender erkennen, wo eine Transaktion gerade steht und was als Nächstes zu tun ist.

Zugriff in Business Central

Der Status ist in IC-Inbox, IC-Outbox und in den Transaktions-Übersichten sichtbar.

Voraussetzungen

Zugriff auf die IC-Transaktionslisten.
Grundkenntnis des IC-Prozesses (Senden, Akzeptieren, Buchen).

Tätigkeiten

Status regelmäßig prüfen und auffällige Transaktionen früh behandeln.
Bei „Fehler" die Ursache im Fehlerprotokoll klären.

Felder und Aktionen

Status	Bedeutung
Neu	Transaktion wurde erstellt, aber noch nicht gesendet/akzeptiert.
Offen	Transaktion ist in Verarbeitung (z. B. durch die Aufgabenwarteschlange).
Fehler	Verarbeitung ist abgebrochen; Details stehen im Fehlerprotokoll.
Akzeptiert	Empfänger hat den Beleg übernommen.
Abgelehnt	Transaktion wurde bewusst nicht verarbeitet.
Abgeschlossen	Transaktion ist durchgelaufen und archiviert.

Überwachung und Troubleshooting

Mehrere Transaktionen in „Offen" über längere Zeit → Aufgabenwarteschlange prüfen.
Transaktionen in „Fehler" nicht massenhaft erneut starten, ohne die Ursache geklärt zu haben.

Best Practices

Status-Feld in die täglichen Kacheln des Rollencenters einbeziehen.
„Abgelehnt" bewusst dokumentieren, damit Nachfragen nachvollziehbar sind.

Fehlerprotokoll

Mon, 01 Jan 0001 00:00:00 +0000

Zweck

Das Fehlerprotokoll ist die zentrale Anlaufstelle für fehlgeschlagene IC-Verarbeitungen. Jede abgebrochene Transaktion hinterlässt hier einen Eintrag mit Zeitpunkt, Transaktionsreferenz und Fehlermeldung.

Zugriff in Business Central

Das Fehlerprotokoll wird aus dem Rollencenter oder über die Suche geöffnet.

Voraussetzungen

Berechtigung zum Lesen der IC-Fehlerprotokolleinträge.
Zugriff auf die betroffenen Quell- bzw. Zielbelege zur Nachbearbeitung.

Tätigkeiten

Fehlermeldungen lesen, Kategorie und Ursache klären.
Betroffene Transaktion bereinigen und erneut starten.
Einträge als erledigt markieren oder dokumentieren, warum sie bewusst bestehen bleiben.

Felder und Aktionen

Feld	Inhalt
Datum/Uhrzeit	Zeitpunkt des Abbruchs.
Quelle	Betroffene IC-Transaktion oder Aufgabenwarteschlangen-Eintrag.
Fehlertext	Von Business Central gelieferte Fehlermeldung.
Benutzer	Ausführender Benutzer oder System-Benutzer der Aufgabenwarteschlange.

Überwachung und Troubleshooting

Häufig wiederkehrende Fehlertexte deuten auf ein Einrichtungs- oder Datenproblem hin, nicht auf ein Einzelereignis.
Vor einem Massen-Retry immer Ursache klären, sonst produzieren die Retries neue Einträge.

Best Practices

Fehlerprotokoll mindestens einmal täglich durchgehen.
Wiederkehrende Fehlertypen in der Partner- oder Stammdatenpflege abstellen.

Aufgabenwarteschlange

Mon, 01 Jan 0001 00:00:00 +0000

Zweck

Die Aufgabenwarteschlange trägt die automatische Verarbeitung von IC-Belegen. Diese Seite beschreibt den laufenden Betrieb: Überwachung, Start/Stopp, Fehleranalyse und Retry-Strategie. Die initiale Einrichtung ist auf der Seite Aufgabenwarteschlange (Einrichtung) dokumentiert.

Zugriff in Business Central

Aufgabenwarteschlangen-Posten werden im Rollencenter und über die Suche „Aufgabenwarteschlangenposten" erreicht.

Voraussetzungen

Aufgabenwarteschlange ist eingerichtet (siehe Einrichtungsseite).
Nutzer verfügt über Rechte zum Starten/Anhalten von Posten.

Tätigkeiten

Zustand der IC-Posten prüfen („Bereit", „In Bearbeitung", „Fehler").
Fehlgeschlagene Posten gezielt neu starten.
Zeitpläne bei veränderter Last anpassen.

Felder und Aktionen

Aktion	Wirkung
Auf „Bereit" setzen	Startet einen Posten neu, z. B. nach Fehler.
Anhalten	Stoppt die zyklische Ausführung temporär.
Fehler einsehen	Öffnet die zuletzt aufgetretene Fehlermeldung.
Maximale Anzahl von Versuchen	Begrenzt die automatische Wiederholung.

Überwachung und Troubleshooting

„Fehler"-Posten mit sprechendem Fehlertext zuerst beheben, bevor per Retry nachjustiert wird.
Dauerhafte „In Bearbeitung"-Zustände über die Zeit deuten auf hängende Sessions hin – ggf. Posten anhalten und neu starten.
Automatisches Retry über die Intercompany-Einrichtung (siehe Automatisierung) reduziert manuelle Arbeit.

Best Practices

Maximale Anzahl der Ausführungsversuche setzen – unbegrenzt ist selten sinnvoll.
Zyklen nur so häufig wählen wie nötig, um die Plattform nicht unnötig zu belasten.

Azure File Share

Mon, 01 Jan 0001 00:00:00 +0000

Zweck

BE-terna Intercompany unterstützt den Dateiaustausch zwischen IC-Partnern über einen Azure File Share. Diese Seite beschreibt die laufende Verwaltung dieses Austauschs – die zugrunde liegenden Rechte werden im Azure-Portal gepflegt.

Zugriff in Business Central

Die Azure-File-Share-Einstellungen sind auf der IC-Partnerkarte im Bereich des Transfertyps sichtbar.

Zum Vergrößern anklicken

Voraussetzungen

Azure-Speicherkonto mit einem File-Share; Zugriff erfolgt über einen SAS-Token (nie über persistente Kontoschlüssel in BC).
Partner nutzen denselben File-Share-Pfad für den bilateralen Austausch.
Transfertyp „Dateispeicherort" auf der IC-Partnerkarte aktiv.

Tätigkeiten

Gültigkeit des SAS-Tokens überwachen und rechtzeitig erneuern.
Freigaben und Rechte im Azure-Portal auf das Notwendige begrenzen.
Bei Störungen: Netzwerkzugriff und Ablageverzeichnis prüfen, bevor die IC-Einrichtung angepasst wird.

Felder und Aktionen

Feld	Zweck
File-Share-Pfad	Quell- bzw. Zielverzeichnis des Austauschs.
Zugriffstoken	SAS-Token mit begrenzter Gültigkeit.
Prüfsumme	Optional: Validierung der ausgetauschten Dateien.

Überwachung und Troubleshooting

„Datei nicht gefunden" deutet fast immer auf abgelaufenes Token oder geänderten Pfad hin.
Verbindungsprobleme erzeugen Einträge im Fehlerprotokoll.
Die Aufgabenwarteschlange beim automatischen Import arbeitet nur, wenn das IC-Partnerverzeichnis existiert.

Best Practices

SAS-Token mit möglichst kurzer Gültigkeit und minimalen Rechten ausstellen.
Verzeichnisse pro Partner trennen, um Datenvermischung auszuschließen.