Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[[newtron]]

Empezado por novatico

Con respecto a las fechas diferentes para desarrolladores y clientes, supone llevar paralelamente 2 programas, uno el que puedes instalar a los clientes hasta la fecha de entrada en vigor para ellos, y otro el que vas desarrollando con todo lo que necesitas incluir para cumplir la OM.

En el documento que publicaron de preguntas realizadas en el último webinar, dejan claro que la firma de los registros de facturación SOLO ES PARA NO VERIFACTU.

Por último comentar que, hasta hace poco en mi empresa se pretendía desarrollar una aplicación DUAL, es decir, para VERIFACTU y para NO VERIFACTU, pero con los últimos cambios que están introduciendo en todos los diseños y en la operativa, así como en la problemática de que el cliente sea el depositario de los Registros de Facturación, perdiendo los desarrolladores el control aunque no parte de la responsabilidad, estamos prácticamente decididos a desarrollar la aplicación como SOLO VERIFACTU, con la única salvedad de controlar la posibilidad de que el OT esté excluido de presentar los registros, como por ejemplo si está sujeto al SII.

No sé si me estoy perdiendo algo pero yo veo claramente que los programas hay que prepararlos para ser VERIFACTU y simplemente poner una opción para que los registros se envíen de forma automática o no. De esta manera el que quiera que envíe y el que no que tenga una opción para enviar los registros (entre fechas imagino) si se los requieren.


Saludos.

[pablog2k]

Empezado por newtron

No sé si me estoy perdiendo algo pero yo veo claramente que los programas hay que prepararlos para ser VERIFACTU y simplemente poner una opción para que los registros se envíen de forma automática o no. De esta manera el que quiera que envíe y el que no que tenga una opción para enviar los registros (entre fechas imagino) si se los requieren.


Saludos.

no es así del todo.
con verifactu NO tienes que firmar el xml , simplemente lo generas y se lo envías a la AEAT, de manera mas o menos inmediata
sin verifactu SI que tienes que firmar el xml (como hace ticketbai) , guardártelo , y enviarlo a la AEAT cuando lo soliciten (y encima la responsabilidad es tuya como comentan los compañeros)
Por eso al final siempre va a ser mejor con VERIFACTU, ya que haces el xml (sin firmar), envías y listo

[CarlosR]

Empezado por newtron

No sé si me estoy perdiendo algo pero yo veo claramente que los programas hay que prepararlos para ser VERIFACTU y simplemente poner una opción para que los registros se envíen de forma automática o no. De esta manera el que quiera que envíe y el que no que tenga una opción para enviar los registros (entre fechas imagino) si se los requieren.


Saludos.

Sinceramente creo que se está perdiendo en un laberinto de normas. NO verifactu es mucho mucho mas restrictivo que verifactu. Encima el responsable de la autenticación, conservación y verificación de los datos del cliente es usted no su cliente.
Se firman los registros en NO verifactu, en cambio en verifactu no.
Se firman los eventos. Los requerimientos de la AEAT van a ser continuados, etc.etc.etc.

No tengo a mano ahora mismo toda la documentación al respecto pero ante la duda yo también aconsejo usar "solo verifactu". Opción en la que se renuncia a usar NO verifactu. Si el programa tiene las dos opciones debe cumplir la mas restrictiva que es NO verifactu.
En mi anterior comentario he aludido a que generaré dos ejecutables. Uno para dual verifactu / NO verifactu y otro ejecutable para solo verifactu. Solo verifactu es apriori el que pondré en producción.

No sé si al final sacaré el dual a producción porque tengo serias dudas de la responsabilidad que puedo adquirir, inclusive teniendo precios significativamente mayores para dar dicho soporte que tal vez no me compense el esfuerzo y riesgo.

En mi opinión debería leerse la documentación de la AEAT antes de poner en producción su proyecto. Mi consejo es que se acoja a solo veri*factu si tiene dudas.


Un saludo.

[keno_71]

Empezado por CarlosR

Sinceramente creo que se está perdiendo en un laberinto de normas. NO verifactu es mucho mucho mas restrictivo que verifactu. Encima el responsable de la autenticación, conservación y verificación de los datos del cliente es usted no su cliente.
Se firman los registros en NO verifactu, en cambio en verifactu no.
Se firman los eventos. Los requerimientos de la AEAT van a ser continuados, etc.etc.etc.

No tengo a mano ahora mismo toda la documentación al respecto pero ante la duda yo también aconsejo usar "solo verifactu". Opción en la que se renuncia a usar NO verifactu. Si el programa tiene las dos opciones debe cumplir la mas restrictiva que es NO verifactu.
En mi anterior comentario he aludido a que generaré dos ejecutables. Uno para dual verifactu / NO verifactu y otro ejecutable para solo verifactu. Solo verifactu es apriori el que pondré en producción.

No sé si al final sacaré el dual a producción porque tengo serias dudas de la responsabilidad que puedo adquirir, inclusive teniendo precios significativamente mayores para dar dicho soporte que tal vez no me compense el esfuerzo y riesgo.

En mi opinión debería leerse la documentación de la AEAT antes de poner en producción su proyecto. Mi consejo es que se acoja a solo veri*factu si tiene dudas.


Un saludo.

¿ Hay alguna forma de controlar que una empresa está en el SII para que el programa no envíe las facturas ya que se enviarán en 4 días como muy tarde? y en caso contrario (no están en el SII) qué lo envíe inmediatamente. Actualmente nuestros clientes son los que nos dicen que tienen SII y le activamos el módulo de envío, pero el envío es manual. El cliente un año puede estar en el SII y al año siguiente no.

¿Cómo lo tenéis pensando vosotros? para que el programa siempre funcione en verifactu pero tenga esa excepción con los del SII y no haya un control manual por parte nuestra. Gracias!!

[CarlosR]

Empezado por keno_71

¿ Hay alguna forma de controlar que una empresa está en el SII para que el programa no envíe las facturas ya que se enviarán en 4 días como muy tarde? y en caso contrario (no están en el SII) qué lo envíe inmediatamente. Actualmente nuestros clientes son los que nos dicen que tienen SII y le activamos el módulo de envío, pero el envío es manual. El cliente un año puede estar en el SII y al año siguiente no.

¿Cómo lo tenéis pensando vosotros? para que el programa siempre funcione en verifactu pero tenga esa excepción con los del SII y no haya un control manual por parte nuestra. Gracias!!

Aunque ya se ha explicado en el foro, la empresa (no grupo de empresas) que esté acogido al SII queda exento del SIF (verifactu).
El SII tiene obligatoriedad de activarse si se supera un umbral o valor de operaciones en un ejercicio o bien porque se acoge voluntariamente la empresa (liquidación mensual del iva, etc.).
Si se acoge voluntariamente puede decidirlo al final del ejercicio. Si no se acoge al SII a final de ejercicio deberá activar el SIF (verifactu) sí o sí. En este punto su software deberá cumplir con todos los requisitos que impone esta norma. Como ya he mencionado anteriormente hay dos formatos muy diferentes. Sistema dual que permite verifactu y NO verifactu y por otro lado que el software permita exclusivamente verifactu.
Lo que haga usted en los ejercicios que esté acogido a SII es irrelevante para verifactu pues estará excluido.
Pero en los ejercicios que se acoja a una de las dos alternativas de verifactu deberá cumplir con los requisitos.
En el webservice existen métodos para indicar que comienza la actividad con verifactu y otros para indicar el final de verifactu.

Hay varias combinaciones de como puede funcionar un software que atienda a varias empresas en distintas circunstancias. Hay un esquema en un pdf en la página de la AEAT ilustrativo de cuales son los requisitos de cada combinación.
Quede claro que cuando me refiero a NO verifactu no significa que esas normas deban aplicarse a un sistema SII. SII excluye todo lo demás.
Al menos así es como entiendo que debe funcionar un sistema


Espero que le sirvan estas indicaciones. Pero recuerde que todavía se están cambiando normas actualmente y que estamos sujetos a cambios.


Si le sirve de algo, nuestro soft intenta funcionar siempre (SII, verifactu, No verifactu) con el máximo requisito exigido por NO verifactu. Lo que hacemos es activar servicios para cada actividad, pero la operativa del backoffice siempre genera todos los datos. Cuando entre en vigor definitivamente la norma decidiré si desactivo el NO verifactu.



Un saludo y buen finde.

[keno_71]

Empezado por CarlosR

Aunque ya se ha explicado en el foro, la empresa (no grupo de empresas) que esté acogido al SII queda exento del SIF (verifactu).
El SII tiene obligatoriedad de activarse si se supera un umbral o valor de operaciones en un ejercicio o bien porque se acoge voluntariamente la empresa (liquidación mensual del iva, etc.).
Si se acoge voluntariamente puede decidirlo al final del ejercicio. Si no se acoge al SII a final de ejercicio deberá activar el SIF (verifactu) sí o sí. En este punto su software deberá cumplir con todos los requisitos que impone esta norma. Como ya he mencionado anteriormente hay dos formatos muy diferentes. Sistema dual que permite verifactu y NO verifactu y por otro lado que el software permita exclusivamente verifactu.
Lo que haga usted en los ejercicios que esté acogido a SII es irrelevante para verifactu pues estará excluido.
Pero en los ejercicios que se acoja a una de las dos alternativas de verifactu deberá cumplir con los requisitos.
En el webservice existen métodos para indicar que comienza la actividad con verifactu y otros para indicar el final de verifactu.

Hay varias combinaciones de como puede funcionar un software que atienda a varias empresas en distintas circunstancias. Hay un esquema en un pdf en la página de la AEAT ilustrativo de cuales son los requisitos de cada combinación.
Quede claro que cuando me refiero a NO verifactu no significa que esas normas deban aplicarse a un sistema SII. SII excluye todo lo demás.
Al menos así es como entiendo que debe funcionar un sistema


Espero que le sirvan estas indicaciones. Pero recuerde que todavía se están cambiando normas actualmente y que estamos sujetos a cambios.


Si le sirve de algo, nuestro soft intenta funcionar siempre (SII, verifactu, No verifactu) con el máximo requisito exigido por NO verifactu. Lo que hacemos es activar servicios para cada actividad, pero la operativa del backoffice siempre genera todos los datos. Cuando entre en vigor definitivamente la norma decidiré si desactivo el NO verifactu.



Un saludo y buen finde.

Gracias Carlos!!

[ermendalenda]

Buenas tardes a todos.
Sería tan amable alguna persona del grupo de poner un Xml de ejemplo (con el actual esquema) de rectificativa por sustitución de un solo paso, que rectifica por error en el cif del cliente. Muchas gracias

[sglorka]

Empezado por ermendalenda

Buenas tardes a todos.
Sería tan amable alguna persona del grupo de poner un Xml de ejemplo (con el actual esquema) de rectificativa por sustitución de un solo paso, que rectifica por error en el cif del cliente. Muchas gracias

Adjunto ejemplo, las huellas son inventadas

<?xml version="1.0" encoding="utf-8"?>
<RegistroFacturacionAltaType xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<IDVersion xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">1.0</IDVersion>
<IDFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDEmisorFactura>XXXXXXXXX</IDEmisorFactura>
<NumSerieFactura>106-15</NumSerieFactura>
<FechaExpedicionFactura>14-05-2024</FechaExpedicionFactura>
</IDFactura>
<NombreRazonEmisor xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">EMPRESA S.L.</NombreRazonEmisor>
<Subsanacion xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">N</Subsanacion>
<RechazoPrevio xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">N</RechazoPrevio>
<TipoFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">R4</TipoFactura>
<TipoRectificativa xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">S</TipoRectificativa>
<FacturasRectificadas xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDFacturaRectificada>
<IDEmisorFactura>XXXXXXXXX</IDEmisorFactura>
<NumSerieFactura>101-687</NumSerieFactura>
<FechaExpedicionFactura>14-05-2024</FechaExpedicionFactura>
</IDFacturaRectificada>
</FacturasRectificadas>
<ImporteRectificacion xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<BaseRectificada>1.42</BaseRectificada>
<CuotaRectificada>0.30</CuotaRectificada>
</ImporteRectificacion>
<FechaOperacion xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">14-05-2024</FechaOperacion>
<DescripcionOperacion xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">Entrega de Bienes( Sin Plomo 95 )</DescripcionOperacion>
<Destinatarios xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDDestinatario>
<NombreRazon>DESTINATARIO SL</NombreRazon>
<NIF>YYYYYYYYY</NIF>
</IDDestinatario>
</Destinatarios>
<Desglose xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<DetalleDesglose>
<ClaveRegimen>01</ClaveRegimen>
<CalificacionOperacion>S1</CalificacionOperacion>
<TipoImpositivo>21.00</TipoImpositivo>
<BaseImponibleOimporteNoSujeto>1.42</BaseImponibleOimporteNoSujeto>
<CuotaRepercutida>0.30</CuotaRepercutida>
</DetalleDesglose>
</Desglose>
<CuotaTotal xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">0.30</CuotaTotal>
<ImporteTotal xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">1.72</ImporteTotal>
<Encadenamiento xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<RegistroAnterior>
<IDEmisorFactura>XXXXXXXXX</IDEmisorFactura>
<NumSerieFactura>101-688</NumSerieFactura>
<FechaExpedicionFactura>14-05-2024</FechaExpedicionFactura>
<Huella>cb62c727cfe8a3e5408e0e2aa0e923d26498fc2d6c06d8ab8d28eee1f5925662</Huella>
</RegistroAnterior>
</Encadenamiento>
<SistemaInformatico xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<NombreRazon>EMPRESA DESARROLLADORA SL</NombreRazon>
<NIF>BYYYYYYYY</NIF>
<NombreSistemaInformatico>SOFTWARE DE GESTIÓN</NombreSistemaInformatico>
<IdSistemaInformatico>SG</IdSistemaInformatico>
<Version>1.0.0</Version>
<NumeroInstalacion>1</NumeroInstalacion>
<TipoUsoPosibleSoloVerifactu>S</TipoUsoPosibleSoloVerifactu>
<TipoUsoPosibleMultiOT>N</TipoUsoPosibleMultiOT>
<IndicadorMultiplesOT>S</IndicadorMultiplesOT>
</SistemaInformatico>
<FechaHoraHusoGenRegistro xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">2024-05-14T08:38:29+01:00</FechaHoraHusoGenRegistro>
<TipoHuella xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">01</TipoHuella>
<Huella xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">cb62c727cfe8a3e5408e0e2aa0e923d26498fc2d6c06d8ab8d28eee1f5925662</Huella>
</RegistroFacturacionAltaType>