![]() |
![]() |
| 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
|
||||
|
||||
|
Tienes que cambiar el "chip" y diferenciar entre registro de facturación y factura. A mi también me costó entenderlo al principio.
Lo que se encadenan son los registros de facturación, no las facturas. Un registro de facturación pertenece a una única factura, pero una factura puede tener X registros de facturación, según las veces que se haya enviado hasta que te dé respuesta correcta. Normalmente será 1 registro de facturación por factura. Tu tienes que encadenar los registros de facturación. RF1 - Factura 1 - (sin encadenamiento). Ok. RF2 - Factura 2 - RF1. Error RF3 - Factura 3 - RF2. Ok. RF4 - Mod. Factura 2 - RF3. Ok. RF5 - Anul. Factura 1 - RF4. Ok. RF6 - Factura 4 - RF5 etc, etc. |
|
#2
|
|||
|
|||
|
Si, si lo entiendo!!!
Pero lo que no me queda claro es ese "vacio" en la trazabilidad que tendrá AEAT respecto a las facturas que "realmente" reciban, pues habrá huellas que no seguiran la trazabilidad de Registros enviados. ¿Como podrán saber que la "trazabilidad" es "honerosa", que no hay "manipulación" de datos y que no hay "alterabilidad" entre nuestros registros de facturación y los suyos??? Ahí es donde quiero llegar. Entiendo lo que leo y veo que es de esa manera, pero no "comprendo" el tener que nosotros guardar una trazabilidad de RF cuando segun VERIFACTU, la trazabilidad no corre por nuestra cuenta, sinó que son ellos los que van a garantizar la trazabilidad, salvaguarda, custodia, etc... Nuestra responsabilidad ¿donde finaliza con un sitema VERIFACTU??? |
|
#3
|
||||
|
||||
|
Hombre, para poder encadenar correctamente los registros de facturación, tendrás que guardarlos en alguna tabla de tu base de datos, porque sin los datos del anterior registro de facturación no puedes encadenar el siguiente. Si tu no guardas esa trazabilidad, no veo cómo vas a poder encadenarlos.
|
|
#4
|
|||
|
|||
|
Hombre, eso si!!!. Tengo una tabla de RF, donde guardo el xmlsaliente, xmlrespuesta, factura, fecha, huella...
De ahí que obtengo la trazabilidad "MIA" y que 'debería' de cuadrar con la de AEAT, pero como en esa tabla voy guardando TODOS los registros, aceptados, con errores, rechazados... TODOS tienen una huella y trazabilidad, como digo "la mia"... pero como bien digo, no se va a corresponder con la de AEAT, dado que los registros "rechazados" no estan disponibles en AEAT. No se si me explico. |
|
#5
|
||||
|
||||
|
Te explicas, pero yo creo que lo que hacienda te rechaza es la factura, no el registro de facturación, con lo cual, es consciente del encadenamiento del registro correspondiente. Yo al menos, en todos aquellas facturas rechazadas hasta el momento en pruebas no he tenido rechazo por encadenamiento, excepto al principio durante las primeras pruebas, como es lógico. Luego las envío modificadas / subsanadas con el nuevo encadenamiento del registro de facturación y listo.
|
|
#6
|
|||
|
|||
|
He hecho comprobaciones de enviar registros "Alta" con huella anterior que pertenece a un registro anterior rechazado y Ok.
He hecho comprovaciones de enviar registros "Alta" con huella anterior que pertenece a la anterior PERO que haya sido aceptado o aceptadoconerrores, y también "traga" Ok. Por lo que de ahí mis dudas e inquietudes. No tengo problema por guardar en mi RF todos los registros, pero lo que no me entra en la cabeza es el huellaanterior que deba pertenecer a mi último RF o al último RF aceptado o aceptadocon errores, pues ese va a ser el SUYO que van a tener. De las 2 formas la respuesta es OK, solo que no veo una trazabilidad por parte de AEAT que la puedan exigir por nuestra parte, cuando esa trazabilidad no es por nuestra parte, sinó que al ser VERIFACTU, compete a ellos. Solo eso. Luego ya entraremos en como subsanar, rectificar... pero de momento estoy con lo de envios Alta nuevo registro... Gracias por vuestro tiempo. |
|
#7
|
|||
|
|||
|
Cita:
Cita:
Imagino que también tendrán sistemas para controlarlo sin hacer inspección. Por ejemplo: El usuario crea una factura (se crea su registro de facturación), luego se envía y suponemos que se rechaza. AEAT no tiene ese registro de facturación. El usuario debe hacer alguna cosa fara informar esa factura. Puede subsanar o rectificar (dependiendo del caso) 1 Si subsana el registro de facturación, crea otro registro de facturación de la misma factura e indica rechazo previo. Se envía y se acepta. AEAT sabe que se rechazo un registro anterior y puede "entender" el motivo de la falta de un registro en la cadena (de los que tienen ellos). 2 Si hace una rectificativa (es una nueva factura y se crea su registro de facturación indicando que rectifica a otra factura) . Se envía y se acepta. AEAT sabe que hay una factura anterior (y por lo tanto también su registro de facturación) que no la tiene AEAT y puede "entender" el motivo de la falta de un registro en la cadena (de los que tienen ellos). Saludos |
|
#8
|
|||
|
|||
|
Hola YellowStone..
Tu respuesta es mas que clara y al menos a mi me ha ayudado a terminar de convencerme de que lo entendía bien, porque la verdad que tambien me ha costado. Me pregunto si esto sería correcto, entiendo que si, por si se da este caso, me apoyo en tu ejemplo. RF1 - Factura 1 - (sin encadenamiento). Ok. RF2 - Factura 2 - RF1. Error Pero ahora me doy cuenta del error, subsano y mando de nuevo la factura 2, esto me genera el Registro de facturación 3 y cojo la huella del Registro anterior que curiosamente es de la misma factura. RF3 - Factura 2 - RF2. Error Pero como me vuelve a dar error, subsano y mando de nuevo la factura 2, esto me genera el Registro de facturación 4 y cojo la huella del registro anterior que curiosamente vuelve a ser de la misma factura. RF4 - Factura 2 - RF3. Error. nuevamente Sigo facturando. RF5 - Factura 3 - RF4. Ok. Ahora modifico el dato incorrecto de la factura 2 que había dado error y envio, esto genera el registro de facturación 6 RF6 - Mod. Factura 2 - RF5. Ok. RF7 - Anul. Factura 1 - RF6. Ok. RF8 - Factura 4 - RF7 ... ... Gracias a todos... |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Error 2004 - FechaHoraGenRegistro Exento De Subsanacion | bmfranky | Errores (relacionados con al AEAT) | 3 | 05-12-2024 13:36:39 |
| Error 3002 en subsanacion | ermendalenda | Errores (relacionados con al AEAT) | 5 | 14-11-2024 10:59:55 |
| Error "la llamada fue rechazada por el destinatario" usando OLE Object | Soa Pelaez | Varios | 2 | 23-01-2018 17:24:55 |
| Ayuda para solventar un error de diseño | Willo | Varios | 5 | 29-04-2012 21:57:37 |
| Conexión rechazada por Oracle Data Base | winzo | Oracle | 0 | 28-02-2012 04:11:57 |
|