ED13 - Tarea: escanear y procesar comprobantes de gastos de representación

Disparador: Ha tenido lugar una consumición con fines comerciales; el establecimiento de hostelería ha emitido una factura (restaurante). Los gastos deben registrarse como gasto de explotación — para ello debe aportarse la prueba exigida por la ley (§ 4 Abs. 5 Satz 1 Nr. 2 EStG).

Qué exige la ley

La tarea en cinco pasos

  1. Escanear — el comprobante en papel o de restaurante se fotografía o escanea y se almacena como documento original (p. ej., PDF) en el directorio de comprobantes.
  2. Captación por OCR — a partir del comprobante se determina el texto interpretable (ocr.txt) y se documenta con su calidad/confianza (TrustVector-BitVector, inicio 0x0001 = machine-unverified).
  3. Reconocer el tipo de comprobante — a partir del texto del OCR, el tipo de comprobante se determina de forma basada en reglas: en este caso, BUSINESS_MEAL_RECEIPT (comprobante de gastos de representación; reconocido por „Bewirtungsaufwendungen“, „Bewirtete Personen“, „Anlass der Bewirtung“).
  4. Incorporar al proceso de firma — se genera un *.gcsig.md (artefacto de firma, clase GCSIG) que transporta el recibo propio digital: los datos exigidos por la ley en un content integrado (esquema business-meal-receipt-1.0), la procedencia del OCR (ocr), el bloque Sidecar integrado (source) y el bloque de firma (signature) con el facsímil de la persona firmante.
  5. Presentar y firmar — el artefacto se marca como presented, se presenta a la persona (HITL) para que firme y, tras la aprobación, se marca como accepted → signed. El ancla de la firma es el SHA-256 del documento original.

El artefacto: comprobante y firma en un solo documento

Para los comprobantes que se incorporan al proceso de firma, no es necesario un .v7g.md independiente: el *.gcsig.md asume íntegramente la función de Sidecar (regla «Función Sidecar/transición»: el .v7g.md se transforma en el .gcsig.md, sin pérdida de información y sin Sidecars concurrentes). A partir del esquema gcsig-1.4 contiene:

Bloque Contenido
subject / sha256 el documento original (PDF) con su SHA-256 como ancla de prueba
content los datos del recibo propio (business-meal-receipt-1.0)
ocr texto completo del OCR + TrustVector (procedencia)
source metadatos Sidecar integrados: taxonomía V7GUID, tenant/categoría, esfera, ubicaciones de almacenamiento, etiquetas, finalidad, FZul, referencias de GCPN
signature firmante, procedimiento (§ 126b BGB), referencia del facsímil
phases ciclo de vida como vector de bits de 32 bits: draft → presented → accepted → signed (verified ortogonal)

Seguridad ante revisiones — Cumplimiento nativo de Git

Ejemplo (serie: organización ficticia KMU)

El gerente de KMU ofrece una consumición a un representante de una editorial técnica después de una feria sectorial para hablar de una posible publicación. Se escanea el recibo del restaurante por 59,80 €; mediante OCR se identifica el tipo de comprobante BUSINESS_MEAL_RECEIPT. El recibo propio se crea como *.gcsig.md (participantes, motivo „Feria sectorial — posible publicación“, importe, esfera ideell, sin deducción de impuestos indirectos, contabilización como reembolso de gastos) y se presenta al gerente para su firma.

Herramientas

Herramienta Tarea
gc-sidecar scan capturar el documento original (SHA-256), determinar el texto del OCR y el nivel de confianza
gc-sidecar detect reconocer el tipo de comprobante a partir del texto del OCR (basado en reglas)
gc-docsign gcsig generar/incrustar *.gcsig.md (--content, --ocr, --source, --facsimile) y establecer las fases

Referencias