DATEV-Rechnungen einlesen

Liebe Grüsse aus Wien!

Ich arbeite als NAV-Entwickler bei einer Großhandelfirma die jetzt mehr und mehr auch direkt auf Amazon Marketplace verkauft.

Ich habe die Bestellung-Importierung schön automatisiert, aber es ist keine gute Idee 300 Rechnungen pro Tag in Navision zu verbuchen, wir werden eher eine externe E-Commerce Warenwirtschaftslösung dafür einsetzen, und die Daten in NAV importieren und SUMMIERT verbuchen, damit wir nicht eine 100GB Datenbank kriegen.

Nun die meiste Lösungen können Daten nur in DATEV-Format exportieren. Und da habe ich keine Ahnung was das ist oder wie ich dafür eine Schnittstelle entwickle. Google sagt mir DATEV ist eine riesige Genossenschaft in Deutschland aber die Schnittstellen-Definition sind nicht offen, man muss dafür bezahlen.

Oder ich könnten eine Add-On kaufen, aber woher weiss ich auch der zigmillionen Schnittstellen die DATEV hat, welche wird benutztr? Rechung, Gutschrift, Zahlung. Mehr braucht man nicht. Ich würde davon summierte Artikelbuchungsblattzeilen und summierte FiBuBuchungbsblattzeilen generieren und fertig.

(Mindestens) diese beiden Partner hier bieten eine Schnittstelle für DATEV an und sollten dir Details zum Umfang nennen können.

Ich habe die Bestellung-Importierung schön automatisiert, aber es ist keine gute Idee 300 Rechnungen pro Tag in Navision zu verbuchen, wir werden eher eine externe E-Commerce Warenwirtschaftslösung dafür einsetzen, und die Daten in NAV importieren und SUMMIERT verbuchen, damit wir nicht eine 100GB Datenbank kriegen.

Viel Spass beim Buchen der Debitoren- und Kreditorenbuchhaltung, Mahnwesen und anderen Dingen. Eure Buchhalter müssen zwei Systeme kennen und beherrschen, und werden sich wahrscheinlich die Finger dabei brechen. 300 Rechnungen pro Tag sind für ein normales NAV- System kein wirkliches Problem.
Eine automatisierte Schnittstelle, die die Listung, Preispflege und Bestandsmeldung übernimmt, würde euch wahrscheinlich mehr helfen.

Gruß Fiddi

300 Rechnungen pro Tag sind wirklich kein Problem. Das sind pro Jahr 110.000 und in zehn Jahren gerade einmal 1,1Mio Belege.
Und in Zeiten des SQL-Servers sind auch 100GB Datenbanken kein Thema. Selbst wenn sie 500GB hätte ich persönlich kein Problem damit.

Unnützes Wissen:
Das Limit vom SQL Server sind übrigens 524 PB (Petabyte) pro DB.

News - Summenbuchungen sind aus - die Auditor haben da klar nein gesagt. Zwei Systeme zu pflegen: für E-Commerce eine Summendebitor pro Land reicht.

Datenbankgrösse:
Jetzt: Chef/Auditor: ich brauche so und so eine Auswertung. Ich: keine Problem, Artikelposten in Excel auskopieren, Pivo, fertig.
Dann: Chef/Auditor: ich brauche so und so eine Auswertung. Ich: na gut dann ich progammiere einen Bericht und melde mich morgen weil so einen Bericht haben wir zurzeit nicht.
Natürlich ich könnte für jede wichtige Postentabelle einen Excel-Buffer Bericht erstellen die pro Tag und pro wichtige Felder alles summiert und dann man kann das weiter pivotieren. Nur welche die wichtige Felder sind ist eher eine große Frage :)

DATEV: importiert nur Sachposten. Also die Artikelbuchungen muss man anders importieren. Ist kein Problem so eine Schnittstelle zu programmieren, aber es ist besser eine gut getestete Add-On zu kaufen und nicht Versuchskaninchen spielen...

Weiss nicht, wird vielleicht NAVConnector das Antwort.

Hallo,

News - Summenbuchungen sind aus - die Auditor haben da klar nein gesagt.

Das war sinvollerweise zu erwarten.

NAVConnect könnte so eine Antwort sein, es gibt da aber auch noch andere Anbieter, die eine Schnittstelle haben, man muss sich da den Funktionsumfang evtl. in Richtung Erweiterbarkeit auf andere Online- Anbieter anschauen.

Gruß Fiddi