Colocacion QR
 

No se al final que decidiran, pero yo estaba por poner el qr, al lado del numero de factura y demas, como pone que dejemos un espacio de 6mm, se supone que puede ir en una pare visible, siempre delante de cualquier otro Qr qu epueda incluir la factura.

Hola, la imagen no puedo subirla alguien podria decirme por que?

evitar el spam
 

Necesitas escribir 10 posts, para evitar el spam

Ok, gracias ya me falta menos...;-)

De momento puedes ponerla con "truco" y un moderador lo editará.
Por ejemplo, quita la "h" inicial: ttp://loquesea.com/fotos/tuimagen.png

Otra de las dudas que me surge...

Está claro el tema de ir creando registro con la huella y sucesivamente con la huella anterior. Bien.

Enviar los registros a VERI*FACTU... ese envio ¿debe ser immediato??? ¿Puedo ir creando mis registros, encadenados correctamente y luego enviarlos a VERI*FACTU??? no se, igual voy emitiendo facturas y las puedo enviar al cabo de unas horas, o al dia siguiente...
Y de ser eso posible, que entiendo que debería de ser posible... ¿Puedo enviar a VERI*FACTU el registro de la factura 5, luego el de la 6, luego puedo enviar la 10, la 11... y luego envio la 7, 8 y 9 ??? Con el SII si se puede, y entiendo que con VERI*FACTU debería, también. Además, en mis registros SI hay la correspondiente trazabilidad y encadenamiento de facturas, no habrá algun envio de alguna factura, pero por problemas varios.

No se, se me ocurre el problema de conexión en la factura 7, 8 y 9 por cualquir razón. Luego se envian correctamente la 10 y 11... y pues hago el envio de las pendientes 7, 8 y 9.

Gracias por vuestro tiempo.

Os recomiendo que os reviséis el documento de preguntas y respuestas que publicaron tras uno de los evento realizados.
Muchas de estas cosas se aclaran ahí.
Está en el FTP del club, junto al resto de documentación:
https://terawiki.clubdelphi.com/Otro...-Verifactu.pdf

PREGUNTA:
Me gustaría que aclararáis el tema del tiempo entre la confección y el envio a Verifactu. Lo veo de
vital importancia dado que el SII es bastante más indulgente y permite mucha más maniobra de
correción rapida de errores.

RESPUESTA:
Salvo por incidencia puntual, la remisón debería hacerse tras la emisión de la factura, dentro del margen establecido por
el control de flujo.



En otros sitios lo comenta de pasada...

Si el intento de envío inmediato diera algún problema, será necesario reintentarlo periódicamente y marcar el campo
"Incidencia" en la remisión del registro de facturación.

Deberán enviar las facturas simplificadas de forma inmediata, con el control de flujo que publique la AEAT.

Envio diferido
 

Entonces hay que asumir, que en el control de flujo, hay que tener en cuenta, que si se envia a la primera, nada, sino en el retry , hay que marcar incidencia si o si, ademas de supongo que especificar el motivo de la misma.

Orden de envíos
 

1º Aunque ya se ha hablado de ello, si tienes 1000 registros para enviar debes hacerlo, o si no los tienes en un plazo de 2 horas debe enviar lo que tengas.


2º Por cada serie de facturación las facturas estarán ordenadas por fecha-hora y su código. Entiendo que se subirán ordenadas por fecha-hora. Otra cuestión será que alguna de las que has subido vengan rechazadas y que tengas que volver a subirlas.

Supongo que estarás pensando en la confección de las facturas recapitulativas. No podrás encadenarlas de otra forma que no sea por fecha-hora. Indistintamente de la serie. Y dicha fecha-hora estará acorde a la numeración de las facturas. Eso de hacer facturación general, revisarlas, asociar o desasociar albaranes y validarlas en un orden que no sea el del propio código no coincidiría con la fecha hora.



Saludos.

Encadenamiento.
 

Ojito, que las facturas emitidas por el mismo programa, aunque sean de diferente serie, han de ser encadenadas por momento de creacion, asi me lo contestaron a mi.

Encadenado.
 

Su respuesta fue:

Se pueden anular facturas y modicarlas también
 

Siguendo con esto , he confirmado con Hacienda , que también de puede dejar al ususario modificar facturas , siempre que se registre.



Resumiendo , parece ser que los usuarios pueden modificar y/o anular facturas sin problema , siempre que se registren todos los eventos verifactu, más que nada por las veces que oído por ahí que no se pueden arreglar o modificar facturas.


Saludos

No creo, ¿estás diciendo que puedo modificar 10 veces una misma factura, generando 10 registros verifactu sobre el mismo nº de factura?

No te confundas, los técnicos de Verifactu no te van a evaluar si la modificaciones que estás haciendo sobre una Factura emitida son acordes con el reglamento de facturación vigente o no. Simplemente, están respondiendo a cuestiones referentes exclusivas al reglamento Verifactu, o sea, si subsanas una factura tienes que enviar un registro de subsanación, si la subsanas 10 veces, debes enviar 10 registros de subsanaciones, si la anulas, debes enviar un registro de anulación. Esto es correcto respecto del reglamento técnico de Verifactu, pero puede no ser correcto desde el punto de vista del reglamento de facturación vigente.

Las subsanaciones se realizan sobre campos que no impliquen la generación de una factura rectificativa, error en la fecha de operación, error en el régimen tributario, incoherencias de valores en los tipos de facturas, huella mal calculada, encadenamiento erróneo, etc.

Las Anulaciones deben hacerse sólo sobre operaciones que no se han llevado a cabo y que lo puedas demostrar.

Si los errores son de otro tipo, por ejemplo, tipos de Iva inexistentes, se me olvidó aplicar un descuento al cliente, el precio de un producto es incorrecto, las cantidades facturadas son incorrectas, etc, etc, NO PUEDES EMITIR UNA SUBSANACIÓN del registro, estás obligado a emitir una factura rectificativa y tu factura original permanecerá invariable en el sistema de la Aeat y en tu SIF.
Así que, siento rebajarte las expectativas que tenías ya que tu software debe cumplir con los DOS REGLAMENTOS, el de Verifactu y el de Facturación.

Webinar relacionado con VeriFactu
 

Por si le interesa a alguien; es la grabación de un webinar que emitió Software del Sol hace unos días, con una persona de ONIF (Hacienda)

Link al Vídeo en YouTube

Si si está claro , pero lo que me importa es que el fabricante del software NO es el responsable del método de corrección que escoja el usuario , anular,modificar,rectificativa,etc... , siempre que el software cumpla con los registros verifactu , la responsabilidad de mal uso del procedimiento no recae en el fabricante , otra cosa es que alguna empresa se decida orientar fiscalmente al usuario cobrando servicio , pero en software donde no se cobre ese servicio , la orientación que se la den sus asesores fiscales.

A lo que em refiero es que a al empresa de software queda libre de cualquier conflicto con hacienda siempre que registre todo lo que hace el usuario, parece ser o al menos eso es lo que me han contestado.

Eso es lo que em han contestado, se lo he preguntado explícitamente, una primera alta y x alta de subsanación por cada "arreglo"

Es decir , en el registro verifactu quedarían todos los registros , el de Alta y todos los de subsanación , tantos como veces el usuario ha modificado la factura.

Siento discrepar ...., como responsable del sistema de facturación que vas a certificar, no deberías permitir que una modificación de las bases imponibles y cuotas repercutidas de una factura emitida se pudiera hacer por subsanación ya que este proceso no genera una nueva factura y te verías en la tesitura de tener una factura original emitida e impresa que arroja unos valores de Iva distintos de los valores de Iva que tendrá si la imprimes después de la subsanación. Las opciones que puedes habilitar en tu programa para subsanar o rectificar una factura son muy claras y deberías de dirigir a tu cliente programáticamente a una sola de ellas.
Recuerda que para ellos es muy fácil saber sin la factura debería haber sido rectificada o subsanada, sólo tienen que comparar el importe final y las cuotas repercutidas de ambos registros. Y no sé yo si la responsabilidad del desarrollador se vería afectada ante un caso de este tipo.
Ojo, me pongo como abogado del diablo porque el Reglamento técnico de Verifactu lo dice muy claro..... Sólo se puede emitir un registro de subsanación si no cabe emitir una factura rectificativa.

Esa era la idea , plantear aquí las respuestas de los de verifactu , ya que tienen muchas implicaciones.
Esta claro que cuando al normativa obliga a hacer una rectificativa el usuario debe hacer una rectificativa, pero eso ya es cosa de él , a mí me parece coherente lo que me han contestado , los programadores no deberíamos sustituir a los inspectores de hacienda ni a los asesores fiscales, claro que podemos orientar a un usuario , pero en estos casos de facturación, la responsabilidad final es del usuario.

El tema es que, parece indicar, que lo que nos piden a los programadores es que registremos todo lo que ocurre en verifactu , nos obligan a certificar es que el software cumpla con los requisitos verifactu pero no que seamos la "niñera" de los usuarios.


Igual hay que insistir un poco más , pero la respuesta que me han dado parece clara
Evidentemente que el software debe permitir cumplir el reglamento de facturación y dejar hacer rectificativas , pero también la opción de Anular o modificar registrando todo en verifactu. La cantidad de incidencias y llamadas a soporte que nos ahorraría....

Conste que inicialmente no iba a dejar modificar facturas en el software , pero he estado insistiendo con ellos unos días y al final , releed las preguntas...


Otra cosa es que el reglamento de facturación diga que no se debe permitir modificar nada , entonces no tendría sentido el registro de subsanación verifactu , ya que siempre tendría que ser una rectificativa o una anulación.

Y le veo sentido y facilita el soporte.

Igual se tendría que confirmar con ellos por más sitios, pero yo ya me he guardado las preguntas y respuestas de los mails por si algún día vienen a buscarme. jajaja

Gracias Javierus, 3 puntos importante creo:

1- el OM seguramente salga en septiembre u octubre, no ha dado seguridad y por lo tanto la fecha del 1 de julio del 2025 está en el aire
2- Aunque no es este foro, la factura electrónica está aun más en el aire, no ha sido capaz siquiera de indicar un periodo donde se podría comenzar, habla incluso de que es necesario un complemente político, eso puede hacer que se alargue muchísimo.
3- Los del SII están exento de todo, parecía que en el tema de las autofacturas estarían obligados pero parece que se está modificando para que no sea así.

Otra inquietud, que acabo de trasladar a verifactu...

Como desarrollador de software de facturación, para clientes que no quieran acogerse al VERI*FACTU se maneja la opción de acogerse*al SII.

Bien, ¿como debo protegerme como desarrollador de software con esos clientes que si bien yo voy a implementar que mi SIF solamente trate las facturas con sistema VERI*FACTU, para esos clientes que opten como utilizar mi SIF pero acogidos al SII???
O sea, debo poner una declaración responsable de mi sistema SIF como VERI*FACTU, pero no para todos los usuarios/clientes que utilizen*mi SIF, pues como comento, el que no quiera remitir los datos a VERI*FACTU, ya que estará*remitiendo los datos al SII.

No se, es un poco para "cubrirme" de responsabilidad cuando un cliente me diga, "NO YO NO QUIERO QUE TU SIF ME MANDE LOS DATOS A VERI*FACTU*PORQUE YO ESTOY ACOGIDO AL SII"

Nosotros le activaremos el sii, y si en 4 días no está enviando facturas le empezaremos a mandar errores, y entonces tendrá que enviar a verifactu con incidencias, estamos dándole vueltas.

Si tu software cumple con el reglamento de Verifactu, debes tener tu declaración responsable, independientemente de si se usa como Verifactu o no. Si el cliente sólo lo quiere para remitir al SII, tu software debe trabajar igual y generar los registros de facturación de Verifactu pero no remitirlos a hacienda. Tendrás una carpeta donde se habrán generado todos los registros de facturación y ahí se quedarán. Además, deberás generar las facturas en Xml para remitirlas al SII, si quieres, en el mismo momento de creación, ya que no deberías dar opción de modificar dicha factura una vez emitida, lo prohíbe el reglamento de facturación que está por encima del SII y Verifactu. En resumen, trabajaría como si fuera Verifactu pero sin enviar los registros de facturación y enviando las facturas xml a la aeat

Modificar Facturas
 

He hecho otra confirmación con [email protected] de si se puede dejar modificar facturas al usuario.... y me siguen insistiendo en que si...

Para: <[email protected]>
Fecha: 17/06/2024 17:13
Asunto: RE: Consulta verifactu
________________________________________

Hola

Para confirmar , entonces podemos dejar modificar facturas en el software para ser arregladas siempre que se registre TODO y TODAS las versiones de la factura en el registro verifactu, la responsabilidad de decidir cuando hacer una factura Rectificativa o cuando modificar una factura, recaería sobre el usuario?

Sería correcto?

Gracias y Saludos


De: [email protected]
Enviado el: martes, 18 de junio de 2024 10:30
Asunto: RE: Consulta verifactu

Buenos días:

Efectivamente, así es.

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: [email protected]

Hola compañero, quizá te he entendido mal, o sino creo que estás equivocado. Voy a exponer lo que yo se, a ver si el equivocado soy yo...

Por una parte tenemos la ley antifraude, que está hecha para evitar las dobles contabilidades (lo de facturar al negro de toda la vida). Esto lleva una serie de puntos de , no permitir modificar facturas finalizadas/cerradas/como se diga, no permitir generar cosas en 'B'/negro...etc etc.
La declaración responsable es sobre esta ley, la que tienen que tener tus clientes firmada por ambas partas y visible en el sistema.
Todo esto está , como comentas, por encima de SII y Verifactu.

Por otra parte ,tenemos los SIF (verifactu o no verifactu). Verifactu es envío inmediato, sin firmar los registros , y no verifactu es guardar los registros firmados y enviarlos a la AEAT si te lo solicitan.
El SII pues ya sabemos lo que es, que lleva años en uso, enviar los registros con hasta 4 días de retraso.

Según tengo entendido, si utilizas el SII, NO tienes que hacer nada con Verifactu/No verifactu, pues ya estás utilizando el SII. Ni guardar registros...nada
Pero SI que debes cumplir la ley antifraude (no permitir modificar facturas, contabilidades en 'B'....etc), con su correspondiente ley antifraude

Es correcto lo que digo? O he entendido mal?
gracias

Bajo mi punto de vista es correcto lo que dices. Yo a lo que me refería es que si ya tienes un sistema que es Verifactu, lo puedes usar para un cliente que remita al SII.

Eso que te han contestado te parece correcto bajo tu punto de vista ?. Y si visitas esta página que es de la agencia tributaria donde te explica cuándo es OBLIGATORIO emitir una factura rectificativa, qué pensarías de la respuesta que te han dado en Verifactu ??

https://sede.agenciatributaria.gob.e...ficativas.html

vale, si, ahora que lo he leído con más pausa, ya te entiendo.
Menos mal que es como yo pensaba, solo me faltaba a los clientes que usan el SII, meterles mas cosas :D

Te remito correo que acaban de responderme desde Verifactu para aclarar este tema

MI CONSULTA
Buenos días.
Varios compañeros de desarrollo han realizado consultas a este buzón referidas a la posibilidad de modificar facturas emitidas por errores de facturación, precios erróneos, cuotas mal calculadas, etc, mediante la emisión de un registro de subsanación. Y no sólo eso, han consultado la posibilidad de emitir tantos registros de subsanación como errores se hayan ido produciendo en la factura, y la respuesta vuestra ha sido que Sí, que se puede utilizar este método para corregir facturas. O sea, que teniendo la obligación de emitir una factura rectificativa, cuando está dentro de los supuestos de rectificación citados en la Ley 1619/2012 del 30 noviembre por el que se aprueba Reglamento que regulan las obligaciones de facturación, ustedes permiten la emisión de un registro de subsanación para corregir una factura que entra dentro de los supuestos de rectificación ??

Me gustaría que aclararán este extremo porque en los ámbitos de desarrollo de software donde confluyen muchos equipos de programación que colaboramos para llevar a buen puerto este desarrollo de Verifactu, existe cierta perplejidad al no tener claro cómo debemos actuar.

Gracias por su tiempo.

RESPUESTA

Buenos días:

Cuando sea necesario subsanar la información que contiene un registro de facturación que ha sido enviado y con estado “Aceptado” o “AceptadoConErrores” por la AEAT, siempre y cuando no se trate de una causa que exija la emisión de una factura rectificativa (u otro
mecanismo contemplado en el Reglamento de Facturación) ni se anule la factura, se deberá generar un nuevo registro (“de subsanación”), ya con los datos completos y correctos, que será remitido dentro de un nuevo fichero o mensaje de envío a la AEAT.

En consultas anteriores no se nos mencionaba que fueran casos concretos que exijan la emisión de una factura rectificativa. Aun así le confirmamos que será siempre y cuando no se trate de una causa que exija la emisión de una factura rectificativa. Tal y como indica la documentación y en concreto el documento "Documento de descripción de servicios web (v0.3.1) - Borrador" donde se detallan las altas por subsanación "8.1.2. Subsanación del registro de facturación.". Lamentamos si ha podido producirse algún malentendido al respecto.

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: [email protected]

Ojo con las respuestas de la AEAT no vinculantes.
Por mucho que tengais un email con la respuesta, puede ocurrir que la pregunta no se haya entendido por que no la hayan interpretado correctamente o se haya formulado mal o incompleta.
El caso que si es una respuesta por email no tiene por que ser vinculante, para que sea vinculante tiene que estar en el reglamento o de alguna forma aclarada que sea vinculante.
Ya hemos sufrido incorrecciones en Ticketbai, para la misma pregunta nos hemos encontradocon respuestas diferentes y contradictorias de cada Hacienda Foral.

Para mi la pregunta y respuesta sobre la sustitución me ha generado confusiones. Me cuesta ver si han entendido bien la pregunta por la respuesta tan simple. Normalmente siempre llevan aclaraciones.
Creo que no hay que dar nada por sentado, además pienso, que aunque haya errores en como se debe actuar ante un error de una factura, y haya un camino para casa uno, no pueden ni creo que sean tan estrictos. Esta claro que tiene que haber una normativa, pero si no hay actuacion de mala fé ni van a perder impuestos, no creo que se metan.
Que mas dá que el emisor de la factura en ves de una rectificativa, haga un la vuelva anulación y la vuelva a emitir (si es una operación que hace de vez en cuando), al igual de que si imprimes por segunda vez una factura o la reenvias, ya tiene que ser un DUPLICADO, seg un el reglamento, en serio tiene sentido?

Aclaraciones
 

Con respecto a las sustitutivas que previamente había mencionado :


(h)ttps://sede.agenciatributaria.gob.es/static_files/Sede/Tema/IVA/PRE_303/FAQs_Pre303_22v1_5.pdf

página 11 apdo. 1-12 párrafo 2
creo que está muy claro.


Con respecto a las anuladas :


1- caso de SII. En el SII se permite dar de baja una factura contablemente y en su lugar y con el mismo número registrar otra. Esto es un proceso contable y de registro de iva. Ninguna Ley se puede aplicar a que se deshaga una factura recién hecha por error y se cree una nueva. (recapitulativas, etc.)

2- caso veri*factu. Este caso es distinto al SII puesto que existen documentos registrados y que implican movimientos de existencias y otros documentos tales como número de albarán, número de factura, etc. que no son obviados a la hora de anular una factura. El mismo registro de factura debe ser encadenado y sin posibilidad de modificación ulterior. De ahí mi duda de cómo funcionará de factu el proceso de anulación.
3- caso comunmente establecido. De toda la vida que yo sepa al finalizar todos los procesos sobre un documento factura y ésta ser errónea se expedía una factura negativa para anular la anterior. Creo que todos los que aquí hemos escrito alguna vez lo hemos hecho. Pero tengo serias dudas de que este proceso sea al que se refiere la AEAT con el término "factura anulada". No obstante sería muy defendible ante cualquier tribunal ante la AEAT puesto que nadie obraría de mala fe ni creo que haya ningún precepto jurídico que pueda aplicarse a tal proceder. (al menos eso creo)



Con respecto a las facturas de rectificación o rectificativas :


(h)ttps://sede.agenciatributaria.gob.es/Sede/ayuda/manuales-videos-folletos/manuales-practicos/manual-iva-2021/capitulo-10-obligac-formales-suj-registro/obligaciones-materia-facturacion/facturas-rectificacion.html


Con respecto a modificar una factura ya expedida (en el mismo documento)
(h)ttps://www.boe.es/buscar/pdf/2012/BOE-A-2012-14696-consolidado.pdf


apatado 2



Un vistazo rápido sin ir al memento o a sendos pdf colgados en la AEAT.

Espero que a alguien le sirva de ayuda.


Un saludo.

mas aclaraciones
 

Entiendo que los registros de subsanación podrán ser aquellos cuyo cambio no implique la pérdida del hash o datos que calculen el hash puesto que de ese modo se rompería la cadena.

Ni tampoco podrían ser datos tales como los del receptor de la factura (nombre, dirección, ... ) porque las facturas no se pueden modificar una vez expedidas.
¿ No es así ?


Gracias de antemano por la aclaración si la hubiere.

Me remito a las contestaciones de la AEAT, a falta de publicación en el BOE del reglamento técnico aún pendiente de blablabla...
Pero a falta de tener esa particularidad informada y bajo mi punto de vista, lo más factible sería que un registro de subsanacion debería tener el mismo tratamiento a efectos de encadenamiento que los demás, o sea. Se encadena con el anterior generado sea lo que sea(anulación,alta otra subsanacion)
Con la fecha y hora de generación actual y su propio hash.y como se ha venido comentando solo debería generarse si no está contempladol motivo como rectificativa o anulación. Los datos del cliente debería ser una rectificativa por sustitución .

mas de lo mismo
 

Creo que me he expresado con poca claridad. No me refiero al registro de subsanación en sí mismo sino a los registros originales de facturación. Puedes tener 30 registros con datos distintos de subsanación, Me refiero, ya sabes, a la cabecera, los albaranes, el pie de documento si existe, etc. ¿ va a permitir la AEAT que se modifique una factura a un cliente una vez expedida ? ¿ Va a permitir que cambie los datos del cliente o la fecha de emisión ? ¿ Permitirá que se puedan desasociar albaranes y agrupar otros con otros importes ? ¿ Eliminar el asiento contable y el registro de iva para modificarlo por otro ?



Creo que nos estamos haciendo un lío de algo que todavía no existe. Quedaré a la espera. Esto ya está a punto de caramelo y no tardarán en sacar una versión definitiva.



Gracias igualmente por el esfuerzo.

A los clientes nos.puefes reenviar una factura con los datos de cliente modificado con wl mismo número y serie. Tienes que mandarle la rectificativa con otro nunero y serie.
Lo que me queda duda es si enviar una rectificativa por sustitución tb mal a que haces referencia. Por que se acumulan facturas mal

Pues me da que nos están respondiendo lo mismo , si la norma obliga a hacer una rectificativa, se hace, para cualquier otro caso, se puede modificar la factura siempre que se registren todos los movimientos en registro verifactu , la responsabilidad final del método a escoger es del usuario no del fabricante del software.
Con lo que ninguna empresa de software va a ir a los calabozos de hacienda por dejar modificar facturas en un momento dado , siempre que se registren los cambios.


Todo ello con pinzas , como dice @ermendalenda más adelante, ningún mail es vinculante , pero deberían aclararlo bien o ya estoy oyendo a usuarios diciéndole a sus empresas de Software que el programa de la competencia les deja arreglar facturas.


En mi humilde opinión, tiene sentido , estando todo registrado en el registro verifactu, el Sr.Pepito que cada vez que se acerca al software de facturación le sube la tensión , cuando le piden una factura es capaz de equivocarse tres veces y ni siquiera la ha entregado al cliente , tiene que hacer tres anulaciones o tres rectificativas ? Y al final entregarle tres rectificativas al cliente? no me parece lógico, pero claro la lógica y las normas... ya se sabe.


No sé , pero me parece un tema que deberían aclarar muy bien.

Saludos

no estaría mal
 

No estaría mal, no. Llamar al cliente para ver si le convence la factura y sino hacer como Groucho Marx "estos son mis principios, si no le gustan tengo mas"
Al menos esto permite no tener tanta soledad frente a un grupo de pantallas amorfas y sin empatía.


Un saludo.

Vamos a tener otra incompatibilidad.
Facturae no contempla las subsanaciones. Y en caso de querer arreglar algo hay que hacer un nuevo registro con otra factura.
Así que viendo como está el patio, perdonad pero en muchas cosas voy a hacer lo que me de la gana.
En facturae modificaré solo el identificador de la factura y no la factura y serie para las incompatibilidades con verifactu

Paso de las rectificativas por sustitución para arreglar un cliente, hago anulación y vuelvo a generar. En las facturas sustitutivas/canje igual,anulo la factura sustitutiva y nueva apuntando al mis o tiquet. A ver si se lo comen o da error
No voy a meterme más líos al software
Es de locos.

Es más,no voy a hacer más cambios.
En la web de la aeat para el sii tienen herramientas web para arreglar cosas
Voy a esperar a ver si ponen algo similiar.
Lo de la subsanacion me parece un grandisima putada como lo quieren solucionar

Idem
 

Pues lo mismo digo. Llego ya un tiempo acariciando la idea de anular la factura emitida por error simplemente con lo que he hecho toda la vida. Hacer una factura negativa. El cliente tendrá un extracto con las dos pero es explicable y lo entenderá.



Y sí, cuando la factura electrónica entre en vigor no entenderá de subsanaciones.

^\||/