Ley antifraude 2021 (VERIFACTU) - Programas informáticos

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

Empezado por keys

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

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

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

[keno_71]

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

[ermendalenda]

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

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

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

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

Empezado por keno_71

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.

Empezado por keno_71

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.

Empezado por keno_71

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.

[keno_71]

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

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!

[Sistel]

Empezado por Sistel

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 observaciones.proyectos@aeat.es ha sido rechazado por el servidor de correo de aeat.es

SMTP error from remote mail server after RCPT TO:<observaciones.proyectos@aeat.es>:
550 5.1.1 <observaciones.proyectos@aeat.es>: Recipient address rejected:
User unknown

Saludos

[sglorka]

Empezado por keys

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 ?

[keys]

Empezado por sglorka

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 ?

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

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

[sglorka]

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.

[keys]

Empezado por sglorka

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.

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.

[keys]

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

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. Sólo para que veáis lo importante que tener validado todo. Esto mismo ocurre en el SII.

[ermendalenda]

Empezado por Sistel

Hola,

Parece que el email enviado a observaciones.proyectos@aeat.es ha sido rechazado por el servidor de correo de aeat.es

SMTP error from remote mail server after RCPT TO:<observaciones.proyectos@aeat.es>:
550 5.1.1 <observaciones.proyectos@aeat.es>: Recipient address rejected:
User unknown

Saludos

Pues ya solo queda verifactu@correo.aeat.es
y mandale lo que te ha pasado en periodo de consulta.

[ermendalenda]

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

[sglorka]

Empezado por keys

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.

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.

[_Io]

Buenas noches.

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

<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

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.

[_Io]

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

Pero me he dado cuenta de un detalle

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

[_Io]

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

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:

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

[keys]

Empezado por sglorka

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.

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.

[ermendalenda]

Empezado por keys

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.

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

   <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

 <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>ç