![]() |
Mis envíos de los RF - vuestra opinión
Buenos días.
Me gustaría saber vuestra opinión respecto al flujo de trabajo que he implementado en mi sistema de facturación (sólo Verifactu). De modo muy global: 1.- Cuando el usuario factura, siempre genera un "borrador" (de hecho, la opción no se llama "Facturar", si no "Generar Borrador"), el cual, posteriormente hay que "validar". 2.- Mientras no se "valide", si decide imprimir, pondrá "Borrador Nº", en lugar de "Factura Nº" y por supuesto, no hay forma de imprimir QR. 3.- A ese "borrador", mientras no se "Valide", se le pueden añadir más registros (borradores de facturas). 4.- Cuando el usuario "Valida", es cuando genero los registros correspondientes al "Registro de Facturación", pero dichos registros, aún no tienen ni "Huella", ni "datos enlazados", ni "fechaUsoHorario" 5.- Cuando termina el último registro del punto anterior, se intentan enviar los registros (hasta máximo de 1000), y es cuando se están generando los registros del correspondiente XML a enviar, cuando se generan los datos enlazados, la huella y la fechausohorario. Todo ello, dentro de una transacción, de forma que si no se genera toda la información sin error, es como si no se hubiese hecho nada y los registros están como recién generados. 6.- Si todo ha ido correcto, se procesa la respuesta y se actualiza determinada información en el fichero "Registro de Facturación". Un saludo. Antonio |
Cita:
"es cuando genero los registros correspondientes al "Registro de Facturación", pero dichos registros, aún no tienen ni "Huella", ni "datos enlazados", ni "fechaUsoHorario" Esto lo veo raro y no lo acabo de entender. Deberías consultar si es correcto. "y es cuando se están generando los registros del correspondiente XML a enviar, cuando se generan los datos enlazados, la huella y la fechausohorario." Los registros se deben generar en el momento de guardar la factura, no en el momento del envío. Piensa que el envío puede ser diferido (X segundos) desde que se genera la factura. Se DEBEN generar al guardar la factura no el enviar. |
La hora de generación del registro de facturación que confirma que es una factura tiene que coincidir con la del timestamp del xml de cada registro (+-1 minuto), no debes generar un xml posteriormente ni asignarle una hora posterior a la validación de la factura, ni se puede dar el caso de que por alguna incidencia en la generación puedas generarlo con un timestamp posterior, sí tienes una incidencia en la generación debes confirmar la factura cuando subsanes el problema y en ese momento proceder a la generación del xml con el timestamp correspondiente al momentoen el que lo generas,
No es correcto. |
En el punto 4 discrepo en cuanto a la fechahorauso.
La fecha y hora del RF ha de ser la misma (lo MÁS aproximada posible +-1 segundo digamos) que la del momento de crear la factura. Otra cosa es la fecha y hora del XML. Un XML no implica 1 solo RF. Esto va a misa tal cual que un XML puede contener hasta 1000 RF. Por tanto la fechahorauso del XML no tiene por que coincidir con la del/de los RF. Por lo demás creo que coincidimos. |
Cita:
Perdona, lo mismo no te estoy entendiendo muy bien, pero lo de la fechaorauso del xml refiriendote al conjunto de registros, a que te refieres? Cada registro en el xml lleva su timestamp de generacion=fechahorauso.... El conjunto de registros empaquetados para el envio no tiene una fechahora, aunque si la respuesta del envio. Perdona si no te he entendido. Vale edito: Creo que eso es lo que le estabas explicando al del antrrior post.. ok ok |
Cita:
A ver, tal vez no me he explicado bien. Para mi desarrollo VALIDAR FACTURA = 1-IMPRIMIR + 2-GENERAR RF + 3-ENVIAR RF + 4-PROCESAR RESPUESTA Proceso continuo, lo que podríamos decir que todo se produce en tiempo real. Que por cierto, hablando de VALIDAR FACTURA, se me olvidó comentar que, cuando el usuario valida la facturación, la fecha en que valida es la que uso como FECHA EXPEDICION de la factura, ya que podría estar validando un borrador que, por ejemplo, generó ayer. Pero sí que tenéis razón en que debo generar el timestamp y demás, en el momento de generar los registros de facturación, porque si se produjese un problema (prolongado en el tiempo) durante el envío, podría haber un gran desfase entre cuando se expide la factura y el timestamp que pretendía generar en el momento del envío. ----------- Un saludo Antonio |
Cita:
No pretendo quitaros la razón, entre otras cosas, por que la tenéis :), pero he leído mucho contenido en este foro, y se habla mucho como si hubiese más de una fecha y hora en el procedimiento (o es que yo lo estoy entendiendo mal). La única FechaHora que yo he encontrado, es la correspondiente a la que se informa cuando se crea el XML a enviar con cada uno de los registros de facturación (FechaHoraHusoGenRegistro). De ahí que me lo planteara como os expuse. Es decir (y según mi planteamiento inicial), si físicamente valido e imprimo a las 10:00, x facturas, pero por el motivo que sea, la información no se envía hasta las 12:23, a todos los efectos, es como si el proceso de validación que realicé a las 10:00, lo hubiese hecho a las 12:23 Dicho lo cual, voy ha realizar los cambios oportunos. ----------- Un saludo Antonio |
Hola,
Se me ha ido la pinza. El XML no tiene fecha y hora, son los RF individualmente. >>Es decir (y según mi planteamiento inicial), si físicamente valido e imprimo a las 10:00, x facturas, pero por el motivo que sea, la información no se envía hasta las 12:23, a todos los efectos, es como si el proceso de validación que realicé a las 10:00, lo hubiese hecho a las 12:23 Sí, si la lógica del programa la tienes así, pero esta lógica no cumple la ley; a partir de ahí y siendo conscientes de ello... Si es una excepción, lo aceptaran pero en ese caso yo enviaría el XML con el indicativo de 'incidencia' y me prepararía para justificarla, si no es una excepción y lo 'descubren' no te lo aceptaran, y puede haber sanción. |
| La franja horaria es GMT +2. Ahora son las 12:39:37. |
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