Buenas nincillo.

Importe el wdsl del soap con la version 1.2 y a continuacion hice lo que comentas, o sea sustitui

por estos dos:

y con esto me funciono

Creo que me he despistado un poco. Rechazan mi factura por error en el tipo impositivo y envío rectificativa por sustitución pero yo entiendo que no queda el hueco en la numeración; esa factura rechazada sigue estando en mi sistema y seguirá contando con su número. ¿Cómo es que queda el hueco? ¿Por eliminar la factura? Para contrarrestar sus valores... ¿Cómo he de hacer con la incorrecta además de generar otra adicional rectificativa? ¿Hago otra complementaria con el tipo también incorrecto pero en negativo para contrarrestarla?

duda
 

alguien ha conseguido instalar la unidad como componente "VerifactuHTTPRIO"


error:
HTTPWebNode.ClientCertificate.Stream := Certificate;
HTTPWebNode.ClientCertificate.Password := CertPassword;

La factura rechazada siguen en tu sistema SIF pero el hueco queda en la Aeat, en tu SIF la factura reza como anulada, sin huecos. El procedimiento para rectificar en dos pasos que es el que yo utilizo sería :

1.- Emitir una Anulación del Registro con la marca SinRegistroPrevio = S (ya que no existe en la Aeat) y la marca RechazoPrevio = S
2.- Emitir Factura Rectificativa por sustitución donde se indica la rectificación de la factura que ha sido rechazada

Esta información que aporto está contrastada con el [email protected]

Gracias Antoine0.
En resumen, se pueden emitir Facturas completas y Facturas Simplificadas cualificadas (con identificación de destinatario) y ambas se informan con la clave F1, sólo en caso de factura simplificada cualificada se marca la opción FacturaSimplificadaArt7273=S

Y la marca FacturaSinIdentifDestinatarioArt61d se pone a "S" cuando emites una factura simplificada a un cliente que no necesitas identificar por el artículo "6", punto "1" apartado "d", pero que normalmente, si la venta a es público esta marca no se utiliza

Hola sglorka, el primer caso es correcto, es decir:

se pueden emitir Facturas completas y Facturas Simplificadas cualificadas (con identificación de destinatario) y ambas se informan con la clave F1, sólo en caso de factura simplificada cualificada se marca la opción FacturaSimplificadaArt7273=S

pero en el segundo caso, tanto la factura simplicada no cualificada como la factura ordinaria sin identificar se informan con la clave F2, pero para el caso de la factura ordinaria sin identificar se pone la clave FacturaSinIdentifDestinatarioArt61d a S.

Lo de Factura ordinaria sin identificar es porque se utiliza un identificador que no lo recoge la AEAT, por ejemplo un pasaporte o un documento de identificacion de otro pais. En este caso en destinatario habria que poner el IDOtro en vez del NIF.

Sí, tiene sentido lo que dices.
Gracias

TicketBAI y VeriFactu
 

Hola, tengo una pregunta:

Las empresas del País Vasco están exentas de VeriFactu porque ya envían TicketBAI?
O tendrán que cumplir tanto a TicketBAI como VeriFactu y enviar las facturas a dos agencias tributarias?

Lo he buscado por internet pero en diferentes páginas web dicen cosas distintas.

Muchas gracias

En el caso de los territorios forales del País Vasco y Navarra, el reglamento solo será aplicable a los obligados tributarios correspondientes que tengan su domicilio fiscal en territorio común.

Entiendo que los que están haciendo TBAI (porque son empresas con sede en el país Vasco) están exentas de hacerlo aquí.

Exacto, eso depende de donde tenga el domicilio fiscal, se aplicara uno u otro sistema.

De hecho, conozco de empresas del Pais Vasco que cambiaron su domicilio fiscal para no estar en el sistema de TICKETBAI.

Ok es lógico

Muchas gracias Neftali y delphiGar por vuestra respuesta!

Hola,

Una cosa a tener en cuenta:
Las empresas, con domicilio fiscal en el País Vasco, y que están en el SII, siguen obligadas al SII a pesar de estar también obligadas a TicketBAI.
En el resto del estado, si se está en SII, no se está obligado a Verifactu.

Saludos

Buenas, se sabe cuándo saldrá al final la orden ministerial? se suponía que tenía de fecha para el 1 de octubre y no se ha dicho nada más sobre el tema.

Recargo de Equivalencia
 

¿Alguien sabe si en las facturas con Recargo de Equivalencia hay que indicar "ClaveRegimen = 18" (Recargo de Equivalencia) o no?

Estoy enviando facturas con Recargo de Equivalencia y me las acepta sin errores tanto con ClaveRegimen = 01 como con ClaveRegimen = 18

Otra cosa:

Estoy recibiendo este error...

Codigo[4112].El titular del certificado debe ser Obligado Emisión, Colaborador Social, Apoderado o Sucesor.

...cuando intento enviar una factura como persona física, usando mi NIF y Nombre reales.

Lo curioso es que ya he enviado varias igual, y han sido aceptadas, pero de repente ahora me da ese error :mad:

Confirmado: he vuelto a intentarlo 10 minutos después y ya no me da el error

Generar y Recuperar posteriormente IXML RegistroAlta
 

Por si alguien sabe la solución , si la tiene... mientras seguiremos investigando... :)


Generar el XML RegistroAlta con IXML.


El problema que me he encontrado es que como el XML Tiene dos Prefijos , sum: en RegistroAlta y Sum1: En IDVersion y el resto , luego no puedo Recuperar el Objeto SuministroInformacion.IXMLRegistroFacturacionAltaType Correctamente.


FacturaCargadaIXML.XML es correcto, varga el XML , la carga , pero el FacturaCargadaIXML.IDVersion , etc... esta vacío , parece que no coloca los nodos en su sitio.


Antes de no poder usar LoadXMLData igual alguien tiene una solución.

Gracias y Saludos

Pero tú puedes tener un cliente en SII, por lo tanto tu programa funcionaría sin enviar a verifactu, pero el cliente al año siguiente a lo mejor (por error o por lo que sea ) no avisa que no está en el sii y no estás enviando las facturas, yo no tengo claro que no haya que realizar todo lo de los eventos.

Ayer hice una consulta a hacienda donde preguntaba si hay alguna consulta donde podamos saber si un cliente está en el SII o no y nos dijeron que no, que con el certificado del mismo cliente si, pero no existe tal consulta y que por lo tanto es el cliente el que debe controlar si un año está en el SII o no está en el SII y si debe realizar verifactu o no por ese tema.

Hice otra consulta que si podíamos realizar verifactu con un cliente con SII pero todavía no me han respondido.

Obligaciones específicas de los SIF "NO VERI*FACTU"
 

Como se ha comentado mucho sobre las diferencias entre las obligaciones entre un Sistema Informático de Facturación VERI*FACTU y otro NO VERI*FACTU, he elaborado una lista con las obligaciones añadidas a NO VERI*FACTU, como punto de partida para que podamos añadir, quitar o corregir si he cometido errores.


- Obligación de conservar los registros de facturación y de eventos, asegurando su inalterabilidad e integridad
- Firmar con certificado cada factura del registro de facturación y cada evento (Art.6.c OM)
- Poder comprobar, bajo demanda, si la firma electrónica es válida (Art.6.d OM).
- Poder comprobar, bajo demanda, si toda o una determinada parte de la cadena de registros de facturación es correcta (Art.6.e OM).
- Poder acceder a consultar, comprobar y exportar la información del Registro de Facturación, en un formato legible y fácilmente accesible.
- Poder remitir, por requerimiento, los registros de facturación y de eventos a la AEAT.
- Generar el Registro de Eventos de:

- Inicio del funcionamiento del sistema informático como «NO VERI*FACTU».
- Fin del funcionamiento del sistema informático como «NO VERI*FACTU».
- Lanzamiento del proceso de detección de anomalías en los registros de facturación.
- Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de facturación.
- Lanzamiento del proceso de detección de anomalías en los registros de evento.
- Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de evento.
- Restauración de copia de seguridad, cuando ésta se gestione desde el propio sistema informático de facturación.
- Exportación de registros de facturación generados en un periodo.
- Exportación de registros de evento generados en un periodo.
- Registro resumen de eventos
- Otros tipos de eventos a registrar voluntariamente por la persona o entidad productora del sistema informático.

En la detección de anomalías en los registros de facturación y en los de eventos, se concretará si el fallo detectado es por:

- Integridad-huella
- Integridad-firma
- Integridad - Otros
- Trazabilidad-cadena-registro - Reg. no primero pero con reg. anterior no anotado o inexistente
- Trazabilidad-cadena-registro - Reg. no último pero con reg. posterior no anotado o inexistente
- Trazabilidad-cadena-registro - Otros
- Trazabilidad-cadena-huella - Huella del reg. no se corresponde con la 'huella del reg. anterior' almacenada en el registro posterior
- Trazabilidad-cadena-huella - Campo 'huella del reg. anterior' no se corresponde con la huella del reg. anterior
- Trazabilidad-cadena-huella - Otros
- Trazabilidad-cadena - Otros
- Trazabilidad-fechas - Fecha-hora anterior a la fecha del reg. anterior
- Trazabilidad-fechas - Fecha-hora posterior a la fecha del reg. posterior
- Trazabilidad-fechas - Reg. con fecha-hora de generación posterior a la fecha-hora actual del sistema
- Trazabilidad-fechas - Otros
- Trazabilidad - Otros
- Otros


Un saludo.

Hola,

Son 2 cosas diferentes:
- Una es el régimen de IVA en el que está dado de alta, en la AEAT, el emisor de la factura: régimen normal, régimen simplificado, régimen de recargo de equivalencia, etc
- Y otra es emitir una factura a un cliente que está en régimen de recargo de equivalencia y por tanto hay que emitírsela con RE.

Saludos

Gracias, Sistel

El problema, o mi confusión, viene porque creo recordar que en TicketBAI, la suma de los importes, cuotas, etc. era distinta si el emisor está en régimen de Rec. Equiv. o si es solo el cliente final el que está acogido al Rec. Equiv. O al menos cuando ambos (emisor Y receptor) estaban acogidos al RE.

Pero VeriFactu "parece" más sencillo a la hora de hacer los cálculos, no sé si es apreciación mía o es que realmente es así.

Total, recapitulando...

Si el Emisor está en Regimen de Recargo de Equivalencia, hay que marcar la Clave Regimen "Recargo de Equivalencia"
Pero si solo es el cliente quien está acogido al RE y debemos emitir una factura acogida al RE, entonces eso no es necesario, y basta con indicar los porcentajes y cuotas del RE en el desglose.
Y si ambo están acogidos a RE, pues ambas cosas.

¿Correcto?

Quiero tener claro estas cosas antes de meterme a hacer pruebas con rectificativas, sustitutivas, inversión del sujeto pasivo, etc.

Validaciones previas antes del envío
 

Tengo una duda con respecto a las "validaciones" del XML antes del envío. Me gustaría saber cómo lo planteáis vosotros...

Para evitar facturas rechazadas y tener que estar emitiendo sustitutivas, anulaciones, rectificativas, etc. lo ideal sería comprobar que todas las validaciones (del documento de validaciones) son correctas.
Como son un rollo bastante complejo, con opciones enlazadas unas con otras, algunas que no pueden marcarse juntas pero con excepciones, etc... ¿cómo lo hacéis vosotros? Porque yo hoy casi termino con dolor de cabeza.

En nuestro software, el usuario elije en un desplegable algunos de estos datos (tipo de rectificativa R1, R2, R3, motivo de factura exenta, etc.) y otras son automáticas (según la configuración del programa, según tipo de empresa (regimen iva...), según la provincia (IVA, IGIC o IPSI), etc.).

Por lo tanto, cuando llega el momento del envío, antes hay que comprobar que lo que ha elegido el usuario para cada documento, es compatible con lo demás.

Yo actualmente genero el XML primero y una vez generado, antes de enviarlo, lo "valido" y, o bien lo envío o muestro un error y cancelo el envío, pero no sé si es la mejor forma de operar o no.

Encima hay que revisar uno a uno los porcentajes de iva y re, con la fecha de la factura, etc. En fin :rolleyes:

Necesitas Delphi 12
 

Hola,

Si un negocio está dado de alta en el régimen de recargo de equivalencia es porque funciona como comercio intermedio entre un proveedor y el cliente final.
El proveedor además de facturarle con IVA también debe recargarle el RE.
Y él, en sus facturas a clientes debe cargar sólo el IVA.
Está exento de hacer declaraciones de IVA: ya ha pagado IVA + RE de lo comprado y ha cobrado IVA de lo vendido. Y Hacienda con eso se da por satisfecha.
Y, lógicamente, no puede vender a clientes que también estén en régimen de recargo de equivalencia: no puede emitir facturas con RE.
Sólo puede vender a clientes finales.

Saludos

Hola.

¿Conseguiste instalar el parche y/o hacer que te funcionara de alguna manera en Windows 7 el TLS 1.2?

Pues lo primero que hice fue instalar algunas actualizaciones que tenía pendientes de windows (por si acaso) y :eek: se me fastidió el arranque del sistema y no hubo forma de repararlo. Llevo casi una semana intentando ponerlo todo al día. Si consigo avances en ese sentido lo pondré por aquí por si a alguien le viene bien pero la verdad es que soy pesimista al respecto.


Saludos.

AEAT - Convocatoria de reunión Entidades de Desarrollo - 28 de octubre
 

AEAT - Convocatoria de reunión Entidades de Desarrollo - 28 de octubre (12:00) de 2024 - DIT
https://www.agenciatributaria.es/AEA...24___DIT.shtml

Entre los puntos del día está estos, que afectan a este proyecto:
...
13:30 – 13:45 h. Estado de los Proyectos de Sistemas Informáticos de Facturación
13:45 – 14:00 h. Ruegos y preguntas

Toda la información y registro en el link de arriba.

13:30 – 13:45 h. Estado de los Proyectos de Sistemas Informáticos de Facturación

¿Solo 15 minutos???

Pues, o lo tienen ya a punto de caramelo o les queda más días que longanizas para ponerlo definitivamente en marcha.
No se, no se...

a ver que nos cuentan en esta reunión.... mi pronóstico es que retrasan todo hasta 2026

En los "ruegos y preguntas" ¿se les podrá "rogar" que se olviden de esta ñapa? :D:D

Alguien tiene problemas con las url de hacienda

Y 15min de preguntas.para todos los temas?
Preguntará 1 persona lo más elemental y no dará tiempo a más. Esto va para largo.o es un error en los horarios.

O que nos contraten, fijo ganan.
Ya verás más de un negocio que chapa por esta movida.

Esta reunión es para mostrar las novedades de los modelos informativos de hacienda. La convocan todos los años y la parte de verifactu y efactura, sera la misma que la del año pasado. Osea nada.

Yo voto por lo segundo... :D:D

Nif erroneo
 

Hola, estoy probando a realizar envios y tengo algun problema con dni de los que empiezan por letra, los tengo copiados desde el mismo documento, tanto los nombres como el numero de identificacion, pero algunos me responde esto "1109 -> El NIF no está identificado en el censo de la AEAT.. NIF:X*******Y", a alguno mas le ha ocurrido esto?

Yo tambien estoy teniendo problemas con los accesos a la web desarroladores. Me da error 404

Alguien puede poner el xml con ALTA FACTURA, pues estoy intentado enviar xml y me genera error en el detalle estoy viendo desde el EXCEL que descargue en su dia, pero creo que hay algo cambiado

Alguien pude poner el OSD para ver como esta estructurado


Tambien seria de utilidad si podeis postear un XML en funcionamiento

Gracias

Buenas, alguien sabe si han sacado ya la orden ministerial que prometieron para el 1 de octubre? y si no lo han sacado, no debería de retrasarse la implementación de verifactu? Se supone que tiene que haber un periodo de 9 meses desde que esta sale hasta que entre en rigor.

Que yo sepa NO está publicada.
Por lo tanto ya no hay tiempo para cumplir los 9 meses antes de la teórica fecha del 1 de julio de 2025

URL Desarrolladores
 

Buenos días, la cambiaron hace poco a esta :

https://www.agenciatributaria.es/AEA...ERI_FACTU.html


Saludos,

Muchas gracias, ya puedo acceder

Ahora a ver si alguien puede postear la OSD y un XML que funcione al subirlo

Yo ya tengo varios clientes que han decidido adelantar su jubilación al año que viene, para evitar tener que enfrentar toda esta movida.