## id doc_enllac_pagament_factura ## nom Enllaç de pagament d'una factura — comportaments i casos concrets ## descripcio Consulta aquest document quan calgui explicar amb precisió per què l'opció de pagament d'una factura concreta apareix desactivada, la diferència exacta entre l'enllaç puntual i el recurrent, o com decideix FiskAppCloud si cobra automàticament en lloc d'oferir cap enllaç. No és l'explicació general, que cobreix `flux_enllac_pagament_factura`. ## contingut ### L'ordre exacte de les comprovacions `FacturaPagamentDecisionService.Decidir` és una funció pura (no consulta res, rep els fets ja resolts) que decideix, a partir d'un únic conjunt de dades d'entrada, tres coses alhora: si es pot oferir un enllaç puntual, si se'n pot oferir un de recurrent, i si cal programar un cobrament automàtic. `FacturaEnllacPagamentService.ObtenirDecisioAsync` és qui resol prèviament aquests fets (consultant la base de dades) i li'ls passa. Les dades que es resolen abans de decidir: 1. **Mitjà de pagament habitual del client per a aquesta activitat** (`AuxiliarActivitatPagaments`, filtrat per `Actiu`). Si el client no en té cap configurat per aquesta activitat concreta, la resta de comprovacions ni s'arriben a fer — el resultat és directament "cap opció disponible". 2. **Si aquest mitjà està habilitat per pagament puntual** — es mira a `EmpresaMedisPagament` o a `ActivitatMedisPagament`, segons si `Activitat.HeretaMedisPagament` és cert (empresa) o fals (pròpia de l'activitat). En qualsevol dels dos casos, cal que el mitjà estigui `Actiu`, `VisiblePortal` i amb `PermetPagamentPuntual` marcat. 3. **Si hi ha un TPV Virtual assignat i actiu per a l'activitat**, i si aquesta configuració permet tokenització i recurrència (`PermetTokenitzacio`, `PermetRecurrencia`). 4. **Si ja existeix un testimoni de targeta vigent** per aquell client+activitat+configuració de TPV (`AuxiliarActivitatTpvTokens`, `Estat == Vigent`, sense caducar). ### Per què "Domiciliació Bancària" mai genera enllaç Encara que un client tingui domiciliació bancària com a mitjà habitual actiu i correctament configurat a nivell d'empresa/activitat, **mai se li oferirà cap enllaç de pagament** — és una exclusió explícita al codi (`esDomiciliacio` es comprova abans de `permetPuntual`). Els cobraments per domiciliació només es gestionen per Remeses (`flux_remeses`); mesclar-ho amb un enllaç de pagament puntual crearia dues vies de cobrament incompatibles per al mateix rebut. ### L'enllaç puntual no fixa el mitjà de pagament final Que el mitjà **habitual** del client sigui, per exemple, "Targeta", només decideix si es pot **oferir** el botó de l'enllaç — un cop el client hi entra des del Portal, pot triar qualsevol mitjà de pagament puntual que el Portal li mostri disponible per a aquella activitat (targeta, Bizum...), no necessàriament el que tenia marcat com a habitual. El mitjà habitual és una condició d'accés, no una restricció del que es pot pagar. ### Recurrent vs. cobrament automàtic (MIT): mai els dos alhora Aquests dos només tenen sentit per a factures de subscripcions, amb mitjà habitual "Targeta" i un TPV amb recurrència disponible. La diferència és si ja existeix un testimoni vigent: - **Sense testimoni vigent encara**: s'ofereix l'enllaç **recurrent** — el client l'obre, paga i FiskAppCloud guarda el testimoni de la seva targeta per a properes factures. - **Amb testimoni vigent i factura ja validada**: FiskAppCloud **no ofereix cap enllaç** — cobra directament amb el testimoni guardat (MIT), sense que el client hagi de fer res. - **Amb testimoni vigent però factura encara no validada**: no es programa el cobrament automàtic (exigeix `FacturaValidada`) ni tampoc s'ofereix l'enllaç recurrent (ja hi ha testimoni) — en aquest estat intermedi no s'ofereix cap de les dues opcions fins que la factura es validi. ### Prioritat quan s'envia una factura per correu automàticament Quan una factura s'envia sola per correu (sense intervenció manual), i podrien aplicar diverses opcions alhora, l'ordre de prioritat és: 1. Enllaç **recurrent**, si aplica. 2. Cap enllaç, si ja toca cobrament automàtic (MIT) — no té sentit oferir-ne un si ja es cobrarà sol. 3. Enllaç **puntual**, si aplica. 4. Cap opció, si no es compleix res de l'anterior. ### Requisits addicionals només per generar l'enllaç de debò (no per decidir si es pot oferir) Fins i tot complint tota la cadena anterior, generar l'enllaç real exigeix a més: - Que la factura no estigui anul·lada i tingui un estat vàlid (esborrany, validada, o equivalent). - Que la factura tingui **import pendent de cobrar** superior a 0,005 € (marge de tancament decimal) — una factura ja totalment cobrada no genera enllaç. - Que el Portal de Clients estigui **activat per a l'empresa** (`PortalEmpreses.Actiu`) i que hi hagi una URL pública del Portal configurada (`Portal:PublicBaseUrl`) — sense això, la generació falla encara que tota la resta estigui bé. ## comprovacions Si el botó de generar/copiar enllaç apareix desactivat i l'empresa/activitat semblen ben configurades: - comprova primer si el client té un mitjà de pagament habitual **actiu** assignat per a aquesta activitat concreta (fitxa del client, botó "Pagaments") — és la comprovació que es fa primer i bloqueja tota la resta si falta. - comprova que aquest mitjà no sigui "Domiciliació Bancària" — mai genera enllaç. - comprova, segons si l'activitat hereta la configuració de l'empresa o no, la taula que correspongui (`EmpresaMedisPagament` o `ActivitatMedisPagament`). Si un usuari pregunta per què no li surt l'opció "recurrent" en una subscripció que sí té targeta configurada: - comprova si ja existeix un testimoni vigent — en aquest cas no es torna a oferir l'enllaç recurrent, es cobra sol (o s'espera a validar la factura si encara no ho està). Si la factura té import pendent i tota la configuració és correcta però la generació falla igualment: - comprova que el Portal estigui activat per a l'empresa i que `Portal:PublicBaseUrl` estigui configurat.