Check-in de huéspedes

El huésped registra sus datos desde un enlace de reserva o desde el QR permanente de recepción. La web envía una persona por solicitud; la API guarda los datos y un recibo, y puede entregarlos después a Business Central.

El módulo comparte el host ASP.NET Core 8 y PostgreSQL de BC PDF Sign. Tiene rutas, tablas, autenticación y aplicación web propias. Se activa expresamente con CHECKIN_ENABLED=true; las firmas siguen usando su configuración habitual.

Elige tu recorrido

Necesitas…	Guía
Entender qué ve el huésped y ayudarle con un error	Web y recepción
Crear una invitación o integrar otro cliente	API y ejemplos completos
Recibir los datos y completar la integración del camping	Business Central
Publicar el sistema completo en Coolify	Desplegar API, web y documentación
Probar API y web en el equipo de desarrollo	Anexo de laboratorio local
Saber qué llegó a BC, reintentar o diagnosticar incidencias	Estados y operación
Publicar únicamente este portal independiente	Publicar solo la documentación

Dos formas de entrar

Con reserva: BC crea la reserva de negocio. Su integración debe provisionar una referencia estable, el número total de huéspedes y la caducidad en la API. Recibe un token privado y envía al huésped el correo con enlace/QR. La web muestra referencia y plazas disponibles, y registra cada huésped hasta completar el cupo.

Desde recepción: un QR permanente abre el formulario del establecimiento. No necesita token de reserva ni consulta de reservas en BC. Guarda cada envío como recepción, sin cupo ni referencia de reserva; la asociación posterior a una estancia necesita el procedimiento de negocio del camping.

Reserva creada en BC ── provisionar en API ── token ── correo/QR desde BC
                                                        │
QR permanente de recepción ──────────────────────────────┤
                                                        ▼
Web de huéspedes ── API ── PostgreSQL: huésped + recibo + outbox
                                              │
                                      worker opcional
                                              ▼
                                  BC: Guest Check-in Inbox
                                              │
                                    Import / Retry + adapter
                                              ▼
                                 Persona y estancia reales

El recibo de la web confirma que el servicio guardó el envío. La recepción en la bandeja de BC y la importación a las tablas del camping son etapas posteriores, con estados distintos.

Qué está disponible

• Web React/TypeScript independiente, adaptable a móvil, tablet y escritorio, con siete idiomas.
• API de recepción, contexto de reserva, registro idempotente y provisión administrativa de reservas.
• Validación de campos, cupo atómico por reserva y prevención de documentos duplicados dentro de esa reserva.
• Outbox duradera y entrega opcional a una API propia de BC Online; consulta y reintento administrativo por recibo.
• Fuentes de una aplicación AL independiente con bandeja, permisos y evento de importación transaccional.

Qué falta antes de producción

La creación de reservas, envío de correo y generación del enlace/QR en las tablas reales de BC aún necesitan integración. Tampoco están implementados la recuperación del token tras perder la respuesta de provisión, revocación/rotación de invitaciones o sincronización de cambios de cupo y cancelaciones.

El receptor AL es genérico: falta el adapter que escribe las personas y reservas/estancias del camping. No se han validado la compilación de esta aplicación AL con los símbolos destino ni su ejecución en un sandbox real. Sin adapter, la bandeja permanece Pending.

Hay que acordar el texto y enlace de privacidad, acceso y retención/borrado de datos, documentos de menores y revisión de traducciones. No hay purga automática de check-in: el mantenimiento de PDFs no borra huéspedes. Esta funcionalidad no genera PDFs, recoge firmas, verifica la autenticidad del documento ni presenta partes oficiales de viajeros.

La documentación describe las fuentes disponibles, no una versión publicada ni un despliegue confirmado. Los dominios https://checkin.example.com y https://api.example.com son marcadores que debes sustituir.

Ubicación de las fuentes

Componente	Ubicación
API y persistencia	backend/src/Api/Features/CheckIn/ dentro de bc-pdf-sign
Web	checkin-web/ dentro del mismo repositorio; aplicación y recurso de despliegue independientes
Receptor AL	business-central/checkin/, separado de los objetos de firma
Contrato HTTP canónico	openapi.yaml en la raíz; explicación funcional en docs/API_CONTRACT.md
Referencia de ingeniería	docs/CHECKIN.md y business-central/checkin/README.md

Estas guías constituyen el portal independiente de check-in, con fuentes en docs-checkin/ y configuración mkdocs.checkin.yml. El sitio de firmas conserva su configuración y navegación propias. Los esquemas de OpenAPI siguen siendo la referencia de contrato; no es necesario crear otra especificación para integrar check-in.