Si previamente no habías mandado nada a producción lo tendrás que marcar como primer envío sino no. La verdad es que no me queda muy clara tu duda.

El marcar el primer registro no es por fecha sino el primero que envíes a producción sea en 2026 o 2025 que ya puedes hacerlo.


Saludos.

Buenas

Tienes que marcar como "primer registro" pues eso, el primer registro que envíes. Sea del 1 de enero, de hoy o de dentro de 3 meses (cuando actives Verifactu).

Pero si empiezas a enviar hoy y marcas el primer envío como "primer registro", no puedes hacer que llegue el 1 de enero y vuelva a enviar un primer registro, porque es mentira.

El único caso en que tendrías que volver a enviar otro "primer registro" es si formateas, cambias el servidor, etc. (los casos en lo que hay que cambiar el número de instalación)

Saludos

Básicamente si había/hay que volver a marcar el primer registro el 1 de Enero del 2026, aunque sean el mismo entorno.

Ok, es lo que tenía en mi cabeza pero me surgió la duda al leer el hilo, aún así tengo la consulta abierta a ver que dicen ellos.

Además de lo dicho, les he consulta si hay que marcar otra vez cuando un cliente se va al SII al año siguiente vuelve a Veri*factu.

¿Hay que cambiar el nº de instalación si formateas o cambias de servidor? para mi...sigue siendo la misma instalación, de hecho se puede dar el caso que ni te enteres de esos cambios si es el cliente el que los hace.

Sí. lo especifica en la página 9, pregunta 4 de las FAQs de empresas de desarrollo

https://www.agenciatributaria.es/sta...rolladores.pdf

Normalmente, cambiar de servidor implica cambiar/actualizar la licencia, y en ese proceso se podría cambiar el número de instalación. Si tu programa no necesita una nueva licencia ante un cambio de servidor lo vas a tener más difícil de controlar (porque precisamente puedes no enterarte)

Madre mía, se les va mucho...
De hecho, indica que si tienes varias tiendas/delegaciones cada una debe tener su nº de instalación wow!!!

Yo les mantengo la licencia que va junto con los datos.
Nada, habrá añadir un hash generado en base al hardware, no sé.

Gracias!!

Si las tiendas NO ESTAN conectadas en tiempo real con un servidor, se consideran SIF independientes, aunque sean de un mismo OT. Por tanto deben tener nº de instalación diferente, para tener encadenamientos diferentes.

Muy buenas, ahora que se acerca de nuevo el día de nuevo me asalta alguna duda. Nosotros tenemos ya clientes enviando sin problemas, pero ahora hay algunos que van a entrar pero ya dicen que hasta el 1 de Enero del 2027 no quieren enviar en firme, ya no se como quedo el tema de si el cliente puede enviar con su certificado al portar de pruebas algunas facturas para comprobar que va todo bien y luego ya el año que viene activar el envío a producción.
Otra prueba tambien seria duplicar la empresa, poner el certificado de pruebas, hacer un par de envios y luego cuando todo este ok eliminar el certificado de pruebas y la empresa.
Nose, vosotros que estais haciendo para probar aquellos clientes que son reacios y no quieren enviar hasta el primer día oficial.

Yo los beta testers los tengo con sus datos y mi certificado de pruebas, enviando al entorno de pruebas, (que para eso está creo yo) y cuando se decida que la versión es adecuada (1 mes o así) y hayamos eliminado todos los errores posibles, se hace una actualización, se importan de nuevo sus datos, se pone su certificado, su SIFId nuevo y a rular como instalación nueva, sin enviar de momento (salvo que el cliente así lo pida), eso si, se enviarán a partir del 1 de enero o 1 de julio según proceda sin preguntarle ya. No se qué opináis vosotros.

PS: De hecho mi programa no puede facturar si no tiene un certificado válido, ya se que hay algunos que opinan que eso no puede ser motivo para no facturar, pero yo como conozco a mis "clientes", los obligo del tiron a tener el certificado en regla, que si no me veo mandando incidencias de seis meses, luego a la buya cuando les llegue el inspector.....

No creo que pase nada por hacer eso pero los de la aeat dijeron expresamente que el entorno de pruebas era para desarrolladores y no para clientes finales. Yo en principio iba a hacer eso mismo y al final desistí.


Saludos.

Yo tengo tambien entendido eso, pero bueno, si se hace con algún cliente y se envian un par de facturas para comprobar que todo fluye bien no creo que haya problema, nosotros aún no lo hemos realizado pero por ver si estaba la alternativa.

En teoría el portal del empleado es para los desarrolladores, no para que cualquier empresa envíe pruebas.

Nosotros lo que hicimos en su día fue traernos bases de datos de algunos clientes (los que tenían distintas casuísticas de facturas) y las enviamos con nuestro certificado. De esta manera las pruebas las hacíamos nosotros, no el cliente. Y comprobábamos si las facturas del cliente entraban o no y que incidencias daban.

¿Y quien habla de clientes finales? :rolleyes: yo hablo de beta testers, trabajando con mi cetificado, y con datos de prueba, yo creo que no es lo mismo. No creo que con mandar un par de facturas de prueba se pueda dar por comprobado un sistema, más cuando tienen una lista del copon de errores que te puede devolver el servidor (si es que contesta, claro), hay multitud de escenarios potencialmente catastróficos que hay que probar de verdad, y si se les cae el entorno de pruebas (que el de producción ya les petó, no creais que esto se retrasó un año por problemas nuestros, sino porque con el supuesto 10% de la gente enviando el sistema se les moría cada 5 minutos) pues vaya truño de servicio que queréis que os diga, entre otras cosas tengo que probar a mandar paquetes de más de 1000 rf para comprobar que mis rutinas los cortan y mandan apropiadamente, y no una sino un buen puñado de veces, si nó que leches estamos probando (y es sólo un ejemplo). ¿Voy a tener que hacerme un programa que se invente miles de movimientos en intervalos aleatorios y montar 15 máquinas para que lo hagan simultáneamente por si hay algun problema de sincronización? Para eso ya tengo a mis beta testers que lo van a probar con esas 15 máquinas trabajando en paralelo y metiendo miles de documentos de prueba "del mundo real", que yo sepa no hay ninguna limitación a que tengas que hacer las pruebas desde una IP única ni cosas raras de estas..... no se, pero es que me parece tan de cajón, que es que no le veo sentido a hacerlo de otra manera.... y perdonad por la chapa, me ha sentado muy mal que se acaben las vacaciones:D

¿Vacaciones? ¿¿Ezo qué eh?? :D

Nosotros tambien hicimos eso al principio para ir viendo que de disitintos clientes iban pasando y así si nos saltaba algo raro podiamos ir corrigiendo.

En los primero contactos que tuve, en el entorno de pruebas te banean vaeios minuroa si mandas varios lotes grandes, eso no pasa en producción.
Ya este tema es antiguo, creo que habría que cpnsoderar que el que se quiwra saltar las reglas, aunque les parezcan absurdas, que hagan lo que les apetezca ,pero no vep bien que animen a los demás para autoconfirmar sus aptitudes sin advertir de ello.
Saludos

Si va por mi, nada más lejos de mi intención que animar a nadie a hacer nada, sólo compartía una reflexión, (aunque no entiendo lo de "autoconfirmar sus aptitudes sin advertir antes de ello") no estoy por iniciar ninguna polémica, si el moderador estima que es improcedente, por favor, que elimine mis comentarios anteriores (incluido este). Gracias!! :o

Cada uno puede hacer lo que quiera, eso por delante, pero desde la AEAT dejaron claro que ese entorno sólo era para empresas desarrolladoras. Si tus "betatester" pertenecen a tu empresa desarrolladora bien, sino... :o

Dependerá de lo "tiquismiquis" que se pongan, pero como bien habéis dicho, lo avisaron desde el principio.

Lo dicho, la AEAT no ha dicho ni betatesters, ni clientes finales, no finales o distribuidores,...
Lo que dijo fue sólo "empresas desarrolladoras".

Yo creo que es diferente, entre decir lo que hace cada uno y animar al resto.

Ha quedado claro que es una decisión personal y que la mayoría hemos entendido que es algo que no se debería hacer.