Pues con la respuesta que han dado creo que estan liados.
Vanos a vrr.
Si formatesas un equipp con un sif y recuoeras los datos (para seguir encadenando),como saben ellos como has recuperado el sif? Como van a saber s8 has reinstaldo.si.lo.dejas.impecable.Puedes tener clonado el disco y solo recuperar los datos, que saben si es una nueva instalacion o no, cual es la linea que delimita una reinstalacion, por que hasta actualizar uel software es una reinstalacion, yo pienso que a lo que se refieren(o mas bien lo que quieren) es que si vas a empezar de nuevo por la factura numero 1, debe ser una nueva instalacion(en ese nodo), eso tiwne mas logica, pero si vas a seguir con wl encadenamiento, por que vas a cambiar el numero de instalacion, ademas es una forma facil de "perder ventas" y lo pondrian muy facil para, simplemente cambiando nunero de instalscion, "perder un bloque de ventas" que no has dado los tiquets/facturas(un domingo con la impresora rota), no es por dar ideas pero xreo que la explicacion es erronea, yo sogo propiendo que el nodo numeroinstalacion no es mala idea la siguiente: cif+nunero de comercio+numrro de terminal, cpn lo cual cubrss lo que te indican, en cuanto a un numero de instalacion distinto por empresa para el mismo sif.
Creo que ademas han mezclado conceptos. Yo volveria a realizar la consulta poniendo ejemplos claros y como actuarias ante una eventual reinstalacion. Siempre intento preguntar ponendo distinroa escenarios y si no vuelvo a preguntar y muchas veces recrifican.
Yp tengo claro que cada vez que se rompa un equipp no voy a cambiar el numero de instalaxion(si puedo recuperar el ultimo registro que ya es suficiente en verifactu)
Y perdon por los errores de escritura, puñetero movil.
No compreis vocal ;)

Yo no lo veo nada claro, aunque pongas preguntas muy concretas al final no responden directamente, suelen remitirse a la ley y tienen respuestas más o menos establecidas. Si un agente te da una respuesta y otro te da la contraria yo no me fiaría. Al final la "jurisprudencia" la va dar el inspector con las multas. Nosotros en algunos programas a medida no llegamos al 29 así que tendrán que esperar los que quieran alguna modificación y si es importante ya veremos. Lo que sí tengo claro que quieren todo bien registrado. Nosotros por ejemplo tenemos un editor de plantillas porque cualquier cliente puede modificarse la suya ( los avanzados , hay clientes que ni se molestan ) y por lo tanto vamos a tener que guardar el diseño con que se imprimió esa factura porque es posible que el cliente te inserte por ejemplo un label con un importe total y tenemos que guardar como se imprimió esa factura en ese momento. Está consultado con verifactu y es así. Osea que cuanto más rascas, más te encuentras.

Saludos y animo!

Ok, no obtante voy a exponerles el escenario (recuperando copia de seguridad), te cuento lo que respondan.
Me temo que muchos inspectores van a tener muchas interpretaciones que no van a coincidir con lo que tengamos, y puede que esté bien como lo hayamos hecho,, a mi eso de que desaparezcan numeross de instalación me gusta poco, por que veo otro tipo de problemáticas en desconfianza ante una eventual inspeccion o seguimiento por analisis de datos desde sus servidores.
De todas formas creo que nos rayamos demasiado en ciertas cosas, ppr que ppr ejempño, lo que comentas de la plantilla, una cosa es que ante una inspeccion te pidan una copia fiel del tiquet/factura, y otra es que este todo milimetricamente en el mismo sitio, yo por ejemplo emito tiquets para las impresoras de 80mm y si el cliente lo pide por email ss lo mando en formato A4 con los mismos dats pero con otro formato, y he tenido requerimientos y les he mandado todo en el mismo formato y no ha pasado nada, nadie se ciñe 100% a todo lo que está "reglamentado" y a no ser que hayan hecho algo gordo y/o te niegues a pagar las sanciones no van a rebuscar.
Y si no dime tú cuantoa desarrolladors le van a dar caña a las rectificativas, no pueden sancionar a todos los que hacen en vez de rectificativas abonos, se cargan al 90%

Hola, aqui la respuesta, ni exactmente lo que te habian dicho ni exactamente ll que yo decia.
Pero esto va a ratos, jeje.
Vaya tela. Y si el otro equipo es el mismo hardware, jajaj. No tiene sentido.
Además, no tienen nunero de series de nada del hardware en verifactu, coml se demuestra lo contrario.

Los que han puesto estas condixiones no son tecnicos.
Yo, a vecea, hago cambios de equipo por que se ha roto la plaxa base y pongo el disco del equipo roto y reactivo windows segun las condiciones de cada fabricante x
Con la licencia.

Yo pregunté algo relacionado con este tema:

y su respuesta:

La verdad que es un liazo, creo que nos decantaremos que si formatean sea un número nuevo de instalación

Exactamente, empieza un nuevo encadenamiento. Pero 3s raro que dejen ese espacio que puede dar ligar a malas practicas en cuanto a "perdidas de datos". Hace unos meses daban la opcion de que en caso de una averia irrecuperable se podia empezar de cero con un njuevo nunero de instalacion, cosa que he tendio en cuenta, ahora estan intentando que "cualquier cosa" sea un numero dr instalacion nuevo, no ent8enfo muy bien ni ese criterio no tantos cambios de criterio.
De todas fo4maa he pedido aclracion adocional de que a que componentes se refieren exactamente en un cambio de equipo. Ppr que se ha podido cambiar medio equipp.
Ppr que puede ser que otro inspector te diga, oye, por que has empezado un nuevo encadenamiento si tenias tofo para seguir y el tpv está en wl mismo sitio, miama marca, mismo modelo, ademss es cliente y ha visto que el equipo que hay es antiguo y para éo es el misml(pero resulta que se ha xambiafo por uno reciclado). Ostias es que no sabe uno por donde le van a llover las tortas.

Nosotros tenemos en cuenta un id del disco duro para la licencia del programa. No es de ahora por el Verifactu, ya lo hacíamos desde hace años. Por eso, si un cliente cambiaba el servidor o simplemente el disco duro tenía que pedir una nueva licencia.

Y ese id de disco duro lo metimos como parte del campo número de instalación, y así podemos jugar para hacer el encadenamiento sin que nos suponga mucho cambio:

-en la tabla de los registros de facturación guardamos el campo Numero de Instalación.
-si al grabar un registro el valor que le damos a ese campo no coincide con el del último registro, es que se cambió el equipo o disco. Y por tanto tendrá que ir como primer registro.

Por si a alguien le ayuda como lo planteamos nosotros!

Otra pregunta, un nuevo numero de instalacion implicara el inicio nuevo del contador de numeradores de cada serie de facturas?. O sw puede disociar?

Entiendo que no, o al menos nosotros no lo hemos hecho!

que cambies el servidor no implica que tengas que volver a empezar a mandar las facturas desde la 1

Llevas razon, no tiene sentido.

Para cuando una sanción para cada técnico de Verifactu que dé una respuesta ambigua?


Porque no es de recibo estar así con esta gente

Tiene sentido, estoy aun insistiendo con verifactu que no me cuadra poner un nuevo numero de instalacion en el caso de poder seguir encadenando normalmente, despues pregubtntaré eso, aunque tiene sentido lo que comentas, ya me quiero aegurar todo.

Pues nada. Yo voy a consid3rar hasta las actualizaciones, van a tener reinstalacion cada mes

Pues nada. Yo voy a considerar hasta las actualizaciones, van a tener reinstalacion cada mes

Hombre, una actualización de programa no debe hacer que el siguiente registro que se envíe vaya marcado como primer registro. Reinstalación si, actualización no

Bueno, he lanzado la pregunta esta maána a ver que me dicen, por que esto me ha creado otras dudas, ya que lo que en pincipio me parecía evidente, resulta que no lo es:
-He lanzao la pregunta de si se puede continuar con las mismas series y por el número que iba, supongo que sí, pero ya aseguro.
-Y, por ejemplo, si la máquina hay que cambiarla y hay que subsanar algún/os registros de la anterior instalación ¿como se hace referencia a ese registro en el nodo sistema informático?, si ya no tienes el sif y es otro número de instalación. En la mayoria de los casos la subsanación se producirá por que el registro está tan mal que ni siuiera te lo han aceptado, pero puede ocurrir que lo hayan a aceptado y se produciria una incongruencia en la que ellos tendrias 2 registros y posiblemente duplicando venta.
Este tema me ha descuadrado la lógica del programa.

Evidentemente, puedes seguir con las mismas series. Normalmente, cuando se cambia de servidor o se formatea el disco no se pierden datos. Simplemente paras a los usuarios, mueves la base de datos y a seguir. Con lo que si hay que subsanar algo de atrás deberías tenerlo.
Otra cosa es un cliente que tenía otro programa y ahora pase al tuyo y tengas que subsanar algo de atrás que no está en tu programa. O por ejemplo si se te encriptó la base de datos y recuperas una copia de hace días (ahí si que se pierden datos). En ese caso, si es mediante facturas rectificativas, no debería haber problema.

Sí, se suppne que tanropara una subsanacion como para una rwctificativa o anulacion se puedw incluso emitoe desde otro sif/termibal generando nuneros de series distintos, o sea que parece que es corecta tu afirmacion.

Sí, se supone que tanto para una subsanacion como para una rectificativa o para una anulacion se puede incluso emitir desde otro sif/terminal refernciando a un registro emitido por otro sif, generando numeros de series distintos, o sea que parece que es correcta tu afirmacion.

Creo que el numero dr instalacion voy a hacrr lo mksmo que comentais, un timestamp y comprobacion en cada emision de factura de que el anterior regostro sea el mismo timestamp de instalación antes de encadenar, y si no o empiezo encadenamiento no o no dejo facturar hasta reiniciar los encadenamientos. Ya veré.

Es Normal que cuando se reinstale el programa tengas que empezar por el primer registro siendo un SIF Verifactu, ya que en el RRSIF dice que los SIF Verifactu no están obligados a guardar los Registros de Facturación ni los XMLs. Por este motivo si instalas de nuevo no tiene la huella anterior

Efectivamente, entonces hay que tener especial cuidadp a un par de cosas,:
'-Cuando se active el sif para verifactu o no verifactu, creo que todos tenemos claro que el primer registro generado en ese cambio no puede tenrr encadenamientos, fruto del cambio de modalidad de uso, del comienzo de uso o de pruebas anteriores. Ya que ese cambio implica haber realizado una reinstalación y por ende un nuevo numero de instalacion y reinicio de encadenamiento
-También es importante tener en cuenta que los que ponemos el timestamp(fechahora) en el nodo numeroinstalacion, éste no puede ser anterior al cambio de modalidad, por si a alguien se le habia escapado y el cambio de modalidad lo hace de una forma que no implica una reinstalacion completa, que sé que más de uno lo va a activar con una pestañita, jeje., sobee todo los que empiecen a enviar justo el día que comience la obligación, cosa que lo veo un pelin locura y se os pueden atragantar las uvas.

Este es un tema que yo tampoco entiendo muy bien y se han dicho cosas que estoy de acuerdo y otras que no, pero voy a poner mi opinión.
Un equipo informático que tiene un SIF y emite RF's, si se actualiza el programa y esta actualización sigue el encadenamiento correctamente, no está cambiando de hardware, por lo tanto debería ser el mismo número de instalación.
Si a un equipo se le cambia el disco duro e instala de cero el SIF y este puede seguir con su último registro y por consiguiente su encadenamiento, tampoco debería tener un nuevo número de instalación.
Solo se puede detectar mediante un Tracer desde sus servidores el numero de la MAC de las tarjetas de red que sí implicaría un cambio de hardware. Si no es así, no es detectable un cambio de equipo desde otro servidor ni por disco duro ni nada.
Si el SIF es capaz de seguir con su encadenamiento correctamente y no "cambia de equipo" no es detectable por nadie una actualización o reinstalación (que eso es otra, a ver que es una cosa u otra) y eliminas las posibles preguntas que se puedan hacer en la AEAT como ¿ Por que emiten tantas veces con el <PrimerRegistro= "S"> ? también veo más aconsejable no cambiar de nº de instalación.
Si se instala por primera vez o cambia de equipo, es lógico que sea un Numero de instalación distinto. Pero pongo un ejemplo de encadenamiento.
Si tenemos el siguiente escenario:
RF 1 (Primer registro sin encadenar)
RF 2 (Encadena con nº1)
RF 3 (Encadena con nº2)
Aquí se cambia de equipo e instalamos con Nº de instalación diferente y con primer registro sin registro anterior
RF 4 (Primer registro sin encadenar)
RF 5 (Encadena con nº4) y así sucesivamente...pero no hay e empezar con una nueva serie. En cualquier momento puede ser el primer registro
He tenido clientes que han querido empezar por el nº 1200 como primera factura porque han querido y es totalmente legal, como si quieres poner como primer registro en vez del 4 (que le sigue al 3) el 25 como primer registro pero veo mas lógico que sea el 4 si registro anterior y no empezar una nueva numeración con el riesgo de que se ha podido fallar en algo y emitir una factura ya emitida. Rechazo seguro.

Estoy ee acuerdo en cuanto a lo de cambiar el disco, pero lamrentablemente, despues de inisitir con el mismo argumento que dices aparte de añadir que es mas seguro seguro con el encadenamiento, me dicen nuevamente que cualquierr cambio ddñe hardware o software implica un nuevo numero de instalacion y por tanto el reinicio dd los encadenamientos.
Respecto a lss nuneraciones segun me comentab tambien y segun el ROF cada serie debe tener una nuneracion consecutiva dentro del mismo año, lo que comentas de dar un salto, creo que no es muy legal.. pero es independiente de los cambios de los numeros de instalacion, no habiendo que ni crear una serie nueva ni empezar una nueva numeracion respecto a los nuneros de facturas, otra cosa es que sean laxos con esa parte dd ls normativa.
Imagina que tu softwaretoma la nuneracion al inicio de la rutina de crear la factura, y hay varios usuarios o cambias de pantalla a otra factura, generandose antes la nunero 11 que la 10, el encadenamiento estaria correcto y verifactu, de momento, no te va a decir nada, oero y el ROF, lo cumples, tenfo dudas en este caso, pero saltos, lo veo mas grave., otra cosa que ppr la rutina que comentaba se te quedw un hueco y poster8ormente lo utilices. Ya tendriss todos los numeros, que no siendo consecutivos, lo mismo pasa bien si mo hay grandes saltos en eñ tiempo, pero es arriesgado y el inspector será el que decida ya que aunque cumplas verifactu, ahí no se acaban los posibles requerimientos/inspecciones

Yo lo del "número de instalación" no lo termino de ver ni de entender. Empezando porque dan por sentado que hay una "instalación". ¿Qué pasa con el software basado en la nube? ¿Acaso hay "instalación" ahí? ¿por qué debería haberla entonces para software de escritorio?

A mí me da que Hacienda no es consciente de toda la casuística, problemas, etc. que conlleva todo esto. Con lo fácil que sería identificar a cada OT y punto. Es un lío enorme tener en cuenta todas las cosas que pueden pasar a lo largo de un año en una empresa: reinstalación, cambio de PC, clonar disco, cambio de SIF, pérdida de datos, virus...
Y encima que seamos nosotros los que tenemos que preverlo todo.

Por no hablar de la confusión que genera la documentación, que no es nada clara. Empresas con varios equipos en red, empresas con varias tiendas pero con facturación independiente, autónomos con varios puntos de venta en la misma ciudad. No sé, cuanto más me pongo a analizarlo, menos seguro estoy.

Y ya lo de tener que distribuir un SIF para VeriFactu, distinto al SIF genérico, ya es que me cabrea. O sea, tengo que tener una instalación para la versión SII, otra para TicketBAI, otra para Sudamérica, otra para VeriFactu... Lo mismo que antes: ¿y el software en la nube, acaso se "distribuye" de forma diferente? No, es el mismo, pero cada cliente lo configura según el país en el que se encuentre.

Añado que lo que comentas ee la mac no es ninguna locura, es probable que controlen los cambios de mac y de ahí la insistencia de cambiar el numero, ya que puede ser que hayan cruzado y nos llegue una inspeccion por este tema que, a priori, parecxe una tontetia y se lo vsn a saltar casi todos, ños que estan en la nube, podran controlar
La mac/nunrro de instalacion del que realiza los envios, dd los terminales está claro que no, a no ser que requieran logs de las trazas de conexiones

Totalmente de acuerdo. Así estamos, el problema es que se echa el tiempo encima y siguen saliendo cosas y otra cosa supersubjetiva son las DR, que pueddn decir siempre que falta algo.

Correcto. Por eso insisto en seguir la numeración correlativa independientemente de si es primer registro sin encadenar o no.
Si no hay registro anterior tampoco te pueden exigir una numeración correlativa, desde mi punto de vista es incongruente, puedes empezar por la numeración que quieras no es obligatorio seguir con la numeración pero si seguir trazando desde el nuevo RF sin registro anterior. De todas formas es mas fácil hacerla correlativa desde código que empezar con un nuevo Numero de Factura a X distancia en la numeración. Por lo que insisto en el ejemplo que puse antes de encadenamiento.
Por otro lado aconsejo coger la fechahorahuso, numero Registro anterior, huella del registro anterior, es decir la creacion de huella propia en el momento de emitir la factura. Se puede confeccionar una factura larga o extensa y mientras ir emitiendo facturas que han empezado más tarde a confeccionarse pero han terminado antes.
Con respecto a cambiar de Nº de instalación, no habrá más remedio que aceptar algo incongruente desde mi punto de vista, pero ellos mandan. Eso sí que nos dará mas de un dolor de cabeza a demás que habrá que hacer una nueva declaración por cada nº de instalación y guardarla en la BD del cliente ¿no? y ¿también guardarla nosotros?

Claro!! y por eso mis conclusiones. Mientras no cambien de placa o tarjeta de red (si va independiente) no hay forma de saber que se ha reinstalado o actualizado

Otra cosa seria que en los RF´s que enviamos nos obligaran a rellenar un nodo por ejemplo de <NumeroDiscoDuro>. Estariamos hablando de otra cosa

O yo lo veo muy claro o vosotros lo veis muy oscuro... :D

¿por qué tienes que distribuir SIF distintos? Nosotros tenemos un único programa que va a permitir modo Verifactu o modo SII (no contemplamos TicketBAI ni No-Verifactu). ¿cual es el problema de eso? Se lo instalas a un cliente y lo configura para trabajar de una manera u otra. ¿por que tienes que tener varios distintos?


Ellos lo que quieren saber es cuando se reinstala un programa. Si el cliente compra un nuevo servidor, tenemos que reinstalarle el programa en ese equipo. Ahí tenemos que marcar como "Primer registro". Si se formatea o le cambiamos el disco, tenemos que reinstalar y por tanto marcar como "Primer registro". Pero si le cambiamos la tarjeta de red o el teclado o el ratón, no lo tenemos que hacer. Así al menos es como lo vemos nosotros y como lo hicimos (que a lo mejor estamos equivocados, ojo).
Otra cosa es cómo ellos pueden saber eso... si le cambio el servidor a un cliente, le copio la base de datos como la tenía y no marco nada como primer registro, ¿ellos se van a enterar? Pues posiblemente no. Pero... ¿debo marcarlo? Sí


Ellos dicen que sí, jeje. Pero si tu instalas de cero el SIF, ¿no tendrías que ponerle una nueva licencia? ¿o hacerle algo para que funcione? ¿o como lo controlas? Si en ese momento creas un Timestamp como dicen o cualquier id único ya lo tienes resuelto. Ese id lo metes dentro del campo NumeroInstalacion y ya está.

Vuelvo a insistir, igual estoy en los mundos de Yupi... yo me lié con muchos puntos del Verifactu pero este lo veo medianamente claro. Luego igual me llevo el chasco (no lo descarto :eek:)

Tal y como yo tengo organizado mi Proyecto no haría falta cambiar de Nº de instalacion si se cambia el disco duro en el mismo equipo si es el mismo OT.

Un cambio de tarjeta de red cambia la Mac, ojo.

Pero si un cliente cambia el disco duro, ¿tu tienes que hacer algo con el programa para que funcione? ¿puede haber un cambio de disco o de equipo de un cliente que tiene tu programa sin que tu te enteres?

-Si lo puede haber evidentemente no vas a poder marcar el registro como "Primer registro", porque no vas a detectar que hubo ese cambio
-Si cualquiera de esos casos requiere que tu hagas algo para que el programa funcione, ahí puedes cambiar el Nº de instalación (aunque como dices no sea necesario)

¿y cual sería el problema? es que no lo veo :confused:

Pero lo de marcar el registro como "Primer registro" solo se hace en el primer RF que se envíe ¿no? al menos es como lo tenemos nosotros, una vez generes y envies el segundo ya no volvera a mandarse como "primer registro" aunque se cambie de servidor, disco duro, etc...
El número de instalación lo tengo actualmente donde se encuentra el .exe , así que para cada SIF hay un nº de instalación, independientemente de los equipos que trabajen con el SIF, para que cambie de nº de intalación tendría que reiniciar yo el contador o que se perdiera el fichero que lo contiene.

Nosotros lo tenemos así:

en la tabla de registros de facturación que enviamos tenemos los siguientes campos, entre muchos otros:

-Factura - Huella - Huella Anterior - Nº Instalación - Nº Instalación Anterior

Entonces, hacemos algo como esto:

Factura 1 - Huella 1 - vacío - Instalación 1 - vacío
Factura 2 - Huella 2 - Huella 1 - Instalación 1 - Instalación 1
Factura 3 - Huella 3 - Huella 2 - Instalación 1 - Instalación 1

si ahora cambiamos el disco duro y por tanto cambia el número de instalación:

Factura 4 - Huella 4 - vacío - Instalación 2 - Instalación 1
Factura 5 - Huella 5 - Huella 4 - Instalación 2 - Instalación 2

A la hora de enviar los registros, si los campos "Nº Instalación" y "Nº Instalación Anterior" no tienen el mismo valor marcamos el registro como "Primer Registro" (y por tanto no lleva la huella anterior "Huella 3").

Vale, cuando cambiais de nº de instalación marcais como "primer registro". Pues eso tengo que mirarlo entonces.