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

[josecarrillo]

Yo ademas de capicom tube que instalar el configurador de hacienda(Configurador_FNMT_RCM.exe)

[pesadillator]

Gracias he registrado capicom.dll, pero ahora me sale "conexión a Oracle no disponible", estoy accediendo al portal de pruebas, puede ser que ya no este activo?
De hecho en el ordenador que funcionaba me sale el mismo error.

[josecarrillo]

Instala capicom y configurador de hacienda. (Configurador_FNMT_RCM.exe, capicom_dc_sdk.msi)

[[newtron]]

Empezado por pesadillator

Gracias he registrado capicom.dll, pero ahora me sale "conexión a Oracle no disponible", estoy accediendo al portal de pruebas, puede ser que ya no este activo?

Ese error es del servidor de la aeat, a mi me da el mismo mensaje, así que por tu parte ya tienes el problema resuelto.

[josecarrillo]

El portal de pruebas creo que hoy esta cerrado. Yo estoy ya en el bueno y me va todo bien. Solo he tenido que compilar cambiado la version V 0.7 por la v 1.0

[RafaSerMed]

Pues eso, que comenzamos el baile, y en este caso pisando a nuestro partener...

El Modo en pruebas, o no funciona o da error.

En nuestro caso tenemos dos problemas, el primero es que no nos permite enviar ni consultar información con un certificado no censado para el SII. Cuando antes funcionaba perfectamente y en la documentación de la fase de pruebas se especifica literalmente: "Está abierto a todos los sujetos pasivos, ya sean obligados del SII o no."

Y en segundo lugar con un certificado obligado al SII, nos remite el error por aquí comentado anteriormente: "Conexión a Oracle no disponible".

Ou Yeah!!!

[pablog2k]

pues si, parece que el servidor de pruebas hoy no funciona .....

[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

[[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

[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 ?

[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>

[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);

[[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.

[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

[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....