|
Cita:
"Esto entrará en vigor de inmediato una vez que el Decreto se publique en el BOE, lo que puede suceder en un par de meses y, previsiblemente, antes de junio." |
Tambien dice :
Cita:
|
Información importante
Buenas tardes tengo algo información importante.
Parece ser keperi factum va a ser una estructura reducida del fichero XML de la factura electrónica. Supongo que al fichero XML factura electrónica le recortarán campos que no hacen falta para hacienfa e incluirán el blockchain/hash/huella... |
Parece que no se ha corregido lo que he puesto o han borrado el equivocado.
Verifactu va a ser una versión reducida de Facturae, o sea los desarrolladores que apliquemos verifactu tendrémos que generar un fichero como el de facturae pero con menos contenido, ya que la AEAT no necesita tanta información Por otro lado, pienso yo y a raíz de la propuesta del reglamento, habrá que calcular el hash y presumiblemente habrá que añadir algún campo oara hacer el enlace entre facturas(blockchain) etc. Esta decisión de unificación de criterios y formatos viene a raíz de la obligación de que, en breve, habrá que tener preparado los programas para emitir Facturae y por tanto han querido simplificar las nuevas obligaciones, cuyos reglamentos serán aprobados a partir del verano, por un lado el del ministerio de Hacienda (con Verifactu) y por otro el de Economía (Con factura electrónica). Así que los que no estemos al día con Facturae vamos a tener que darle unas vueltas a dichos FORMATOS. Los que quieran empezar con factura electrónica echad un vistazo a envíos tipo FACE, y FACEB2B, He visto alguna web de un señor que ha puesto a disposición de todosy en php el tema de generar factura, firmarlo ETC puedes copiar y tienes permiso de distribución indicando fuente. Ya os iré informando La fuente es fiable Saludos |
BOE Antifraude es Inminente
Buenos días, cada vez está más cerca, todos dicen que en Julio va a salir el BOE de la ley antifraude, ya nos sacarán de "muchas dudas".
Insisto en la factura electrónica, y esto no es "tan facil" como Ticketbai. Corregidme por favor si me equivoco, factura electrónica hay 2 principales, que son FACE y FACEB2B, FACE: para emitir facturas a organismos públicos, y se envia a un servidor de la AEAT. FACEB2B: para facturas entre empresas pero igualmente hay que usar servicios de la AEAT. Despues tenemos, que para los que ya tienen Ticketbai va a ser lo de menos en desarrollo: VERIFACTU: Parece que va a ser parte del XML que generamos de factura electrónica. Vamos a tener que desarrollar 2 proyectos de una vez, FacturaElectrónica-Verifactu. Para la factura electrónica (que las empresas que facturen mas de 8 millones de euros, solo tienen 1 año desde el proximo BOE y el resto tendran 3 añitos), vamos a tener que hacer una comunicación bidireccional ya que habrá que dar de alta, consultar, enlazar con nuestros softwares o ERP... Nos vamos a tener que ayudar muchisimo y COMPARTIR los desarrollo, he estado haciendo un sondeo de precios para integrar APIS de terceros para Facturae y es una locura de precios además de que ya te obliga a pagar una cuota, carisimo.. |
Cita:
|
Hola, aporto este vídeo muy aclaratorio y sobre todo tranquilizador
Participan José Borja Tomé (director de Informática de la AEAT y Javier Hurtado Puerta (director del Departamento de Inspección Financiera y Tributaria de la AEAT) ( pongo la url con espacios porque no tengo permiso para colgar enlaces ) https://www.dailymotion.com/video/x89tixv |
Gracias por el enlace.
Creo que es el mismo que se comentó en este otro mensaje. De todas formas lo añado al hilo original (mientras no haya más información). |
Hola a todos.
Esto se sigue moviendo. En la página de desarrolladores de la aeat https://www.agenciatributaria.es/AEA...olladores.html |
Esto es lo más importante que veo.
Cita:
Cita:
Esto tiene pinta de ser una presentación que han hecho con las empresas que ya estan metidas en el proyecto. :rolleyes: |
Cita:
Al menos han quitado lo del manual y parece que lo de los eventos se suaviza, que eran dos puntos peliagudos. |
Cita:
|
definición SIF
Otra cosa que, yo pienso y, debería acabar suavizandose, por que si no esto va a ser interminable. Cualquier dato que se extraiga de la facturación va a ser parte del sistema Verifactu, con lo cual es facil adivinar que se va a tener que incluir en el prooyecto/alta Verifactu, guardar todas las versiones, añadirle la parte de eventos que se defina, etc.
Ejemplos: generar estadisticas, cuadros de mandos, generar contabilidad, etc., da igual que lo haga un tercero, que lo hagas en la nube, lo hagas en otro equipo, será parte del sistema. Cita:
|
Encadenamiento
Ojo con los encadenamiento, hay una ligera diferencia con Ticketbai. Aquí las anulaciones van a ir encadenadas también. Cosa que veo rara, eso me hace suponer que el encadenamiento se hará solo sobre el hash o habrá que crear un número común y correlativo de la generación de los xmls. Ya que una anulación no lleva, supuestamente, número de serie ni de documento.
|
Ya tenemos nombre para los programas de facturacion: SIF, otro módulo más que vender a nuestros clientes: ERP, CRM, SGA, SII, BI.... El caso es que yo me había planteado sacar el módulo de facturación del ERP, tal y como tengo el módulo de contabilidad, de manera que el ERP se puede conectar con nuestra contabilidad, o con otras como A3, Director, Contaplus.... Y nuestra contabilidad puede importar a su vez de diferentes ERP's. La idea que plantemos es hacer los mismo para el SIF, es decir, que el ERP lleve la logística, fabricación/elaboración, pedidos a proveedores, compras, gastos, gestión de comerciales, pedidos a clientes, entregas de mercancía (albaranes)... y cuando llegue el momento de facturar, que se conecte a un SIF (posiblemente en la nube, no lo hemos decidido hasta tener los detalles técnicos) y que nuestro ERP no tenga que estar sujeto a las reglas que imponga Hacienda, que sí serán contempladas y cumplidas por nuestro SIF, el cual quisiéramos incluso que se pueda conectar con otros ERP's.
Me cabe la duda si la parte financiera (control de cobros y efectos recibidos, remesas, transferencias, domiciliaciones, devoluciones...) podrán estar en el ERP o tendrán que estar en el SIF, ya que el ERP no va a tener almacenada información de facturación (para que no lo consideren al ERP como un SIF). ¿Qué pegas le veis a este sistema? Lo que no quisiera es tener que certificar el ERP o estar sujeto a lo que pida Hacienda que deba cumplir... por ejemplo, lo de los manuales (aunque parece que no lo van a exigir). |
Cita:
Por otro lado hay que tener en cuenta que Verifactu no se va a plantar aquí, con lo cual ve pensando, que cuando esto ya esté funcionando, twn por seguro que incluiran las compras y por tanto los SIF también van a ser los sisyemas que manejen los registros de compras, además del FacturaE Faceb2b que también est por llegar, pendiente de aprobación, y por tanto en el SIF tendrás que tener la parte de ventas contemplado. En resumen, es complicado separarlo, por que al final va a haber puntos comunes en que tengas las compras y las ventas, por ejemplo cualquier listado de cuadro de mandos. |
Registro de eventoa
Parece que ya he entendido lo del registro de eventos.
La intención es que los XMLs sirvan de registro de eventos. Pero hay que esperar al reglamento para que la Orden Ministerial lo confirme. |
Me han confirmado de la AEAT, que este enlace es donde van a colgar la documentación verifactu, por si algún moderador lo puede poner en el índice igual q hacéis con tbai
https://www.agenciatributaria.es/AEA...ERI_FACTU.html |
Cita:
Gracias. Ya está añadido al primer mensaje. |
|
Cita:
|
Cita:
|
Ya está llegando también lo que os comenté, como vais de
Factura electronica faceb2b? https://www.abc.es/economia/abci-gob...ticia_amp.html |
Hola,
Alguna nueva noticia, sobre retrasos, en prensa: https://www.eleconomista.es/legal/no...ributaria.html Saludos |
Hacienda retrasa a julio de 2024 las nuevas facturas de pymes y autónomos en conexión contínua con los servidores de la Agencia Tributaria.
|
Sí, viene en las novedades que pusieron hace unos días.
|
Cita:
Por ejemplo, podríamos pensar en algún día del futuro, los SIC («sistemas informáticos de compras») registren los códigos de todas las compras (españolas con IVA deducible), y pasen la información a Hacienda. Así lo que ahora es una simple recomendación con un efecto marginal sobre la detección de fraudes, pasaría a tener un efecto mucho más generalizado. Pasar la información podría hacerse en directo (portal web), bajo petición como lo propuesto en este reglamento, o a través del SII. Pero de inmediato se ve un pequeño problema: si todas las facturas emitidas por los SIF españoles sometidos al reglamento van a llevar un QR (creo), no será el caso de las facturas emitidas por los que están en el SII... que representan en general la mayoría de las compras en cualquier empresa. De hecho, parece ser que han eliminado completamente del proyecto de reglamento el «código identificado», por tanto parece imposible recuperar de forma útil una referencia univoca a la factura del proveedor. Y por haber intentado varias veces cuadrar mis ficheros del SII con los ficheros de mis proveedores, te puedo asegurar que cuadrar una cosa con la otra no es un juego informáticamente sencillo. Al escribir esto, veo una cosa que no había percibido hasta ahora: una función que deberían hacer los SIF comercializados será generar los 347 del lado facturación con facilidad, para poder intercambiar la información con los clientes. Los 347 me parecen una herramienta de lucha contra el fraude, y no he leído por ninguna parte que se piensa quitarlos (fuera del SII); entonces Hacienda podría usarlos para detectar eficientemente casos «problemáticos»; y acto seguido insistir en qué estén bien documentados, ya que para un SIF debería ser sencillo generarlo. O si se prefiere, usar errores en la declaración 347 como un indicio de qué «hay que investigar más». |
Cita:
Saludos |
Cita:
Dicho esto, había entendido que las facturas de las empresas bajo SII no están sometidas al reglamento y por tanto no llevan QR. Si te leo bien, todas las facturas deberán llevar QR. Evidentemente, esto cambia las cosas. |
Cita:
Respecto a los obligados al SII, parece que no van a estar obligados a todo esto, pero a mi me extraña y yo esperaría al reglamento, ya que es raro que vayas a un comercio y tenga el qr en la factura y otros no, lo cual, pposiblemente, provocaría continuas denuncias/sospechas... A no ser que tenga una leyenda tipo "TICKET/FACTURA NO SUJETO AL REGLAMENTO VeriFactu", no sé, de momento solo se pueden hacer conjeturas con el punto espinoso SII. Respecto al reglamento actual, no creo que esté disponible, solo lo tiene/n la/s empresa/s desarrolladora/s y quizás algún consorcio de empresas relacionadas con ellas. Yo no lo tengo ni lo veo por ningún lado. Todo lo que hablamos aquí está basado en las propuesta de reglamento de febrero, el powerpoint y la experiencia con Ticketbai que tiene mucho en común con lo que hemos visto en dicha propuesta. Saludos |
Cita:
:o:o:o:o |
Cita:
También me parece raro que el QR conforme a TicketBAI fuese distinto del QR que aparezca en las facturas «SIF» de los demás comunidades. :confused: Sin pensar en los SIF del reglamento que deben cumplir TicketBAI, y por tanto las facturas llevarían dos QR :eek: |
Cita:
En España hay 5 Haciendas diferentes: Álava, Bizkaia, Gipuzkoa, Navarra y Agencia Tributaria. Si una empresa o autónomo tiene su domicilio fiscal en una de las provincias del País Vasco (Álava, Bizkaia o Gipuzkoa) sus obligaciones fiscales son con la Hacienda Foral de esa provincia. Entiendo que si hace todas sus declaraciones fiscales (o su SII, si le corresponde) a su Hacienda Foral (y no hace declaraciones a la Agencia Tributaria estatal), sólo tendrá que cumplir con TicketBAI (o con Batuz si es de Bizkaia), que es la normativa que le impone su Hacienda Foral. Saludos |
Hola a todos.
Han publicado cositas nuevas, parece que no quieren que nos vallamos de vacaciones. https://www.agenciatributaria.es/AEA...ERI_FACTU.html |
Cita:
|
Cita:
Pero con solo los totales en euros, se queda en una cosa manejable. |
Cita:
|
He echado un primer vistazo y parece mucho más fácil que ticketbai, pero veo alguna incongruencia en el encadenamiento con las anulaciones que tendrán que aclarar, al ser una versión borrador supongo que habrá muchos cambios.
En cuanto al encadenamiento de la anulaciones se encadenan con la factura anterior y el hash anterior, pero teniendo en cuenta que una anulación no genera un muevo número de factura se crea un problema al generar 2 anulaciones seguidas, ya que hay una incertidumbre sobre si se repite la secuencia de encadenamiento. Esto es raro tendrán que corregirlo, y me temo que nos obliguen a crear un número especial de serie para las anulaciones, aunque eso no está en la normativa de facturación. Por otra parte leo que los registros erróneo se podrán corregir y volver a enviar, pero ahí veo que falta mucho por explicar, ya que las facturas rechazadas rompen encadenamiento y al volverla a enviar ya no se envian en la misma secuencia, ni de encadenamiento, ni de número de factura, no se si hay que enviarlo de otra f9rma a otro servicio o seguir por el encadenamiento que va en ese momento... O han explicado poco o le falta mucho curro básico o como es lógico ambas cosas. |
Ahora solo falta empezar a subir ejemplos con los curros que vayais/mos haciendo
|
La franja horaria es GMT +2. Ahora son las 11:46:14. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi