mit APPS

Dies ist Artikel 6 von 8 Artikeln darüber, wie Sie Ihr gesamtes Unternehmen mit BUSINESS CENTRAL abdecken
- ohne kundenspezifische Erweiterungen
- ausschließlich mit APPS
Erfüllen Sie alle Ihre Anforderungen an die Steuerung des GLOBALEN GESCHÄFTS in BUSINESS CENTRAL.
In diesem Artikel erklären wir, was Sie fordern sollten, wie Sie Anpassungen vermeiden und welche APPS Sie nutzen.
Wenn wir mehrere Unternehmen mit Business Central verwalten, entstehen zusätzliche Anforderungen. Das liegt oft an Unternehmen in mehreren Ländern, es können aber auch einfach mehrere Unternehmen im selben Land sein.
Die Unternehmen haben typischerweise unterschiedliche Rollen in der Lieferkette, zum Beispiel Logistikunternehmen, Produktionsunternehmen und Vertriebsunternehmen mit einer Reihe von Prozessen dazwischen.
Wir haben ein Vertriebsunternehmen mit Verkaufsaufträgen, weil es Bestellungen von Endkunden erhält. Das Vertriebsunternehmen liefert Prognosen an die Zentrale, die den Produktbedarf plant und auf das Lager-/Logistikunternehmen oder einen externen Logistikdienstleister zur Lieferung zurückgreift; bei manchen Aufträgen kann das Logistikunternehmen direkt an den Endkunden liefern.
Die Zentrale kauft außerdem Waren beim Produktionsunternehmen ein, das eine Reihe externer Lieferanten nutzt, die Artikel produziert und sie in einem Container an das Logistik-/Lagerunternehmen liefert.

Das ist nur ein Beispiel. Egal, wie unsere Unternehmensstruktur aussieht, wir müssen sie in Business Central abbilden können, und die Prozesse müssen unterstützt werden, damit wir nicht alle Daten und die Buchhaltung manuell handhaben müssen.
Standardmäßig kann Business Central Intercompany-Transaktionen gut abwickeln, insbesondere seit dem Release vom Oktober 2023, aber wir brauchen schnell mehr Struktur und Automatisierung, damit wir automatisch in mehreren Unternehmen gleichzeitig buchen können.
Wenn das Vertriebsunternehmen eine Einkaufsbestellung erstellt, muss automatisch in dem Unternehmen, das liefern soll, ein Verkaufsauftrag erstellt werden – und so weiter durch die Unternehmensstruktur. Wir möchten außerdem die Lagerbestände in anderen Unternehmen einsehen können, damit wir bereits bei der Auftragsannahme vom Kunden sehen, ob der Artikel in einem anderen Unternehmen auf Lager ist.

Wir müssen außerdem die Preisgestaltung zwischen Unternehmen steuern. Eine Herausforderung sind auch unterschiedliche Wechselkurse in verschiedenen Unternehmen.
Wir müssen dieselbe Quelle für Preise und Wechselkurse verwenden, damit Eliminierungen einfacher werden und wir in den Konsolidierungskonten dieselben Werte für dieselben Artikel erhalten.

Master Data Management ist ein wichtiges Thema in einem Konzern mit vielen Unternehmen (juristischen Einheiten). Wir müssen eine globale Struktur für Stammdaten haben und Stammdaten zwischen Unternehmen synchronisieren können, und wir müssen Stammdaten in die Belege aufnehmen, die bei Verkaufs-, Einkaufs- und Umlagerungsaufträgen zwischen allen Unternehmen verwendet werden. Wir gehen darauf in einem eigenen Kapitel zu Stammdaten ausführlich ein.
Vielleicht haben wir fünf verschiedene Unternehmen, die in der Praxis dieselben Debitoren, Artikel, Stammdaten usw. haben werden. Wenn wir in der Zentrale einen neuen Artikel anlegen, möchten wir, dass er in die anderen Unternehmen repliziert wird, sodass wir ihn nicht mehrfach anlegen – und in mehreren Unternehmen pflegen – müssen. Wir brauchen Stammdaten, die in einer Master-und-Subscriber-Hierarchie organisiert sind.

Container sind ein wichtiges Thema, wenn wir Waren über weite Strecken versenden, sowohl wenn wir Waren in Containern senden als auch wenn wir sie empfangen.
Als Käufer kann es sein, dass beim Lieferanten ein Container steht, den wir nach und nach mit Einkaufsbestellungen füllen, und wenn er voll genug ist, lassen wir ihn zu uns verschiffen. Dann möchten wir alle Einkaufsbestellungen im Container gemeinsam verwalten. Wenn sich der Container unterwegs um 4 Tage verspätet, möchten wir alle Einkaufszeilen auf einmal aktualisieren und die dadurch entstehenden Konflikte finden.
Genauso sind wir als Verkäufer diejenigen, die den Container versenden, und wir möchten die Kapazität des Containers so gut wie möglich planen, bevor wir ihn auf den Weg schicken.

Oft gibt es Unterschiede, welche Waren und Varianten in verschiedenen Unternehmen ein- und verkauft werden dürfen.
Im Lagerunternehmen haben wir 8 Farben eines Artikels, und ein Vertriebsunternehmen muss alle 8 einkaufen, während ein anderes nur 2 der Farben einkaufen kann, weil es nur diese 2 Farben vermarktet.
Im Webshop müssen für Kunden im ersten Land ebenfalls alle 8 Farben vorhanden sein, für Kunden im zweiten Land aber nur 2. Und die Zentrale hat entschieden, dass eine der Farben eingestellt wird und daher nur 7 der Farben beim Lieferanten nachbestellt werden dürfen.
Die internationale Struktur muss all das in Business Central steuern können.
Wenn Sie Waren in viele Länder anbieten, werden Verpackungen und Etiketten zu einer besonderen Herausforderung. Ein Inhaltsstoffetikett kann 3 Sprachen enthalten: Englisch, Spanisch und Portugiesisch, und das bestimmt, in welchen Ländern das Produkt verkauft werden kann.
Wir haben denselben Artikel mit anderen Sprachkombinationen auf Lager, z. B. Englisch, Italienisch und Griechisch. Es kann sein, dass wir 1000 Stück des Artikels auf Lager haben und alle 1000 in englischsprachige Länder liefern können, aber nur 80 nach Italien, weil die anderen 920 kein Italienisch auf dem Inhaltsstoffetikett haben.
Viele Varianten von Verpackungen und Etiketten sind eine zusätzliche Herausforderung in Business Central.

Beim Reporting geht es um Business Intelligence. In einem globalen Setup möchten wir über die gesamte Unternehmensstruktur hinweg berichten können. Was verkaufen wir in welchen Teilen der Welt? Wie lang sind unsere Lieferzeiten?
Wenn Business Intelligence zeigt, dass die Wiederbeschaffungszeit eines Artikels in Wirklichkeit 3 Monate beträgt, die Stammdaten des Artikels im ERP aber 2 Monate angeben, sollten wir die Stammdaten korrigieren, damit wir den Kunden nichts versprechen, was wir nicht einhalten können.

Die Finanzkonsolidierung ist ein weiteres Thema, das häufig mit einem Reporting-Werkzeug gehandhabt wird.
Wir möchten die Einheiten der Unternehmensstruktur vergleichbar analysieren können. Es bringt nichts, jedes Mal Daten von Grund auf zuordnen zu müssen, um vergleichbare Zahlen zu erhalten. Wir müssen die Struktur zentral für den gesamten Konzern verwalten können.
Typischerweise erstellen wir einen Konzernabschluss, in dem wir alle Daten der darunterliegenden Unternehmen bis zum Konzernabschluss konsolidieren und die Transaktionen eliminieren. Sofern nicht alle Unternehmen Business Central nutzen, ist es klug, die Konsolidierung mit einer Business-Intelligence-Lösung durchzuführen, aber das setzt voraus, dass wir in allen Unternehmen harmonisierte Kontenpläne und Dimensionscodes haben.


Wenn unser Unternehmen international tätig ist – oder wenn wir in unserem ERP-System viele Unternehmen haben, die integriert werden müssen –, ist „Intercompany“ ein wichtiges Thema.
In einem Vertriebsunternehmen erstellen wir einen Verkaufsauftrag für einen Kunden; wenn wir ihn freigeben, muss eine Einkaufsbestellung zum Kauf des Artikels bei einem anderen Unternehmen der Gruppe erstellt werden, und im Produktions- oder Lagerunternehmen unseres Konzerns muss (automatisch) ein Verkaufsauftrag erstellt werden.
Nun haben wir drei Auftragsbelege, die über zwei Unternehmen hinweg miteinander verknüpft sind, und wir müssen sie gemeinsam verwalten und als Einheit ändern können.

Die Verwaltung von Änderungen ist der schwierige Teil. Im Produktionsunternehmen müssen wir Mengen oder Preise ändern können, und die Änderung muss sowohl in die Einkaufsbestellung als auch in den Verkaufsauftrag im Vertriebsunternehmen übernommen werden.
Wir müssen an jedem der drei Datensätze eine Änderung vornehmen können, und die Änderung muss sich in den anderen widerspiegeln. Es nützt nichts, wenn unsere Lösung zu starr verdrahtet ist, um die Welt zu unterstützen, in der wir leben.
Es gibt mehrere Bereiche, in denen wir im Tagesgeschäft Flexibilität brauchen.
Unser Vertriebsunternehmen braucht die Möglichkeit, einen Verkaufsauftrag mit Zeilen aus mehreren Unternehmen zu erstellen, z. B. zwei Artikel vom lokalen Vertriebsunternehmen selbst, vier Artikel vom Lagerunternehmen in Deutschland und drei Artikel, die vom Unternehmen in Polen produziert werden.
Wir müssen angeben können, ob es sich um eine Direktlieferung handelt – d. h. ob alle Unternehmen die Artikel direkt an den Endkunden senden – oder ob die deutschen und polnischen Unternehmen die Artikel an unser lokales Vertriebsunternehmen senden, das dann an den Kunden versendet.
Das ist tatsächlich einer der schwierigsten Aspekte von Intercompany-Transaktionen. Wenn die deutschen und polnischen Unternehmen direkt an den Kunden liefern, müssen sie einen Lieferschein oder eine Rechnung beilegen können, die nach der Logik des ursprünglichen lokalen Vertriebsunternehmens gedruckt wurde, mit dem der Kunde ja zu tun hatte. Das wird kompliziert, wenn verschiedene Unternehmen und Buchungseinheiten beteiligt sind.
Wenn das lokale Unternehmen an einen lokalen Kunden zu lokalen Preisen und lokalen Rabatten verkauft, müssen die Belege in Deutschland und Polen aus dem Drucker kommen können.
Wir möchten Artikel außerdem über Unternehmen hinweg verfolgen können.
Wenn der Lagermitarbeiter in Deutschland Artikel mit Seriennummern kommissioniert, muss er die Seriennummer scannen, und sie muss dann bis zu unserem lokalen Vertriebsunternehmen durchfließen, sodass wir lokal sehen können, welche Seriennummern für den Auftrag kommissioniert wurden.
Bei der Artikelkonfiguration müssen die Daten in die andere Richtung fließen. Wir erfassen im lokalen Verkaufsauftrag die Spezifikationen des konfigurierten Artikels und vielleicht die Tatsache, dass ein Firmenlogo auf den Deckel gedruckt werden muss. Diese Details müssen dann zum polnischen Produktionsunternehmen fließen, das die Artikel produziert und das Logo auf den Deckel druckt.
Wie geht die Intercompany-Lösung schließlich mit Fehlern um? Wenn zwischen Unternehmen etwas schiefgeht (z. B. wenn die Artikelnummer im anderen Unternehmen nicht existiert), landet der Auftrag dann in einem Fehlerprotokoll, dem jemand nachgehen muss, bevor der Auftrag fortgesetzt werden kann?
Wir empfehlen unbedingt, dass die Lösung online arbeitet und Fehler in Echtzeit an den Benutzer zurückgemeldet werden. Das bedeutet: Wenn wir in unserem lokalen Vertriebsunternehmen einen Auftrag erfassen, der Artikel aus dem deutschen und dem polnischen Unternehmen abruft, sehen wir etwaige Fehler sofort beim Tippen auf dem Bildschirm und können im Prozess nicht weitergehen, bevor der Fehler behoben ist.
Wir stellen einen deutlichen Anstieg der Nachfrage nach Intercompany-Lösungen fest. Es wird zweifellos immer normaler, dass Transaktionen Grenzen und Unternehmen überschreiten.
Die Grundlagen sind einigermaßen einfach, aber Flexibilität bei den Herausforderungen des Tagesgeschäfts ist das wahre Merkmal einer guten Intercompany-Lösung.


Wir haben vielleicht fünf verschiedene Unternehmen (juristische Einheiten), die in der Praxis dieselben Debitoren, Artikel, Stammdaten usw. haben werden. Wenn wir in der Zentrale einen neuen Artikel anlegen, möchten wir, dass er in die anderen Unternehmen repliziert wird, sodass wir ihn nicht mehrfach einrichten müssen.
Möglicherweise haben wir in einer der Tochtergesellschaften auch ein anderes ERP-System. Wir brauchen Stammdaten, die über alle Plattformen hinweg synchronisiert werden, Business Central ebenso wie andere ERP-Systeme im Konzern. Das gilt auch für Stammdaten, die wir selbst angelegt haben, d. h. Farbe, Größe, Material oder viele andere Arten von Stammdaten zu Artikeln, Debitoren und Kreditoren

Die Herausforderung besteht darin, die verschiedenen ERP-Systeme mit unterschiedlichen Datenstrukturen miteinander kommunizieren zu lassen. Bei der Entwicklung einer Datenstruktur müssen wir sorgfältig überlegen, damit die Schlüssel in allen Unternehmen – über die verschiedenen ERP-Systeme hinweg – zusammenpassen.
Wir können zwischen verschiedenen Strategien wählen.
Eine zentralisierte Strategie bedeutet, dass wir ein Hauptunternehmen haben, in dem wir alle Stammdaten in konsolidierter Form einrichten und alle Debitoren, alle Artikel und alles andere zusammenführen, was vom zentralen Team verwaltet werden soll. Das System „schiebt“ die Daten vom Hauptunternehmen in die peripheren Unternehmen.
Zentrale Verwaltung hat gewisse Vorteile, aber der Nachteil ist, dass Daten schwerer zu pflegen sind, wenn weniger Mitarbeiter Zugriff haben.
Vielleicht bemerkt ein lokaler Benutzer in Frankreich, dass eine bestimmte Information zu einem Artikel falsch ist, bekommt sie aber nicht korrigiert, weil es sehr mühsam ist, sie an die Zentrale zu melden. Wenn er seine lokalen Daten korrigiert, werden sie beim nächsten Synchronisierungsjob einfach von den Daten des Hauptunternehmens überschrieben.
Wir tendieren daher zu einer hybriden Strategie, bei der Daten in beide Richtungen synchronisiert werden können.
Es ist in Ordnung, dass Daten in einem zentralen Hauptunternehmen gesammelt werden, aber wir halten es für entscheidend, dass lokale Benutzer die Daten aktualisieren können, sodass der Franzose die lokalen Artikeldaten aktualisieren kann, die Änderung zurück in das zentrale Unternehmen synchronisiert wird und der nächste Synchronisierungsjob seine Änderung in alle Unternehmen repliziert.
Wir müssen natürlich im Blick behalten, welche Bearbeitungsrechte er braucht, d. h. welche Felder er aktualisieren darf und an welchen er nichts ändern darf.
Er braucht außerdem die Möglichkeit, Daten auf Französisch einzugeben, ohne dass andere Sprachvarianten überschrieben werden.
Er braucht auch die Möglichkeit, einen Artikel anzulegen, der nur in Frankreich relevant ist und nicht an andere Unternehmen verteilt werden soll.
Je größer der Konzern ist und je weniger Artikel wir haben oder je weniger dynamisch unsere Artikelstruktur ist, desto relevanter halten wir eine zentralisierte Strategie mit einem Hauptunternehmen.
Das gilt auch, wenn wir strenge Qualitätskontrollen für unsere Artikel haben und unsere Entwicklungs- oder Qualitätsabteilung die Daten sehr rigoros absichert und bereinigt. In diesen Fällen ist es sinnvoll, auf dezentrale Aktualisierung und Neuanlage zu verzichten.
Wir müssen eine Stammdatenstruktur mit einem Eigentümer der Daten und Abonnenten der Daten aufbauen können. In jeder Tochtergesellschaft wählen wir die Daten aus, die wir abonnieren möchten.
Gibt es zum Beispiel in einem deutschen Konzern eine französische Tochtergesellschaft, kann die französische Tochtergesellschaft gemeinsame Artikel, Debitoren und andere Stammdaten abonnieren – sie kann aber auch lokale Artikel anlegen, die nur in Frankreich relevant sind.
Wenn die französische Tochtergesellschaft einen Artikel einkauft, der nur in Frankreich existiert, ergibt es keinen Sinn, diese Artikelnummer in 20 andere Tochtergesellschaften auf der ganzen Welt zu replizieren.
