repetir datos or not to be

[xamminf]

Empezado por rci

Tenias que generar el registro de facturación de ALTA justo cuando se emitió la factura, en ese momento tenias la información.

Cuando haces una subsanación generas otro registro de facturación.

Saludos

Cuando hablas de "generar el registro de facturacion de ALTA" ¿ Te refieres a generar la parte del .xml relativo a esa ALTA de manera que el .xml final sólo sea el pegado de los trozos xml de las distintas facturas-registro que componen el envio ?

Se me está rompiendo alguna costura, pero habrá que suturar

Gracias por responder

[rci]

Empezado por xamminf

Cuando hablas de "generar el registro de facturacion de ALTA" ¿ Te refieres a generar la parte del .xml relativo a esa ALTA de manera que el .xml final sólo sea el pegado de los trozos xml de las distintas facturas-registro que componen el envio ?

Se me está rompiendo alguna costura, pero habrá que suturar

Gracias por responder

No se si nos estamos entendiendo

Según la ley antifraude, inmediatamente en el momento emitir cada factura (por ejemplo salvas la factura en una tabla facturas_ventas) también hay que crear un "registro de facturación", que es un objeto XML con el formato especificado en la normativa, y con la información de la factura (por ejemplo salvar el XML en una tabla registros_facturacion).
En el caso de una nueva factura, el registro de facturación será una ALTA, pero también hay otros tipos de registros de facturación, por ejemplo para Anular.

En modo Veri*Factu (facturas verificables) todos los registros de facturación se tienen que remitir a la AEAT siguiendo un control de flujo establecido en la normativa.

Según entiendo de lo que explicas en tu ejemplo, detectas algún error en la factura (que no requiere generar una factura rectificativa) y por lo tanto se puede corregir usando Subsanación.
Para hacer esto, se tiene que generar un nuevo registro de facturación, con la información de la misma factura ya corregida y con las marcas pertinentes para indicar que es una subsanación.
Ese registro de facturación de subsanación también se tiene que remitir a hacienda.

Dependiendo del número de facturas que hagas y de la respuesta de hacienda en cada envío, debido al control de flujo es posible que el primer registro de facturación de la factura (el alta) todavía no se haya enviado cuando se genere el segundo registro de facturación de la factura (el de subsanación).
Pues en ese caso los dos registros (y los otros que estén en cola) estarán esperando que se pueda enviar y cuando "ya toque" se crea un nuevo XML (un paquete de varios registros de facturación) que contendrá tanto el alta como la subsanación de esa factura y otros registros de facturación de otras facturas si se da el caso.

Ese XML del "paquete" de registros de facturación se enviará a la AEAT y contestará con el estado de cada registro de facturación enviado.

Saludos

[xamminf]

Empezado por rci

No se si nos estamos entendiendo

Según la ley antifraude, inmediatamente en el momento emitir cada factura (por ejemplo salvas la factura en una tabla facturas_ventas) también hay que crear un "registro de facturación", que es un objeto XML con el formato especificado en la normativa, y con la información de la factura (por ejemplo salvar el XML en una tabla registros_facturacion).
En el caso de una nueva factura, el registro de facturación será una ALTA, pero también hay otros tipos de registros de facturación, por ejemplo para Anular.

En modo Veri*Factu (facturas verificables) todos los registros de facturación se tienen que remitir a la AEAT siguiendo un control de flujo establecido en la normativa.

Según entiendo de lo que explicas en tu ejemplo, detectas algún error en la factura (que no requiere generar una factura rectificativa) y por lo tanto se puede corregir usando Subsanación.
Para hacer esto, se tiene que generar un nuevo registro de facturación, con la información de la misma factura ya corregida y con las marcas pertinentes para indicar que es una subsanación.
Ese registro de facturación de subsanación también se tiene que remitir a hacienda.

Dependiendo del número de facturas que hagas y de la respuesta de hacienda en cada envío, debido al control de flujo es posible que el primer registro de facturación de la factura (el alta) todavía no se haya enviado cuando se genere el segundo registro de facturación de la factura (el de subsanación).
Pues en ese caso los dos registros (y los otros que estén en cola) estarán esperando que se pueda enviar y cuando "ya toque" se crea un nuevo XML (un paquete de varios registros de facturación) que contendrá tanto el alta como la subsanación de esa factura y otros registros de facturación de otras facturas si se da el caso.

Ese XML del "paquete" de registros de facturación se enviará a la AEAT y contestará con el estado de cada registro de facturación enviado.

Saludos

Muchísimas gracias por tu exhaustiva explicación. Me ha quedado super claro y sobre todo, fundamentado.
Muchas gracias de corazón

[xamminf]

Empezado por rci

No se si nos estamos entendiendo

Según la ley antifraude, inmediatamente en el momento emitir cada factura (por ejemplo salvas la factura en una tabla facturas_ventas) también hay que crear un "registro de facturación", que es un objeto XML con el formato especificado en la normativa, y con la información de la factura (por ejemplo salvar el XML en una tabla registros_facturacion).
En el caso de una nueva factura, el registro de facturación será una ALTA, pero también hay otros tipos de registros de facturación, por ejemplo para Anular.

En modo Veri*Factu (facturas verificables) todos los registros de facturación se tienen que remitir a la AEAT siguiendo un control de flujo establecido en la normativa.

Según entiendo de lo que explicas en tu ejemplo, detectas algún error en la factura (que no requiere generar una factura rectificativa) y por lo tanto se puede corregir usando Subsanación.
Para hacer esto, se tiene que generar un nuevo registro de facturación, con la información de la misma factura ya corregida y con las marcas pertinentes para indicar que es una subsanación.
Ese registro de facturación de subsanación también se tiene que remitir a hacienda.

Dependiendo del número de facturas que hagas y de la respuesta de hacienda en cada envío, debido al control de flujo es posible que el primer registro de facturación de la factura (el alta) todavía no se haya enviado cuando se genere el segundo registro de facturación de la factura (el de subsanación).
Pues en ese caso los dos registros (y los otros que estén en cola) estarán esperando que se pueda enviar y cuando "ya toque" se crea un nuevo XML (un paquete de varios registros de facturación) que contendrá tanto el alta como la subsanación de esa factura y otros registros de facturación de otras facturas si se da el caso.

Ese XML del "paquete" de registros de facturación se enviará a la AEAT y contestará con el estado de cada registro de facturación enviado.

Saludos

Una apostilla, por lo que he estado viendo: No es necesario generar un registro xml. Basta grabarlo en tablas y construir el "registro" xml en el momento del envio. ¿ Por qué ? En ningún sitio (ley) dice que deba ser de una manera concreta.

[rci]

Empezado por xamminf

Una apostilla, por lo que he estado viendo: No es necesario generar un registro xml. Basta grabarlo en tablas y construir el "registro" xml en el momento del envio. ¿ Por qué ? En ningún sitio (ley) dice que deba ser de una manera concreta.

No se si acabo de entender lo que dices.

Empezado por xamminf

No es necesario generar un registro xml.

Generar un registro de facturación es obligatorio.

El registro de facturación se tiene que generar en el momento de emitir la factura. Para guardarlo puedes guardar en una tabla o crear fichero XML o como sea que puedas almacenarlo.

En el momento del envió puedes construir el XML del "paquete" de registros de facturación.

[xamminf]

Gracias por la aclaración !

[novatico]

Por si quedase alguna duda, en el caso de realizar "NO VERIFACTU", en el momento de crear la factura se ha de generar el registro de facturación !!! FIRMADO !!!, y esta firma ha de ser del momento de la generación de la factura, no del momento en que la AEAT pueda pedirte que le remitas esos registros de facturación, si te los pide.

[espinete]

Empezado por xamminf

Una apostilla, por lo que he estado viendo: No es necesario generar un registro xml. Basta grabarlo en tablas y construir el "registro" xml en el momento del envio. ¿ Por qué ? En ningún sitio (ley) dice que deba ser de una manera concreta.

Supongo que te refieres a que no hace falta guardar el archivo XML, y que lo que tienes pensado es guardar el XML en la BD directamente (yo también lo hago).

Hay quien prefiere guardar todos los XML generados en una carpeta, por seguridad, aunque no puedes garantizar que esos archivos se pierdan y tampoco sirve de mucho tenerlos en disco si ya los tienes en la BD.

No sé si era eso a lo que te referías. Generarlo vas a tener que generarlo siempre.

[xamminf]

Empezado por espinete

Supongo que te refieres a que no hace falta guardar el archivo XML, y que lo que tienes pensado es guardar el XML en la BD directamente (yo también lo hago).

Hay quien prefiere guardar todos los XML generados en una carpeta, por seguridad, aunque no puedes garantizar que esos archivos se pierdan y tampoco sirve de mucho tenerlos en disco si ya los tienes en la BD.

No sé si era eso a lo que te referías. Generarlo vas a tener que generarlo siempre.

Me referia a en que momento generar el "registro" de cada factura y sobre todo a como hacerlo.

El momento es "inmediatamente" despues de imprimir la factura.
Como hacerlo es generando un registro en una nueva tabla que se utilizara para en el momento del envio generar TODO el xml.

La confusion posterior, al menos para mi, vino cuando un compañero comentó:
"""hay que crear un "registro de facturación", que es un objeto XML""" y ciertamente el registro de facturacion NO tiene por qué ser un objeto xml, ni siquiera una parte del xml en formato texto: Se puede grabar los datos necesario para la formacion del registro en tablas siguiendo el paradigma de la inalterabilidad, supongo

[rci]

Empezado por xamminf

La confusion posterior, al menos para mi, vino cuando un compañero comentó:
"""hay que crear un "registro de facturación", que es un objeto XML""" y ciertamente el registro de facturacion NO tiene por qué ser un objeto xml, ni siquiera una parte del xml en formato texto: Se puede grabar los datos necesario para la formacion del registro en tablas siguiendo el paradigma de la inalterabilidad, supongo

Ahora entiendo la confusión que dices. Pido disculpas.
En nuestro caso (c#) tenemos objetos de los tipos de las clases generadas al importar el wsdl y al generar el registro de facturación, creamos objetos y los rellenamos. Para guardarlos, serializamos esos objetos a XML y guardamos en una tabla el XML comprimido pero también otros datos que forman parte del XML.
Supongo que podríamos no serializar el objeto y no utilizar XML, porque de hecho para enviar cogemos el XML de la tabla y lo deserializamos para volver a obtener el objeto y enviarlo.
Pero tendríamos que guardar toda la información en varios campos de la tabla de registros de facturación y supongo que también tendríamos que crear tablas relacionadas para guardar por ejemplo los datos de los desgloses de cada registro de facturación... Imagino que es posible pero lo veo mas complicado.
Supongo que en ese caso también podríamos crear el objeto para enviar (RegFactuSistemaFacturacion) en el momento del envío, con los datos de uno o varios registros de facturación (RegistroFactura) guardados al emitir la factura.

De momento nosotros lo hacemos así pero supongo que hay varias posibilidades, mientras se cumplan los requisitos de la ley

Saludos

[xamminf]

Empezado por rci

Ahora entiendo la confusión que dices. Pido disculpas.
En nuestro caso (c#) tenemos objetos de los tipos de las clases generadas al importar el wsdl y al generar el registro de facturación, creamos objetos y los rellenamos. Para guardarlos, serializamos esos objetos a XML y guardamos en una tabla el XML comprimido pero también otros datos que forman parte del XML.
Supongo que podríamos no serializar el objeto y no utilizar XML, porque de hecho para enviar cogemos el XML de la tabla y lo deserializamos para volver a obtener el objeto y enviarlo.
Pero tendríamos que guardar toda la información en varios campos de la tabla de registros de facturación y supongo que también tendríamos que crear tablas relacionadas para guardar por ejemplo los datos de los desgloses de cada registro de facturación... Imagino que es posible pero lo veo mas complicado.
Supongo que en ese caso también podríamos crear el objeto para enviar (RegFactuSistemaFacturacion) en el momento del envío, con los datos de uno o varios registros de facturación (RegistroFactura) guardados al emitir la factura.

De momento nosotros lo hacemos así pero supongo que hay varias posibilidades, mientras se cumplan los requisitos de la ley

Saludos

Compañero, ninguna disculpa era necesaria
Muchas gracias nuevamente por otra fenomenal respuesta que me ayuda a comprender mejor el sistema

[Jarogo08]

Empezado por rci

Ahora entiendo la confusión que dices. Pido disculpas.
En nuestro caso (c#) tenemos objetos de los tipos de las clases generadas al importar el wsdl y al generar el registro de facturación, creamos objetos y los rellenamos. Para guardarlos, serializamos esos objetos a XML y guardamos en una tabla el XML comprimido pero también otros datos que forman parte del XML.
Supongo que podríamos no serializar el objeto y no utilizar XML, porque de hecho para enviar cogemos el XML de la tabla y lo deserializamos para volver a obtener el objeto y enviarlo.
Pero tendríamos que guardar toda la información en varios campos de la tabla de registros de facturación y supongo que también tendríamos que crear tablas relacionadas para guardar por ejemplo los datos de los desgloses de cada registro de facturación... Imagino que es posible pero lo veo mas complicado.
Supongo que en ese caso también podríamos crear el objeto para enviar (RegFactuSistemaFacturacion) en el momento del envío, con los datos de uno o varios registros de facturación (RegistroFactura) guardados al emitir la factura.

De momento nosotros lo hacemos así pero supongo que hay varias posibilidades, mientras se cumplan los requisitos de la ley

Saludos

Buenas rci


Nosotros hacemos más o menos lo que comentas... creamos el objeto a enviar (RegFactuSistemaFacturacion) en el momento del envío, y se alimenta de una tabla creada para los envíos que tiene todos los datos necesarios. Una vez creado el objeto a enviar lo serializamos y guardamos el XML en una ruta. Pero realmente ese XML no lo usamos para nada, de hecho hasta nos planteamos no guardarlo.


Saludos