FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#2321
|
|||
|
|||
Cita:
|
#2322
|
|||
|
|||
Cita:
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... |
#2323
|
|||
|
|||
Cita:
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. |
#2324
|
||||
|
||||
Cita:
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. Cita:
|
#2325
|
|||
|
|||
Cita:
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:
|
#2326
|
|||
|
|||
Cita:
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. |
#2327
|
|||
|
|||
[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:
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á). |
#2328
|
|||
|
|||
Cita:
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 |
#2329
|
|||
|
|||
Cita:
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 ). Detectar un hueco en un sistema así sería pedir un poco mucho a la AEAT. |
#2330
|
|||
|
|||
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.
|
#2331
|
|||
|
|||
Cita:
<?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. |
#2332
|
|||
|
|||
Cita:
|
#2333
|
|||
|
|||
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.
Última edición por xamminf fecha: 04-08-2017 a las 11:53:29. |
#2334
|
|||
|
|||
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.
|
#2335
|
|||
|
|||
Cita:
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 |
#2336
|
|||
|
|||
¿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! |
#2337
|
|||
|
|||
Cita:
|
#2338
|
|||
|
|||
JEJEJE Sí, supongo.. a ver si son ellos igual de condescendientes con los fallos de los demás
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 |
#2339
|
|||
|
|||
Cita:
|
#2340
|
||||
|
||||
Cita:
__________________
Be water my friend. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco | keys | Internet | 4246 | Hace 23 Horas 11:17:09 |
AEAT envio de datos vía Webservice problemas con WSDL | CelsoO | Internet | 11 | 09-10-2019 20:03:41 |
webService Soap de la Administración Digital Española notific@ | apicito | Internet | 3 | 31-01-2017 11:25:28 |
Error en Webservice funcion envio de sms | webmasterplc | Delphi para la web | 5 | 25-07-2013 20:10:29 |
Problemas con envío de XML a un WebService | davidvamo | Internet | 1 | 13-02-2007 15:49:20 |
|