Varios Xml o uno solo
 

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

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

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

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

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.

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.

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.

probado y funcionando , gracias !

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.

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:

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.

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.

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.

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

Gracias

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:


El codigo que tengo creado es este:
Muchas gracias de antemano.

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

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)

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

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.