Tally-Anbindung für Individualsoftware, richtig gemacht

Fast jedes System, das wir für ein indisches Unternehmen bauen, endet am selben Punkt: Die Buchhaltung liegt in Tally, und der Buchhalter wechselt nicht. Das ist meist die richtige Entscheidung. Tally kennt der Buchhalter, Tally erwartet der Prüfer, und in Tally werden die Steuermeldungen erstellt. Aufgabe eines individuellen Systems ist es, Tally sauber zu beliefern, nicht es zu ersetzen.

Ob das neue System dem Buchhalter Zeit spart oder ihm Arbeit macht, entscheidet sich fast vollständig daran, wie diese Verbindung gestaltet ist.

Wie Daten in Tally gelangen

1. XML über HTTPTallyPrime kann auf dem Rechner, auf dem es installiert ist, als Server laufen – standardmäßig auf Port 9000 – und XML-Anfragen annehmen, die Stammdaten und Belege anlegen oder Berichte exportieren. Das ist der direkteste Weg und der, den die meisten Integrationen nutzen. Dafür muss Tally laufen und die Firma geöffnet sein.
2. DateiimportBelege und Stammdaten werden als XML-Dateien vorbereitet und vom Buchhalter importiert. Langsamer, aber es bleibt ein Mensch beteiligt, und es funktioniert auch dort, wo der Tally-Rechner gar nicht erreichbar ist.
3. ODBCTally stellt seine Daten auch über ODBC bereit, was praktisch ist, um Berichte in ein anderes System einzulesen. Es ist ein Weg zum Lesen, nicht zum Schreiben von Buchungen.
4. Anpassung mit TDLTallys eigene Definitionssprache kann Felder und Berichte innerhalb von Tally ergänzen. Das ist nützlich, aber es ist Code, der über Tally-Versionen hinweg gepflegt werden muss, daher halten wir ihn auf dem Minimum, das die Aufgabe braucht.

Wenn Tally auf einem Büro-PC läuft

Tally läuft meist auf einem Rechner im Büro, eine Webanwendung auf einem Server anderswo. Die beiden können sich nicht einfach gegenseitig aufrufen, und man sollte sie auch nicht dazu zwingen. Das verlässliche Muster ist ein kleiner Connector auf dem Tally-Rechner, der die Webanwendung nach offenen Buchungen fragt, sie lokal in Tally bucht und zurückmeldet, was passiert ist. Die Verbindung geht nur nach außen, also ist im Büro nichts offen erreichbar.

Stammdaten vor Belegen

Ein Beleg verweist auf Konten, Artikel, Lager und Kostenstellen über deren Namen. Stimmt ein Name nicht exakt mit den Stammdaten in Tally überein, schlägt der Import fehl – oder schlimmer, er landet auf dem falschen Stammsatz. Die Integration muss daher eine Zuordnung führen: Jeder Geschäftspartner, jeder Artikel und jedes Konto im neuen System ist mit seinem Stammsatz in Tally verknüpft.

Auch neue Stammdaten brauchen eine Regel. Entweder legt die Integration sie nach vereinbarten Konventionen an, oder sie hält die Buchung zurück und fragt den Buchhalter. Was nie passieren darf: dass abweichende Schreibweisen – ein Punkt am Ende, eine geänderte Abkürzung – stillschweigend ein zweites Konto für denselben Geschäftspartner anlegen.

Nie doppelt buchen

Der häufigste Integrationsfehler ist der doppelte Beleg. Tally nimmt eine Buchung an, das Netz bricht ab, bevor die Antwort ankommt, und das System sendet sie erneut. Beide Kopien stehen in den Büchern, und die Summen sind auf eine Weise falsch, deren Suche einen Nachmittag kostet.

1. Eine feste Kennung für jede BuchungJeder Beleg trägt eine Kennung aus dem Quellsystem, und die Integration prüft sie, bevor sie etwas anlegt. Wird dieselbe Buchung zweimal gesendet, wird sie dann aktualisiert oder übersprungen, statt ein zweites Mal angelegt.
2. Ein BuchungsprotokollJeder Versuch wird mit dem Gesendeten und Tallys Antwort festgehalten, sodass sich eine fehlende oder doppelte Buchung in Minuten nachverfolgen lässt, statt sie mühsam zu rekonstruieren.
3. AbgleichEin regelmäßiger Vergleich der Summen pro Tag und pro Konto zwischen beiden Systemen, der die Fälle findet, die damals niemand bemerkt hat.
4. Umsichtige WiederholungenVerbindungsfehler werden automatisch wiederholt. Was Tally abgelehnt hat, geht mit dem Grund an eine Person, statt so lange wiederholt zu werden, bis es an der falschen Stelle landet.

Einzeln oder zusammengefasst

Nicht jede Transaktion gehört als eigener Beleg in Tally. Die Wahl hängt von der Transaktionsart ab und sollte mit dem Buchhalter getroffen werden, nicht für ihn.

• Verkaufsrechnungen werden meist einzeln gebucht, denn wo die Steuermeldungen aus Tally erstellt werden, müssen die Details auf Rechnungsebene vorhanden sein.
• Die Lohnabrechnung wird meist als eine geprüfte Sammelbuchung pro Monat gebucht, nach Kostenstellen aufgeteilt, statt eines Belegs pro Mitarbeiter.
• Kasseneinnahmen in großer Zahl werden oft als Tageszusammenfassung je Zahlungsart gebucht, während die Details im Quellsystem bleiben.
• Lagerbewegungen hängen davon ab, ob der Bestand überhaupt in Tally bewertet wird. Führt das neue System die Lagerhaltung, braucht Tally oft nur die buchhalterische Wirkung.

Die GST-Details, an denen Meldungen scheitern

• GSTIN, Leistungsort und HSN oder SAC auf jeder Zeile, sodass jeder Beleg ohne Nacharbeit in Tally für die Steuermeldungen vollständig ist.
• Steuerkonten nach Satz und Art zugeordnet, CGST und SGST getrennt von IGST, statt eines einzigen Steuerkontos für alles.
• In beiden Systemen wird gleich gerundet. Sonst weichen die Summen um eine Rupie ab, und danach traut niemand mehr einem der beiden.
• Gutschriften sind mit der Rechnung verknüpft, die sie korrigieren, statt als freistehende negative Buchungen gebucht zu werden.
• Ein Beleg mit Datum in einer abgeschlossenen Periode wird von der Integration abgelehnt, statt stillschweigend in einen Monat gebucht zu werden, den der Buchhalter bereits abgeschlossen hat.

Zoho Books und andere Buchhaltungen

Zoho Books hat eine dokumentierte REST-API, womit das Problem mit dem Büro-PC ganz entfällt. Alles andere in diesem Artikel gilt trotzdem: die Zuordnung der Stammdaten, eine feste Kennung für jede Buchung, das Buchungsprotokoll und der Abgleich. Sie machen eine Integration mit jeder Buchhaltung vertrauenswürdig, und sie werden am häufigsten weggelassen.