Preproducción en empresas reales

[ermendalenda]

Empezado por Jarogo08

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 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.

[ermendalenda]

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é.

[RUBEN_SP]

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

[ermendalenda]

Empezado por RUBEN_SP

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.

[Rja750]

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.

[ermendalenda]

Empezado por Rja750

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

[espinete]

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.

[ermendalenda]

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

[ermendalenda]

Empezado por espinete

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.

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.

[Rja750]

Empezado por ermendalenda

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

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?

[Rja750]

Empezado por ermendalenda

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

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

[Rja750]

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

[Jarogo08]

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

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.

¿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?

Añado que lo que comentas ee la mac no es ninguna locura, es probable que controlen los cambios de mac

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í

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.

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 )

[Rja750]

Empezado por Jarogo08

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á.

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.

[ermendalenda]

Empezado por Jarogo08

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



¿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 )

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

[Jarogo08]

Empezado por Rja750

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.

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)

[Jarogo08]

Empezado por ermendalenda

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

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

[Faneka]

Empezado por Jarogo08

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)

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.

[Jarogo08]

Empezado por Faneka

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").

[Faneka]

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