SIF vs SII
 

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

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>

Si lo quieres empaquetado para su envío sería así

<?xml version="1.0" encoding="utf-8"?>
<RegFactuSistemaFacturacion xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Cabecera xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<ObligadoEmision>
<NombreRazon>EMPRESA S.L.</NombreRazon>
<NIF>XXXXXXXXX</NIF>
</ObligadoEmision>
<RemisionVoluntaria>
<Incidencia>N</Incidencia>
</RemisionVoluntaria>
</Cabecera>
<RegistroFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
<RegistroAlta>
<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>
</RegistroAlta>
</RegistroFactura>
</RegFactuSistemaFacturacion>

Perfecto,muchísimas gracias
Saludos

Vaya lio hoy en malaga, media ciudad con cortes de luz

¿Y eso, qué ha pasado?
Por la Axarquía hemos notado un breve parpadeo nada más y luego siguió todo normal.

Ha salido en algun diario, un transformador averiado que ha afectado a miles de malagueños.
Yo he tenido problemas en echeverria (el palo) malaga centro, barriada de la luz(ctra de cadiz) y sobre todo en polígono guadalhorce, donde ha habido un corte de al menos 1 hora y media(tirando de sai), a la axarquía no ha llegado por que en la cala no se ha notado. Los técnicos electricistas que tenia al lado han empezado a recibir llamadas y han tenido bastante trabajo para reparar cuadros rotos a raíz del apagón.
Bueno me "ha venido bien" para probar todo este rollo de encadenamiento en caso d eun apagón en comercios sin SAI y recuperar algún tiquet (incidencia) y continuar el encadenamiento, vaya tela.

Requerimientos AEAT
 

Supongo que os interesa, para que lo tengais en cuenta los que aún no hayan tenido un requerimiento de la AEAT estos meses. Un comercio ha recibido un requerimiento en el que le piden el Libro de Facturas emitidas, pero todo todo, en el que hacen referencia a articulos de la nueva ley antifraude, ademas de lo tipico que no haya tachaduras, continuidad de numeracion etc.., mas o menos así:
Todas las facturas simplificadas, facturas normales, autoconsumos, sustitutivas, rectificativas por diferencias y sustitución, de un trimestre. Por un lado lo entregado a cada cliente en pdf o en el formato que tengamos que sea legible y Los totales (Base cuota Iva, recargos de equivalencia, cif del receptor, nombre receptor...) en un excell, con el formato que tienen establecido-
El numero de archivos máximo es de 90 y el tamaño maximo de cada archivo. (si no recuerdo mal 68 Megas)

Si fuera posible, no estaría mal conseguir el documento de requerimiento para ir viendo por donde van los tiros.

No sé si esa información se puede publicar..pero te dejo enlaces de ejemplos de como confeccionar las excell de los libros de iva para satisfacer a los requerimientos:
https://sede.agenciatributaria.gob.e...odelo_100.xlsx
https://sede.agenciatributaria.gob.e...odelo_100.xlsx
https://sede.agenciatributaria.gob.e...odelo_100.xlsx
No hace falta que sea estrictamente como los Ejemplos, nosotros hemos eliminado las columnas innecesarias y hemos añadido algunas como la serie y número de las facturas a las que rectifica una factura rectififcativa e igualmente para las sustitutivas. También hemos añadido un txt de leyendas, en el que detallamos las series utilizadas a que corresponden.
Por otro lado hemos enviado los tiquets y facturas en pdf comprimidos en zip, de 10 días en 10 días, en total nlo ha llegado a 15 ficheros enviados, y el resultado del requerimiento ha sido OK. Estos requerimientos pueden ser simplemente por haber solicitado un aplazamiento de pagos de iva o cualquier cosa que se salga del procedimiento normal.
Saludos.

Me refiero a que si podrías saber exactamente en ese requerimiento a que artículos se refiere de la nueva ley antifraude. muchas gracias.

A nada de la Ley antifraude. Error mío de interpretación. Hace referencia a normativas anteriores que he confundido con la nueva ley antifraude, ejemplo:
En el art. 68.1 Todos los libros registro mencionados en este reglamento deberán ser llevados, cualquiera que sea elprocedimiento utilizado, con claridad y exactitud, por orden de fechas, sin espacios en blanco y sin interpolaciones, raspaduras ni tachaduras.

Exportación csv
 

Creo que se ha confundido. Ya me extrañaba por los siguientes motivos :
1- Los requerimientos son telemáticos (o lo serán)
2- No se ha terminado de crear un formato definitivo. Por lo que no se puede pedir un csv sin formato oficial.
3- No se habla de que un requerimiento tenga que ser exportado en csv. Lo que si se habla en la Ley es de que se puedan exportar a ficheros LEGIBLES por la Aeat los siguientes datos (registro de eventos, altas y anulación de facturas ya enviados). Pero esto no es un requerimiento sino otra cosa. Imagino que ante un fraude se personarán en las instalaciones y querrán llevarse los registros. Ni siquiera tienen que estar los datos en la propia base de datos. Dicen que tienen que tenerlos a disposición de la Aeat, y custodiados durante el tiempo que la Ley lo requiera. Y me imagino que solo hace referencia a los NO verifactu. Ya se verá.



A lo que se está usted refiriendo es a una norma que hace ya tiempo que está en vigor mediante la cual se deberá exportar a csv el registro de iva repercutido y soportado. Esto generalmente se saca del programa de contabilidad financiera. En mi caso lo tengo por mes, trimestre y ejercicio. Pero ya no es nuevo.


Un saludo.

Lo mismo sigo equivocado, pero si ésto (imagen adjunta) no es un requermiento, ya me diras.

segunda parte

borrar este mensaje

sigue aqui

Yo entiendo que efectivamente eso es un requerimiento pero no tiene nada que ver con VeriFactu. Están requiriendo los libros de iva en el formato habitual desde hace unos años acá. A algunos clientes míos se lo han pedido igualmente así.



Saludos.

Hola,

Sí, ése es el clásico requerimiento de Hacienda (de toda la vida) para que aporte uno (ahora en formato digital), todos los datos referentes a facturación.
Es muy habitual que lo hagan cuando se solicita devolución de IVA (craso error) en lugar de dejar la deuda pendiente para compensar en siguientes trimestres o ejercicios.

Antes te pedían llevar los libros de facturas y todas las facturas emitidas y recibidas (en papel) a Hacienda.
(Somos también asesoría contable y fiscal y ya nos ha tocado, más de una vez, hacer el numerito de circo de ir cargados de carpetas de facturas a Hacienda)
Pasado un tiempo te avisaban para que pasases a recogerlos y a que te cantasen las cuarenta:
"Que si esta factura no es factura porque no aparece la palabra FACTURA".
"Que si esta no tiene desglosado el IVA"
"Que si en ésta no aparece el NIF/CIF del destinatario"
Al final te descontaban de las facturas recibidas unas cuantas y te devolvían bastante menos de lo que habías pedido de devolución.

Nuestro consejo siempre a los clientes: "No pedir nunca devolución de pasta a Hacienda".
Pero algún cliente que insistió, ya lo pagó caro: de unos 10.000€ que le tenían que devolver, al final perdió casi 5.000€ (que habría podido compensar de no haber tenido inspección por pedir devolución de IVA)

En resumen, no es nada nuevo ni que tenga que ver con VeriFactu.
Es inspección de IVAs de toda la vida.

Saludos

Jejeje. Veo que se está alargando mucho este último tema y se insitr en lo mismo del error.
VUELVO a aclararlo, no he dicho que sea verifactu, dije (POR ERROR) que hacia referencias a artículos de la nueva normativa antifraude. En otro Post dije que HE CONFUNDI DICIENDO QUE HACIA REFERENCIA A LA NORMATIVA ANTIFRAUDE. EFECTIVAMENTE NO TIENE QUE VER CON VERIFACTU.
Por supuesto que ea un requerimiento y he puesto partes del documento del requerimiento para quien le pueda servir. Saludos

Ahhhhhhhhhhhhhhhhhhh... Verifactuuuuuuuuuuuuuu... ¿qué es eso de Verifactu? :D:D

Pues algo muy bonito que estanos haciendo para recaudar por que hacienda somos todos y verás los paseos marítimos , carreteras, autopistas gratuitas, salud dental gratuita, todo lo que van a hacer gracias a nuestras colaboración.:D

Hola.

Eso es un requerimiento de hacienda. Pero no tiene que ver nada con verifactu. Tenéis la información en este enlace https://www.agenciatributaria.es/AEA...rimientos.html.

Estos ficheros se utilizan desde hace tiempo a parte de por un requerimiento de hacienda, para que los contribuyentes puedan llevar su libro registro de IVA y de IRPF, de esta forma hacienda les calcula el IVA 303 y el 130 (personas físicas). Es una especie de SII pero para empresas que no están en el SII. Bueno una chapuza por que se hace con ficheros en formato excel.

También te lo pueden pedir de hacienda mediante un requerimiento, normalmente si les pides la devolución del IVA. Pero repito no tiene que ver nada con VERIFACTU

Requerimiento
 

Por supuesto hombre. Tal vez me he expresado con pocos datos y pueda dar lugar a equívoco. Pero no es un requerimiento de verifactu que es a lo que yo me refería.
Cualquier actuación de la Agencia Tributaria demandando datos se ejecuta mediante un requerimiento.


A continuación le muestro la U.R.L. en donde se especifican los formatos de exportación del registro de iva.
https://sede.agenciatributaria.gob.e...RECIBIDAS.xlsx


Como le decía no es una nueva norma. Ya lleva en vigor un tiempo. Y creo que ha confundido esta norma con un nuevo requerimiento de la AEAT para quien deba soportar verifactu y NO verifactu. (conjuntamente denominado S.I.F.)
Los requerimientos telemáticos están definidos y sujetos a cambio para verifactu. No obstante pra quien opte por NO verifactu la AEAT podrá presentarse en las instalaciónes y solicitar que se le exporten los registros a un formato que sea legible para la AEAT. Este formato NO está definido.

Tal vez ahora me he explayado un poco mas.

El defecto de algunos informáticos entre los cuales me encuentro es que somos parcos en palabras.


Un saludo.:)

Esquema
 

Habrá que esperar a que salga la norma definitiva y luego hacer un esquema o resumen general tanto para verifactu como NO verifactu.
No vaya a ser que a alguno se nos escape alguna.


Salu2.

hola Carlos, podrías mirar tu bandeja de entrada en mensajes privados ? Muchas gracias

Me acaba de llegar el aviso de que hay nueva documentación.
Actualización de Diseño de Registro y Documento de validaciones y errores de sistemas VERI*FACTU

• Diseños de registro de facturación (v0.13.1) - Borrador
• Documento de validaciones y errores (v0.7.2) - Borrador
• Documento de descripción de servicios web (v0.3.0) - Borrador

Actualizo el mensaje #1 del hilo.

^\||/ Gracias Germán.

Novato en esto de Verifactu
 

Buenas tardes Foro

Me llamo Jesús, soy programador freelance, y tengo una aplicación de Facturación desarrollada en .NET.

Bueno el tema es que buscando en la web he dado con este foro que me parece estupendo y que me está ayudando un montón, pero como todo novato me invaden las dudas y no se muy bien por donde empezar.

Por ejemplo esto de los servicios web SOAP es la primera vez que voy a trabajar con ello, no sé que información debe ir en el hash encadenado (o esa especificación esta por detallar), en fin os agradecería la información que me pudierais prestar a modo de guía (ejemplos, manuales, etc.). A ver si así me voy animando.

Os lo agradezco un montón de antemano.

Gracias.

Buenas, jesus

He estado unos dias muy liado y no te he visto hasta hoy. ¿Has resuelto ya algo? Yo desarrollo en net y me encontré en diciembre con el mismo problema. Aprendi como hacer peticiones soap aprendiendo primero que es un webservice y desarrollando la programacion para el sii en net y lo que aprendi lo he aplicado a verifactu. Empece con el sii porque dispone de entorno de pruebas que creo es fundamental para saber que y como enviar y que responde el servidor al hacer una peticion soap a un webservice. Como no se como andas exactamente de conocimientos si te parece me haces un privado y si vemos que andas regular te paso mi telefono y te doy unas nociones para que al menos puedas comenzar a desarrollar esto tan bonito que nos tienen preparados que se llama verifactu y que nos trae a mas de uno de cabeza. Ante todo no desesperes que por aqui hay muy buena gente y con muy buenos conocimientos que siempre estan dispuestos a hechar una mano.

Un saludo

Esquemas de Registro de Eventos y de Requerimiento AEAT
 

Buenos días a todos;

Programo en C#, pero este foro ya me ayudó muchísimo en su día con TicketBai, con lo que lo tengo de cabecera desde entonces.
Aunque ya no me pilla de sorpresa lo de VeriFactu (que es como un TicketBai pero a lo grande y a nivel nacional, con sus peculiaridades por supuesto), sí que tengo algunas (muchas) dudas planteo aquí, por si me podéis ayudar a resolverlas:

1. ¿El esquema de Registro de Eventos para Verifactu, ya está publicado?. Sí que han publicado borrador del Excel con la estructura... pero el XSD (tipos complejos, etc....) para montarlo en la aplicación, pero el XSD (el tipo complejo) no lo encuentro por ninguna parte. Igual es que no lo han publicado aún, pero por eso lo consulto.

2. Lo mismo ocurre con el esquema de la estructura de envíos NO Verifactu, es decir, a requerimiento, y el formato en el que se tienen que almacenar.
¿Tienen que almacenarse en formato .XML, y debe de ir firmado verdad?
Es cierto que en los comentarios del excel, existen algunos que hacen referencia a que el campo será obligatorio o no para Verifactu/No Verifactu... pero mi consulta era si existe algún tipo de documento que ya esté formado con todos los campos necesarios para la remisión.
Pero en la documentación, establece que la remisión de Verifactu y requerimiento, utilizan el mismo esquema XSD para el envío, con lo que, ¿para qué se almacenan los .XML, si la remisión del requerimiento es a través de un SOAP con el protocolo y esquemas que se indican?

3. La remisión de la factura Verifactu, ¿debe de adjuntarse el certificado del obligado tributario en la misma?. En el envío SOAP, no encuentro tal posibilidad.
¿Alguien ha trabajado ya con C#, y ha logrado esta posibilidad?


Muchas gracias de antemano como siempre.
Un cordial saludo.

Primero, a un nivel operacional como son los esquemas, nada está publicado de manera oficial. Solo existen borradores. Con estos se pueden diseñar cositas, pero tienes que estar preparado a cambios. (Por esto este foro está muy tranquilito.;))
Un detalle importante: se ha dicho (pero no creo haberlo he visto escrito en un texto oficial) que el esquema para los registros de facturación será el mismo para todos los casos, o siga, que no habrá diferencias entre sistemas veri*factu y no-veri*factu a nivel de registros intercambiados.

Luego, los eventos no tienen que ser almacenados en XML. Y lo mismo ocurre con los registros de factura en un sistema no-veri*factu.
Solo será obligatorio usar XML (con esquemas aún por publicar) para transmitir estos registros en contestación a los futuros requerimientos. Y posiblemente para firmar los registros (este proceso de firma no está definido claramente en la actualidad; al principio era basado sobre el contenido XML, pero se dice que se van a suprimir algunos nodos del contenido a firmar; otro tema abierto).

En este punto hay que preguntarse por qué estás programando un sistema no-veri*factu.
La posibilidad de sistemas no-veri*factu no es la preferida por Hacienda claramente, no hacen nada para que siga la opción por defecto, más bien todo lo contrario.
Creo que esta opción existe para las empresas que tienen ya en casa un sistema de facturación capaz de cumplir los requerimientos de la ley (integridad, trazabilidad, etc.) y que no quieren desarrollar una adaptación a este sistema para comunicar en tiempo casi real las facturas por el canal veri*factu. El caso más obvio son las empresas donde el sistema de facturación no está conectado a Internet.
Estas empresas solo deberán desarrollar una adaptación para firmar los registros de facturación y los de eventos (y almacenar dichas firmas), y otra para comunicar lotes de registros en formato XML bajo requerimientos.
¿Se sabe cómo firmar? No, no está publicado.
Lo de los registros para los requerimientos está un poco más claro (no mucho) porque al menos el contenido se puede deducir de los borradores; pero no es suficientemente preciso para que puedes empezar a programar la generación en XML de estos lotes: tal como lo dices, faltan los esquemas.

Para mi, si tienes resuelto todo lo demás y solo te falta programar la generación en XML de los lotes para enviar a Hacienda, creo que vas muy bien en tu agenda. Solo te queda esperar un poco más a que Hacienda publique su orden ministerial. Y luego ¡tendrás muchos meses para los ensayos! (y adaptarse a posibles cambios de normativa; cf. ticketBAI.:cool:)

El envío SOAP se hace en una comunicación segura (https:) que involucra un certificado.
Pero este certificado no tiene que ser él del obligado tributario: existen casos dónde "colaboradores" pueden presentar registros en nombre de un obligado.

Muchas gracias por la respuesta, Antoine0. Me sirve de mucha ayuda tu respuesta.
No obstante, tengo muchas dudas todavía con respecto al funcionamiento.
En mi caso, todavía no tiene claro mi empresa si será el Cliente el que decida si se acoge a VeriFactu o no, con lo que tengo que abrir ambas posibilidades mientras no me digan lo contrario (doble de curro para mi, obviamente). Tenía entendido que en un sistema NO Verifactu, los XML se guardaban firmados en espera de ser enviados ante un requerimiento de la AEAT, pero ya no me queda nada claro con lo que me comentas de que NO hace falta almacenarlos, sino que como dices solamente se generarán los XML y se firmarán y enviarán en el momento que los requiera hacienda, pero no antes. Tengo bastantes dudas sobre eso. No sé si alguien lo había interpretado como yo ... jejeje

Un saludo y gracias de nuevo.

Yo te diría que es la primera (casi seguro).
Primero, porque para el encadenamiento de facturas te hacen falta datos de la anterior incluyendo la firma (por lo que sabemos de otros sistemas similares). Eso obliga a generar y FIRMAR una factura, que es lo que impide su modificación. Y parte de esa firma es lo que se usa en la siguiente.

Si se hiciera de la segunda forma, podrías generar las facturas e ir modificándolas y generar todos los XML sólo cuando te los solicitara hacienda. De esa forma se generarían todos correctos con la última foto de cada factura.

No se si me explico.

Tratamiento Verifactu para Canarias y Ceuta/Melilla
 

Hola a todos de nuevo.

Cuando se habla de Operación, quiero entender que se está hablando de una Línea de la Factura, ya que en el esquema y dentro de la factura, la calificación de la operación y demás, está dentro del desglose de la misma, donde habría que meter todas las líneas de la factura. ¿Esto es así?.


El caso es que tenía pendiente revisar el tratamiento "diferente" que se hace para Canarias y Ceuta/Melilla.
A la hora de Calificar la Operación (CalificacionOperacionType), y en base al Regimen (ClaveRegimen), existe la opción de establecer una operación como Exenta.

Es decir, ClaveRegimen (de IVA) es Regimen General.... Criterio de Caja.... y en concreto está el elemento "08", que hace relación a IPSI/IGIC

Aquí me entran todas las dudas del mundo, cuando habla de "Operación No Sujeta por Reglas de localización.", que entiendo que será lo que aplique en estos casos.

1. Si el empresario que emite la factura tributa en Canarias, Ceuta o Melilla, ¿existe algún tratamiento distinto con un empresario Peninsular?.
Es decir, a la hora de remitir las facturas, ¿hay que tener en cuenta algo en concreto por el hecho de que el empresario esté en Canarias o no?

2. ¿Existe algún tratamiento especial cuando un empresario está en la península, pero la factura se emite a una persona residente en Canarias, Ceuta o Melilla?
¿Y existe algún tratamiento al revés? (Es decir, empresario en Canarias, Ceuta o Melilla, y el destinatario de la factura es en la península)


Alguien que lo tenga más o menos esto claro, ¿podría poner un breve esquema de cómo interpretar todo esto, con Canarias, Ceuta y/o Melilla, y quizá un pequeño ejemplo de cómo rellenar ClaveRegimen(), CalificacionOperacionType() y posteriormente la Base Imponible, Tipo Impositivo, Cuota Repercutida, etc..... en estos casos?.

3. ¿CalificacionOperacionType() va a ser "N2" siempre que el Empresario tribute en Canarias, Ceuta/Melilla?. ¿Y en este caso sería siempre una OperacionExenta?
¿En este caso, no habría que rellenar TipoImpositivo, Base Imponible, Cuota Repercutida, etc...., aunque sí tuviesen valor?

Muchas gracias de antemano a todos, y disculpad el "caos" que tengo todavía montado en la cabeza.
Un saludo.

Hola, sí, muchas gracias Neftali [Germán.Estévez]

Es lo que yo tenía entendido. Esperamos a ver que nos comente alguien más a ver qué se interpreta, de si se necesita almacenarlos o no.
Pero yo creo que los XML NO Verifactu, tienen que guardarse firmados, aunque la segunda opción de generarlo según te los requiera Hacienda, quizá también sería factible, ya que en realidad se enviaría lo que hubiese en el último momento como dices, y Hacienda no era conocedora del "primer estado de la factura"... sino que conocerá el último, el que se remita... Pero no sé si eso sería viable o está permitido.

Un saludo

- Si se hiciera de la segunda forma, podrías generar las facturas e ir modificándolas y generar todos los XML sólo cuando te los solicitara hacienda. De esa forma se generarían todos correctos con la última foto de cada factura.

Quizás esté equivocado pero entiendo que la firma no deja de ser una cadena de caracteres especifica que se puede guardar en un campo de la factura, con lo cual siempre podrás regenerar el xml cuando quieras, no haría falta guardar cada xml por si lo requiere hacienda ya que podrás regenerarlos cuando te lo exijan.

Por ejemplo cuando firmas una factura electrónica con el certificado digital :
</ds:SignedInfo>
<ds:SignatureValue Id="Signature-e488077f-3ef5-445a-8ba0-b5ce49a5a2fc-SignatureValue">F5512COqupJ0YPXM70N/CvnX7F6n+8bvupqIxR+AGtLE6RThxzemHMLAYZaj1e6e8xEHoejY1oo3sDyuov/hoAlRjwk/0VJkhx+xsQ3p9xE9N7sTTPUdyRmS/J9kab3sTeVJaOKNkoz+AmpekCRIdv5Zc7SbAIXvhIuqdvUD5DmNZjFrX6fwbmUDQDW/R5erRane/cJhAb9QCVfsNEsZZpITarfhYabe3JgOaqS9XJYHHSsjbnFMLLJWlOZC/QB7t8MEez9cjS9v+rqLuv9GyCoswxuNw==</ds:SignatureValue>
<ds:KeyInfo Id="Signature-e488077f-3ef5-445a-8ba0-b5ce49a5a2fc-KeyInfo">
<ds:X509Data>
<ds:X509Certificate>MIIIyzCCB7OgAwIBAgIQHfcbEeyvXcVlOMY6oDfmbzANBgkqhkiG9w0BAQsFADBNMQswCQYDVQQGEwJF UzERMA8GA1UECgwIRk5NVC14guFNj6IXjDFwB6+f8fYhAsabiqSg3i/5nk3yVH9mF/XzxPAKJ+Fk69oqtT6a7yHMsvSrQ4G7NmJ5mVcm/aSI/KRkpWLQ9TRYtw9tYgEvYPEOdNYHmW/HolveDDAywKQ8A+NAwlENs5aYCTg3bWBZj0BHX5MS9Dv0xkdaw1FfUXnp93YJcAAmqoUd3AuLUCaRcOyNeI=</ds:X509Certificate>
<ds:X509Certificate>MIIG3DCCBMSgAwIBAgIQYcLU1PaprndVkma5ja/WITANBgkqhkiG9w0BAQsFADA7MQswCQYDVQQGEwJFUzERMA8GA1UECgwIRk5NVC1SQ00xGTAXBgNVBAsMEEFDIFJBSVogRk5NVC1 SQ00wHhcNMTUwNjMwMDk1MTUzWhGZubXRyY21jYS9PY3NwUmVzcG9uZGVyMDsGCCsGAQUFBzAChi9odHRwOi8vd3d3LmNlcnQuZm 5tdC5lcy9jZXJ0cy9BQ1JBSVpGTk1UUkNNLmNydDAfBgNVHSMEGDAWgBT3fcX9xOiaG3dkp/UdoMy/h2CabTCB6wYDVR0gBIHjMIHgMIHdBgRVHSAAMIHUMCkGCCsGAQUFBwIBFh1odHRwOi8vd3d3LmNlcnQuZm5tdC5lcy9kcGNzLzCB pgYIKwYBBQUHAgIwgZkMgZZTdWpldG8gYhbWqC6z7KeGyZBTeVIilPhp+xZzJnvFVBjN6s2j7W3+esQkiT4SdY9RN+c3tBuWF54U Nc7YVe6KVTjzkpev9szp6vUNQ+A45i2KGXRLN6/16nA9fujzITRWmX4tOGABo0aL/wBrf3Po89gvZwZRaVQ9Bw/KfEF8eZDhA1MgQKSPJLSXSl58elHGFLUR2CQMGl+mgfPB0qZUUkRG/RYpZLocczAz6pfkxA3Mt3DfIyVtA/YJ0O4ZYpdbH9zdJZI1RQEWmFrMOrEAWmGIG0SmNpARqOPJsTQJomUcvd3EvA7so2LzLJ+Sjj2So=</ds:X509Certificate>
<ds:X509Certificate>MIIFgzCCA2ugAwIBAgIPXZONMGc2yAYdGsdUhGkHMA0GCSqGSIb3DQEBCwUAMDsxCzAJBgNVBAYTAkVT MREwDwYDVQQKDAhGTk1ULVJDTTEZMBcGA1UECwwQQUMgUkFJWiBGTk1ULVJDTTAeFw0wODEwMjkxNTU5NTZaFwpLuHvUBKwrZ1pe bbuCoGRw6IYsMHkCtA+fdZn71uSANA+iW+YJF1DngoABd15jmfZ5nc8OaKveri6E6FO80vFIOiZiaBECEHX5FaZNXzuvO+FB8Txx uBEOb+dY7Ixjp6o7RTUaN8Tvkasq6+yO3m/qZASlaWFot4/nUbQ4mrcFuNLwy+AwF+mWj2zs3gyLp1txyM/1d8iC9djwj2ij3+RvrWWTV3F9yfiD8zYm1kGdNYno/Tq0dwzn+evQoFt9B9kiABdcPUXmsEKvU7ANm5mqwujGSQkBqvjrTcuFqN1W8rB2Vt2lh8kORdOag0wokRqEIr9baRRmW1FMdW4R5 8MD3R++Lj8UGrp1MYp3/RgT408m2ECVAdf4WqslKYIYvuu8wd+RU4riEmViAqhOLUTpPSPaLtrM=</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue>
<ds:RSAKeyValue>

Puedes leer toda la hilera de mensajes. Pero para resumir, creo que el consenso aquí es que tu cliente se va a decantar por un sistema Veri*Factu. Por qué, para que se decante para un sistema no-veri*factu, tiene que tener muy buenas razones, con todos las pegas que tienen estos sistemas.

Realmente, Hacienda está poniendo toda la presión que puede, en su comunicación (de momento), para que las cosas pasen por Veri*factu; por tanto la lógica para tu empresa es convencer al cliente de ir por este lado (y menos curro; o menos inversión, si tienes que venderlo a tu jefe; cosas de palabras).
Aparte de los que quieren ir siempre en contra de lo que dice Hacienda o el gobierno, por qué sí (y tienen todo el derecho de opinar así), creo que las únicas empresas que deben considerar no-veri*factu son las que tienen sistemas en casa que son más baratos de adaptar a este modalidad que al Veri*factu; si no, no tiene lógica ir por este lado.
Y esto antes de hablar del suplemento de costes por ser un sistema de facturación compatible no-veri*factu (con más funciones). Qué serán vendidos en menores cantidades, por tanto con menor retorno de las inversión para las empresas de software.

No me he explicado bien.
Por supuesto debes firmar en el momento de la generación, no en el momento del envío.
Pero una vez firmado, no estás obligado a almacenar los registros con el mismo formato XML que él que se hará el envío bajo requerimiento: puedes almacenar la firma en un lugar, el contenido de los nodos en otros etc. Solo debes estar en capacidad de garantizar que generarás un XML con el formato correcto para que la firma valide, en el momento de cumplir con algun requerimiento.

Dicho esto, si siguen con la necesidad de referirse a múltiplos esquemas XSD (que era lo opción presentada en el primer borrador que estaba), almacenar y luego presentar los registros dentro de un conjunto por el requerimiento será un lío por culpa de los múltiples xmlns: (hay mensajes anteriores que lo expliquen en la práctica). Si solo se necesita un solo espacio de nombres, es mucho más sencillo deconstruir el XML (y también firmar y validar; ganamos todos). Ya veremos... cuándo se publique. :o

Esto viene directamente de las preguntas y respuestas de una de las presentaciones:

"Se recuerda que el registro de facturación debe ser generado inmediatamente antes o simultáneamente a la expedición
de la factura. Quiere eso decir que, si se ha podido imprimir la factura, el registro ya se ha generado y por lo tanto debe
existir y, en el caso de NO VERI*FACTU, conservarse. En el caso de VERI*FACTU, será necesario reintentar la remisión
hasta conseguirlo y marcar el campo "Incidencia" en la remisión del registro de facturación. ..."


La opción de generarlos cuando los pida hacienda no es viable. Los necesitas en el momento de generar la factura y no tendria sentido, porque es justo lo que se quiere, que generes el XML "Registro de facturación" en el momento para encadenarlos y así evitar que a partir de ese momento puedas modificar la factura original.