Cuando la reclamación del cliente es claramente causada por terceros no hay que tener pelos en la lengua y decirlo sin tapujos. Nosotros tenemos esa costumbre. No hemos de cargar con las ineficiencias de los demás y lo expresamos con toda la contundencia posible. Que cada palo aguante su vela.

Libro registro de facturas recibidas:
. Fecha registro contable: Fecha del envío.

Estoy pendiente de respuesta de la AEAT pero necesito sacar hoy la versión y tengo dudas en el dato Fecha registro contable...
alguién me puede decir que fecha introduce para los envios del primer semestre...
muchas gracias...

Nosotros marcamos las facturas enviadas en la aplicación del cliente y es lo que usarán para hacer su liquidación. Leyendo mas detenidamente la FAQ lo único nuevo es que con la cosulta vía formulario (porque la consulta via servicio web ya estaba) marcando la opcion "Todas las columnas" en la consulta se puede exportar todos los campos de las facturas enviadas a un excel (con un máximo de 1000).

Entiendo que esa opción puede ser útil si no se tiene registrado las facturas enviadas en la aplicación del cliente. Nosotros no lo vamos a usar. Sabemos lo que hemos enviado, porque lo hemos marcado en la respuesta de los envíos realizados.

Las facturas de 1º semestre hay que enviarlas en registros XML iguales que las del 2º, obviamente con la clave de tipo de operación pertinente (16 o 14) y solo con las reglas y valores que eran obligatorias en el modelo 340; el sistema de al AEAT se adaptará en consecuencia.

Por ejemplo, la descripción de la factura es una novedad del nuevo sistema y entró en vigor solo el 1/7/2017, no es exigible para las facturas del 1º semestre. Pero el XML exige un valor en este elemento: entonces puedes poner el texto fijo «factura del 1º semestre 2017»: así será correcto acorde al XML; no sería legal para una factura del 2º semestre dado que no es descriptivo pero da igual en este caso; y la maquinita de validación no te pondrá pegas.

En el 340 se debe informar de las facturas, pero no hay explícitamente la distinción entre las exentas y las no sujetas (todas va a tipo 0); entonces la AEAT ha decidido que todas las facturas del 1º semestre deben registrarse en la categoría más comuna, sujeta no exenta, que implica poner el detalle de IVA pero no explicitar causas de exención (E1, E2 etc.) Estas son muy probablemente las reglas que han determinado mirando a las facturas viniendo de los 340 que ya tienen, y han extendido lógicamente las reglas a las demás empresas.

¿Por qué partir por meses?

En mis pruebas, he enviando una vez (un poco por error, un poco a ver lo que pasaba) un colección de más de 1.500 facturas de varios años. Me lo ha aceptado sin problema el sistema de pruebas. Fíjate que si el sistema de consultación va por periodo, no así el sistema de suministro (envío) que permite mezclar varios periodos; solo no puedes mezclar varios tipos de factura ni varios tipos de operación (alta, modificación o baja).

Tienes que pensar en varias cosas:

1. máximo 10.000 facturas en un envío
2. el web service tiene un tiempo límite de 30 segundos o algo así; si estas en conexión lenta, puede ser un problema (una factura mide unos 1000 bytes, 10.000 facturas serán 10 MB; y es una operación de subida, ni vale la velocidad de bajada del ADSL que es la en cual habitualmente nos fijamos)
3. a veces el sistema falla, por ejemplo registra pero no te devuelve la contestación «OK»...

La fecha del día, es decir, Now.

En los 340, la AEAT no tiene la información; por tanto han decidido poner la fecha que ellos han recibido el 340, lo que me parece un criterio sensible. Para los demás, el más parecido es la fecha que la AEAT recibe la información correspondiente: de aquí la instrucción.

[quote=Sergio J.;519773]Efectivamente, para que el sistema interprete el xml de respuesta y guarde dicha información en el sistema cómo lo hacéis?/QUOTE]

He probado unas cuantas cosas, y he acabado con el método siguiente:

1. recupero el contenido de la respuesta SOAP/Envelope
2. compruebo que no es Fault, que tiene Body
3. paso el elemento dentro del Body por una transformación XSLT que me deja un elemento Respuesta (si en correcto o parcialmente correcto) con un montón de elementos-hijos RespuestaLinea o RespuestaLineaConError; si la respuesta es Incorrecto, es otro elemento madre con un montón de elementos-hijos RespuestaLineaConError
4. vuelco el XML resultado de la transformación directamente a 4 tablas, donde puedo tranquilamente recuperar las varias partes, actualizar tablas etc.

La ventaja para mí es que así reduzco al mínimo la interfaz con el XML; antes tenía un montón de código que iba por las varias ramas del XML, pero tenía dudas que fuese sencillo de mantener en el futuro.

Si les interese el XSLT, está en http: //pastebin.ca/3850663 (perdonad las molestias del copiar y pegar y editar, soy novato; gracias por adelante al administrador que lo rectificará).

En el mismo post me haces la pregunta y me das los mismos porqués que yo tenía en mente cuando escribí lo que escribí.
¿ Por qué partir el envio del primer trimestre en 6 envios ? EXACTAMENTE por los porqués que tu comentas

No creo que te las van a reclamar. Tal como lo tengo entendido (con asesores), solo hay que informar en el SII de las facturas que realmente están en circulación y por tanto pueden ser contrastadas; los demás, mejor en el cajón que obligar a la contraparte que la declare también... Al revés, si la factura a 0 está en circulación (digamos, unas muestras que han pasado por alguna aduana, o el saldo de una devolución compensada), mejor documentarla en el sistema, ahora sí las admite.

Además las a 0 no generan deducciones de IVA (entonces nada por rascar; nunca olvidar que este sistema es en contra del fraude, para recaudar más) y la penalización en % del importe base tampoco interesa los inspectores.

Otra cosa es que el sistema de numeración puede ser arbitrariamente complejo. Solo dar una mirada a las facturas recibidas de los proveedores más habituales te dará una idea que por allí se puede encontrar de todo y mucho más. Para poner un ejemplo, podrías usar un sistema con 23 letras, la 1ª una T, la 2ª una R, luego una W etc. O usar números romanos, o letras (dígitos) griegas o chinas (aunque difícil en Delphi antes de 2009 :rolleyes:). Detectar un hueco en un sistema así sería pedir un poco mucho a la AEAT.

Si eso es así, entonces las facturas simplificadas (tiques) no deberían ser informadas pues al ser casi todas sin contraparte nunca van a ser contrastadas. Tampoco las emitidas a particulares, que pueden ser muchísimas. No intento contradecirte, pero me parece bastante extraño.

Pero no lo acabo de entender ya que ellos tienen la fecha de presentacion que en definitiva es la fecha de envio. Adjunto un ejemplo de envío de ahora mismo con una factura recibida de junio(primier semestre) tanto de alquiler con sin alquiler. Marco en negrita lo requerido.
<?xml version="1.0" encoding="utf-8"?>
....
<siiLR:RegistroLRFacturasRecibidas>
<sii:PeriodoImpositivo>
<sii:Ejercicio>2017</sii:Ejercicio>
<sii:Periodo>06</sii:Periodo>
</sii:PeriodoImpositivo>
<siiLR:IDFactura>
<sii:IDEmisorFactura>
<sii:NIF>B08367898</sii:NIF>
</sii:IDEmisorFactura>
<sii:NumSerieFacturaEmisor>ALQU52552526</sii:NumSerieFacturaEmisor>
<sii:FechaExpedicionFacturaEmisor>03-06-2017</sii:FechaExpedicionFacturaEmisor>
</siiLR:IDFactura>
<siiLR:FacturaRecibida>
<sii:TipoFactura>F1</sii:TipoFactura>
<sii:FechaOperacion>05-06-2017</sii:FechaOperacion>
<sii:ClaveRegimenEspecialOTrascendencia>12</sii:ClaveRegimenEspecialOTrascendencia>
<sii:ImporteTotal>605.00</sii:ImporteTotal>
<sii:descripcionOperacion>REGISTRO DEL PRIMER SEMESTRE</sii:descripcionOperacion>
<sii:desgloseFactura>
<sii:desgloseIVA>
<sii:detalleIVA>
<sii:TipoImpositivo>21.00</sii:TipoImpositivo>
<sii:BaseImponible>500.00</sii:BaseImponible>
<sii:CuotaSoportada>105.00</sii:CuotaSoportada>
</sii:detalleIVA>
</sii:desgloseIVA>
</sii:desgloseFactura>
<sii:Contraparte>
<sii:NombreRazon>NACIONAL ESTÁNDAR</sii:NombreRazon>
<sii:NIF>B08367898</sii:NIF>
</sii:Contraparte>
<sii:FechaRegContable>04-08-2017</sii:FechaRegContable>
<sii:CuotaDeducible>0</sii:CuotaDeducible>
</siiLR:FacturaRecibida>
</siiLR:RegistroLRFacturasRecibidas>
<siiLR:RegistroLRFacturasRecibidas>
<sii:PeriodoImpositivo>
<sii:Ejercicio>2017</sii:Ejercicio>
<sii:Periodo>06</sii:Periodo>
</sii:PeriodoImpositivo>
<siiLR:IDFactura>
<sii:IDEmisorFactura>
<sii:NIF>B08367898</sii:NIF>
</sii:IDEmisorFactura>
<sii:NumSerieFacturaEmisor>N100-66969</sii:NumSerieFacturaEmisor>
<sii:FechaExpedicionFacturaEmisor>03-06-2017</sii:FechaExpedicionFacturaEmisor>
</siiLR:IDFactura>
<siiLR:FacturaRecibida>
<sii:TipoFactura>F1</sii:TipoFactura>
<sii:FechaOperacion>03-06-2017</sii:FechaOperacion>
<sii:ClaveRegimenEspecialOTrascendencia>14</sii:ClaveRegimenEspecialOTrascendencia>
<sii:ImporteTotal>705.00</sii:ImporteTotal>
<sii:descripcionOperacion>REGISTRO DEL PRIMER SEMESTRE</sii:descripcionOperacion>
<sii:desgloseFactura>
<sii:desgloseIVA>
<sii:detalleIVA>
<sii:TipoImpositivo>21.00</sii:TipoImpositivo>
<sii:BaseImponible>500.00</sii:BaseImponible>
<sii:CuotaSoportada>105.00</sii:CuotaSoportada>
</sii:detalleIVA>
<sii:detalleIVA>
<sii:TipoImpositivo>0.00</sii:TipoImpositivo>
<sii:BaseImponible>100.00</sii:BaseImponible>
<sii:CuotaSoportada>0</sii:CuotaSoportada>
</sii:detalleIVA>
</sii:desgloseIVA>
</sii:desgloseFactura>
<sii:Contraparte>
<sii:NombreRazon>NACIONAL ESTÁNDAR</sii:NombreRazon>
<sii:NIF>B08367898</sii:NIF>
</sii:Contraparte>
<sii:FechaRegContable>04-08-2017</sii:FechaRegContable>
<sii:CuotaDeducible>0</sii:CuotaDeducible>
</siiLR:FacturaRecibida>
</siiLR:RegistroLRFacturasRecibidas>
</siiLR:SuministroLRFacturasRecibidas>
</soapenv:Body>
</soapenv:Envelope>


Me puedes decir si seria correcto así, muchas gracias.

En lo del contraste me refería a las facturas a 0 (o los conjuntos de facturas que suman 0).

Siendo esto así, se hace OBLIGATORIO enviar, de entrada, todas las fras. con importe, y a mi entender, las que tengan importe cero. ¿ En qué me baso ? Sólo sentido común. La principal razón: igual que la ley obliga a realizar fras. cero, lógico es que se envien.

El esquema XML require algo de formato 99-99-9999 en este elemento. Entonces la maquinaría XML (que viene antes de todas los demás cositas inteligentes que hay en la trastienda de la AEAT) te está obligando a poner algo. Lo mismo ocurre para el campo Descripción.

No entiendo me acaba de decir mi asesor que no ponga la fecha de envío como la actual ya que no tiene sentido por tanto dejaré la que tenía en su momento
No utilizare la fecha de envío como la actual el dia en que se envia
<sii:FechaRegContable>04-08-2017</sii:FechaRegContable>
<sii:CuotaDeducible>0</sii:CuotaDeducible>
Sera la fecha en la que se realizo el pago si era de junio...
<sii:FechaRegContable>03-06-2017</sii:FechaRegContable>
<sii:CuotaDeducible>0</sii:CuotaDeducible>

Cualquier novedad os digo...
saludos

¿Posible error en la consulta?
 

Buenas,

Alguien ha tenido el siguiente problema: haciendo la consulta vía webservice o en la propia web de la Agencia Tributaria no salen algunas facturas que por otro lado si las vuleves a enviar com alta te las da como duplicada o si las envías como modificación te da correcto?

No tiene mucha lógica: si no sale en la consulta, no debería darme duplicada al darla de alta ni aceptar como correcto un cambio, ya que se supone que no está en el sistema, no?

Gracias!

Ellos también tienen sus fallos. Hay que ser condescendiente.

JEJEJE Sí, supongo.. a ver si son ellos igual de condescendientes con los fallos de los demás :D

Era, más que nada, saber si a alguien le había pasado lo mismo o no
Y, luego, de cara al IVA también era interesante ver lo que se declaraba por un lado y por otro para mirar de cuadrarlo

A mí no me ha pasado (todavía), pero cualquier cosa es posible :)

Yo tengo un cliente al que le está pasando eso. Ha enviado facturas de forma correcta y al consultarlas desde la web no aparecen, si las vuelve a enviar le dice que está duplicada y si la envías como modificación si que se las traga. Se ha enviado un mail a la aeat pero, por supuesto, tardarán en responder.

Hubo un colega que pensó (en este mismo hilo) que había fallo y luego resultó que pasaba mal los parámetros.

La clave es triple y para fras. recibidas hay dos fechas a tener en cuenta (f. contabilización y f. fra.). Bueno, tb. fecha de operación, pero para esto no la incluyo.

¿ Has comprobado en la sede obteniendo el csv y luego buscando en él por ejemplo, con nº de factura ?

A mi tambien me ha pasado con un cliente al enviar mas de 1000 facturas. Las ha tenido que reenviar por lotes. Todo viene por la respuesta si no lo hacen bien a la vuelta perdemos referencias de facturas a marcar.
Ahora he puesto limitaciones de 20,50,100,200 y 500 registros. Realizando envios por lotes pequeños va bien.
Eligen dependiendo de cada caso por ahora lo dejare asi.
Cualquier cosa os digo...
Saludos

No lo veo claro esto, entonces si modifico un envio del primer semestre que pasa lo reenvio otra con fecha now , no esta claro esto he realizado la pregunta a la aeat ... esperando como es habitual...
Pero segun asesores dicen que no tiene sentido q deberia ser la fecha de devengo ya que ellos tienen en todo momento la fecha y hora de presentacion ademas de la posible modificacion.
Por tanto comparto las indicaciones del asesor.
Ya hace tiempo que hice la consulta a la parte tributaria de la aeat y luego te pasan como una cuestion tecnica .
Si te fijas en las faqs dice cosas distintas dependiendo por donde lo mires.
Queremos hacerlo bien pero ellos lo hacen imposible.
Como dicen en mi pueblo:
Aço es caguera de bou quan plou se remulla...
Por no decir otra cosa
Saludos

Enviarlas como cambios es la única salida fácil a esa situación sin necesidad de consultar a nadie. Las admite siempre (a condición de que los datos y la sintaxis sean los correctos).

yo ya las he enviado como cambios por probar alguna cosa y me da como correcto el envío de la factura pero sigue sin aparecer en la consulta

Si anotaste el CSV de cada factura ya tienes una certificación de que han sido enviadas. Y si además conservas el XML de respuesta, todavía mejor. Si en las consultas no aparecen debería ser un problema de ellos. Yo no me preocuparía demasiado.

Saludos,

Hola, antes de enviar sácate un mensaje del XML que envías y comprueba que el ejercicio y periodo son correctos (aparte del número de factura, fecha, ...). A ver si crees que las estás enviando en un ejercicio/periodo y luego las vas a tener en otro y por eso no las ves en la consulta.

Clarosocuros del tema consulta
 

Primero, gracias a todos por vuestros comentarios acerca de la consulta. Me han sido de gran utilidad.

Dos conclusiones:

1) para algunas facturas recibidas , ciertamente cometí un error y se me colaron con el periodo anterior. MEA CULPA v\||/ Pero bueno, ya está subsanado.

2) pero para emtidias, se me da el caso, que haciendo la consulta por número de factura la encuentra pero en una consulta general del periodo, no. Es decir sale cuando preguntas por ella en concreto pero en el global del mes no aparece. He comprobado (esta vez sí!!!!!!!!!) el periodo impositivo en el resultado individual, y es el correcto. Eso ya sí que me parece un problema de la consulta, por lo menos, a priori.

Utiliza la opción de exportar masivo y busca la factura dentro del csv, a ver si das con algo.

Un saludo.

Alquiler sujeto a retención
 

Alguien tiene un ejemplo de como subir una factura de alquiler con retención?

Ya se me suben pero tengo dudas si está bien subida la factura. Se debe declarar la retención de alguna manera?

Voy a buscar si encuentro donde lo leí pero las retenciones no se informan en el SII.

Efectivamente

2.36. ¿Debe informarse del importe de las retenciones reflejadas en factura a través del SII?
No.

Muchas gracias por tu respuesta.

Entonces si tenemos el ejemplo de una factura de alquiler con estos importes:

Base Imponible 900
Iva (21%) 189
Retencion (19%) 171

Total Factura 918

El total factura no coincide con base+iva, es correcto?

El total factura si coincide con base+iva, pero el total factura no es 918.
El total factura es 1.089

Se van a pagar por la factura 918 + 171 que se van a ingresar en la AEAT.

O sea que tengo que declarar el total factura que tengo que declarar es 1089

Límite de 1000 facturas en la consulta web
 

Así lo hice, pero nada. La cosa es que ya no recordaba que la consulta vía web solo devuelve 1000 registros. En este caso, mi cliente tenía algunas más y no aparecían por eso.

Según me dijo, él ya había probado vía webservice y nada pero .. casualmente esta mañana lo he probado yo y sí que estaban. En fin, que tener en cuenta ese límite de 1000 (vía web) y de 10000 (vía webservice). Para más de 10000, paginación

Gracias por todo y disulpad las molestias (y mi incompetencia)

Consultas facturas
 

Hola,
me están pidiendo desde mi empresa que a efectos de pagar el IVA quieren contrastar lo que hay en la AEAT con nuestra base de Datos. Me encuentro con que si hago la exportación a Excel tengo una limitación de 1000 registros. También existe la posibilidad de hacer un fichero de consultas y que me envíen el XML de respuestas pero esto también tiene una limitación de 10000 registros . ¿ es correcto lo que digo ? ¿ se os ocurre alguna solución ?

Gracias por vuestra ayuda

Hola. Cuando dices paginación ¿ a qué te refieres ? ¿ a hacer otra consulta indicando cual era la última factura de la primera consulta ¿ Si tienes 200.000 facturas, ¿ has de hacer 20 consultas con sus correspondientes xml's ?

Gracias por vuestra ayuda

Yo en particular pienso que, con las opciones expuestas, no hay mucho donde "rascar". Hazte una consulta con la limitación de los 10000 registros (que son bastantes para un mes) y si ves que tu cliente se pasa de ese rango tendrás que inventarte algo como, por ejemplo, ir haciendo consultas por días y sumándolas hasta completar los X días del mes filtrando por "Fecha de presentación".

Saludos

Buenas, sí habría que hacer 20 consultas usando "ClavePaginacion". El XML es el mismo, solo que se incluye esa clave:

2.33. ¿Se podrán consultar los datos enviados?
Las empresas acogidas al SII podrán consultar tanto los datos enviados como los datos remitidos e imputados por los clientes y proveedores que estén acogidos al sistema (Libros registro declarados y contrastados).
Si al realizar una consulta de facturas, se supera el tope de 10.000 facturas en la respuesta, habrá que realizar nuevas consultas con la identificación de la última factura obtenida (informando el bloque “ClavePaginacion” de la petición) para obtener el resto de facturas.

En el PDF de la descripción del servicio web tienes un ejemplo de consulta paginada.

Un saludo.

Buenas, tengo unas dudas con una factura recibida con dos bases con IVA y luego dos importes no sujetos.

Los importes no sujetos los hemos registrado como una base imponible sin IVA y por lo tanto se envían en la clave detalleIVA.
Cando hago una consulta me da parcialmente contrastada y me dice que la base que informan ellos es la suma de las bases que llevan IVA y que en el total de la factura tampoco van incluidos esos importes no sujetos.
¿Es correcto, no se debe informar de esos importes no sujetos ni en las bases ni en el total de la factura?

Muchas gracias.