En esta entrada vamos a analizar la estructura de datos contables de Zoho Books con la finalidad de diseñar un esquema que nos permita importar los datos de la contabilidad a otras aplicaciones.
Las dos características principales que encontramos son:
- Se trata de un SAAS online del que no tenemos acceso a la base de datos y del que en principio tampoco haría falta
- tiene sus propias aplicaciones, addons, integraciones (stripe, paypal, zoho crm,) y posibilidad de importar y exportar datos
- tiene su propio sistema de reporting personalizado mediante zoho analytics del que en su día hice mis pruebas con datos del CV y con ejemplo report de ventas
- Se trata de un software con propósito internacional con posibilidad de adaptación local como SAP, Odoo, etc y eso determina la estructura de datos
En el ANEXO hay un análisis más en profundidad de lo que esto supone exactamente
Objetivo
La idea principal consiste en relacionar los datos de ZOHO BOOKS Con lo que serían los campos de un plan de cuentas sencillo
En ZOHO tenemos «account_id» y «name» para plan de cuentas básico. Otros campos necesarios cuando se trata de la cuenta de clientes o proveedores son «Contact ID» y «contact_name»
Lo que obtendremos será «cuenta», «nombre» y otros campos necesarios (de cuentas de clientes o proveedores) que permitan acumular para declaraciones informativas (347) como NIF, país, Código postal, etc.
En el caso especial de querer importar registros de facturas se explica en el ANEXO 2 cómo obtener los datos para informes de impuestos como son el tipo de impuesto, base, cuota, etc.
Datos
En account_transactions tendremos el diario
En Contacts los clientes y en Vendors los proveedores
1. Descargar exportaciones excel INFORMES -> Contable -> Transacciones de cuentas (account_transactions)
Verificar las fechas y los importes en formato inglés del diario (account_transactions) que las estemos procesando adecuadamente
Si vamos a tratar el fichero Excel como origen de datos hay que revisar
- Eliminar la primera fila título sin utilidad de los excel descargados
- Eliminar la última línea que hace de pie de informe vacía
2. Exportar clientes y proveedores desde ventas / compras -> Contacts / Vendors
En estas tablas encontramos los siguientes campos útiles entre otros
Billing Code -> NIF
CF.Tax Number -> Codigo Postal
Billing Country -> País
3. Generar un fichero en el que podamos guardar nuestro cuadro de cuentas
Será nuestra «piedra de Rossetta» donde guardarnos la traducción, codificado según Plan General Contable con los campos que sirvan para relacionar como se ha indicado en el objetivo
4. Crear una consulta para revisar en futuras importaciones si hay nuevas cuentas financieras.
- Para ello podemos usar el fichero general ledger = sumas saldos (libro mayor ZOHO) pues permite observar el campo adicional si en ZOHO estamos informando del código de cuenta PGC
- En caso contrario lo mejor será obtener el account_id desde account_transactions (agrupado desde el diario) para los que no obtenemos cuenta de nuestro fichero generado (punto 3)
5. Generar otra consulta que permita comprobar para las cuentas de clientes / proveedores fijas
La consulta nos tiene que permitir ver qué terceros tenemos pendientes de relacionar según contact_id
- Los datos en esta ocasión los podemos complementar con los ficheros exportados vendors y contacts (TAX NUMBER y código postal)
6. Generar otra consulta para evitar el problema que tengamos alguna cuenta o tercero duplicado
Cuando eso ocurre obtendremos más líneas de las del diario original. También se puede hacer verificación de sumas debe y sumas haber, que coincida con el diario original en el diario transformado. OJO pues un mismo contacto puede tener cuenta de cliente o proveedor por lo que se requiere establecer un filtro que también tenga en cuenta el dato de account_type
7. Generar en el diario transformado
Obtener un número de asiento, cuenta contable (si no es cliente / proveedor directo account_id de lo contrario según contact_id), fechas e importes
- Conviene añadir fórmulas de previsión de error o valor NULO en DEBE y HABER, revisar que sean números válidos.
- Realizar revisiones al diario transformado
- Que los asientos contengan igual número de líneas que el diario original
- Que cada asiento esté cuadrado como suma debe = suma haber
- Podemos obtener un número de asiento válido desde el transaction_id con la siguiente transformación en la que obtenemos el valor de los últimos 7 dígitos del campo Val(Der([transaction_id];7))
8. Por último usar una plantilla de importación
Como ejemplos de importación de datos a otras aplicaciones están las siguientes entradas sobre importaciones en A3 o en SAGE
Esquema
Como punto final este es el esquema de la relación entre datos para obtener el diario contable
Si hay alguien a quien le haya servido este artículo para transformar los datos de ZOHO Books o que ya estuviera trabajando en algo similar los comentarios serán de agradecer.
ANEXO
Otra información relevante para asignar un código de cuentas según plan general contable la encontraremos en el fichero de diario «account_transactions» analizando la función de la cuenta por grupo (1) y tipo (2) o el tipo de asiento en el que interviene (3)
1) el campo account_group te da la idea del grupo de cuentas al que pertenece
asset -> activos grupo2, clientes 430, caja 570, bancos 572, Organismos deudores
equity -> fondos propios grupo 1
expense -> grupo 6
income -> grupo 7
liability -> proveedores , impuestos / administraciones públicas, anticipos, financiación, … grupos 1, 4 y 5
2) el account_type debe indicarte si se trata de una cuenta de balance o de resultados
accounts_payable, accounts_receivable, bank, cash, cost_of_goods_sold, credit_card, equity, expense, fixed_asset, income, input_tax. long_term_liability. other_current_asset, other_current_liability, other_expense, other_income, output_tax, payment_clearing, stock
El esquema es similar al que encontramos en otros programas contables multi-propósito como Odoo o SAP a partir del cual con informes y/o codificaciones específicos se logra la adaptación del programa al sistema local de cada país
3) el campo transaction_type para interpretar en qué tipo de asientos se ha usado la cuenta. En programas contables de este tipo se puede asimilar la idea de diario para cada tipo de operación. Por ello es como si físicamente hubiera un archivador / diario con los asientos de ventas separado del de los abonos, y así con todos los siguientes tipos de asientos. Es un sistema muy efectivo de ordenar los libros contables y más claro que usar un mismo diario para todo.
bill -> factura recibida
customer_payment -> cobros
deposit -> liquidaciones
expense -> asientos de gastos (nóminas, seguros, otros…)
expense_refund -> anulación de gastos
interest_income -> ingresos financieros
inventory_adjustment -> regularización de existencias
invoice -> factura emitida
journal -> diario general
other_income -> otros ingresos (excepcionales, etc…)
refund -> cancelaciones
sales_return -> factura emitida abono
transfer_fund -> traspasos de tesorería
vendor_credit -> abonos de proveedor
vendor_credit_refund -> cancelación abonos proveedor
vendor_payment -> pago a proveedores
vendorpayment_refund -> cancelación de pago a proveedores
ANEXO 2
Para importación de registros de facturas debemos exportar en excel las ventas «Invoice» (Facturas) y compras «Bills» (Facturas_proveedor) vemos por línea de factura los campos
- Tax ID -> Identifica el tipo de impuestos (operación interior / intracom / sujeto / exento)
- Item Tax -> Es la descripción asignada al tipo de impuesto p.e. VAT Spain (operación interior sujeta)
- Item Tax % -> El porcentaje de impuesto a aplicar
- Item Tax Amount -> El importe del impuesto aplicado
- Account Code -> La cuenta de la contrapartida según nuestra codificación (no es el account_id)
- SubTotal -> Importe base
- Total -> Importe con impuestos
- Balance -> Importe final
Advertencia Retenciones
Al igual que ocurre con otros programas similares habrá 2 líneas en la tabla si sobre un mismo producto de una misma factura se aplica más de un impuesto. En concreto en el caso de las retenciones habrá una línea de impuesto + IVA y otra de -IRPF.
Conviene convertir con una consulta estas líneas en columnas para poder trabajar el clásico listado de registro de facturas si queremos ver en un mismo informe los distintos impuestos.
En formato líneas lo que obtenemos de forma directa es el importe de impuestos si filtramos por TIPO. Es decir, informe de IVA por un lado, informes de IRPF por otro…
