![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
|||
|
|||
|
Cita:
Solo el erroneo. Incluso si quiere puedes automatizar ese proceso de subsanacion, pero está claro que si pasa es que, normalmente, tienes algún error que debes tambien arreglar en el software. |
|
#2
|
|||
|
|||
|
Cita:
![]() |
|
#3
|
|||
|
|||
|
Cita:
Yo iguañmente hagl algo parecido a lo que comenta el compañero, aunque no paro la facturacion, no emito el doxumento xomo factura, si no como prefactura indixando en la mismade que hay una incidencia puntual y que pueden dejar un correo o venir despues por la factura, y si no tienes impresora se lo apuntan en un papel. La aeat no quieres que dejes de facturar(vender), pero ai que nada mas resolverlo se envie todo Por cierto , a mi me pasa la rotura de encadenamiento pero lo detecto antes de generar/enviar y ya se pone el sistema en modo alarma y solo emite prefacturas hasta que se arregle, pero para arreglarlo la primera opxion es semiautomatica, ya que creo que hay que esperar a um buen momento para hacerlo, y en cada nueva emision de prefacturaa advierto al usuario de que tiene que reparar Última edición por ermendalenda fecha: 15-10-2025 a las 20:52:31. |
|
#4
|
|||
|
|||
|
Cita:
Si hay una incidencia, la que sea, que precise no enviar a Veri*factu, pues no se envía; se sigue facturando, se sigue imprimiendo las facturas, SE SIGUEN GENERANDO LOS REGISTROS DE FACTURACIÓN con su fecha y hora. Y mientras se busca que ha pasado; una vez resuelto se genera el XML con los 'n' RF (máximo 1000 por cada envío creo) y se envían con el indicador de incidencia. Y se documenta TODO que cuando vengan a cobrar (siempre cobran) se pueda explicar. |
|
#5
|
|||
|
|||
|
Cita:
|
|
#6
|
|||
|
|||
|
Cita:
|
|
#7
|
|||
|
|||
|
No sé muy bien a que te refieres con error de encadenamiento, pero no tienes que parar nada ni arreglar todas las que se hicieron posteriores. Sólo tienes que arreglar la que te dio error.
Pongo un ejemplo, y así también nos dices si es el error del que hablas Factura Huella Huella Anterior 10..............A..............- 11..............B..............A 12..............C..............B Ahora supongamos que subes la factura 13 pero obtienes mal la huella anterior, y por tanto te dará error: 13..............D..............X -> debería ser C, pero mandé X y devuelve error de huella Ahora sigues haciendo más facturas, sin error 14..............E..............D 15..............F..............E 16..............G..............F Cuando quieras corregir la factura 13 (aunque sea una semana después), tendrás que crear otro registro de facturación (una subsanación) y debe ser algo como esto: 13..............H..............G -> ahora ya va a entrar correcta Como ves, no hay que corregir más que la que te dio error, las otras entraron correctas. No sé si me expliqué bien o si es el error del que hablas Última edición por Jarogo08 fecha: 16-10-2025 a las 10:02:46. |
|
#8
|
|||
|
|||
|
Yo creo que el problema es mucho más gordo.
Hacienda contempla casos que no dependen de nosotros: caída de internet, hardware estropeado, cliente que devuelve lo que sea, el usuario que se equivoca de NIF, de % IVA, que el sistema de hacienda esté caído, ... Pero no contempla que el software tenga errores y más aun cuando emitimos una declaración responsable de que hace lo que debe hacer; que si, que los ficheros se corrompen y todo lo demás Yo intentaré evitar ese marrón de huellas incorrectas de la siguiente manera: -Cuando creo el XML en ese momento cojo el RF que voy a enviar, busco su anterior (último tratado/enviado), genero la huella y la GUARDO (sólo guardo la última). -En el siguiente registro hago lo mismo y además comparo la huella generada con la que tengo guardada, si coinciden sigo generando el XML y guardo la nueva última huella -Si no coinciden permito que el SIF haga su tarea, que genere registros RF y busco el error, cuando lo soluciono envío los registros pendientes indicando valor en el campo 'incidencia'. Es que no sé que es peor, enviar el XML 5 horas / 2 días más tarde o enviar una cadena de registros en donde se ha roto la trazabilidad de las operaciones, o no tomar medidas para evitar el error. Al final cobraran, como siempre. |
|
#9
|
|||
|
|||
|
Cita:
Sí, es exactamente el error al que me refiero, y lo has explicado muy bien. Efectivamente con la huella H subsanamos la factura 13, y la huella anterior será la G, ya que lo encadenamos siempre al último registro. La verdad es que visto así, gráficamente, aparece mucho más claro, podemos ir hacia atrás desde la cadena H a la D verificando el encadenamiento, y este estará correcto, hasta llegar a la D, que seguirá mal en ese punto, pero se arregla posteriormente en la H, o si ponemos una columna más para los números de registro, el registro 17, factura 13, huella H. Con una sola subsanación se arreglaría el encadenamiento. De hecho no podría corregir el registro 14, factura 14, porque me daría exactamente la misma huella, ya que la corrección se hace posteriormente., y está encadenada correctamente con su registro anterior. Gracias Jarogo08 por el ejemplo, me ha clarificado las cosas. |
|
#10
|
|||
|
|||
|
Cita:
A raiz de este hilo pongo otro posible caso, que por lo que he visto en las exposiciones de algunos mensajes ed usuarios, se va a dar a menudo, a ver que pensais si es correcto: -Se envia un registro con el nif incorrecto y lo rechazan -Siguiente factura es correcta y la envio -Si no me equivoco es aceptada con errores por que no encuentran el anterior encadenamiento que yo lo tengo pero me han rechazado, y por redondear más se ha enviado en el mismo lote que la anterior y no pude ni detectarlo para, si lo tengo controlado, proceder a la subsanación inmediata/automática, me he liado bastante. -Con lo cual, también supongo: HAY QUE HACER 2 SUBANACIONES Me respondo a mi mismo: No hay devuelta de errores de encadenamiento, solo de la huella mal calculada y por tanto solo hay que subsanar/rectificar el del nif incorrecto Última edición por ermendalenda fecha: 16-10-2025 a las 13:18:15. |
|
#11
|
||||
|
||||
|
Yo no tengo muy claro eso de comprobar que se ha hecho un envío correcto y en caso contrario pararlo todo porque, efectivamente, puede ser un problema. Por otro lado creo que no han puesto plazo para las subsanaciones/rectificaciones así que yo en particular lo que hago es un proceso que cuando se quiere revisa los envíos para manejar las devoluciones.
__________________
Be water my friend. |
|
#12
|
|||
|
|||
|
Cita:
|
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Poligono con posicion incorrecta dentro del canvas | el-mono | FireMonkey | 2 | 10-03-2015 14:49:31 |
| Impresion incorrecta | Rolando Glez | Impresión | 3 | 14-09-2012 22:50:11 |
| Logica incorrecta en Consulta SQL | DANY | SQL | 0 | 14-12-2007 04:48:46 |
| Seleccion incorrecta de registros Con Codigo SQL!! | jmedina | SQL | 8 | 13-12-2004 19:36:52 |
| Exportacion a Excel incorrecta | jfloro | Servers | 4 | 19-09-2003 09:48:36 |
|