^\||/^\||/^\||/

¿Navarra?
 

Hola, ¿Navarra queda en un limbo con esto de verifactu?

Si no recuerdo mal, en el último webinar del exj3fe de inspección de hacienda, Javier Hurtado, posiblemente se acoja a Verifactu al igual que pasó con el SII.

Gracias por el aporte [seccion31].
Subo el proyecto al FTP del club, junto a un fichero TXT con una pequeña descripción y el link a github (original).
https://terawiki.clubdelphi.com/Otro...go-proyectos_/

Actualizo también el segundo mensaje del hilo, donde iremos recopilando códigos útiles.

Gracias compañero.

Revisión 0.4 QR
 

Hay una revisión de la imagen del QR.
No esperes nada bueno.
Sigue quedándose donde dijeron y además presionan un poco más con el mensaje de inmediatez.
Si un cliente pasa el QR, antes decían que aún no se ha subido y que lo intenten un poco más tarde, ahora lo han cambiado por aún no lo han subido por que han podido tener una incidencia puntual.
Una vueltecita más de tuerca jeje.

Obligaciones fiscales desarrollador
 

Off-Topic

Alguien puede aclararme una duda. Si se produce un crimen con una hacha comprada en la ferretería del pueblo, se presupone que el criminal es el que usa el hacha para realizar el crimen, NADIE IMPUTA AL VENDEDOR DE LA FERRETERIA. Entonces porque en el tema que nos ocupa VERI*FACTU, y después de leer y analizar TODO lo que se ha publicado en este foro, planteo la pregunta :

Porque se esta derivando TODA LA RESPONSABILIDAD FISCAL Y CONTABLE sobre el desarrollador de la aplicación VERI*FACTU, cuando legalmente el/los responsables son los GESTORES Y LOS ASESORES FISCALES que son los que tienen que indicar al cliente/empresa la forma de actuar a partir de la publicacion de las normas VERI*FACTU y son lo que tienen que controlar los distintos conceptos y artículos contables/fiscales.

Bajo mi opinión, el desarrollador ha de realizar la aplicación VRI*FACTU cumpliendo la normativa de facturación ya publicada, a partir de este momento termina toda su responsabilidad.

Quien puede evitar que el usuario realice las facturas con sino negativo en lugar de realizar una rectificativa. Por el mismo motivo, se puede emitir una factura sin IVA porque se trate como si fuera Canarias o intracomunitaria siendo esto realizado por error.

Disculpad si me he pasado con mis apreciaciones y si alguien quiere anotar su opinión , la guardare con aprecio.

Un saludo

Estoy de acuerdo. Muchos casos en los que el cliente actúe "equivocadamente" con mala fe o erróneamente, puede pasar que nos salpique. Estoy seguro que el desarrollo reglamentario final nos va a dar trabajo en cuanto a requerimientos que el cliente no sabe solucionar y tendremos que ir creando herramientas para que el cliente sea lo más autosuficiente posible, pero nos van a dar por el ojete seguro.
Posiblemente te pase lo mismo que nos pasa a todos, cosas que antes no controlaban vamos a tener quenpegarnos muchas horas sin dormir.

Pero en ese caso estamos hablando de COMPETENCIA DESLEAL con respecto a contables y asesores fiscales, salvo que el desarrollador este capacitado y titulado en ambas categoría CONTABLE y ASESOR, y este caso creo que es muy difícil encontrarlo.

Se que, por ejemplo, en Portugal, muchas empresas de desarrollo han tenido que chapar. No te interesa meterte en temas legales para perder el tiempo a no ser que tengas un primo ministro o un padre juez del supremo
Te dirán que si tienes que contratar una auditoría para fiscalizar correctamente todo es nuestro problema.

desarrollador
 

Ya han estado comentado que los asesores y contables deberían empezar a reorientar sus negocios. La hacienda va a ser quien te haga los impuestos y a no ser que sea una empresa que tenga la capacidad de hacer algo de ingeniería fiscal para pagar menos los asesores los tiene crudo.

Yo creo que es así.
Al final lo que pretendes es que tu programa no facilite el "trabajar mal". Si tu programa es correcto y el cliente "trabaja mal" (por no decir en B) la responsabilidad es suya. Lo único que tu programa no debería facilitárselo.

No soy letrado, pero esto me recuerda una cuestión básica de derecho civil: las obligaciones y las responsabilidades.
Un asesor tiene obligación de medíos; no tiene responsabilidades sobre las consecuencias de sus consejos.
El desarrollador tiene obligación de resultado, y eso incluye la responsabilidad de producto que distribuye (realmente, la obligación de corregir sus errores y defectos).

No creo que los desarrolladores tienen responsabilidad fiscal o contable (y seguro que tiene todas las responsabilidades). Tienen la responsabilidad de suministrar un producto que cumple la normativa, nada más.[/quote]

Por lo que voy leyendo en este foro y muchas conversaciones sobre el tema de la ley 1007/2023... parece ser que CADA VEZ TENGO MÁS CLARO el desarrollo de mi aplicación de facturación SOLO para clientes que esten adscritos forzosamente o voluntariamente al SII.

Imaginad el tema como está, que legalmente, tenemos más a perder los desarrolladores de software de facturación (de momento, porqué vendran más y más cambios en otras aplicaciones), que los propios usuarios de nuestras aplicaciones.
En este caso que os comento, imaginad un cliente empresa/autónomo que voluntariamente decide (o le convecemos) entrar en el SII, esta nueva ley 1007/2023 se la pasa por el forro, con perdón de la expresión, y nosotros como desarrolladores del SIF, también. Solamente, entiendo yo, haciendo una comprovación del egistro y poniendo una nota al arrancar el SIF que el aplicativo SOLO es utilizable para aquellos que esten adscritos al SII, tema resuelto. Ni QRs, ni trazabilidad, ni custódia... nada de nada!!!
Asi, pues, el aplicativo SIF puede seguir siendo, incluso... Excel!!!

¿Que compromete el SII a nuestros clientes???
Haber de enviar a hacienda los registros de facturación (facturas emitida i recibidas), con un sistema mas "laxo", diría yo.
Tienen cuatro días para poder hacer el envío. El sistema és muy ágil por lo que he ido utilizando en un par de clientes que lo está utilizando... y nos permite "rectificar" registros mientras no lo hayamos enviado al SII

Como yo tengo ya funcionando mi parte de envios a hacienda del SII...
No se... me lo estoy planteando y és la salida con menos responsabilidades que me puedo echar sobre mi persona. Hacienda no perdona ni un resbalón, cualquier pequeño fallo en nuestro aplicativo se puede convertir en una arma muy peligrosa para nuestros intereses.
VERI*FACTU ni NO VERI*FACTU... SII

Hola,

En nuestras aplicaciones ponemos controles de todo tipo y con ellos esperamos que el cliente no pueda realizar determinadas acciones.
El problema es que el cliente suele darle muchas vueltas a las cosas y siempre encuentra resquicios que no habíamos previsto para obtener lo que quiere hacer.
La picaresca del cliente es infinita y no es raro que encuentre métodos (inimaginables por nosotros) para saltarse nuestros controles.

Saludos

Hola,

No creo que tarden mucho en hacer obligatorio Veri*Factu aunque se esté en el SII.
De hecho, por ejemplo, en las Haciendas Forales del País Vasco es obligatorio TicketBAI aunque se esté en el SII.

Y con la obligación de factura electrónica (que al final unificarán con Veri*Factu) Hacienda irá controlando cada vez más hasta tener la contabilidad de todos los negocios en sus manos, en tiempo real.

Tiempo al tiempo.

Saludos

formas de veri*factu
 

Estoy de acuerdo en que el responsable debería ser el que hace uso de la herramienta y no quien la crea, sino todas las armas blancas estarían prohibidas. Es una vigilancia social encubierta.

Es un paso mas para que ejerzan de "guardianes" los que crean el soft.
No obstante no debe confundir "veri*factu" con "NO veri*factu".
En el caso veri*factu el responsable no es el que crea el soft sino el que lo usa. La responsabilidad del fabricante está en último caso en que el sistema pueda enviar a la AEAT la información generada por la empresa que usa el software. No hay responsabilidad del fabricante del software, salvo su buen funcionamiento como no debería ser de otra manera.
Otra cuestión muy muy distinta es el caso de acogerse al modelo NO veri*factu. Aparte de generar, vigilar, certificar información tal como los registros y los eventos (y un montón de cosas mas) el responsable de los datos es el fabricante del soft. Esto es una opción, el cliente que quiera ese soft ha de pagarlo y no puede tener acceso a los datos o al menos a modificarlos. Significa el uso si o si de la nube. Un buen seguro, muchas copias y un buen equipo jurista. Eso se soluciona con la billetera. Supongo que hay pocas excepciones que necesiten esta opción.

Pero si se acoge al modelo solo veri*factu no debería preocuparse mucho. Impida desde el programa que el cliente no pueda cambiar nada y poco mas. Si el cliente accede por fuera del programa y cambia algo es responsabilidad del cliente puesto que el soft no permite tales cambios y ya ha registrado en la AEAT en su momento las facturas.

Un saludo.

factura rectificativa por sustitucion
 

Buenas.


Me podriais aclarar si este planteamiento es correcto, por favor?. Vuelvo a estar muy liado


tenemos una factura de 1000 Euros + 210 Euros de IVA. Por un error en la misma, necesitamos hacer una rectificación, siendo el importe correcto 800 Euros + 168 de IVA:

• Emitimos primero una factura ordinaria en negativo de -1000 Euros (y -210), es decir, la factura original pero en negativo.
• Emitimos una nueva factura ordinaria de 800 (+168) .
• En este caso no se rellenan los datos “base rectificada”, “cuota rectificada” y las estadisticas a nivel de articulos e inventario cuadrarian, etc.

gracias por vuestra ayuda.

En principio esta bien. Pero no estas emitiendo una factura simplificada por sustitución.Para hacer una factura rectificativa por sustitución tienes que emitir una sola factura.

- Emitimos una nueva factura Rectificativa por sustitución de 800 (+168) . y en la base rectificada pones 1000 y en la cuota rectificada 210. Esto rectifica toda la factura inicial.
dejándola a 0.

Un saludo. Yo creo que esto sería lo mas correcto.

Hola,

Lee la respuesta 48 de https://www.batuz.eus/es/preguntas-f...0&actualPage=2
Ahí explican las 2 posibles operativas en el caso de factura rectificativa por sustitución:
- Si se informa la base y cuota de la factura original, sólo tienes que emitir esa factura rectificativa por sustitución.
- Si no se informa de la base y cuota de la factura original, debes emitir una factura normal pero de importes negativos y una factura rectificativa con los nuevos importes.

Si se emite una factura rectificativa por diferencias sólo tienes que emitir una factura rectificativa de las diferencias entre la original y lo que debería haber figurado.

Nota: Eso es así en TicketBAI. Y supongo que en Verifactu será igual.

Saludos

En el SII, es una de las tres operativas aceptadas para las rectificativas (punto 2.8 opción 2).
Solo apuntar que en el SII, base y cuota rectificadas se rellenan con 0 en este caso.

Lo más correcto es lo que te ha puesto Sistel, y para tu operativa y que te cuadren las estadísticas la opción 2.
En verifactu , casi seguro, será igual que en ticketbai, ya que esa operativa se basa en el reglamento de facturación , pero dado que es un tema un poco complejo, tampoco me extrañaría que dieran otra solución, así que de momento dejalo un poco abierto. Yo de momento lo he dejado como has puesto, una rectificativa normal y vuelvo a emitir y ya veremos, por que aunque no es lo correcto quien se va a meter tanto en eso, otra cosa es que pase de un periodo de facturación a otro mientras se arregla, entonces si hay que andarse con un poco más de ojo.

¿ Quizá quiso decir "período de liquidación de IVA" ?

Correcto, gracias.

Es más, la decisión final tiene que tenerla el usuario, y alguien cree que lo va a hacer siempre bien si les das varias opciones de arreglo de factura, lo único que puede pasar es que la líen más y más problemas para nosotros. Yo optó por la opción fácil y una sola opción que es la primera que ha puesto en la pregunta.

Muchas gracias a todos,

Cuestion perfectamente aclarada.

Generación de la firma
 

Buenos días a todos. Estoy intentando generar la firma para enviar las facturas a la hacienda, pero me dice que firma no válida, y no encuentro en la web de hacienda documentación sobre la generación de la firma, ni donde ubicarla dentro de la estructura del xml que se envía. He estado intentando leer desde el principio todos los mensajes que hay en este foro pero son demasiadas páginas con demasiados mensajes y no lo logro encontrar. Sólo he visto una DLL pero no me vale, ya que nuestros sistemas trabajan en Linux.

Alguno tiene y me podría compartir la estructura de firma y como generarla?

Muchas gracias

En los primeros mensajes del hilo tienes un pequeño resumen y acceso a la documentación y a los códigos disponibles.

En el FTP, hay una carpeta con toda la documentación hasta ahora. La oficial y la no-oficial:
https://terawiki.clubdelphi.com/Otro...LeyAntifraude/

En concreto, este documento, hace referencia a temas de HASH del registrro de facturación (a ver si es lo que necesitas):

https://terawiki.clubdelphi.com/Otro...os20240527.pdf

Aquí hay algunos códigos:
https://terawiki.clubdelphi.com/Otro...go-proyectos_/

Gracias.
Esa carpeta la vi, sí. Y el tema del hash también, pero no es el hash lo que necesito, eso en teoría ya la genero.
El tema es que cuando subo el SOAP con varias facturas y tal me responden que no está firmado, y cuando uso el certificado de persona para firmar el XML me dice que la firma no es válida.

Hola, ya está funcionando el servicio de pruebas de recepcion de verifactu?

Por cierto, estas firmando la peticion soap o cada xml?
Si hay que firmar algo es el soap, cada xml no es necesario, aunque si los firmas no te debe dar el error por ese motivo, en la recepción no comprueban los xmla firmados a no ser que sea un sistema No Verifactu.

Sí, estoy firmando el SOAP que engloba los diversos XML.
mmm con la pregunta de si ya está funcionando el entorno de pruebas..... me hace plantearme que igual estoy probando con otro servidor que no sea Verifactu.

Le he mandado un correo a Hacienda, y estoy esperando que me respondan.

Muchas gracias

entorno de pruebas
 

Que yo sepa aun no esta operativa. Se abrira cuando terminen de modificar, cosa que debe de ocurrir cuando salga la orden ministerial.

Hasta donde se , lo que esta activo es el servicio para enviar l<as facturas electronicas, tipo facturae, como aqui: https://face.gob.es/es/facturas/vali...lizar-facturas pero por soap.
y para que acepte la firma, habia que dar de alta el certificado y la empresa, no?
Por lo menos eso es lo que he leido en el foro, en varios hilos.

Hola, estanos teniendo un aumento muy significativo de pedir facturas sustitutivas de los tiquets pero a través de email.
A alguien más le pasa?

Buenos días, y hola a toda la comunidad.



Yo tengo una duda con los encadenamientos. Cuando tienes por ejemplo distintas tiendas y que se van sincronizando con una central donde se reciben las facturas simplificadas y las generadas por cada TPV, y además tienes la "central" que recibe todos los datos de las tiendas y además puede hacer otros tipos de facturas con distintas series claro. Tienen que ir encadenadas por serie entiendo no? Porque sinó no veo como saber cual es la última factura para hacer el encadenamiento. He visto la documentación y videos y habla de distinto software que no seria el caso.


Saludos y muchas gracies

Hola,

Si es el mismo software de la central el que procesa, secuencialmente, todas las facturas que se van recibiendo de todas las tiendas, puedes encadenarlas seguidas independientemente de que sean de distintas series.
(Por supuesto, siempre que que el NIF del emisor sea el mismo).
Así es como lo hacemos nosotros en TicketBAI y parece que será igual en Verifactu.

Si no puedes procesar secuencialmente las facturas (independientemente de su serie), tendrás que encadenar por serie (aunque el software sea el mismo).

Saludos

Hola,

Tal vez sea por el tema de la próxima declaración de IVA correspondiente al trimestre pasado.
Que los destinatarios pidan esas facturas sustitutivas de simplificadas por email, por teléfono o en persona no debería ser un cambio respecto a trimestres anteriores.

Saludos

Hola, segun la contestacion que me dieron, tiene que ser FIFO, osea las tienes que encadenar por tiempo independientemente de la serie, si el programa que hace la comunicacion a hacienda es el de la central, las tiene que ir encadenando segun las reciba independientemente de la serie, incluso te diria que en sus pensamientos, han de ser los tpv, los que gestionen el encadenamiento y envio de las mismas.
Ojo siempre que sean del mismo NIF, como dice @Sistel.

Cada siflleva un encadenamiento de todas las fact7rss independientemente de la serie. Donde el SIF es interpretable según tu forma de trabajar.
En aplicaciones de escritorio, un sif es cada máquina aunque se conecten varios usuarios.en aplicaciones en la nube cambia y serían para cada cif un encadenamiento, aunque no se si existe la posibilidad de que cada máquina que se conecte a la nube tenga también su encadenamiento.
Las series no tienen nada que ver.
Solo cifs y SIF.