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

[austral_es]

Acabo de probar el servidor de pruebas y YA FUNCIONA!

[RafaSerMed]

Empezado por austral_es

Acabo de probar el servidor de pruebas y YA FUNCIONA!

Efectivamente empieza a funcionar. Aunque en ocasiones sigue dando errores, pero funciona 9 de cada 10.......

[didou]

buenos días, alguien sabe si una vez enviado el primer semestre hay opciones de bajas y/o modificaciones de estas facturas del primer semestre? además por lo que estoy viendo hay que hacer 6 envios (uno por cada mes) de las facturas del 1er. semestre, no se puede hacer un solo envio agrupando todas las facturas del primer semestre?

Gracias y buen SII para todos.

[[newtron]]

Ya empezamos....

Tengo un cliente que ya ha enviado datos, se le ha quedado colgado por problemas en el webservice y ha cerrado el programa "a lo bruto". Consultamos y resulta que parte de las facturas constan como enviadas y otra parte no y, logicamente, mi programa no se ha enterado de cuales han quedado subidas porque se ha colgado antes.

¿Alguna idea de si es posible preveer esto?

Saludos

[marine]

Buenas , aparte de los problemas sufridos con la caida del portal de pruebas me encuentro ahora con problemas de certificados donde antes no los tenia. Ha cambiado algo ?

[dgcapel]

Buenas tardes,
alguno de vosotros ha conseguido deserializar una respuesta del servidor en formato texto, una vez que la tienes guardada como un fichero, ¿mediante las clases del SII Service? Uso C#, pero cualquier sugerencia en delphi es bienvenida. Es un problema con los Namespaces, pero no consigo dar con la tecla.

Código Delphi [-]
                
// File : Open
                XmlSerializer serializer = new XmlSerializer(typeof(RespuestaLRFRecibidasType));
                fs = new FileStream(xmlReponseUri, FileMode.Open);
                XmlReader reader = XmlReader.Create(fs);

                // Deserialize
                RespuestaLRFRecibidasType facturaRecibida = (RespuestaLRFRecibidasType)serializer.Deserialize(reader);

                // File : Close
                fs.Close();

                // Response
                Console.WriteLine("CSV: " + facturaRecibida.CSV);

[jcapilla]

Empezado por dgcapel

Buenas tardes,
alguno de vosotros ha conseguido deserializar una respuesta del servidor en formato texto, una vez que la tienes guardada como un fichero, ¿mediante las clases del SII Service? Uso C#, pero cualquier sugerencia en delphi es bienvenida. Es un problema con los Namespaces, pero no consigo dar con la tecla.

Código Delphi [-]
                
// File : Open
                XmlSerializer serializer = new XmlSerializer(typeof(RespuestaLRFRecibidasType));
                fs = new FileStream(xmlReponseUri, FileMode.Open);
                XmlReader reader = XmlReader.Create(fs);

                // Deserialize
                RespuestaLRFRecibidasType facturaRecibida = (RespuestaLRFRecibidasType)serializer.Deserialize(reader);

                // File : Close
                fs.Close();

                // Response
                Console.WriteLine("CSV: " + facturaRecibida.CSV);

Si cambias en el xml de respuesta RespuestaLRFacturasRecibidas por RespuestaLRFRecibidasType y quitas los tags de env: debe funcionar.

[xamminf]

Empezado por newtron

Ya empezamos....

Tengo un cliente que ya ha enviado datos, se le ha quedado colgado por problemas en el webservice y ha cerrado el programa "a lo bruto". Consultamos y resulta que parte de las facturas constan como enviadas y otra parte no y, logicamente, mi programa no se ha enterado de cuales han quedado subidas porque se ha colgado antes.

¿Alguna idea de si es posible preveer esto?

Saludos

Newtron Jimmy,

Esa es el peor de los escenarios posibles.. y no es para tanto porque lo que tiene que hacer tu usuario es regularizar la situacion:

Entrar al portal, ver las que si estan enviadas y marcarlas en tu programa como enviadas para que no entren en el próximo envio.

¿ ok ?

Hay que aplicar mucha lógica informática de tolerancia a fallos para evitar que estos fallos nos amarguen el verano.

[[newtron]]

Empezado por xamminf

Newtron Jimmy,

Esa es el peor de los escenarios posibles.. y no es para tanto porque lo que tiene que hacer tu usuario es regularizar la situacion:

Entrar al portal, ver las que si estan enviadas y marcarlas en tu programa como enviadas para que no entren en el próximo envio.

¿ ok ?

Hay que aplicar mucha lógica informática de tolerancia a fallos para evitar que estos fallos nos amarguen el verano.

Hasta ahí llego compañero, yo preguntaba si había alguna manera de que, al enviar los datos hubiera alguna especie de transacción o algo que nosotros pudiéramos tocar para que no ocurra esto, porque me da la impresión de que está fuera de nuestra mano. Pregunto porque, con lo listos que deben de ser los que han montado ese chiringuito, deberían de tener esta posibilidad contemplada.

Saludos

[xamminf]

Empezado por newtron

Hasta ahí llego compañero, yo preguntaba si había alguna manera de que, al enviar los datos hubiera alguna especie de transacción o algo que nosotros pudiéramos tocar para que no ocurra esto, porque me da la impresión de que está fuera de nuestra mano. Pregunto porque, con lo listos que deben de ser los que han montado ese chiringuito, deberían de tener esta posibilidad contemplada.

Saludos

El sistema es síncrono, es decir: petición y respuesta en el mismo viaje.

¿ No habría sido mejor montar un sistema asíncrono de manera que envias ahora y puedes tener la repuesta más tarde ?
Así el asunto sólo se trataría de enviar el .xml y ellos lo procesarían cuando pudieran y cuando lo hicieran colocarían un .xml que podríamos leer cuando conectasemos.

Es verdad que tiene alguna desventaja, pero tiene algunas otras, como este tema de los cortes.

En fin, pura informática ficción.

[RafaSerMed]

Empezado por newtron

Ya empezamos....

Tengo un cliente que ya ha enviado datos, se le ha quedado colgado por problemas en el webservice y ha cerrado el programa "a lo bruto". Consultamos y resulta que parte de las facturas constan como enviadas y otra parte no y, logicamente, mi programa no se ha enterado de cuales han quedado subidas porque se ha colgado antes.

¿Alguna idea de si es posible preveer esto?

Saludos

Eso se debe de prever siempre. No solo por los posibles errores de cuelgue del programa al enviar o lo que sea. También porque si enviamos mucha información, por ejemplo enviamos 3000 facturas a la vez y el servicio tarda y no llega la respuesta o se corta a mitad del envío, con lo que tenemos la mitad por ejemplo de facturas procesadas cuando hemos enviado todas....

Pues bien, la AEAT, comento en alguna que otra reunion que esto puede pasar. En ese caso al volver a enviar toda la información de nuevas (por ejemplo en tu caso), tenemos que procesar la respuesta de aquellas que nos indica que están duplicadas. Eso significa que dichas facturas ya han sido presentadas. Por esa razón en las ultimas versiones añadieron el CSV en la respuesta del error de factura duplicada.

A mi no me parece una solución muy viable, ya que el resultado de factura duplicada puede ser un resultado correcto en muchos casos y no tiene porque ser el caso de que se hayan enviado previamente y no se haya procesado la respuesta. Sinceramente me parece una chapuza.

La solución medianamente viable es que al intentar enviar los registros de alta, previamente realicemos una consulta con el filtro de la factura que queremos añadir. En ese caso si nos devuelve que existe un registro con esos criterios en el filtro, nos indicará la fecha de presentación. Con esa fecha podemos "deducir" si se ha presentado anteriormente pero no se ha registrado la respuesta....

Vamos sencillo.

[RafaSerMed]

Ahora mismo estamos teniendo problemas en el envío de facturas, ya sean recibidas o emitidas, con el código de error de vuelta 1117, la contraparte no está censada...

Pues bien son NIF totalmente correctos, con su nombre perfectamente introducido y son NIFs utilizados hace 10m y que NO daban ningún tipo de error....

Pasados 5m, esas mismas facturas, sin tocar nada, ya se procesan perfectamente.......

Bufffff que miedo me está dando todo esto....

[seccion_31]

nosotros estamos enviando sin problemas. tal cual días anteriores, sin mas inconvenientes.

Lo que no tengo es la dirección del menú de opciones en la web de la AEAT de la nueva versión 7
¿alguien la sabe?

Saludos y muchas gracias a todos por vuestras aportaciones y comentarios. Es una distinción especial pertenecer a los programadores Delphi.

[[newtron]]

Empezado por didou

buenos días, alguien sabe si una vez enviado el primer semestre hay opciones de bajas y/o modificaciones de estas facturas del primer semestre? además por lo que estoy viendo hay que hacer 6 envios (uno por cada mes) de las facturas del 1er. semestre, no se puede hacer un solo envio agrupando todas las facturas del primer semestre?

Gracias y buen SII para todos.

Yo no he leido por ningún sitio que haya que enviar por meses los datos del primer semestre de 2016 y, por otro lado, imagino que el tratamiento para bajas y modificaciones será exactamente igual que el resto de periodos.

Saludos

[didou]

Empezado por newtron

Yo no he leido por ningún sitio que haya que enviar por meses los datos del primer semestre de 2016 y, por otro lado, imagino que el tratamiento para bajas y modificaciones será exactamente igual que el resto de periodos.

Saludos

En los XML de ejemplo en el nodo periodo esta especificado el mes de la fecha de la factura o sea que no se que pensar, yo creo que si hay que enviar por periodo las fras. del 1er. semestre.
<siiLR:RegistroLRFacturasEmitidas>
<sii:PeriodoImpositivo>
<sii:Ejercicio>2017</sii:Ejercicio>
<sii:Periodo>03</sii:Periodo>

[[newtron]]

Empezado por didou

En los XML de ejemplo en el nodo periodo esta especificado el mes de la fecha de la factura o sea que no se que pensar, yo creo que si hay que enviar por periodo las fras. del 1er. semestre.
<siiLR:RegistroLRFacturasEmitidas>
<sii:PeriodoImpositivo>
<sii:Ejercicio>2017</sii:Ejercicio>
<sii:Periodo>03</sii:Periodo>

Vale, hay que informar del periodo, pero si no me equivoco esa información va en cada registro, no en cabecera, con lo que informas del periodo en cada factura que se envía.