|
A mi me contestaron lo mismo y me parece bien hasta cierto punto, ¿Que ocurre las facturas de empresas a consumidores finales? estas no tendrán que ser en el formato de factura electrónica.
|
Ya falta poco
Cita:
La verdad es que lo que mas se mira en un ticket es el final (el importe). Ahí tiene toda la razón, seguro que al técnico tributario también le ocurre lo mismo. La cabecera se mira al final del todo para acordarse de la familia de los dueños del supermercado. Por lo demás, creo que las cosas están meridianamente claras en lo que van sacando. Faltan detalles. Cuando salga definitivamente la norma final estarán también los detalles clarificados. Esperaré a que saquen la susodicha norma final y luego terminaré los detalles del soft. Un gran foro ! Animo a todos y paciencia ! |
Es que no tiene ningún sentido que el QR vaya al principio del ticket/Factura, haciendo que todo el mundo tenga que rediseñar los formatos....
Con lo fácil que sería copiar lo que ya hace bien ticketbai en ese sentido, e ir todos a una En fin, a darnos mas trabajo .. y espérate que no publiquen la OM el 1 de agosto, pillando a medio sector de vacaciones y por lo tanto con un mes menos para implementar todo... :D |
hola
¿alguien puede decirme que son los eventos que aparecen detallados en la hoja excel del verifactu? comentaros que estoy creando un programa de ejemplo, para añadir/borrar facturas en verifactu, importandolas desde excel, algo simple, pero que sirva como ejemplo, cuando lo tenga lo posteo para corregirlo un poco entre los que se animen. Bien completo seria una buena plataforma. Lo dicho, ¿ alguien sabe que son los eventos ? Saludos ! |
Cita:
|
Cita:
Si no me equivoco los eventos son registros que tienes que ir generando cuando pasen determinadas cosas que exactamente no sé cuales son. Por ejemplo cuando haya un problema al hacer el envío se tendrá que generar un evento, no sé si hay que generarlos cada vez que un usuario entre y/o salga de la aplicación, etc. Sobre el tema del programa de ejemplo es una idea estupenda y que creo todos tenemos en mente así que aportaremos lo que buenamente sepamos. Saludos. |
Cita:
En este modo, además de deber firmar los registros de facturación en el momento de su generación (en lugar de enviarles a la web Veri*factu), el SIF debe guardar un segundo registro independiente de «eventos» con fecha y hora, también encadenados y firmados, que relatan las acciones importantes que realice el SIF, incluyendo arranques y paradas, dar el estado del SIF cada hora, avisar de exportación a petición, o si se restaura una copia de seguridad. Además, debe fiscalizar el control de los registros (proceso llamado de «detección de anomalías»). Más todos los eventos que puede añadir el desarrollador. |
Cita:
Un sistema que funciona en modo NO Veri*factu (el único modo que requiere de los eventos) debe facilitar los registros (artículo 14.2) pero no he visto que esté obligatorio hacerlo con un envío: solo hay que facilitar los registros en formato electrónico a los inspectores, que se supone se presencian (artículo 14.1). Ahora bien, si tienes un sistema que funciona en modo Veri*factu, que tiene registros de eventos firmados encadenados etc. (no está prohibido aunque no es necesario), y si te apetece usarlo para registrar problemas de envío, me parece perfecto hacerlo. |
Veri*factu vs NOVeri*factu
Cita:
Como Usted ya será conocedor a estas alturas después de leer la documentación de la AEAT existen dos modalidades distintas dentro de la ley antifraude : 1- Veri*factu : Registro de facturas y anulación encadenado con hash (no borrado) para impedir cambios fundamentales en las facturas. Utilizar un webservice con la AEAT para declarar dicho registro en un período máximo de 2 horas desde el momento de producirse el registro. Entre otras cosas. 2- NO Veri*factu : No se utiliza el webservice de la AEAT. Por el contrario existen numerosos requerimientos mas que en el caso de Veri*factu. Uno de los requerimientos es llevar un sistema de eventos encadenado y exportable para la AEAT. Modelos solo Veri*factu. El soft solo permite veri*factu con lo que quedan excluidas todas las demás opciones. Modelo Dual. El sistema admite Veri*factu y NO verifactu. En dicho modelo se exigen las mismas condiciones para ambos que en NO Verifactu. Supongo que esto le indica cuando debe usar los eventos y registrarlos. En el caso de un importador para generar altas y anulaciones a partir de excell...no comprendo bien a qué se refiere. Recuerde que en el registro de facturas deben estar clasificados los registros por fechahora de generación de factura física y que no puede transcurrir mas de 2 horas antes de que se registre en la AEAT. Y también por número de documento ordenado, sin importar la serie que sea. En cuanto al borrado de facturas creo que está errado. NO SE PUEDE ELIMINAR NADA DEL REGISTRO. Todo el registro de facturas está encadenado y no sería posible la eliminación de ningún registro. Un saludo. |
mas aclaraciones
Cita:
No termino por comprender el por que de la incorporación de facturas al registro mediante excell. Me he imaginado que tiene un soft que no permite veri*factu y que quiere complementarlo haciendo exportaciones en excell e importaciones a un registro que luego pretende subir a la AEAT. Si esto es así le aconsejo que lo consulte bien pero creo que no le servirá. El que debe cumplir normas no es un registro de facturas, ES EL SOFTWARE MISMO. Un saludo nuevamente. |
Pues a ver como te comes esto:
Solicitan factura B2G por FACE. Posteriormente piden corrección de conceptos por que nos les gusta como lo han pedido y quieren cambiarlo. Me dicen que la corrija a su gusto pero que no la mande como rectificada por que no las admiten. DIOOSS DAME PACIENCIA. |
Lo de ls excell que comentáis es factible, es una entrada de datos como otra cualquiera. El programa que lea esas Excel y genere los xmls es que tiene q7e cumplir verifactu
La entrada de datos es algo independien6e, 0uede ser json, excell, xml, una fuente de datos odbc...eso no influye en nada. |
Buenas.
Estoy intentando aclararme un poco cómo hacer lo de la firma del registro pero no lo veo. El compañero Jesusggc puso amablemente un ejemplo en vb pero no acabo de ver la luz. ¿Hay que generar un fichero XML en disco para firmarlo? ¿No se puede hacer en memoria? ¿Alguien le ha dado ya solución a esto en Delphi? Gracias y un saludo. Edito: Estoy viendo que hace algunas semanas el colega Delphier puso a disposición una dll para esto precisamente. Haré pruebas con ello pero si alguien le ha dado alguna otra solución se admiten ideas. |
Cita:
Sin embargo, suponiendo que la factura se imprime desde Excel (cosa que podía tener sentido hace años), ahora al dicho Excel se lo tiene que añadir el QR... :rolleyes: Y por supuesto, debe ir en la cabecera, impreso como primero de la fila &c. :p |
buenos dias !
he propuesto un software de ejemplo, que lea registros desde una excel, tipo asi: OPERACIÓN NUMSERIEFACTURA FECHA FACTURA DESCRIPCION OPERACIÓN CLIENTE CLIENTE NIF TIPONIF CODPAIS BASE IMP TOTAL IVA1 REQ1 ALTA F240001 21/01/2024 VENTA MERCADERIAS CLIENTE1 NIFCLI1 02 ES 1000 1121 21 1000 ALTA F240002 22/01/2024 VENTA MERCADERIAS CLIENTE2 NIFCLI2 02 ES 2000 2420 21 2000 Para abstraer del programa de ejemplo de la interacción con un modelo de base de datos propia, nada mas. solo a modo de ejemplo. Estoy con el alta (en su modo mas simple) y el envio de los registros con el certificado digital instalado, via HTTPRIO. Luego hare la baja. Si alguien quiere colaborar que me escriba en privado y se lo enviare antes de publicarlo (calculo que durante la semana que viene) y asi hacerlo mas completo y con menos errores. Me he quedado algo obsoleto, ... pero no hace falta firmar nada ¿no? en el SII no firmo nada, y los envio a la AEAT (HTTPRIO) y listo. Saludos ! |
Cita:
Yo estoy trabajando en algo parecido pero con ciertas diferencias. Uno de mis problemas (tengo muchos :D) es que tengo un montón de programas personalizados y que todos entrarán en VeriFactu por lo que tendré que adaptarlos. Lo que se me ha ocurrido es preparar un programa genérico para el envío a VeriFactu que esté atento a una carpeta determinada y en esa carpeta ir poniendo ficheros .csv, uno por cada factura, con los datos de la misma y que se encargue de ir enviándolos según van "cayendo" en la carpeta. De esta manera en los distintos programas lo "único" que tendré que hacer es generar esos ficheros con una estructura determinada. Y digo lo "único" porque hay bastantes modificaciones que hacer para manejar datos que hasta ahora no hago como el tipo de documento de identificación, tipo de operación, etc. Se admiten ideas. Saludos. |
Esa idea tambien la barajo yo. En principio lo ideal seria que ese programa, tomara la lista de facturas con un mínimo tratamiento, y las convierta a verifactu.
Por otro lado, me gustaria haber visto ya, ese programa que dicen los de la AEAT que van a crear para los que facturen "poco", quizas haya una importacion de ese tipo. (Si quieres colaborar en este programa ejemplo me escribes un privado). Como digo limitado a alta y anulacion, entre el lunes o martes lo podre enviar a quien me lo pida. Pero, si fueramos varios podriamos hacerlo crecer en condiciones. Saludos ! Cita:
|
Desde este humilde hilo quiero agradecer al gobierno su abnegada labor de seguir joribiando a las empresas de software con sus ocurrencias
Te pegas el susto cuando oyes que a partir de julio quitan el IVA del aceite y lo pasan al 0% y dices bueno, todo controlado...que cambien el tipo de iva, que regeneren los documentos si los tenía grabados con una fecha anterior...lo de siempre, sin problema. Y llegamos a ayer cuando nos sorprenden con que se van a inventar UN IVA NUEVO DEL 2% para el ACEITE DESDE OCTUBRE HASTA FINAL DE AÑO que pasará al 4%. Lo que mayormente viene a decir que ahora una factura puedes tener 6 tipos de iva diferentes!!! Pues nada genial todo!! Como total las empresas de España imprimen facturas con un rollo de ticket sin fin..qué mas problema hay en que sean 6 o 16 bases imponibles diferentes !!! Y dices bueno...lo cambio en el formato de facturas de Verifactu que tenemos que preparar todos...meeccc error...quién garantiza que vamos a tener la orden ministerial antes de septiembre y aun con eso que tengas tiempo a preparar todo tu software para Verifactu o que no quieres los clientes no quieran ser los primeros en entrar por el aro... Pues nada, agradecido por darnos un trabajo que no va a valer más que para 3 meses Lo mejor de todo es que harás todos los cambios que tu software necesita y luego en septiembre volverán a pensar otra cosa. Me cawen to :mad: Yo recuerdo una época en la que el 80% del trabajo de mi empresa no era para cumplir los requisitos de la administración (y lo que nos queda) |
Pues tienes razón, esperemos que amplíen los plazos y lo atrasen todo lo máximo porque esta gentuza no tienen en cuenta que tenemos que dejar de trabajar para nuestros clientes para trabajar para ellos y gratis, al menos que no den 9 meses a los desarrolladores y al menos que den un año. Porque van a ir saliendo dudas y casos que ellos ni los saben ni se les ha ocurrido plantear (funcionariado vago), lo único que deberían haber hecho es consultar con desarrolladores de empresas pequeñas porque los desarrolladores de empresas grandes ni fu ni fa.
No dudar en escribir siempre aquí con todas estas cosas a ver si entre todos les hacemos entrar en razón de todo lo que significa este cambio y van aceptando algunas cosas que son de cajón: [email protected] Por ejemplo a mis clientes cuando le dices que NO pueden modificar una factura se les va la cabeza y realmente tienen razón, ¿porqué no puedo modificar una factura si la acabo de guardar y he visto un error? eso sí una vez sincronizada con la AEAT o impresa o enviada por mail se bloquea automaticamente, pero mientras ¿porque no puedo editarla? ¿estoy defraudando por eso? , al final tendrán más facturas rectificativas que ordinarias. |
Completamente de acuerdo con todo, pero especialmente con esto:
"Yo recuerdo una época en la que el 80% del trabajo de mi empresa no era para cumplir los requisitos de la administración (y lo que nos queda)" Llevo meses pensando lo mismo. Como si no tuviéramos otros proyectos, trabajo, etc. que hacer en la empresa... |
Cita:
Es una puñetada porque los clientes no saben valorar lo que "cuesta" todo esto solo ven que tu ritmo habitual de evolución del software ha cambiado significativamente |
Buenos días,
soy programador en una muy pequeña empresa, y me veo en el trance :( de tener que actualizar varias aplicaciones de facturación desarrolladas hace años en vb6, a medida para pequeños comercios locales.... Buscando y buscando he dado con este foro, que aunque no sea de vb6, me parece magnífico, así que he seguido todo el hilo y me está aclarando muchos conceptos, pero como novato en relaciones con la AEAT, soy todo dudas y no se muy bien por donde meterle mano. Por ejemplo, se supone que tienes que mandarle un XML a hacienda de forma inmediata (máximo 2 horas) de cada factura simplificada o no que hagas, eso puede ser igual 3, que 30, o que 300 XML en un día, pero por otra parte leo que hay que agruparlos en bloques de al menos 1000, pero ¿cómo leches voy a agruparlos si sólo genero 30 en un día? en los negocios pequeñitos no hay tantísimo movimiento, pero por otra parte, si todos, desde toda España, los mandamos uno a uno ¿no va a fliparlo el servidor de la AEAT?. Aunque he estado viendo cosas para usar servicios web SOAP desde vb6, estoy dando mis primeros pasos para intentar comunicarme con el entorno de pruebas del SII para luego pasar a VERIFACTU, es mi primera experiencia con este tema, así que, en fin, os agradeceré cualquier indicación, idea, guía, ejemplo, manual, lo que sea, porque lo que he encontrado es todo con HTTP y supongo que ahora deberá ser con HTTPS. Muchísimas GRACIAS de antemano, e intentaré aportar lo que pueda. |
Hola Logan, tienes que enviar cada x tiempo o x facturas lo que pase antes, esto te lo comunicará la aeat. En el SII tienes plataformas de pruebas para probar ya la conexión con la AEAT, de todas formas se supone que cuando aprueben el OM o quizás días más tarde activaran la plataforma de pruebas de verifactu y habrá 9 meses para llevarlo a cabo. Ahí ya podrás hacer pruebas en verifactu y ya creo que podremos ir resolviendo dudas y es cuando este foro se volverá estresante :-)
Bienvenido y has llegado al mejor foro que hay |
Firmar verifactu ?
Cita:
Que yo sepa no hay que firmar veri*factu. Solo has de usar un certificado digital para enviar datos a la AEAT. Lo que sí hay que firmar es el xml donde esté instalado un soft dual o No veri*factu. Al igual que los eventos. |
Cita:
|
Lo que importa es el soft
Cita:
Por cierto, a colación de comentarios anteriores, ¿ importa el soft o solo importa la rutina de validación con la AEAT ? Considero importante recordar que el propio soft debe identificar cuántas empresas están acogidas a veri*factu de forma visible. También debe haber un "contrato" con el cliente que determine a qué modelo de veri*factu se acoge. Al mismo tiempo se debe identificar datos tales como el productor (nombre,nif,número de instalación, etc.) y que eso se debe identificar en la comunicación con la AEAT. Al mismo tiempo se debe recordar que el soft debe ser capaz de identificar fallos de coherencia entre lo que se envia a la AEAT y lo que realmente tiene archivado. Todo esto en el modelo solo verifactu. En el modelo NO verifacto ni te cuento. Mi pregunta sería...¿cómo puedo dar validez a mis datos de gestión si no coinciden con mis datos del registro enviado a la AEAT ? ¿ Mi soft se puede validar a partir de lo que hay enviado a la AEAT ? Desde un punto de vista procedimental considero que la forma de alimentar el registro de envíos a la AEAT sería igualmente de eficaz se use el protocolo de comunicación que se use. Pero desde un punto de vista legal, ¿ Son mis datos consistentes ? ¿ Puedo garantizar que lo que se envía se ha registrado en mi gestión ? ¿ Puedo GARANTIZAR que mi sistema de gestión mantiene datos coherentes con lo enviado ? Por ello creo que alimentar los envíos con CSV/XLSX podría generar inconsistencias. Modelo que permitiría al cliente final hacer "apaños" jugando con la credibilidad del productor de soft. Me reitero, sería objeto de una consulta legal mas allá de lo que se pudiera representar en este foro, pero creo que sería contraproducente para el programador. Atte, Un saludo. |
Contestación de AEAT :
El reglamento aprobado por el Real Decreto 1007/2023, de 5 de diciembre, no hace sino especificar ciertos requisitos que deben cumplir los sistemas informáticos de facturación para evitar o reducir y detectar la posible realización de fraude en los procesos de facturación mediante su uso, de acuerdo con lo que impone el artículo 29.2.j) de la Ley 58/2003, de 17 de diciembre, General Tributaria, introducido por la Ley 11/2021, de 9 de julio, de medidas de prevención y lucha contra el fraude fiscal. En este sentido, deben seguir permitiendo realizar las operaciones de facturación legalmente admitidas, del tipo que sean, pero realizando el correspondiente registro "seguro" de las mismas. En cualquier caso, todo esto es independiente de la debida diligencia con la que han de proceder los empresarios y profesionales a la hora de realizar adecuadamente los procesos de facturación, siguiendo -entre otras- las normas establecidas en el reglamento por el que se regulan las obligaciones de facturación, aprobado por el Real Decreto 1619/2012, de 30 de noviembre. Atentamente, Atención al Usuario Departamento de Informática Tributaria Email: [email protected] |
Cita:
Estamos como los agricultores, más papeles para sacar un tomate del huerto que papeles para... |
Cita:
Gaacias |
Esta es la pregunta :
Buenos días, Querría hacerles llegar el malestar de los clientes de nuestro software al no poder editar una factura una vez guardada. Si todo va a funcionar con rectificativas, y teniendo en cuenta que también se comenten errores incluso en las rectificativas va a ser un auténtico lio y así nos lo plantean. ¿porqué no dejan modificar facturas y una vez esté correcta entonces que la puedas sincronizar? , es decir, que te de la opción a no sincronizar en tiempo real y eso si, una vez sincronizada está claro que quedará totalmente bloqueada para que no se pueda manipular. La cantidad de casos a la hora de facturar llega a ser una barbaridad y cada vez es más complejo facturar de la forma que ustedes plantean con el nuevo reglamento, ruego lo tengan en cuenta porque la carga que estamos sufriendo los desarrolladores a la hora de atender e incluso de formar a todos los usuarios es insoportable, hay semanas completas que no podemos avanzar y ni siquiera trabajar, solo nos dedicamos a tranquilizar a los usuarios que algunos incluso nos amenazan con dejar nuestro software porque así no pueden trabajar. Gracias. |
Prefactura
Cita:
¿ Por qué no prueba a utilizar un tipo documento intermedio denominado PREFACTURA ? En las recapitulativas es indispensable. Cuando tenga la prefactura lista entonces cierre el documento y genere factura y todos los encadenamientos. La prefactura no se podrá usar para el cliente, es un documento temporal. ¿ No seria mas provechoso ? Saludos. |
Cita:
|
Cita:
|
Una voz en el desierto
Cita:
Debe ser verano, a veces siento que el sudor del camino no acompasa al agua fresca que espera en el riachuelo. Vuelvo a reiterar lo que he explicado y doy fe de que funciona en primera persona : Un documento de prefactura es un documento temporal, con su fecha temporal, con su contador temporal. Si se elimina o se sacan albaranes no importa, es un espacio de trabajo. No se le puede expedir a ningún cliente porque no es una factura. Es un espacio de trabajo. Cuando se valide se convertirá en una factura con todas las circunstancias. Tendrá su fecha, su fecha-hora de generación de registro, su encadenamiento, etc.etc. Es sólo una sugerencia y doy fe de que funciona perfectamente. Cada cual haga como mejor le convenga. Un saludo a todos. |
Una prefactura puede ser una opcion si la ejecutamos de 1 en 1. Pero la mayoria de mis clientes meten albaranes y facturan al cabo de 15 días o 30 días. En este caso es inviable la prefactura.
|
Cita:
Hasta que no le das a ese botoncito, la factura no está 'completa' digamos. El usuario final (en teoría) revisa que esté todo bien en la factura (precios, cliente, descuentos, productos....) y si está todo correcto, le dan al botoncito y damos la factura por finalizada |
Varios de nuestros clientes de TicketBai sirven la mercancía con un documento de albarán, si hay alguna corrección se hace sin problema y cuando está todo correcto "cierran" esos albaranes, se facturan, se suben a Ticket Bai y se manda a los clientes por mail
|
siguiendo con prefactura
Cita:
Justamente es ahí donde se necesita una prefactura o cualquier otro nominativo que signifique lo mismo. Es en las facturas recapitulativas. ¿ Por qué ? Porque las facturas deben ir ordenadas consecutivamente tanto por fecha-hora de creación así como por fecha de documento y por número de factura. Si se hace una tirada de facturación no podrá contabilizar una antes que otra. No podrá sacar un albarán para meterlo en otra o incorporar un albarán que se haya quedado fuera de la factura. Por si alguien lo ignora, un albarán una vez listado o enviado por email no se puede modificar. Si el cliente le pide su factura no podrá contabilizarla antes que una que tenga el número anterior. Eso no ocurre en la factura de contado. De otro modos la fecha-hora del registro (algo tan importante para la aeat y su encadenamiento) quedaría desfasada. En realidad ni siquiera serviría cambiarle el tipo de documento así como se contabilice porque el registro tiene una fecha-hora de creación. De ahí que en mi caso haya optado por tener un documento temporal de trabajo. Cuando se cierra se crea un documento de factura con su código,fecha,serie, fecha-hora correspondiente y ordenado eliminando el documento temporal. No sigo mas con este tema. Solo fue una sugerencia por si alguien se ha perdido en este paso y puedo ayudarle en algo. Un saludo. |
Respecto de crear un programa intermedio que reciba facturas integradas en ficheros, Excel, Csv, etc provenientes de terminales de facturación para, posteriormente, generar la estructura en Xml y enviar a Verifactu, les recuerdo que, el Real decreto 1007/2023 por el que se rige el reglamento que establece los requisitos a adoptar por los sistemas de facturación dice en su Artículo 9:
Artículo 9. Generación del registro de facturación de alta. Los sistemas informáticos de facturación que sean utilizados por los obligados tributarios a que se refiere el artículo 3 de este Reglamento, deberán generar automáticamente un registro de facturación de alta de forma simultánea o inmediatamente anterior a la expedición de cada factura |
Cita:
Una cosa, mi programa , genera visual mente la factura y la previsualiza en pantalla, personalmente no considero la factura como definitiva hasta que le doy a la opcion de guardar, asi si veo que me he confundido , vuelvo atras, modifico lo que sea y vuelvo a previsualizar, o si es de una venta y el cliente decide que no quiere el articulo, la elimino. Este forma de proceder, considerais que seria en contra de dicho articulo? |
| La franja horaria es GMT +2. Ahora son las 21:22:59. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi