Cita:
Empezado por delphiGar
Se supone que lo hace desde el mismo SIF y con el NIF del obligado tributario correspondiente, esta claro que si tienes dos SIF con la misma identificacion y con el mismo NIF va a tener un problema gordo.
Esto ya lo probe yo con el mismo SIF, y es lo que digo, que ya lo has enviado a la aeat, ademas tienes forma de comprobarlo con el QR.
|
Por este mismo tema, realice una consulta, sobre como evitar estos errores en nuestros SIF distribuidos e intentar solucionar dos de las situaciones en las que se podrian dar el caso de recibir un duplicado sin serlo realmente.
Pregunta realizada a VERIFACTU:
Quisiera saber para evitar problemas de rechazo por el motivo “3000 = Registro de
facturación duplicado.” que campos o suma de campos son los utilizados como validación para que
se produzca este error de rechazo.
En caso de que la respuesta sea IDEmisorFactura1+NumeroSerieFactura , mi pregunta es?
En el campo NumeroSerieFactura a parte de meter la composición de la serie y el número, se
podría complementar por un identificado único interno del SIF, es decir, como ejemplo,
<codigoSerie>/<numeroSecuencia>-[GUID], donde el GUID sería el identificador único con el que
identificamos a nuestro registro interno de la cabecera.
FT101-24-A/000000009-[7B387288-43F9-4C9E-BA55-96EFE27801D8]
FT101-24-A/000000010-[9C167288-43G8-4C9E-BA55-96EFE36901D0]
Con esto evitaríamos problemas de duplicidad en ocasiones muy singulares como son:
1. Durante el día se esta realizando facturas y enviando continuamente, pero por un fallo de
disco se pierde todo. En estos casos, se restable el programa completo con la copia de
seguridad última del cierre por ejemplo del día anterior, pero esta contendrá la misma
configuración de series de facturas, pero con la numeración atrasada. En estos casos, lo que
tendría que hacer el instalador o el técnico del programa, seria crear una serie nueva para
empezar a emitir, y crear otra serie auxiliar para crear todas las facturas emitidas para
tenerlas registradas en el propio SIF, pero si no lo hacen, por dejadez o por ignorancia, dejara
que el cliente emitir a partir del numero desde donde se quedo y verifactu nos remitirá
duplicidad de facturas cuando realmente no están repetidas ya que son nuevas.
Incorporando el GUID en el NumeroSerieFactura al final, el servidor no dará duplicadas, y estaremos
en una situación en el que un conjunto de facturas si las tiene VERIFACTU en sus servidores y el SIF
no poque las perdió, y VERIFACTU tendrá las anteriores y las nuevas que se emitan.
2. Otra situación, que se suele dar, es que el mismo SIF se instale por defecto en varias tiendas
del mismo contribuyente con mismo CIF, donde se tendrían que configurar con series
diferentes si se realiza una instalación técnica por un técnico formado, pero en caso de que
so se realice de esta manera por ignorancia , al emitir ambas tendríamos rechazos en uno u
en otro cuando se estén solapando la numeración, cuando realmente son facturas distintas.
3
En definitiva, y después de dar estas explicaciones, la duda es:
c. ¿Hay algún problema de tipo conceptual en caso de revisiones (ya que técnico no sería) al
poner o informar en el campo NúmeroSerieFactura una composición de serie+numero y
añadir un GUID al final?
d. ¿Cuál es el criterio de validación para dar un rechazo por duplicidad?