|
|
 |
 |
|
FTP | |
|
CCD | |
|
Buscar | |
|
Trucos | |
|
Trabajo | |
|
Foros | |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
 |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
#41
Hace 4 Semanas
|
|||
|
|||
|
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. 
|
|
#42
Hace 4 Semanas
|
||||
|
||||
|
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.
|
|
#43
Hace 4 Semanas
|
|||
|
|||
|
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.
|
|
#44
Hace 4 Semanas
|
|||
|
|||
|
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
|
|
#45
Hace 4 Semanas
|
|||
|
|||
|
Podría alguien, por favor, decirme la forma de proceder con uno de las posibles causas de rechazo más habituales, que son las que me preocupan a priori?
Ejemplo: se genera/envía una factura pero el cliente (o el software) se equivoca en la ClaveRegimen y CalificacionOperacion, por el motivo que sea, indicando dos opciones que se contradicen entre sí. Hacienda rechaza la factura, indicando que "no se puede indicar X si se indica Y", o lo que sea. Bien. ¿Qué se debe hacer en este caso? 1) Subsanación con RechazoPrevio = S 2) Subsanación con RechazoPrevio = X 3) Rectificativa y punto He probado con la opción 1, me devuelve Hacienda el Error 3002: No existe el registro de facturación Con la opción 2 me la acepta, una vez corrijo la ClaveRegimen y CalificacionOperacion, pero no sé si es lo correcto Con rectificativa no sé si es correcto, porque no sé si se puede rectificar una factura que Hacienda ha rechazado (por lo que no tiene constancia de que exista) Es que por más que leo, algunos dicen que no se debería subsanar casi nunca, y otros dicen que hay cosas que sí se deben subsanar, y ya me estoy volviendo loco. Es un lío tener que preparar el software para tantas condiciones: si es rechazada completa, si fue aceptada pero con errores, luego depende de qué error exactamente, porque unos sí pero otros no...
|
|
#47
Hace 3 Semanas
|
|||
|
|||
|
No es la forma correcta.
Cita:
Última edición por Franche fecha: Hace 3 Semanas a las 16:33:03.
|
|
#48
Hace 3 Semanas
|
|||
|
|||
|
Cita:
|
|
#49
Hace 3 Semanas
|
|||
|
|||
|
Os adjunto la documentación que CHATGPT en un analisis en profundidad ha hecho.
RESUMIENDO: La factura que falle, se debe reenviar con el nuevo HASH generado, pero llevará la HUELLA DEL ANTERIOR.
Pensarás que esta factura, pierde el enlace con la siguiente, y es cierto, pero esto se informa a hacienda, indicando en este segundo envio: -> Tipo de registro” sustitutivo y marcando el indicador de subsanación de error a “S” (Sí) TODA LA CUESTIÓN AMPLIADA: (DUDA y resputa de chatgpt con un INVESTIGACIÓN en profundidad: Eso que se tira 20 minutos. ) En el sistema de envio de facturas VERIFACTU que se implementará proximamente en españa, hay un envio de facturas ENLAZADAS. Cada una se enlaza con la anterior, medienate un hash, que incluye la factura anterior, incluido su hash y la fecha y hora de envio. Creo ver un problema cuando se hace un envio maximo de facturas. Se que máximo son 1000, pero si una de ellas es rechazada, como puede ser que quede todo bien enlazado. En un envio de 5 facturas, si falla la segunda, la tercera, apuntará a la segunda, pero esta factura numero 2 ha podido ser rechazada, por lo que habrá que volver a enviarla correctamente y por tanto su hash sería modificado, lo cual afecta a todas las siguientes, que sí que fueron registradas. Necesito que me expliques con claridad como se hace este encadenamiento de facturas y como se soluciona este problema o como lo tiene en cuenta la hacienda de españa (AEAT). sOY UN informatico que está desarrollando el sistema de envio de facturas. ChatGPT Plus ¿Podrías confirmar si estás buscando una explicación técnica y actualizada del mecanismo de encadenamiento de facturas en el sistema VERI*FACTU de la AEAT, en especial cómo se gestiona el caso de errores o rechazos en facturas intermedias dentro de un lote (hasta 1000 facturas)? ¿Quieres que profundice en documentación oficial y fuentes técnicas de la AEAT sobre este aspecto? Tú dijiste: sÍ. ChatGPT Plus Perfecto. Voy a investigar cómo funciona exactamente el encadenamiento de facturas en el sistema VERI*FACTU de la AEAT, incluyendo cómo se maneja el caso de errores o rechazos en envíos de lotes de facturas enlazadas (por ejemplo, si una factura intermedia es rechazada y su hash cambia al reenviarse). También revisaré cómo la AEAT espera que se manejen estos escenarios desde el punto de vista del desarrollador. Research completed in 14m· 19 fuentes Encadenamiento de facturas en VERI*FACTU: funcionamiento técnico Introducción VERI*FACTU es el sistema de la Agencia Tributaria Española (AEAT) para garantizar la integridad y trazabilidad de las facturas emitidas mediante encadenamiento criptográfico de los registros de facturación. Cada factura generada por un Sistema Informático de Facturación (SIF) lleva asociada una huella hash única, calculada a partir de sus datos esenciales, que sirve como “fingerprint” digital SEDE.AGENCIATRIBUTARIA.GOB.ES . Esta huella se incluye en la siguiente factura emitida, creando una cadena inalterable: cualquier modificación de una factura alteraría su hash y ya no coincidiría con el incluido en la factura siguiente, evidenciando la manipulación. A continuación, se detalla cómo se construye técnicamente esta huella encadenada y cómo se maneja la consistencia de la cadena en envíos por lotes (hasta 1000 facturas a la vez) incluso si alguna factura intermedia es rechazada por la AEAT. Cálculo de la huella criptográfica de una factura ¿Qué es la “huella” (hash) de un registro de facturación? En VERI*FACTU, la huella es un resumen criptográfico SHA-256 aplicado a ciertos datos clave del registro de la factura SEDE.AGENCIATRIBUTARIA.GOB.ES . Se calcula solo sobre campos específicos de la factura, no sobre la totalidad del documento. Esto produce un código de 256 bits (generalmente representado en 64 caracteres hexadecimales) único para esos datos; incluso el cambio mínimo en la información original produciría una huella completamente diferente SEDE.AGENCIATRIBUTARIA.GOB.ES . La huella actúa como identificador único inmutable de la factura dentro del sistema. Datos incluidos en el cálculo del hash: Para las facturas de emisión (registro de alta), la AEAT define un conjunto concreto de campos que se concatenan para calcular la huella AGENCIATRIBUTARIA.ES . Los principales campos incluidos (en este orden) son: NIF del emisor de la factura (IDEmisorFactura). Serie y número de la factura (NumSerieFactura). Fecha de expedición de la factura (FechaExpedicionFactura). Tipo de factura (TipoFactura, por ejemplo F1 para factura completa). Cuota total del impuesto (CuotaTotal, suma de las cuotas de IVA/IGIC). Importe total de la factura (ImporteTotal, con impuestos). Huella del registro anterior (Huella del Encadenamiento del registro previo). Fecha y hora de generación del registro (FechaHoraHusoGenRegistro, con zona horaria). Estos campos se extraen del fichero XML de la factura y se unen en una sola cadena de texto con el formato nombreCampo=valorCampo separados por &, siguiendo exactamente el orden indicado por la AEAT AGENCIATRIBUTARIA.ES . El nombre de cada campo es literal (según el esquema XML) y el valor es el dato correspondiente tal cual figura en la factura, aplicando solo normalizaciones menores (trim de espacios en extremos y uniformidad de decimales) AGENCIATRIBUTARIA.ES AGENCIATRIBUTARIA.ES . Por ejemplo, si <NumSerieFactura> 12345678 / G33 </NumSerieFactura>, en la cadena se añade NumSerieFactura=12345678 / G33 AGENCIATRIBUTARIA.ES . Si un campo numérico como <ImporteTotal>123.1</ImporteTotal> se informa con un decimal, se considera equivalente a 123.10 a efectos del hash (es decir, los ceros finales no alteran el resultado) AGENCIATRIBUTARIA.ES . En caso de que algún campo no tenga valor (o no aplique), igualmente se incluye su nombre seguido de =, pero sin ningún valor detrás AGENCIATRIBUTARIA.ES . Una vez construida esta cadena de entrada (codificada en UTF-8), se le aplica el algoritmo SHA-256 para obtener la huella final SEDE.AGENCIATRIBUTARIA.GOB.ES . Esa huella (el hash resultante, normalmente expresado en hexadecimal) se almacena como un campo más dentro del propio registro de la factura en el SIF y en el envío a AEAT SEDE.AGENCIATRIBUTARIA.GOB.ES . Encadenamiento de facturas mediante hash Inclusión de la huella previa en la siguiente factura: El sistema VERI*FACTU implementa la trazabilidad obligatoria encadenando cada registro de factura con el anterior. En la práctica, esto significa que cada nueva factura incorpora en sus datos la huella hash de la factura anterior, antes de calcular su propia huella SEDE.AGENCIATRIBUTARIA.GOB.ES . Como vimos, el campo Huella forma parte de los datos de entrada del hash; para la factura n, ese campo contendrá el hash calculado de la factura n-1. De este modo, al calcular la huella de la factura n, en el cómputo ya está entrelazado el identificador criptográfico de la factura previa. Esta “cadena” de hashes asegura que las facturas queden secuencialmente ligadas: si alguien alterara una factura anterior (por ejemplo, para eliminar ventas), cambiaría su hash y ya no coincidiría con el valor almacenado en la siguiente factura, rompiendo la cadena y delatando la manipulación. Factura inicial de la cadena: En cada sistema o serie de facturación habrá un primer registro (p.ej. la primera factura tras implementar VERI*FACTU o tras iniciar el año) que no tiene una factura previa. En ese caso, el campo de huella anterior se envía vacío. Por ejemplo, la primera factura de un SIF tendría en la cadena de entrada algo como ...&ImporteTotal=123.45&Huella=&FechaHoraHusoGenRegistro=01-01-2024T10:00:00+01:00 (obsérvese Huella= vacío) AGENCIATRIBUTARIA.ES . La AEAT permite ese valor en blanco para iniciar el encadenamiento. A partir de ahí, cada registro de factura de alta incluirá siempre la huella calculada del registro inmediatamente anterior en el tiempo. Es importante destacar que el encadenamiento se realiza independientemente de la numeración de factura o la serie – lo que cuenta es el orden temporal de generación de los registros ESCURA.COM . En otras palabras, el hash de encadenamiento siempre se refiere al último registro de facturación generado previamente por el SIF (en ese mismo sistema o cadena), garantizando una secuencia cronológica consistente. La AEAT verifica en cada envío la coherencia de la huella encadenada: recalcula internamente el hash de cada registro recibido y comprueba que coincide con el valor informado, y que el hash declarado como “anterior” coincide con la huella de la última factura aceptada previamente para ese emisor SEDE.AGENCIATRIBUTARIA.GOB.ES . Si hubiera discrepancias (hash mal calculado, o referencia a una huella anterior que no concuerda), el registro sería rechazado por inconsistencia. Gracias a este mecanismo, mientras el SIF calcule correctamente las huellas y envíe la anterior en cada nueva factura, se asegura una trazabilidad robusta — cada factura queda encadenada a la siguiente de forma que no se puedan omitir ni falsificar registros sin ser detectados. Envío por lotes y gestión de rechazos Envío de facturas en lote: La plataforma VERI*FACTU soporta el envío electrónico de registros de facturación tanto de uno en uno como en lotes de hasta 1000 facturas por solicitud (siempre que correspondan al mismo obligado tributario). En un envío por lote, el SIF agrupa hasta mil registros (cada uno con su propia huella encadenada) y los remite conjuntamente. La AEAT procesa cada registro individualmente dentro del lote, respondiendo para cada factura si fue aceptada o si contiene errores. Importante: aunque se envíen juntas, todas las facturas del lote deben pertenecer a la misma cadena temporal (i.e. al mismo SIF o serie que lleva el encadenamiento correspondiente) para mantener la lógica de la huella anterior. La secuencia de hashes en el lote continúa la cadena: por ejemplo, si el último registro enviado anteriormente tenía la huella H<sub>prev</sub>, la primera factura del nuevo lote llevará Huella=H<sub>prev</sub>; luego la segunda factura del lote tomará la huella de la primera, y así sucesivamente. En resumen, el lote no rompe la secuencia, solo agrupa varios eslabones consecutivos de la cadena para enviarlos de una vez. Rechazo de una factura intermedia: Puede ocurrir que, al enviar un lote, alguna factura dentro de él sea incorrecta (p.*ej. datos obligatorios erróneos, NIF inválido, cálculo de hash mal formado, duplicidad, etc.) y la AEAT la rechace, mientras que otras facturas del mismo lote son válidas. ¿Qué sucede con la cadena en este caso? Según aclara la AEAT, no se rechaza el lote completo si el resto de registros están correctos, solo se rechaza la(s) factura(s) individual(es) con error ESCURA.COM . Las facturas anteriores al registro rechazado ya habrán sido aceptadas normalmente, y las posteriores también pueden ser aceptadas (la respuesta del servicio indicará aceptación parcial del lote). Esto implica que facturas posteriores en el lote pudieron referenciar en su campo Huella a un registro que, en esa primera instancia, no fue admitido. A priori parecería que la cadena queda rota; sin embargo, la trazabilidad no se compromete, porque el encadenamiento se rige por el orden de generación de los registros, no por la secuencia numérica de las facturas ESCURA.COM . Es decir, aunque una factura del medio fuese rechazada en el envío, en la cronología del SIF esa factura existió (se generó con cierta fecha/hora) y las siguientes se encadenaron a ella en aquel momento. La AEAT conserva esa referencia temporal de encadenamiento. Subsanación (reenvío) de la factura rechazada: Dado que un registro rechazado no puede alterarse ni “borrarse” (no se puede simplemente corregir el mismo envío erróneo), la solución es emitir un nuevo registro de facturación para esa misma factura con los datos corregidos, manteniendo su lugar en la secuencia temporal. La AEAT ha dispuesto un mecanismo de sustitución para estos casos: el nuevo registro de la factura debe enviarse indicando un “Tipo de registro” sustitutivo y marcando el indicador de subsanación de error a “S” (Sí) ESCURA.COM . Con esta etiqueta, se deja claro que este envío corrige a un registro anterior que falló. En la práctica, el SIF generará un nuevo XML de esa factura (con la corrección necesaria, por ejemplo corregir un importe mal puesto) pero manteniendo los datos de identificación (misma serie/número, fecha de expedición original, etc.), y muy importante: conservará la referencia hash al registro previo de la cadena. De ese modo, al recalcular la huella para la factura subsanada, quedará nuevamente encadenada correctamente entre la anterior y la siguiente. Mantenimiento de la consistencia de la cadena: Gracias al procedimiento anterior, la consistencia del encadenamiento queda asegurada. Retomando el ejemplo, supongamos un lote con cuatro facturas (F1, F2, F3, F4) encadenadas: F1 no tiene huella anterior; F2 incluye la huella de F1; F3 incluye la huella de F2; F4 incluye la huella de F3. Si F3 es rechazada por un error, las facturas F1, F2 y F4 resultan aceptadas en ese envío inicial (F4 fue aceptada a pesar de contener la huella de F3) ESCURA.COM . Ahora el desarrollador del SIF corrige F3 y la reenvía como sustitutiva. Esta Factura 3 (corregida) llevará el indicador de subsanación y tomará como huella anterior la de F2 (es decir, se inserta en la cadena después de F2, como originalmente debía). Al calcularse su nueva huella H3', es posible que H3' difiera de la huella original H3 (porque cambiaron datos para corregir el error). Sin embargo, la factura F4 que ya fue aceptada mantiene en AEAT la referencia a H3 (la huella original de F3). ¿Está entonces rota la cadena? Desde el punto de vista de la trazabilidad temporal, no: internamente la AEAT vincula los registros por su secuencia de generación y sabe que la F3 original fue sustituida por F3 corregida. La “brecha” queda cerrada con la nueva F3 sustitutiva, y la cadena cronológica de hashes (F1 → F2 → F3' → F4) permanece íntegra. En otras palabras, la trazabilidad se mantiene porque está ligada al orden en que se generaron los registros de facturación, no estrictamente a la secuencia numérica de las facturas físicas ESCURA.COM . Desde la perspectiva del sistema, las facturas posteriores no necesitan reenviarse ni modificarse, ya que sus registros eran válidos. La AEAT simplemente actualiza la cadena insertando el nuevo registro subsanado en la posición correspondiente. Gracias a esto, una vez aceptada la factura corregida, la empresa tendrá sus cuatro facturas F1–F4 registradas correctamente y encadenadas en el orden debido, cumpliendo los requisitos de VERI*FACTU. Conclusiones El encadenamiento de facturas en VERI*FACTU se logra incorporando el hash de la factura previa en cada nuevo registro y calculando un SHA-256 sobre los campos clave, lo que garantiza que cada factura quede criptográficamente vinculada a la anterior. Este diseño aporta una alta seguridad: cualquier alteración rompe la cadena de hashes y puede ser detectada por la AEAT. En escenarios prácticos de envío masivo (por lotes), el sistema está preparado para preservar la consistencia incluso si alguna factura es rechazada: solo ese registro erróneo se subsana con un nuevo envío (marcado adecuadamente como sustitución), sin invalidar ni reprocesar el resto del lote ESCURA.COM ESCURA.COM . En resumen, la trazabilidad de la cadena de facturas se asegura manteniendo el orden temporal de los registros y encadenando sus huellas, de modo que el historial de facturación queda íntegro y verificado de extremo a extremo. Referencias: La información técnica aquí presentada se basa en la documentación oficial de la AEAT (FAQs de VERIFACTU, especificaciones técnicas de cálculo de huella AGENCIATRIBUTARIA.ES SEDE.AGENCIATRIBUTARIA.GOB.ES ) y aclaraciones de sus expertos en foros y seminarios recientes ESCURA.COM ESCURA.COM , garantizando que los detalles reflejen fielmente el funcionamiento previsto del sistema VERIFACTU. Fuentes Tú dijiste: en el ejemplo que me dices, la factura F3 debe ser enviada por segunda vez, indicando Tipo de registro” sustitutivo y marcando el indicador de subsanación de error a “S” (Sí) Perfecto, pero la duda es que se envia con el nuevo hash acorde al nuevo timestamp o se envia el primer hash que se generó. En caso de generar el nuevo hash, ¿como saba la factura F4 el hash anterior si esta ha cambiado en el segundo envio? ChatGPT Plus He encontrado la información que necesitas. 🔑 Respuesta técnica a tu pregunta: Cuando envías una factura corregida (F3 en tu ejemplo), debes seguir el siguiente procedimiento: Generación de un nuevo hash: Al reenviar F3 con el tipo de registro sustitutivo y el indicador de subsanación de error a “S” (Sí), debes generar un nuevo hash. Este nuevo hash se genera con los datos corregidos y con la nueva fecha y hora de generación (timestamp). Encadenamiento con la factura anterior (F2): Al generar el nuevo hash de F3, debes incluir como HuellaAnterior el hash de la factura F2, que ya fue aceptada previamente. Es decir, el hash nuevo de F3 no hace referencia al hash antiguo de la F3 errónea, sino que se enlaza directamente con el hash de F2. ¿Qué pasa con F4 (ya aceptada) que apuntaba al hash anterior de F3?: Aquí está la clave: F4 NO se ve afectada. Aunque F4 apuntaba al hash incorrecto de F3 (el original que fue rechazado), en el sistema de la AEAT queda registrado que F3 ha sido corregida. La AEAT mantiene la consistencia de la cadena mediante la cronología de envíos, y la nueva F3 se inserta en la secuencia como válida. El hash de F4 no se modifica, pero el sistema de la AEAT sabe que existe un registro sustitutivo válido para F3. Conclusión: Al reenviar F3, creas un nuevo hash basado en los datos corregidos y la nueva fecha/hora. F4 sigue apuntando al hash antiguo de F3, pero la AEAT permite esto porque la subsanación se registra como una corrección oficial. No es necesario reenviar F4 ni modificar su hash.
|
|
#50
Hace 3 Semanas
|
||||
|
||||
|
Cita:
Cita:
__________________
Uno se alegra de ser útil. (Isaac Asimov) Última edición por bmfranky fecha: Hace 3 Semanas a las 17:01:24. Razón: Aclaracion
|
|
#51
Hace 3 Semanas
|
|||
|
|||
|
Nada de insertar
Siempre encolar. Ya esa pregunta se ha respondido en ocasiones y se ha realizado consultas a verifactu. El chatgpt, al menos, para los aspectos técnicos mete mucho la pata, nos puede dar una idea pero falla más que una escopeta de feria.
|
|
#52
Hace 3 Semanas
|
|||
|
|||
|
Pienso que cuando mandamos un registro de facturación de una factura emitida y rechazada, es decir no existe en la AEAT, solo se puede subsanar así: "Subsanación con RechazoPrevio = X" porque todo lo que queramos hacer sobre un registro de factura que no existe ya sea una anulación o rectificativa nos devolverá el Error 3002: No existe el registro de facturación.
Para que sea rechazada totalmente y no haya registro puede ser porque no cumple el esquema XML o algo parecido pero estructural. Si los RF que enviamos devuelven un incorrecto, o aceptado con errores debería aplicarse la Rectificativa del tirón y aunque el numero de esa rectificativa sea una serie diferente, es un registro de factura(no una factura) y será el último Registro de facturación, nuestro próximo "RegistroAnterior" que lo necesitaremos para seguir encadenando el próximo 'registro de factura' de la próxima factura ordinaria(Registro Alta normal). Esto se puede en reversar todo lo que queramos, pero para entendernos es así como lo veo. El correcto encadenamiento no se validará en el momento de la presentación. Será en comprobaciones posteriores de la AEAT cuando se verificará la correcta trazabilidad de los registros. Por esta razón no es raro que se cuelen RF's con encadenamientos que no son lógicos o fuera de lugar. ¿Podrían pasar desapercibido? pues sí, pero si te toca y falla te aplicarán un margen de error antes de enviarte el requerimiento. Lo mejor es tener el SIF depurado para evitar esos errores. No creo que cuando tengas una aplicación corregida te vaya a dar problemas de esquemas estructurales o que con un recargo de equivalencia+ IVA no sumes un total en condiciones. Los problemas que puedes tener serán aceptados con errores y otros como confusiones en el tipo de facturas a emitir que simplemente serán aceptados, o cliente confundido, CIF erróneo... y todos pasan por una rectificativa. Creo que esto simplifica mucho y no tenemos que crear cuarenta estados, que pueden ocurrir sí, pero que lo normal es que ocurran en fase de pruebas.
|
|
#53
Hace 3 Semanas
|
|||
|
|||
|
Cita:
También está la anulación con rechazoprevio=X para ciertos problemas
|
|
|
|
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 |
 |
|
Mode Lineal
