P0 — Modo dual de facturación (estándar / Verifactu demo) - #1
Merged
Conversation
Plan incremental para el vertical de electricista + facturación de uso real: P0 modo dual de facturación, P1 partes de trabajo, P2 mediciones en el CIE, P3 PWA offline, P4 tarifas de material, P5 (solo diseño) verticales VE/FV. Incluye avisos de la revisión del código (QR de pruebas en toda factura, falta perfil fiscal del emisor), tabla de PRs, complejidad y deuda técnica anticipada. Incremental roadmap for the electrician vertical + real-use invoicing: P0 dual billing mode, P1 work orders, P2 CIE measurements, P3 offline PWA, P4 material tariffs, P5 (design only) EV/PV verticals.
ES
--
Hasta ahora TODA factura salia con el QR del host de PRUEBAS de la AEAT y la
leyenda «Verifactu», porque InvoiceService escribe siempre un registro y el PDF
imprimia el QR cuando existia. Una factura real del piloto para su cliente
saldria con un QR de preproduccion. El modo dual lo arregla.
- User.billingMode por usuario ('standard' por defecto / 'verifactu' demo) +
perfil fiscal del emisor (businessName, fiscalAddress; el NIF ya existia) para
que una factura ordinaria RD 1619/2012 este completa. La migracion rellena las
filas existentes a 'standard' (columna con DEFAULT, nunca NOT NULL sin default).
- InvoicePdf::build(..., bool $showVerifactu): el QR + leyenda solo en modo demo;
el PDF estandar es una factura ordinaria con el perfil del emisor. Los
endpoints /qr y /xml devuelven 403 en modo estandar.
- La cadena de hash vive en AMBOS modos. VerifactuHasher::fingerprint() NO
incluye el modo, asi que cambiar de modo nunca reescribe una huella y
GET /api/invoices/verify sigue en verde sobre facturas preexistentes. Hay un
test de regresion que lo comprueba.
- AccountController: GET/PUT /api/account/settings (modo + perfil emisor).
- UI en espanol y no tecnica: selector de modo en Cuenta -> Facturacion; la
pestana de facturas oculta QR/XML/cadena en estandar y muestra un aviso DEMO
en Verifactu; el PDF siempre se puede descargar.
- Fecha de obligacion verificada contra el BOE: autonomos desde el 1-jul-2027
(RD-ley 15/2025); opcional en 2026.
Tests: 85 (379 aserciones). Docs: ADR 0004, guia 38, DEVLOG 048.
EN
--
Until now EVERY invoice shipped with the AEAT TEST-host QR and a "Verifactu"
legend, because InvoiceService always writes a record and the PDF printed the QR
when one existed. A real invoice for the pilot's real client would carry a
pre-production QR. The dual mode fixes it.
- Per-user User.billingMode ('standard' default / 'verifactu' demo) + issuer
fiscal profile (businessName, fiscalAddress) so a standard RD 1619/2012 invoice
is complete. Migration backfills existing rows to 'standard'.
- InvoicePdf::build(..., bool $showVerifactu): QR + legend only in demo mode;
/qr and /xml return 403 in standard mode.
- The hash chain runs in BOTH modes; the fingerprint does not include the mode,
so switching mode never breaks GET /api/invoices/verify over pre-existing
invoices (regression test asserts it).
- Account settings endpoints; Spanish non-technical UI; DEMO banner in Verifactu.
- Obligation date verified against the BOE: autonomos from 2027-07-01.
Tests: 85 (379 assertions). Docs: ADR 0004, guide 38, DEVLOG 048.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Primer PR del PLAN-v2 (aprobado). Implementa el P0: modo dual de facturación para que el piloto emita facturas reales por defecto.
Qué resuelve
Hasta ahora toda factura salía con el QR del host de pruebas de la AEAT y la leyenda «Verifactu», porque
InvoiceServiceescribe siempre un registro y el PDF imprimía el QR cuando existía. Una factura real del piloto para su cliente saldría con un QR de preproducción.Cambios
User.billingMode(standardpor defecto /verifactudemo) + perfil fiscal del emisor (businessName,fiscalAddress) → factura ordinaria RD 1619/2012 completa. Migración conDEFAULT 'standard'(rellena filas existentes).InvoicePdf: QR + leyenda solo en modo demo./qry/xml→ 403 en modo estándar.VerifactuHasher::fingerprint()no incluye el modo → cambiar de modo nunca rompeGET /api/invoices/verifysobre facturas preexistentes (test de regresión).AccountController:GET/PUT /api/account/settings.Normativa (verificada contra el BOE)
Verifactu es opcional en 2026; autónomos obligados desde el 1-jul-2027 (RD-ley 15/2025). Factura ordinaria válida hoy (RD 1619/2012). Ver ADR 0004.
Verificación
/qr·/xml403, gating del PDF.doctrine:schema:validateen sync.Docs
ADR 0004, guía 38, DEVLOG 048.
🤖 Generated with Claude Code