NT en SDR (Catalunya) — automática¶

En Catalunya las notificaciones de traslado se gestionan con el SDR de l'Agència de Residus de Catalunya (ARC). A diferencia de eSIR, aquí la NT es automática: al validar el CT, Odoo envía la Notificació Prèvia (NP) o la Fitxa d'Acceptació (FA) al SDR —según el traslado— y registra la respuesta. Tú no subes nada a mano.

🎯 Objetivo

Entender el flujo SDR de Catalunya, por qué el operador del traslado es el productor (centro), y qué se envía exactamente al activar el CT.

Antes de empezar

El CT debe estar en Borrador con plataforma SDR (se deduce sola por los NIMAs de origen/destino catalanes).
El centro gestor de destino debe tener su autorización SDR configurada (inscripció catalana, tractament, via de gestió). Ver Residuos por plataforma de gestión.
La configuración de plataforma SDR (credenciales ARC) debe existir y apuntar al gestor de destino.

NP o FA: qué documento envía Odoo¶

En el SDR conviven dos tipos de documento, y Odoo envía uno u otro según el traslado:

	NP — Notificació Prèvia	FA — Fitxa d'Acceptació
Es	la NT de Catalunya (aviso previo, con validación de ~10 días, como eSIR)	un documento más ligero, sin validación por días
Para	todos los residuos peligrosos que necesitan NT (lo habitual)	cantidades pequeñas / ciertos materiales (envases, algunos absorbentes)
Por defecto	Sí — si dudas, NP: cubre todos los peligrosos	solo cuando corresponde

Regla práctica

Si no estás seguro, deja NP: es la más restrictiva y sirve para todos los peligrosos. El propio SDR te avisa (error E53/E54) si un residuo debía ir por el otro tipo.

Dónde se elige NP o FA¶

La FA/NP es propiedad del RESIDUO (un centro tiene varios residuos: unos van por FA y otros por NP), así que se configura en el residuo, no en el centro:

Por defecto, en el residuo (producto): Inventario → producto → sección SDR Catalunya → Tipo doc. Catalunya (SDR). Normalmente NP; ponlo en FA en los residuos que lo requieran (aceite, envases, absorbentes…).
Por traslado, en el CT: cada CT hereda el tipo del residuo, pero puedes cambiarlo en la pestaña Plataforma API → grupo Tratamiento SDR → Tipo doc. Catalunya, tanto en borrador como cuando la NT está en error (para recuperar un E53/E54/E55).

El sistema aprende solo (auto-corrección)

Aunque el tipo por defecto no sea el correcto, no pasa nada: si el SDR rechaza el envío por el tipo (E53/E54/E55), Odoo cambia NP↔FA y reenvía automáticamente, y deja fijado en el CT el tipo que ha funcionado (ver Errores de FA vs NP).

La NP la firma el cliente

La NP la firma el productor (cliente) con su usuario/contraseña del SDR (campos «Usuario SDR / Contraseña SDR» del centro productor). La FA no lleva esa firma del cliente.

El resto de la guía dice «FA» por comodidad

De aquí en adelante se habla de «FA», pero el flujo es idéntico para la NP: mismos estados, misma firma en el portal, mismo ciclo de corrección. Solo cambia el tipo de documento que se envía.

El flujo de un vistazo¶

graph LR
  A[CT en Borrador<br/>plataforma SDR] --> B[Pulsar Validar] --> C[Odoo construye la NP/FA<br/>en JSON] --> D[POST a sdr.arc.cat] --> E[ARC devuelve nº ficha] --> F[NT Enviada<br/>pendiente de firma]

A diferencia de eSIR (manual, XML a la Sede), el SDR es un servicio web JSON y el envío ocurre al validar el CT (botón Validar, individual o en masa desde la lista). Pero ojo: enviarla no es el final — luego hay que firmarla en el portal de la ARC para que llegue a Vigente (ver Los estados de la NT en Catalunya).

🔑 La clave de Catalunya: el operador del traslado es el productor¶

En el resto de plataformas el operador del traslado suele ser el gestor de destino. En Catalunya no: el operador del traslado es el centro productor (el origen).

Por qué

En el SDR la Notificació Prèvia (NP) es autorellenable: la inicia el productor del residuo. Lo confirmamos con una NP real de un cliente, donde el Notificant / Operador era el propio productor (un taller), no el gestor. Por eso, para los CT de Catalunya, Odoo fija automáticamente:

Operador del traslado = Centro (origen / productor)

No hay que tocarlo a mano: al crear o editar un CT con plataforma SDR, Odoo pone el operador = centro solo. En las demás plataformas se mantiene el comportamiento habitual (operador = destino salvo que se cambie).

Las credenciales son del GESTOR, no del operador

Aunque el operador sea el productor, la FA la acepta el gestor de destino. Por eso Odoo busca las credenciales de la plataforma por el centro de destino, no por el operador. Esto está resuelto internamente: tú solo activas.

La cadena de conceptos catalanes¶

Concepto SDR	Qué es	Ejemplo real
Codi productor	Inscripció catalana del centro productor (origen)	`P-59700.1`
Codi gestor	Inscripció catalana del centro gestor (destino)	`E-1185.10` (Ecogestval, Olèrdola)
Codi residu	El LER del residuo	`130208`
Tractament	El tipo de tratamiento del gestor	`T62`
Via de gestió	La operación R/D codificada en el SDR	`R1302` (valorización)
Operador del traslado	Quién figura como operador → el productor	el centro de origen

Tratamiento intermedio y destino final

Un gestor puede hacer un tratamiento intermedio (almacenamiento/transferencia, p. ej. T62) y luego mandar el residuo a un destino final (otro gestor que lo valoriza/elimina). En la NP real, tras Ecogestval (T62) el residuo iba a un destino final distinto con su propia via de gestió. Para el flujo automático de la FA basta con el gestor de destino del CT; el destino final posterior se gestiona aparte.

Pasos¶

1. Revisa el CT en Borrador¶

Abre el CT (desde el contrato → Tratamientos) y comprueba, estando en Borrador:

Plataforma = SDR (Catalunya).
Origen (centro productor) y Destino (centro gestor catalán).
Operador del traslado = Centro (lo pone Odoo solo; está bloqueado al validar).
Tractament y Via de gestió importados de la autorización SDR del destino.

2. Pulsa Validar¶

Al validar, si el residuo requiere NT y la plataforma es SDR (automática), Odoo:

Genera el número de CT.
Construye la Fitxa d'Acceptació (FA) en JSON con los datos de la tabla anterior.
La envía al servicio web del SDR (https://sdr.arc.cat, o el entorno de pruebas durante la fase de test).
Registra la NT en el CT con la respuesta de ARC.

3. Comprueba la NT¶

La NT queda colgando del CT con el número que devolvió ARC.

Si el envío falla: estado «Error de envío»

Si algo falla (dato de ficha que falta, credenciales, error de la plataforma), la NT no se queda en silencio: pasa al estado «Error de envío» con el motivo en un banner rojo, se avisa por Odoo a los gestores de plataformas, y la lista la resalta. Corrige el dato indicado y pulsa «Enviar a plataforma» en la NT para reintentar. Si el dato a corregir es del propio CT (que se bloquea al validar), usa «Editar CT» en el CT → corrige → vuelve a validar. El detalle técnico también queda en el log de plataforma.

Los estados de la NT en Catalunya¶

A diferencia de eSIR o E3S (donde la administración auto-acepta al recibir y solo puede revocar en 10 días), en el SDR la FA no se acepta sola: una vez enviada, las partes tienen que entrar al portal de la ARC a firmarla. Por eso la NT pasa por tres estados que reflejan ese ciclo real:

graph LR
  A[Enviada<br/>pendiente de firma] -->|firman las partes| B[Firmada<br/>pendiente de registro] -->|ARC la registra| C[Vigente]

Estado en Odoo	Color	Qué significa	Qué dice la ARC (`estatStr`)
Enviada (pendiente de firma)	🟠 naranja	La FA se ha creado en el SDR, pero nadie la ha firmado todavía. Hay que entrar al portal de la ARC y firmarla.	Oberta
Firmada (pendiente de registro)	🔵 azul	Las partes (productor / notificante / gestor) ya la han firmado, pero la ARC aún no la ha registrado.	Pendent de registre / Signada
Vigente	🟢 verde	La ARC la ha registrado y está en vigor: la plataforma la da por buena. (Es el equivalente a «aceptada».)	Vigent

¿Quién firma?

En la ficha de la NT (pestaña de plataforma) hay un panel de firmas con tres marcas: Productor, Notificante y Gestor. Te dice exactamente quién falta por firmar. La NT pasa a Firmada cuando han firmado las partes, y a Vigente cuando la ARC la registra.

¿Cómo se actualiza el estado?

No tienes que estar pendiente: Odoo consulta el estado solo (cron cada pocas horas) y va avanzando la NT por sí misma. Si quieres forzar la comprobación al momento, pulsa «Verificar estado» en la NT (o «Verificar NT» en el CT). Mientras nadie firme en el portal, la NT se quedará en Enviada (pendiente de firma). Y si has cancelado la FA en el portal, al verificar Odoo lo detecta y devuelve el CT a Rechazado para que puedas rehacerla (ver Corregir o rehacer una FA).

La NT no es válida hasta «Vigente»

El consumo de cantidades (kg cubiertos por la NT) y la generación de DIs solo se activan cuando la NT está Vigente. Que esté Firmada significa que falta el registro de la ARC; aún no cuenta como cobertura definitiva.

Otros estados posibles: Error de envío (el SDR rechazó el envío por un dato — ver abajo), Rechazada (la ARC deniega la FA — Denegada), Revocada (la admin la anula tras estar vigente), Anulada y Caducada.

Cuando el envío falla: «Error de envío»¶

Si al Validar el CT el SDR no acepta la FA/NP (un dato de ficha mal, un residuo no autorizado, FA donde tocaba NP…), el envío no se pierde en silencio:

La NT queda en estado 🔴 Error de envío con el motivo exacto en un banner rojo arriba del formulario de la NT.
Se avisa por el chatter a los gestores de plataforma (equipo técnico).
En la lista de CT, la columna «Estado plataforma» muestra ese CT en rojo como «Error de envío», para que lo localices entre todos.

Cómo encontrar los CT que han fallado

En la lista de CT, ordena o filtra por la columna «Estado plataforma»: los envíos fallidos salen en rojo («Error de envío»). Antes esta columna se quedaba en blanco cuando fallaba y no se podían distinguir; ahora sí se ven.

Qué hacer: abre la NT (o el CT → pestaña Plataforma API), lee el motivo del banner, corrige el dato en la ficha correspondiente y pulsa «Enviar a plataforma» para reintentar. No hace falta rehacer nada: el mismo botón reenvía la NT corregida.

Errores de FA vs NP (E53 / E54 / E55)¶

El SDR puede rechazar el envío porque el tipo de documento no es el que toca para ese residuo/cantidad:

Código	Qué dice el SDR	Qué significa
E53	«No hay que hacer un NP (debe ser FA)»	Enviaste NP pero toca FA
E54	«No hay que hacer una FA (debe ser NP)»	Enviaste FA pero toca NP
E55	«Si se ha marcado FA hay que hacer NP y a la inversa»	El tipo está al revés

Se corrige SOLO (auto-corrección)

Ante cualquiera de estos tres errores, el sistema no te obliga a hacer nada: cambia NP↔FA automáticamente, reenvía una vez y, si entra, deja fijado en el CT el tipo que ha funcionado (con una nota en el historial). Solo si el reenvío corregido también falla por otro motivo verás la NT en «Error de envío» para revisarla a mano.

Y si quieres cambiarlo tú

En el CT, grupo «Tratamiento SDR» → «Tipo doc. Catalunya» (NP o FA), editable en borrador o con la NT en error. Lo ideal: marca el tipo correcto en el residuo (Inventario → producto) para que todos sus CT lo hereden y ni siquiera haga falta la doble llamada. Ver Dónde se elige NP o FA.

Corregir o rehacer una FA ya enviada¶

En Catalunya una FA enviada NO se puede modificar

A diferencia de un borrador, una FA ya enviada al SDR no se edita: ARC no deja cambiarle el residuo, el gestor ni las cantidades. Corregir SIEMPRE significa anular la FA vieja y enviar una nueva. Odoo lo refleja con dos caminos según lo que necesites.

Caso 1 — corregir datos (la FA aún no está firmada)¶

Usa el botón «Editar CT» (solo en CT de Catalunya; sustituye al Rechazar de las demás plataformas). El CT vuelve a Rechazado y puedes editarlo.

El cambio NO llega solo a ARC

Odoo te avisa al pulsar: la FA del portal de ARC no se actualiza sola. Tú decides:

Si lo gestionas tú → actualiza la FA a mano en el portal de ARC.
Si quieres que Odoo mande una FA nueva → cancela la FA vieja en el portal y sigue el Caso 2.

El botón no aparece si la FA ya está firmada: una vez firmada, el traslado está comprometido y no se toca. Si tras editar validas con la FA todavía viva, Odoo te avisa en el historial de que no ha reenviado nada.

Caso 2 — cancelé la FA en el portal y quiero rehacerla¶

Cancela la FA en el portal de la ARC (queda Cancel·lada).
En el CT, pulsa «Verificar NT». Odoo consulta el estado real: al ver la FA Cancelada, marca la NT como Anulada y devuelve el CT a Rechazado automáticamente (te lo avisa con una notificación).
Ya en Rechazado, cambia lo que necesites (o nada) y pulsa Validar: Odoo envía una FA nueva (la vieja ya no bloquea) heredando el destino final.

graph LR
  A[FA Enviada] -->|cancelas en el portal| B[Cancel·lada en ARC] -->|Verificar NT| C[CT a Rechazado<br/>NT Anulada] -->|editas + Validar| D[FA nueva Enviada]

Nada se envía a tus espaldas

Con este flujo el reenvío siempre pasa por Validar: revisas los datos antes de que salga una FA nueva. No hay envíos automáticos sorpresa.

Qué se envía exactamente (la FA)¶

Esta es la estructura JSON que Odoo manda al SDR (ejemplo de un CT de prueba real):

{
  "tipusFitxa": "FA",
  "codiProductor": "P-59700.1",
  "codiGestor": "E-1185.10",
  "codiResidu": "130208",
  "classeResidu": "ES",
  "codiTractament": "T62",
  "codiViaGestio": "R1302",
  "qEstimada": 0.67,
  "qAnual": 0.67
}

No hay campo «operador» en la FA

Fíjate en que el JSON no lleva un campo operador separado: el operador del traslado se deduce del codiProductor. Por eso es tan importante que el productor (origen) tenga bien su inscripció catalana.

Característica de peligrosidad (HP)¶

Si el residuo es peligroso, ARC exige declarar al menos una característica de peligrosidad (códigos HP1 a HP15 del Reglamento UE 1357/2014). Si falta, al firmar la FA aparece:

«Ha d'informar-se almenys una característica de perillositat...»

En Odoo no se teclea en cada traslado: el HP vive en la ficha del producto/residuo (campo Código peligrosidad (HP)). Al generar el contrato de tratamiento (CT) desde el contrato, el HP se copia solo al CT y de ahí viaja a la FA como caractPerillositat.

Revisa que el HP coincide con lo que declaras en ARC

El HP debe ser el que ARC espera para ese LER. Por ejemplo, para aceites usados de motor (LER 130205/130208) la FA real de ARC declara HP5. Si un producto de aceite tiene otro HP (p.ej. HP14), corrígelo en la ficha del producto para que la FA salga conforme.

Destino final tras un CRT (cascada R13/D15)¶

Algunos gestores catalanes no tratan el residuo: lo almacenan y lo reenvían. Son los Centros de Recogida y Transferencia (CRT), que operan con vías de almacenamiento/transferencia R13/D15 (en Catalunya, p.ej. R1302 + T62). Para estos, ARC exige declarar a dónde va el residuo DESPUÉS del CRT — el destí subseqüent:

«Cal informar del destí subsegüent i de la gestió subsegüent després de la via de gestió R13/D15»

Sin ese destino la FA se puede enviar, pero no se puede registrar/firmar en ARC (queda pendiente).

Cómo se configura (una vez, POR RESIDUO, en la autorización del gestor)¶

No se rellena traslado a traslado. Como el destino final es distinto para cada residuo (las baterías van a una planta, los aceites a otra), se configura en la línea de cada LER de la autorización SDR del gestor CRT, y cada CT hereda la línea de su residuo:

Abre la ficha del gestor CRT (p.ej. Ecogestval) → Autorizaciones de residuos → la línea de plataforma SDR.
En la tabla de residuos autorizados (LER), en la línea del residuo, rellena las columnas de destino final:
- Gestor final → la planta real de tratamiento (p.ej. Sertego Servicios Medioambientales).
- Vía de gestión final y Tratamiento final catalanes de esa planta (p.ej. R0901 / V22).
Guarda. A partir de ahí, cada CT de ese gestor con ese residuo hereda el destino final automáticamente en su pestaña «Tratamiento posterior» (editable después: la FA dura 3 años y el destino puede cambiar).

Planta catalana vs planta del resto de España

El conector distingue sola:

Planta catalana → se identifica por su inscripció (E-xxxx / P-xxxx) y va como codiGestor.
Planta del resto de España (como Sertego) → se identifica por su NIMA y va como codiNima.

Solo tienes que tener bien la inscripció (catalana) o el NIMA (estatal) en la ficha de la planta de destino.

Qué se manda en la FA¶

Cuando hay destino final, la FA incluye un array destinsFinals con el LER, la planta, su vía y su tractament:

{
  "tipusFitxa": "FA",
  "codiProductor": "P-59700.1",
  "codiGestor": "E-1185.10",
  "codiResidu": "130208",
  "codiViaGestio": "R1302",
  "codiTractament": "T62",
  "caractPerillositat": ["HP5"],
  "destinsFinals": [
    {
      "codiNima": "2800021374",
      "nomInstal": "SERTEGO SERVICIOS MEDIOAMBIENTALES S.L.U.",
      "codiResidu": "130208",
      "codiViaGestio": "R0901",
      "codiTractament": "T62"
    }
  ]
}

El DI del traslado: el FS (Full de Seguiment)¶

Cuando la NT (FA) está Vigente, cada recogida genera su DI, que en Catalunya es el FS (Full de Seguiment). Odoo lo gestiona en dos partes:

Parte A — se envía al finalizar la recogida (el conductor cierra la recogida con residuos), con el peso del conductor.
Parte B — se cierra sola a las 24 horas de la Parte A (configurable, puede ser 48 h), con los kilos documentales vigentes: si logística corrigió tras una incidencia de nave, va corregido; si no, va lo del conductor. El peso de báscula de la nave es interno y no viaja. Ver Descarga de ruta.

Un FS por recogida (salvo ruta itinerante)

Por defecto cada recogida genera su propio FS, también en rutas con muchas paradas. Si una recogida acaba vacía, el DI se anula solo en el SDR. El PDF oficial del FS se descarga desde el DI con «Descargar PDF».

Rutas de varios productores catalanes: el FI itinerante

Cuando una ruta recoge de ≥2 productores, todos en Catalunya, el SDR permite documentarla con un único documento —el FI (Full de Seguiment Itinerant)— en lugar de un FS por recogida. Odoo decide solo qué recogidas entran, cuáles quedan «Pendiente NT» y cuáles van a un gestor. Está pendiente de activar en producción. Todo el flujo (planificar → iniciar → cerrar recogidas → validar descarga → firmar) y los casos especiales están en FI itinerante en SDR.

El FS exige transportista T- y vehículo registrado

El SDR solo acepta el FS si el transportista tiene inscripción catalana T-#### vigente y autorizada para el grupo del residuo, y si la matrícula es de un vehículo registrado de ese transportista. Si falta, Odoo avisa antes de enviar. El código T- y sus vehículos se consultan en el portal SDR → Transportistas.

¿Qué residuos generan NT (y DI)?¶

No todo se documenta ante el SDR. La regla (RD 553/2020, igual en todas las plataformas):

Residuo	¿Genera NT/DI?
Peligroso	Sí, siempre
No peligroso destinado a eliminación (D01–D15)	Sí
No peligroso destinado a valorización (R…)	No

En los no peligrosos manda la operación de tratamiento del producto (si acaba en D…, genera NT); y el CT tiene el campo «Requiere NT» (Automático / Forzar SÍ / Forzar NO) para las excepciones.

Entornos: pruebas vs producción¶

Entorno	URL	Cuándo
Pruebas (test)	`https://sdr.test.arc.cat`	Durante la implantación / validación
Producción	`https://sdr.arc.cat`	Cuando ARC dé el visto bueno

ARC nos facilitó un usuario de pruebas con perfiles de gestor (E-1185.10) y productor (P-59700.1). La configuración de plataforma SDR de Odoo apunta al entorno test mientras se validan los envíos; al pasar a producción, solo cambia el entorno (y las credenciales reales).

Errores frecuentes¶

No deja activar: «el destino es un centro del grupo y no tiene autorización»

El gestor catalán de destino necesita su autorización SDR con la inscripció, el tractament y la via de gestió. Cárgala en la ficha del centro (Autorizaciones de residuos) y reintenta. Ver Residuos por plataforma de gestión.

El SDR rechaza el envío

Suele ser un dato de ficha: la inscripció catalana del productor o del gestor, el LER, o el tractament/via de gestió de la autorización. Corrígelo y reactiva. El detalle del rechazo queda en el log de plataforma.

«Ha d'informar-se almenys una característica de perillositat»

El residuo es peligroso y le falta el HP. Rellena Código peligrosidad (HP) en la ficha del producto/residuo y vuelve a generar/reenviar. Ver Característica de peligrosidad (HP).

«Cal informar del destí subsegüent... després de la via de gestió R13/D15»

El gestor es un CRT (vía R13/D15) y falta el destino final. Configúralo en la línea del LER de la autorización SDR del gestor (columnas «Gestor final» + vía/tratamiento finales); el CT lo heredará solo. Ver Destino final tras un CRT.

Las otras plataformas

Para eSIR la NT es manual (ver NT en eSIR) y para E3S (Valencia) es automática como el SDR. Este tutorial cubre solo SDR (Catalunya).