![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
#241
|
||||
|
||||
|
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.
__________________
La religión es personal e intransferible. |
|
#242
|
||||
|
||||
|
Cita:
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.
__________________
Be water my friend. |
|
#243
|
|||
|
|||
|
Cita:
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 |
|
#244
|
|||
|
|||
|
Básicamente si había/hay que volver a marcar el primer registro el 1 de Enero del 2026, aunque sean el mismo entorno.
|
|
#245
|
|||
|
|||
|
Cita:
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. |
|
#246
|
|||
|
|||
|
Cita:
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) |
|
#247
|
|||
|
|||
|
Cita:
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!! |
|
#248
|
|||
|
|||
|
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.
|
|
#249
|
|||
|
|||
|
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. |
|
#250
|
|||
|
|||
|
Cita:
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..... |
|
#251
|
||||
|
||||
|
Cita:
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.
__________________
Be water my friend. |
|
#252
|
|||
|
|||
|
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.
|
|
#253
|
|||
|
|||
|
Cita:
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. Última edición por Jarogo08 fecha: Hace 8 Horas a las 11:30:17. |
|
#254
|
|||
|
|||
|
Cita:
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![]() |
|
#255
|
||||
|
||||
|
Cita:
¿Vacaciones? ¿¿Ezo qué eh?? ![]()
__________________
Be water my friend. |
|
#256
|
|||
|
|||
|
Cita:
|
|
#257
|
|||
|
|||
|
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 |
![]() |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Cambio de Preproducción a Producción | novatico | General/Noticias | 207 | 08-07-2025 18:37:22 |
| Acceso a preproducción | Ja Mon | Envío de registros y sus respuestas | 9 | 27-01-2025 10:00:14 |
| Apertura de servicios en PREPRODUCCION | bmfranky | General/Noticias | 21 | 04-12-2024 10:18:27 |
| Privacidad en las empresas | FDB | Seguridad | 11 | 14-03-2012 23:41:58 |
| Listado de empresas | DarKraZY | La Taberna | 0 | 10-11-2006 15:16:50 |
|