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.

[Neftali [Germán.Estévez]]

Empezado por 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?

Cada registro de facturación debe tener su huella, su hash,...
Así que lo lógico es guardarlo en otra tabla, porque como tu has dicho, una factura puede tener RF, Alta/Modificación/Anulación.

[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.

[CarlosArjonomia]

Empezado por Jarogo08

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.

La huella la puedes generar en el momento del envío, pero con los datos necesarios para generarla que guardaste en su momento al generar el registro de facturación.

[Kuraudeo]

Bueno, la huella puedo generarla en el momento de intentar hacer el envío, si el envío no se puede realizar por alguna razón, ese registro que tengo en mi tabla ya tiene la huella generada, en el momento de intentar hacer el envío. También creo que si se hace con los datos que tengo, en el momento de crear la factura, no tendría que alterar nada.
Mi duda era esa, si tengo que grabar la huella. Había pensado en grabar la huella del primer registro de facturación que genera esa factura, si luego se genera alguna subsanación o se anula, esa huella no grabar, sólo a modo de dato en la factura. En la tabla donde guardo los registro de facturación, ya tengo asociada a que factura corresponde y si tengo varios, puedo acceder a ellos desde la factura.
Pero eso era mi duda, si era obligado que el primer registro de facturación sobre esa factura, tiene que guardar los datos de la huella,huella anterior,etc.
Muchas gracias.

[Jarogo08]

Empezado por Kuraudeo

Mi duda era esa, si tengo que grabar la huella. Había pensado en grabar la huella del primer registro de facturación que genera esa factura, si luego se genera alguna subsanación o se anula, esa huella no grabar, sólo a modo de dato en la factura. En la tabla donde guardo los registro de facturación, ya tengo asociada a que factura corresponde y si tengo varios, puedo acceder a ellos desde la factura.
Pero eso era mi duda, si era obligado que el primer registro de facturación sobre esa factura, tiene que guardar los datos de la huella,huella anterior,etc.
Muchas gracias.

Por tener... no tienes. Las huellas tienen que estar guardadas en la tabla de registros de facturación, pero no es obligatorio que estén en la tabla de facturas.

¿quieres que esté igualmente? Nadie te va a impedir crear un campo en tu tabla de facturas para guardar ese valor. Nosotros por ejemplo lo hicimos, aunque lo que guardamos es la última huella (no la primera como tu sugieres). Es un campo informativo que no tiene mayor importancia

[Kuraudeo]

Buenas, una duda sobre el registro de facturación, esta tabla se tiene que rellenar siempre o sólo en el momento de empezar a trabajar en modo verifactu (en mi caso no me planteo otro).
Me refiero, por ejemplo un cliente en SII, ¿tendría que generar también ese registro de facturación aunque no se genere el envío?
Un cliente que quiera el software y no este obligado a generar facturas (creo que las personas que están en módulos), ¿tiene que generar esta tabla con el registro de facturación?
Gracias.

[Neftali [Germán.Estévez]]

Empezado por Kuraudeo

por ejemplo un cliente en SII, ¿tendría que generar también ese registro de facturación aunque no se genere el envío?

No.

Empezado por Kuraudeo

Un cliente que quiera el software y no este obligado a generar facturas (creo que las personas que están en módulos), ¿tiene que generar esta tabla con el registro de facturación?

No.

Sólo si estás acogido a veri*factu/No-veri*factu tienes que cumplir con todo lo que dice la ley (QR, Reg. facturación, Huellas, Hash,...)

[jakematespain]

Entonces, con todo esto del cambio de fechas,etc, el cliente que tenga un software preparado para el sistema verifactu, por ejemplo, pero no lo tenga activado (el cliente que se a principios de julio ya lo tenía instalado todo, por ejemplo), ese cliente como en el software no lo tiene, no genera ningún registro hasta activar algún sistema.

Otra consulta, en modo verifatu, en lugar de activarlo en el software de Gestión, hace los envíos desde el software de contabilidad. Crea la tabla con toda la información en Gestión, pero el envío se hace desde la contabilidad. Algo como el SII, pero en verifactu. Está claro que tiene que estar totalmente enlazado y sincronizado, por que no sería la misma base de datos, sería una de Gestión y otra de contablidad.

Gracias.

[Neftali [Germán.Estévez]]

Empezado por jakematespain

Entonces, con todo esto del cambio de fechas,etc, el cliente que tenga un software preparado para el sistema verifactu, por ejemplo, pero no lo tenga activado (el cliente que se a principios de julio ya lo tenía instalado todo, por ejemplo), ese cliente como en el software no lo tiene, no genera ningún registro hasta activar algún sistema.

Entiendo que con la prórroga, puedes tener a un cliente con el software actualizado, pero no activarle Ley Antifraude (verifactu o noveri*factu) hasta el 2027.
No es nuestro caso, que en cuanto actualizamos a un cliente, si tiene obligación legal, se lo activamos (en la modalidad que él quiera verif*actu o no_veri*factu). Quedan excluídos los del SII, TicketBAI,...

Empezado por jakematespain

Otra consulta, en modo verifatu, en lugar de activarlo en el software de Gestión, hace los envíos desde el software de contabilidad. Crea la tabla con toda la información en Gestión, pero el envío se hace desde la contabilidad. Algo como el SII, pero en verifactu. Está claro que tiene que estar totalmente enlazado y sincronizado, por que no sería la misma base de datos, sería una de Gestión y otra de contablidad.

Esto no lo he entendido.
En nuestro caso también tenemos la tipología de 2 programas enlazados. Uno de facturación y otro de contabilidad. Cada uno se encarga de lo suyo. En este caso, el de facturación es el que hace todo lo referente a veri*factu y el de contabilidad no sabe nada de eso.

[jakematespain]

Lo de la contabilidad, lo comento por que he visto algún software de contabilidad que se encarga de enviar al SII y no se hace desde Gestión. Por eso lo decía, si se podía hacer algo parecido para el software de Gestión, que fuera el de contabilidad, el que recogiera esa información y la enviara. Sabiendo el tema de plazos, etc y que todo tendría que ir muy sincronizado.

Gracias.

[Jarogo08]

Empezado por jakematespain

Lo de la contabilidad, lo comento por que he visto algún software de contabilidad que se encarga de enviar al SII y no se hace desde Gestión. Por eso lo decía, si se podía hacer algo parecido para el software de Gestión, que fuera el de contabilidad, el que recogiera esa información y la enviara. Sabiendo el tema de plazos, etc y que todo tendría que ir muy sincronizado.

Gracias.

Es que es distinto... El SII envía asientos, mientras que Verifactu envía registros de Facturación (facturas). Por eso uno se hace desde Contabilidad y otro desde Gestión

[novatico]

Para nosotros, el SII también es un módulo enlazado con la Contabilidad.

[Faneka]

Nosotros el SII esta en el modulo de contabilidad unicamente.