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

[2uolap2]

Si, pero recibo esto:

<env:Body><env:Fault><faultcode>env:Client</faultcode><faultstring>Codigo[4102].El XML no cumple el esquema. Falta informar campo obligatorio.: DetalleIVA</faultstring><detail><callstack>El XML no cumple el esquema. Falta informar campo obligatorio.: DetalleIVA
WSExcepcion [faultcode=null, detailMap=null, version=0, faultstring=null, faultactor=null, faultSubCode=null, reasonText=null, detail=null, nameSpaceUriDetail=null]
	at es.aeat.ssii.fact.xml.util.UtilesXMLSII.existeEtiquetaFin(UtilesXMLSII.java:376)
	at es.aeat.ssii.fact.xml.comun.ParserXmlDesgloseIva.parsearLista(ParserXmlDesgloseIva.java:57)
...

He comprobado todos los registros NoExenta y contienen la etiqueta DetalleIVA... no se por donde buscar.
Otros ficheros si que me entran correctamente, con lo cual, debe ser algo especifico de algun registro de este pero que no puedo encontrar.

[CMB]

Este hilo llegará hoy a las 64.000 vistas. No está mal.

[dgcapel]

Buenas tardes,
yo estoy un conector para la base de datos de contabilidad de mi empresa con el SII, pero lo estoy haciendo con C# / .NET.
¿Algún desarrollador por aquí de .NET? Me encuentro ahora deserializando una respuesta del WebService, ya con los XSD convertidos a una clase. Por ejemplo un RespuestaLRFRecibidasType. Pero me falla.

Muchas gracias!

[jcapilla]

Empezado por dgcapel

Buenas tardes,
yo estoy un conector para la base de datos de contabilidad de mi empresa con el SII, pero lo estoy haciendo con C# / .NET.
¿Algún desarrollador por aquí de .NET? Me encuentro ahora deserializando una respuesta del WebService, ya con los XSD convertidos a una clase. Por ejemplo un RespuestaLRFRecibidasType. Pero me falla.

Muchas gracias!

Yo tengo el mismo problema. Cuando serializo a traves de los xsd el xml es correcto pero cuando deserialzo las respuesta obtengo un error. El problema es que al deserializar se espera en el tag principal <RespuestaLRFRecibidasType> pero el xml contiene <RespuestaLRFRecibidas>. Revisa si ese es el problema. Yo lo soluciono con un replace chapucero por que no se por que pasa. Si encuentro la solución "buena" lo posteare. Si es el mismo problema el que tienes y lo solucionas postealo también .

Gracias.

[pilarinweb]

Empezado por dgcapel

Buenas tardes,
yo estoy un conector para la base de datos de contabilidad de mi empresa con el SII, pero lo estoy haciendo con C# / .NET.
¿Algún desarrollador por aquí de .NET? Me encuentro ahora deserializando una respuesta del WebService, ya con los XSD convertidos a una clase. Por ejemplo un RespuestaLRFRecibidasType. Pero me falla.

Muchas gracias!

Hola,
yo soy de C#, tambien me falla...al deserialize(fstream)....te ocurre a ti lo mismo?

[inyu]

Empezado por pilarinweb

Hola,
yo soy de C#, tambien me falla...al deserialize(fstream)....te ocurre a ti lo mismo?

¿ Si estáis en .NET por qué no agregáis una referencia al servicio ? no hace falta ir deserializando ni nada, tratas directamente con las clases, métodos y propiedades que se generan automáticamente al agregar la referencia al wsdl. -> http://imgur.com/a/xXUJk

[pilarinweb]

[quote=inyu;518584]¿ Si estáis en .NET por qué no agregáis una referencia al servicio ? no hace falta ir deserializando ni nada, tratas directamente con las clases, métodos y propiedades que se generan automáticamente al agregar la referencia al wsdl. ->

porque al hacer
resp = oSiiSFE.SuministroLRFacturasEmitidas(oSfe);
me da el error:
El tipo de contenido text/html del mensaje de respuesta no coincide con el tipo de contenido del enlace (text/xml; charset=utf-8). Si usa un codificador personalizado, asegúrese de que el método IsContentTypeSupported se implemente correctamente...

¿alguna idea de porque?...gracias

[marine]

[quote=pilarinweb;518590]

Empezado por inyu

¿ Si estáis en .NET por qué no agregáis una referencia al servicio ? no hace falta ir deserializando ni nada, tratas directamente con las clases, métodos y propiedades que se generan automáticamente al agregar la referencia al wsdl. ->

porque al hacer
resp = oSiiSFE.SuministroLRFacturasEmitidas(oSfe);
me da el error:
El tipo de contenido text/html del mensaje de respuesta no coincide con el tipo de contenido del enlace (text/xml; charset=utf-8). Si usa un codificador personalizado, asegúrese de que el método IsContentTypeSupported se implemente correctamente...

¿alguna idea de porque?...gracias

Comprueba que en tu app.config tienes configurado asi el binding.

        <binding name="siiBinding" maxReceivedMessageSize="1310720">
          <security mode="Transport">
            <transport clientCredentialType="Certificate" />
          </security>
        </binding>

[JJAlf]

Empezado por CMB

Este hilo llegará hoy a las 64.000 vistas. No está mal.

No me extraña, yo soy una de ellas (de hace un tiempo) y desde aquí el agradecimiento a que hayáis dedicado tanto tiempo a resolver dudas y poner blanco sobre negro temas que a muchos programadores se nos escapan.
Tengo el tema en fases finales de desarrollo (sobre todo gracias a este foro) y entre ellas, mejora de controles existentes. Unas dudas:

1. ¿Habéis constatado que en el mensaje de respuesta los documentos vayan en el orden en que se han enviado? Yo he forzado envío de documentos 'desordenados' y parece que me lo devuelven en el mismo 'desorden'... Más que nada por la tarea de marcar los documentos. Si me los devuelven en orden, a medida que los envío me voy grabando mi propia lista con su ID único, porque es un poco farragoso volver a buscar entre las enviadas por NIF, número y demás. Ya podían haber pensado en un ID interno para comunicarnos...
   
2. ¿Hay algún otro método aparte de la capicom (y de las SecureBlackBox) para hacer un Cert.Load? Me ha venido de p.m., porque me guardo el certificado en la bbdd (quisquillosidad de los clientes a instalar certificados por ahí) y lo descargo a un archivo temporal y lo cargo con esa función. Pero al ir a crear el proyecto como webservice en 64bits me encuentro con que no puedo usar la capicom por ser librería de 32bits. No es un problema, pero me gusta dejar las cosas finas...
   
3. Y la más importante. Yo compagino clientes que envían directamente las facturas a la AEAT con mi servicio y clientes que van a usar terceros (SERES, EDICOM) para ello. Claro, no hago dos programaciones. Para estos últimos les envío el XML generado con el WSDL. Para ello, en esos casos, no cargo el certificado, capturo el XML en BeforeExecute y me 'trago' el error que da por no tener certificado, pero no me parece una solución 'limpia'. ¿Hay alguna manera de conseguir el XML SIN intentar un envío?

Gracias, y lo dicho, chapeau por el hilo. Espero poder aportar algo más que preguntas...

[vboloradito]

Empezado por JJAlf

Y la más importante. Yo compagino clientes que envían directamente las facturas a la AEAT con mi servicio y clientes que van a usar terceros (SERES, EDICOM) para ello. Claro, no hago dos programaciones. Para estos últimos les envío el XML generado con el WSDL. Para ello, en esos casos, no cargo el certificado, capturo el XML en BeforeExecute y me 'trago' el error que da por no tener certificado, pero no me parece una solución 'limpia'. ¿Hay alguna manera de conseguir el XML SIN intentar un envío?

¿Ves alguna ventaja en usar SERES o EDICOM frente a hacerlo a pelo contra la AEAT?

[CMB]

Empezado por vboloradito

¿Ves alguna ventaja en usar SERES o EDICOM frente a hacerlo a pelo contra la AEAT?

La ventaja es para las empresas intermediarias, que aumentan su facturación a cambio de casi nada.

[JJAlf]

Empezado por vboloradito

¿Ves alguna ventaja en usar SERES o EDICOM frente a hacerlo a pelo contra la AEAT?

En mi caso no, porque igualmente tengo hacerlo directo contra AEAT y el usar además otro interlocutor me complica la existencia. Pero entiendo que si sólo tuviera que interactuar con ellos, el sistema se 'simplifica', en cuanto a que te olvidas en muchos casos de complejos componentes (THTTPRio, parseadores XML, Certificados, XLDS...) y normalmente te ofrecen dejarles los datos en simples ficheros planos. De las versiones, validaciones y demás se encargan ellos, yo sólo formateo los datos y recibo resultados.
Eso sí, no son precisamente baratos. Lo que ocurre es que muchas veces (como es mi caso) ya trabajan con esas empresas para la recepción y envío de documentos. Lo cual no supone que les vayan a cobrar poco, pero el cliente manda...

[austral_es]

Buenas, estamos aquí intentando hacer pruebas con el NIF NO CENSADO (novedad en la 0.7) pero no nos acepta el error

"Error en el bloque de la Contraparte. El NIF no está identificado."

Lo hemos probado con un NIF que sabemos que no existe, pero que tiene la letra correcta 99999999R

Vosotros lo habéis conseguido, ¿remitir con NIF no censado? si es así que Nif habéis utilizado, gracias!

Nota: Por cierto creemos que ya esta en funcionamiento el web service de la 0.7 porque enviamos una razón social de mas de 40 caracteres (en la versión 0.6 eran 40 de máximo y en la 0.7 son 120) y lo acepto sin problemas.

[javi_valencia44]

Empezado por austral_es

Buenas, estamos aquí intentando hacer pruebas con el NIF NO CENSADO (novedad en la 0.7) pero no nos acepta el error

"Error en el bloque de la Contraparte. El NIF no está identificado."

Lo hemos probado con un NIF que sabemos que no existe, pero que tiene la letra correcta 99999999R

Vosotros lo habéis conseguido, ¿remitir con NIF no censado? si es así que Nif habéis utilizado, gracias!

Nota: Por cierto creemos que ya esta en funcionamiento el web service de la 0.7 porque enviamos una razón social de mas de 40 caracteres (en la versión 0.6 eran 40 de máximo y en la 0.7 son 120) y lo acepto sin problemas.

En el bloque IdOtro has puesto ese nif también y la clave 07?

[CMB]

Empezado por austral_es

Buenas, estamos aquí intentando hacer pruebas con el NIF NO CENSADO (novedad en la 0.7) pero no nos acepta el error
"Error en el bloque de la Contraparte. El NIF no está identificado."
Lo hemos probado con un NIF que sabemos que no existe, pero que tiene la letra correcta 99999999R
Vosotros lo habéis conseguido, ¿remitir con NIF no censado? si es así que Nif habéis utilizado, gracias!
Nota: Por cierto creemos que ya esta en funcionamiento el web service de la 0.7 porque enviamos una razón social de mas de 40 caracteres (en la versión 0.6 eran 40 de máximo y en la 0.7 son 120) y lo acepto sin problemas.

Con los no censados hay que poner IDType = '07'.

[mrobles]

Empezado por vboloradito

Mi cliente en ocasiones emite factura nº1, se da cuenta de que esta mal, genera otra igual con el mismo importe pero en negativo nº2 y luego genera la tercera definitiva nº3.

LAS dos primera nº1 y nº2 no se las envia al cliente.
LA tercera si.

¿que hago ahora yo?
1 - ¿Solo envio al SII las que envio al cliente nº3 y dejo un salto en la secuencia de la serie factura sin envair a la AEAT.?
2 -¿ Envio todas al SII para que tenga la secuencia de la serie completa pero no se la envio al cliente (luego no cuadraran en el contraste)?
3 - ¿Envio todo al SII y al cliente para que este tambien la pueda subir al SII?

Tienes que hacer una rectificativa por sustitucion
8.1.9. Alta Factura Rectificativa por sustitución “S” en el Libro de registro Facturas Expedidas
http://www.agenciatributaria.es/stat...ioWeb_v0.7.pdf

Empezado por austral_es

Buenas, estamos aquí intentando hacer pruebas con el NIF NO CENSADO (novedad en la 0.7) pero no nos acepta el error

"Error en el bloque de la Contraparte. El NIF no está identificado."

Lo hemos probado con un NIF que sabemos que no existe, pero que tiene la letra correcta 99999999R

Vosotros lo habéis conseguido, ¿remitir con NIF no censado? si es así que Nif habéis utilizado, gracias!

Nota: Por cierto creemos que ya esta en funcionamiento el web service de la 0.7 porque enviamos una razón social de mas de 40 caracteres (en la versión 0.6 eran 40 de máximo y en la 0.7 son 120) y lo acepto sin problemas.

Tiene que ser tipo 07 e incluir los campos, ademas creo que tienes que hacer 2 intentos antes

8.1.1.4.Ejemplo mensaje XML de alta cuando la contraparte no está censada
Para los casos en que se haya rechazado una factura emitida debido a que la contraparte (NIF y nombre) no está censada en la AEAT, podrá
enviar dicha factura, en un segundo intento, suministrando el NIF en el bloque <IdOtro> con los siguientes contenidos:
Código país: ES
Clave ID: 07. No censado
Número Id: NIF no censado del receptor de la factura
Apellidos y nombre: Nombre del no censado receptor de la factura.
En este caso, la factura figurará en el SII como aceptada con errores. En cualquier caso un error de formato en el NIF supondrá un rechazo de
la factura.
XML de entrada

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:siiLR="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/ssii/fact/ws/SuministroLR.xsd"
                  xmlns:sii="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/ssii/fact/ws/SuministroInformacion.xsd">
    <soapenv:Header/>
    <soapenv:Body>
        <siiLR:SuministroLRFacturasEmitidas>
            <sii:Cabecera>
                <sii:IDVersionSii>0.7</sii:IDVersionSii>
                <sii:Titular>
                    <sii:NombreRazon>EMPRESAXXXXXXXXXXXXX</sii:NombreRazon>
                    <sii:NIF>A84532501</sii:NIF>
                </sii:Titular>
                <sii:TipoComunicacion>A0</sii:TipoComunicacion>
            </sii:Cabecera>
            <siiLR:RegistroLRFacturasEmitidas>
                <sii:PeriodoImpositivo>
                    <sii:Ejercicio>2017</sii:Ejercicio>
                    <sii:Periodo>01</sii:Periodo>
                </sii:PeriodoImpositivo>
                <siiLR:IDFactura>
                    <sii:IDEmisorFactura>
                        <sii:NIF>A84532501</sii:NIF>
                    </sii:IDEmisorFactura>
                    <sii:NumSerieFacturaEmisor>01</sii:NumSerieFacturaEmisor>
                    <sii:FechaExpedicionFacturaEmisor>15-01-2017</sii:FechaExpedicionFacturaEmisor>
                </siiLR:IDFactura>
                <siiLR:FacturaExpedida>
                    <sii:TipoFactura>F1</sii:TipoFactura>
                    <sii:ClaveRegimenEspecialOTrascendencia>01</sii:ClaveRegimenEspecialOTrascendencia>
                    <sii:ImporteTotal>26.70</sii:ImporteTotal>
                    <sii:DescripcionOperacion>VentaXXXXXXX</sii:DescripcionOperacion>
                    <sii:Contraparte>
                        <sii:NombreRazon>EMPRESAYYYYYYYY</sii:NombreRazon>
                        <sii:IDOtro>
                            <sii:CodigoPais>ES</sii:CodigoPais>
                            <sii:IDType>07</sii:IDType>
                            <sii:ID>94234500B</sii:ID>
                        </sii:IDOtro>
                    </sii:Contraparte>
                    <sii:TipoDesglose>
                        <sii:DesgloseFactura>
                            <sii:Sujeta>
                                <sii:NoExenta>
                                    <sii:TipoNoExenta>S1</sii:TipoNoExenta>
                                    <sii:DesgloseIVA>
                                        <sii:DetalleIVA>
                                            <sii:TipoImpositivo>21</sii:TipoImpositivo>
                                            <sii:BaseImponible>22.07</sii:BaseImponible>
                                            <sii:CuotaRepercutida>4.63</sii:CuotaRepercutida>
                                        </sii:DetalleIVA>
                                    </sii:DesgloseIVA>
                                </sii:NoExenta>
                            </sii:Sujeta>
                        </sii:DesgloseFactura>
                    </sii:TipoDesglose>
                </siiLR:FacturaExpedida>
            </siiLR:RegistroLRFacturasEmitidas>
        </siiLR:SuministroLRFacturasEmitidas>
    </soapenv:Body>
</soapenv:Envelope>

[vboloradito]

Empezado por JJAlf

En mi caso no, porque igualmente tengo hacerlo directo contra AEAT y el usar además otro interlocutor me complica la existencia. Pero entiendo que si sólo tuviera que interactuar con ellos, el sistema se 'simplifica', en cuanto a que te olvidas en muchos casos de complejos componentes (THTTPRio, parseadores XML, Certificados, XLDS...) y normalmente te ofrecen dejarles los datos en simples ficheros planos. De las versiones, validaciones y demás se encargan ellos, yo sólo formateo los datos y recibo resultados.
Eso sí, no son precisamente baratos. Lo que ocurre es que muchas veces (como es mi caso) ya trabajan con esas empresas para la recepción y envío de documentos. Lo cual no supone que les vayan a cobrar poco, pero el cliente manda...

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.

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

[Virman]

Cómo puede ser que esté enviando una factura con la versión 0.6 del SII, que ayer me dejaba enviar, sólo he cambiado el número de serie para que no me tire error de duplicado, ahora me muestra el error:

Codigo[4121].Error en asincrono de cuadre
Código (ITEADEST/ES.AEAT.SSII.FACT.API.FE.ASINC.CONSUEMITSRV/20170517) no existe

En principio se podrían enviar facturas con la versión 0.6 hasta finales de mes, no? A alguien más le da este error? Sino recuerdo mal, la información de cuadre se ponía en la versión 0.7 pero no debería pedirla si hacemos envíos con la versión 0.6

[mrobles]

Empezado por Virman

Cómo puede ser que esté enviando una factura con la versión 0.6 del SII, que ayer me dejaba enviar, sólo he cambiado el número de serie para que no me tire error de duplicado, ahora me muestra el error:

Codigo[4121].Error en asincrono de cuadre
Código (ITEADEST/ES.AEAT.SSII.FACT.API.FE.ASINC.CONSUEMITSRV/20170517) no existe

En principio se podrían enviar facturas con la versión 0.6 hasta finales de mes, no? A alguien más le da este error? Sino recuerdo mal, la información de cuadre se ponía en la versión 0.7 pero no debería pedirla si hacemos envíos con la versión 0.6

4121 Error tecnico al procesar cuadre

No sera que reiniciaran los datos o algo?, yo voy a empezar las pruebas de la 0.7 ahora mismo y si sale te comento