|
Sobre encadenamiento
Buenos días.
Leyendo en el Foro y la documentación, el encadenamiento sobre el registro anterior, se debe hacer siempre, excepto en el primer alta que debería ponerse PrimerRegistro. En las pruebas que estoy haciendo, siempre pongo PrimerRegistro en cada primer registro de facturación de cada envío, encadenado a partir del segundo registro de facturación con el RegistroAnterior. En los envíos de un sólo registro de facturación, siempre pongo PrimerRegistro en el encadenamiento y no tengo ningún tipo de error. ¿Puede ser porque se un entorno de pruebas? Muchas Gracias. |
Supongo que si, porque no les sera dificil saber si es el primer RF que mandas. En producción al menos deberían devolver algún tipo de aviso/error.
|
Cita:
El encadenamiento correcto no lo verifican en el envío, si no posteriormente, y si tienes muchos errores (numeto X o según sus algoritmos) de encadenamiento comienzan el protocolo de avisos de la aeat. Supongo que no es lo mismo que tengas un error de encadenamiento y una continuidad normal en el envío que si se rompe el encadenamiento a menudo y además con pausas largas después de la rotura en el envío, eso seguro que les salta la alarma. Tendrán algoritmos de cálculos con medias De venta, número de incidencias. Etc. Ya está preguntado a verifactu lo he puesto en el hilo de "errores relacionados con la aeat" |
Cita:
Muchas gracias. |
Cita:
Muchas gracias. |
Sobre los encadenamientos pienso que al principio deberían avisar, para que se corrijan posibles problemas que no detectamos,eso de que si han fallado de firma frecuente empiecen las notificaciones me parece más serio.al menos unos meses deberían avisar con un warning igual que con los envíos fuera de tiempo, aunque no lo hagan en el momento del envío. Pero claro no tienen un correo para esa notificación.es un problema
|
A ver.... dices que:
En las pruebas que estoy haciendo, siempre pongo PrimerRegistro en cada primer registro de facturación de cada envío, encadenado a partir del segundo registro de facturación con el RegistroAnterior. Si cada prueba es de una empresa distinta, vale. pero si haces una segunda prueba de una empresa que ya has hecho algún envio anterior, no puedes volver a utilizar PrimerRegistro, el primer registro del nuevo envío lo deberás encadenar al ultimo del envío anterior de esa empresa, para mantener el encadenamiento de toda tu facturacion. Imagina que envias 20 facturas de una en una, a todas les pones primer registro. ¿donde está el encadenamiento? |
Cita:
Claro, por eso era la duda. No me daba error. Pero sabiendo que está mal, aunque por ahora me lo permitiera, ya lo he corregido. Saludos. |
Encadenamiento correcto
Hola buenas tardes. En mis lios con el encadenamiento este es el planteamiento que yo entiendo:
fra fecha encadenamiento ALTA FR0001 01/02/2025 ALTA FR0002 01/02/2025 FR0001 ALTA FR0003 02/02/2025 FR0002 ALTA FR0004 02/02/2025 FR0003 ALTA FR0005 03/02/2025 FR0004 ALTA RF0001 03/02/2025 FR0005 SUBS FR0003 02/02/2025 RF0001 La factura se envío con algún tipo de error y se corrige con una subsanación en días posteriores. Esto sería correcto así o estoy en un error. Disculpar este tema creo que se hablo, pero no encuentro el p... tema.:D |
Cita:
|
Que pasaría si una mista empresa tienes 3 tiendas. Ya les he adjudicado series distintas de facturas.
Tienda 1 : Serie A00000001-2025A ... Tienda 2 : Serie A00000001-2025B ... Tienda 3 : Serie A00000001-2025C ... De esta manera al consultar una factura en hacienda o generar el QR, no tengo problema ya que los datos: "Nif" es común para los tres y "numero serie, fecha y total" son independiente para cada factura. Cada una de las tiendas va a enviar sus propio datos. Mi duda es, para la generación de la huella, el registro anterior supongo que será el ultimo enviado en cada una de las tiendas. Alguien lo puede confirmar? Disculpen y Gracias. Por cierto aprovecho una vez mas para agradecer a Seccion_31, por el trabajo realizado y mi enorme gratitud por compartirlo con todos nosotros. |
Cita:
Buenas, La huella del registro anterior se refiere al enlace del registro recien creado con el registro inmediatamente anterior(sea la serie que sea) por orden cronologico de cada sif. Cada sif hace su encadenamiento. Si tienes 3 terminales y cada uno tiene su serie propia tienes entonces 3 sif porque los numeros que se crean lo hacen independientes del resto de maquinas de tu red, pues entonces cada uno encadenara la serie teniendo en cuenta el ultimo registro generado en cada sif o maquina Lo suyo es que cada sif encadene y envie sus series pero se puede dar el caso de que por ejemplo llegue todo a un servidor y este encadene y envie. En este caso el servidor debe encadenar por sif de forma independiente, osea, debera pasar por los registros recibidos de cada sif y encadenarlos y posteriormente enviarlos. Si filtras los registro por fecha en un consulta te devolvera los registros para el nif que pide la consulta mientras que si filtras por fecha y programa informatico te devolvera los registros que existan entre fechas del sif que definas en la consulta. Creo que es asi el procedimiento Un saludo |
Cita:
Despues ya está el nivel de complicación que queramos añadir, la tecnología hoy en día te permite muchas cosas, escritorio remoto con lo cual se unifica la facturación o una VPN centralizando la base de datos, etc, etc... que le dí muchas vueltas a esto, pero sin embargo la respuesta de los de verifactu fue tan sencilla como lo que te acabo de comentar. Muchas veces los desarrolladores somos los que nos complicamos la existencia. Y ya lo dije ayer, con que sea funcional y funcione correctamente es lo que vale, o por lo menos para mi. La elegancia ya vendrá en un futuro. Espero haberte ayudado. |
Tengo una duda, ¿como diferencia la demo si son facturas ordinarias o simplificadas?
|
Cita:
Si es el servicio de verifactu le tienes que enviar el nodo con el tipo de factura. F1, F2, F3, RX Do de cada F identifica ordinaria, simplificada o sustitutiva y las R los ttipps de rectificativas. En las e isiones al clientes tienes que ponerlo de alguna manera: Factura Factura sustitutiva Factura rectificativa Factura simplificada (ademas, hasta donde yo sé, siguen admitiendo otras nomenclaturas antiguas, como tiquet) |
Cita:
|
Duda Encadenamientos
Buenas,
Me gustaria que me confirmara alguien el proceso de encadenamiento con esta secuencia de envios y respuestas porque no se si lo hago bien. Estoy encadenando siempre con los correctos y omito incorrectos y Aceptada con errores . -subo la factura A12 (encadena con la A11),respuesta correcto -subo la factura A13 (encadena con A12), respuesta Aceptada con errores, error en la huella. -subo la factura A14 -----> con quien encadeno ¿ con A12 (correcta) o A13 (Aceptada con errores)? Si A13 fuese incorrecta en vez de aceptada con errores encadenaria con A12 pero en este caso como seria lo mas correcto? -subo factura A15 (encadena con A14), respuesta correcto paro de facturar A las dos horas me pongo a subsanar: -subo subsanacion de la fra. A13 reenviandola calculando bien la huella y encadenando con A15 Una ayuda, muchas gracias |
En el hilo de errores->"Cómo solventar el error de una factura rechazada y subsanación por rechazo" al final se habla de lo que preguntas.
Pero en resumen el encadenamiento es siempre del último RF que envies, sea correcto o rechazado. |
Cita:
Por favor revisad la Guía de estilo de los foros. Una de las cosas importantes que comenta es realizar una búsqueda antes de abrir un nuevo hilo.
De otra forma, además de añadir hilos repetidos, los moderadores debemos ir detrás retocando y corrigiendo temas. Uno los 3 temas en uno sólo. Un saludo. |
Duda Encadenamientos
Buenas,
siento haberme equivocado de hilo Mirad , necesito resolver esta duda que ademas me esta liando cada vez mas al leer algunas respuestas y ya no se ni en donde vivo: En el sif se guarda el estado de cada registro. Si envio un registro y me lo da como incorrecto y no entra en hacienda...... a pesar de eso debo de encadenar en mi sif la siguiente factura que haga con el ultimo registro que tengo en mi sif independientemente de que este mal y de que no haya generado registro alguno en hacienda? Yo tenia entendido de que se encadena siempre con el ultimo correcto y se subsanan y envian despues los incorrectos Esto es importante para mi porque parte del procedimiento del flujo de envios lo baso en una consulta inicial que realizo a hacienda para saber lo ultimo que tiene registrado, saber si responde, controlar la ultima huella registrada por ellos,etc. y en dicha consulta no salen los registros que no han entrado por incorrectos, logicamente , luego la huella ultima que ellos tienen no es la misma que la ultima que tengo yo. Pufff, espero haberme explicado, gracias |
Cita:
El encadenamiento siempre es con la última factura generada independientemente de que haya sido aceptada o rechazada. Puedes emitir 100 facturas todas rechazadas que se encadenan la una detrás de la otra. Saludos. |
Cita:
Cita:
Cita:
Para ser "purista" se encadena con el último "registro de facturación" (del mismo NIF) generado. Puede ser de alta, de subsanación o de anulación e independientemente de si esttá aceptado, rechazado,... |
En el caso de que envies un xml vacio o no informes del encadenamiento, como se seguiría el encadenamiento??? Alta por rechazo previo seguro, pero que habría que poner en el RegistroAnterior ??
Podria ser hacer el hash de: IDEmisorFactura=&NumSerieFactura=&FechaExped icionFactura=&TipoFactura=&CuotaTotal=&ImporteTotal=&Huella=&FechaHoraHusoGenRegistro= sin dato alguno?? |
Hola!
Entiendo que hay que encadenar todos los registros independientemente de si han sido aceptados o rechazados. Esto incluye los registros con error soapenv:Server y Client? Por ejemplo, envío una factura (A) correcta. Al enviar una segunda factura (B) la encadeno con la (A). Si la (B) me da error de tipo soapenv:Server, con cual encadeno una tercera (C), ¿con la (A) o la (B)?. Me surge la misma duda con el caso de error de tipo soapenv:Client para la factura B. |
Cita:
|
Cita:
|
Cita:
En la Sede de verifactu tendrán un registro menos xon un salto pero detectaron que habrá otro registro de subsanacion o anulación en referencia a ese salto |
Cita:
|
Cita:
|
imaginate que me rechazan un Rf en el cual no he informado de los datos necesarios para el encadenamiento, el siguiente Rf que genere debería generar una huella con los datos del Rf previo, pero en este caso no tiene. Habria que hacer el hash de:
IDEmisorFactura=&NumSerieFactura=&FechaExpedicionFactura=&TipoFactura=&CuotaTotal=&ImporteTotal=&Hue lla=&FechaHoraHusoGenRegistro=(aquí si que habría datos) asi sin datos??? |
Cita:
Cita:
No, quería decir del mismo NIF. Un SIF (nuestro programa de facturación) puede trabajar con más de 1 empresa, por lo tanto con más de 1 NIF. Los encadenamientos y los envíos dentro de nuestra aplicación (nuestro SIF) se hacen por NIF. 1 Factura NIF1 - sin encadenamiento 2 Factura NIF2 - sin encadenamiento 3 Factura NIF1 - se encadena con la 1 4 Factura NIF1 - se encadena con la 3 5 Factura NIF2 - se encadena con la 2 ... |
Cita:
Creo que aquí tienes un error de concepto. La generación de un registro (incluídos sus datos de encadenamiento) debe hacerse SIN TENER EN CUENTA el envío. Es decir, debes poder generar 50 registros de facturación (por decir un número) seguidos y encadenados sin enviar nada. Si tu programa no es capaz de hacer eso, es que lo estás planteando mal. El registro de facturación y el encadenamiento NO DEPENDE como he dicho ni del envío, ni de si se ha aceptado o rechazado. |
A ver si lo dejo mas claro, se que este es un caso que nunca debería darse, pero imaginaos que por algún casual no se han rellenado los nodos para el encadenamiento (pero si que existe, solo que con '' por valor)y sin darme cuenta del error lo he enviado a la AEAT (respondiendome que esta rechazado obviamente). Ahora la duda es como proceder con el encadenamiento en el siguiente Rf que queramos generar.
|
Cita:
Entiendo entonces que todas las empresas definidas en vuestro software tienen el mismo número de SIF. Si el OT NIF1 tiene dos o tres empresas distintas en vuestro software, las tres empresas de ese OT tendrán que encadenar en la misma línea de facturación no ?. |
Cita:
|
Ok, era lo que me esperaba y la verdad que es un caso extraño, pero me ha entrado la duda, gracias.
|
Pues supongo que debemos estar hablando de lo mismo, pero no nos entedemos...
Cita:
1 OT tiene 1 NIF, y si hay 3 empresas tiene que haber 3 NIFs. No puede haber 2 empresas con el mismo NIF, si tienen el mismo NIF, son la misma. Cita:
1) Mi SIF, es mi programa de facturación; MiERP.exe -para que nos entendamos-. 2) Mi SIF trabaja con multiempresa, es decir, mi programa permite trabajar con 3 empresas (cada una con su NIF). Que significa 3 OTs. Por lo tanto la frase "Siempre debes encadenar con el último RF generado por tu SIF", es errónea. Dentro de mi software (y de los que sean como el mío) no se encadena con el último RF geneado, sino con el último generado del mismo NIF (que puede ser de hace 1 semana). |
Cita:
Es por eso, que te comentaba que teniendo en tu sistema el mismo SIF para todos, no te queda otra que encadenar en una sola línea de facturación las tres empresas de este OT. Tienes razón en que la frase "Siempre debes encadenar con el último RF generado por tu SIF" no se puede generalizar, pero se sobreentiende que cuando dices esto es porque ese SIF sólo tiene un OT. Aunque te podría responder lo mismo, cuando dices "se encadena con el último "registro de facturación" (del mismo NIF) generado", para tu sistema sí pero para el resto donde un OT puede tener diferentes SIF's no sería correcto. Al final, lo que debemos dejar claro para la gente que anda buscando información es remitirnos a lo que dice el reglamento, y sus Faq's lo deja bien claro ¿En qué consiste la trazabilidad exigida a los sistemas informáticos de facturación (SIF) en el reglamento y la orden «de requisitos de los SIF»? La trazabilidad se refiere a que se pueda garantizar (y, en su caso, detectar) que no hay “huecos” o “saltos” en la secuencia de generación de los registros de facturación (RF) correspondientes a las facturas expedidas utilizando un determinado SIF de un obligado tributario (OT), así como que dicha secuencia se corresponde con la de la fecha y hora de generación empleadas. Esto se consigue “encadenando” los RF generados por cada SIF del OT, es decir, formando virtualmente una “cadena”..... https://sede.agenciatributaria.gob.e...recuentes.html |
Cita:
|
Cita:
El problema del encadenamiento con un solo SIF y las tres empresas en el mismo software de facturación es que tienes que usar una sola cadena con los registros de tres empresas que podría generar retrasos a la hora de emitir facturas ya que las tres comparten la misma línea y desde que una la bloquee para emitir su RF las otras dos tienen que esperar. |
| La franja horaria es GMT +2. Ahora son las 23:46:56. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi