respuesta al error 3000
 

Hola a todos!!!
Había puesto esta pregunta por error en otro hilo. Perdón.
¿Cómo solucionaríais el error 3000 registro de facturación duplicado?
¿enviando otro con el número de factura modificado?. que entiendo yo que es el motivo del error ¿no?

Eso te esta indicando que la factura que envias ya esta en el sistema de la AEAT, si esta bien no es necesario que hagas nada, por el contrario, si lo que quieres es modificar algo puedes hacer una subsanacion indicando que no hay rechazo previo.

¿Lo primero que yo preguntaría es porqué tienes un registro duplicado en la AEAT?
A partir de saber el porqué, se puede decidir una solución.


¿Ha sido por un error al subirlo la primera vez? (error en tu sistema)
¿Está enviando una modificación? (podría ser que lo estás enviando como alta, en lugar de como subsanación)
¿Estás en preproducción? (en ese caso no hacer nada y crear una serie nueva, por ejemplo)
¿Problemas al recibir la respuesta del alta y tu sistema no la tiene como subida? (en ese caso no habría que hacer nada)
....

Hay que tener mucho cuidado con este error, ya que puede parecer que que ya hayas enviado esta factura desde su SIF, y a lo mejor, no registraste la respuesta correctamente ( con lo que no harías nada al respecto ) o puede ser que hayas enviado esta factura desde otro SIF y ésta sea totalmente distinta a la que tiene registrada la Aeat. Cuando se trabaja con varios SIF's para un mismo obligado tributario este error no es tan obvio.

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.

Tambien podria ser que se recupera la copia de un SIF y siga con la misma serie pero con la nuemracion atrasada.

Por cierto, ¿Como o que medios utilizais para controlar que un mismo SIF que se instala por defecto en dos equipo (2 tiendas del mismo contribuyente) y al emitir con la misma serie no se dupliquen?
Colocais en la composicion SERIE+NUMERO algo como la MAC, NUMERO DE SERIE DEL PROGRAMA, o algo irrepetible por equipo cuando estos estan descentralizados.?

Tambien podria ser que se recupera la copia de un SIF y siga con la misma serie pero con la nuemracion atrasada.

Por cierto, ¿Como o que medios utilizais para controlar que un mismo SIF que se instala por defecto en dos equipo (2 tiendas del mismo contribuyente) y al emitir con la misma serie no se dupliquen?
Colocais en la composicion SERIE+NUMERO algo como la MAC, NUMERO DE SERIE DEL PROGRAMA, o algo irrepetible por equipo cuando estos estan descentralizados.?

Tambien podria ser que se recupera la copia de un SIF y siga con la misma serie pero con la nuemracion atrasada.

Por cierto, ¿Como o que medios utilizais para controlar que un mismo SIF que se instala por defecto en dos equipo (2 tiendas del mismo contribuyente) y al emitir con la misma serie no se dupliquen?
Colocais en la composicion SERIE+NUMERO algo como la MAC, NUMERO DE SERIE DEL PROGRAMA, o algo irrepetible por equipo cuando estos estan descentralizados.?

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?

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?

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?

La clave principal, del registro de facturación es IdEmisorFactura-NumeSerieFactura-FechaExpedicionFactura (el Nodo IDFactura).
No puedes usar un GID para identificar una factura ,ya que éstas, deben ser correlativas en su expedición. Cuando un OT tiene varios SIF's, lo suyo sería que las series o el número de factura recogieran un parámetro que identificara unívocamente al SIF que la ha generado. Si quieres que sea el número de factura, cada SIF tendría un identificador de dos dígitos, por ejemplo, que precedería el número de factura
de tal forma forma que el número de factura generado por el SIF 1 estaría formado por Serie-número de la siguiente manera 01-01xxxxxxx, factura serie 01 con número 01xxxxxxx y el SIf 2 generaría la factura 01-02xxxxxx y así sucesivamente (suponiendo que no vas a generar más de 1 millón de facturas en el mismo año fiscal).
Si quieres que sea la serie la que lleva el identificador, el SIF 1 generaría la factura 0101-xxxxxxx y el SIF 2 la 0201-xxxxxxxx

FUTURA te han contestado desde Veri*Factu?
Cuando lo hagan, postea la respuesta por favor.
Gracias

Contestacion: (Solo me dicen que no seria muy adecuado, pero sigo creyendo que seria una medida de seguridad para ambas situaciones que menciono)

Contestación de Verifactu:
Buenos días:
La clave única que identifica a cada factura se compone del conjunto de datos: <NIF> +
<NumSerieFacturaEmisor> + <FechaExpedicionFacturaEmisor>. Es decir, los datos que conforma el
IDFactura:
IDFactura
IDEmisorFactura Número de identificación fiscal (NIF) del obligado a expedir laNumSerieFactura Nº Serie+Nº Factura que identifica a la factura emitida.
FechaExpedicionFactura Fecha de expedición de la factura.
A partir de esto, entendemos que deberán revisar el planteamiento que nos comentan.
Y en cuanto a si "existe algún problema de tipo conceptual en caso de revisiones", el
NumSerieFactura es un campo que se corresponde con los datos que aparecerán en la factura, así que no
parece demasiado apropiado que utilicen esa "coletilla". No obstante, igual les interese saber que existe
un campo llamado <RefExterna> que es optativo y cuya finalidad es ayudar a identificar los registros a los
SIF. Es un campo que ha sido añadido a petición de diferentes desarrolladores. En la descripción del
mismo se indica lo siguiente:

Se refiere al campo "RefExterna"

En la respuesta aparece este mismo campo. Puede revisarlo en el documento de descripción del servicio
web en su página 25. Si quieren identificar cada registro con ese GUI que comentan, posiblemente esta
sería la ubicación apropiada para ello.