KSeF E-Invoicing: configuración y ayuda

Envío y facturas impresas

PrestaShop emite y numera la factura. El módulo prepara FA(3) a partir de los importes guardados, deja fijado el documento saliente y permite que la tarea programada lo envíe, siga su estado y recupere la UPO. Un abono se convierte en una KOR que hace referencia a su original. Comprueba el estado del pedido en el bloque KSeF y abre Detalles para descargar su UPO desde la página del documento.

Tras la aceptación, el PDF nativo de la factura lleva el número KSeF y KOD I. Antes de que KSeF acepte una factura emitida sin conexión, el PDF también puede llevar KOD II con un certificado Offline separado y válido. Sin ese certificado, KOD II no aparece y el equipo ve un aviso. Los documentos excluidos de KSeF por un fallo total no llevan códigos KSeF.

Resumen y recepción de facturas de compra

El resumen muestra documentos y estado de funcionamiento. Los recuentos de envíos, aceptaciones y recepciones cubren hoy y los seis días naturales anteriores en Varsovia. Las importaciones aceptadas cuentan al verificarse; a los registros antiguos sin las marcas de tiempo de los eventos no se les asignan recuentos históricos inventados.

La recepción está desactivada por defecto. Actívala para la tienda y el entorno elegidos con una fecha inicial del historial y credenciales con permiso de lectura de facturas. La bandeja de entrada tiene filtros, una vista legible de la factura y la descarga del XML original. Los bytes descargados deben coincidir con el hash de KSeF. Las tiendas que comparten NIP del vendedor y entorno comparten la bandeja de entrada. La vista legible es la del módulo, no una visualización oficial del ministerio ni un asiento contable.

Rectificaciones y reembolsos

Usa la página del documento KSeF de la factura aceptada para previsualizar rectificaciones. Las rectificaciones de datos del comprador cambian el nombre o la dirección y conservan la identidad fiscal y los importes. Cambiar el NIP requiere el proceso para NIP erróneo: una rectificación a cero y después una factura de sustitución retenida hasta que KSeF acepte la puesta a cero. Previsualiza y emite indicando un motivo; el proceso manual no altera ningún pago, reembolso o movimiento de existencias PrestaShop.

Los reembolsos de importe libre esperan a que el equipo confirme su reparto entre los códigos de IVA. El formulario propone un reparto, pero no aplica ninguno sin confirmación. Las rectificaciones requieren que la factura original y todas las rectificaciones anteriores estén finalizadas en KSeF; una factura importada también necesita que su base histórica de referencia esté conciliada.

Credenciales y paso a producción

Cada tienda tiene ajustes y credenciales para TEST, DEMO y PRODUCTION. TEST usa una identidad ficticia y sustituye al vendedor y al comprador en el XML saliente. Usa datos ficticios tanto en TEST como en DEMO. DEMO usa el token o certificado DEMO del comerciante. Obtén un token de la aplicación MF KSeF para el entorno correcto, introduce el NIP del vendedor y el token en el formulario de conexión o usa un certificado de autenticación con su clave privada correspondiente y la contraseña cuando sea necesaria. Prueba la conexión después de guardar.

PRODUCTION tiene su propio token o certificado de autenticación. Un empleado con permisos de edición y gestión de credenciales abre la vista previa de producción, revisa vendedor, dirección de la tienda y punto de inicio y escribe el NIP del vendedor y el dominio para confirmar. Este paso habilita los envíos con efectos jurídicos. La vinculación abarca la tienda, el NIP del vendedor, el dominio de la tienda, esta instalación y las credenciales guardadas. Cualquier cambio exige una nueva confirmación. Pausa los envíos para retener las nuevas transmisiones; la recuperación de estados puede continuar cuando la vinculación lo permita. Volver a producción tras haberla abandonado requiere una nueva confirmación. Obtén la autorización escrita del propietario antes de pasar una tienda real a PRODUCTION.

Se rechazan los servidores de desarrollo, las bases de datos restauradas y las copias bajo otro dominio. Esta protección no puede distinguir una copia idéntica de los archivos y la base de datos de la tienda bajo el mismo dominio; el alojamiento debe aislarla o bloquear su acceso saliente a producción.

Certificados Offline e interrupciones

El certificado de tipo Offline firma KOD II; es distinto del certificado de autenticación. Con acceso mediante certificado, solicita el certificado Offline desde los ajustes. Quienes usan un token suben un certificado Offline de la aplicación MF. Solo un certificado Offline válido, correspondiente a la identidad afectada y activo puede proporcionar KOD II.

La eliminación local y la revocación en KSeF son acciones separadas. La revocación desde el módulo exige acceso mediante certificado y confirmación; quienes usan un token revocan en la aplicación MF. Una solicitud de revocación detiene la firma KOD II con ese número de serie mientras se resuelve el resultado.

El canal de producción Latarnia del ministerio proporciona información de interrupciones en todos los entornos, incluido TEST. El modo de emisión registrado controla la espera, la gestión sin conexión y las exclusiones por fallo total. Los documentos aptos en cola se reanudan tras una interrupción mediante la tarea programada. Revisa el estado del canal y los motivos de los documentos; el módulo no garantiza que todos los documentos se acepten automáticamente.

Importar facturas ya presentes en KSeF

Selecciona tienda y entorno y usa Facturas ya en KSeF en los ajustes o la acción Ya en KSeF de cada factura. Un CSV sencillo puede contener:

id_order_invoice,ksef_number
123,REPLACE_WITH_THE_EXISTING_KSEF_NUMBER

El segundo valor es un marcador que debes sustituir por un número real ya presente en KSeF. También se admite JSON. Previsualiza el archivo, resuelve los conflictos y las identidades sin correspondencia y sube el mismo archivo para confirmar. La tarea descarga el original, comprueba el NIP del vendedor, el número de factura de la tienda y la fecha de emisión y conserva el XML. Las importaciones registradas nunca vuelven a enviarse. Este proceso de importación no inventa ni recupera UPO.

Una importación puede aceptarse aunque su base de referencia para rectificaciones siga incompleta. Concilia las correspondencias ambiguas de líneas y las rectificaciones históricas antes de intentar rectificaciones posteriores. Los conflictos de identidad aptos pueden aceptarse con un motivo obligatorio del empleado y pruebas registradas; examina las diferencias antes de usar esa acción.

Elegir el proceso de revisión

Usa las rectificaciones de datos del comprador para un nombre o una dirección; usa el proceso para NIP erróneo cuando cambie el NIP del comprador. Confirma tú mismo los repartos de reembolsos de importe libre. Configura la política de envío para particulares y revisa el tratamiento del IVA de compradores extranjeros. Nunca uses la aprobación del equipo para eludir la falta de pruebas fiscales.

Requisitos

Mínimo declarado: PrestaShop 1.6.1.0, con soporte hasta 9.x, y PHP 7.1 o posterior. El módulo se ha probado en instalaciones nuevas de PrestaShop 1.6.1.24 con PHP 7.1, 1.7.8.11 con PHP 7.4 y 8.2.8 y 9.2.0 con PHP 8.1, y su conexión al entorno de producción de KSeF (acceso y recepción) se ha comprobado en PHP 8.4.

PHP necesita cURL, DOM/libxml, JSON, mbstring y OpenSSL. El vendedor debe tener un NIP polaco válido. Permite el acceso al entorno KSeF elegido y al canal ministerial Latarnia; el envío requiere la tarea programada. Instala mediante el Gestor de módulos PrestaShop y consulta Integridad tras la instalación. Protege copias de seguridad y credenciales. El precio es de 79 EUR sin IVA, con 12 meses de actualizaciones y 3 meses de soporte.

Selecciona una sola tienda antes de configurar credenciales, confirmación de producción o recepción. Los ajustes son por tienda, mientras las bandejas de facturas de compra se comparten para el mismo NIP y entorno. El módulo incluye textos en inglés, polaco, alemán, francés, español e italiano; son distintos de las traducciones de la ficha de la tienda.

El hook de factura detecta el documento después de que PrestaShop lo numere. La preparación lee los importes guardados de facturas y abonos, valida FA(3) y conserva el XML para enviarlo. La tarea programada envía los documentos preparados, sigue los resultados inciertos y registra la aceptación de KSeF y la UPO. Los datos fiscales no válidos o incompletos requieren revisión. La ficha del pedido y el PDF usan el documento registrado en lugar de generar una segunda factura comercial.

La misma tarea verifica las importaciones y recibe las facturas de compra en el tiempo que le queda de ejecución. Las credenciales y los tokens de acceso se almacenan cifrados y autenticados. Los datos y XML de las facturas, los metadatos y XML de las facturas de compra, los datos de rectificación y los identificadores del personal para auditoría permanecen como registros fiscales en la base de datos de la tienda. El módulo no registra ningún hook específico de exportación, eliminación o anonimización GDPR ni ofrece limpieza automática por periodo de conservación. La desinstalación conserva documentos, eventos y ajustes; el comerciante debe establecer políticas de acceso y conservación para esos registros.

• El módulo envía las facturas emitidas por PrestaShop y gestiona sus procesos de rectificación KSeF. No emite recibos fiscales, no contabiliza facturas de compra ni ofrece asesoramiento fiscal. El vendedor debe tener un NIP polaco válido.
• La aceptación depende de los datos de factura, las credenciales, la disponibilidad de KSeF y la tarea programada. Los datos de empresa sin identidad fiscal válida, un tratamiento del IVA no admitido, los reembolsos incompletos o la falta de pruebas históricas pueden dejar documentos en revisión. Debe revisarse el tratamiento de los compradores extranjeros.
• KOD II necesita un certificado Offline activo. Una exclusión por fallo total no tiene código QR KSeF. Una copia idéntica de los archivos y la base de datos bajo el mismo dominio necesita aislamiento por parte del alojamiento.
• La recepción requiere permiso de lectura de facturas. Este módulo proporciona su vista legible; conserva el XML original para disponer del documento fuente completo.
• Las importaciones nunca se reenvían y el proceso de importación no proporciona UPO. Una factura verificada puede seguir necesitando correspondencias de líneas y rectificaciones históricas antes de permitir rectificaciones posteriores. Los recuentos de aceptaciones de siete días incluyen las importaciones al verificarse.

• No se envía ningún documento: comprueba tienda seleccionada, entorno, modo de envío, punto de inicio, estado de pedido que emite facturas, tarea programada y motivos del panel de funcionamiento. Un documento retenido necesita que se resuelva el problema indicado.
• La producción está bloqueada o falla el acceso: comprueba credenciales específicas del entorno, permisos, NIP del vendedor, dominio e identidad de la instalación. Revisa y confirma una vinculación modificada con el administrador responsable; nunca eludas el rechazo de una copia.
• Falta UPO o KOD II: la UPO llega tras un envío del módulo aceptado; una factura importada no la recupera aquí. Para KOD II, comprueba el certificado Offline separado, su validez, la coincidencia del NIP y el estado de revocación.
• La recepción o el estado de interrupciones no se actualiza: comprueba que la recepción esté activada, la fecha inicial del historial, los permisos de lectura de facturas, la tarea programada y la conexión Latarnia. Conserva el error y la hora de reintento mostrados; el XML descargado debe superar la comprobación del hash.
• Una rectificación o importación sigue en revisión: lee la discrepancia, resuelve las rectificaciones anteriores, concilia la base importada y los reembolsos históricos o confirma el reparto del IVA del importe libre. Previsualiza de nuevo tras cambiar la fuente. Contacta con soporte con los ID de documentos y los motivos sin datos sensibles, nunca con tokens ni claves privadas.