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.

[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

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

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