ERP Software mit Delphi

[Furtbichler]

Normalerweise, bzw. in meiner kleinen Welt, werden System nicht so gekoppelt, das man direkt ins Zielsystem schreibt.

Normalerweise gibt es den berühmten Pull/Push-Mechanismus, d.h. Import/Export-Dateien, wobei 'Dateien' auch ein Synonym für eigenen Tabellen sein kann. Natürlich gibt es auch die berühmten TXT/CSV/XML-Dateien in einem Verzeichnis deiner Wahl.

Der Import in die eigene DB wird dann von customized-Importprozessen vorgenommen. Meist behält sich der Anbieter vor, die Importe zu schreiben, was auch anzuraten ist. Bei SAP kann man das auch selbst machen, da die meines Wissens nach, das Paradigma der virtuellen Tabellen mit einer API verfolgen, d.h. man beschreibt bestimmte 'Tabellen', um Daten zu importieren.

[Perlsau]

Zitat von Furtbichler:

Normalerweise, bzw. in meiner kleinen Welt, werden System nicht so gekoppelt, das man direkt ins Zielsystem schreibt.

Mich hat das damals auch etwas gewundert, daß ich eine vollständige Kopie der Firmen-DB einfach so erhalten habe. Da waren auch Bankverbindungen und Kontenbewegungen drin. Selbstverständlich hab ich nichts programmiert, um da reinzuschreiben, es ging nur um's Auslesen des aktuellen Artikelbestandes nebst Preisen, Bildern, Attributen wie Länge, Breite, Höhe, Gewicht, Farbe usw. Irgendwelche virtuellen Tabellen waren da nicht zu sehen, alles war stark normalisiert, d.h. jede Möglichkeit, Subtabellen anzulegen, wurde genutzt. Ich weiß bis heute nicht mal, mit welchem WiWa-System dort genau gearbeitet wurde, ich hatte nur die DB als Zip-Datei erhalten.

Zitat von Furtbichler:

Normalerweise gibt es den berühmten Pull/Push-Mechanismus, d.h. Import/Export-Dateien, wobei 'Dateien' auch ein Synonym für eigenen Tabellen sein kann. Natürlich gibt es auch die berühmten TXT/CSV/XML-Dateien in einem Verzeichnis deiner Wahl.

Das würde aber auch bedeuten, daß bei einem Daten-Update des abhängigen Systems immer zwei Schritte notwendig sind: Export vom Quellsystem und Import ins Zielsystem. Bei meiner damaligen Entwicklung war immer nur der Importvorgang nötig, das Aktualisieren des Quell-Systems besorgten die Damen in der Fakturierung. Beim Start des Katalog-Programsm wurde dann automatisch dessen DB aktualisiert: Veränderungen übernommen, nicht mehr existierende Artikel gelöscht, neue Artikel eingefügt. Das war im Grunde eine doppelte Verwaltung, ging aber nicht anders, weil die Suche in der Quell-DB viel länger dauerte als in der Katalog-DB.

Zitat von Furtbichler:

Der Import in die eigene DB wird dann von customized-Importprozessen vorgenommen. Meist behält sich der Anbieter vor, die Importe zu schreiben, was auch anzuraten ist.

Mit Anbieter meinst du jetzt den Anbieter des zugrundeliegenden Systems, also des Quellsystems, z.B. die FiBu, die Daten für ein WaWi liefern soll? Wenn ja, wie kann ein Anbieter einer FiBu z.B. Importe für ein Warenwirtschaftssystem schreiben, das ein anderer entwickelt hat? Der müßte doch zumindest den Quellcode des WaWi haben, und zudem die entsprechende Entwicklungsumgebung, und sich dann noch mit der Programmiersprache auskennen.

Zitat von Furtbichler:

Bei SAP kann man das auch selbst machen, da die meines Wissens nach, das Paradigma der virtuellen Tabellen mit einer API verfolgen, d.h. man beschreibt bestimmte 'Tabellen', um Daten zu importieren.

Vielleicht gab es damals bei diesem WaWi ja auch eine entsprechende API, aber das konnte mir niemand sagen, ging ja alles fernmündlich bzw. via Teamviewer über die Bühne. Ich hab die dortige Clientsoftware nie richtig gesehen.

[Hansa]

Zitat von Perlsau:

...
also des Quellsystems, z.B. die FiBu, die Daten für ein WaWi liefern soll?

Perlsau, wie soll denn eine Fibu (zumindest eine klassische) Daten an ein WaWi liefern ? Auf mittlerweile glaube 9 Seiten wurde die Nomenklatur doch genau erläutert. Wie soll man nun aus Rechnungs/Mwst.-Beträgen (also aus der Fibu) einen Lagerbestand für WaWi rekonstruieren ? Holger Klemt hat das doch ausführlich beschrieben : FiBu hat nur am Rande etwas mit WaWi zu tun ! Das ist eine Einbahnstrasse. Aus dem Wawi werden sich vielleicht Daten für die Fibu ableiten lassen, umgekehrt aber wohl kaum.

[mkinzler]

Ein WaWi-System benötigt aber u.U. Zugriff auf die Nebenbücher ( Kreditoren, Debitoren) z.B. für das Bestellwesen

[hstreicher]

ich ergaenze mal die vorherige Aussage,

eine Fibu _muss_ einen Rückkanal zur Wawi/ERP haben um zu verhindern dass Kunden die nicht zahlen weiter beliefert werden,
ob das jetzt Elektronisch oder als Liste per Sneakernet erfolgt ist wohl Betriebsgrößen abhaengig

[Furtbichler]

Ich glaube, ihr verwechselt 'man wäre in der Lage, die DB zu schroten' und 'der Datenaustauschprozess funktioniert so, das man direkt in die DB schreibt'.

In der Tat hatte ich bei diversen Systemen direkten Zugriff auf die DB. Verändert man die Daten allerdings, erlischt der Support, die Garantie usw.

Ich persönlich würde beim Datenaustausch hererogener Systeme für die einzelnen Systeme Adapter implementieren (lassen), die ein standartisiertes Austauschformat und -protokoll verwenden.

[mkinzler]

Es ging um die Notwendigkeit des Datenaustausches und Hansas Ansicht, das ein WaWi (Aus seiner Sicht) keine Daten der Fibu benötigt.

[arnof]

Zitat von hstreicher:

ich ergaenze mal die vorherige Aussage,

eine Fibu _muss_ einen Rückkanal zur Wawi/ERP haben um zu verhindern dass Kunden die nicht zahlen weiter beliefert werden,
ob das jetzt Elektronisch oder als Liste per Sneakernet erfolgt ist wohl Betriebsgrößen abhaengig

Es soll sogar WAWIS (ERP 's geben), die eine eigene OP Verwaltung haben, damit man das machen kann. Viele kleine Firmen bis zu mittleren (was mittel ist, da kann man ja wieder 100 Posts machen) lagern die Buchhaltung aus zum Steuerbüro. Der Rückkanal ist da meistens verwehrt, da nicht gerade Leuchten der EDV dort tätig sind

Das ist meine Erfahrung in nun ca 25 Jahren auf diesem Gebiet und bei über 50.000 Kunden in diesem Bereich!