Les factures prenen la data del dia en què s'emeten

10 de novembre de 2026 — Fins ara, una factura conservava la data del seu esborrany encara que s'emetés setmanes després, i una sèrie podia acabar amb números fora de l'ordre de les dates. Des d'avui, emetre una factura li posa la data del dia en què s'emet. Val alhora per a l'API v1 i per a MCP, sense període d'avís.

Què canvia

• issued_on és el dia d'emissió — en emetre una factura, issued_on passa a ser aquell dia natural a Europe/Madrid, tingués el que tingués l'esborrany, anterior o posterior. A partir d'aleshores és immutable.
• La data de l'esborrany passa a operation_on — si la data de l'esborrany era anterior al dia d'emissió i operation_on era buit, la data de l'esborrany es conserva a operation_on. Un operation_on que ja havies enviat es conserva. Una data d'esborrany posterior al dia d'emissió se substitueix i no passa a operation_on.
• No es recalcula res més — due_on i payment_terms es queden com estaven.

Per exemple, emetent el 2026-11-10:

Programades, recurrents i lots

• Factures programades — una factura que programes surt amb la data del dia en què s'executa, no la de l'esborrany ni la del dia en què la vas programar. La data del seu esborrany no passa a operation_on; un operation_on que vas enviar es conserva.
• Factures recurrents — quan el generation_mode de la factura recurrent és issue o issue_and_send, generate crea la factura ja emesa, amb la data del dia d'emissió. Una data de generació anterior es conserva a operation_on.
• Els lots emeten de la data més antiga a la més recent — bulk-status a issued (o el seu àlies sent) i bulk-send, que emet els esborranys abans d'enviar-los, processen les factures per la data del seu esborrany, i per antiguitat si dues dates coincideixen, amb independència de l'ordre d'ids. El número més baix va a la data més antiga. failures[] surt en aquest ordre de processament, no en el que vas enviar.
• bulk-create no emet — només crea esborranys, així que en aquesta operació issued_on continua sent la data de l'esborrany.

Un 422 nou protegeix l'ordre de la sèrie

Una factura mai no s'emet amb una data anterior a la de l'última factura emesa de la seva sèrie. La crida respon 422, error.code: business_rule_violation i error.subcode: issue_date_before_series_last_issue_date, amb error.param: issued_on. No es consumeix número i l'esborrany queda com estava.

{
  "error": {
    "type": "invalid_request_error",
    "code": "business_rule_violation",
    "subcode": "issue_date_before_series_last_issue_date",
    "message": "No se puede emitir con fecha 10/11/2026: la serie ya tiene una factura emitida con fecha 12/11/2026.",
    "param": "issued_on",
    "doc_url": "https://docs.factuarea.com/guides/errors#business_rule_violation",
    "request_id": "req_01KFPT3RM5H7J9K2M4N6P8Q0RS"
  }
}

El dia d'emissió és ara sempre avui, així que només passa quan la sèrie ja té una factura amb data futura, cosa que l'API v1 permetia fins ara, o, en casos rars, quan el rellotge del servidor retrocedeix. Canviar issued_on no ho resol. Passa l'esborrany a una altra sèrie del mateix tipus amb series_id, o emet-lo quan arribi la data d'aquella última factura.

• On pots rebre-ho — create amb opcions que emeten, payment o type: F2; issue; send sobre un esborrany; mark-sent a les versions de l'API anteriors a 2026-10-01; bulk-send; i generate en una factura recurrent amb un mode que emet. Si vas crear la factura amb options, l'esborrany ja existeix: emet aquest esborrany en lloc de repetir l'alta.
• Lots — bulk-status notifica la fila rebutjada a failures[] amb error_code business_rule_violation i sense subcodi, i continua amb les altres. bulk-send fa el mateix a les empreses amb presentació amb revisions; a les altres, el rebuig avorta la crida amb aquest 422, les factures anteriors ja estan emeses i les posteriors no es processen.
• Factures programades — la que la regla rebutja en executar-se no s'emet: continua en scheduled, no consumeix número i es torna a provar a la passada següent.

Els models fiscals compten per la data de meritació

Emetre conserva ara a operation_on una data d'esborrany anterior, així que moltes més factures porten un operation_on diferent d'issued_on. Perquè una factura no canviï de trimestre només per emetre's més tard, el Modelo 303 i el Modelo 130, a l'API v1 i a MCP, assignen ara cada factura de venda al període del seu operation_on quan en té i, si no, al del seu issued_on.

• Modelo 303 i Modelo 130 — i les seves vistes prèvies. El 130 és acumulat, així que una venda hi entra des del trimestre de la seva data de meritació i compta una sola vegada.
• Factures rectificatives — compten sempre per la seva pròpia issued_on, perquè la seva diferència es declara al període en què s'emeten.
• Modelo 347 — no canvia: continua assignant per issued_on.
• Despeses — no canvien.

Per exemple, una factura amb operation_on 2026-09-28 i issued_on 2026-10-05 compta al 303 del tercer trimestre i no al del quart. Al 347 compta al quart trimestre.

Un model ja generat no es reescriu. Generar o previsualitzar de nou un període que ja ha passat pot donar un altre resultat: una factura emesa després l'operation_on de la qual cau en aquest període hi compta ara. Les operacions que generen i previsualitzen els models conserven la seva forma i la seva descripció, així que no són entre les operacions actualitzades d'aquí sota; el que canvia és quines factures entren a cada període. Quina data decideix el període recull la regla de cada model.

Comandes de botiga

La factura que Factuarea crea automàticament per a una comanda de botiga, de WooCommerce o de Shopify, neix emesa amb la data del dia d'emissió, com qualsevol altra. El dia de la comanda, a la zona horària de l'aplicació, es conserva a operation_on quan és anterior. Una comanda amb data futura, per un desfasament del rellotge del proveïdor, surt amb la data d'avui i sense operation_on.

• La data ja no s'ajusta a la sèrie — fins ara la data de la comanda es movia a la de l'última factura numerada de la sèrie i es registrava un esdeveniment d'integració amb discard_reason series_date_clamped. Això ja no passa. El valor continua a l'enum de discard_reason, i com a filtre de GET /v1/companies/{company}/integrations/events, perquè els esdeveniments anteriors al canvi el conserven. La safata d'esdeveniments d'integració el llista com a retirat.
• La regla d'ordre de dates pot rebutjar la factura — si la regla de dalt rebutja la factura d'una comanda, perquè la sèrie té una factura emesa amb data futura, la comanda no es factura sola i no es consumeix número. Queda registrada als esdeveniments d'integració amb estat skipped i sense discard_reason: el seu error_message diu que la comanda no és elegible per a facturació automàtica i per què. Queda per a revisió manual i no es reintenta, i is_replayable és false. És el tractament que ja tenia qualsevol regla de negoci que rebutja la factura d'una comanda. Factura-la a mà en una altra sèrie, o quan arribi la data d'aquella última factura.

Què revisar a la teva integració

• Llegeix les dates de la resposta — si enviaves un issued_on passat esperant que es conservés, ara issued_on torna com el dia d'emissió i la data que vas enviar és a operation_on. Pren les dues de la resposta d'issue o create, o de la factura que llegeixis després.
• Dates futures — un issued_on futur ja no sobreviu: la factura surt amb la data d'avui i sense operation_on. Si a més enviaves un operation_on posterior al dia d'emissió, emetre respon operation_date_after_issue_date, tret que la primera línia que declara un regime_key faci servir 14 o 15.
• Sèries amb dates futures — una sèrie que ja té una factura amb data futura rebutja qualsevol emissió fins que arribi aquell dia. Fes servir una altra sèrie o espera. Anul·lar aquella factura no desbloqueja la sèrie, perquè les anul·lades compten.
• Quina data va on — si importa el dia en què es va fer el servei, envia'l com a operation_on a l'esborrany. L'issued_on d'un esborrany és només la data de l'esborrany.
• MCP — les tools es comporten com les seves operacions i retornen el mateix error: issue_invoice, send_invoice, create_invoice, bulk_change_invoice_status, bulk_send_invoices, bulk_create_invoices, schedule_invoice i generate_recurring_invoice. La descripció d'update_invoice ara diu que issued_on és la data de l'esborrany. El guardrail emision-borrador-a-emitida, llistat a Recursos i prompts, explica la regla.

Operacions actualitzades

Les descripcions d'issued_on i operation_on canvien al recurs de factura i als cossos de crear i actualitzar. Aquestes nou operacions canvien la seva descripció, i les sis que poden respondre el 422 nou el declaren:

• POST /v1/companies/{company}/invoices — crear amb opcions que emeten, payment o type: F2 data la factura el dia d'emissió. Declara el 422 nou.
• POST /v1/companies/{company}/invoices/bulk-create — les seves files són esborranys i mai no s'hi emeten.
• POST /v1/companies/{company}/invoices/bulk-send — els esborranys s'emeten de la data més antiga a la més recent, amb la data del dia d'emissió. Declara el 422 nou.
• POST /v1/companies/{company}/invoices/bulk-status — l'emissió va de la data més antiga a la més recent, i cada factura pren la data del dia d'emissió.
• POST /v1/companies/{company}/invoices/{invoice}/issue — la factura surt amb la data del dia d'emissió. Declara el 422 nou.
• POST /v1/companies/{company}/invoices/{invoice}/mark-sent — a les versions de l'API anteriors a 2026-10-01 emet l'esborrany amb la mateixa regla. Declara el 422 nou.
• POST /v1/companies/{company}/invoices/{invoice}/schedule — la factura surt amb la data del dia en què s'executa, i continua programada si la sèrie té una factura emesa posterior.
• POST /v1/companies/{company}/invoices/{invoice}/send — un esborrany s'emet primer, amb la data del dia d'emissió. Declara el 422 nou.
• POST /v1/companies/{company}/recurring-invoices/{recurring_invoice}/generate — amb un mode que emet, la factura neix emesa, amb la data del dia d'emissió. Declara el 422 nou.