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

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)

- Internet (https://www.clubdelphi.com/foros/forumdisplay.php?f=3)

- - SII -Nuevo sistema de la Agencia Tributaria española de envío de datos vía Webservice (https://www.clubdelphi.com/foros/showthread.php?t=91252)

Si, pero recibo esto:

Código:

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

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

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!

Cita:

Empezado por CMB (Mensaje 516715)

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:

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

Cita:

Empezado por mrobles (Mensaje 516712)

Te falta un campo por lo que veo

Código:

<sii:IDOtro>

                            <sii:CodigoPais>PT</sii:CodigoPais>

                            <sii:IDType>02</sii:IDType>

                            <sii:ID>PT999999999D</sii:ID>

</sii:IDOtro>

acabo de hacer una prueba, y mandandole un id (no valido), si que pasa el registro ¿?, tengo entendido que si indicas el idtype 06, no es necesario informar de ningún identificador...

Cita:

Empezado por 2uolap2 (Mensaje 516714)

Si, pero recibo esto:

Código:

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

...

Tienes un ejemplo mio probado en la respuesta #1010
http://www.clubdelphi.com/foros/show...postcount=1010

Cita:

Empezado por JJAlf (Mensaje 516717)

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

Existe un ID interno que se llama CSV

Cita:

Empezado por Galahad (Mensaje 516718)

acabo de hacer una prueba, y mandandole un id (no valido), si que pasa el registro ¿?, tengo entendido que si indicas el idtype 06, no es necesario informar de ningún identificador...

Creo que es obligatorio siempre, a excepcion de si hiciste 2 intentos, que entonces puedes poner el tipo 07 y no es necesario

Código:

3.7. ¿Cómo se registra una Exportación?

La operación se anota en el Libro Registro de Facturas Expedidas.

En el campo “Clave Régimen especial o Trascendencia” se consignará el valor 02.

Deberá identificarse al cliente – en caso de ser extranjero- mediante el “Código país” y

las claves 3 “Pasaporte”, 4 “Documento oficial de identificación expedido por el país o

territorio de residencia”, 5 “Certificado de residencia” ó 6 “Otro documento probatorio”

del campo “IDType”.

Por otra parte, la base imponible de la factura se incluirá en el campo de tipo de

operación “Exenta” dentro del bloque “Entrega”. Como causa de exención se

consignará la clave E2 “Exenta por el artículo 21”.

Cita:

Empezado por mrobles (Mensaje 516719)

Existe un ID interno que se llama CSV

Creo que es obligatorio siempre, a excepcion de si hiciste 2 intentos, que entonces puedes poner el tipo 07 y no es necesario

Código:

3.7. ¿Cómo se registra una Exportación?

La operación se anota en el Libro Registro de Facturas Expedidas.

En el campo “Clave Régimen especial o Trascendencia” se consignará el valor 02.

Deberá identificarse al cliente – en caso de ser extranjero- mediante el “Código país” y

las claves 3 “Pasaporte”, 4 “Documento oficial de identificación expedido por el país o

territorio de residencia”, 5 “Certificado de residencia” ó 6 “Otro documento probatorio”

del campo “IDType”.

Por otra parte, la base imponible de la factura se incluirá en el campo de tipo de

operación “Exenta” dentro del bloque “Entrega”. Como causa de exención se

consignará la clave E2 “Exenta por el artículo 21”.

El CSV identifica el envío, que puede incluir varias facturas y también se recibe en modificaciones y bajas.

La factura se identifica mediante en bloque IDFactura del xml. Juntas los valores de todos los campos que intervienen y ya tienes tu ID único.

Un saludo.

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

Cita:

Empezado por Virman (Mensaje 516732)

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

Cita:

Empezado por Virman (Mensaje 516732)

A mi no me lo ha pedido. Lo único que he cambiado ha sido la versión del 0.6 al 0.7 y me ha funcionado sin problemas.
Nota para los desarrolladores de .Net: al actualizar la url del webservice (de la v0.6 a la v0.7) he tenido que modificar de nuevo el app.config que lo dejaba mal (no usa soap 1.1 etc...).

Cita:

Empezado por figo21 (Mensaje 516727)

Efectivamente, es lo que toca hacer. Es que en otras comunicaciones que he hecho entre sistemas, el que genera la información identifica cada documento que envía con un ID propio, independiente de la información que se envíe, y en las respuestas se hace referencia a ese ID, lo cual es mucho más cómodo y eficiente a la hora de tratar la información.
En fins...

Cita:

Empezado por pprieto (Mensaje 516735)

Podrías indicar el cambio que has hecho en el fichero app.config? He revisado todas las direcciones de los wsdl y ahora me dice: Codigo[4124].Error La direccion no se corresponde con el fichero de entrada.

Al actualizar pone el valor soap:address location="xxxxxxx", pero aunque he puesto las de prueba me sigue diciendo que la dirección no se corresponde con el fichero de entrada y, dado que tu comentas lo de soap, seguro que en app.config me falta algo por añadir.

Muchas gracias de antemano.

Cita:

Empezado por JJAlf (Mensaje 516717)

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?

Uno más que se añade al grupo de sufridores por cambios de versión y demás...

Ayer lo dejé funcionando correctamente asentando la factura de prueba sin novedad y al volver a darle hoy, en lugar de avisarme de que está repetida, lo que me dice es lo siguiente:

Código:

factura: A-451245  01/01/2017

Error no.: 1177

Valor del campo TipoRecargoEquivalencia no está incluido en la lista de valores permitidos

Haciendo pruebas, me he fijado que la única forma que tengo de que acepte la factura es poniendo:

Código:

IVAS[0].TipoRecargoEquivalencia:='';

en lugar de como lo tenía hasta ahora:

Código:

IVAS[0].TipoRecargoEquivalencia:='0';

Se supone que ayer actualice las WSDL. ¿Cómo puedo saber que versión es la que estoy utilizando realmente?

Cita:

Empezado por vboloradito (Mensaje 516739)

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

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?

Cita:

Empezado por Virman (Mensaje 516738)

Lo tienes que tener así:

<bindings>
<basicHttpBinding>
<binding name="siiBinding">
<security mode="Transport">
<transport clientCredentialType="Certificate" />
</security>
</binding>
</basicHttpBinding>
<customBinding>
<binding name="siiBinding">
<textMessageEncoding messageVersion="Soap11" />
<httpsTransport />
</binding>
</customBinding>
</bindings>

Es decir, le tienes que forzar a Certificate y utilizar Soap 1.1. Lo he sacado de stackoverflow (no te puedo poner el enlace porque no me deja el foro).

Cita:

Empezado por dgcapel (Mensaje 516716)

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.

Cita:

Empezado por nincillo (Mensaje 516740)

Código:

factura: A-451245  01/01/2017

Error no.: 1177

Valor del campo TipoRecargoEquivalencia no está incluido en la lista de valores permitidos

Haciendo pruebas, me he fijado que la única forma que tengo de que acepte la factura es poniendo:

Código:

IVAS[0].TipoRecargoEquivalencia:='';

en lugar de como lo tenía hasta ahora:

Código:

IVAS[0].TipoRecargoEquivalencia:='0';

Se supone que ayer actualice las WSDL. ¿Cómo puedo saber que versión es la que estoy utilizando realmente?

A mi me ha pasado lo mismo, ahora no se pone 0 es vacio ^\||/

Cita:

Empezado por vboloradito (Mensaje 516742)

En caso de duda siempre mejor la 3ª opción, te ahorras posibles disgustos futuros