Numeración de tickets

[Jarogo08]

Buenos días a todos

Quería plantearos un problema que tenemos, a ver cómo lo habéis orientado vosotros.

En el caso de las facturas, no vemos problema con la numeración: como siempre tenemos un albarán previo, al momento de facturar coge el número que le corresponde.
Ejemplo: yo estoy haciendo el albarán 1 y mi compañero el albarán 2. Si mi compañero termina antes su albarán, su factura va a ser la número 1 y la mía la número 2. Y esa numeración va a ser la que se envíe a Verifactu. Esto es correcto porque tenemos 2 documentos distintos (albaranes y facturas)


Ahora el lío viene con los tickets, en el que al menos nosotros NO tenemos 2 documentos (preticket y ticket, o como queráis llamarle).
Imaginad que yo estoy haciendo el ticket 1 y mi compañero el ticket 2. Si mi compañero termina antes su ticket (para nosotros terminarlo significa pasarle la fase de pago), tiene que ser el número 1 en Verifactu, y yo cuando termine el mío tendrá que ser el número 2. Pero claro, sólo tenemos una tabla y el número de ticket es clave primaria, no podemos cambiarle el valor según se le vayan pasando la fase de pago.
Lo que hemos hecho es aparte de tener el campo NumeroTicket crear el campo NumeroTicketVerifactu, que mientras no se finaliza el ticket está a 0 y cuando se finaliza es cuando se le da valor. De esta manera, el ticket que hice yo tendrá NumeroTicket=1 y NumeroTicketVerifactu=2 y el ticket de mi compañero tendrá NumeroTicket=2 y NumeroTicketVerifactu=1.

Y a la hora de la impresión y de mandar a Verifactu el campo que tenemos en cuenta es NumeroTicketVerifactu.

¿se os dió este problema a vosotros? ¿Como lo habéis planteado?

Muchas gracias!

[Galahad]

Empezado por Jarogo08

Buenos días a todos

Quería plantearos un problema que tenemos, a ver cómo lo habéis orientado vosotros.

En el caso de las facturas, no vemos problema con la numeración: como siempre tenemos un albarán previo, al momento de facturar coge el número que le corresponde.
Ejemplo: yo estoy haciendo el albarán 1 y mi compañero el albarán 2. Si mi compañero termina antes su albarán, su factura va a ser la número 1 y la mía la número 2. Y esa numeración va a ser la que se envíe a Verifactu. Esto es correcto porque tenemos 2 documentos distintos (albaranes y facturas)


Ahora el lío viene con los tickets, en el que al menos nosotros NO tenemos 2 documentos (preticket y ticket, o como queráis llamarle).
Imaginad que yo estoy haciendo el ticket 1 y mi compañero el ticket 2. Si mi compañero termina antes su ticket (para nosotros terminarlo significa pasarle la fase de pago), tiene que ser el número 1 en Verifactu, y yo cuando termine el mío tendrá que ser el número 2. Pero claro, sólo tenemos una tabla y el número de ticket es clave primaria, no podemos cambiarle el valor según se le vayan pasando la fase de pago.
Lo que hemos hecho es aparte de tener el campo NumeroTicket crear el campo NumeroTicketVerifactu, que mientras no se finaliza el ticket está a 0 y cuando se finaliza es cuando se le da valor. De esta manera, el ticket que hice yo tendrá NumeroTicket=1 y NumeroTicketVerifactu=2 y el ticket de mi compañero tendrá NumeroTicket=2 y NumeroTicketVerifactu=1.

Y a la hora de la impresión y de mandar a Verifactu el campo que tenemos en cuenta es NumeroTicketVerifactu.

¿se os dió este problema a vosotros? ¿Como lo habéis planteado?

Muchas gracias!

Puedes asignar el número de ticket en el momento que se finaliza el ticket, de esa manera pueden haber varios tickets 'en proceso' , cuando se finalice se asigna el número y se envia.

[Jarogo08]

Empezado por Galahad

Puedes asignar el número de ticket en el momento que se finaliza el ticket, de esa manera pueden haber varios tickets 'en proceso' , cuando se finalice se asigna el número y se envia.

Muchas gracias Galahad


El problema es que la clave primaria de mi tabla de tickets es Ejercicio/Serie/Numero, y lo que dices me obligaría a cambiar la clave de la tabla (para que el Numero estuviera a 0 hasta que se finalizase). Y no me gusta nada esa idea porque me cambiaría la estructura de la tabla, con lo que tendría que cambiar código en todos los sitios donde se consultan/borran/crean/actualizan datos de esa tabla.

[[newtron]]

Empezado por Jarogo08

Buenos días a todos

Quería plantearos un problema que tenemos, a ver cómo lo habéis orientado vosotros.

En el caso de las facturas, no vemos problema con la numeración: como siempre tenemos un albarán previo, al momento de facturar coge el número que le corresponde.
Ejemplo: yo estoy haciendo el albarán 1 y mi compañero el albarán 2. Si mi compañero termina antes su albarán, su factura va a ser la número 1 y la mía la número 2. Y esa numeración va a ser la que se envíe a Verifactu. Esto es correcto porque tenemos 2 documentos distintos (albaranes y facturas)


Ahora el lío viene con los tickets, en el que al menos nosotros NO tenemos 2 documentos (preticket y ticket, o como queráis llamarle).
Imaginad que yo estoy haciendo el ticket 1 y mi compañero el ticket 2. Si mi compañero termina antes su ticket (para nosotros terminarlo significa pasarle la fase de pago), tiene que ser el número 1 en Verifactu, y yo cuando termine el mío tendrá que ser el número 2. Pero claro, sólo tenemos una tabla y el número de ticket es clave primaria, no podemos cambiarle el valor según se le vayan pasando la fase de pago.
Lo que hemos hecho es aparte de tener el campo NumeroTicket crear el campo NumeroTicketVerifactu, que mientras no se finaliza el ticket está a 0 y cuando se finaliza es cuando se le da valor. De esta manera, el ticket que hice yo tendrá NumeroTicket=1 y NumeroTicketVerifactu=2 y el ticket de mi compañero tendrá NumeroTicket=2 y NumeroTicketVerifactu=1.

Y a la hora de la impresión y de mandar a Verifactu el campo que tenemos en cuenta es NumeroTicketVerifactu.

¿se os dió este problema a vosotros? ¿Como lo habéis planteado?

Muchas gracias!

Según planteas tu caso, y para no hacer modificaciones profundas, claramente hay que tener dos numeraciones. Lo único que tienes que tener en cuenta de que el número de ticket real sería lo que llamas NumeroTicketVerifactu y el otro se quedaría como un mero número de orden.

[Galahad]

Empezado por Jarogo08

Muchas gracias Galahad


El problema es que la clave primaria de mi tabla de tickets es Ejercicio/Serie/Numero, y lo que dices me obligaría a cambiar la clave de la tabla (para que el Numero estuviera a 0 hasta que se finalizase). Y no me gusta nada esa idea porque me cambiaría la estructura de la tabla, con lo que tendría que cambiar código en todos los sitios donde se consultan/borran/crean/actualizan datos de esa tabla.

Nosotros tenemos una estructura similar, una clave primaria como comentas,, pero utilizamos de cara al cliente y a todos los efectos del ticket otro campo que llamamos 'identificador' que es el que aparece como número de ticket a todos los efectos . Este número es que se asigna al finalizar el ticket. De esa manera, se evitan los huecos en la numeración.

[rdea]

Nosotros tenémos un esquema parecido donde serie tambien se corresponde al numero de terminal.
Por ejemplo, la serie 1 es para facturas y luego cada ticket la seríe sería la del terminal que este usando(por ejemplo si tenemos 3 terminales le asignamos el número de serie 25,26 y 27. Así no se pisan los numeros y cada equipo tiene su terminal).
Al hacer la factura recapitulativa de esos tickets si pasa a tener la serie un ESA FACTURA, la de recapitulación. A ver si por ahí te ayuda. un saludo!

[Jarogo08]

Empezado por newtron

Según planteas tu caso, y para no hacer modificaciones profundas, claramente hay que tener dos numeraciones. Lo único que tienes que tener en cuenta de que el número de ticket real sería lo que llamas NumeroTicketVerifactu y el otro se quedaría como un mero número de orden.

Así es como lo planteamos, no creo que haya mucho más por donde tirar sin cambios profundos de estructura, que no nos apetecen nada!

[[newtron]]

Empezado por Jarogo08

Así es como lo planteamos, no creo que haya mucho más por donde tirar sin cambios profundos de estructura, que no nos apetecen nada!

Finalmente apuntar que ya los programas "modernos" (y no sé si algunos "antiguos") usan un id automático para todo independientemente del número de documento, código o diablos que se quiera asignar al registro en particular. Teniendo un id interno para todo no tendrías ese problema porque le asignas el número de documento final cuando lo guardes ya sean albaranes, tickets, facturas, etc. Igualmente si (por ejemplo) usas un id interno para los artículos podrías cambiar sin miedo la referencia del mismo y cosas así.


Saludos.

[novatico]

En nuestro caso, llevamos series diferentes por cada línea de emisión de tickets, que aunque sigamos llamándolos así, recuerda que son "Facturas Simplificadas"

[pablog2k]

he hecho una consulta al respecto de esta duda al correo que tienen de ayuda, con lo que contesten os diré

[Jarogo08]

Empezado por novatico

En nuestro caso, llevamos series diferentes por cada línea de emisión de tickets, que aunque sigamos llamándolos así, recuerda que son "Facturas Simplificadas"

En nuestro caso si en un mostrador tenemos 3 pcs pueden compartir la serie y la caja.


Pero aunque tengas una serie por cada pc, ¿no se te podría dar el caso? En nuestro programa tenemos la opción de suspender un ticket, con lo cual lo empiezas ahora, lo suspendes, creas x tickets mientras tanto y luego recuperas y finalizas el suspendido. Y ya tienes el mismo problema con la numeración. ¿vuestro programa no tiene opción de suspender un ticket?

[siyei]

Creo que estáis confundiendo la velocidad con el tocino.

La normativa Verifactu habla de enviar las facturas en el momento que se "expidan" conservando el encadenamiento con la factura anterior, pero en ningún momento se habla que la factura 1 se tenga que enviar antes que la 2.

Si tengo dos puestos de trabajo, puedo finalizar la factura 2 antes que la 1 por la razón que sea. En este caso primero envío la factura 2, y posteriormente envío la factura 1 que llevará encadenada la factura 2. Las únicas limitaciones al respecto están en la fecha, la fecha de envío tiene que coincidir con la fecha de la factura.

[bmfranky]

Empezado por siyei

Creo que estáis confundiendo la velocidad con el tocino.

La normativa Verifactu habla de enviar las facturas en el momento que se "expidan" conservando el encadenamiento con la factura anterior, pero en ningún momento se habla que la factura 1 se tenga que enviar antes que la 2.

Si tengo dos puestos de trabajo, puedo finalizar la factura 2 antes que la 1 por la razón que sea. En este caso primero envío la factura 2, y posteriormente envío la factura 1 que llevará encadenada la factura 2. Las únicas limitaciones al respecto están en la fecha, la fecha de envío tiene que coincidir con la fecha de la factura.

Hombre tocino no se, pero si envias la factura 2 y po algun motivo no envias la 1 , el tocino sera de pollo...

[Jarogo08]

Empezado por bmfranky

Hombre tocino no se, pero si envias la factura 2 y po algun motivo no envias la 1 , el tocino sera de pollo...

Efectivamente, puedes tener tickets abiertos en varios pcs y si alguno no se finaliza quedan saltos de contadores. Y eso si que dice la normativa que no está permitido. De ahí que vayamos asignando el contador correlativo que le toque, porque el resto de tickets se finalizarán o no

[[newtron]]

Yo lo que si tengo claro es que hay que asignar el número en el momento de generar la factura/ticket (y por lo tanto enviarlo en ese momento). El "aparcar" documentos no se debería de hacer si ya se ha asignado el número, o sea, que si queremos "aparcar" una factura o ticket tendría que ser sin haber asignado todavía la numeración definitiva a no ser que queramos tener problemas.


Saludos.

[Jarogo08]

Empezado por newtron

Yo lo que si tengo claro es que hay que asignar el número en el momento de generar la factura/ticket (y por lo tanto enviarlo en ese momento). El "aparcar" documentos no se debería de hacer si ya se ha asignado el número, o sea, que si queremos "aparcar" una factura o ticket tendría que ser sin haber asignado todavía la numeración definitiva a no ser que queramos tener problemas.
Saludos.

Claro, no puedes asignarle el número definitivo al ticket en el momento de generarlo porque precisamente aún lo acabas de crear, no tiene líneas (a no ser que tengas un documento previo y el ticket se genere cuando ya finalizas ese documento previo).

Es a lo que me refería en la pregunta inicial... en las facturas no ocurre eso porque cuando se genera ya está finalizada, no se le puede tocar. Y tampoco existe lo de "aparcar" la factura (al menos en nuestro programa)

Pero en los tickets la cosa cambia... imagínate una cafetería. Yo pido un café y ya generan el ticket con esa línea. Pero ese ticket se "aparca" (nosotros le llamamos "suspender"). Dentro de 20 minutos puedo pedir otro café y dentro de 30 una coca cola. Y cuando me marche será cuando pague y ese ticket se finalice (y ahí es donde debería coger el número que le toca y enviarse). En esa hora que yo estuve con mi ticket "suspendido" se pudieron crear, finalizar y enviar otros 10.

Por eso preguntaba como lo estábais planteando vosotros, pero veo que lo de crear el NumeroTicketVerifactu igual no fue tan mala idea

[pablog2k]

ya he obtenido la respuesta de verifactu respecto al tema, voy a pegar mi pregunta y su respuesta:

Buenos días, realizando el desarrollo en nuestro ERP de verifactu, nos surge la siguiente duda:
Actualmente, nuestro ERP (y el de otros muchos), cuando se crea una factura, se asigna un nº de factura automáticamente.
En el caso que haya dos personas realizando facturas, nos pasa lo siguiente:
Persona 1 crea una factura , el sistema le da el nº de factura 10, con fecha digamos las 10:15:27
Persona 2 crea otra factura, el sistema le da el nº de factura 11, con fecha 10:16:01 (inmediatamente posterior a la factura 10)
Por el motivo que sea (puede que la persona 1 esté facturando muchos albaranes y tarde mas en acabar la factura), la persona 2 acaba antes la factura que la persona 1.
Esto, antes de verifactu, no suponía un 'problema', pero ahora nos surge la siguiente duda:
Al realizar el encadenamiento en el registro de facturación, la factura 11 hará el encadenamiento con el ultimo registro de facturación realizado,que es el que corresponde a la factura 9, quedando la factura 11 encadenada a la factura 9.
Cuando la persona 1 finalice la factura 10, se creará el registro de facturación de la factura 10, que irá encadenada al ultimo registro de facturación realizado, por lo tanto irá encadenado a la factura 11.
El siguiente registro de facturación, suponiendo que es el 12, irá encadenado al registro de facturación correspondiente a la factura 10.
Para explicarlo mas visual, el encadenamiento quedaría así:
9 -> 11 -> 10 -> 12 -> 13... etc
Esto sería correcto?
Muchas gracias


respuesta:

Buenos días:

Le confirmamos que sería correcto el comportamiento que nos describe. El encadenamiento se realiza siempre en orden cronológico de generación de los registros de facturación en el SIF y dichos registros deben generarse cuando finalmente se emite la factura. Por lo cual, aunque la entrada en el sistema de dichos registros no sea siguiendo el orden de número de factura con la que identifican sus facturas, esto no supondrá ningún problema ni será motivo de posibles rechazos.

[Jarogo08]

Empezado por pablog2k

ya he obtenido la respuesta de verifactu respecto al tema, voy a pegar mi pregunta y su respuesta:

Buenos días, realizando el desarrollo en nuestro ERP de verifactu, nos surge la siguiente duda:
Actualmente, nuestro ERP (y el de otros muchos), cuando se crea una factura, se asigna un nº de factura automáticamente.
En el caso que haya dos personas realizando facturas, nos pasa lo siguiente:
Persona 1 crea una factura , el sistema le da el nº de factura 10, con fecha digamos las 10:15:27
Persona 2 crea otra factura, el sistema le da el nº de factura 11, con fecha 10:16:01 (inmediatamente posterior a la factura 10)
Por el motivo que sea (puede que la persona 1 esté facturando muchos albaranes y tarde mas en acabar la factura), la persona 2 acaba antes la factura que la persona 1.
Esto, antes de verifactu, no suponía un 'problema', pero ahora nos surge la siguiente duda:
Al realizar el encadenamiento en el registro de facturación, la factura 11 hará el encadenamiento con el ultimo registro de facturación realizado,que es el que corresponde a la factura 9, quedando la factura 11 encadenada a la factura 9.
Cuando la persona 1 finalice la factura 10, se creará el registro de facturación de la factura 10, que irá encadenada al ultimo registro de facturación realizado, por lo tanto irá encadenado a la factura 11.
El siguiente registro de facturación, suponiendo que es el 12, irá encadenado al registro de facturación correspondiente a la factura 10.
Para explicarlo mas visual, el encadenamiento quedaría así:
9 -> 11 -> 10 -> 12 -> 13... etc
Esto sería correcto?
Muchas gracias


respuesta:

Buenos días:

Le confirmamos que sería correcto el comportamiento que nos describe. El encadenamiento se realiza siempre en orden cronológico de generación de los registros de facturación en el SIF y dichos registros deben generarse cuando finalmente se emite la factura. Por lo cual, aunque la entrada en el sistema de dichos registros no sea siguiendo el orden de número de factura con la que identifican sus facturas, esto no supondrá ningún problema ni será motivo de posibles rechazos.

el tema del encadenamiento ya lo tenía más o menos claro... el problema es en los tickets: si envías el ticket 11 y luego el que está haciendo el 10 no finaliza ese ticket (que no es lo mismo que enviarlo más tarde; directamente no lo envía) quedaría un salto en los contadores porque en la AEAT del 9 pasaría al 11.

[pablog2k]

pero ese problema ya lo tenías antes de verifactu, no?
Hacienda no permite saltos en la numeración de las facturas y/o tickets, con lo cual, la misma solución que le dieras, te sirve para verifactu

[bmfranky]

Empezado por Jarogo08

Claro, no puedes asignarle el número definitivo al ticket en el momento de generarlo porque precisamente aún lo acabas de crear, no tiene líneas (a no ser que tengas un documento previo y el ticket se genere cuando ya finalizas ese documento previo).

Es a lo que me refería en la pregunta inicial... en las facturas no ocurre eso porque cuando se genera ya está finalizada, no se le puede tocar. Y tampoco existe lo de "aparcar" la factura (al menos en nuestro programa)

Pero en los tickets la cosa cambia... imagínate una cafetería. Yo pido un café y ya generan el ticket con esa línea. Pero ese ticket se "aparca" (nosotros le llamamos "suspender"). Dentro de 20 minutos puedo pedir otro café y dentro de 30 una coca cola. Y cuando me marche será cuando pague y ese ticket se finalice (y ahí es donde debería coger el número que le toca y enviarse). En esa hora que yo estuve con mi ticket "suspendido" se pudieron crear, finalizar y enviar otros 10.

Por eso preguntaba como lo estábais planteando vosotros, pero veo que lo de crear el NumeroTicketVerifactu igual no fue tan mala idea

Hola, en ese caso , no generas un ticket, abres como nosotros en mi ramo diriamos, una hoja de reparacion, que lleva su numero de serie, para almacenarla y puede o no facturarse, por ejemplo te pasan la orden de reparacion y sabes que va a subir una pasta, asi que se lo presupuestas al cliente y no lo reparas, esa orden de reparacion no se factura porque no llego a repararse, no le asignas un numero definitivo de factura, o si la reparas , se genera una factura que en ese caso si se le asigna un numero, en tu caso el camarero llega a la mesa y el cliene te pide la nota, en ese momento la caja, si emite el ticket real, al que se le asigna un numero de factura , se encadena y encola /envia.


Mientras no generas/imprimes el ticket, es una prefactura/proforma o cualquier documento inermedio que se te ocurra con una numeracion independiente.