Anular Factura
 

Hola Neftali - Keys, primero muchas gracias. No lo tengo claro. He leído en una Web (no sé si se puede poner el link en el foro)

" ------------------------------------------------------------------------------------------------------------------------------------------
Cuándo puedo anular una factura
Los motivos por los que una empresa puede realizar una cancelación de invoice o e factura, pueden ser, entre otros:

• No se ha recibido el producto, aunque se haya pagado.
• No se ha llevado a cabo un servicio, aunque se haya abonado
• Directamente cuando un producto ha sido devuelto

Solo es factible anular una factura si ha sido recién enviada y no está incluida en un trimestre contable ya cerrado. Es decir: no tienen el IVA liquidado. En este caso, cancelamos la factura y emitimos una nota de crédito.

En el caso de que el invoice, o la factura electrónica, tenga un error (faltan datos, se han calculado mal los impuestos) y el trimestre contable/administrativo ya esté cerrado y liquidado, se debe emitir una factura rectificativa, de la que hablaremos en otro artículo.

Una de las preguntas comunes es: ¿puedo anular una factura aunque ya haya pasado el periodo impositivo en el que se registró? La AEAT dice que sí.

¿Qué es una nota de crédito?

La nota de crédito es un documento legal en el cual queda constancia del reembolso, al incluir todos los importes finales en negativo de la factura a cancelar. De esta manera, a efectos prácticos, es como si se anulara la otra factura. Y Hacienda tiene constancia de que ese dinero ya no está en la caja de la empresa.

La nota de crédito se realiza como una factura normal, pero que se identifique claramente que es una nota de crédito. El cliente debe recibir la nota junto a copia de la factura original, y que se vea la anulación del importe económico.

Volviendo a Hacienda, debes mantener las facturas antiguas, aunque estén “anuladas” con una nota de crédito, por si acaso en algún momento tuvieras una inspección de la Agencia Tributaria. Así podrás demostrar que la nota de crédito se realizó en base a una factura real.

Cómo anular una factura.
Teniendo en cuenta todo lo anterior, para anular una factura, es necesario:

Hacer la factura nueva, donde quede claro que es una “nota de crédito”.
Asignarle un número correlativo al de la serie de facturas que ya se han emitido. No debe ser correlativo al de la factura que estás anulando, si no que si en el período contable corriente llevas 22 invoice o facturas, la nota sería la 23.
Incluir el número de referencia de la factura anulada.
Y no te olvides de incluir las cantidades que se han anulado, en negativo.

Conclusión
Los errores en las facturas pueden ocurrir, como humanos que somos, por diferentes motivos. Y es importante saber gestionar esas facturas erróneas, por ejemplo para hacer anulaciones.

------------------------------------------------------------------------------------------------------------------------------------------ "
Por esto, si anulo una factura, TicketBAI me dice que tengo que crear un XML de Anulación con los dato indicados en el esquema del XML de Anulación. Pero arriba indica que se debería crear, también, una nota de crédito (factura negativa en la misma serie) e enviársela al cliente para que tenga constancia de la anulación de la factura. ¿A está factura negativa le debo crear su XML de Alta? Ya que si no creo el XML de Alta me va a quedar un número de factura que no le he enviado a Diputación.

Y para las Facturas rectificativas se crea un XML de Alta indicando la factura que se rectifica. Pero se crea otra factura en una serie diferente con los datos rectificados.


Igual tienes razón y me estoy liando yo solo.

¿Cómo debería realizarlo?

Saludos y muchas gracias,
Joselu:confused::confused:

Envío de Ficheros con ChilKat
 

Lo reviso, y sobre todo muchas gracias por todo.
Joselu

Hola chic@s, tengo algunas dudas y me gustaría saber cómo afrontáis vosotros estas situaciones.

Pj. qué valores han de ir al registrar la primera factura en ticketbai en el encadenamiento?

- NumFacturaAnterior ?
- FechaExpedicionFacturaAnterior ?
- SignatureValueFirmaFacturaAnterior ?

Si no ponemos nada devuelve error y no registra la factura. En la primera si van los datos de la anterior factura y ésta no está registrada en ticketbai, entonces nos dará un warning? es eso aceptable o hay que hacerlo de otra forma?

--------

Y por otro lado vosotros cómo lo organizáis si tenéis un cuadro como este:

Factura Nº 003 vamos a registrar esta factura
Factura Nº 002 ya generada, NO registrada en ticketbai (pj vuestro servidor caído o similar)
Factura Nº 001 ya generada, registrada en ticketbai

al registrar la factura Nº 003, nos dará error en el encadenamiento al referirse a la 002 por tanto cómo lo resolvéis? si al registrar la 003 tomamos la 001 como la anterior entonces rompemos el orden en el que se generaron las facturas en nuestro sistema o eso da igual? siempre que una vez resuelto el problema de la factura 002, al registrarla cogeríamos la última factura aquella que esté registrada arriba aunque por orden de fechas no se cumple el encadenamiento? ¿Cómo hacéis vosotros en caso de que una factura no se ha registrado por alguna razón y queréis tramitar las demás? cómo actuáis?

Un saludo, y muchas gracias de antelación lo que compartan su experiencia!

En el caso de la primera factura no debes rellenar la información de la factura anterior. El bloque:
No debe estar presente (los TAGs tampoco).

Debería devolverte una respuesta con un "Warning/aviso", pero te la aceptan igualmente. Algo como esto.





Esto que te he explicado es para la primera. Por ejemplo la primera de una serie.

Las facturas que subas a ticketBAI siempre deben encadenarse con la última subida, así que en tu caso la 3 tiene que ir encadenada con la 1. Cualquier otra cosa te dará error.
Otro problema es que tal vez luego tengas que justificar qué ha pasado con la NUMFACT=2.

Nosotros, lo que hacemos es asignar el NUMDOC al subir la factura, por lo tanto siempre son correlativas.


En nuestro caso no queda registrada como factura, sino como documento temporal.
Cuando se "finaliza" ese documento se le asigna fecha, numero y se sube a TBAI.

¡¡¡Muchísimas gracias por las respuestas!!!
^\||/^\||/^\||/^\||/

Hola Bilbur.

Yo también trabajo en PHP y me interesa controlar todo el proceso (generación, firma y envío) dependiendo lo menos posible de librerías ajenas.
Cualquier información sobre el tema, me interesa.

Gracias

Hasta hoy tengo completo TBAI GIP


Genero xml
Firmo xml
Envio xml firmado a Gipuzkoa (curl php)

Todo OK

Ahora estoy con TBAI BIZ

Genero y firmo igual que TBAI GIP es lógico
No consigo envia a BIZ con curl php (llevo días sin avanzar nada)


Si te interesa, vamos por partes y probando lo que finciona

Hola Bilbur

¿Obtienes alguna respuesta al php-curl que lanzas?

Cuando, en su día, desarrollé el módulo de SII, tuve problemas con el php-curl.
Sin embargo me iba bien si lo lanzaba mediante shell_exec("curl --connect-timeout ...")
Así que lo dejé de esa manera.

Saludos

Yo os diría que realizarais pruebas con Postman, por ejemplo, para probar las diferentes partes del proceso.
Por ejemplo, se pueden configurar los parámetros de cabecera, el certificado de envío y enviar uno de los ficheros de ejemplo de BATUZ; Con eso ya podréis obtener una respuesta como esta:



Que ya son códigos de error y respuesta de BATUZ.
A partir de ahí se trata de ir centrándose en otros aspectos.

Modificar el fichero de ejemplo, por uno de los vuestros, y de ahí en adelante.

En el caso del ejemplo el problema del certificado (Interesado no identificado), porque la gente de BATUZ no admite certificados de prueba como si se hare en TicketBAI (**NOTA**, por si alguien lo está haciendo así que lo tenga en cuenta...)

Para la parte del JSON, también podéis utilizar uno de ejemplo que se puede descargar de aquí y modificarlo lévemente.

Hola Neftali.

Magnífica idea probar los envíos con Postman o Imsomnia.

¡Muchas gracias!

Esto es para chinarse.
Al final consigo envío y respuesta TBAI BIZ


Correcciones previas:


Error en el json pues yo ponía ejerc 2022 y debo poner 2021
Error en el json que si el nif no coincide con el del obligado tributario
etc


Error de certificado, resulta que el de izenpe (que me dieron para pruebas NO vale)
Error de certificado, resulta que el de FNMT de representante tampoco vale
He cambiado todo a mi certificado personal de FNMT y ya funciona


Recibo respuesta, todos los regitros erróneos
Descomprimo 2 veces la respuesta y me sale el motivo del error (y esto si que es para chinarse)


<SituacionRegistro>
<EstadoRegistro>Incorrecto</EstadoRegistro>
<CodigoErrorRegistro>B4_2000019</CodigoErrorRegistro>
<DescripcionErrorRegistro>
BaseRectificada: La Base Rectificada solo puede venir informada si Tipo (de rectificativa) es S.
</DescripcionErrorRegistro>
</SituacionRegistro>

Eso ya lo sabía, pero en TBAI GIP me daba la misma factura como correcta con aviso
011 Aviso: Error validación de negocio: FacturaRectificativa.

Comento a TBAI GIP y contestan:

Egun on, Buenos días
El motivo del error es que siendo una factura rectificativa, no se indica cual es la factura rectificada.
En TicketBAI siempre es obligatorio informar la factura rectificada correspondiente a la rectificativa.
Un saludo,


Ahora informo de las bases rectificadas en GIP pero no en BIZ y además tb hay que informar de la factura rectificada, tanto GIP como BIZ aunque sea dato no obligatorio (por lo memos hasta el otro día)


Lo importante es esto:
eus-bizkaia-n3-codigo-respuesta:

eus-bizkaia-n3-numero-registro:

eus-bizkaia-n3-tipo-respuesta: Correcto

Content-Type: application/xml;charset=UTF-8

Ordenaré el código PHP ya funcionando y con permiso de los administradores y a petición de Sistel iré subiendo las partes de código que me solicite.

Gracias a todos por todo, me estáis ayudando bastante más de lo que parece

Bueno, en Gipuzkoa, no sé como será, pero en Bizkaia, en el caso de factura rectificativa, sí es obligatorio el número de factura que rectifica.
Boletín Oficial de Bizkaia nº 175 del 11 de septiembre de 2020
Artículo 3, apartado g
Y también aparece en rojo (obligatorio) en la estructura (página 11)

Muchísimas gracias, Bilbur, por tu ayuda.
Seguro que también les será muy útil a otros colegas que leen este foro, aunque no participen.

Un saludo

Cierto, me lié con el SII puesto que en el xml que genero copié lo que tenía del SII y lo tenía como no obligatorio.


Errores de importancia relativa que se van corrigiendo conforme a los resultados de las pruebas.


Por otro lado, cuando queras empezamos con PHP

¿Alguien sabe si el encadenamiento con la factura anterior es relativo o absoluto? es decir, si se encadena con la última factura de su serie o con la última generada sea de la serie que sea?

Se encadena con la última generada sea de la serie que sea

PHP Generación del xml
 

Generación previa a su firma
En mi caso sólo vendo bienes, no servicios

La intención es ver la estructura del xml

</div>Tened en cuenta u obviad las variables de PHP que vienen de una consulta sql previa


Seguimos con el encadenamiento dentro del mismo script
Busco la factura firmada anterior



Fima del xml que detallaré más adelante en otro envío


</div>

Queda enviar el desarrollo de la firma donde intervienen XmlTools.php, firmador.php y el certificado de firma y su clave.

PHP Firma del xml
 

Nos hemos quedado aquí:

Lo que hago es indicar donde guardarlo, en mi caso con el mismo nombre número de orden de emisión de la factura.

XmlTools.php:
</div>

Este es el importante: firmador.php
Mucha atención al contenido de firmador.php
Es posible que algo sobre pero no me atrevo a tocar nada ya que finciona bien.
Proximamente hablaremos del envío de los xml firmados a GIP y a BIZ, este último tiene su miga.
A vuestra disposición para comentar y aclarar lo que requiráis


Sería bueno poder firmar sólo con los .pem y sin clave de certificado pero quizás no se pueda.


Un saludo

¡¡¡¡ Genial, Bilbur !!!!

Estaba atrancado con el tema de la firma.
No conseguía firmar el XML sin errores.
Seguro que con tu clase Firmador, salgo, por fín, del atolladero.

¡¡¡ Muchísimas Gracias !!!
Apunta que te debo alguna, para cuando acabe la pandemia.

Un cordial saludo

Nosotros encadenamos con la última factura independientemente de la serie.
(gracias por la corrección bilbur)

Preguntas frecuentes


¿Cómo se realiza el encadenamiento de la factura anterior?


El sistema TicketBAI implica que cada factura debe identificar la factura anterior (serie,
número, fecha y 100 primeros caracteres de la firma). Aunque en el esquema del
fichero TicketBAI estos campos no son obligatorios, esta circunstancia se debe a que
existen varias situaciones en los que este requisito no es exigible (p. ej. la primera
factura, o en caso de rotura del dispositivo).
Dentro de este encadenamiento, cada factura solo puede tener como máximo una
única factura anterior, es decir cada factura de un obligado tributario solo puede estar
referenciada como factura anterior en una única factura de dicho obligado tributario.
El cumplimiento del requisito de encadenamiento depende de la forma de
funcionamiento del sistema de facturación:
Si un mismo dispositivo o centro de facturación emite facturas de diferentes
series, el requisito de encadenamiento debe identificar la factura anterior
expedida, con independencia de la serie dentro de ese dispositivo o centro de
facturación (por ejemplo, a una factura de una serie ordinaria le puede preceder
una factura rectificativa de otra serie).
•
Igualmente, si el sistema de facturación es un sistema totalmente centralizado,
el encadenamiento se refiere a la última factura expedida por el sistema en
orden temporal.
•
En concreto, la aplicación “Haz tu factura” funcionaría como un sistema de facturación
totalmente “centralizado”, por lo que encadena todas las facturas en orden temporal.
Si son necesarios varios procesos de facturación (se podrían asimilar a centros de
facturación) para dar respuesta a varios usuarios concurrentes de una misma empresa
de forma paralela, se debería encadenar en orden temporal dentro de cada proceso o
centro de facturación, con independencia de la serie. En este caso, debe existir un
número acotado de procesos o colas de facturación, asociado al número de usuarios
concurrentes por empresa emisora de facturas

Tienes razón bilbur.
Estaba pensando en el cálculo del HASh no del encadenamiento...

Borro el mensaje anterior para evitar confusiones.

Si necesitas ayuda en la implementación, me dices. No sea que se me olvidara subir algo.
Para comprobar las firmas y antes de enviarlas yo utilizo estos dos enlaces

http://tools.chilkat.io/xmlDsigVerify.cshtml

https://web.uanataca.com/pe/servicio...ma-electronica

Si te da correcto en las dos validaciones pues ¡eureka!

PHP Envío a TBAI GIP
 

Os adjunto lo que tengo hecho para el envío a Gipuzkoa
Este envío es el más sencillo
Más o menos lo que hago es:

1. Proceso previo o simultáneo a la emisión y firma de la factura
2. En el directorio donde están las facturas firmadas, creo, si no están, los directorios de Envios y Respuestas.
3. Si la factura firmada existe en el directorio de facturas firmadas, la envío a TBAI GIP
4. Me guardo la respuesta y si es afirmativa muevo la factura firmada al directorio de Envios

<div></div>Aparte tengo un script para visualizar la respuesta
En este lo más interesante puede ser la generación de la url del mensaje TBAI para verlo como si se tratara del código QR



Tengo, si interesa, la generación del código QR para PDF con la libreria fpdf.


Comentamos ...

Muchas gracias bilbur.

Aprovecho la ocasión para lanzar otra pregunta -de nota- al que ni las haciendas de Guipúzcoa y Vizcaya han respondido: ¿como se declaran las operaciones hechas a comisión por terminales externos pero que se cobran con el programa (por ejemplo las recargas de móviles)? En estos casos, el programa genera una factura simplificada por importe cero, pues las ventas a comisión no son ventas propias del negocio:

• ¿Hay declarar estas facturas? En su caso ¿debe llevar el QR?
• ¿Qué pasa con la comisión? ¿no habría que declararla en el 140 de batuz?
• Y el más difícil todavía: ¿y si la comisión es variable dependiendo de las ventas (ONCE y loterías) y no se conoce hasta que se recibe la factura?

¿Nadie más se ha encontrado con este caso o alguno similar?

Un saludo

Hola.

Yo entiendo que hablas de un suplido.

En el caso en el que, en una factura, por ejemplo, además de los honorarios de un profesional se documentase un suplido, el importe del suplido no formaría parte de la base imponible del IVA pero estas facturas deben cumplir igualmente los requisitos TicketBAI.

En cambio, si únicamente se quisiera documentar un suplido, se trataría de una operación en la que no se documenta ninguna entrega de bienes ni prestación de servicios realizada por el profesional en el desarrollo de su actividad, ya que en estos casos el empresario actuaría como mero intermediario, satisfaciendo sumas de dinero del cliente a un tercero por mandato expreso. En este caso, no habría obligación de expedir factura de acuerdo con lo dispuesto en el Reglamento de facturación, pudiéndose documentar la operación en un recibo u otro justificante. Por tanto, un documento en el que solo se informe de un suplido quedaría fuera del ámbito de aplicación de TicketBAI.

Luego en el 140 tiene que ir como un ingreso sin factura.

Entiendo que si se emite factura, aunque importe sea cero, hay que declararla en TBAI y estar a lo que ponga en la factura emitida.
Yo si que las declaro en SII.
A mi se me da, a veces, el caso de factura emitida total cero por venta de mercancía p.e. 10 y devolución de envases tb de -10, total 0,00.

Así no "pierdo" número de factura ni encadenamientos

Lo mejor, probar ahora en pruebas (BIZ y GIP) y ver el resultado
Si da error, enviar correo a los dos y a esperar

Proceso de facturación
 

Hola,Voy a empezar a desarrollar el acceso a ticketBai, tengo una pregunta de concepto, por si alguno que ya tenga la solución puede contestarme.
En mi caso generamos la facturas una vez a la semana, generamos cientos de facturas.


¿Hay que realizar una petición por factura y asignar a ese documento el código y el QR en el momento de la generación?


¿Se pueden generar las facturas y posteriormente acceder a ticketbai cuando se imprimen?


Voy implementar sobre VB6 y .NET, usando Chilkat y SecureBlackBlox.


Gracias

El problema es que ese tipo de iva es un iva no sujeto y como envies una factura con importe cero y con iva no sujeto TBAI da error. A nosotros ya se nos planteo el caso y nos contestaron con lo que he puesto antes. Si el importe es cero y no hay base imponible hay que generar un recibo y no una factura.

Sólo se puede incluir en una factura que tenga otros conceptos con base imponible a iva.

Hola,

La factura está completa cuando obtienes su XML firmado.
Para obtener el XML firmado de la factura no necesitas acceder a ningún sitio externo.
Es un proceso local.

Otra cosa diferente es su envío a Hacienda Foral.
Si es de Gipuzkoa, debe hacerse el envío inmediatamente después de haber generado el XML firmado (salvo que obtengas de Hacienda una autorización para el envío posterior por no tener conexión ni fija ni móvil a Internet).
Si es de Bizkaia, tienes el plazo normal que había para las declaraciones de IVA (trimestrales o mensuales según la empresa o en un plazo de 4 días si es una empresa obligada al SII), pero se envían dentro del capítulo 1.1 del LROE.

Pero para imprimirla (o enviarla por email como PDF) tienes que añadir en la parte de abajo del documento el código TBAI y el código QR.
Esos códigos TBAI y QR puedes obtenerlos cuando vayas a imprimirla. No los necesitas antes.

Es lo que yo he entendido, pero se admiten correcciones.

Saludos

Esa es otra, porque las ventas en agencia (que así es como se llaman oficialmente), además de a retención por IRPF al ser una actividad profesional, están sujetas a IVA, aunque sobre la comisión, por lo que es un IVA soportado, no repercutido.

Cágate lorito.

Genial, entonces el proceso consta en generar y firmar xml cuando en mi sistsema se genera la factura y en el momento de imprimir/enviar la factura envio a TBAI y recupero codigo y QR para insertar en el documento.


Gracias

No es un suplido ya que no es el vendedor el que pone el dinero sino el cliente. En todo caso sería un cobro por adelantado.

Me da que esto va a ser trabajo del gestor, que es el que lo declarará en 140 1.2.

Segun dice en la pregunta

Por lo tanto es un servicio que realiza otra empresa pero lo paga a través de ti. Si no estoy equivovado es un suplido.

Yo no lo veo así: no es el profesional quien adelanta el dinero sino el que lo cobra del cliente, por lo que sería un cobro por adelantado del que detraerá una parte por su servicio. Es decir, un cobro por adelantado por partida doble: una parte por cuenta del vendedor y otra por cuenta propia al haber cobrado por adelantado su comisión, de la que deberá soportar el IVA y la retención.

Hola batuzail.
Te recomiendo que te leas todo el hilo porque te aclarará bastantes dudas. Hay bastantes mensajes, pero creo que vale la pena el tiempo.

Aquí también tienes un documento con preguntas y respuestas que han publicado desde TicketBAI/Batuz. Ahí también aclaran muchos conceptos.
Por lo demás en cuanto a las preguntas, este gráfico aclara bastante bien los pasos del proceso.

Alava y Guipuzcoa exigen que el envío sea inmediato tras generar la factura. Cuando generes la factura debes crear el XML, firmarlo y enviarlo (para ello has generado el IDTBAI). Revisa los pasos del gráfico anterior.

Si te refieres a enviarlas a la administración, tal y como te he dicho, el envío debe ser en el momento de realizar la factura.
La impresión en papel/EMail/PDF/... (con el QR y el Id de TBAI incluídos) puede ser posterior.

Para complicarlo más:
Factura emitida base imponible cero
Respuesta TBAI BIZ


Parece ser que SI se pueden enviar facturas con base imponible, cuotas y total cero
He probado con facturas simplificadas total cero
También correcto en TBAi BIZ


Es posible que no tenga que ver con vuestra casuística, las pruebas son venta de bienes, no prestaciones de servicios.


Un saludo

Hola.

Una factura con base 0 si puedes mandar. Lo que no puedes mandar es una factura con solo una línea de no sujeta. Que es como se envía un suplido.

Yo sigo liado con los encadenamientos xDD, cuál de estos supuestos vale y cuál de estos ,no?

Pj.

Sería correcto hacerlo así OPCION A:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazadas (pj por fallo del sistema ticketbai)
3.Registramos la factura 003 y la encadenamos a la última factura recibida en TicketBAI, la 001, recibida
4.Se arregla el error y ahora volvemos a mandar la 002 encadenando a la última factura registrada en ticketbai, la 003.

O hay que hacerlo tal que así OPCIÓN B:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazada (pj por fallo del sistema ticketbai)
3.Registramos la factura 003, encadenando a la 002, obtenemos el warning.
4.Volvemos a enviar la 002 encadenada a la 001.

p.d. me han dichos los de ticketbai que van a sacar pronto nueva versión con opción de subsanar facturas. cómo es posible que a estas alturas metan nuevas funciones posiblemente tan vitales? en fin

Factura encadenada
 

Os adjunto respuesta de Batuz con respuesta a las encadenadas. Nosotros tenemos varias delegaciones y cada delegación una serie de factura y no tienen las facturas del resto de delegaciones, por lo que el encadenamiento lo vamos a realizar en base a la serie.

Contestación de Batuz:

El sistema TicketBAI implica que cada factura debe identificar la factura anterior (serie, número, fecha y 100 primeros caracteres de la firma). Aunque en el esquema del fichero TicketBAI estos campos no son obligatorios, esta circunstancia se debe a que existen varias situaciones en los que este requisito no es exigible (p. ej. la primera factura, o en caso de rotura del dispositivo).

El cumplimiento del requisito de encadenamiento depende de la forma de funcionamiento del sistema de facturación:
- Si un mismo dispositivo emite facturas de diferentes series, el requisito de encadenamiento debe identificar la factura anterior expedida, con independencia de la serie (por ejemplo, a una factura de una serie ordinaria le puede preceder una factura rectificativa de otra serie).
- Igualmente, si el sistema de facturación es un sistema centralizado que genera las series y los números de facturación, con independencia del dispositivo que se esté utilizando, el encadenamiento se refiere a la última factura expedida por el sistema.
En concreto, “Haz tu factura” funcionaría como un sistema de facturación “centralizado”, por lo que encadena las facturas independientemente de la serie.
- No obstante, si existen diferentes dispositivos o centros de facturación, los cuales sólo expiden facturas dentro de una serie específica para cada dispositivo o centro, el encadenamiento se produce dentro de cada serie.
Este último parece ser el caso al que se refiere la pregunta planteada.