repetir datos or not to be

[xamminf]

Buenos días,

Resulta que mandas un ALTA y al poco ves que tienes que mandar una ALTA DE SUBSANACION, pero ambas están en cola ¿ De donde coges los datos para el ALTA si la factura ya está modificada por la subsanacion ?
¿ Hay que duplicar con el envio los datos de la factura o mejor en el envio generamos el trozo xml correspondiente a la factura ?
¿ Como lo haceis vosotros ? Quizá este tema ya se habló en el pasado...

Agradecido

[[newtron]]

Empezado por xamminf

Buenos días,

Resulta que mandas un ALTA y al poco ves que tienes que mandar una ALTA DE SUBSANACION, pero ambas están en cola ¿ De donde coges los datos para el ALTA si la factura ya está modificada por la subsanacion ?
¿ Hay que duplicar con el envio los datos de la factura o mejor en el envio generamos el trozo xml correspondiente a la factura ?
¿ Como lo haceis vosotros ? Quizá este tema ya se habló en el pasado...

Agradecido

Según lo que cuentas (no lo tengo muy claro) entiendo que has emitido una factura que no has enviado y que antes de intentar enviarla te das cuenta de que tienes que subsanarla, ¿no? Si es eso yo enviaría directamente la segunda como si fuera la original porque de una forma o de otra va a entrar fuera de plazo.


Saludos.

[rci]

Empezado por xamminf

¿ De donde coges los datos para el ALTA si la factura ya está modificada por la subsanacion ?

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.

Empezado por newtron

yo enviaría directamente la segunda como si fuera la original porque de una forma o de otra va a entrar fuera de plazo.

Yo creo que da igual que estén los dos registros de facturación en cola para envío, se tienen que enviar todos los registros de facturación.

Saludos

[xamminf]

Empezado por newtron

Según lo que cuentas (no lo tengo muy claro) entiendo que has emitido una factura que no has enviado y que antes de intentar enviarla te das cuenta de que tienes que subsanarla, ¿no? Si es eso yo enviaría directamente la segunda como si fuera la original porque de una forma o de otra va a entrar fuera de plazo.


Saludos.

Entiendo que esa manera, la de interceptar el registro anterior no enviado no es la manera "ortodoxa". Si ese fuera el único caso pues podría dar ese tipo de solucion.

Espero haberme explicado y gracias por la respuesta

[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

[rci]

Empezado por Jarogo08

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

Gracias Jarogo08, después de escribir el post también me he planteado si hacia falta guardar el XML. De momento lo guardamos.
Si realmente el XML no lo usas, cuando dices que "se alimenta de UNA tabla", imagino que debe ser mas de una, porque a parte de que la tabla debe tener unas 100 columnas para guardar toda la información posible de un registro de facturación, los datos que pueden tener múltiples ocurrencias como por ejemplo los bloques de desglose, no puedes representarlos en UNA sola tabla, por ejemplo registros_facturacion, sino que tendrías que tener una segunda relacionada (por ejemplo registros_facturacion_desglose) que tenga todos los desgloses de cada RF.

Lo tenéis así?

Gracias

[Faneka]

Yo guardo tanto el XML completo que se envia (con los diferentes RF) como el RF de la factura. Luego en el programa estando en una factura doy la opción de abrir esos XML si se quieren ver.

[Jarogo08]

Empezado por rci

Gracias Jarogo08, después de escribir el post también me he planteado si hacia falta guardar el XML. De momento lo guardamos.
Si realmente el XML no lo usas, cuando dices que "se alimenta de UNA tabla", imagino que debe ser mas de una, porque a parte de que la tabla debe tener unas 100 columnas para guardar toda la información posible de un registro de facturación, los datos que pueden tener múltiples ocurrencias como por ejemplo los bloques de desglose, no puedes representarlos en UNA sola tabla, por ejemplo registros_facturacion, sino que tendrías que tener una segunda relacionada (por ejemplo registros_facturacion_desglose) que tenga todos los desgloses de cada RF.

Lo tenéis así?

Gracias

Buenas de nuevo rci

Es una única tabla que ahora mismo tiene 127 columnas (cremo que ya no crecerá más porque estamos con los últimos retoques y pruebas). En lo que se refiere a desglose, tenemos un máximo de 6 ivas por documento. Es una restricción que ya teníamos de antes, y por tanto en esta tabla tenemos los campos:

BaseImponible1,BaseImponible2,BaseImponible3,BaseImponible4,BaseImponible5,BaseImponible6
CuotaIva1,CuotaIva2,CuotaIva3,CuotaIva4,CuotaIva5,CuotaIva6
CuotaRecargo1,CuotaRecargo2,CuotaRecargo3,CuotaRecargo4,CuotaRecargo5,CuotaRecargo6
etc.

Y sólo le damos valores a los registros que correspondan. No me digas que no está muy bien planteado porque ya lo sé

Y en cuanto a los XML los guardamos en una carpeta del PC, en la base de datos sólo guardamos su ruta para poder abrirlos desde la pantalla correspondiente del programa

Saludos

[rci]

Empezado por Jarogo08

Buenas de nuevo rci

Es una única tabla que ahora mismo tiene 127 columnas (cremo que ya no crecerá más porque estamos con los últimos retoques y pruebas). En lo que se refiere a desglose, tenemos un máximo de 6 ivas por documento. Es una restricción que ya teníamos de antes, y por tanto en esta tabla tenemos los campos:

BaseImponible1,BaseImponible2,BaseImponible3,BaseImponible4,BaseImponible5,BaseImponible6
CuotaIva1,CuotaIva2,CuotaIva3,CuotaIva4,CuotaIva5,CuotaIva6
CuotaRecargo1,CuotaRecargo2,CuotaRecargo3,CuotaRecargo4,CuotaRecargo5,CuotaRecargo6
etc.

Y sólo le damos valores a los registros que correspondan. No me digas que no está muy bien planteado porque ya lo sé

Y en cuanto a los XML los guardamos en una carpeta del PC, en la base de datos sólo guardamos su ruta para poder abrirlos desde la pantalla correspondiente del programa

Saludos

Muchas gracias por la respuesta Jarogo08. Claro hecho de esta forma si es posible.

Saludos