La pregunta correcta para tu proveedor
Pregunta qué versión concreta resuelve los requisitos, cuándo estará instalada y qué documentación la identifica. Una respuesta comercial genérica no permite organizar pruebas ni asignar responsabilidades.
Si el proveedor cerró, dejó de dar soporte o no ofrece una actualización viable, averigua qué datos puedes obtener. El CSV puede servir para generar facturas por lotes y la API puede conectar un sistema mantenible; ninguna opción exige borrar el histórico.
Prueba el caso que de verdad utilizas
Una factura sencilla demuestra poco si tu actividad utiliza anticipos, varias series, destinatarios extranjeros o rectificaciones. Elige una operación frecuente y un caso que normalmente necesita revisión.
Comprueba el resultado completo: factura legible, QR, registro de alta, encadenamiento y estado de remisión. Anota cualquier campo que deba llegar desde el sistema anterior y quién corrige un rechazo.
Deja un margen para corregir
La puesta en marcha afecta a personas y procedimientos además del programa. Administración debe saber cuándo emitir; comercial, qué información entregar; y la asesoría, cómo recibir los datos que necesita.
Fija una fecha interna anterior al 1 de enero. Ese margen sirve para ajustar formatos, permisos y series sin convertir el último día del año en una prueba de producción.
Qué no debes hacer con el histórico
No reemitas facturas antiguas para que aparezcan en el nuevo sistema. Conserva el acceso, las copias y la relación con cobros o contabilidad según corresponda.
La fecha de corte debe distinguir los documentos anteriores de las nuevas emisiones. Si quedan borradores u operaciones abiertas, asigna una decisión concreta a cada una.
Cinco respuestas que debes tener esta semana
- Producto y versión que utilizarás
- Operación probada de principio a fin
- Persona responsable de cada incidencia
- Fecha interna de puesta en marcha
- Alternativa si tu software no llega
Cómo leer el resultado de la prueba
Una prueba aceptada debe permitir seguir la operación desde el dato de origen hasta la factura y su registro. Anota la referencia utilizada, el momento de emisión, el estado de remisión y la persona que comprobó el resultado. Repite el ejercicio después de cualquier cambio relevante.
Si aparece un rechazo, evita resolverlo solo en la pantalla final. Identifica qué dato lo causó y corrige también el origen. Así la siguiente factura no reproduce la misma incidencia y la prueba mejora el proceso completo.
Guía de aplicación paso a paso
Semana 1: obtén respuestas verificables. Solicita al proveedor versión, documentación, fecha de instalación y condiciones. Si la respuesta depende de una actualización futura, pide un hito concreto. Paralelamente, comprueba qué datos puedes exportar para no descubrir una dependencia técnica cuando ya no quede margen.
Semana 2: prepara casos de prueba. Selecciona una factura habitual, una rectificativa y la operación que más revisiones provoca. Describe el resultado esperado antes de probar. Así podrás diferenciar un fallo del programa de una configuración incompleta o de un criterio fiscal pendiente.
Semana 3: recorre las incidencias. Provoca de forma controlada un dato obligatorio ausente y revisa el mensaje obtenido. Comprueba quién lo recibe, dónde se corrige y cómo se reintenta. Un proceso solo está probado cuando el equipo sabe salir de un error sin duplicar documentos.
Semana 4: forma a quienes facturan. Entrega una instrucción breve con fecha de corte, vía de entrada, revisión previa y canal de soporte. Cada persona debe saber cómo identificar una factura y comunicar su estado. Evita manuales extensos que nadie consultará durante una incidencia real.
Antes de activar: conserva una alternativa. Si la implantación principal no llega, define qué operaciones podrían emitirse manualmente o mediante CSV. La alternativa necesita sus propias pruebas. Tenerla preparada permite mantener la actividad mientras se corrige una integración sin improvisar otro sistema completo.
Ejemplo práctico
Imagina una empresa que factura servicios mensuales desde una aplicación antigua. La prueba útil incluye una factura recurrente, una rectificación y un cliente con datos incompletos. Administración documenta el resultado y el proveedor corrige el origen del error. La empresa llega a la fecha interna con un procedimiento que el equipo conoce y todavía conserva semanas para resolver una incidencia no prevista.
Antes de cerrar la decisión
Con menos de cien días, prioriza aquello que bloquea la emisión: producto, versión, datos, prueba y responsables. Las mejoras de informes o diseño pueden programarse después. Mantén una reunión breve y periódica con una lista única de pendientes para que las decisiones no queden repartidas entre correos, llamadas y documentos diferentes.
Cuando una prueba funcione, anota también las condiciones que la hicieron posible. Si dependía de datos corregidos manualmente o de una persona concreta, todavía no representa el proceso diario. La aceptación debe demostrar que el equipo puede repetir el resultado de forma normal y atender una excepción.
Preguntas frecuentes
¿Basta con que el proveedor confirme que estará listo?
No. Necesitas conocer producto, versión, fecha de instalación y resultado de una prueba que represente tu facturación. La confirmación comercial no sustituye la comprobación del recorrido completo.
¿Qué debería probar primero?
Una operación habitual y una excepción frecuente. Revisa documento, QR, registro, encadenamiento, remisión y forma de corregir un rechazo sin duplicar la factura.
Fuentes consultadas
Contenido informativo. La aplicación de la norma depende de la situación de cada negocio.