SII -Nuevo sistema de la Agencia Tributaria española de envío de datos vía Webservice

[JJAlf]

Empezado por vboloradito

Pero si curras con SERES-edicom:
¿Tienes que recoger la respuesta de seres y trasladarla a tu sistema o te quedas solo en seres?.

Si tienes que modificar un nif lo haces en SERES-edicom y luego a mano en tu sistema o lo haces en tu sistema y tienes qeu marcarla para que la vuelva a extraer para enviar a SERES-edicom.

Perdona, he tenido que cambiar de proyecto y hasta ayer no he vuelto a retomar el tema y empezar con la comunicación con edicom.

Efectivamente, hay que hacer todo el trabajo pero dejando a ellos SOLO el envío final. Si hay que modificar algo, se modifica en el sistema del cliente y se vuelve a enviar (se vuelve a generar el fichero y a decirle a edicom que lo envíe), lo mismo que el tratar las respuestas de edicom (que son las respuestas de la AEAT). Bueno, creo que existe un cliente mu chulo, pero yo ahí no entro, espero que sólo sirva para consultar datos.

La cosa es superchunga. De primeras, al usar yo WSDL el mensaje que la AEAT me acepta sin problemas a ellos no les vale porque tiene el englobado SOAP (fácil de quitar) y no tiene los namespaces (sii:, siiLR: ..) que tendría si hubiera hecho el XML a mano basándome en el XSD. Vale, hago la transformación. Pero luego lo que han hecho (en mi caso) es un cliente java para poder comunicarme con su servicio, que no deja de ser un REST, podría haberme comunicado directamente, ¿no?. En fin, dejas el archivo generado en una carpeta y ejecutas un comando para que lo envíe. Y ya está. Puedo averiguar (algo intrincadamente) que el mensaje ha sido tratado por su servidor correctamente. Pero para saber si la AEAT ha dado el ok, tengo que ejecutar un comando para recibir mensajes de respuesta.
Aún estoy esperándolo, para saber cómo voy a casar el mensaje que he enviado esta mañana con su respuesta.

Una odisea.

[figo21]

Empezado por JJAlf

Perdona, he tenido que cambiar de proyecto y hasta ayer no he vuelto a retomar el tema y empezar con la comunicación con edicom.

Efectivamente, hay que hacer todo el trabajo pero dejando a ellos SOLO el envío final. Si hay que modificar algo, se modifica en el sistema del cliente y se vuelve a enviar (se vuelve a generar el fichero y a decirle a edicom que lo envíe), lo mismo que el tratar las respuestas de edicom (que son las respuestas de la AEAT). Bueno, creo que existe un cliente mu chulo, pero yo ahí no entro, espero que sólo sirva para consultar datos.

La cosa es superchunga. De primeras, al usar yo WSDL el mensaje que la AEAT me acepta sin problemas a ellos no les vale porque tiene el englobado SOAP (fácil de quitar) y no tiene los namespaces (sii:, siiLR: ..) que tendría si hubiera hecho el XML a mano basándome en el XSD. Vale, hago la transformación. Pero luego lo que han hecho (en mi caso) es un cliente java para poder comunicarme con su servicio, que no deja de ser un REST, podría haberme comunicado directamente, ¿no?. En fin, dejas el archivo generado en una carpeta y ejecutas un comando para que lo envíe. Y ya está. Puedo averiguar (algo intrincadamente) que el mensaje ha sido tratado por su servidor correctamente. Pero para saber si la AEAT ha dado el ok, tengo que ejecutar un comando para recibir mensajes de respuesta.
Aún estoy esperándolo, para saber cómo voy a casar el mensaje que he enviado esta mañana con su respuesta.

Una odisea.

Madre mía, pero si es más complicado eso que comunicarte directamente con la aeat. Aparte de que recibes la respuesta en tiempo real...


Un saludo.

[PASPAS]

Empezado por JJAlf

Perdona, he tenido que cambiar de proyecto y hasta ayer no he vuelto a retomar el tema y empezar con la comunicación con edicom.

Efectivamente, hay que hacer todo el trabajo pero dejando a ellos SOLO el envío final. Si hay que modificar algo, se modifica en el sistema del cliente y se vuelve a enviar (se vuelve a generar el fichero y a decirle a edicom que lo envíe), lo mismo que el tratar las respuestas de edicom (que son las respuestas de la AEAT). Bueno, creo que existe un cliente mu chulo, pero yo ahí no entro, espero que sólo sirva para consultar datos.

La cosa es superchunga. De primeras, al usar yo WSDL el mensaje que la AEAT me acepta sin problemas a ellos no les vale porque tiene el englobado SOAP (fácil de quitar) y no tiene los namespaces (sii:, siiLR: ..) que tendría si hubiera hecho el XML a mano basándome en el XSD. Vale, hago la transformación. Pero luego lo que han hecho (en mi caso) es un cliente java para poder comunicarme con su servicio, que no deja de ser un REST, podría haberme comunicado directamente, ¿no?. En fin, dejas el archivo generado en una carpeta y ejecutas un comando para que lo envíe. Y ya está. Puedo averiguar (algo intrincadamente) que el mensaje ha sido tratado por su servidor correctamente. Pero para saber si la AEAT ha dado el ok, tengo que ejecutar un comando para recibir mensajes de respuesta.
Aún estoy esperándolo, para saber cómo voy a casar el mensaje que he enviado esta mañana con su respuesta.

Una odisea.

Madre mia , para edicom estas haciendo el trabajo doble no lo veo viable . Espero que no me toque ningun cliente asi.
Ademas gracias por la info porque si veo q alguien lo quiere con edicom lo dejare bien claro que todo el envio y respuesta se trate via edicom.
Yo de ti lo que haria es marcar com exportado a edicomSII y ya esta luego que el cliente entre a su portal para ver el status , lo que estas haciendo es un trabajo de chinos y perdon por la expresion. Encima de lo que cobran te hacen convertir a su gusto y espera q con nuevas version lo q te tocara hacer extra.
Saludos y animo.

[vboloradito]

Empezado por PASPAS

Madre mia , para edicom estas haciendo el trabajo doble no lo veo viable . Espero que no me toque ningun cliente asi.
Ademas gracias por la info porque si veo q alguien lo quiere con edicom lo dejare bien claro que todo el envio y respuesta se trate via edicom.
Yo de ti lo que haria es marcar com exportado a edicomSII y ya esta luego que el cliente entre a su portal para ver el status , lo que estas haciendo es un trabajo de chinos y perdon por la expresion. Encima de lo que cobran te hacen convertir a su gusto y espera q con nuevas version lo q te tocara hacer extra.
Saludos y animo.

El problema es que si un cliente tiene mal el NIF, que haces, vas a la web de EDICOM apuntas el numero. TE vas a tu ERP, buscas el numero , actualizas el nif.
¿Lo relanzas desde tu ERP o desde EDICOM-SERES?
¿No es mas facil trabajar con fichero plano con EDICOM-SERES en lugar de generar el XML?

[JJAlf]

Empezado por vboloradito

El problema es que si un cliente tiene mal el NIF, que haces, vas a la web de EDICOM apuntas el numero. TE vas a tu ERP, buscas el numero , actualizas el nif.
¿Lo relanzas desde tu ERP o desde EDICOM-SERES?

Se supone que tras el envío, en algún momento, edicom me debe reportar la respuesta de la AEAT, de manera que es 'casi' lo mismo que en el caso on-line, sólo que hay un 'retraso' entre el envío y la confirmación de su estado; o sea, que tengo que tratarlo como enviado-pendiente-de-confirmación. Digo se supone porque aún no he conseguido respuesta. Y como sea lo que apuntas (rollo 'ellos se encargan de todo') que nos lo estamos empezando a temer, les va a caer una buena: no me importa lo farragoso que pueda resultar tener que modificar un NIF en la web de edicom y al mismo tiempo en mi sistema, sino que no puedo permitir que hayan diferencias entre ambos.

Empezado por vboloradito

¿No es mas facil trabajar con fichero plano con EDICOM-SERES en lugar de generar el XML?

Por supuesto, pero dado que el 90% de mis clientes optan por la comunicación directa, no pensaba programar lo mismo dos veces. Es un añadido al funcionamiento estándar.

[PASPAS]

Empezado por JJAlf

Se supone que tras el envío, en algún momento, edicom me debe reportar la respuesta de la AEAT, de manera que es 'casi' lo mismo que en el caso on-line, sólo que hay un 'retraso' entre el envío y la confirmación de su estado; o sea, que tengo que tratarlo como enviado-pendiente-de-confirmación. Digo se supone porque aún no he conseguido respuesta. Y como sea lo que apuntas (rollo 'ellos se encargan de todo') que nos lo estamos empezando a temer, les va a caer una buena: no me importa lo farragoso que pueda resultar tener que modificar un NIF en la web de edicom y al mismo tiempo en mi sistema, sino que no puedo permitir que hayan diferencias entre ambos.

Por supuesto, pero dado que el 90% de mis clientes optan por la comunicación directa, no pensaba programar lo mismo dos veces. Es un añadido al funcionamiento estándar.

Pero para eso antes del envio a edicom puedes hacer el proceso de validacion de nif o esta censado o no para que cuando lo envies a edicom ese problema esta resuelto asi evitar tratar nada a posteriori como mucho y por consejo puedes añadir las consultas y crear el campo contraste por tranquilidad de tus clientes
Saludos

[barnarasta]

Empezado por PASPAS

Pero para eso antes del envio a edicom puedes hacer el proceso de validacion de nif o esta censado o no para que cuando lo envies a edicom ese problema esta resuelto asi evitar tratar nada a posteriori como mucho y por consejo puedes añadir las consultas y crear el campo contraste por tranquilidad de tus clientes
Saludos

Encuentro que verificar si estan censados en un envio de 2500 registros puede ser ...... uffff

Yo como lo trabajo, quizas pueda serviros de orientacion para mejorarlo, es :
* creo un archivo temporal con los registros a enviar, incluyendo el campo 'ERROR'
* realizo el envio del xml generado.
* recojo el resultado y actualizo el archivo temporal actualizando el campo 'ERROR' codigo (1117)
* genero un segundo xml SOLO con los (1117) adaptando los cambios.

Anoto que todo esto lo hago desde un Debian 6 (Squeeze) y bash.
.

[vboloradito]

Empezado por PASPAS

Pero para eso antes del envio a edicom puedes hacer el proceso de validacion de nif o esta censado o no para que cuando lo envies a edicom ese problema esta resuelto asi evitar tratar nada a posteriori como mucho y por consejo puedes añadir las consultas y crear el campo contraste por tranquilidad de tus clientes
Saludos

El caso del NIf era por poner un ejemplo quizas sea el mas facil de resolver. pero no se que problemas puedes tener en el futuro que te obligue a actualizar en EDICOM y en tu sistema dos veces.

[seccion_31]

vamos a ver si ando confundido o muy confundido.

En los últimos ejemplos que he visto se envían las facturas sin indicar si el desglose es por entrega o prestación de servicios.

Asi es como estaba trabajando hasta hace unos días, ahora he decidido actualizar mi envio a esta forma.

Este es el código que me genera para una factura que contendría entrega de material y mano de obra: (los portes por ejemplo no se como calificarlos)

-<TipoDesglose xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/ssii/fact/ws/SuministroInformacion.xsd">
-<DesgloseTipoOperacion>
-<PrestacionServicios>
-<Sujeta>
-<NoExenta>
<TipoNoExenta>S1</TipoNoExenta>
-<DesgloseIVA>
-<DetalleIVA>
<TipoImpositivo>21.00</TipoImpositivo>
<BaseImponible>391.00</BaseImponible>
<CuotaRepercutida>82.11</CuotaRepercutida>
</DetalleIVA>
</DesgloseIVA>
</NoExenta>
</Sujeta>
</PrestacionServicios>

-<Entrega>
-<Sujeta>
-<NoExenta>
<TipoNoExenta>S1</TipoNoExenta>
-<DesgloseIVA>
-<DetalleIVA>
<TipoImpositivo>21.00</TipoImpositivo>
<BaseImponible>164.43</BaseImponible>
<CuotaRepercutida>34.53</CuotaRepercutida>
</DetalleIVA>
</DesgloseIVA>
</NoExenta>
</Sujeta>
</Entrega>
</DesgloseTipoOperacion>
</TipoDesglose>

¿opiniones?

saludos !