Help

Con il bridge in funzione, ogni fattura di vendita che salvi in TallyPrime può arrivare al tuo cliente pochi minuti dopo: su WhatsApp o via email, in PDF con il tuo marchio, oppure come SMS con il link. Gli stessi record tengono aggiornate le liste di clienti e fornitori, portano i dati di vendite, acquisti e magazzino nelle tue dashboard, alimentano i solleciti ai clienti con un saldo aperto e riempiono un portale con il tuo marchio, dove ogni cliente vede le proprie fatture e il saldo aperto sul suo conto. Questa guida è il punto in cui decidi tutto: quali aziende e quali tipi di record Tally — fatture di vendita, fatture di acquisto, clienti, fornitori, conti bancari, articoli di magazzino — vengono condivisi, dove va ciascuno, ogni quanto il bridge legge e che cosa ne fa il tuo flusso, l’automazione che costruisci in SurveyAnalytica. Se il bridge non è ancora sul PC, consulta il Connettore Tally Prime — Guida all’installazione.

Dove si trovano le impostazioni

Tutto si trova in un unico file di testo, bridge.yml, accanto a sa-tally-bridge.exe — di solito in C:\ProgramData\SurveyAnalytica. Fai clic destro sul file, scegli Apri con (Open with), poi Blocco note (Notepad). È testo semplice in formato YAML, dove l’indentazione ha valore.

Indenta solo con spazi, mai con il tasto Tab e mantieni l’indentazione delle righe che copi da questa guida. Il bridge parte da un file che riesce a leggere per intero; se un’indentazione non torna, indica la riga da correggere e attende il file corretto. Verifica la tua modifica prima di affidarla a Windows — basta un comando.

Nella cartella che contiene bridge.yml, fai clic sulla barra degli indirizzi di Esplora file (File Explorer), digita cmd, premi Invio, poi esegui sa-tally-bridge.exe run --config bridge.yml. Se stampa la sua pianificazione e resta in esecuzione, il file è a posto: premi Ctrl+C, poi riavvia il bridge.

Applicare una modifica

Il bridge legge bridge.yml all’avvio, quindi una modifica salvata ha effetto al riavvio successivo. Se è ancora in esecuzione in una finestra del Prompt dei comandi (Command Prompt), premi lì Ctrl+C e avvialo di nuovo. Quando parte da solo (Passaggio 7 della Guida all’installazione), riavvialo dall’Utilità di pianificazione (Task Scheduler) di Windows: apri Libreria Utilità di pianificazione → SurveyAnalytica → Tally Bridge, fai clic destro sull’attività e scegli Termina (End), poi fai di nuovo clic destro e scegli Esegui (Run). Disconnettersi e rientrare ha lo stesso effetto: l’attività parte all’accesso.

La procedura guidata, o Blocco note

Usa la procedura guidata, sa-tally-bridge.exe init, per la prima configurazione. Ogni volta riparte da zero, quindi fai le modifiche successive in Blocco note. Tieni ogni azienda sotto un’unica chiave — il nome scritto dalla procedura guidata oppure il numero della sua cartella — e mantieni quella chiave: è lì che il bridge conserva il punto raggiunto per quell’azienda, così ogni esecuzione legge solo le novità e ogni record arriva una volta sola.

Aziende e tipi di record

Il blocco companies: elenca le aziende da sincronizzare, una voce ciascuna, così più aziende o filiali funzionano da un solo PC con Tally. Ogni voce ha una chiave scelta da te, che arriva con ogni record come companyCode; un name scritto esattamente come lo scrive Tally; e un blocco transactions: che indica i tipi di record da leggere.

bridge.yml — il blocco companies:

companies:
  "010001":
    name: "Acme Traders"
    transactions:
      sales: {}
      purchase: {}
      ledgers/debtors: {}
      stockItems: {}

  "010002":
    name: "Globex Industries"
    transactions:
      sales: {}
      ledgers/debtors: {}

Ogni esempio qui è un pezzo dello stesso file: global: e companies: compaiono una volta sola ciascuno, quindi aggiungi solo le righe che ti mancano, alla stessa indentazione. Le parentesi graffe vuote sono volute: un tipo di record ha bisogno di impostazioni solo quando ha una destinazione propria, cioè la sezione successiva. I sette tipi, chiamati stream:

Scrivi questo	Che cosa invia
`sales`	Fatture di vendita, compresi i tuoi tipi di voucher personalizzati: il bridge chiede a Tally su che cosa si basa ogni tipo, così `GST SALES` viene registrato come vendita.
`purchase`	Fatture di acquisto; i tipi di voucher personalizzati sono gestiti allo stesso modo.
`ledgers/debtors`	Clienti — ogni ledger sotto Sundry Debtors, sottogruppi inclusi.
`ledgers/creditors`	Fornitori — ogni ledger sotto Sundry Creditors.
`ledgers/bank`	Conti bancari.
`ledgers`	L’intero piano dei conti — migliaia di righe. Per clienti o fornitori, le liste mirate qui sopra sono più precise.
`stockItems`	Articoli di magazzino, con quantità, valore e prezzo di chiusura.

I record di clienti e fornitori portano i dati dell’anagrafica così come Tally li conserva — mailing name, email, telefono, cellulare, GSTIN, numero di identificazione fiscale, indirizzo e saldo di chiusura — e tengono aggiornata una lista contatti senza riscrivere nulla. I record di vendita e acquisto portano l’intero voucher: testata, righe di magazzino, righe di ledger e di imposta, narration e i dati della e-invoice GST (IRN, numero e data di acknowledgement) quando Tally li ha.

Che cosa copre il connettore

Fatture di vendita e fatture di acquisto, compresi i tuoi tipi di voucher personalizzati; clienti, fornitori, conti bancari e, se lo desideri, l’intero piano dei conti; articoli di magazzino. Gli altri tipi di voucher — incassi, pagamenti, contra, scritture di giornale, note di credito e di debito, ordini e documenti di trasporto — oggi sono fuori dall’ambito del connettore.

Dove va ogni record

Ogni record va a un flusso il cui trigger è un Webhook — quello che hai creato al Passaggio 3 della Guida all’installazione, e tutti quelli che vuoi in più, ciascuno costruito allo stesso modo. Quel pannello mostra i due valori da copiare in bridge.yml: le righe URL : e KEY :, ognuna con un pulsante di copia. La riga dell’URL prende il nome dal punto in cui si trova: webhook_url sotto global:, sotto un’azienda e sotto un tipo di record; url dentro transaction_webhooks: e heartbeat:, con la chiave come api_key accanto. Copia la struttura dall’esempio qui sotto, usando il nome che appartiene al livello che stai modificando — è quella la grafia che il bridge legge. I record che non hanno ancora una destinazione restano al sicuro in coda finché non ne imposti una.

Buono a sapersi. Copia l’URL esattamente come lo mostra il pannello; se il firewall dell’ufficio limita il traffico in uscita, consenti l’HTTPS in uscita verso il nome host all’inizio dell’URL. La chiave viaggia in un header chiamato code ed è tutto ciò che serve al flusso: lascia vuoti i campi HMAC Signature (Optional) (firma HMAC, facoltativa).

Invia tutto a un solo flusso, oppure assegna un flusso dedicato a un’azienda o a un tipo di record.

bridge.yml — parti dei blocchi global: e 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: {}

Quale destinazione prevale

I record viaggiano in gruppi: un gruppo per ogni azienda e tipo di record. Per ogni gruppo il bridge prende la prima destinazione compilata: questa azienda e questo tipo di record, poi questa azienda, poi questo tipo di record, poi il fallback globale. La chiave viaggia insieme all’URL accanto al quale è scritta, così ogni flusso viene raggiunto con la propria chiave.

Fatture, acquisti e aggiornamento dei clienti possono avere ciascuno il proprio flusso, URL e KEY. Per ogni gruppo di record il bridge prende la prima destinazione della scala.

Generare una nuova KEY

Suggerimento. Genera nuovo, sotto la chiave, emette una nuova KEY; il flusso in esecuzione mantiene quella attuale finché qualcuno non lo pubblica. Dopo averla usata, incolla la nuova KEY in bridge.yml, riavvia il bridge, poi premi Aggiorna versione live. (Un flusso già live mostra Aggiorna versione live; uno mai attivato mostra Attiva, il pulsante di attivazione.) Tutto ciò che viene inviato nel frattempo resta in coda.

Sincronizzazione automatica o pianificata

Il bridge legge Tally in modo automatico, ogni pochi minuti, oppure su pianificazione, agli orari che scegli tu — si imposta nel blocco sync sotto global. Senza blocco sync è automatico, ogni cinque minuti.

Automatica

Legge a intervallo fisso — cinque minuti, se non indichi altro — e una volta appena parte, così le fatture arrivano al tuo flusso pochi minuti dopo essere state registrate e al tuo cliente lo stesso giorno.

Pianificata

Legge solo agli orari che indichi, per esempio alle 21:30 ogni sera. Nel frattempo non fa alcuna richiesta a Tally, così la giornata lavorativa resta ai tuoi collaboratori.

bridge.yml — dentro il blocco global:, automatica

global:
  sync:
    mode: interval
    every: 5m

bridge.yml — dentro il blocco global:, pianificata

global:
  sync:
    mode: cron
    cron: "30 21 * * *"
    timezone: "Asia/Kolkata"

L’automatica legge a intervallo fisso e all’avvio; la pianificata legge agli orari che imposti.

Tutte le impostazioni del blocco sync

Impostazione	Predefinito	Che cosa fa
`mode`	`interval`	`interval` oppure `cron`. Una riga `cron` senza mode viene letta come `cron`.
`every`	`5m`	Ogni quanto leggere Tally in modalità automatica: `30s`, `5m`, `2h`.
`cron`	nessuno	Gli orari in modalità pianificata. Cinque parti: minuto, ora, giorno del mese, mese, giorno della settimana.
`timezone`	`UTC`	Il fuso in cui vengono letti gli orari cron, come nome di località, per esempio `Asia/Kolkata`. Impostalo, così le 21:30 sono le 21:30 da te.
`run_on_start`	`true`	Legge una volta appena il bridge parte. In modalità pianificata, solo su un PC che non ha ancora completato un’esecuzione.
`catch_up`	`true`	Se un orario pianificato è passato mentre il PC era spento, esegue una lettura quando il PC torna disponibile.
`catch_up_grace`	`30m`	Quanto deve essere arretrato un orario mancato perché valga la pena fare un’esecuzione di recupero.
`retry_every`	`15m`	Ogni quanto riprovare ciò che resta da leggere in questo ciclo.
`first_run_guard`	`0` (disattivato)	Trattiene la primissima sincronizzazione di un’azienda con più modifiche di questo numero, in entrambe le modalità, così una lettura dell’intero storico non parte mai in una notte non presidiata; quel tipo di record riporta `needs_backfill` finché non riporti questo valore a `0` e lo lasci eseguire.

Esempi di cron

Scrivi questo	Significato
`"30 21 * * *"`	Ogni giorno alle 21:30. Con `timezone: "Asia/Kolkata"`, le 21:30 IST.
`"0 19 * * 1-5"`	Dal lunedì al venerdì alle 19:00, nulla nel fine settimana.
`"0 /2 * *"`	Ogni due ore, allo scoccare dell’ora.

Scrivi cinque parti, non sei: una parte iniziale per i secondi trasformerebbe "0 30 21 * * *" in una lettura al minuto 30 di ogni ora. Il bridge controlla l’espressione prima di partire e stampa global.sync.cron must have exactly 5 fields (minute hour day-of-month month day-of-week), got 6 in "0 30 21 * * *" in una finestra del Prompt dei comandi — quindi verifica a mano una nuova pianificazione, come sopra.

Nuovi tentativi e recupero

Un orario pianificato avvia un ciclo. Se un’azienda non era pronta — la sua richiesta di login ancora aperta sul desktop, oppure Tally che non risponde ancora — il bridge la tiene in elenco e riprova ogni retry_every, un quarto d’ora per impostazione predefinita, finché non ci riesce o arriva l’orario pianificato successivo: un’azienda aperta alle 09:40 del mattino dopo si sincronizza alle 09:40.

Se il PC era spento a un orario pianificato, una sola esecuzione di recupero copre l’intervallo: tre notti mancate costano una sola esecuzione, perché il bridge chiede tutto ciò che è cambiato dall’ultima volta. In modalità pianificata un riavvio mantiene l’appuntamento invece di anticiparlo; se ti servono i dati subito, passa all’automatica per la giornata.

Trasformare i record in risultati

Qui i record di Tally diventano ciò che volevi: la fattura inviata su WhatsApp o via email, in PDF con il tuo marchio, oppure come SMS con il link; liste di clienti e fornitori allineate a Sundry Debtors e Creditors; un registro delle vendite sempre aggiornato in Google Sheets o Excel; un questionario di gradimento appena la fattura è partita; solleciti nei giorni che scegli, inviati da un flusso pianificato su una lista contatti dei clienti con un saldo aperto; i dati per dashboard e analisi; e un portale con il tuo marchio dove i clienti vedono le proprie fatture e il saldo aperto sul loro conto.

Sul PC con Tally, apri un Prompt dei comandi in quella cartella, come sopra, ed esegui sa-tally-bridge.exe test --config bridge.yml. Invia subito una decina di record recenti per ogni tipo di record.
Nel pannello del trigger Webhook del flusso, premi Controlla lo stato. Recupera una sola volta l’ultimo esempio arrivato — ecco perché il test viene prima. L’esempio compare sopra il pulsante, lì accorciato se è molto grande, mentre l’esecuzione vera porta tutto.
Premi Applica. I campi di quell’esempio diventano i campi utilizzabili dal flusso.
Aggiungi un passaggio e imposta il suo Tipo di componente su loop, in minuscolo nell’elenco.
Nel passaggio loop, imposta Array field to iterate (campo array da iterare) su records. Tutto ciò che sta sotto viene ora eseguito una volta per record, non una volta per gruppo.
Se i passaggi sottostanti hanno bisogno dei dati del gruppo — nome dell’azienda, tipo di record — attiva Include parent fields in each entry (includi i campi del gruppo in ogni voce), disattivato per impostazione predefinita.
Su ogni passaggio sotto il loop, premi il pulsante 1. Configura campi e scegli i campi che usa.
Premi Attiva, così ogni fattura viene elaborata fin dalla primissima sincronizzazione.

Perché in quest’ordine. Il bridge avanza a partire da ciò che ha già consegnato, quindi porta il flusso in live prima del grande carico iniziale. Finché non è attivo, il flusso conserva ciò che arriva come esempio di test — ed è proprio ciò che serve ai passaggi 2 e 3.

Suggerimento. Usa un solo percorso per azienda — il bridge oppure l’origine dati Tally lato cloud con un trigger Programma, non entrambi — così ogni record arriva una volta sola.

Azioni che richiedono un loop

Azione	Serve un loop?
WhatsApp, SMS, Slack, Microsoft Teams, post sui social	Sì. Un messaggio alla volta.
Google Sheets, Excel	Sì. Una riga per record.
Lista contatti, Planner, Risposta al questionario, Utente dell’organizzazione, Shopify, Salesforce, Mailchimp	Sì. Ognuna scrive un singolo record.
Email	No. Un modello può ripetere un elenco al suo interno — più fatture in un unico estratto conto; con un loop si ottiene una email per fattura.
Crea documento, Attività	No. Entrambe lavorano su un elenco, quindi un solo documento può coprire un intero gruppo.

Dove serve un loop, il passaggio lo segnala e propone un pulsante Add Loop (aggiungi loop).

Che cosa invia il bridge

Ogni richiesta è uno di quei gruppi — un batch, da un’azienda e un tipo di record — racchiuso in sei campi.

Campo	Che cosa contiene
`companyCode`	La chiave che hai usato sotto `companies:`.
`companyName`	Il nome dell’azienda come lo scrive Tally.
`transactionType`	Il tipo di record: `sales`, `ledgers/debtors` e così via.
`batchStart`, `batchTotal`	Da dove comincia questo batch all’interno di tutto ciò che è stato trovato nel ciclo (0, poi 250, poi 500), e quanti ne sono stati trovati.
`records`	I record veri e propri, fino a 250 per richiesta — l’array che il tuo loop itera.

Dentro records i nomi dei campi sono quelli di Tally, in maiuscolo, e i tuoi campi personalizzati mantengono il loro nome così com’è. Ogni valore è testo, importi e date compresi, e un campo vuoto in Tally non compare in quel record — quindi costruisci ogni passaggio sui campi che hai scelto al passaggio 7.

Una richiesta, in forma ridotta

{
  "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"
        }
      ]
    }
  ]
}

Il campo su cui costruire è GUID — l’identificatore permanente che Tally assegna a quel voucher o ledger — con REMOTEID come alternativa, perché alcuni voucher lo riportano sotto quel nome. Quando qualcuno modifica una fattura, quando i dati della e-invoice arrivano più tardi o quando una risposta non raggiunge il bridge, il record viene inviato di nuovo con lo stesso identificatore. Confrontalo e aggiorna invece di aggiungere: così una fattura resta una riga sola, in un foglio, in una dashboard o nel portale.

Le tue informazioni

Sei tu a scegliere quali aziende e quali tipi di record vengono condivisi. Per quelli, l’intero voucher o ledger viaggia su una connessione cifrata: ragione sociale e mailing name, GSTIN, PAN, indirizzo postale, email, numeri di telefono e cellulare, nomi degli articoli, prezzi, importi delle imposte e saldi. La maggior parte delle aziende condivide ledgers/debtors e ledgers/creditors invece dell’intero piano dei conti: così ciò che esce dal PC riguarda solo le controparti con cui lavori davvero.

Facoltativo: un report di stato dopo ogni esecuzione

I record viaggiano quando qualcosa è cambiato, quindi una notte tranquilla è tranquilla per scelta. Per avere una conferma esplicita, il report di stato invia un riepilogo a un flusso dedicato dopo ogni esecuzione, con l’URL e la KEY di quel flusso. Aggiungilo a mano:

bridge.yml — dentro il blocco global:

global:
  heartbeat:
    url: "PASTE-THE-STATUS-FLOW-URL"
    api_key: "PASTE-THE-STATUS-FLOW-KEY"

Ogni report porta outcome (success, partial o blocked), blockedReason (gateway_error, gateway_empty, no_companies), outboxDepth, recordsEnqueued, pendingStreams, nextFireAt e hostname. L’avviso più utile: con una pianificazione notturna, segnala se da una macchina non arriva alcun report da 26 ore.

Verificare che funzioni

Sul PC con Tally, apri un Prompt dei comandi in quella cartella, come sopra, ed esegui:

Prompt dei comandi

sa-tally-bridge.exe status --config bridge.yml

Che cosa stampa

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)

Una riga Blocked : compare tra Last run e Next run quando un’intera esecuzione è stata bloccata. outbox depth conta i batch ancora da consegnare; il valore che vuoi è 0. watermark 260321/260409 è il segnalibro in chiaro: il numero di modifica letto fin lì, poi il numero di modifica attuale dell’azienda — quando coincidono, è arrivato tutto. status riporta l’ultima esecuzione completata.

Che cosa significa ogni stato di stream

Stato	Significato	Si riprova?
`synced`	Record nuovi o modificati sono stati letti e messi in coda per l’invio.	Fatto
`up_to_date`	Tally ha risposto e non è cambiato nulla: è lo stato di riposo normale.	Fatto
`company_closed`	Quell’azienda non è aperta in TallyPrime, di solito c’è una richiesta di login in attesa sul desktop.	Sì
`type_map_failed`	L’elenco dei tipi di voucher non è stato letto questa volta, quindi il bridge ha trattenuto quello stream invece di registrare i tuoi tipi personalizzati sotto la voce sbagliata.	Sì
`no_counter`	Questa volta l’azienda non ha riportato alcun contatore di modifiche.	Sì
`needs_backfill`	Una primissima sincronizzazione trattenuta da `first_run_guard`. Elencata da `sa-tally-bridge.exe status --config bridge.yml --json`.	No
`error`	Un tentativo non è andato a termine; il motivo viene registrato e il segnalibro resta dov’è, quindi quei record arrivano la volta successiva.	Sì

I file accanto a bridge.yml

tally_outbox.db, con due file di appoggio — la coda locale e il segnalibro di ciò che è stato inviato. Conservalo: è ciò che fa arrivare ogni record una volta sola.
bridge-status.json — il risultato dell’ultima esecuzione, ciò che stampa status.
sa-tally-bridge.log — il log corrente, con fino a cinque copie precedenti, da .1 a .5. È la prima cosa da inviare al supporto.

Risoluzione dei problemi

Che cosa vedi	Che cosa significa	Che cosa fare
Tutto consegnato, ma il flusso non ha ancora agito.	Il flusso è salvato ma non attivato, oppure è in pausa, quindi ciò che è arrivato finora viene conservato come suo esempio di test.	Apri il flusso e premi Attiva. La sincronizzazione successiva viene elaborata per intero.
`outbox depth` continua a salire.	Il flusso non ha ancora accettato quei batch: una KEY nel frattempo cambiata, un URL di un altro flusso oppure un tipo di record aggiunto a mano senza ancora una destinazione.	Copia di nuovo URL : e KEY : dal pannello e riavvia il bridge; verifica che quel tipo di record abbia un proprio URL, oppure che `webhook_url` sotto `global:` sia compilato. Nel frattempo tutto resta al sicuro in coda.
Un’azienda riporta sempre `company_closed`.	Non è aperta in TallyPrime, di solito perché la sua richiesta di login è in attesa.	Apri quell’azienda nella finestra di Tally e digita lì la sua password. Il bridge la riprende al tentativo successivo.
`Blocked : gateway_error` oppure `gateway_empty`, con ogni azienda su `company_closed`.	Tally non risponde ancora, oppure ha risposto senza alcuna azienda aperta; la riga da leggere è `Blocked`. (`gateway` è il termine che il bridge usa per la connessione di Tally sulla porta 9000.)	Guarda la finestra di Tally: avvia Tally oppure chiudi la richiesta in attesa.
`companyName` o `batchTotal` vuoti sotto il loop.	L’interruttore Include parent fields in each entry del loop è disattivato.	Apri il passaggio loop e attivalo.
Le consegne si sono fermate dopo che qualcuno ha premuto Genera nuovo.	È stata emessa una nuova KEY e il flusso è stato pubblicato, quindi ora il flusso si aspetta quella KEY.	Copia la nuova KEY in bridge.yml, riavvia il bridge, poi premi Aggiorna versione live.
Nessun record da quando il PC è stato riavviato.	Il bridge gira nella tua sessione di Windows e Tally ha bisogno che le sue aziende siano aperte.	Accedi e apri le aziende; il bridge riprende circa un minuto dopo. Su un PC a cui non siede nessuno, attiva l’accesso automatico di Windows e riparte da solo.
I record arrivano due volte.	Il vecchio add-on di Tally è ancora caricato; oppure l’azienda è anche un’origine dati Tally con un trigger Programma; oppure è elencata due volte sotto due chiavi.	Tieni il percorso che vuoi, rimuovi l’altro, riavvia il bridge.
`synced` con `Records : 0`.	Ciò che è cambiato in questo ciclo erano tipi di voucher fuori dall’ambito del connettore, per esempio gli incassi.	Nulla da fare: i record di vendita e di acquisto sono aggiornati.

Buono a sapersi

Affidabilità, in tre righe.
Punto di ripristino (RPO): praticamente zero. Tally resta il tuo sistema di riferimento e il segnalibro di un’azienda avanza solo quando quei record sono al sicuro nella coda su disco — così tutto ciò che è stato registrato nelle aziende e nei tipi di record che hai scelto, mentre internet, il PC o il bridge non erano disponibili, viene ripreso all’esecuzione successiva, senza reinserire nulla.
Tempo di ripristino (RTO): lo decide il tuo PC. Non esiste una procedura di ripristino: appena Windows ha l’accesso effettuato e Tally ha le sue aziende aperte, il bridge riprende da solo circa un minuto dopo, recupera gli orari pianificati nel frattempo trascorsi e, ogni 15 minuti, riprova con le aziende che non erano aperte.
Disponibilità: Windows lo avvia all’accesso e lo riavvia — tre tentativi, a un minuto di distanza — se mai dovesse fermarsi. Quadro completo: L’affidabilità in breve.

Il bridge gira sullo stesso PC di TallyPrime, nella tua sessione di Windows: è questo che gli permette di leggere le cartelle di Tally e di avviare Tally quando serve.
Mentre costruisci un flusso, usa sa-tally-bridge.exe test quante volte vuoi: non sposta alcun segnalibro e non cambia nulla di ciò che hai già sincronizzato.
Le connessioni sono solo in uscita, quindi non serve alcuna regola firewall in entrata. Dietro un proxy aziendale, imposta HTTPS_PROXY per l’account Windows con cui gira il bridge — per esempio http://proxy.example.local:8080 — e riavvialo.
La prima sincronizzazione legge l’intero storico di un’azienda a circa 5.000 record al minuto, quindi un’azienda con 100.000 voucher in archivio richiede circa venti minuti. Falla stando al PC, in modalità automatica, e passa a una pianificazione notturna quando ogni tipo di record riporta up_to_date.
Le aziende protette da password vengono aperte da una persona, nella schermata di login di Tally: il bridge non chiede mai né conserva una password di Tally.

Connettore Tally Prime — Guida all’installazione — il bridge sul PC con Tally e la prima sincronizzazione.
Flussi e automazione — trigger, condizioni e azioni, compreso il trigger Programma, che legge una lista contatti dei tuoi clienti e dei loro saldi per i solleciti.
Liste contatti — dove arrivano i tuoi clienti e fornitori.
Connectors Marketplace — Panoramica — dove si trova il download.