Una sola ventana de rotura: eje y payload

30 de septiembre de 2026 — el contrato de la v1 rompe en cinco sitios a la vez, y esta publicación anuncia los cinco juntos porque son una sola migración: el código que tocas por cualquiera de ellos es el que tocas por los otros cuatro. No habrá una segunda ventana.

• El eje viaja en la URL. Un recurso de empresa vive ahora bajo /v1/companies/{company}/… y uno de cuenta bajo /v1/accounts/{account}/…. La empresa efectiva deja de deducirse de la credencial y va en la ruta, donde se ve, se registra y se audita.
• Los importes viajan como cadenas decimales. Cada campo monetario de un payload publicado es una cadena, ya no un número JSON.
• La fecha de cobro cambia de nombre. paid_at y paid_on desaparecen del payload publicado. Una factura y una factura de compra publican paid_recorded_at y paid_date.
• X-Active-Profile queda retirada. Una petición que aún lleve la cabecera se rechaza con 400 parameter_unknown, subcódigo retired_active_profile_header, antes de llegar al controlador.
• La cuenta pasa a ser el cliente. Un NIF cambia de manos con un traspaso (nif-transfers), las personas de una cuenta son miembros con grants por NIF, un NIF extra es un NIF adicional (paid_until sustituye a seat_paid_until, y tres códigos de error cambian de nombre), y se retiran las API keys emitidas por empresa y las escrituras del catálogo de impuestos.

Esta página enumera todas las operaciones que la ventana toca, recurso por recurso: 519 filas en total — 49 nuevas, 294 movidas al eje con solo su ruta cambiada, 161 movidas con cambios añadidos, 11 retiradas y 4 intactas. Una ruta es su verbo y su path, así que las treinta y tres operaciones de la tabla de verbos cuentan como movidas aunque no cambie nada más en ellas. El contrato resultante, junto con las operaciones que se sumaron después al eje, publica 664 operaciones vivas en 51 recursos, y cada cifra de esta página sale de ese contrato, no de un resumen suyo.

De dónde sale el id de la empresa

El segmento de empresa lleva el id opaco de la empresa, nunca su NIF. GET /v1/me publica una entrada por cada NIF que alcanza tu credencial, y su id es exactamente lo que va en la ruta:

{
  "data": {
    "object": "me",
    "account": {
      "id": "01931b3e-7c4a-7f2e-9a8b-3c5d6e7f8a00",
      "name": "Asesoría Martínez",
      "environment": "live",
      "is_provider": true,
      "privileged_scopes": [
        "accounts:read",
        "accounts:write"
      ]
    },
    "api_key": {
      "id": "019e81ef-e1d4-7208-a51d-94c2c2a54a84",
      "name": "Producción",
      "prefix": "fact_live_1OSf9KdP",
      "scopes": [
        "account:read",
        "series:read",
        "series:write"
      ],
      "tier": "scale",
      "environment": "live",
      "created_at": "2026-01-15T09:30:00Z",
      "last_used_at": "2026-05-25T18:00:00Z",
      "expires_at": null
    },
    "scope": [
      {
        "id": "01931b3e-7c4a-7f2e-9a8b-3c5d6e7f8a01",
        "tax_id": "B12345674",
        "name": "Acme Corporation"
      },
      {
        "id": "01931b3e-7c4a-7f2e-9a8b-3c5d6e7f8a02",
        "tax_id": "B87654323",
        "name": "Acme Logística S.L."
      }
    ],
    "client_accounts": [
      {
        "id": "0199a1f0-1c22-7a10-b111-5a5b5c5d5e5f",
        "name": "Construcciones Ruiz",
        "origin": "granted",
        "access_level": "view",
        "status": "active",
        "paid_by_provider": false,
        "environment": "live"
      },
      {
        "id": "0199a1f0-1c22-7a10-b111-6a6b6c6d6e6f",
        "name": "Talleres García",
        "origin": "provisioned",
        "access_level": "operate",
        "status": "provisioned",
        "paid_by_provider": true,
        "environment": "live"
      }
    ],
    "client_accounts_visible": true,
    "client_accounts_has_more": false
  }
}

GET /v1/me es además el sustituto de GET /v1/account, que ya no existe, y no exige ningún scope: cualquier credencial válida puede introspeccionarse. data.account.id va en el segmento de cuenta; cada data.scope[].id va en el segmento de empresa. Cuando tu cuenta provisiona cuentas gestionadas, o otras cuentas le cedieron acceso, data.client_accounts[] lista las cuentas de clientes que alcanza, con su origin, su access_level y su status y si tu cuenta las paga. Solo se rellena cuando la clave lleva el scope privilegiado accounts:read: sin él la lista va vacía y client_accounts_visible es false. Llámalo una vez al arrancar y guarda la correspondencia: es estable.

Eje de empresa — /v1/companies/{company}/<recurso>

Del segmento de empresa cuelgan 44 familias de recursos, 359 rutas y 432 de las operaciones de la ventana:

Eje de cuenta — /v1/accounts/{account}/<recurso>

El segmento de cuenta lleva el id de tu propia cuenta, data.account.id de GET /v1/me; en una lista cerrada de rutas admite también el id de una cuenta gestionada tuya. Del segmento cuelgan 16 familias de recursos, 49 rutas y 65 de las operaciones de la ventana:

claim-tokens conserva su fila en la tabla, pero ya no es el traspaso de NIF: POST /v1/accounts/{account}/claim-tokens reemite el vale de reclamación de una cuenta gestionada. El traspaso es nif-transfers, y sus scopes y sus códigos se renombran igual: nif_transfers:read, nif_transfers:write, nif_transfer_expired y nif_transfer_invalid. Las rutas claim-tokens del traspaso, los scopes claim_tokens:* y los códigos claim_token_* de las compilaciones previas de este contrato no existen en el definitivo.

Raíz — sin eje

Diez rutas no pertenecen ni a una empresa ni al eje de tu propia cuenta, y entre todas llevan once operaciones. Cinco son introspección y catálogos, y solo una se movió: GET /v1/me sustituye a GET /v1/account. Las otras cinco son la raíz de aprovisionamiento, nueva en esta ventana: ahí el recurso es una cuenta gestionada o una importación masiva, así que no cuelga de ningún eje.

El propio contrato, /v1/openapi.json, también sigue donde estaba.

Cinco trampas antes de reescribir una URL

1. El guion bajo pasa a guion. Cinco recursos cambian de separador al moverse: tax_reports, purchase_invoices, recurring_invoices, delivery_notes y webhook_endpoints pasan a tax-reports, purchase-invoices, recurring-invoices, delivery-notes y webhook-endpoints. Cuatro segmentos de acción los siguen: dry_run, mark_paid, rotate_secret y test_event pasan a dry-run, mark-paid, rotate-secret y test-event. Ningún segmento de ruta del contrato conserva un guion bajo.
2. Familias que esperarías en la raíz están en el eje de empresa. Festivos, el catálogo de automatizaciones y sus campos por disparador, la facturación del plan, la verificación censal, la personalización, las entregas de correo, los eventos, los registros de peticiones y los cuatro listados de estados de documento (invoices, quotes, proformas y delivery-notes publican cada uno su statuses) parecen catálogos globales y no lo son: su respuesta depende de la empresa.
3. {company} no siempre es el eje, y {account} no siempre es la cuenta. En /v1/accounts/{account}/companies/{company}/… —los NIF de una cartera— y en /v1/accounts/{account}/members/{member}/grants/{company} —el grant de un miembro sobre un NIF—, {company} es el recurso al que apuntas, así que lo escribes aunque tu credencial alcance una sola empresa. Y en /v1/companies/{company}/connected-accounts/{account}, {account} es una cuenta conectada de Stripe. Catorce operaciones llevan los dos parámetros: distínguelos por la ruta, nunca por el nombre del parámetro.
4. Los webhooks de empresa, los eventos, los correos, los registros de peticiones y la facturación del plan son recursos de empresa, no de cuenta. En el eje de cuenta están las API keys, los miembros (con sus grants y su acceso por módulo), las invitaciones, los traspasos de NIF, los asientos de empleado, la cartera de NIF, su consumo, su titular, las rutas de aprovisionamiento de una cuenta gestionada y, nuevos en esta ventana, los webhooks y los registros de peticiones de la propia cuenta: /v1/accounts/{account}/webhooks no es /v1/companies/{company}/webhook-endpoints, y sus operaciones difieren. Consulta la guía de webhooks de cuenta.
5. Bajo /v1/accounts/{account}/…, {account} es tu propia cuenta. Solo una lista cerrada de rutas admite también el id de una cuenta gestionada tuya —las rutas de aprovisionamiento y los datos de sus NIF—; cualquier otro id de cuenta, exista o no, responde el mismo 404 account_not_found. La raíz de aprovisionamiento es distinta: en /v1/accounts y en GET /v1/accounts/{account} la cuenta es el propio recurso. Consulta la guía de cuentas gestionadas.

Dieciséis operaciones que la ventana añade

Abren el eje de cuenta, que no tenía superficie pública propia más allá de las API keys: el traspaso de NIF, el equipo con sus invitaciones, la titularidad, el consumo y, bajo la cartera, la aptitud de emisión de un NIF. Son rutas nuevas, así que nada de lo que hoy existe rompe por ellas.

No son las únicas operaciones nuevas. La ventana publica 49 en total, y las otras treinta y tres pertenecen al modelo de cuentas —aprovisionamiento y cuentas gestionadas, importación masiva, webhooks y registros de peticiones de cuenta, los grants de un miembro sobre cada NIF y la revocación de un traspaso, entre otras—. La nota de la publicación modelo de cuentas las describe, y sus filas están en el inventario del final de esta página.

Los códigos invitation_expired, invitation_not_found, member_is_last_owner, nif_transfer_expired y nif_transfer_invalid forman parte de los treinta y siete códigos de error nuevos que se listan más abajo.

Once operaciones que la ventana retira

Cinco son las API keys emitidas por empresa, que desaparecen. Una key es una credencial de la cuenta, no de una de sus empresas, y las operaciones que sobreviven lo dicen en la ruta y en el scope: api_keys:read / api_keys:write dejan paso a account:read / account:write, que es lo que ya usaba el eje de cuenta.

scoped_company_ids es un campo nuevo del body de POST /v1/accounts/{account}/api-keys: ahí es donde se restringe una key a una parte de la cartera, que es justo lo que hacía la ruta por empresa.

El catálogo de impuestos pasa a ser de solo lectura

Las otras seis operaciones retiradas son las escrituras del catálogo de impuestos. El catálogo es común a toda la plataforma, así que una credencial de empresa que lo editaba lo editaba para todas las empresas; ahora solo lo escribe la administración de la plataforma.

No tienen sustituto. Las lecturas se quedan: GET /v1/companies/{company}/taxes y sus hermanas en el eje de empresa, y GET /v1/tax-catalog en la raíz. Una llamada a una escritura retirada responde 405 method_not_allowed donde su ruta aún sirve una lectura, y 404 route_not_found donde no. Los scopes taxes:write y taxes:delete siguen en el catálogo de scopes, pero ninguna operación los exige ya: concederlos no da acceso a nada.

Clientes y proveedores siguen retirados

/v1/clients y /v1/suppliers se retiraron antes de esta ventana, con la llegada de los contactos canónicos, y no vuelven en el eje. Un NIF es un contacto, y los roles customer y supplier se acumulan sobre él:

• Clientes: GET /v1/companies/{company}/contacts?roles[]=customer
• Proveedores: GET /v1/companies/{company}/contacts?roles[]=supplier

Las familias de scopes clients:* y suppliers:* quedan sustituidas por contacts:read, contacts:write y contacts:delete.

Treinta y tres operaciones cambian de verbo

Treinta y dos pasan de PUT a PATCH: ya aceptaban un body parcial, así que el verbo mentía. El body no cambia; solo el método. La actualización de facturas recurrentes es una de ellas: todos los campos son opcionales y el omitido se conserva. La restante, contacts.restore, pasa a POST: es una acción sin body, como archive y unarchive, no una actualización parcial. Tras esta ventana el único PUT del contrato es una operación nueva, PUT /v1/accounts/{account}/members/{member}/grants/{company}, que crea o sustituye el grant de un miembro sobre un NIF.

Treinta y siete códigos de error nuevos

El catálogo pasa de 376 a 410 códigos: llegan treinta y siete y se retiran tres (siguiente sección). Treinta de los nuevos pertenecen a la superficie de cuenta, cuatro a la puerta del NIF adicional, dos al acceso que tiene sobre un NIF la persona que emitió una key, y uno a los webhooks de cuenta.

nif_transfer_expired y nif_transfer_invalid ocupan el lugar de claim_token_expired y claim_token_invalid, los códigos del traspaso claim-tokens de las compilaciones previas, que ya no existen.

Aparte, 190 de las operaciones que ya existían documentan ahora un 404 que antes no documentaban: un segmento de eje que nombra una empresa o una cuenta que tu credencial no alcanza responde 404, no 403, de modo que la API nunca confirma la existencia de una empresa que no puedes ver. Toda operación del eje de empresa documenta 404 profile_not_found para ello; una cuenta que no alcanzas responde 404 account_not_found.

Tres códigos de error que la ventana retira

El NIF adicional sustituye al cargo por asiento de cada empresa y a sus puertas de plan y de módulo, así que tres códigos salen del catálogo. Ramifica según el sustituto: el estado y el error.type son los mismos en cada pareja.

Payload: importes, fechas y cobertura

Cada importe es una cadena decimal

123 propiedades monetarias repartidas en 40 esquemas publicados pasan de número JSON a cadena: totales, subtotales de línea, impuestos, retenciones, recargos, precios y costes unitarios, importes cobrados y pendientes, estadísticas, cifras de payouts, vistas previas de cargo y los umbrales de la factura simplificada. La cadena lleva dos decimales, punto como separador, sin separador de millares ni símbolo de moneda; la moneda conserva su campo currency. La única excepción es el unit_price de una línea de documento, que conserva la escala de cuatro decimales con la que se guarda ("100.0000"), de modo que leer una línea y reenviarla nunca cambia su precio; los importes derivados de la línea (subtotal, taxes y total) conservan dos.

{
  "object": "invoice",
  "subtotal": "1000.00",
  "total_vat": "210.00",
  "total": "1210.00",
  "paid_amount": "1210.00",
  "pending_amount": "0.00",
  "currency": "EUR"
}

Un número JSON no declara escala: 1210 vuelve como 1210, 1210.0 o 1209.9999999999998 según quién lo parsee. Lee cada campo de dinero a un tipo decimal de precisión fija — Decimal en Python, un big decimal o unidades mínimas en JavaScript — y jamás a un float binario. Los esquemas afectados son BusinessContactActivity, CompanySeatChargePreview, DeliveryNote, DeliveryNoteLine, DeliveryNoteStats, EmployeeSeatBillingStatus, EmployeeSeatChargePreview, EventDataInvoicePaid, Invoice, InvoiceCorrective, InvoiceLine, InvoicePaymentDetail, InvoiceReminderPreview, InvoiceStats, ProductSalesAnalytics, ProductVariant, Proforma, ProformaLine, ProformaStats, PurchaseInvoice, PurchaseInvoiceLine, PurchaseInvoicePayment, PurchaseInvoiceStats, Quote, QuoteLine, QuoteStats, RecurringInvoice, RecurringInvoiceLine, RecurringInvoicePreviewDate, RecurringInvoiceStats, SimplifiedInvoiceEligibility, Store, StripeAutoinvoicedCorrective, StripeAutoinvoicedPayment, StripePayout, SupplierProductOffer, TaxCalculation, TaxTotals, TaxTotalsLine y VeriFactuRecord.

La fecha de cobro cambia de nombre

paid_at y paid_on desaparecen del payload publicado. No se emiten en paralelo ni se mantienen como alias: el sufijo _at marca un instante, y cada nombre canónico dice ahora de qué fecha se trata.

El body de la petición no cambia: mark-paid y el registro de pagos siguen tomando paid_on, una fecha YYYY-MM-DD, y el listado de facturas filtra por paid_on[gte], paid_on[lte], paid_on[gt] y paid_on[lt]. Envías paid_on y lees paid_date y paid_recorded_at.

La cobertura pagada de un NIF cambia de nombre

El recurso Company pierde seat_paid_until y publica paid_until: la fecha hasta la que el NIF está cubierto como NIF adicional de la cuenta (ISO 8601). Vale null cuando el NIF nunca se cobró o su cobertura caducó, y reactivarlo antes de esa fecha es gratis. El recurso gana además readiness, el mismo veredicto y los mismos bloqueos que issuing-readiness, y suspension_reason: payer_blocked cuando la cuenta que paga una cuenta gestionada tiene su facturación bloqueada, management_ended cuando la gestión terminó antes de que nadie asumiera el pago, y null en cualquier otro caso.

Las respuestas de creación declaran Location

Cuarenta y una operaciones responden 201 Created con una cabecera Location: la URL canónica, relativa al servidor, del recurso que creó la petición, con el segmento del eje dentro —para una factura, /v1/companies/{company}/invoices/{invoice} con los dos ids rellenos—. La cabecera no es nueva en el cable: veintidós de esas operaciones ya la enviaban sin declararla, y ahora el contrato lo dice. Cuatro de las cuarenta y una son operaciones nuevas. Sigue Location en vez de reconstruir la URL a partir de la respuesta.

La cabecera que ya no existe

X-Active-Profile se rechaza por presencia, nunca por su valor: un id bien formado, el id de una empresa que no alcanzas, un valor mal formado y una cadena vacía reciben el mismo error.

Ignorar la cabecera habría sido la opción «compatible» peligrosa: la llamada saldría bien y emitiría el documento con el NIF del titular de la credencial en vez del que pretendías, sin ninguna señal.

# Antes
curl https://api.factuarea.com/v1/invoices \
  -H "Authorization: Bearer $FACTUAREA_API_KEY" \
  -H "X-Active-Profile: $COMPANY_ID"

# Ahora
curl https://api.factuarea.com/v1/companies/$COMPANY_ID/invoices \
  -H "Authorization: Bearer $FACTUAREA_API_KEY"

Todo identificador público es un UUID v7

Todo id que devuelve la API, y todo identificador de una ruta, es un UUID v7: ordenado en el tiempo, así que ordenar por id sigue el orden de creación. Hay un único formato, sea cual sea el recurso.

• Los registros nuevos reciben siempre un UUID v7, también las facturas que se emiten automáticamente a partir de cobros de Stripe.
• Los identificadores que creas tú —el id de una configuración, un grupo de opciones o un valor de opción nuevos en products.create y products.update— tienen que ser UUID v7. Cualquier otra versión se rechaza con 422; un elemento existente conserva su identificador.
• Unos pocos registros antiguos —algunos documentos, configuraciones de producto y certificados de VeriFactu creados antes de que UUID v7 fuera la norma— reciben un UUID v7 nuevo en esta ventana. El id antiguo deja de responder en la API, así que vuelve a leer esos registros desde sus listados si guardaste sus ids. Los enlaces públicos de documentos que ya enviaste siguen funcionando y abren el documento con su identificador nuevo.

Idempotencia tras la mudanza

El mecanismo de replay no cambia y crece con la superficie. Las 287 escrituras publican Idempotent-Replayed y repiten la respuesta de una key repetida, y 130 declaran Idempotency-Key como obligatoria — trece más que antes de la ventana, porque el eje de cuenta y la superficie de aprovisionamiento suman escrituras irreversibles (emitir, canjear y revocar un traspaso de NIF, retirar a un miembro, transferir la titularidad, crear una cuenta gestionada, terminar su gestión, cambiar su plan, reemitir su vale, aplicar una importación, rotar el secreto de un webhook de cuenta y borrarlo) y unas pocas más que no son irreversibles pero merecen la misma protección (enviar y reenviar una invitación, reintentar la entrega de un webhook de cuenta y probar un endpoint). 69 quedan marcadas como irreversibles, nueve más que antes.

idempotency_key_reused es la que se movió: antes de esta ventana respondía 409, y ahora responde 422. La huella a la que se ata una key incluye la ruta, así que la misma key enviada a /v1/invoices y a /v1/companies/{company}/invoices no es un replay. Mientras migras, genera una key nueva por llamada en vez de reutilizar las que ya tenga tu cola. Lee la guía de idempotencia.

CLI, SDK de PHP y SDK de Node

Los tres se generan desde este contrato y se regeneran contra él: las rutas de recurso de la CLI, los métodos de operación del SDK de PHP y los del SDK de Node toman el segmento del eje como primer argumento, los importes vuelven como cadenas y la cabecera retirada ya no tiene opción en ninguno. Sus notas de versión apuntan a esta página en vez de describir una rotura propia.

Lista de migración

1. Llama a GET /v1/me y guarda data.account.id y cada data.scope[].id. Si trabajas para cuentas de clientes, lee también data.client_accounts[]: lista las cuentas que cedieron acceso a la tuya y las cuentas gestionadas que provisionaste, con el nivel que tienes sobre cada una.
2. Reescribe tus rutas base: recursos de empresa bajo /v1/companies/{company}/…, recursos de cuenta bajo /v1/accounts/{account}/…, la raíz de aprovisionamiento y las cinco rutas de catálogo e introspección en la raíz. Vigila los cinco renombrados de guion bajo a guion y los cuatro segmentos de acción que pierden el guion bajo.
3. Cambia PUT por PATCH en las treinta y dos operaciones de la tabla de verbos, y llama a contacts.restore con POST.
4. Quita X-Active-Profile de tu cliente. Si la usabas para operar sobre varias empresas, el segmento de empresa hace eso mismo por petición, sin cabecera.
5. Lee cada campo de dinero como cadena hacia un tipo decimal de precisión fija, con el unit_price de cuatro decimales de las líneas; lee paid_recorded_at y paid_date donde leías paid_at y paid_on, y sigue enviando paid_on; lee paid_until donde leías seat_paid_until.
6. Lleva cualquier llamada a las API keys de una empresa a /v1/accounts/{account}/api-keys, restringe la key con scoped_company_ids y cambia api_keys:* por account:read / account:write en tus keys.
7. Cambia claim-tokens por nif-transfers si integraste el traspaso de NIF contra una compilación previa: scopes nif_transfers:read y nif_transfers:write, códigos nif_transfer_expired y nif_transfer_invalid.
8. Trata los códigos de la puerta del NIF adicional: additional_nif_charge_failed donde tratabas seat_charge_failed, additional_nif_plan_required donde tratabas gestoria_plan_required, additional_nif_not_in_plan donde tratabas gestoria_module_required, y billing_managed_by_provider para una cuenta cuya facturación paga otra cuenta.
9. Trata los 403 del modelo de cuentas: privileged_scope_required, live_credential_required, company_read_only, emitter_capability_restricted, owner_transfer_forbidden, additional_nif_not_in_plan y billing_managed_by_provider. Ramifica según code, no según message.
10. Deja de llamar a las escrituras del catálogo de impuestos: léelo con GET /v1/companies/{company}/taxes o GET /v1/tax-catalog.
11. Añade los treinta y siete códigos nuevos y parameter_unknown a tu manejo de errores, lee idempotency_key_reused como un 422, y trata un 404 en un segmento de eje como «fuera de alcance», no como un fallo pasajero.
12. Repite tu integración con una key fact_test_ antes de mover tráfico real.
13. Si guardaste ids de registros creados antes de la ventana, vuelve a leerlos desde los listados: los pocos que aún tenían una versión de UUID antigua tienen ahora un UUID v7.

Lee Importes y fechas, Alcanzar un NIF por el segmento de empresa, Cuentas y NIF, NIF adicionales y Errores.

Cada operación, recurso por recurso

Operaciones: 519 — 49 nuevas, 294 movidas al eje, 161 movidas con otros cambios, 11 retiradas, 4 sin cambios.

Los cambios que alcanzan a 50 o más operaciones a la vez no se repiten en las filas de abajo: se documentan aquí una sola vez, con el número de operaciones que toca cada uno. Todo lo demás que cambió en una operación está en su fila.

Saldos de ausencia

Operaciones: 2 — 0 nuevas, 2 movidas al eje, 0 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Calendario de ausencias

Operaciones: 1 — 0 nuevas, 1 movidas al eje, 0 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Políticas de ausencia

Operaciones: 10 — 0 nuevas, 7 movidas al eje, 3 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Solicitudes de ausencia

Operaciones: 6 — 0 nuevas, 4 movidas al eje, 2 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Tipos de ausencia

Operaciones: 6 — 0 nuevas, 3 movidas al eje, 3 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Cuenta

Operaciones: 57 — 47 nuevas, 4 movidas al eje, 6 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Automatizaciones

Operaciones: 18 — 0 nuevas, 0 movidas al eje, 18 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Empresas

Operaciones: 19 — 2 nuevas, 0 movidas al eje, 12 movidas con otros cambios, 5 retiradas, 0 sin cambios.

Contactos

Operaciones: 27 — 0 nuevas, 2 movidas al eje, 25 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Albaranes

Operaciones: 22 — 0 nuevas, 19 movidas al eje, 3 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Registros de peticiones

Operaciones: 2 — 0 nuevas, 2 movidas al eje, 0 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Entregas de correo

Operaciones: 3 — 0 nuevas, 3 movidas al eje, 0 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Empleados

Operaciones: 17 — 0 nuevas, 8 movidas al eje, 9 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Eventos

Operaciones: 3 — 0 nuevas, 0 movidas al eje, 2 movidas con otros cambios, 0 retiradas, 1 sin cambios.

FacturaE / FACe

Operaciones: 5 — 0 nuevas, 4 movidas al eje, 1 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Festivos

Operaciones: 3 — 0 nuevas, 3 movidas al eje, 0 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Eventos de integración

Operaciones: 3 — 0 nuevas, 3 movidas al eje, 0 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Facturas

Operaciones: 48 — 0 nuevas, 25 movidas al eje, 22 movidas con otros cambios, 0 retiradas, 1 sin cambios.

VeriFactu

Operaciones: 27 — 0 nuevas, 24 movidas al eje, 3 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Cierres mensuales

Operaciones: 8 — 0 nuevas, 5 movidas al eje, 3 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Exportaciones de nómina

Operaciones: 2 — 0 nuevas, 1 movidas al eje, 0 movidas con otros cambios, 0 retiradas, 1 sin cambios.

Stripe

Operaciones: 10 — 0 nuevas, 9 movidas al eje, 1 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Presencia

Operaciones: 3 — 0 nuevas, 3 movidas al eje, 0 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Tarifas

Operaciones: 13 — 0 nuevas, 12 movidas al eje, 1 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Productos

Operaciones: 41 — 0 nuevas, 37 movidas al eje, 4 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Facturas proforma

Operaciones: 20 — 0 nuevas, 17 movidas al eje, 3 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Facturas de compra

Operaciones: 18 — 0 nuevas, 6 movidas al eje, 12 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Presupuestos

Operaciones: 20 — 0 nuevas, 17 movidas al eje, 3 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Facturas recurrentes

Operaciones: 18 — 0 nuevas, 15 movidas al eje, 3 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Series

Operaciones: 12 — 0 nuevas, 8 movidas al eje, 4 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Tienda Shopify

Operaciones: 1 — 0 nuevas, 1 movidas al eje, 0 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Tiendas

Operaciones: 5 — 0 nuevas, 4 movidas al eje, 1 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Impuestos

Operaciones: 18 — 0 nuevas, 11 movidas al eje, 0 movidas con otros cambios, 6 retiradas, 1 sin cambios.

Informes fiscales

Operaciones: 9 — 0 nuevas, 8 movidas al eje, 1 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Balances de jornada

Operaciones: 3 — 0 nuevas, 3 movidas al eje, 0 movidas con otros cambios, 0 retiradas, 0 sin cambios.

Correcciones de fichajes

Operaciones: 5 — 0 nuevas, 4 movidas al eje, 1 movidas con otros cambios, 0 retiradas, 0 sin cambios.