Introduce el código de 4 dígitos que has recibido por separado.
El cuello de botella no es contabilizar: eso ya lo tenéis pulido. Es cómo os llega la información de vuestros clientes, y cuánto cuesta comprobar (empresa por empresa, cierre a cierre) que una contabilidad está bien terminada.
Salen de la llamada del 13 de julio, del kickoff del 16 y de vuestras respuestas al cuestionario del 25 de agosto. Están dichos con vuestras palabras, no con las nuestras. Los tres primeros son de puertas adentro y los dos últimos de puertas afuera: es la misma frontera que separa la Fase 1 de la Fase 2.
Para certificar una contabilidad hay doce comprobaciones, y las hacéis vosotros entrando a los mayores de cada empresa. Treinta y una empresas por doce preguntas, en cada cierre.
La información existe, pero en forma de asientos. Para saber si la 129 cuadra o si la 555 está a cero hay que ir a buscarlo. Vuestra frase: «sí es necesario organizar bien la base de datos por cuentas contables, no solo el diario y ya».
El tipo de contabilidad de cada empresa, sus cuentas, sus criterios de amortización, su forma de cobro y por qué se decidió así: está en vuestra cabeza. Tres personas activas, y las particularidades sin escribir en ningún sitio consultable.
Muchos de vuestros clientes son analógicos: la factura llega en papel, en PDF por correo o subida al Drive, y sin orden. Lo dijisteis vosotros en el kickoff: el atasco no está en contabilizar, está antes.
Pasar de gestoría reactiva a asesor financiero. Avisar antes de que venza, contestar cuando preguntan y entregar un informe que se entienda. Es el producto que queréis vender, y hoy no se puede producir a escala.
Sin adornos y sin propuesta todavía: solo el proceso y, al lado, lo que hoy no queda registrado. El primero es el recorrido central del despacho, certificar una contabilidad; los otros tres son los que lo rodean. Los pasos marcados como «no se toca» son los que el proyecto deja exactamente igual.
Las treinta y una empresas del censo que entregasteis no son homogéneas: hay dos sectores de contraste en el piloto, dos empresas cuya contabilidad no es fiable y a las que solo interesa el laboral, y el resto. La base de datos tiene que saber distinguirlas desde el primer día.
Cuatro cuadrantes. Arriba a la izquierda, lo que se monta primero porque rinde pronto. Arriba a la derecha, lo que cuesta más y vale más. Abajo a la derecha, lo que recomendamos no hacer y por qué.
La base organizada por cuentas contables.
La Fase 1 no la ve ningún cliente vuestro y es la que sostiene todo lo demás: la base por cuentas, las doce comprobaciones y la fuente de la verdad. La Fase 2 (Telegram y el área del cliente) no tiene nada que contar si la Fase 1 no está: los avisos salen de los vencimientos de la base, y las respuestas de los saldos.
Por qué en ese orden: es el único que no obliga a rehacer nada.
Es la pieza que menos luce en una demo y la que más vale a tres años. Con ella escrita, cualquiera de vosotros puede llevar cualquier contabilidad sin preguntaros, y quien entre nuevo llega con el contexto entero: las reglas de cada cliente, su cuadro contable, por qué se decidió así y su histórico. Sin ella, el despacho no escala porque el despacho sois vosotros.
Y va en la Fase 1 justamente por eso: no es un extra, es parte de ser más eficientes.
Lo pedisteis vosotros: la 2 de odontología y la 21 de hostelería, más vuestra propia sociedad. Con un solo sector, las reglas parecen genéricas y no lo son. Con dos, el cuadro de cuentas nace como parámetro por sector desde el primer día, que es lo que después permite que la empresa 32 no sea un proyecto.
Si solo caben dos: la 2 y la 21, tal como lo dejasteis escrito.
Es la base intermedia que montasteis vosotros uniendo los datos del ERP dental con la API de Cegid. Lo dijisteis sin adornos: lleva meses inactiva, no está actualizada y la parte del ERP dental ha cambiado. Sirve para entender la estructura y lo que hay; no para sostener el servicio.
Qué sí hacemos: leerla una vez, para no perder lo que ya aprendisteis montándola.
Podríamos montar una tabla de incidencias con su ciclo de vida y su marcado manual. Vuestra respuesta al 3.3 lo hace innecesario: al volver a cargar los datos, si el error ya no existe, no se carga. El informe se recalcula desde cero.
Qué haría falta para reconsiderarlo: querer medir cuánto se tarda en cerrar lo pendiente, no solo qué queda pendiente.
Los mismos cuatro recorridos del diagnóstico, ahora con el sistema al lado, paso por paso. Se empieza por el central, certificar una contabilidad: seis pasos, y el sexto no cambia, porque la contabilidad la seguís dando por buena vosotros con vuestro criterio. Lo que cambia es que la lista de lo que hay que mirar ya está hecha cuando os sentáis.
Los tres recorridos que rodean al central. Los pasos que el proyecto no toca se dicen igual: el asiento se sigue haciendo en Cegid y el análisis del informe sigue siendo vuestro. El único paso que sí cambia de manos es el del OCR, y está explicado justo debajo.
De los cuatro recorridos de arriba, el de la factura tiene un paso que hoy pasa por el OCR de Cegid. Alimentar ese OCR desde fuera no es la vía: lo cerrasteis con un «NO» en el cuestionario porque vuestra licencia no ampara la entrada automática, y no hace falta insistir. Lo que se hace en su lugar es ocupar su función, y desde el 6 de septiembre eso está verificado contra la documentación de Diez Software: ya no es una hipótesis, es una partida con su precio y su semana.
Cuándo se decide. Cuando el arranque dé el coste real medido con vuestras propias facturas, no con una estimación. Hasta entonces las dos vías conviven: el añadido no se integra con el OCR ni lo necesita, y cancelar su cuota es una decisión vuestra y de nadie más. Los números medidos están más abajo, en el bloque de la escritura en Cegid.
Una sola base de datos en el centro. Cegid sigue siendo donde se contabiliza y de él se lee siempre. Solo el añadido escribe, y en dos casos acordados (el alta de trabajador y el desglose de factura por cuenta), siempre con una validación humana por delante.
Las maquetas de esta pestaña son ilustrativas: los datos que muestran son de ejemplo y el diseño final puede variar en la implementación, sin alterar el alcance descrito.
Vuestra petición literal del kickoff. La respuesta cita la cuenta y el saldo a fecha, y dice de qué empresa y de qué ejercicio sale: si no puede citarlo, dice que no lo sabe en lugar de inventárselo.
Datos de ejemplo. Los importes y los nombres de las respuestas son ilustrativos; lo que es real es la forma de responder: cuenta, saldo, empresa y origen.
El que nunca llega al cliente, con vuestras palabras: «para detectar rápido errores de contabilidad del propio trabajo del despacho». Se recalcula desde cero cada vez, así que lo que ya está resuelto desaparece solo, como pedisteis en el 3.3.
Empresas 4, 17 y 74 con saldo en 555 o 558 a cierre de mes. Son cuentas de paso: cualquier saldo distinto de cero es alerta.
Empresa 2: dos apuntes de 1.452,00 € del mismo proveedor con la misma fecha, y números de factura que coinciden en parte. Empresa 56: mismo patrón, 318,70 €.
Empresa 22: el saldo de la 129 no coincide con ingresos menos gastos de los grupos 6 y 7 del propio diario. Diferencia de 2.140,18 €. Suele ser error de traspaso o asiento de regularización mal hecho.
Dos cuentas de proveedor con saldo deudor (empresas 9 y 40) y dos de cliente con saldo acreedor (empresas 15 y 66). Con el detalle de cada una y su importe.
Empresa 18: préstamo sin cuadro de amortización cargado para el ejercicio en curso. Empresa 71: anticipo de cliente en la 438 con 8 meses sin regularizar contra factura.
Cuatro de los avisos del miércoles pasado ya no aparecen: al recargar los datos, el error había dejado de existir. No hace falta cerrar nada a mano.
Aquí está el reto que más pesa a tres años. Hoy el despacho depende de quién está: el cuadro contable de cada cliente, sus criterios de amortización, su forma de cobro y por qué se decidió así viven en vuestra cabeza. Escrito y jerarquizado, cualquiera de vosotros puede llevar cualquier contabilidad sin preguntar, y quien entre nuevo llega con el contexto entero desde el primer día.
Outline autoalojado en infraestructura propia: sin licencia por usuario y sin depender de la herramienta de moda. Es el mismo patrón que ya corremos en cuatro instancias, así que no es un experimento.
Vuestra preocupación del 1.4 era la integridad. Esto es la respuesta: cada columna dice de dónde viene, y el año vivo se recarga completo cada 2-3 meses porque un asiento antiguo modificado a mano no se marca como cambiado.
| A · Empresa | B · Cuenta | C · Denominación | D · Saldo a fecha | E · Naturaleza | F · Última carga | |
|---|---|---|---|---|---|---|
| 1 | 2 · Odontología Digital | 555 | Partidas pendientes de aplicación | 0,00 € | Cuenta de paso | hoy 06:10 |
| 2 | 4 · Lizaran Molina | 555 | Partidas pendientes de aplicación | 1.284,50 € D | Cuenta de paso | hoy 06:10 |
| 3 | 2 · Odontología Digital | 129 | Resultado del ejercicio | 22.014,82 € H | Patrimonio neto | hoy 06:10 |
| 4 | 20 · Alicons Zaidín | 551 | Cuenta corriente con socios | 42.800,00 € D | Activo | hoy 06:10 |
| 5 | 13 · Súper Recuerda | 472 | Hacienda Pública, IVA soportado | 812,44 € D | Activo | hoy 06:10 |
| 6 | 21 · Hoteles de Almuñécar | 438 | Anticipos de clientes | 6.310,00 € H | Pasivo | hoy 06:10 |
Maqueta con datos sintéticos. La base real no es una hoja de cálculo: se representa así porque es la forma más rápida de ver qué columnas hay y de dónde sale cada una.
Muchos de vuestros clientes no van a usar una plataforma nueva, pero el móvil ya lo tienen. Dos direcciones: el canal les avisa sin que nadie llame, y ellos preguntan y mandan facturas cuando les cuadra.
Nadie escribe estos mensajes. Salen de los vencimientos que ya están en la base y del calendario fiscal de esa empresa. Este es el argumento de venta de AGR hacia sus clientes, y hoy no lo tiene nadie.
La otra mitad: el cliente consulta lo suyo sin llamar al despacho, y manda la factura en el momento en que la tiene. Aquí es donde AGR deja de ser gestoría y empieza a ser asesor, porque la respuesta sale de su contabilidad real y no de una hoja aparte.
La otra puerta a lo mismo, para quien prefiera pantalla grande. Entra con su acceso y encuentra sus informes, su calendario, sus vencimientos y su documentación. Dos fuentes para el mismo dato: no todos vuestros clientes se manejan igual, y el que no quiera instalar nada tiene Telegram.
El área del cliente y el canal de Telegram leen del mismo sitio, así que no hay dos verdades. Lo que cambia es por dónde entra cada cliente.
El entregable con el que AGR sube de precio. Ratios, vencimientos, flujos, cuenta de resultados con márgenes y balance, comparado contra el mes y el año anteriores. Llega por Telegram en PDF y vive en el área del cliente, así que el cliente lo tiene por donde le venga bien.
Cuenta de resultados con márgenes, comparada
Empresa 2 · Odontología Digital Multidisciplinar SL, con datos sintéticos. Ninguna cifra de esta maqueta sale de una contabilidad real.
En la reunión del 3 de septiembre quedó pendiente comprobar si la API de Cegid permite escribir, y no solo leer. Esa verificación iba incluida y sin coste, y ya está hecha: el 6 de septiembre se revisó la documentación técnica de Diez Software, la de Contabilidad y la de Nóminas, endpoint por endpoint. La respuesta es que sí, y eso cambia el planteamiento: el añadido no complementa al OCR, ocupa su función. Lee la factura, la desglosa línea a línea a las cuentas que le corresponden y escribe el asiento en Cegid, siempre con una persona validando antes. Debajo, los matices que conviene decir antes y no después.
La creación de facturas (POST /api/facturas/add) admite un array de apuntes con su cuenta contable y su importe por línea, así que la factura del laboratorio puede llevar cada línea a su cuenta (629, 628, 627). Maneja además hasta ocho tramos de IVA por factura y la retención completa (base, porcentaje, cuota y tipo), que es lo que hace falta para el alquiler con IRPF. Y el alta de asientos (POST /api/apuntes/add) permite multilínea con Debe, Haber y contrapartida por cuenta: control total sobre el asiento, no un apunte plano.
Hay creación de empleado (POST /api/Employees/AddEmpleado) y tres endpoints de detalle: contratación, pagas y conceptos salariales. El alta completa encadena cuatro llamadas, así que no es un botón, pero es perfectamente montable dejando siempre una validación humana antes de escribir. Es la partida que entra incluida en la Fase 2.
No hay entorno de pruebas documentado, así que las pruebas se hacen contra vuestra propia empresa y comprobando que lo escrito se puede corregir o anular. La inversión del sujeto pasivo (las facturas tipo Google) no aparece explícita: hay un tipo de factura que hay que confirmar con Diez. Y el coste y los límites de llamadas de la API los tenéis que confirmar vosotros como titulares, con dos líneas de correo.
El esquema es el recorrido del añadido, no una promesa de plazos. La diferencia con el OCR está en el paso 03: hoy la factura del laboratorio que mezcla ortodoncia e implantes va entera a una sola cuenta, y aquí cada línea va a la suya.
Las cinco facturas que mandasteis sirven de piloto porque traen los casos difíciles: inversión del sujeto pasivo, alquiler con retención de IRPF, multilínea con QR de Verifactu, telecomunicaciones multilínea y un proveedor autónomo con NIE. Se pedirán otras cinco variadas para completar la medida. Las cifras de arriba son una estimación, no un compromiso. El número real sale de medir con vuestras facturas durante el arranque, y se os enseña antes de que toméis ninguna decisión sobre la cuota del OCR: el módulo puede convivir con él el tiempo que queráis, y cancelarlo es una decisión vuestra y de nadie más.
Es el objetivo final del producto que queréis vender: cruzar la contabilidad que ya lleváis con los datos operativos del programa de gestión de cada cliente (implantes y ortodoncias del año, primeras visitas, tiempos de sala, coste de laboratorio, producción real frente a facturación) y sumar todo eso al cuadro de mando, para entregar un informe que hoy no da ninguna gestoría. Queda para una tercera fase, y aquí no lleva precio a propósito: traer esos datos depende de lo que permita la API de ese programa, y esa documentación todavía no se ha podido revisar. Lo que se compromete es el hito, no el importe.
Conectar el programa de gestión al asistente para hacerle preguntas concretas ya entra en lo contratado. Responde más despacio, porque no pasa por la base, pero responde. Es barato y por eso va dentro.
Traerse los datos del ERP a la base de forma continua, montar las tablas del sector dentro de la habitación de cada cliente, escribir las reglas del cruce como fórmulas y no como criterio de la IA, y sumar esos indicadores al cuadro de mando que ya entrega la Fase 2. Es un proyecto con entidad propia, del tamaño del que ya se hizo para una joyería, y por eso va en una fase aparte.
El nombre exacto del programa de la clínica (¿Clinic Cloud o Clinicer?), la documentación de su API y las credenciales por el panel. Poner precio sin haber leído esa documentación sería inventarlo. Con eso encima de la mesa se dimensiona en días, y una sesión con vosotros fija de una vez qué campos y qué fórmulas entran, para después congelarlo en lógica. Cuanto antes llegue el nombre, antes hay número.
Dos fases con precio cerrado por fase y un añadido con precio propio: cada partida se explica al pulsarla, y lo que se contrata es la fase completa. Los 800 € de la consultoría que ya pagasteis se descuentan íntegros del primer pago, una sola vez. Todos los importes son sin IVA.
Nadie de fuera la ve, y es la que sostiene todo lo demás. Al terminarla tenéis la base por cuentas, las doce comprobaciones ejecutándose solas, el informe interno llegando dos veces por semana, la consulta en lenguaje natural y el conocimiento del despacho escrito donde se consulta.
La que se nota por fuera. Telegram en las dos direcciones, el área del cliente y el informe ejecutivo trimestral. Es lo que convierte a AGR de gestoría en asesor, y lo que ninguna gestoría de su tamaño está dando hoy.
Lo que hoy hace el OCR, hecho por la IA y mejor: cada línea de la factura a su cuenta. Es la pieza que pedíais al final de la reunión del 3 de septiembre, y se puede presupuestar porque el 6 de septiembre se verificó que vuestra API lo permite.
Se puede contratar por fases y decidir la segunda cuando veáis funcionar la primera. No hay descuento por juntarlas ni penalización por separarlas: el precio es el mismo. El añadido de escritura también se puede dejar fuera, y entonces el proyecto son 7.700 €. Esta es la cifra pagando contra entregas; fraccionarlo a doce meses tiene otro precio, y está en el bloque siguiente.
Dos caminos, y no cuestan lo mismo. En la opción A se paga contra entregas: cada hito se cobra cuando se acepta. En la opción B el sistema se entrega entero y se paga a lo largo de doce meses, así que la inversión la adelanta SoluTech IA. La diferencia de 2.500 € es el coste de ese aplazamiento, no un recargo sobre el producto: es lo que vale que el desembolso no vaya por delante del trabajo.
Somos vuestro partner tecnológico: vigilamos que todo siga funcionando, corregimos lo que se rompa, mantenemos la infraestructura y las actualizaciones, y vamos manteniendo la fuente de la verdad al día, que es lo que la mantiene útil.
En la opción A cada hito tiene su criterio de aceptación y se cobra cuando lo aceptáis. No se factura por horas ni por «está casi listo». En la opción B se entrega igual, con los mismos criterios, pero el cobro va por calendario y no por entrega, y por eso lleva permanencia de doce meses.
Seis semanas para la Fase 1 con su certificación al final, tres para la Fase 2 y una más para la escritura en Cegid. Las barras naranjas son las que dependen de algo que tiene que llegar de AGR: si eso se retrasa, se retrasa el calendario, y por eso está dicho aquí y no en una llamada a mitad del proyecto.
| Trabajo | S1 | S2 | S3 | S4 | S5 | S6 | S7 | S8 | S9 | S10 |
|---|---|---|---|---|---|---|---|---|---|---|
| Conexión con Diez SoftwareTres APIs por OAuth2, sorteando la mal cargada | ||||||||||
| Base por cuentas contablesMayores y saldos agregados por empresa, cuenta y periodo | ||||||||||
| Las 31 empresas y su históricoEl censo ya está entregado | ||||||||||
| Las 12 comprobaciones del auditorDepende del cuadro de cuentas por sector | ||||||||||
| El informe interno automáticoLas cuatro recurrencias, ya cerradas | ||||||||||
| Preguntar en lenguaje naturalSobre la base ya montada | ||||||||||
| La fuente de la verdad en OutlineDepende del acceso al NAS o de una muestra | ||||||||||
| Certificación de la Fase 1Las 12 comprobaciones validadas contra la empresa 2 · hito de cobro | ||||||||||
| Telegram · los avisos proactivosFase 2 | ||||||||||
| Telegram · consultas y facturasFase 2 | ||||||||||
| El área del clienteFase 2 | ||||||||||
| El informe ejecutivo trimestralFase 2 | ||||||||||
| Alta de vuestros clientes en el canalFase 2 · los avisa AGR, no nosotros | ||||||||||
| Medición con vuestras facturas realesCoste por factura y acierto · depende de que lleguen otras cinco | ||||||||||
| Escritura en Cegid · de la factura al asientoAñadido · con validación humana antes de escribir | ||||||||||
Si contratáis solo la Fase 1, el proyecto son seis semanas. La Fase 2 se puede arrancar justo después o más adelante: no caduca y no cambia de precio. El añadido de escritura suma una semana al final y también se puede dejar para más adelante, aunque la medición con vuestras facturas se hace igual en el arranque.
Diez cosas, con su semana. Está escrito aquí para que no haya que descubrirlo a mitad del proyecto: el calendario solo se sostiene si las dependencias están dichas desde el principio. El DPA, que era la novena, ya está firmado: el tratamiento de datos de terceros queda habilitado desde el primer día.
Confirmasteis en el 2.1 que el patrón existe, pero no llegó el cuadro. Se saca en una sesión de volcado con vosotros (vuestra respuesta al 4.3 fue «conmigo por ahora») y se empieza por dental. Sin él, las reglas no se heredan de una empresa a otra y cada una se configura desde cero. Semana 3.
El bloque 2.4 del cuestionario quedó en blanco. Lo interpretamos como que la lista de doce está completa, pero eso no se da por hecho: es una frase. Semana 3.
En el NAS están los impuestos presentados por año y los trámites de cada empresa. Es lo que permite pre-rellenar la fuente de la verdad con lo que ya tenéis, en lugar de escribirla desde cero. Bloquea la pieza que más vale a futuro. Semana 5.
Nos disteis las preguntas y el criterio, que es lo valioso, pero no el resultado esperado por empresa. La demo contra la empresa 2 ES la validación: se ejecutan, se miran juntos y lo que salga raro es hallazgo de su contabilidad, no error nuestro. Conviene tenerlo claro antes de la demo. Semana 6.
Hablasteis de avisar de «pagos pendientes que periodificaron con Hacienda». Lo hemos entendido como los vencimientos de aplazamientos o fraccionamientos de deuda, que son los que no salen en el calendario de modelos y por eso se olvidan. Si os referíais a las periodificaciones contables (480 y 485), es otra pieza. Semana 7.
Qué empresas van a usar Telegram y quién queda autorizado a mandar facturas en nombre de cada una. Sin eso, una factura llega sin dueño. Semana 7.
Lo manda AGR, no nosotros: es vuestra relación y tiene que salir de vosotros. Nosotros entregamos el texto y el enlace de alta preparados. Un canal que nadie sabe que existe no lo usa nadie, y es la forma más fácil de que la Fase 2 no rinda. Semana 9.
La IP de salida ya está habilitada en vuestro firewall de Azure y las APIs están cargadas en la bóveda. Solo hace falta que si algo cambia (una rotación de contraseña, un cambio de firewall) nos llegue. Continuo.
Qué coste y qué límite de llamadas tiene la API, y cómo se marca la inversión del sujeto pasivo al crear una factura. Las tiene que hacer AGR porque el contrato con Diez es vuestro, no nuestro. Son dos líneas de correo. Semana 1.
No hace falta para este proyecto, pero sin él no se puede poner precio a lo que viene después. El nombre exacto del software, su documentación y las credenciales por el panel. Cuanto antes llegue, antes hay número. Cuando podáis.
Y lo que nos comprometemos nosotros. Un update de dos líneas cada semana, sin que tengáis que pedirlo, y los hitos del proyecto visibles en vuestro panel para que podáis ver en qué semana vamos sin escribir a nadie. Además, la verificación de que vuestra API permite escribir ya está hecha y entregada, sin esperar a que se firmara nada, y montamos las doce comprobaciones contra la empresa 2 para que la demo de certificación tenga algo que enseñar.
Cuatro columnas: lo que se incorpora, lo que se conecta y se queda como está, lo que no se toca y lo que se descarta. Ninguna pieza del despacho se sustituye: Cegid sigue siendo el programa de contabilidad, se lee de él siempre y solo se escribe en los dos casos del añadido, con validación humana.
La base del despacho: mayores y saldos a fecha organizados por cuentas contables, con las treinta y una empresas separadas por su código de contabilidad.
Por qué esta y no otra: las doce comprobaciones preguntan por cuenta y por saldo a fecha. Sobre un volcado del diario habría que recalcularlo en cada consulta. El aislamiento va en nuestra capa, no en la credencial.
Patrón de cinco puntos: incremental diario del año en curso y el anterior, recarga completa del año vivo cada 2-3 meses, históricos en carga única, y cada dato con la carga de la que sale.
Por qué así: un asiento antiguo modificado a mano no se marca como cambiado. La recarga es el único modo de que un saldo viejo no dé verde cuando debería dar alerta.
Consultas deterministas contra los saldos agregados, con sus cuentas concretas, más la regla de duplicados. El resultado sale por empresa y fecha, y llega al correo los lunes y los miércoles a las 8:00.
Por qué no lo decide un modelo: el criterio es vuestro y no se interpreta. Una comprobación tiene que dar el mismo resultado hoy y en marzo.
Saldo, mayor y auditoría. No hay consulta libre: responde citando cuenta, saldo y ejercicio, y si no puede citarlo dice que no lo sabe.
Por qué acotado: una respuesta inventada sobre una contabilidad es peor que ninguna, y en la Fase 2 la lee el cliente final. La consulta no entrena al modelo.
Donde vive el conocimiento del despacho: procesos, ficha por cliente, cuadro de cuentas por sector y registro de decisiones. Autoalojado en infraestructura propia.
Por qué esta y no otra: instancia propia en la Unión Europea y sin licencia por usuario, así que dar acceso a alguien más no cuesta más. Y en un formato del que el sistema puede leer.
Bot propio con alta y autorización por empresa: avisos que salen solos, consultas del cliente y entrada de facturas con acuse que dice en qué estado queda cada documento.
Por qué Telegram y no WhatsApp: la vía oficial de Meta tiene coste por conversación y crece con la cartera. El documento se guarda en almacenamiento propio en la UE, el chat no es el archivo.
Aplicación web con acceso propio por cliente: sus informes, su calendario, sus vencimientos y su documentación. Lee exactamente lo mismo que el canal de Telegram.
Por qué las dos puertas: hay clientes que viven en el móvil y clientes que quieren entrar a un sitio y descargar. Detrás no hay dos sistemas, hay uno.
Contraseñas de base de datos y claves de API cifradas, con acceso auditado y acotado a este proyecto. Nunca en texto plano ni en manos de ningún desarrollador.
Por qué se dice aquí: son credenciales que dan acceso a las contabilidades de vuestros clientes. Son revocables en cualquier momento, y el expediente del Reglamento europeo de IA se entrega con la Fase 1.
Sigue siendo donde se contabiliza. Se conecta por OAuth2 a las tres APIs que hacen falta: de lectura para las diez piezas, y de escritura solo en los dos casos del añadido.
Cómo se conecta: la conexión fija explícitamente cuál de las credenciales se usa (hay una cargada mal que no se puede borrar) y valida el resultado contra un saldo conocido en cada carga. Ninguna de las diez piezas escribe en Cegid; el añadido sí, y siempre con una persona aprobando antes.
De ahí salen los impuestos presentados y los expedientes que alimentan el volcado inicial de la ficha por cliente en la fuente de la verdad.
Cómo se conecta: lectura para el volcado inicial, o una muestra de dos clientes si preferís no dar acceso. No es una conexión permanente.
El asiento se sigue haciendo donde se hace hoy, y el OCR se queda exactamente como está.
Por qué se queda fuera: es el paso que ya está pulido, y la licencia no ampara la entrada automática al OCR. Tocarlo añadiría riesgo sin añadir función.
El eje laboral sigue funcionando como hoy, también en las empresas 27 y 28, que son las dos que solo tienen laboral.
Por qué se queda fuera: la API de Nóminas existe y el interés está dicho, pero es un eje nuevo que no estaba en el diseño. Se acota y se dimensiona cuando toque, fuera de estas dos fases.
La base intermedia que ya existe, montada a mano uniendo el ERP dental con la API de contabilidad.
No es lo que recomendamos: lleva meses inactiva y arrastra decisiones tomadas para otra cosa. Sale más barato levantar la base nueva que auditar la vieja, y la de Azure queda como referencia de lo que ya se probó.
El mismo canal del cliente, por la vía oficial de Meta o dentro de una aplicación nativa.
No es lo que recomendamos: la vía de Meta tiene coste por conversación y una app propia añade dos tiendas, dos revisiones y mantenimiento, para dar exactamente lo mismo que ya dan Telegram y el área del cliente.
Pedisteis entender el porqué de cada decisión técnica para poder sostener el sistema con criterio propio, así que aquí va sin adornos. Cegid aparece siempre como fuente y nunca como destino: nada de lo que se monta escribe en vuestro programa. Y dos cosas que conviene que sepáis antes de firmar y no después: vuestros datos y los de vuestros clientes viven en una base propia nuestra alojada en la Unión Europea, con aislamiento por cliente, no en un servidor dedicado para AGR; y la titularidad del sistema la resuelve el contrato, no la infraestructura. Si preferís infraestructura aparte, se puede valorar y tiene otro precio.
| # | Pieza | Cómo se construye | Dónde viven sus datos | De qué depende |
|---|---|---|---|---|
| 01 | 1 · Los datos en su sitio | Tareas programadas, patrón de 5 puntos: incremental diario, recarga trimestral y carga única de históricos | Base propia en la Unión Europea, aislada por código de contabilidad | API de Contabilidad de Diez por OAuth2 |
| 02 | 2 · El auditor · 12 comprobaciones | Consultas deterministas sobre los saldos agregados, no las decide un modelo | La base · resultados por empresa y fecha | Cuadro de cuentas por sector |
| 03 | 3 · El informe interno | Tarea programada + envío de correo | La base · el correo no guarda datos | Nada: las recurrencias ya están cerradas |
| 04 | 4 · Consulta en lenguaje natural | Modelo de lenguaje con herramientas acotadas: saldo, mayor y auditoría. Sin consulta libre | La base · la consulta no entrena al modelo | Pieza 1 terminada |
| 05 | 5 · La fuente de la verdad | Outline autoalojado en infraestructura propia | Instancia propia en la UE · sin licencia por usuario | Acceso al NAS o muestra de 2 clientes |
| 06 | 6 · Autoservicio y alta de empresa | Configuración sobre la base | La base | Piezas 1 y 2 terminadas |
| 07 | 7 · Telegram · avisos proactivos | Bot propio + tarea programada sobre los vencimientos | La base · el aviso no lleva adjuntos | Piezas 1 y 2 terminadas |
| 08 | 8 · Telegram · consultas y facturas | Bot propio + almacenamiento propio | El documento en almacenamiento propio (UE) · el chat NO es el archivo | Alta y autorización por empresa |
| 09 | 9 · El área del cliente | Aplicación web con acceso por cliente | La base · lee lo mismo que Telegram | Pieza 7 terminada |
| 10 | 10 · Informe ejecutivo trimestral | Generación en PDF y entrega por los dos canales | La base | Piezas 2 y 3 terminadas |
| + | + · Escritura del asiento desglosado | Lectura de la factura y propuesta de asiento, escrita vía POST /api/facturas/add y POST /api/apuntes/add solo tras validación humana | La base y Cegid · es el único punto del sistema que escribe en vuestro programa | Confirmar con Diez el coste y los límites de llamadas, y el tipo de factura de la inversión del sujeto pasivo |
El sistema trata contabilidades de clientes de AGR, es decir datos de terceros, y en la Fase 2 esos terceros lo usan directamente. Por eso esto no es un apartado de relleno. Aquí se identifica el marco aplicable y qué hace el sistema en cada frente; la validación jurídica final es de AGR con su asesoría, y conviene hacerla antes del arranque y no durante.
Las contabilidades no son de AGR: son de sus clientes. Nosotros las tratamos por cuenta del despacho, y hay clínicas en la cartera.
Las facturas que manda un cliente llevan datos fiscales y, a veces, personales. El canal es de un tercero.
Para leer de Cegid hacen falta credenciales que dan acceso a las treinta y una contabilidades.
Hay un modelo de lenguaje dentro del sistema: en la Fase 1 lo usa el despacho, y en la Fase 2 lo lee el cliente final.
Lo que se monta es de AGR, y los datos que hay dentro son de AGR y de sus clientes.
Los mismos recorridos del diagnóstico, vistos por sistemas: qué pieza actúa en cada paso y dónde queda escrito el dato. Es la vista que necesita quien vaya a revisar las conexiones.
Cinco capas. El dato de contabilidad no se duplica en dos sitios que manden a la vez: Cegid es la fuente y la base es la copia de lectura sobre la que se pregunta y se audita.
De dónde sale el dato, y quién manda en cada cosa.
Cómo entra, cada cuánto y con qué trazabilidad.
Dónde vive, y separado de quién.
Lo que convierte los saldos en una alerta o en una respuesta.
Dónde se lee el resultado, dentro y fuera del despacho.
Doce riesgos reales, con su probabilidad y su mitigación. Tres los identificasteis vosotros en el cuestionario, y cuatro entran con la Fase 2: un canal que tocan vuestros clientes añade riesgos que un sistema interno no tiene.
| Riesgo | Probabilidad | Qué pasa si ocurre | Qué hacemos |
|---|---|---|---|
| Son contabilidades de terceros, y en la Fase 2 esos terceros usan el sistema | alta | Tratar datos personales de los clientes de AGR exige el encargo del tratamiento firmado y por escrito. Y hay clínicas en la cartera, con lo que eso implica. | El DPA ya está firmado, así que el tratamiento está habilitado desde el arranque y no bloquea ninguna semana. Encima de eso: aislamiento por código de contabilidad, almacenamiento propio en la Unión Europea y acceso auditado. |
| Los datos viven en una base compartida, no dedicada | media | Si en algún momento hace falta aislamiento de infraestructura y no solo de datos, es otro proyecto y otro precio. | Está dicho por escrito aquí y en la tabla de arriba: base propia en la UE con aislamiento por cliente, no servidor dedicado. La titularidad la resuelve el contrato, no la infraestructura. Si preferís infraestructura aparte, se valora. |
| La API de contabilidad no permite escribir asientos | alta | Se cae la contabilización sin intervención de lo que entra por Telegram, y con ella la vía de sustituir el OCR. El canal sigue sirviendo (la factura llega ordenada, leída y sin duplicados) pero la entrada la sigue haciendo una persona. | Lo verificamos antes de que empecéis a pagar la Fase 2 y sin coste. Y la partida ya está redactada sin prometerlo. |
| El cuadro de cuentas por sector no llega | alta | Las reglas no se heredan y cada empresa se configura una por una: el coste de las 28 restantes deja de ser configuración. | Bloquea explícitamente la pieza 2 en el calendario, semana 3, y encabeza la lista de lo que hace falta de AGR. |
| Un asiento antiguo modificado a mano no se marca | media | El saldo se queda viejo y una comprobación da verde cuando debería dar alerta. Es el riesgo que vosotros mismos identificasteis en el 1.4. | La recarga completa del año vivo cada 2-3 meses, con vuestro ritmo y no con el nuestro. Y cada dato dice de qué carga sale. |
| La API errónea de contabilidad, la que no podéis borrar | media | Una conexión que apunte a la mala devuelve datos incompletos, y nadie se entera hasta que un saldo no cuadra. | La conexión fija explícitamente cuál se usa y valida el resultado contra un saldo conocido en cada carga. Si cambia, salta. |
| El cliente cree que mandar por Telegram es «ya está contabilizado» | media | Deja de revisar y da por hecho que un gasto está registrado cuando solo está entregado. El error aparece en el cierre, cuando ya cuesta caro. | El acuse dice en qué estado queda: recibida, clasificada y en cola. Nunca dice contabilizada si no lo está. Es una decisión de redacción, no un detalle. |
| Una factura que llega sin dueño | media | Un remitente no vinculado a una empresa manda un documento y nadie sabe de quién es. Con 31 empresas, eso es trabajo manual de vuelta. | Alta con autorización por empresa: un remitente no reconocido no puede enviar, y el bot le dice a quién pedir el alta. |
| Datos por un canal que no es nuestro | alta | Las facturas llevan datos fiscales y personales. Los chats normales de Telegram no van cifrados de extremo a extremo, y conviene saberlo antes y no después. | El documento se guarda en almacenamiento propio en la UE y el chat no es el archivo: el bot no conserva el fichero. Los avisos salientes no llevan adjuntos, solo el enlace al área del cliente. |
| Nadie avisa a los clientes de que el canal existe | media | La Fase 2 no rinde: el canal montado y vacío. Es la forma más fácil de que esta inversión no se note. | El aviso lo manda AGR porque es su relación, pero nosotros entregamos el texto y el enlace de alta preparados, y está en las dependencias con su semana. |
| El modelo de lenguaje responde de más | media | Una respuesta inventada sobre una contabilidad es peor que ninguna. Y en la Fase 2 la lee el cliente final, y no vosotros. | Herramientas acotadas (saldo, mayor, auditoría) y no consulta libre: responde citando cuenta, saldo y ejercicio, y si no puede citarlo dice que no lo sabe. Es cómo está construida, no una promesa. |
| Sin tabla de estados no hay métrica de cierre | baja | No se podrá medir cuánto se tarda en resolver lo pendiente ni ver su histórico. Es consecuencia de vuestra decisión del 3.3, y la aceptamos. | Se dice por delante, aquí y en la partida del informe interno. Si algún día queréis medirlo, se monta aparte. |
Dicho aquí para que no haya sorpresas ni conversaciones incómodas en la semana seis.
Vuestra licencia no lo ampara: respondisteis «NO» en el 5.2. El añadido no lo alimenta, ocupa su función: lee la factura y escribe el asiento desglosado. Lo que sigue fuera de alcance es cualquier integración con el propio OCR. Y cancelar su cuota es una decisión vuestra y de nadie más: no se pide en este documento, primero se mide con vuestras facturas y luego decidís.
La API sí permite escribir, verificado el 6 de septiembre, y el añadido de escritura monta el desglose por cuenta. Lo que no se hará nunca es escribir sin que una persona lo valide: el sistema propone el asiento y espera vuestra aprobación.
Ninguna de las diez piezas escribe en Cegid: de él solo se lee. Lo único que escribe es el añadido, y en dos casos y solo esos dos: el alta de trabajador y el desglose de factura por cuenta. Cualquier otra escritura se acota y se dimensiona aparte.
El chat no es el archivo. El documento se guarda en almacenamiento propio; buscar en el historial del chat no es una funcionalidad.
Telegram sí, WhatsApp no: la vía oficial de Meta tiene coste por conversación y alta de número. Y el área del cliente se abre en el navegador del móvil igual que en el ordenador.
El alta de trabajador sí entra, incluida en la Fase 2. Lo que queda fuera es el resto del eje laboral (nóminas, finiquitos, partes), que es un eje nuevo y no estaba en el diseño. Se acota y se dimensiona cuando toque.
Es la Fase 3, explicada en su bloque, y no lleva precio en este documento porque haría falta leer antes la documentación de la API del programa de la clínica. La consulta puntual contra el ERP sí va incluida.
Se habló en el kickoff. Sin la base montada no hay sobre qué unir métricas de marketing.
Interés declarado, y se presupuesta aparte. No está incluida en estos importes.
Cumplimiento. El sistema trata contabilidades de clientes de AGR (datos de terceros) y en la Fase 2 esos terceros interactúan con él directamente: el encargo del tratamiento (DPA) es requisito previo a tocar un dato real, y ya está firmado. Los documentos que entren por el canal se guardan en almacenamiento propio en la Unión Europea; el chat no es el archivo y los avisos salientes no llevan adjuntos. Los secretos que AGR nos ceda (contraseñas de base de datos, claves de API) viven cifrados en bóveda con acceso auditado y acotado a este proyecto, no en texto plano ni en manos de ningún desarrollador, y son revocables en cualquier momento: es el mismo procedimiento por el que subisteis la contraseña de Azure. El expediente del Reglamento europeo de IA se entrega con la Fase 1. Los importes de este documento son sin IVA y tienen una validez de 30 días naturales desde la fecha de emisión.
Lo que firmas es exactamente lo que has leído en este documento. El contrato recoge el alcance de las dos fases, los hitos con su criterio de aceptación y el encargo del tratamiento del artículo 28, que hasta ahora estaba pendiente de confirmar.
El contrato se abre al pulsar y se firma en el navegador. Cuando lo firmes nos llega el aviso al momento y queda archivado: no tienes que devolvernos nada por correo. El primer pago ya está recibido, así que el contrato no vuelve a pedirlo.
El contrato se ha abierto en una pestaña nueva. Fírmalo ahí y esta página se actualiza sola.
Volver a abrir el contratoContrato firmado. Ya lo tenemos y arrancamos. Te damos de alta en el panel de seguimiento y te escribimos para cerrar la sesión de diseño de los dos informes.
SoluTech IA · Wixyn Tech, SL. Contrato de consultoría e implantación, referencia SIST-AGR-2026-08. Los importes de este resumen incluyen el 21 % de IVA salvo donde se indica lo contrario; el documento que se firma es el que manda.