We use cookies
We use cookies and similar technologies to improve your experience, analyse traffic, and personalise content. You can accept all cookies or reject non-essential ones.
Sobald die Bridge läuft, erreicht jede Verkaufsrechnung, die Sie in TallyPrime speichern, Ihren Kunden wenige Minuten später: über WhatsApp oder E-Mail mit einem PDF in Ihrem Branding oder als SMS mit dem Link. Dieselben Datensätze halten Ihre Kunden- und Lieferantenlisten aktuell, bringen Ihre Verkaufs-, Einkaufs- und Bestandszahlen auf Ihre Dashboards, treiben die Nachverfolgung bei Kunden mit offenem Saldo voran und füllen ein Portal in Ihrem eigenen Branding, in dem jeder Kunde seine eigenen Rechnungen und den offenen Saldo seines Kontos sieht. In dieser Anleitung legen Sie all das fest: welche Unternehmen und welche Tally-Datensatzarten — Verkaufsrechnungen, Eingangsrechnungen, Kunden, Lieferanten, Bankkonten, Lagerartikel — geteilt werden, wohin sie jeweils gehen, wie oft die Bridge nachsieht und was Ihr Flow, die Automatisierung, die Sie in SurveyAnalytica bauen, damit macht. Wenn die Bridge noch nicht auf dem PC ist, lesen Sie Tally Prime Connector — Installationsanleitung.
Alles steht in einer einzigen Textdatei, bridge.yml, neben sa-tally-bridge.exe — meist in C:\ProgramData\SurveyAnalytica. Klicken Sie sie mit der rechten Maustaste an, wählen Sie Öffnen mit (Open with) und dann Editor (Notepad). Es ist reiner Text im YAML-Format, in dem die Einrückung Bedeutung trägt.
Rücken Sie nur mit Leerzeichen ein, nie mit der Tabulatortaste, und behalten Sie die Einrückung der Zeilen bei, die Sie aus dieser Anleitung kopieren. Die Bridge startet mit einer Datei, die sie vollständig lesen kann; verrutscht eine Einrückung, nennt sie die Zeile, die zu korrigieren ist, und wartet auf die korrigierte Datei. Prüfen Sie Ihre Änderung, bevor Sie sie Windows überlassen — ein Befehl genügt.
Klicken Sie im Ordner mit bridge.yml in die Adressleiste des Datei-Explorers, tippen Sie cmd, drücken Sie die Eingabetaste und führen Sie dann sa-tally-bridge.exe run --config bridge.yml aus. Wenn der Zeitplan ausgegeben wird und das Programm weiterläuft, ist die Datei in Ordnung: Drücken Sie Ctrl+C und starten Sie die Bridge anschließend neu.
Die Bridge liest bridge.yml beim Start, eine gespeicherte Änderung wirkt also ab dem nächsten Start. Läuft sie noch in einem Eingabeaufforderungsfenster, drücken Sie dort Ctrl+C und starten Sie sie erneut. Sobald sie von selbst startet (Schritt 7 der Installationsanleitung), starten Sie sie über die Windows-Aufgabenplanung (Task Scheduler) neu: Öffnen Sie Aufgabenplanungsbibliothek → SurveyAnalytica → Tally Bridge, klicken Sie die Aufgabe mit der rechten Maustaste an und wählen Sie Beenden (End), dann erneut mit der rechten Maustaste und Ausführen (Run). Ab- und wieder anmelden bewirkt dasselbe: Die Aufgabe startet bei der Anmeldung.
Für die Ersteinrichtung nutzen Sie den Assistenten, sa-tally-bridge.exe init. Er beginnt jedes Mal mit einem leeren Blatt; spätere Änderungen nehmen Sie deshalb im Windows-Editor vor. Führen Sie jedes Unternehmen unter genau einem Schlüssel — dem Namen, den der Assistent eingetragen hat, oder seiner Ordnernummer — und behalten Sie diesen Schlüssel bei: Dort merkt sich die Bridge den Stand dieses Unternehmens, sodass jeder Lauf nur das Neue liest und jeder Datensatz genau einmal ankommt.
Der Block companies: listet die Unternehmen auf, die synchronisiert werden sollen, je einen Eintrag pro Unternehmen — so laufen mehrere Unternehmen oder Niederlassungen von dem einen Tally-PC aus. Jeder Eintrag hat einen frei wählbaren Schlüssel, der mit jedem Datensatz als companyCode ankommt; einen name, genau so geschrieben, wie Tally ihn schreibt; und einen Block transactions:, der die zu lesenden Datensatzarten nennt.
bridge.yml — der Block companies:
companies:
"010001":
name: "Acme Traders"
transactions:
sales: {}
purchase: {}
ledgers/debtors: {}
stockItems: {}
"010002":
name: "Globex Industries"
transactions:
sales: {}
ledgers/debtors: {}Jedes Beispiel hier ist ein Ausschnitt derselben Datei: global: und companies: kommen jeweils nur einmal vor; ergänzen Sie also nur die Zeilen, die Ihnen fehlen, mit derselben Einrückung. Die leeren geschweiften Klammern sind Absicht: Eine Datensatzart braucht nur dann Einstellungen, wenn sie ein eigenes Ziel hat — das ist der nächste Abschnitt. Die sieben Arten, Streams genannt:
| So schreiben Sie es | Was damit gesendet wird |
|---|---|
sales | Verkaufsrechnungen, eigene Belegarten eingeschlossen: Die Bridge fragt Tally, worauf jede Belegart beruht, sodass GST SALES als Verkauf eingeordnet wird. |
purchase | Eingangsrechnungen; eigene Belegarten werden genauso behandelt. |
ledgers/debtors | Kunden — jedes Konto unter Sundry Debtors (Debitoren), einschließlich Untergruppen. |
ledgers/creditors | Lieferanten — jedes Konto unter Sundry Creditors (Kreditoren). |
ledgers/bank | Bankkonten. |
ledgers | Der gesamte Kontenplan — Tausende von Zeilen. Für Kunden oder Lieferanten sind die enger gefassten Listen darüber treffender. |
stockItems | Lagerartikel, mit Schlussbestand, Wert und Preis. |
Kunden- und Lieferantendatensätze führen die Angaben des Geschäftspartners so mit, wie Tally sie hält — Mailing-Name, E-Mail, Telefon, Mobil, GSTIN, Steuernummer, Adresse und Schlusssaldo —, was eine Kontaktliste ohne erneutes Tippen aktuell hält. Verkaufs- und Einkaufsdatensätze führen den gesamten Beleg mit: Kopf, Lagerzeilen, Konten- und Steuerzeilen, Narration sowie die Angaben zur GST-E-Invoice (IRN, Bestätigungsnummer und -datum), wenn Tally sie hat.
Verkaufsrechnungen und Eingangsrechnungen, eigene Belegarten eingeschlossen; Kunden, Lieferanten, Bankkonten und, wenn Sie möchten, den vollständigen Kontenplan; Lagerartikel. Andere Belegarten — Zahlungseingänge, Zahlungen, Contra, Journale, Gut- und Lastschriften, Aufträge und Lieferscheine — liegen heute außerhalb des Funktionsumfangs des Connectors.
Jeder Datensatz geht an einen Flow, dessen Trigger ein Webhook ist — der, den Sie in Schritt 3 der Installationsanleitung gebaut haben, und so viele weitere, wie Sie möchten, jeder auf dieselbe Weise gebaut. Dieses Panel zeigt die beiden Werte, die Sie in bridge.yml übernehmen: die Zeilen URL : und KEY :, jede mit einer Schaltfläche zum Kopieren. Die URL-Zeile ist nach ihrem Platz benannt: webhook_url unter global:, unter einem Unternehmen und unter einer Datensatzart; url innerhalb von transaction_webhooks: und heartbeat:, mit dem Schlüssel als api_key daneben. Übernehmen Sie die Form aus dem Beispiel unten und verwenden Sie den Namen, der zu der Ebene gehört, die Sie gerade bearbeiten — genau diese Schreibweise liest die Bridge. Datensätze, die noch kein Ziel haben, warten sicher in der Warteschlange, bis eines gesetzt ist.
Gut zu wissen. Übernehmen Sie die URL genau so, wie das Panel sie zeigt; schränkt die Firewall in Ihrem Büro ausgehenden Verkehr ein, erlauben Sie ausgehendes HTTPS zu dem Hostnamen an ihrem Anfang. Der Schlüssel reist in einem Header namens code, und mehr braucht der Flow nicht: Lassen Sie die Felder HMAC Signature (Optional) leer.
Senden Sie alles an einen einzigen Flow, oder geben Sie einem Unternehmen oder einer Datensatzart einen eigenen.
bridge.yml — Teile der Blöcke global: und companies:
global:
webhook_url: "PASTE-THE-URL-FROM-THE-TRIGGER-PANEL"
api_key: "PASTE-THE-KEY-FROM-THE-TRIGGER-PANEL"
transaction_webhooks:
sales:
url: "PASTE-THE-SALES-FLOW-URL"
api_key: "PASTE-THE-SALES-FLOW-KEY"
ledgers/debtors:
url: "PASTE-THE-CONTACTS-FLOW-URL"
api_key: "PASTE-THE-CONTACTS-FLOW-KEY"
companies:
"010002":
name: "Globex Industries"
webhook_url: "PASTE-THE-GLOBEX-FLOW-URL"
api_key: "PASTE-THE-GLOBEX-FLOW-KEY"
transactions:
sales: {}Datensätze reisen in Gruppen, je Gruppe ein Unternehmen und eine Datensatzart. Für jede Gruppe nimmt die Bridge das erste ausgefüllte Ziel: dieses Unternehmen und diese Datensatzart, dann dieses Unternehmen, dann diese Datensatzart, dann der globale Fallback. Der Schlüssel reist mit der URL, neben die er geschrieben wurde, sodass jeder Flow mit seinem eigenen Schlüssel erreicht wird.
Tipp. Neu generieren unter dem Schlüssel erzeugt einen neuen KEY; der laufende Flow behält den bisherigen, bis ihn jemand veröffentlicht. Fügen Sie den neuen KEY danach in bridge.yml ein, starten Sie die Bridge neu und drücken Sie dann Live aktualisieren. Ein Live-Flow zeigt Live aktualisieren, ein nie eingeschalteter Flow Aktivieren. Alles, was währenddessen gesendet wird, wartet in der Warteschlange.
Die Bridge liest Tally entweder automatisch, alle paar Minuten, oder nach einem Zeitplan, zu Uhrzeiten, die Sie wählen — festgelegt im Block sync unter global. Ohne Block sync läuft sie automatisch, alle fünf Minuten.
Liest in einem festen Intervall — fünf Minuten, sofern Sie nichts anderes angeben — und einmal direkt nach dem Start, sodass Rechnungen innerhalb von Minuten nach der Erfassung in Ihrem Flow sind und noch am selben Tag bei Ihrem Kunden.
Liest nur zu den Zeiten, die Sie angeben, etwa um 21:30 Uhr jede Nacht. Dazwischen stellt sie überhaupt keine Anfragen an Tally, sodass der Arbeitstag Ihren Mitarbeitern gehört.
bridge.yml — im Block global:, automatisch
global:
sync:
mode: interval
every: 5mbridge.yml — im Block global:, zeitgesteuert
global:
sync:
mode: cron
cron: "30 21 * * *"
timezone: "Asia/Kolkata"| Einstellung | Standard | Was sie bewirkt |
|---|---|---|
mode | interval | Entweder interval oder cron. Eine Zeile cron ohne Modus wird als cron gelesen. |
every | 5m | Wie oft Tally im automatischen Modus gelesen wird: 30s, 5m, 2h. |
cron | keiner | Die Uhrzeiten im zeitgesteuerten Modus. Fünf Teile: Minute, Stunde, Tag des Monats, Monat, Wochentag. |
timezone | UTC | Die Zone, in der die cron-Zeiten gelesen werden, als Ortsname wie Asia/Kolkata. Setzen Sie sie, damit 21:30 Uhr auch zu Hause 21:30 Uhr ist. |
run_on_start | true | Einmal lesen, sobald die Bridge startet. Im zeitgesteuerten Modus nur auf einem PC, der noch keinen Lauf abgeschlossen hat. |
catch_up | true | Ist eine geplante Zeit vergangen, während der PC aus war, wird ein Lauf nachgeholt, sobald er zurück ist. |
catch_up_grace | 30m | Wie weit eine verpasste Zeit zurückliegen muss, damit sich ein Nachholen lohnt. |
retry_every | 15m | Wie oft erneut versucht wird, was in diesem Zyklus noch zu lesen ist. |
first_run_guard | 0 (aus) | Hält die allererste Synchronisation eines Unternehmens mit mehr Änderungen als dieser Zahl zurück, in beiden Modi, damit ein Lauf über die gesamte Historie nie in einer unbeaufsichtigten Nacht beginnt; diese Datensatzart zeigt needs_backfill, bis Sie den Wert wieder auf 0 setzen und sie laufen lassen. |
| So schreiben Sie es | Das bedeutet |
|---|---|
"30 21 * * *" | Täglich um 21:30 Uhr. Mit timezone: "Asia/Kolkata" um 21:30 Uhr IST. |
"0 19 * * 1-5" | Montag bis Freitag um 19:00 Uhr, am Wochenende nichts. |
"0 */2 * * *" | Alle zwei Stunden, zur vollen Stunde. |
Schreiben Sie fünf Teile, nicht sechs: Ein führender Sekundenteil würde aus "0 30 21 * * *" einen Lauf 30 Minuten nach jeder vollen Stunde machen. Die Bridge prüft den Ausdruck vor dem Start und gibt in einem Eingabeaufforderungsfenster global.sync.cron must have exactly 5 fields (minute hour day-of-month month day-of-week), got 6 in "0 30 21 * * *" aus — prüfen Sie einen neuen Zeitplan daher von Hand, wie oben beschrieben.
Eine geplante Zeit startet einen Zyklus. War ein Unternehmen nicht bereit — sein Anmeldedialog steht noch auf dem Desktop, oder Tally antwortet noch nicht —, behält die Bridge es auf der Liste und versucht es alle retry_every, standardmäßig alle Viertelstunde, erneut, bis es gelingt oder die nächste geplante Zeit kommt: Ein Unternehmen, das am nächsten Morgen um 09:40 Uhr geöffnet wird, synchronisiert um 09:40 Uhr.
War der PC über eine geplante Zeit hinweg aus, deckt ein einziger nachgeholter Lauf die Lücke ab: Drei verpasste Nächte kosten einen Lauf, denn die Bridge fragt alles ab, was sich seit dem letzten Blick geändert hat. Im zeitgesteuerten Modus hält ein Neustart den Termin ein, statt ihn vorzuziehen; wenn Sie Zahlen sofort brauchen, wechseln Sie für den Tag auf automatisch.
Hier werden Tally-Datensätze zu dem, was Sie eigentlich wollten: die Rechnung, die über WhatsApp oder E-Mail mit einem PDF in Ihrem Branding oder als SMS mit dem Link verschickt wird; Kunden- und Lieferantenlisten im Einklang mit Sundry Debtors und Creditors; ein laufendes Verkaufsregister in Google Sheets oder Excel; eine Feedback-Umfrage, sobald die Rechnung heraus ist; Erinnerungen an den Tagen, die Sie wählen, versendet von einem zeitgesteuerten Flow über eine Kontaktliste der Kunden mit offenem Saldo; Zahlen für Dashboards und Auswertungen; und ein Portal in Ihrem Branding, in dem Kunden ihre eigenen Rechnungen und den offenen Saldo ihres Kontos sehen.
sa-tally-bridge.exe test --config bridge.yml aus. Damit werden sofort rund zehn aktuelle Datensätze je Datensatzart gesendet.records. Alles darunter läuft nun einmal pro Datensatz, nicht einmal pro Gruppe.Warum diese Reihenfolge. Die Bridge geht von dem weiter, was sie bereits zugestellt hat; lassen Sie den Flow deshalb vor der großen ersten Ladung live gehen. Solange er nicht aktiv ist, bewahrt ein Flow das Eingehende als Testbeispiel auf — genau das brauchen die Schritte 2 und 3.
Tipp. Nutzen Sie je Unternehmen einen Weg — die Bridge oder die cloudseitige Tally-Datenquelle an einem Zeitplan-Trigger, nicht beides —, damit jeder Datensatz genau einmal ankommt.
| Aktion | Schleife nötig? |
|---|---|
| WhatsApp, SMS, Slack, Microsoft Teams, Social-Media-Beiträge | Ja. Eine Nachricht nach der anderen. |
| Google Sheets, Excel | Ja. Eine Zeile je Datensatz. |
| Kontaktliste, Planner, Umfrageantwort, Org-Benutzer, Shopify, Salesforce, Mailchimp | Ja. Jede schreibt einen einzelnen Datensatz. |
| Nein. Eine Vorlage kann eine Liste in sich selbst wiederholen — mehrere Rechnungen in einer Aufstellung; eine Schleife ergibt eine E-Mail je Rechnung. | |
| Dokument erstellen, Aufgabe | Nein. Beide arbeiten eine Liste ab, sodass ein Dokument eine ganze Gruppe abdecken kann. |
Wo eine Schleife nötig ist, sagt der Schritt das und bietet eine Schaltfläche Add Loop (Schleife hinzufügen) an.
Jede Anfrage ist eine dieser Gruppen — ein Batch aus einem Unternehmen und einer Datensatzart —, verpackt in sechs Feldern.
| Feld | Was darin steht |
|---|---|
companyCode | Der Schlüssel, den Sie unter companies: verwendet haben. |
companyName | Der Name des Unternehmens, so wie Tally ihn schreibt. |
transactionType | Die Datensatzart: sales, ledgers/debtors und so weiter. |
batchStart, batchTotal | Wo dieser Batch innerhalb von allem beginnt, was in diesem Zyklus gefunden wurde (0, dann 250, dann 500), und wie viele gefunden wurden. |
records | Die Datensätze selbst, bis zu 250 je Anfrage — das Array, über das Ihre Schleife iteriert. |
Innerhalb von records sind die Feldnamen Tallys eigene, in Großbuchstaben, und Ihre benutzerdefinierten Felder behalten ihre schlichten Namen. Jeder Wert ist Text, Beträge und Datumsangaben eingeschlossen, und ein in Tally leeres Feld fehlt in diesem Datensatz — bauen Sie jeden Schritt deshalb auf den Feldern auf, die Sie in Schritt 7 ausgewählt haben.
Eine Anfrage, gekürzt
{
"companyCode": "010001",
"companyName": "Acme Traders",
"transactionType": "sales",
"batchStart": 0,
"batchTotal": 312,
"records": [
{
"GUID": "0a1b2c3d-0000-4000-8000-000000000001-00000101",
"REMOTEID": "0a1b2c3d-0000-4000-8000-000000000001-00000101",
"DATE": "20250401",
"VOUCHERNUMBER": "101",
"VOUCHERTYPENAME": "GST SALES",
"PARTYLEDGERNAME": "Example Customer Pvt Ltd",
"AMOUNT": "5900.00",
"PARTYGSTIN": "29XXXXXXXXXX1Z5",
"ALLINVENTORYENTRIES": [
{
"STOCKITEMNAME": "Sample Item A",
"BILLEDQTY": "10 Nos.",
"RATE": "500.00/Nos.",
"AMOUNT": "5000.00"
}
]
}
]
}Das Feld, auf dem Sie aufbauen, ist GUID — Tallys dauerhafte Kennung für diesen Beleg oder dieses Konto — mit REMOTEID als Ersatzfeld, da manche Belege sie unter diesem Namen führen. Wenn jemand eine Rechnung bearbeitet, wenn ihre E-Invoice-Angaben später eintreffen oder wenn eine Antwort die Bridge nicht erreicht, wird der Datensatz unter derselben Kennung erneut gesendet. Gleichen Sie darauf ab und aktualisieren Sie, statt neu anzulegen: So bleibt eine Rechnung eine Zeile, in einer Tabelle, einem Dashboard oder im Portal.
Sie wählen, welche Unternehmen und welche Datensatzarten geteilt werden. Für diese reist der vollständige Beleg oder das vollständige Konto über eine verschlüsselte Verbindung: Namen des Geschäftspartners und Mailing-Namen, GSTIN, PAN, Postanschrift, E-Mail-Adresse, Telefon- und Mobilnummern, Artikelnamen, Preise, Steuerbeträge und Salden. Die meisten Firmen teilen ledgers/debtors und ledgers/creditors statt des gesamten Kontenplans; so bleibt das, was den PC verlässt, auf die Geschäftspartner beschränkt, mit denen Sie tatsächlich Geschäfte machen.
Datensätze reisen, wenn sich etwas geändert hat; eine ruhige Nacht ist also ruhig, weil es so gedacht ist. Für eine ausdrückliche Bestätigung sendet der Statusbericht nach jedem Lauf eine Zusammenfassung an einen eigenen Flow, mit dessen URL und KEY. Ergänzen Sie ihn von Hand:
bridge.yml — im Block global:
global:
heartbeat:
url: "PASTE-THE-STATUS-FLOW-URL"
api_key: "PASTE-THE-STATUS-FLOW-KEY"Jeder Bericht führt outcome (success, partial oder blocked), blockedReason (gateway_error, gateway_empty, no_companies), outboxDepth, recordsEnqueued, pendingStreams, nextFireAt und hostname mit. Die nützlichste Meldung: Lassen Sie sich bei einem nächtlichen Zeitplan benachrichtigen, wenn von einem Rechner 26 Stunden lang kein Bericht eingegangen ist.
Öffnen Sie auf dem Tally-PC wie oben eine Eingabeaufforderung in diesem Ordner und führen Sie aus:
Eingabeaufforderung
sa-tally-bridge.exe status --config bridge.ymlWas ausgegeben wird
sa-tally-bridge [version] on TALLY-PC
Schedule : cron "30 21 * * *" (Asia/Kolkata)
Last run : Sat, 15 Aug 2026 21:30:04 IST → 21:34:11 (partial)
Next run : Sat, 15 Aug 2026 21:45:04 IST
Records : 312 enqueued last run; outbox depth 0
Pending : 1 stream(s) awaiting retry
- Globex Industries / sales : company_closed
ok Acme Traders / sales : synced (watermark 260321/260409, 312 records)
ok Acme Traders / stockItems : up_to_date (watermark 8821/8821, 0 records)Eine Zeile Blocked : erscheint zwischen Last run und Next run, wenn ein ganzer Lauf blockiert war. outbox depth zählt die Batches, die noch zuzustellen sind; 0 ist der gewünschte Wert. watermark 260321/260409 ist das Lesezeichen in schlichten Zahlen: die Änderungsnummer, bis zu der gelesen wurde, dann die aktuelle Änderungsnummer des Unternehmens — stimmen sie überein, ist alles drin. status berichtet vom zuletzt abgeschlossenen Lauf.
| Status | Bedeutung | Erneuter Versuch? |
|---|---|---|
synced | Neue oder geänderte Datensätze wurden gelesen und zum Senden in die Warteschlange gestellt. | Erledigt |
up_to_date | Tally hat geantwortet und nichts hat sich geändert: der gesunde Ruhezustand. | Erledigt |
company_closed | Dieses Unternehmen ist in TallyPrime nicht geöffnet, meist wartet ein Anmeldedialog auf dem Desktop. | Ja |
type_map_failed | Die Liste der Belegarten wurde diesmal nicht gelesen; die Bridge hat diesen Stream deshalb zurückgehalten, statt Ihre eigenen Belegarten unter der falschen Überschrift einzuordnen. | Ja |
no_counter | Das Unternehmen hat diesmal keinen Änderungszähler gemeldet. | Ja |
needs_backfill | Eine allererste Synchronisation, zurückgehalten durch first_run_guard. Wird von sa-tally-bridge.exe status --config bridge.yml --json aufgeführt. | Nein |
error | Ein Versuch wurde nicht abgeschlossen; der Grund ist festgehalten und das Lesezeichen blieb stehen, sodass diese Datensätze beim nächsten Mal kommen. | Ja |
status ausgibt..1 bis .5. Das Erste, was Sie dem Support schicken.| Was Sie sehen | Was es bedeutet | Was zu tun ist |
|---|---|---|
| Alles zugestellt, aber der Flow wird noch nicht tätig. | Der Flow ist gespeichert, aber nicht aktiviert oder pausiert; das bisher Eingegangene wird deshalb als sein Testbeispiel aufbewahrt. | Öffnen Sie den Flow und drücken Sie Aktivieren. Die nächste Synchronisation wird vollständig verarbeitet. |
outbox depth steigt weiter. | Der Flow nimmt diese Batches noch nicht an: ein KEY, der inzwischen ersetzt wurde, eine URL aus einem anderen Flow oder eine von Hand ergänzte Datensatzart, die noch kein Ziel hat. | Kopieren Sie URL : und KEY : erneut aus dem Panel und starten Sie die Bridge neu; prüfen Sie, ob die Datensatzart eine eigene URL hat oder ob webhook_url unter global: ausgefüllt ist. Alles wartet währenddessen sicher in der Warteschlange. |
Ein Unternehmen zeigt immer company_closed. | Es ist in TallyPrime nicht geöffnet, meist weil sein Anmeldedialog wartet. | Öffnen Sie dieses Unternehmen im Tally-Fenster und geben Sie dort sein Passwort ein. Die Bridge nimmt es beim nächsten Versuch auf. |
Blocked : gateway_error oder gateway_empty, und jedes Unternehmen company_closed. | Tally antwortet noch nicht oder hat geantwortet, ohne dass ein Unternehmen geöffnet ist; die Zeile Blocked ist die maßgebliche. (gateway ist das eigene Wort der Bridge für Tallys Verbindung über Port 9000.) | Schauen Sie ins Tally-Fenster: Starten Sie Tally, oder erledigen Sie den dort wartenden Dialog. |
companyName oder batchTotal unterhalb der Schleife leer. | Der Schalter Include parent fields in each entry der Schleife ist ausgeschaltet. | Öffnen Sie den Schleifenschritt und schalten Sie ihn ein. |
| Die Zustellung hat aufgehört, nachdem jemand Neu generieren gedrückt hat. | Ein neuer KEY wurde ausgestellt und der Flow veröffentlicht; der Flow erwartet nun diesen KEY. | Kopieren Sie den neuen KEY in bridge.yml, starten Sie die Bridge neu und drücken Sie dann Live aktualisieren. |
| Keine Datensätze, seit der PC neu gestartet wurde. | Die Bridge läuft in Ihrer angemeldeten Windows-Sitzung, und Tally braucht seine Unternehmen geöffnet. | Melden Sie sich an und öffnen Sie die Unternehmen; die Bridge nimmt ihre Arbeit rund eine Minute später wieder auf. Auf einem PC, an dem niemand sitzt, schalten Sie die automatische Windows-Anmeldung ein, dann kommt sie von selbst zurück. |
| Datensätze kommen doppelt an. | Das ältere Tally-Add-on ist noch geladen; oder das Unternehmen ist zusätzlich eine Tally-Datenquelle an einem Zeitplan-Trigger; oder es ist zweimal unter zwei Schlüsseln aufgeführt. | Behalten Sie den einen Weg, den Sie möchten, entfernen Sie den anderen und starten Sie die Bridge neu. |
synced mit Records : 0. | Geändert haben sich in diesem Zyklus Belegarten außerhalb des Funktionsumfangs des Connectors, etwa Zahlungseingänge. | Nichts zu tun: Verkaufs- und Einkaufsdatensätze sind aktuell. |
Zuverlässigkeit, in drei Zeilen.
Wiederherstellungspunkt (RPO): praktisch null. Tally bleibt Ihr führendes System, und das Lesezeichen eines Unternehmens rückt erst weiter, wenn diese Datensätze sicher in der Warteschlange auf der Festplatte liegen — was also in den von Ihnen gewählten Unternehmen und Datensatzarten erfasst wurde, während Internet, PC oder Bridge nicht verfügbar waren, wird beim nächsten Lauf mitgenommen; nichts muss neu erfasst werden.
Wiederherstellungszeit (RTO): von Ihrem PC bestimmt. Es gibt kein Wiederherstellungsverfahren: Sobald Windows angemeldet ist und Tally seine Unternehmen geöffnet hat, nimmt die Bridge rund eine Minute später von selbst ihre Arbeit wieder auf, holt jede vergangene geplante Zeit nach und versucht es bei jedem Unternehmen, das nicht geöffnet war, alle 15 Minuten erneut.
Verfügbarkeit: Windows startet sie bei der Anmeldung und startet sie erneut — drei Versuche im Abstand von einer Minute —, falls sie je stehen bleibt. Ausführlicher: Zuverlässigkeit auf einen Blick.
sa-tally-bridge.exe test so oft verwenden, wie Sie möchten: Es rückt kein Lesezeichen weiter und ändert nichts an dem, was Sie bereits synchronisiert haben.HTTPS_PROXY für das Windows-Konto, unter dem die Bridge läuft — etwa http://proxy.example.local:8080 — und starten sie neu.up_to_date zeigt.