Integrar Tally con software a medida, bien hecho

Casi todos los sistemas que construimos para una empresa india acaban en el mismo sitio: la contabilidad está en Tally y el contable no va a cambiar. Normalmente es la decisión correcta. Tally es lo que el contable conoce, lo que el auditor espera y donde se preparan las declaraciones. La tarea de un sistema a medida es alimentarlo con datos limpios, no sustituirlo.

Que el nuevo sistema ahorre tiempo al contable o le cree trabajo depende casi por completo de cómo se diseñe esa conexión.

Cómo llegan los datos a Tally

1. XML sobre HTTPTallyPrime puede funcionar como servidor en el equipo donde está instalado – por defecto en el puerto 9000 – y aceptar peticiones XML que crean maestros y comprobantes o exportan informes. Es la vía más directa y la que usan la mayoría de las integraciones. Requiere que Tally esté abierto y con la empresa cargada.
2. Importación de archivosComprobantes y maestros preparados como archivos XML e importados por el contable. Más lento, pero mantiene a una persona en el proceso y funciona incluso donde no se puede acceder al equipo de Tally.
3. ODBCTally también expone sus datos mediante ODBC, lo que resulta práctico para leer informes desde otro sistema. Es una vía de lectura, no de registro de asientos.
4. Personalización con TDLEl lenguaje de definición propio de Tally permite añadir campos e informes dentro de Tally. Es útil, pero es código que hay que mantener con cada versión de Tally, así que lo limitamos al mínimo que requiere el trabajo.

Cuando Tally está en un ordenador de la oficina

Tally suele funcionar en un ordenador de la oficina, y una aplicación web en un servidor en otro lugar. No pueden llamarse directamente el uno al otro, ni conviene forzarlos a hacerlo. El patrón fiable es un pequeño conector en el equipo de Tally que pide a la aplicación web los asientos pendientes, los registra en Tally localmente e informa de lo ocurrido. La conexión es solo saliente, así que nada de la oficina queda expuesto.

Maestros antes que comprobantes

Un comprobante hace referencia a cuentas, artículos, almacenes y centros de coste por su nombre. Si un nombre no coincide exactamente con un maestro de Tally, la importación falla o, peor aún, se registra contra el maestro equivocado. Por eso la integración debe mantener una correspondencia: cada tercero, artículo y cuenta del nuevo sistema vinculado a su maestro en Tally.

Los maestros nuevos también necesitan una regla. O la integración los crea según convenciones acordadas, o retiene el asiento y consulta al contable. Lo que nunca debe hacer es permitir que una variación ortográfica – un punto final, una abreviatura distinta – cree en silencio una segunda cuenta para el mismo tercero.

No contabilizar nunca dos veces

El fallo de integración más común es el comprobante duplicado. Tally acepta un asiento, la red se corta antes de que llegue la respuesta y el sistema lo vuelve a enviar. Las dos copias quedan en los libros, y los totales están mal de una forma que cuesta una tarde encontrar.

1. Una identidad estable para cada asientoCada comprobante lleva un identificador del sistema de origen, y la integración lo comprueba antes de crear nada. Enviar dos veces el mismo asiento lo actualiza o lo omite en lugar de añadir uno nuevo.
2. Un registro de contabilizaciónCada intento queda registrado con lo que se envió y lo que respondió Tally, de modo que un asiento que falta o está duplicado se localiza en minutos en lugar de reconstruirse.
3. ConciliaciónUna comparación periódica de totales por día y por cuenta entre los dos sistemas, que detecta los casos que nadie notó en su momento.
4. Reintentos prudentesLos fallos de conexión se reintentan automáticamente. Todo lo que Tally rechazó pasa a una persona con el motivo, en lugar de reintentarse hasta acabar en el sitio equivocado.

Detalle o resumen

No todas las transacciones deben ir a Tally como un comprobante propio. La elección depende del tipo de transacción, y conviene tomarla con el contable y no por él.

• Las facturas de venta suelen registrarse una a una, porque cuando las declaraciones se preparan desde Tally el detalle por factura tiene que estar ahí.
• La nómina suele registrarse como un único asiento revisado al mes, repartido por centro de coste, en lugar de un comprobante por empleado.
• Los cobros de mostrador en gran volumen suelen registrarse como un resumen diario por forma de pago, con el detalle guardado en el sistema de origen.
• Los movimientos de existencias dependen de si las existencias se valoran en Tally. Si el nuevo sistema gestiona el inventario, a Tally a menudo solo le hace falta el efecto contable.

Los detalles del GST que estropean las declaraciones

• GSTIN, lugar de suministro y código HSN o SAC en cada línea, para que cada comprobante esté completo para las declaraciones sin editarlo en Tally.
• Cuentas de impuestos asignadas por tipo y clase, CGST y SGST frente a IGST, en lugar de una sola cuenta de impuestos para todo.
• El redondeo se hace igual en los dos sistemas. Si no, los totales difieren en una rupia, y a partir de ahí nadie se fía de ninguno.
• Las notas de crédito vinculadas a la factura que corrigen, no registradas como asientos negativos independientes.
• Un comprobante con fecha en un periodo cerrado lo rechaza la integración, en lugar de registrarse en silencio en un mes que el contable ya ha cerrado.

Zoho Books y otros programas contables

Zoho Books tiene una API REST documentada, lo que elimina por completo el problema del ordenador de la oficina. Todo lo demás de este artículo sigue aplicándose: la correspondencia de maestros, una identidad estable para cada asiento, el registro de contabilización y la conciliación. Son lo que hace fiable una integración con cualquier programa contable, y son las partes que más a menudo se omiten.