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

[didou]

Buenos días.

¿ Las Altas, Bajas, Modificaciones de facturas Emitidas pueden ir en un mismo XML o deben de ir separadas en XML distintos?

Igualmente los periodos deben ir en XMLs distintos (por cada periodo) o todos en el mismo?




Muchas gracias, un saludo.

[javi_valencia44]

Empezado por didou

Buenos días.

¿ Las Altas, Bajas, Modificaciones de facturas Emitidas pueden ir en un mismo XML o deben de ir separadas en XML distintos?

Igualmente los periodos deben ir en XMLs distintos (por cada periodo) o todos en el mismo?




Muchas gracias, un saludo.

Un XML distinto en ambos casos

[keys]

Por cierto en el fichero que te desgargas ahora del 0.7 hay distintos paises que los que había cuando me lo descargue en su momento. Por ejemplo este QU, que como ha dicho no está en el pdf y no han informado en ningún momento que yo sepa.

Habrá que esperar al último momento a descarse otra vez la información ya que puede haber cambios de los que no avisan.

Un Urra por nuestra Agencia Tributaria.

[PepCat]

Empezado por marine

Buenas! ,

Error 1100 . Valor o tipo incorrecto del campo: BaseImponible

Si que se permiten facturas con base 0. Lo unico que tienes que hacer es poner un 0 en la <baseimponible>

<TipoImpositivo>0</TipoImpositivo>
<BaseImponible>0</BaseImponible>
<CuotaRepercutida>0</CuotaRepercutida>

[lsgrep]

Empezado por keys

Por cierto en el fichero que te desgargas ahora del 0.7 hay distintos paises que los que había cuando me lo descargue en su momento. Por ejemplo este QU, que como ha dicho no está en el pdf y no han informado en ningún momento que yo sepa.

Habrá que esperar al último momento a descarse otra vez la información ya que puede haber cambios de los que no avisan.

Un Urra por nuestra Agencia Tributaria.

Gracias keys, ya he mandado con QU las que me faltaban y han entrado pero como dices no había ninguna documentación sobre esto si no mirabas el formulario manual de entrada

[lsgrep]

De hecho, ahora me encuentro con el último problema:

Cuando pongo el NIF/CIF en algunos casos me responde:

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

Por lo que he podido ver, consultando la parte de "Consulta NIF" si el nombre o razón social no está como ellos lo tienen censado no te acepta la factura.

Pienso que únicamente con poner el NIF/CIF debería aceptarlo el problema es ¿donde se obtiene el nombre o razón social que ellos tienen?

He probado de enviarlas con el campo IDotro y 07 y la aceptan pero con errores.

La verdad es que no tengo ni idea que debe hacer contabilidad. Buscar la razón social censada o enviarlo como 07 pero de todas formas al ser un alta con errores hay que corregirlo ¿no?

¿Alguien se ha encontrado con este caso ? La utilidad para buscar el NIF/CIF que proporcionan necesita la razón social y no devuelve exactamente como la tienen ellos así que no tengo ni idea de como informar esto.

Salu2

[keys]

Empezado por lsgrep

De hecho, ahora me encuentro con el último problema:

Cuando pongo el NIF/CIF en algunos casos me responde:

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

Por lo que he podido ver, consultando la parte de "Consulta NIF" si el nombre o razón social no está como ellos lo tienen censado no te acepta la factura.

Pienso que únicamente con poner el NIF/CIF debería aceptarlo el problema es ¿donde se obtiene el nombre o razón social que ellos tienen?

He probado de enviarlas con el campo IDotro y 07 y la aceptan pero con errores.

La verdad es que no tengo ni idea que debe hacer contabilidad. Buscar la razón social censada o enviarlo como 07 pero de todas formas al ser un alta con errores hay que corregirlo ¿no?

¿Alguien se ha encontrado con este caso ? La utilidad para buscar el NIF/CIF que proporcionan necesita la razón social y no devuelve exactamente como la tienen ellos así que no tengo ni idea de como informar esto.

Salu2

Yo creo que la unica solución es que en tu programa de contabilidad tengan los datos bien metidos. Ya que el enviar todo con 07 te la aceptan pero con errores y me imagino que en el futuro te lleguen los problemas. La razón social la puedes obtener del servicio de hacienda, pero de las personas fisicas el nombre y los apellidos no por la LOPD.

[lsgrep]

Empezado por keys

Yo creo que la unica solución es que en tu programa de contabilidad tengan los datos bien metidos. Ya que el enviar todo con 07 te la aceptan pero con errores y me imagino que en el futuro te lleguen los problemas. La razón social la puedes obtener del servicio de hacienda, pero de las personas fisicas el nombre y los apellidos no por la LOPD.

Si, pero el principal problema en las personas físicas es como obtener correctamente el nombre y apellidos que tienen censados en hacienda. Si es como dices que la LOPD no permite ofrecer esta información debería ser suficiente con indicar el NIF y aceptarlas. El problema no es arreglarlo es como obtener la información correcta. Yo creo que si se lo preguntan al cliente no va a tener ni idea de como tiene los datos censados en hacienda.

Tal y como nos dijo una persona un alta con errores implica que hay que revisar los datos así que un 07 no sirve de mucho en esta caso como bien dices.

[keys]

Hombre una persona fisica no sabrá como tiene sus datos censados en hacienda. Pero sus apellidos y nombre ya sabrá. Y en ese caso es para el que está pensado el tipo 07, cuando no tienes forma de obtener los datos de tu cliente.

[marine]

Empezado por PepCat

Si que se permiten facturas con base 0. Lo unico que tienes que hacer es poner un 0 en la <baseimponible>

<TipoImpositivo>0</TipoImpositivo>
<BaseImponible>0</BaseImponible>
<CuotaRepercutida>0</CuotaRepercutida>

probado y funcionando , gracias !

[lsgrep]

Empezado por keys

Hombre una persona fisica no sabrá como tiene sus datos censados en hacienda. Pero sus apellidos y nombre ya sabrá. Y en ese caso es para el que está pensado el tipo 07, cuando no tienes forma de obtener los datos de tu cliente.

Yo hice la prueba con un caso en el que nos rechazaron la factura por que el nombre/razón social no coincidía. Fui a la utilidad de hacienda y puse el NIF y el nombre y apellidos que nos había facilitado el cliente. La utilidad me devolvía todo el rato que no estaba identificada. Como era una prueba fui a Google y busque su NIF y me apareció el nombre tal y como estaba informado en una comunicación del BOE (tuve suerte en este caso) y cogí el nombre tal cual figuraba lo puse en la utilidad y voila la aceptó. El nombre y apellidos no coincidía no sólo por el orden sino por que la persona tenía un nombre compuesto. Como este caso debe haber mil. Aunque sepas su nombre y apellidos el caso que te comento es usual y encontrarlo es el problema.

[CMB]

¿ Las Altas, Bajas, Modificaciones de facturas Emitidas pueden ir en un mismo XML o deben de ir separadas en XML distintos?
Igualmente los periodos deben ir en XMLs distintos (por cada periodo) o todos en el mismo?

Empezado por javi_valencia44

Un XML distinto en ambos casos

Acabo de hacer una prueba enviando en un mismo XML una factura emitida en mayo y otra en junio, y han sido ambas aceptadas sin problema.

De hecho el bloque de cada factura ya incluye el período a que corresponde:

<siiLR:RegistroLRFacturasEmitidas>
  <sii:PeriodoImpositivo>
    <sii:Ejercicio>2017</sii:Ejercicio>
    <sii:Periodo>05</sii:Periodo>
  </sii:PeriodoImpositivo>

javi_valencia44, ¿estás completamente seguro de que no se puede?

Este detalle es muy importante, porque en la fase de producción en los primeros días de mes es posible que se mezclen facturas de los últimos días del mes anterior con las del mes actual.

[keys]

Empezado por lsgrep

Yo hice la prueba con un caso en el que nos rechazaron la factura por que el nombre/razón social no coincidía. Fui a la utilidad de hacienda y puse el NIF y el nombre y apellidos que nos había facilitado el cliente. La utilidad me devolvía todo el rato que no estaba identificada. Como era una prueba fui a Google y busque su NIF y me apareció el nombre tal y como estaba informado en una comunicación del BOE (tuve suerte en este caso) y cogí el nombre tal cual figuraba lo puse en la utilidad y voila la aceptó. El nombre y apellidos no coincidía no sólo por el orden sino por que la persona tenía un nombre compuesto. Como este caso debe haber mil. Aunque sepas su nombre y apellidos el caso que te comento es usual y encontrarlo es el problema.

Para estos casos esta el 07. Yo con todas las pruebas que he hecho no me he encontrado con este problema que comentas y tengo varias empresas probando con datos reales, no se si a alguien tambien le habrá pasado lo que tu comentas.

[jcapilla]

Hola.

Respeto al tema de las facturas a Canarias y demas lo que tengo entendido despues de hablar con varios asesores es lo siguiente:
De Peninsulta a Canarias: Clave 02 Exportacion
Factura emitida en Canarias: Clave 08 (IPSI/IGIC) No Sujeta con el campo ImporteTAIReglasLocalizacion informado.

[javi_valencia44]

Empezado por CMB

Acabo de hacer una prueba enviando en un mismo XML una factura emitida en mayo y otra en junio, y han sido ambas aceptadas sin problema.

De hecho el bloque de cada factura ya incluye el período a que corresponde:

<siiLR:RegistroLRFacturasEmitidas>
  <sii:PeriodoImpositivo>
    <sii:Ejercicio>2017</sii:Ejercicio>
    <sii:Periodo>05</sii:Periodo>
  </sii:PeriodoImpositivo>

javi_valencia44, ¿estás completamente seguro de que no se puede?

Este detalle es muy importante, porque en la fase de producción en los primeros días de mes es posible que se mezclen facturas de los últimos días del mes anterior con las del mes actual.

Me sorprende que se pueda, pensaba que no la verdad.

Gracias

[Patry159]

Hola, a ver si alguien me puede echar una mano porque ya no sé como solucionar este fallo(He leído todos los posts y a simple vista tengo lo mismo que lo descrito por otros pero ya no sé si me falta algo).... Estoy intentando enviar las facturas mediante el web service. Al declarar el objeto siiSOAPClient no me da ningún fallo pero al ejecutarlo me da el siguiente error:

No se encontró el elemento de extremo con el nombre 'SuministroFactRecibidasPruebas' y el contrato 'SuministroFacturasRecibidas.siiSOAP' en la sección de configuración de cliente de ServiceModel. La razón puede ser que no se encontró ningún archivo de configuración para la aplicación o que no se encontró ningún elemento de extremo con este nombre en el elemento de cliente.

El codigo que tengo creado es este:

  
   Dim store As Security.Cryptography.X509Certificates.X509Store = New Security.Cryptography.X509Certificates.X509Store(StoreName.My, StoreLocation.CurrentUser)
            store.Open(Security.Cryptography.X509Certificates.OpenFlags.ReadOnly)

            Dim Certificado As New System.Security.Cryptography.X509Certificates.X509Certificate2
            Certificado = store.Certificates(0)


            Dim respuesta() As RespuestaLRFRecibidasType
            Dim SuministroC As New SuministroLRFacturasRecibidas
            Dim SuministroD() As LRFacturasRecibidasType

                     ....'todo el desarrollo de implementar los objetos con los valores de las facturas'

           SuministroC.RegistroLRFacturasRecibidas = SuministroD

            Dim Subir As New siiSOAPClient()         'En este punto es donde me da el error'
            Subir.ClientCredentials.ClientCertificate.Certificate = Certificado
          
            respuesta = Subir.SuministroLRFacturasRecibidas(SuministroC)

Muchas gracias de antemano.

[Sergio J.]

Hola a todos. Estoy, por un lado orgulloso de pertenecer a este club desde que empecé a chapurrear delphi y tranquilo por la información aportada a este hilo sobre el famoso SII hasta hace poco desconocido para mí, y por otro agobiado por tener que dar solución a un cliente que está acogido al REDEME y me pidió que le diera una solución el otro día, sin tener conocimiento de lo que me esperaba y en tan poco tiempo .
Como trabajo con delphi 6, a la hora de crear el XML, tendré que hacerlo a mano, pero para enviarlo a través de Web Service y el tema de la autenticación tenía pensado crear un proyecto nuevo con Delphi XE7 o subirlo con algún formulario al estilo que ahora tiene publicado la AEAT en su enlace https://www7.aeat.es/static_files/co...teWSAEAT2.html para pruebas, pero no sé si para envíos reales habrá una plataforma similar para hacerlo a partir del 1 de Julio.
He leído gran parte de este hilo pero no sé con seguridad si se podrá.

¿Alguien sabe algo al respecto? Agradecería cualquier referencia, muchísimas gracias.

[nuevo1234]

Empezado por lsgrep

Hola a todos!

Como nosotros exportamos a muchos países me he encontrado que por ejemplo el código MQ (Martinica) no está en la lista de códigos aceptados por el ENUM del SIII. ¿Alguien ha consultado al SIII por este tema? Yo les envié otra pregunta hace ya 3 semanas y no he tenido contestación.

Resumen, no tengo ni idea de como mandarles estas facturas con el país que hago referencia.

Salu2

Mira en el BOE de la lista de paises. Hay un link en la documentacion
http://www.boe.es/boe/dias/2011/12/2...2011-20179.pdf

FR FRANCIA (Incluidos los departamentos franceses de ultramar: Reunión, Guadalupe, Martinica y Guayana Francesa)

[Patry159]

Hola, pregunté a Hacienda y me dijeron que si, que mantendrían la plataforma que hay.

Empezado por Sergio J.

Hola a todos. Estoy, por un lado orgulloso de pertenecer a este club desde que empecé a chapurrear delphi y tranquilo por la información aportada a este hilo sobre el famoso SII hasta hace poco desconocido para mí, y por otro agobiado por tener que dar solución a un cliente que está acogido al REDEME y me pidió que le diera una solución el otro día, sin tener conocimiento de lo que me esperaba y en tan poco tiempo .
Como trabajo con delphi 6, a la hora de crear el XML, tendré que hacerlo a mano, pero para enviarlo a través de Web Service y el tema de la autenticación tenía pensado crear un proyecto nuevo con Delphi XE7 o subirlo con algún formulario al estilo que ahora tiene publicado la AEAT en su enlace para pruebas, pero no sé si para envíos reales habrá una plataforma similar para hacerlo a partir del 1 de Julio.
He leído gran parte de este hilo pero no sé con seguridad si se podrá.

¿Alguien sabe algo al respecto? Agradecería cualquier referencia, muchísimas gracias.

[keys]

Empezado por Sergio J.

Hola a todos. Estoy, por un lado orgulloso de pertenecer a este club desde que empecé a chapurrear delphi y tranquilo por la información aportada a este hilo sobre el famoso SII hasta hace poco desconocido para mí, y por otro agobiado por tener que dar solución a un cliente que está acogido al REDEME y me pidió que le diera una solución el otro día, sin tener conocimiento de lo que me esperaba y en tan poco tiempo .
Como trabajo con delphi 6, a la hora de crear el XML, tendré que hacerlo a mano, pero para enviarlo a través de Web Service y el tema de la autenticación tenía pensado crear un proyecto nuevo con Delphi XE7 o subirlo con algún formulario al estilo que ahora tiene publicado la AEAT en su enlace https://www7.aeat.es/static_files/co...teWSAEAT2.html para pruebas, pero no sé si para envíos reales habrá una plataforma similar para hacerlo a partir del 1 de Julio.
He leído gran parte de este hilo pero no sé con seguridad si se podrá.

¿Alguien sabe algo al respecto? Agradecería cualquier referencia, muchísimas gracias.

En principio parece que eso lo van a mantener también en producción. El problema es que el cliente tiene que poner los enpoint para cada envío que tenga que realizar, es decir para emitidas uno, para recibidas otro, etc ..... y claro pierdes la interacción con las respuestas de hacienda.