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.