Pruebas para un nuevo proyecto

[Kuraudeo]

Hola, estoy preparando un nuevo proyecto de facturación, si ya se que ahora mismo es una locura y tengo una duda. Desde la aplicación que estoy haciendo, genero todo el tema de facturación usando procedures en la base de datos, de forma que yo hago una facturación manual y dependiendo de la cantidad de albaranes a facturar, me puede tardar más o menos tiempo. No es lo mismo facturar 10 albaranes que 1000 albaranes. La cuestión, es que yo tenía planteado crearme una tabla de registro_de_facturación, para ir guardando es esa tabla toda la información, a medida que va saltando el trigger alter insert de la nueva factura, pero claro, desde hay no puedo generar el xml hasta que lance toda la facturación, ya que las facturas van en bloque.
Imagino que el xml de registro de facturas es obligado que se genere, no vale con tener una tabla donde se guarda toda esa información que se usa para luego generar el xml del envío.
También entinedo, que como es un bloque de facturas, me tocará hacer que cuando termine el bloque, generar en un proceso todos esos xml de las facturas generadas para el envío.
He visto que hay APIS, que les mandas un json al enviar la factura, no generan el RF en el mismo momento de crear la factura.
Me podéis ayudar sobre esta duda.
Gracias.

[Carlos]

Empezado por Kuraudeo

Hola, estoy preparando un nuevo proyecto de facturación, si ya se que ahora mismo es una locura y tengo una duda. Desde la aplicación que estoy haciendo, genero todo el tema de facturación usando procedures en la base de datos, de forma que yo hago una facturación manual y dependiendo de la cantidad de albaranes a facturar, me puede tardar más o menos tiempo. No es lo mismo facturar 10 albaranes que 1000 albaranes. La cuestión, es que yo tenía planteado crearme una tabla de registro_de_facturación, para ir guardando es esa tabla toda la información, a medida que va saltando el trigger alter insert de la nueva factura, pero claro, desde hay no puedo generar el xml hasta que lance toda la facturación, ya que las facturas van en bloque.
Imagino que el xml de registro de facturas es obligado que se genere, no vale con tener una tabla donde se guarda toda esa información que se usa para luego generar el xml del envío.
También entinedo, que como es un bloque de facturas, me tocará hacer que cuando termine el bloque, generar en un proceso todos esos xml de las facturas generadas para el envío.
He visto que hay APIS, que les mandas un json al enviar la factura, no generan el RF en el mismo momento de crear la factura.
Me podéis ayudar sobre esta duda.
Gracias.

Hola,
Cuando se crea la factura se debe crear inmediatamente el RF, otra cosa será cuando se envíe.
El envío de los RF se debe hacer en un XML que los contendrá y tenemos un margen de 'n' segundos para ello.
Veri*factu tolera una demora en el envío de los RF de 'n' segundos; hay quién dice 60/120/240 (por que es lo habitual), pero puede establecer los que le plazca, por tanto tan pronto podamos enviar enviamos.
Que hacen los API? Pues ciertamente no lo sé y entiendo que cada API quizás lo hace diferente.
Que hago yo? Cuando creo la factura en el SIF, creo el RF en una tabla (forma parte del SIF) con SU FECHA/HORA de CREACIÓN, y lo envío a una utilidad externa que importa los RF respetando su fecha/hora de creación, y los envía; el proceso de importación y envío desde esta utilidad se realiza cada 'x' segundos (tengo establecido 30/45 segundos hoy en día). Creo que esta manera de trabajar sería la correcta y no que el API estableciera la fecha/hora de creación de los RF (por que deben coincidir con el momento de la creación de la factura); un API o esta utilidad no deberían alterar la información que debe manejar/gestionar el SIF.

[Kuraudeo]

Hola y gracias por la contestación. Mi duda es, el registro de facturación de alta en XML, lo tengo que generar de forma obligada dando lo mismo si estoy en verifactu o en no verifactu.
Por lo que me comentas, tú también generas la información en una tabla en el momento de generar la factura que luego usas para generar el XML que se envía al Verifactu, ¿es eso correcto?
Tú entonces no generas ningún XML previo que luego es el que usas para enviar. Estás generando el XML en la tabla que luego usas para el envío, ¿es eso lo que haces? o directamente usas esa tabla para que la utilidad que comentes genera el XML y haga el envío.

Yo ya te digo, genero toda la información que necesito en una tabla de RF y luego es la que quiero usar para generar todo el tema del envío, pero mi duda es esa, si tengo que generar un XML previo y luego generar el XML para el envío.
Por ejemplo:
Si hago una tanda de 10 factura que tengo que comunicar.
¿Tengo que generar 10 XML para cada factura o si tengo la información en mi tabla de la bd registro_de_facturacion me vale?
Luego, a la hora de hacer el envío, si que se generará un envío de un XML con esas 10 facturas para enviar.
He visto por ejemplo, la demo que hay aquí y veo que me genera un xml por cada factura y luego si tengo varias facturas me lo agrupa en uno.
Mi gran duda es esa, ¿tengo que generar por obligación el xml de esas 10 facturas de forma individual o con el xml del envío y la tabla que tengo ya vale¿
Gracias por responder, pero tengo un lío impresionante.


Muchas gracias.

[Carlos]

Empezado por Kuraudeo

Mi duda es, el registro de facturación de alta en XML, lo tengo que generar de forma obligada dando lo mismo si estoy en verifactu o en no verifactu.

En 'No Veri*factu' deberás generar el XML a enviar a Hacienda cuando te lo pidan. El caso es que en un 99% la mayoría creemos que te lo van a solicitar con lo que no te ahorras nada en apuntarte a 'No Veri*factu', es más en 'No Veri*factu' te complicas la vida en cuanto a desarrollo y responsabilidades que asumes, ya que debes custodiar los RF, con sus firmas digitales (en eventos también), etc.

Empezado por Kuraudeo

Por lo que me comentas, tú también generas la información en una tabla en el momento de generar la factura que luego usas para generar el XML que se envía al Verifactu, ¿es eso correcto?

Si; no genero ningún XML hasta que voy a enviar, pero los datos del RF (incluida fecha/hora de creación) los tengo en una tabla.
Y cuando voy a generar XML de envío es cuando calculo cada huella.

Empezado por Kuraudeo

Tú entonces no generas ningún XML previo que luego es el que usas para enviar.

Exacto, ningún XML previo.

Empezado por Kuraudeo

Estás generando el XML en la tabla que luego usas para el envío, ¿es eso lo que haces? o directamente usas esa tabla para que la utilidad que comentes genera el XML y haga el envío.

Guardo datos en tabla, después la utilidad los importa, genera un único XML y lo envía.

Empezado por Kuraudeo

Yo ya te digo, genero toda la información que necesito en una tabla de RF y luego es la que quiero usar para generar todo el tema del envío, pero mi duda es esa, si tengo que generar un XML previo y luego generar el XML para el envío.

Si 'tengo'='debo', no, no debes. Eso depende de como lo montes, si a cada RF le generas el XML (incluida huella), después se trata de ir añadiendo nodos (cada RF del XML creado previamente en un nodo) al XML de envío.
A mi me es más cómodo guarda la información del RF en un tabla (sin crear el XML del RF), cada dato en un campo/columna por que si quiero atacar la tabla, lo hago más cómodamente que examinando un supuesto XML de cada RF.

Empezado por Kuraudeo

Si hago una tanda de 10 factura que tengo que comunicar.
¿Tengo que generar 10 XML para cada factura o si tengo la información en mi tabla de la bd registro_de_facturacion me vale?

A mi me vale, por la sencilla razón que si estoy en 'Veri*factu' y ya he enviado a Hacienda, no debo (puedo pero no debo) guardar los RF ya sean en tablas o en XML; no me he cuestionado si Hacienda querrá ver 'in situ' los datos del RF en tabla o en XML.

Empezado por Kuraudeo

Luego, a la hora de hacer el envío, si que se generará un envío de un XML con esas 10 facturas para enviar.

Exacto.

Empezado por Kuraudeo

He visto por ejemplo, la demo que hay aquí y veo que me genera un xml por cada factura y luego si tengo varias facturas me lo agrupa en uno.

Es una manera de hacerlo; en vez de guardar datos en tabla, guarda XML de cada RF ya creado. Supongo, por que desconozco la demo.

Empezado por Kuraudeo

Mi gran duda es esa, ¿tengo que generar por obligación el xml de esas 10 facturas de forma individual o con el xml del envío y la tabla que tengo ya vale¿

Con el XML de envío y los datos en la tabla ya te vale.

[Kuraudeo]

Ok, muchas gracias.
Entonces sigo con mi planteamiento, en una tabla que voy rellenando cada vez que genero una factura, con los datos de la factura, la fecha de creación y los necesarios para generar luego el XML. Me voy a plantear también la opción de hacerlo con una aplicación externa, que cada x segundos vaya repasando esa tabla con los rf pendientes de enviar, genere la huella, xml y lo envies.
Gracias por tú ayuda.

[Kuraudeo]

Hola, otra duda básica, los datos de la huella, huella anterior,etc que tienes en la tabla de la apliacación, ¿luego la grabas también en la factura? En caso de ser de esa forma, imagino que si una factura tiene luego varios registros de facturación (por que se haya tenido que subsanar), la huella que se tendrá que grabar es la del primer registro que grabo esa factura, ¿es correcto?
No se si con tener en la tabla ya la información del envío (huella,tipo factura,xml del envío), necesito incorporar esos datos también en la factura o con tenerlo en la tabla de rf ya es válido.
Muchas gracias.

[Jarogo08]

Empezado por Kuraudeo

Ok, muchas gracias.
Entonces sigo con mi planteamiento, en una tabla que voy rellenando cada vez que genero una factura, con los datos de la factura, la fecha de creación y los necesarios para generar luego el XML. Me voy a plantear también la opción de hacerlo con una aplicación externa, que cada x segundos vaya repasando esa tabla con los rf pendientes de enviar, genere la huella, xml y lo envies.
Gracias por tú ayuda.

La huella ya le deberías dar valor cuando grabas el registro, no cuando lo envíes. Piensa que puedes estar 3 días sin internet y por tanto 3 días sin enviar. La tabla debería tener todos los datos cubiertos, independientemente de si se ha enviado o no.