Foros Club Delphi - Ley antifraude 2021 (VERIFACTU)

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)

- Internet (https://www.clubdelphi.com/foros/forumdisplay.php?f=3)

- - Ley antifraude 2021 (VERIFACTU) - Programas informáticos (https://www.clubdelphi.com/foros/showthread.php?t=95235)

Cita:

Empezado por keys (Mensaje 554134)

El problema es tener que obligar a todos tus clientes que se metan en VeriFactu, aunque es una opción a considerar y así se te olvidas de los eventos, inspecciones, etc....

Es una opción serie a considerar.
Al final al cliente en la mayoría de los casos le da igual la implementación (quiero pensar), mientras el sistema funcione y cumpla con la ley. Y la verdad es que tal y como está planteado, VERI*FACTU evita muchos problemas, simplifica el proceso y los requisitos son bastante más "normales".

A medida que avanza van saliendo noticias en otros medios. Pongo esta, porque el gráfico me ha parecido correcto y clarificador.
El "Gran Hermano" de Hacienda será con códigos QR: así se vigilará a las empresas a través de las facturas

Pero es muy posible que el cliente salga de la tienda lea el QR y la factura todavía no esté en hacienda si por ejemplo subimos todas las facturas en un servicio cada x minutos ¿no?

luego hay algo con los certificados, no sé si es una tontería o no, los que habéis trabajado con Ticketbai seguramente lo tengáis más que pensado o será algo con lo que me como el coco solamente. Veo que en la aplicación tendremos que indicar que es una aplicación verifactu (que enviará toda la información inmediatamente ). Normalmente los servidores no suelen tener instalados un certificado digital porque hasta ahora (quitando el SII) el certificado digital es algo que utilizaba el responsable de administración o alguien con responsabilidad. El Sii realmente no ha cambiado demasiado ese uso porque al enviarse cada cuatro días, todo el mundo facturaba y había un responsable que hacía el envío con el certificado. Pero esto es inmediato o casi inmediato. Estaba pensando en instalar un servicio de envío en un ordenador que no fuera el servidor y que este se dedicara solamente a enviar las facturas que se generen (este ordenador sí tendría el certificado ). Pero que pasa si ese ordenado no se enciende ( o bien por un problema o bien porque el cliente decide no encenderlo ) nosotros indicamos que es una aplicación verifactu pero no está enviando la información inmediatamente, y no sé como controlar eso. He visto que hay certificados de dispositivos y no sé si esto se instalaría en el servidor (he oído campanas pero no sé de donde vienen), estoy aquí imaginando problemas...

Cita:

Empezado por Neftali [Germán.Estévez] (Mensaje 554138)

Creo que ll de firmado elwctronicamente será solo en la opción de si no envías. Por lo demás bien

Cita:

Empezado por keno_71 (Mensaje 554139)

Pero es muy posible que el cliente salga de la tienda lea el QR y la factura todavía no esté en hacienda si por ejemplo subimos todas las facturas en un servicio cada x minutos ¿no?

No han dicho cual es el plazo para enviar, pero si no es inmediato, parece que pueder ser que si.

Cita:

Empezado por keno_71 (Mensaje 554139)

Estaba pensando en instalar un servicio de envío en un ordenador que no fuera el servidor y que este se dedicara solamente a enviar las facturas que se generen (este ordenador sí tendría el certificado ). Pero que pasa si ese ordenado no se enciende ( o bien por un problema o bien porque el cliente decide no encenderlo ) nosotros indicamos que es una aplicación verifactu pero no está enviando la información inmediatamente, y no sé como controlar eso.

Si optas por esa opción deberás asegurarte de que ese equipo funciona siempre. Dependerá de cómo esté configurado y como se comuniquen tus sistemas.
De alguna forma deberás controlar que esas facturas que generas, pasado X tiempo DEBAN tener una respuesta, si no es así, es que no se están enviando.

Cita:

Empezado por keno_71 (Mensaje 554139)

He visto que hay certificados de dispositivos y no sé si esto se instalaría en el servidor (he oído campanas pero no sé de donde vienen), estoy aquí imaginando problemas...

Si estás pensando en que envíe el servidor, pues instalas ese certificado en el servidor (a efectos prácticos es como uno normal, sólo que en lugar de identificar a una persona o empresa, identificaa un equipo.
Cuando pides un certificado personal das tu DNI y con eso quedan enlazados, cuando pides uno de dispositivo das el "SerialNumber" del dispositivo y con eso quedan enlazados.

Cita:

Empezado por Neftali [Germán.Estévez] (Mensaje 554141)

No han dicho cual es el plazo para enviar, pero si no es inmediato, parece que pueder ser que si.

Si optas por esa opción deberás asegurarte de que ese equipo funciona siempre. Dependerá de cómo esté configurado y como se comuniquen tus sistemas.
De alguna forma deberás controlar que esas facturas que generas, pasado X tiempo DEBAN tener una respuesta, si no es así, es que no se están enviando.

Si estás pensando en que envíe el servidor, pues instalas ese certificado en el servidor (a efectos prácticos es como uno normal, sólo que en lugar de identificar a una persona o empresa, identificaa un equipo.
Cuando pides un certificado personal das tu DNI y con eso quedan enlazados, cuando pides uno de dispositivo das el "SerialNumber" del dispositivo y con eso quedan enlazados.

Gracias Neftali!

Cita:

Empezado por Sistel (Mensaje 554135)

Hola,

Gracias por avisarnos, Ermendalenda.

Acabamos de enviar email con el texto:

A ver si tienen en cuenta el tema.

Saludos

Hola,

Parece que el email enviado a [email protected] ha sido rechazado por el servidor de correo de aeat.es

Código:

SMTP error from remote mail server after RCPT TO:<[email protected]>:

550 5.1.1 <[email protected]>: Recipient address rejected:

User unknown

Saludos

Cita:

Empezado por keys (Mensaje 554129)

Hola a todos.

Vamos a empezar a trabajar en esto de verifactu. Ya hemos desarrollado para TicketBAI, así que el cambio no es tan grande. Lo primero que veo es que hacienda ha lanzado todo esto pero lo tiene un poco verde, al menos la información que tenemos, seguramente hay algunas empresas (las de siempre, ya ha pasado en otros desarollos) que tienen más información.

He estado leyendo el foro, y veo que hay un poco de dudas sobre la fecha de factura, según TicketBAI (Hacienda te dice que también según el reglamento de facturación), la fecha de factura tiene que ser igual a la fecha del día que se genera, ni antes ni después. Hemos tenido varias discusiones con clientes y hacienda y eso es lo que te contestan. De hecho los programas que han hecho en hacienda para los que hacen pocas facturas no se puede modificar la fecha de factura, otra cosa es la fecha de operación.

Una consulta muy recurrente que hacían los clientes es, Es que yo hago las facturas el viernes con fecha del lunes para así tenerlas preparadas, pues no se puede. Nosotros lo que hacemos es generar una prefacturación y luego el día que quiere hace las facturas, pero siempre con la fecha del día que se genera las facturas.

Una diferencia que he encontrado respecto a TicketBAI y el SII es que no hay que indicar si el desglose es a nivel de factura o a nivel de operación. Me imagino que por eso las empresas que hacen el SII no tiene por que hacer todo esto. En las Haciendas forales es al revés, el que entra en TicketBAI ya no tiene que enviar las facturas emitidas al SII.

Otra diferencia que veo es que las anulaciones hay que tenerlas en cuenta en el encadenamiento de las facturas, en TicketBAI.

Me llama la atención toda la información que hay que enviar del sistema informático. También veo que respecto a TicketBAI el mayor cambio y del cual no hay mucha información es el tema de los eventos. Entiendo que todo esto es por no obligar a todo el mundo a entrar en VErifactu, como han hecho en las forales que todo el mundo (salvo pocos casos) tienen que entrar en TicketBAI.

Gracias por la aportación.
Al hilo de esta información, que ocurriría si tienes que emitir una factura el día 16 de abril (último día para emitir las facturas de empresarios o profesionales ) y resulta que te cae el sistema el día 15 y no lo restauras hasta el día 18, por ejemplo. Tendrías que emitir la factura con fecha 18 de abril, cuando tienes el sistema restaurado. Esta factura emitida está mal y te van a solicitar una rectificativa de la misma con fecha de expedición 16 de abril.
¿ Has contemplado esa posibilidad ?

Cita:

Empezado por sglorka (Mensaje 554170)

En este caso hacienda tendrá que decir hay que hacer. Te puedo decir lo que dice por ejemplo la hacienda de Alava en TicketBAI

Cita:

Artículo 17. Incidencias de carácter técnico en el cumplimiento de la obligación TicketBAI

1. En los supuestos excepcionales de interrupción del servicio eléctrico, de destrucción, fallo, avería, rotura u otras circunstancias en las que la o el contribuyente no pueda generar ficheros TicketBAI ni expedir factura o justificante empleando el software TicketBAI, y éstas deban ser expedidas en el momento de realizarse la operación, dicha circunstancia se notificará a la Administración Tributaria y la o el contribuyente expedirá y entregará factura o justificante por otros medios a la persona o entidad destinataria, conservando copia del mismo.
La factura o justificante se consignará a una serie específica que se destinará únicamente a las facturas o justificantes expedidos en virtud de lo dispuesto en este artículo, y contendrá la expresión “factura o justificante expedido según lo dispuesto en el artículo 17 del Decreto Foral por el que se desarrolla la obligación TicketBAI”

2. La o el contribuyente, tan pronto como desaparezca el motivo que imposibilite la generación de ficheros TicketBAI y la expedición de factura o justificante empleando el software TicketBAI, deberá introducir correlativa y sucesivamente en su software TicketBAI los datos de todas las facturas y justificantes expedidos, generando los ficheros TicketBAI y enviándolos a la Administración Tributaria.
La factura o justificante expedido por el software TicketBAI tendrá la consideración de duplicado.
En cualquier caso, la persona o entidad destinataria de la operación podrá solicitar un duplicado
de la factura o justificante emitido, que contemple el código TicketBAI y el código QR.

3. En los supuestos excepcionales de falta temporal de cobertura, interrupción del servicio telefónico o telemático, avería del sistema de envío u otras circunstancias en las que la o el contribuyente pueda generar ficheros TicketBAI pero no pueda enviarlos a la Administración Tributaria, el software TicketBAI acumulará sucesivamente todos los ficheros TicketBAI generados y procederá a su envío tan pronto se restablezca la conexión.”

Gracias por la información.
Confirmamos entonces que puede ocurrir que el fechado de registros de facturación (Fecha hora y minuto) puede diferir de la fecha de emisión del registro.
¿ Se te ha dado el caso de tener que emitir una factura rectificativa que corrige la fecha de expedición de una factura expedida en fecha incorrecta ?. Este caso no es atribuible a error técnico, en este caso el cliente se olvida de que tiene que facturar y lo hace pasado el plazo de legal ( antes del día 16 del mes siguiente al periodo de devengo para empresarios y profesionales ). En este caso también habría diferencias entre la fecha de fechado de registro y la fecha de expedición.

Cita:

Empezado por sglorka (Mensaje 554177)

LA fecha de expedición siempre tiene que ser el día actual, otra cosa es la fecha de operación. Si puede haber una rectificativa por que te has equivocado en la fecha de la factura original, pero siempre tendrá que tener la fecha del día (Yo en ese caso si no la ha enviado ni al cliente, la anulaba).

Por otro lado, si alguien se olvida de hacer la facturación es asunto suyo. En ese caso tendrá que hacer la facturación con la fecha de factura de cuando las haga y en su caso cambiar la fecha de operación.

Solo por aportar algo en el tema de los cifs correctos o no. Una de nuestros clientes a enviado una factura a TicketBAI y hacienda le ha devuelto el aviso siguiente

Cita:

El NIF del destinatario tiene un formato erróneo

Todo por que era una persona física y han puesto los apellidos en distinto orden:eek:. Sólo para que veáis lo importante que tener validado todo. Esto mismo ocurre en el SII.

Cita:

Empezado por Sistel (Mensaje 554163)

Hola,

Parece que el email enviado a [email protected] ha sido rechazado por el servidor de correo de aeat.es

Código:

SMTP error from remote mail server after RCPT TO:<[email protected]>:

550 5.1.1 <[email protected]>: Recipient address rejected:

User unknown

Saludos

Pues ya solo queda [email protected]
y mandale lo que te ha pasado en periodo de consulta.

Registro de eventos

Bueno. creia que los que ibamos a adaptaar el software solo para envios directos nos ibamos a librar del registro de eventos, supongo que solo será en ciertos casos.
Por que una consulta a verifactu, nos hacen referencia a que en ese caso hay que generar el evento del error.
Ahora, además, me queda la duda si el evento se envia

Cita:

Empezado por keys (Mensaje 554178)

Siento discrepar.
Entonces la consulta vinculante a la que hago referencia el post de hace unos días donde se constata que hay que emitir una factura rectificativa por sustitución para enmendar una anterior emitida con fecha de expedición incorrecta, no se puede realizar en Verifactu ???
La fecha de operación de una factura es la fecha en que se entregan los bienes o se presta el servicio, si el cliente no es profesional o empresario entonces coincide con la fecha de expedición. Si es empresario o profesional, entonces la fecha de operación puede distinta de la fecha de expedición.
La fecha de operación de una factura rectificativa es la fecha de expedición de la factura que rectifica.
He hecho la consulta a Verifactu a ver qué me responden. Pondré la contestación en el foro.

Buenas noches.

Ya he conseguido generar un xml mediante la función GetsfSOAP.

Código:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding">

<SOAP-ENV:Body xmlns:NS1="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SistemaFacturacion.wsdl" xmlns:NS2="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd" xmlns:NS3="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">

<NS1:AltaFactuSistemaFacturacion SOAP-ENV:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

<AltaFactuSistemaFacturacion SOAP-ENC:id="1" xsi:type="NS2:AltaFactuSistemaFacturacion">

<Cabecera SOAP-ENC:id="2" xsi:type="NS3:Cabecera">

<IDVersion xsi:type="NS3:VersionType">1.0</IDVersion>

<ObligadoEmision SOAP-ENC:id="3" xsi:type="NS3:PersonaFisicaJuridicaESType">

<NombreRazon xsi:type="xsd:string">EMPRESA VENDEDORA</NombreRazon>

<NIF xsi:type="xsd:string">56423076R</NIF>

</ObligadoEmision>

<TipoRegistroAEAT xsi:type="NS3:TipoRegistroAEATType">T0</TipoRegistroAEAT>

</Cabecera>

<item SOAP-ENC:id="4" xsi:type="NS2:FacturasEmitidasType">

<RegistroFacturacion SOAP-ENC:id="5" xsi:type="NS3:RegistroFacturacionType">

<IDFactura SOAP-ENC:id="6" xsi:type="NS3:IDFacturaExpedidaType">

Tengo el problema que al querer abrirlo con un TXMLDocument, me da el siguiente error

Cita:

Element "SOAP-ENV:Body" does not contain a single text node

¿Puede ser que sea porque es muy largo?

Ha sido el código que ha generado automáticamente.

Muchas Gracias.

Me respondo yo mismo.
He conseguido solventar el problema utilizando GetLocalName en vez de Text

Pero me he dado cuenta de un detalle

Código:



<SOAP-ENV>

<SOAP-ENV:Body >

<NS1:AltaFactuSistemaFacturacion>

<AltaFactuSistemaFacturacion>

<Cabecera SOAP-ENC:id="2" xsi:type="NS3:Cabecera">

........

........

</Cabecera>



<item SOAP-ENC:id="4" xsi:type="NS2:FacturasEmitidasType">

<RegistroFacturacion>

.....

......

El nombre de etiqueta, sale item en vez FacturasEmitidasType.

Sabéis de qué puede ser ?

Muchas Gracias.

Cita:

Empezado por Neftali [Germán.Estévez] (Mensaje 553902)

A mi los tres ficheros generados con esas opciones me resultan similares.
Completando el código que has puesto, la llamada podría ser similar a esta:

En este caso genera un fichero como este:

Código:

<?xml version="1.0"?>

<SOAP-ENV:Envelope.......">

    <SOAP-ENV:Body..........>

        <NS1:AltaFactuSistemaFacturacion SOAP-ENV:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

            <AltaFactuSistemaFacturacion SOAP-ENC:id="1" xsi:type="NS2:AltaFactuSistemaFacturacion">

                <Cabecera SOAP-ENC:id="2" xsi:type="NS3:Cabecera">

                     .......

                     .......

                </Cabecera>

                <item SOAP-ENC:id="4" xsi:type="NS2:FacturasEmitidasType">

                    <RegistroFacturacion SOAP-ENC:id="5" xsi:type="NS3:RegistroFacturacionType">

                        .......

                        .......



                    </RegistroFacturacion>

                    <DatosControl xsi:nil="true"/>

                </item>

            </AltaFactuSistemaFacturacion>

        </NS1:AltaFactuSistemaFacturacion>

    </SOAP-ENV:Body>

 </SOAP-ENV:Envelope>

Parece que no sólo me pasa a mi, lo que no sé si es normal o es un error que genera el código importado(wsdl).

Saludos.

Cita:

Empezado por sglorka (Mensaje 554183)

Eso es lo que digo, la fecha de factura de la rectificativa es la fecha del día que se esta generando y la fecha de operación es la fecha de la factura que se esta rectificando o al menos en TicketBAI y en el SII.

Cita:

Empezado por keys (Mensaje 554200)

A ver, lo que yo entiendo, es esto (ya que no hay un nodo de fecha operación en Ticketbai ni en Verifactu):

La fecha de la sustituida va en su nodo

Código:

   <FacturasRectificadasSustituidas>

   - <IDFacturaRectificadaSustituida>

     <SerieFactura>12.1.1</SerieFactura> 



    <NumFactura>8</NumFactura> 



    <FechaExpedicionFactura>15-01-2024</FechaExpedicionFactura> 



   </IDFacturaRectificadaSustituida>





   </FacturasRectificadasSustituidas>

Y la de "operación" (que no existe ya que es la fecha de expedición) en el suyo que tiene que coincidir con el dia que hago la rectificación

Código:



 <Factura>

   - <CabeceraFactura>





<SerieFactura>12.1.4</SerieFactura> 



    <NumFactura>1</NumFactura> 



    <FechaExpedicionFactura>29-01-2024</FechaExpedicionFactura> 



    <HoraExpedicionFactura>11:04:11</HoraExpedicionFactura> 



    <FacturaSimplificada>S</FacturaSimplificada>

....

Ten en cuenta de que en un solo registro de rectificación podemos incluir varias facturas rectificadas, pero solo hay un nodo de fecha de expedición para la factrura rectificativa(Y no de operación), con lo cual no cabe meter las fechas de operación de cada factura si no es en cada uno de sus nodos de <FacturasRectificadasSustituidas>ç

En TicketBAI y en Verifactu si existe el campo fecha de operación y el campo fecha factura.

El día 01/01/2024 hago una factura y será :
Fecha Factura : 01/01/2024
Fecha Operación : 01/01/2024 o anterior

El día 06/01/2024 tengo que hacer una rectificativa de esta factura.
Fecha Factura : 06/01/2024
Fecha Operación : 01/01/2024 //la fecha de la factura que estoy rectificando

Si hay varias rectificadas en la misma factura hay que poner en fecha de operación la de la factura más reciente.

Todo esto es así en TicketBAI y en el SII, me imagino que será igual en VERIFACTU

Cita:

Empezado por keys (Mensaje 554204)

Ok he visto que es un campo opcional, por eso no lo ponia yo, voy tambien a consultarlo a verifactu para asegurarme.

Cita:

Empezado por ermendalenda (Mensaje 554208)

Ok he visto que es un campo opcional, por eso no lo ponia yo, voy tambien a consultarlo a verifactu para asegurarme.

El campo Fecha de operación es un campo que nadie tenía en cuenta hasta ahora, pero en TicketBAI y es esto pasa a ser muy importante. Ya que la fecha de factura tiene que ser igual al día actual.;)

Cita:

Empezado por ermendalenda (Mensaje 554182)

Bueno. creia que los que ibamos a adaptaar el software solo para envios directos nos ibamos a librar del registro de eventos, supongo que solo será en ciertos casos.

Los registros de eventos están definidos por el artículo 8.3 del RDL 1007/23, y el artículo 14.1 piede que haya acceso a ellos. Luego viene el artículo 16 quién... exente de cumplir los artñiculos 8 y 14, por ser estos cubiertos por la funcionalidades del sistema de registración en Hacienda.
Por su parte, el proyecto de OM es claro (artículo 3, Particularidades aplicables a los “Sistemas VERI*FACTU”): «[...] en tanto actúen como sistemas VERI*FACTU, no les serán de aplicación los artículos [...] y 9 de esta orden.» Y aunque sea de manera indirecta, el artículo 2 escribe: «[...] la gestión de los registros de facturación y, en su caso, de eventos de [...]».
Lo leo como qué cuando estás en modo Veri*factu, no tienes que preocuparte de los registros de eventos, Hacienda se hace cargo.

Cita:

Por que una consulta a verifactu, nos hacen referencia a que en ese caso hay que generar el evento del error.

¿Puede ser que hacen referencia al contenido del campo «Incidencia», que a mi juicio tiene una lógica similar a un "evento de error" por un sistema Veri*factu? (O.M: artículo 16.5)

Cita:

Ahora, además, me queda la duda si el evento se envia

En el protocolo que han propuesto hasta la fecha, no hay forma de enviar registros de eventos en formato estructurado (a la imagen de lo descrito en el artículo 8.3). Cuando sí está previsto para los requerimientos.
Es cierto que pueden faltar cosas (como por ejemplo una interfaz de consulta, que parece está algo prevista). Pero para los eventos en modo Veri*factu, no hay nada previsto.
Además una parte importante de las especificaciones de eventos tal como se describen en la O.M., es el hecho de ir firmados en el instante de su generación. Si en un sistema Veri*factu no hay firma, creería una avenida enorme para problemas de integridad de estos registros de eventos.

Cita:

Empezado por keys (Mensaje 554204)

Creo que keys lo tiene claro pero para rematarlo un poco más, la fecha operación de la rectificativa no tiene que ser la fecha factura de la factura rectificativa; debe ser la fecha de la operación inicial (o la última de las fechas si hay varias). Entonces 01/01/24 únicamente si la fecha operación de la factura inicial es el 01/01/24 (o no está indicada); si la fecha operación de la inicial era algo de 2021, ese fecha debe ser la que se indica en la fecha de operación de la rectificativa.

Buenas, ¿se sabe si hay alguna url de pruebas para ir probando los ficheros de Verifactu al igual que su día hubo para Ticket Bai? ¿Hay que darse de alta en algún sitio para registrar el software? No he visto nada en la documentación publicada

Cita:

Empezado por skatologiko (Mensaje 554216)

Que se sepa, no hay todavía.

registro de eventos

Bueno como voy bien voy a adelantarme a crear al menos registro de eventos de los posibles errores por fallos de las BD por errores de disco...
Aqui os dejo, por si os sirve, lo que he sacado de la excell sobre los eventos.

Código:

<?xml version="1.0" encoding="UTF-8"?>

<RegistroEvento>

    <IDVersion>1.0</IDVersion>

    <Evento>

        <SistemaInformatico>

            <NombreRazon>SOFTWARE GARANTIZADO VERI*FACTU PRUEBA</NombreRazon>

            <NIF>A99800005</NIF>

            <IdSistemaInformatico>01</IdSistemaInformatico>

            <Version>1.0.03</Version>

            <NumeroInstalacion>00000006Y NCentro:12 NTPV:1</NumeroInstalacion>

        </SistemaInformatico>

        <ObligadoEmision>

            <NombreRazon>Prueba</NombreRazon>

            <NIF>00000006Y</NIF>

        </ObligadoEmision>

        <FechaGenRegistro>24-01-2024</FechaGenRegistro>

        <HoraGenRegistro>12:46:24</HoraGenRegistro>

        <HusoHorarioGenRegistro>02</HusoHorarioGenRegistro>

        <TipoEvento>

            <!--OPCIONES-->

            <!--01    Instalacion o puesta en marcha inicial del sistema informatico.-->

            <!--02    Inicio del funcionamiento del sistema informatico como sistema VERI*FACTU.-->

            <!--03    Fin del funcionamiento del sistema informatico como sistema VERI*FACTU.-->

            <!--04    Lanzamiento del proceso de deteccion de anomalias en los registros de facturacion.-->

            <!--05    Deteccion de anomalias en la integridad, inalterabilidad y trazabilidad de registros de facturacion.-->

            <!--06    Lanzamiento del proceso de deteccion de anomalias en los registros de eventos.-->

            <!--07    Deteccion de anomalias en la integridad, inalterabilidad y trazabilidad de registros de eventos.-->

            <!--08    Restauracion de copia de seguridad. -->

            <!--09    Exportacion de registros de facturacion generados en un periodo.-->

            <!--10    Exportacion de registros de eventos generados en un periodo.-->

            <!--11    Registro resumen de eventos-->

        </TipoEvento>

        <DatosPropiosEvento>

        <!--Opcional-->

            <LanzamientoProcesoDeteccionAnomaliasRegFacturacion>

                <RealizadoProcesoSobreIntegridadHuellasRegFacturacion/>            

                    <!--"Indica si se ha lanzado algun proceso de deteccion de anomalias sobre la integridad de las huellas de los registros de facturacion."    Alfanumerico (1)  L11-->

                <NumeroDeRegistrosFacturacionProcesadosSobreIntegridadHuellas/>

                    <!--"Numero de registros de facturacion analizados por el proceso sobre la integridad de las huellas."    Numerico (7) -->

                <RealizadoProcesoSobreIntegridadFirmasRegFacturacion/>

                    <!--"Indica si se ha lanzado algun proceso de deteccion de anomalias sobre la integridad de las firmas  de los registros de facturacion."    Alfanumerico (1)  L11-->

                <NumeroDeRegistrosFacturacionProcesadosSobreIntegridadFirmas/>

                    <!--"Numero de registros de facturacion analizados por el proceso sobre la integridad de la firma."    Numerico (7) -->                                                                                    

                <RealizadoProcesoSobreTrazabilidadCadenaRegFacturacion/>

                    <!--"Indica si se ha lanzado algun proceso de deteccion de anomalias sobre la trazabilidad del encadenamiento  de los registros de facturacion."    Alfanumerico (1)  L11-->

                <NumeroDeRegistrosFacturacionProcesadosSobreTrazabilidadCadena/>

                    <!--"Numero de registros de facturacion analizados por el proceso sobre la trazabilidad del encadenamiento."    Numerico (7) -->

                <RealizadoProcesoSobreTrazabilidadFechasRegFacturacion/>

                    <!--"Indica si se ha lanzado algun proceso de deteccion de anomalias sobre la trazabilidad de las fechas de los registros de facturacion."    Alfanumerico (1)  L11-->

                <NumeroDeRegistrosFacturacionProcesadosSobreTrazabilidadFechas/>

                    <!--"Numero de registros de facturacion analizados por el proceso sobre la trazabilidad de las fechas."    Numerico (7) -->

            </LanzamientoProcesoDeteccionAnomaliasRegFacturacion>

            <DeteccionAnomaliasRegFacturacion>

                <!--Opcional-->

                <TipoAnomalia/>

                    <!--"Tipo de anomalia detectado."    Alfanumerico (2)  L1E-->

                <OtrosDatosAnomalia/>

                    <!--"Otros datos de interes o explicacion adicional que el sistema informatico pueda aportar sobre la anomalia detectada."    Alfanumerico (100) -->

                <RegistroFacturacionAnomalo>    

                    <IDEmisorFactura>    

                        <NIF/>

                            <!--"ID del obligado a expedir la factura a que se refiere el registro de facturacion anomalo."    FormatoNIF (9) -->

                    </IDEmisorFactura>    

                    <NumSerieFactura/>

                        <!--N SerieN. Factura a que se refiere el registro de facturacion anomalo. "    Alfanumerico (60) -->

                    <FechaExpedicionFactura/>

                        <!--"Fecha de expedicion de la factura a que se refiere el registro de facturacion anomalo."    Fecha (dd-mm-yyyy) -->

                </RegistroFacturacionAnomalo>    

            </DeteccionAnomaliasRegFacturacion>

            <LanzamientoProcesoDeteccionAnomaliasRegEventos>

                <!--Opcional-->

                <RealizadoProcesoSobreIntegridadHuellasRegEventos/>

                    <!--"Indica si se ha lanzado algun proceso de deteccion de anomalias sobre la integridad de las huellas de los registros de eventos."    Alfanumerico (1)  L11-->

                <NumeroDeRegistrosEventosProcesadosSobreIntegridadHuellas/>

                    <!--"Numero de registros de eventos analizados por el proceso sobre la integridad de las huellas."    Numerico (5) -->

                <RealizadoProcesoSobreIntegridadFirmasRegEventos/>

                    <!--"Indica si se ha lanzado algun proceso de deteccion de anomalias sobre la integridad de las firmas de los registros de eventos."    Alfanumerico (1)  L11-->

                <NumeroDeRegistrosEventosProcesadosSobreIntegridadFirmas/>

                    <!--"Numero de registros de eventos analizados por el proceso sobre la integridad de la firma."    Numerico (5) -->

                <RealizadoProcesoSobreTrazabilidadCadenaRegEventos/>

                    <!--"Indica si se ha lanzado algun proceso de deteccion de anomalias sobre la trazabilidad del encadenamiento de los registros de eventos."    Alfanumerico (1)  L11-->

                <NumeroDeRegistrosEventosProcesadosSobreTrazabilidadCadena/>

                    <!--"Numero de registros de eventos analizados por el proceso sobre la trazabilidad del encadenamiento."    Numerico (5) -->

                <RealizadoProcesoSobreTrazabilidadFechasRegEventos/>

                    <!--"Indica si se ha lanzado algun proceso de deteccion de anomalias sobre la trazabilidad de las fechas de los registros de eventos."    Alfanumerico (1)  L11-->

                <NumeroDeRegistrosEventosProcesadosSobreTrazabilidadFechas/>

                    <!--"Numero de registros de eventos analizados por el proceso sobre la trazabilidad de las fechas."    Numerico (5) -->

            </LanzamientoProcesoDeteccionAnomaliasRegEventos>

            <DeteccionAnomaliasRegEventos>

                <!--Opcional-->

                <TipoAnomalia/>

                    <!--"Tipo de anomalia detectada."    Alfanumerico (2)  L1E-->

                <OtrosDatosAnomalia/>

                    <!--"Otros datos de interes o explicacion adicional que el sistema informatico pueda aportar sobre la anomalia detectada."    Alfanumerico (100) -->

                <RegEventoAnomalo>

                    <TipoEvento/>

                        <!--"Tipo de evento detectado como anomalo."    Alfanumerico (2)  L2E-->

                    <FechaEvento/>

                        <!--"Fecha del evento detectado como anomalo."    Fecha (dd-mm-yyyy) -->

                    <HoraEvento/>

                        <!--"Hora del evento detectado como anomalo."    Hora (hh:mm:ss) -->

                    <HusoHorarioEvento/>

                        <!--"Huso horario del evento detectado como anomalo."    Alfanumerico (2)  L13-->

                </RegEventoAnomalo>

            </DeteccionAnomaliasRegEventos>

            <ExportacionRegFacturacionPeriodo>

                <!--Opcional-->

                <FechaInicioPeriodoExport/>

                    <!--"Fecha inicial del periodo a exportar."    Fecha (dd-mm-yyyy) -->

                <HoraInicioPeriodoExport/>

                    <!--"Hora inicial del periodo a exportar."    Hora (hh:mm:ss) -->

                <FechaFinPeriodoExport/>

                    <!--"Fecha final del periodo a exportar."    Fecha (dd-mm-yyyy) -->

                <HoraFinPeriodoExport/>

                    <!--"Hora final del periodo a exportar."    Hora (hh:mm:ss) -->

                <HusoHorarioPeriodoExport/>

                    <!--"Huso horario de la hora inicial y de la hora final del periodo a exportar."    Alfanumerico (2)  L13-->

                <RegistroFacturacionInicialPeriodo>

                    <IDEmisorFactura>    

                        <NIF/>

                            <!--"ID del obligado a expedir la factura a que se refiere el primer registro de facturacion del periodo exportado."    FormatoNIF (9) -->

                    </IDEmisorFactura>    

                    <NumSerieFactura/>

                        <!--"N. Serie N. Factura  de la factura a que se refiere el primer registro de facturacion del periodo."    Alfanumerico (60) -->

                    <FechaExpedicionFactura/>

                        <!--"Fecha de expedicion de la factura  a que se refiere el primer registro de facturacion del periodo. "    Fecha (dd-mm-yyyy) -->

                    <Huella/>

                        <!--"Huella del primer registro de facturacion del periodo. "    Alfanumerico (64) -->

                </RegistroFacturacionInicialPeriodo>

                <RegistroFacturacionFinalPeriodo>

                    <IDEmisorFactura>    

                        <NIF/>

                            <!--"ID del obligado a expedir la factura a que se refiere el ultimo registro de facturacion del periodo exportado."    FormatoNIF (9) -->

                    </IDEmisorFactura>    

                    <NumSerieFactura/>

                        <!--"N. Serie N. Factura  de la factura a que se refiere el ultimo registro de facturacion del periodo."    Alfanumerico (60) -->

                    <FechaExpedicionFactura/>

                        <!--"Fecha de expedicion de la factura correspondiente al ultimo registro de facturacion del periodo. "    Fecha (dd-mm-yyyy) -->

                    <Huella/>

                        <!--"Huella del ultimo registro de facturacion del periodo. "    Alfanumerico (64) -->

                </RegistroFacturacionFinalPeriodo>

                <NumeroDeRegistrosFacturacionAltaExportados/>

                    <!--"Numero de registros de facturacion de alta exportados para el periodo."    Numerico (9) -->

                <SumaImporteTotalAlta/>

                    <!--Opcional-->

                <NumeroDeRegistrosFacturacionAnulacionExportados/>

                    <!--"Numero de registros de facturacion de anulacion exportados para el periodo."    Numerico (9) -->

                <SumaImporteTotalAnulacion/>

                    <!--"Suma del Importe total de las facturas a que se refieren todos los registros de facturacion de anulacion exportados para el periodo."    Decimal (12,2) -->

                <RegistrosFacturacionExportadosDejanDeConservarse/>

                    <!--"Indica si los registros de facturacion exportados para el periodo dejan (o no) de conservarse en el sistema informatico."    Alfanumerico (1)  L11-->

            </ExportacionRegFacturacionPeriodo>

            <ExportacionRegEventosPeriodo>

                <!--Opcional-->

                <FechaInicioPeriodoExport/>

                <HoraInicioPeriodoExport/>

                <FechaFinPeriodoExport/>

                <HoraFinPeriodoExport/>

                <HusoHorarioPeriodoExport/>

                <RegistroEventoInicialPeriodo>

                    <TipoEvento/>        

                        <!--"Tipo de evento del primer reg. de eventos del periodo exportado."    Alfanumerico (2)  L2E-->

                    <FechaEvento/>        

                        <!--"Fecha del primer reg. de eventos del periodo exportado."    Fecha (dd-mm-yyyy) -->

                    <HoraEvento/>        

                        <!--"Hora del primer reg. de eventos del periodo exportado."    Hora (hh:mm:ss) -->

                    <HusoHorarioEvento/>        

                        <!--"Huso horario del primer reg. de eventos del periodo exportado."    Alfanumerico (2)  L13-->

                </RegistroEventoInicialPeriodo>

                <RegistroEventoFinalPeriodo>

                    <TipoEvento/>        

                        <!--"Tipo de evento del ultimo reg. de eventos del periodo exportado."    Alfanumerico (2)  L2E-->

                    <FechaEvento/>

                        <!--"Fecha del ultimo reg. de eventos del periodo exportado."    Fecha (dd-mm-yyyy) -->

                    <HoraEvento/>

                        <!--"Hora del ultimo reg. de eventos del periodo exportado."    Hora (hh:mm:ss) -->

                    <HusoHorarioEvento/>

                        <!--"Huso horario del ultimo reg. de eventos del periodo exportado."    Alfanumerico (2)  L13-->

                </RegistroEventoFinalPeriodo>

                <NumeroDeRegEventosExportados/>                    

                    <!--"Numero de registros de eventos exportados para el periodo indicado."    Numerico (7) -->

                <EventosExportadosDejanDeConservarse/>            

                    <!--"Indica si los eventos exportados para el periodo indicado dejan de conservarse (o no) en el sistema informatico."    Numerico (7) -->

            </ExportacionRegEventosPeriodo>

            <ResumenEventos>

                <!--Opcional-->

                <TipoEvento>

                    <!--(1 20)1-->

                    <TipoEvento/>

                        <!--"Tipo de evento al que va a referirse la informacion que va a inmediatamente a continuacion de este campo."    Alfanumerico (1)  L11-->

                    <NumeroDeEventos/>

                        <!--"Numero de eventos del tipo que indica el campo anterior que se han producido en el periodo (desde que se genero el ultimo registro de resumen de eventos hasta el actual registro de resumen de eventos que se esta generando)."    Numerico (4) -->

                </TipoEvento> 

                <RegistroFacturacionInicialPeriodo>

                    <IDEmisorFactura>

                        <NIF/>

                            <!--"ID del obligado a expedir la factura a que se refiere el primer registro de facturacion del periodo (desde que se genero el ultimo registro de resumen de eventos hasta el actual registro de resumen de eventos que se esta generando)."    FormatoNIF (9) -->

                    </IDEmisorFactura>

                    <NumSerieFactura/>

                        <!--"N. Serie N. Factura  de la factura a que se refiere el primer registro de facturacion del periodo (desde que se genero el ultimo registro de resumen de eventos hasta el actual registro de resumen de eventos que se esta generando)."    Alfanumerico (60) -->

                    <FechaExpedicionFactura/>

                        <!--"Fecha de expedicion de la factura  a que se refiere el primer registro de facturacion del periodo. "    Fecha (dd-mm-yyyy) -->

                    <Huella/>

                        <!--"Huella del primer registro de facturacion del periodo. "    Alfanumerico (64) -->

                </RegistroFacturacionInicialPeriodo>

                <RegistroFacturacionFinalPeriodo>

                    <IDEmisorFactura>

                        <NIF/>    

                            <!--"ID del obligado a expedir la factura a que se refiere el ultimo registro de facturacion del periodo (desde que se genero el ultimo registro de resumen de eventos hasta el actual registro de resumen de eventos que se esta generando)."    FormatoNIF (9) -->

                    </IDEmisorFactura>

                    <NumSerieFactura/>

                        <!--"N. Serie N. Factura  de la factura a que se refiere el ultimo registro de facturacion del periodo (desde que se genero el ultimo registro de resumen de eventos hasta el actual registro de resumen de eventos que se esta generando). "    Alfanumerico (60) -->

                    <FechaExpedicionFactura/>

                        <!--"Fecha de expedicion de la factura correspondiente al ultimo registro de facturacion del periodo. "    Fecha (dd-mm-yyyy) -->

                    <Huella/>

                        <!--"Huella del ultimo registro de facturacion del periodo. "    Alfanumerico (64) -->

                </RegistroFacturacionFinalPeriodo>

                <NumeroDeRegistrosFacturacionAltaGenerados/>

                    <!--"Numero de registros de facturacion de alta generados en el periodo(desde que se genero el ultimo registro de resumen de eventos hasta el actual registro de resumen de eventos que se esta generando)."    Numerico (6) -->

                <SumaImporteTotalAlta/> 

                    <!--Suma del Importe total de las facturas de todos los registros de facturacion de alta del periodo (desde que se genero el ultimo registro de resumen de eventos hasta el actual registro de resumen de eventos que se esta generando)."    Decimal (12,2) -->

                <NumeroDeRegistrosFacturacionAnulacionGenerados/>

                    <!--"Numero de registros de facturacion de anulacion generados en el periodo (desde que se genero el ultimo registro de resumen de eventos hasta el actual registro de resumen de eventos que se esta generando)."    Numerico (6) -->

                <SumaImporteTotalAnulacion/>

                    <!--"Suma del Importe total de las facturas a que se refieren todos los registros de facturacion de anulacion del periodo (desde que se genero el ultimo registro de resumen de eventos hasta el actual registro de resumen de eventos que se esta generando)."    Decimal (12,2) -->

            </ResumenEventos>

        </DatosPropiosEvento>

        <OtrosDatosEvento/>

            <!--"Cualquier dato o conjunto de datos adicionales que el sistema informatico considere de interes sobre el evento registrado."    Alfanumerico (100) -->

        <EncadenamientoEventoAnterior>

            <TipoEventoAnterior/>

                <!--"Tipo de evento anterior."    Alfanumerico (2)  L2E-->

            <FechaEventoAnterior/>

                <!--"Fecha de generacion  del registro del evento anterior."    Fecha (dd-mm-yyyy) -->

            <HoraEventoAnterior/>

                <!--"Hora de generacion del registro del evento anterior."    Hora (hh:mm:ss) -->

            <HusoHorarioEventoAnterior/>

                <!--"Huso horario usado por el sistema informatico de facturacion en el momento de generacion del registro del evento anterior."    Alfanumerico (2)  L13-->

            <HuellaEventoAnterior/>

                <!--"Huella de evento anterior."    Alfanumerico (64) -->

        </EncadenamientoEventoAnterior>

    </Evento>

    <DatosControl>

        <TipoHash/>

            <!--"Tipo de Hash aplicado para obtener las huellas."    Alfanumerico (2)  L12-->

        <HuellaEvento/>                    

            <!--"Huella del evento (Realizada sobre el nodo Evento)"    Alfanumerico (64) -->

        <Firma/>

            <!--"Bloque de firma electronica de la huella del evento."    -->

        <HuellaFirma/>    

            <!--"Huella de la firma, a calcular en el caso de utilizar sellado de tiempo (que se hara sobre esta huella de la firma)."    Alfanumerico (64) -->

        <TipoSelladoTiempo/>                

            <!--"Tipo de sellado de tiempo empleado, aplicado sobre la huella de la firma."    Alfanumerico (1)  L3E-->

        <SelladoTiempo/>            

            <!--"Bloque correspondiente al sellado de tiempo de la huella de la firma, conteniendo la informacion necesaria para su verificacion, con la estructura y formato que aplique al tipo de sellado de tiempo empleado."    -->

    </DatosControl>

</RegistroEvento>

Fechado de registro distinto de fecha de expedición

Buenos días.
Ya tengo la contestación de VeriFactu, que creo que arroja bastante luz, al tema del que hablábamos relativo a, si se puede o no, generar una factura con fecha de expedición anterior al día en curso.

Esta es la pregunta que yo les hago :

Buenas tardes
Tengo una consulta referente a la emisión de una factura rectificativa por sustitución en el caso en que se haya expedido con fecha incorrecta, una factura a empresario o profesional en primera instancia. Si la factura emitida tiene una fecha de expedición, 18 de abril, que resulta ser incorrecta ya que tenía que haber sido expedida con fecha 16 de abril (plazo límite de emisión de facturas para empresarios o profesionales) ¿Podría emitir una factura rectificativa por sustitución, de la emitida en primera instancia, corrigiendo su fecha de expedición a 16 de abril ?. En este caso, el registro de facturación generado será fechado el 18 de abril pero su fecha de expedición será 16 de abril.
¿ Hay algún problema en ello ?

Gracias por su tiempo

y la respuesta que ellos me dan es la siguiente:

Buenos días:

No debería haber ningún problema, puesto que la fecha de expedición sí que puede ser anterior a la fecha actual (pero no puede ser posterior).

Además, se debe tener en cuenta que VERI*FACTU implica el envío previo o simultáneo a la expedición de la factura y, teniendo en cuenta que existe una limitación que impide que la fecha de expedición sea superior a la fecha actual, no terminamos de ver claro que ocurra esa primera situación debido a que se ha "indicado" una fecha de expedición incorrecta posterior (porque, si el funcionamiento Veri*Factu es correcto, la fecha de generación no debería ser anterior a la de expedición).
No obstante, imaginemos que por algún motivo el envío se hace el día 17 y se indica esa fecha de expedición (pero debería haberse informado con fecha de expedición el día 16).
¿Cómo se corrige eso?

En primer lugar se tiene que tener en cuenta que el tener que presentar una factura rectificativa o tener que enviar un registro de alta por sustitución (para corregir el dato que corresponda), dependerá de:

1. Reglamento de facturación (IVA) donde se indica en qué casos se admiten facturas rectificativas. Si fuera alguno de esos casos se debería presentar un alta nueva (t0) con un tipo de factura rectificativa, que tendrá su propia numeración etc.

2. Si no se trata de un caso en que corresponda realizar una factura rectificativa, y se quiere "corregir" el contenido erróneo de esa factura:

a) Si el error se ha producido en algún campo que no forme parte de la clave única (compuesta de <NIF> + <NumSerieFacturaEmisor> + <FechaExpedicionFacturaEmisor>) se podrá realizar el envío de un tipo de registro T1 (alta sustitución en AEAT) / S1 (alta sustitución en el SIF).

b) En cambio, si el error se ha producido en uno de los campos de la clave única [<NIF> + <NumSerieFacturaEmisor> + <FechaExpedicionFacturaEmisor>] (que es precisamente el error que usted planteaba al principio, puesto que se refiere a la Fecha de expedición) entonces lo que tendría que hacer el SIF es:

1. Anular la factura por medio del envío de un registro de anulación T2 (para la AEAT) / S2 (para el SIF).
2. Volver a enviar el registro (T0/S0) con los datos correctos. En ese caso, la fecha de expedición será anterior al de generación del registro, pero esto no supondría ningún problema (no existen validaciones que lo impidan).

A la vista de esta respuesta, queda claro que, como el error, sí es una de las causas de emisión de una factura rectificativa (la consulta vinculante a la dirección de tributos establece que se debe emitir rectificativa si hay error en fechas de expedición), el procedimiento que debemos hacer es el del punto 1 "presentar un alta nueva (t0) con un tipo de factura rectificativa, que tendrá su propia numeración etc."

Comparto esta información con el foro porque creo que es muy importante. Además, abre la puerta a poder emitir facturas con fecha anterior al día en curso si no hemos emitido todavía ninguna después de es día. Esto resuelve el problema de facturar a final de mes con fecha 31 aunque estemos a día 1 del siguiente mes.

Fecha de registro distinto a fecha de Expedición y II

Buenos días.
Adjunto también contestación de Verifactu, relativa a la emisión de facturas con fecha anterior al día en curso

La pregunta que le hago es la siguiente:

Buenos días.

Mi consulta tiene que ver con la posible discrepancia, o no, que pueda haber entre la fecha de creación del registro de facturación y la fecha de expedición de la factura.
Le pongo un ejemplo:
Estando a día en curso 01 de abril, y no habiendo emitido ninguna factura este día, tengo que facturar las operaciones del mes de marzo de un empresario/profesional antes del 16 de abril. Resulta que el 31 de marzo es festivo y hoy día 01 de abril me dispongo a realizar la facturación. Necesito que la fecha de expedición de factura sea 31 de marzo y no he emitido ninguna factura el día 01 de abril.
¿Puedo emitir esta factura resumen con fecha 31 de marzo generando esa discrepancia entre la fecha de registro de facturación 01 de abril y la fecha de expedición de factura 31 de marzo ?

Gracias por su tiempo

y la respuesta es la siguiente

Sí, técnicamente es posible (tal y como le comentamos en el correo anterior que la fecha de registro de facturación sea posterior a la de expedición).

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: [email protected]

Gracias los 2
Aclarado lo de las fechas.

Gracias por la consulta. Entonces en eso Verifactu es distinto que TicketBAI y es una diferencia muy importante entre los dos sistemas.:cool:

Buenos días,

Otra duda comparando con Ticket Bai.

Mis clientes vascos por su tipo de negocio están acostumbrados a servir la mercancia con el albarán y luego dependiendo de si es el cliente quiere una factura diaria, semanal o mensual hacer en ese momento la factura y ya subirla a Ticket Ba en el momento de facturarla. De esta manera si hay una incidencia en el documento durante la entrega se puede cambiar al ser "albarán".

Entiendo que en Verifactu se podrá seguir haciendo igual. Es que en algún sitio creí leer que no iba a ser tan sencillo pero no no lo encuentro.

Graciass

Cita:

Empezado por edari (Mensaje 554235)

Es igual,
las Notas de entrega /Albaranes deben ser facturado dentro de la fecha según el reglamento de facturación, o sea:
*Si el destinatario de la operación es empresario o profesional, la factura debe ser emitida y que llegue al cliente antes del 16 del siguiente mes en el que se produce la operación o el devengo.
*Si el destinatario es un consumidor final, como máximo, el último día del mes donde se produce la operación o el devengo.

Registro De Eventos

Veo que obligan al nodo firma.
Tal y comentabais no tiene sentido para sistemas verifactu con envio, sería una incongruencia no obligar a firmar el registro de altas de facturas y si al registro de eventos .
Lo único que queda es lo que comentabais, marcar la opción incidencia, eso facilita mucho para errores.

Cita:

Empezado por ermendalenda (Mensaje 554238)

Es igual,
las Notas de entrega /Albaranes deben ser facturado dentro de la fecha según el reglamento de facturación, o sea:
......
*Si el destinatario es un consumidor final, como máximo, el último día del mes donde se produce la operación o el devengo.

Cuidado, si el cliente es consumidor final la factura se expide en el momento. Otra cosa es que el consumidor final le solicite una factura recapitulativa de todas sus operaciones en un mismo mes natural. Entonces se procedería a anular todas las facturas del cliente final en ese mes y a emitir una factura recapitulativa con todas sus operaciones con fecha máxima la del último día del mes.

Cita:

Empezado por sglorka (Mensaje 554245)

La última vez que les pregunté a verifactu por la recapitulativa me conestaeon que ese concepto no está incluido en verifactu.

Cita:

Empezado por ermendalenda (Mensaje 554249)

La última vez que les pregunté a verifactu por la recapitulativa me conestaeon que ese concepto no está incluido en verifactu.

Posiblemente no entendieron la pregunta.

Es lo que en facturación se llama "Factura sustitutiva de facturas simplificadas".
Antiguamente se llamaba "Factura de canje de tickets"

Cita:

Empezado por Sistel (Mensaje 554250)

Posiblemente no entendieron la pregunta.

Es lo que en facturación se llama "Factura sustitutiva de facturas simplificadas".
Antiguamente se llamaba "Factura de canje de tickets"

Si de esas hacemos decenas al día
Y se pueden pedir hasta 4 años después.per9 para poder declarse ese iva El cliente tiene que hacerlo en las condiciones que he puesto antes. Mismo mes para consumidores finales y hasta el día 15 los demás.

Cita:

Empezado por Sistel (Mensaje 554250)

Posiblemente no entendieron la pregunta.

Es lo que en facturación se llama "Factura sustitutiva de facturas simplificadas".
Antiguamente se llamaba "Factura de canje de tickets"

También pueden ser facturas completas las que recapitula esta factura. Esta no es una factura distinta a las demás es del tipo F1. Para evitar la doble facturación hay que ANULAR todas facturas que contiene. No se debería enviar con F3 ya que no son facturas simplificadas las que contiene en este caso.