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 activar el CT, Odoo envía la Fitxa d'Acceptació (FA) al SDR 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.
El flujo de un vistazo¶
graph LR
A[CT en Borrador<br/>plataforma SDR] --> B[Pulsar Activar] --> C[Odoo construye la FA<br/>en JSON] --> D[POST a sdr.arc.cat] --> E[ARC devuelve nº FA] --> 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 pulsar Activar. 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 activar).
- Tractament y Via de gestió importados de la autorización SDR del destino.
2. Pulsa Activar¶
Al activar, 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 algo falla (credenciales, dato de ficha), el envío se registra en el log de plataforma y la NT podrá reintentarse.
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).
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: Rechazada (la ARC deniega la FA — Denegada), Revocada (la admin la anula tras estar vigente), Anulada y Caducada.
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 sola vez, en la autorización del gestor)¶
No se rellena traslado a traslado. Se configura una vez en la autorización SDR del gestor CRT y todos sus CT lo heredan:
- Abre la ficha del gestor CRT (p.ej. Ecogestval) → Autorizaciones de residuos → la línea de plataforma SDR.
- En el bloque «Destinos finales por defecto (CRT, R13/D15)» añade la(s) planta(s) de destino final:
- Destino → la planta real de tratamiento (p.ej. Sertego Servicios Medioambientales).
- Vía de gestión y Tractament catalanes de esa planta (p.ej. R0901 / T62).
- % cantidad (normalmente 100).
- Guarda. A partir de ahí, cada CT de ese gestor cuya vía sea R13/D15 hereda el destino final automáticamente en su pestaña «Tratamiento posterior».
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 comocodiGestor. - 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"
}
]
}
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 Destinos finales por defecto de la autorización SDR del gestor; 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).

