Ok muchas Gracias
Pero aún no lo deben haber actualizado, por que me da error.

Acabo de probar con lo antiguo y funciona bien.

Ahora probaré cambiando.

Pues de momento, con lo nuevo falla.

Ok, pero gracias, ya he tomado nota. habrá que esperar que lo pongan en el apartado de desarrolladores, de momento no se ven cambios.

Yo solo lo he notado comparando el nuevo xsd con el antiguo.

cambios.
 

An cambiado algunas chorradas, por ejemplo antes Se llamaba -> ahora.

Cabecera -> CabeceraType
CabeceraRemisionVoluntaria -> CabeceraTypeRemisionVoluntaria
CabeceraRemisionRequerimiento -> CabeceraTypeRemisionRequerimiento.
Han cambiado los namespaces generados en la importacion.


Xml Generado y enviado.
Da Ko, con el nuevo dice que justamente no se ha encontrado la cabecera en el envio...
Hbra que esperarse un par de dias a ver si actualizan?

Yo trabajo igual que tú, genero el XML "a pelo".
Para ayudarme, cada vez que publican cambios en la estructura, me descargo el "wsdl" y los "xsd", en una carpeta nueva y vacía cada vez, y usando "SoapUI", tal como explicó algún compañero en este mismo foro, se puede generar un "xml" a modo de plantilla, lo que permite revisar más facilmente.

Llevas razón , desde el inicio del hilo
ll han dicho varias veces. Me tengo que instalar la herramienta y aun no la he puesto

Por cierto sabéis que significa esto
Puede ser que haya que quitar el encapsulamiento soap?

CAmbios namespace
 

Hombre algo an cambiado.
Antes.

Ahora.

Ya lo he entendido.
Bufff me cuesta
Significa que necesitan validar el xml contra xsd o wdsl sin tener que enviar.. y con el nuevo esquema lo.permite.

Osea, para verifica la estrucktura del envio e integridad antes de enviar... y para los pobres mortales como yo, eso como se hace??

Hola, alguien sabe que es esto ?
Otra cosa ahora an añadido suministro de factura...
Se viene envio de facturas tambien ademas de los registros?

Tienes que tener opciones de importarte el xml y validarlo contra el xsd cada sistema de desarrollo lo tiene: vb, php...
Las funciones te devuelven si es correcto o donde tiene algun error,.por ejemplo un formato numérico que.le falte algún decimal obligatorio en el esquema xsd... eso te da más tranquilidad al enviar por que haces una co.probacion previa,y ea lógico que hayan solicitado a verifactu que modifiquen el esquema por que no se podía validar sin enviar, y lo lógico es que se pueda validar previamente

Pues a GooGlear se a dicho, a ver como se puede hacer con C#.

Noticias frescas.
 

Por cierto, acabo de entregar el vehiculo a un cliente asesor fiscal, que venia de hacer un cursillo con los responsables de hacienda, y en tre otros "Palos", han hablado del verifactu, les han dicho que la entrada en vigor, obligatoria se aplaza hasta el 1 de enero de 2026, y que nos van a dar de tiempo hasta Julio de 2025, para que adaptemos los sistemas de facturacion y 6 meses desde ahi hasta enero para que los usuarios se acostumbren al uso hasta que porfin entre en vigor.
Supongo que no tardaran en comunicarnos a nosotros algo por el estilo.

Si nuestro asesor nos ha dicho lo mismo, esperan aprobar el boe en breve y poner esas fechas,
Jejeje, ya verás de retrasos que meten después.
Ellos lo saben, pero tienen que ir poniendo plazos para que nos apretemos el culo.

Yo lo he intentado en vb y de hecho me comprobaba algunos xml/xsd antiguos, las nuevas versiones de xsd como tengan twngan referencias extrrnas me dan error. Estoy en el prerromano.
El año que viene tengo curso de .net pero ya se me hace tarde para pasar todo el software. He dedicado horas a buscar soluciones gratuitas y todo pasa a comprar apis etc. Paso de gastar para esos total si me devuelve error de estructura no se lo van a comer y la única diferencia es que me devolverá el error el envío, por que parar de facturar por eso no lo voy a hacer si lo demás está correcto, qr...
Y el qr es bastante difícil que sea erroneo, son pocos campos y ya está superverificado, así que desistí de esa validación. Además si hay que verificar contra un xsd con referencias a otros xsd externos hay que tener conexión y tendría que hacer más pruebas de 1ue pasa cuando no hay conexión cuanto tarda en devolver el error etc, más retardos
.aunque supongo que también los nuevos desarrollos te importan todas las referencias externas a tu sistema y se comprueba todo localmente, ya me contarás cuando pruebes.

Importante subsanacion de cliente factura
 

Sí, he dicho subsanación .
Buenas noticias para este lío.
Cuando me dé tiempo analizo respuesta que me ha dado verifactu para los distintos escenarios de errores en el cliente, y de principio parece que es con registro de subsanación.
Facil no?
Leo más detenidamente la respuesta y después os pongo la copia.

Pasate la info cuando puedas, mañana me tenia que poner justo a eso, cambiar destinatario de factura por error en el mismo...

Hola, estaba de copas jeje, pero como veo que la necesitas y me has ayudado mucho te la paso, yo creo que es fácil de analizar pero erra largo de leer:

Bien, ya me he leído esto de los cambios de clientes.
Como veis, mi consulta era sobre facturas sustitutivas, pero evidentemente en la respuesta se intuye que la operativa es igual para facturas normales. Con lo cual, al menos a mi, me va a facilitar muchísimo la programación de esta parte y por supuesto es más claro, lo único es que internamente tenemos que tener en cuenta algunas cosas para que esas modificaciones no nos cree problemas fiscales por que perdamos o damos.un salto aparentemente irregular en esa trazabilidad y en algún momento pueden provocar inconsistencia de datos a la hora de las declaraciones, hay que analizar bien esto según el particular desarrollo de cada uno.
Que tengo que tener en cuenta en mi caso:
1. No dejar al usuario hacer esos cambios sin una autorización analizando bien la situación, dejar cambiar los datos del cliente en una factura es un tema delicado.
2.informar a contabilidad adecuadamente y eficientemente de dicho cambio, sobre todo si corre peligro de haber recibido ya la factura con el dato erroneo.
3. Guardar correctamente en nuestras bases de datos el cambio y crear logs de dicha trazabilodad para que nosotros podamos saber que ha pasado ante una duda, incluso, como serán pocas incidencias, crear unas logs separadas para estos casos que pueden ser hasta un correo electrónico. Yo estoy usando mucho esto último para determinadas operativas
4. Atentos a los que estén en SII, por que si se ha presentado incorrectamente esos registros hay que modificarlos, para lo cual si no te lo permite el programa que tengas de SII en la web del SII te permite ese cambio durante bastante tiempo, creo que durante el año en curso.
5. Para nuestra gestion y si ha pasado mucho tiempo desde que se emitió la factura voy a pasar al plan B y hacer abono al cliente erroneo y hacer de nuevo la factura e incluso bloquear las facturas para que no se puedan hacer modificaciones de clientes pasado x meses.
6. En nuestra base de datos queda asignado internamente el tiquet al cliente y también tengo que reasignarlo, por que lo tengo que tener en cuenta por si hay que hacer rectificativas posteriormente.
7. Si hacéis un cambio de cliente debéis revisar en vuestra base de datos si ha habido rectificativas de esa factura al cliente erroneo, en ese caso hay que "obligar" o al menos avisar claramente de que las posibles rectificativas también hay que modificarlas y una de dos, o que se modifiquen automáticamente o informar de cuáles son.

Nadie dice que esto sea fácil pero yo creo que mejor que la otra operativa que obligaba a emitir nuevos registros y nuevas facturas , abonos...
De esta forma modificamos, legalmente, el mismo registro de nuestra base de datos y no se emiten negativas, positivas etc que además para temas estadísticos complicaria el desarrollo y lectura de los datos

Hola, gracias por la info y la explicacion, en mi caso como son facturas simples, simplemente hago el alta de subsanacion y como intuyo, cambio en mi base de datos , en el reguistro de la factura un cliente por otro y reimprimo la factura con los mismos campos, iva,numero, etc..
A la gestoria , y en su caso al cliente le doy la factura con los datos ya correctos , sin mas.
Es asi?

Así de simple parece ser

Resumiendo, si con subsanación podemos arreglar datos de facturación y datos del destinatario. ¿Qué sentido tienen las rectificativas?.

Ten en cuenta que la subsanacion no te dan fecha de lo que puedes tocar por qur no afecta a las declaraciones peror la rectificativa afecta al próximo cierre de iva.
Para otras rectificaciones
Cosas que afecten a la cuota de iva
Importes líneas de artículos...

La manera más fácil de hacer una rectificativa:

1º)Emites una factura negativa, para anular la factura original.
2º)Emites una factura rectificativa con los importes correctos.

No hay anulación, ni subsanación.

Bueno. Según lo que quieras hacer
Si solo quieres quitar un registro sacas una rectificativa por diferencias de wse artículo. Pero eso no viene al hilo de las rectificaciones de errores de clientes, que es lo que estábamos con duda, y la respuesta de verifactu ha sido clara

dudas
 

Yo no entiendo ni lo de rectificativas ni lo de las sustitutivas.


1.- se emite la factura a quien sea.
2.- si está mal, da igual el dato, nif del cliente, importe, ivas. lo que sea q este mal, se hace una abono de la misma.
3.- se emite una nueva factura con la corrección hecha

4.- punto pelota.


vamos yo es lo que pienso hacer.

Pues muy bien hecho. Ole tú que puedes.:D

No sé, creo que el técnico que respondió la consulta no es de este planeta. A ver, Cuando dice

Además, le planteamos nuevos ejemplos para tratar de aclararlo en la medida de lo posible:
1. Usuario rellena factura y envía.
• Se rechaza en el momento de envío por algún motivo de error.
• Si el error no está contemplado en el registro de facturación (ejemplo: rechazo porque el NIF del destinatario es erróneo porque se han confundido al teclearlo) procede alta por rechazo. Se crea un NUEVO registro de facturación *con los datos corregidos, pero que sigue tratándose de la misma factura (mismo número de serie, NIF obligado y fecha de expedición). Se envía usando "Alta por rechazo" (· <Subsanacion>=S *<RechazoPrevio>=X).

De verdad el Nif del destinatario no está dentro del Registro de Facturación ?. Y si el Nif del destinatario es incorrecto, ¿ se soluciona con una subsanación obviando la obligatoriedad de emitir una Rectificativa como obliga reglamento de facturación ?

luego dice ...

Si el error que detecta el usuario es un error contemplado en el registro de facturación (se equivocan en el tipo impositivo) y que se debe solucionar con una NUEVA FACTURA (con otro numero de serie, etc). entonces no procede el alta por subsanación sino, que se deberá generar un nuevo registro de facturación que corresponderá con una nueva factura (distinto número de serie, NIF y fecha que correspondan), tendrá el indicativo de tipo de factura RX, y será un "alta" con la información que establezca el reglamento de facturación.

vaya, el tipo impositivo sí está dentro del registro de facturación, aquí si hay que aplicar rectificativa pero el Nif del destinatario está..... en Burgos ( que por cierto, es un sitio maravilloso )

y luego tiene el detalle de decir ...

Es importante tener claro que el RD no modifica el reglamento de facturación. La misma forma de "solventar errores" que existía es la que se debe aplicar ahora. Esto requiere de conocimientos de la persona que emite una factura (igual que lo ha requerido anteriormente) para discernir si debe o no hacer una factura rectificativa, o si puede hacer una subsanación.


Yo creo que conocimientos le faltan a él.

duda
 

Alguien ha enviado con éxito una factura XML al sistema de pruebas con curl.exe de windows ?

Sí, la he enviado. Y han dejalo las indicaciones en los primeros post del hilo, donde dejan todos los ftps y ayudas m

Ya, pero pro otro lado, es evidente que tienen que facilitar una poco ciertos procesos que el reglamento de facturacion, y si verifactu ha inplementado un nuevo concepto que tiene en cuenta la complejidad de la reparacion de este tipo de operación q7e debería ser sencilla y ese reglamento no contemplaba esa posibilidad que era de hace 11 años, posiblemente en breve veamos alguna modificacion en el reglamento, yo lo he visto congruente, les han dado una vuelta de tuerca y si se hace de esa forma y tienen los registros y pueden establecer la trazabilidad pues ya posiblemente cumpla, el técnico que ha contestado no creo que lo haya hecho a las bravas, además dice que esas dudas estarán en las respuestas de las Faqs, digo yo que algo se habrá informado para no meter la pata.
Yo al menos voy a tirar por esta vía que es la rápida. No contemplo la opción que propones si en verifactu no me lo dicen.

Mira lo que dice textualmente

Es importante tener claro que el RD no modifica el reglamento de facturación. La misma forma de "solventar errores" que existía es la que se debe aplicar ahora. Esto requiere de conocimientos de la persona que emite una factura (igual que lo ha requerido anteriormente) para discernir si debe o no hacer una factura rectificativa, o si puede hacer una subsanación.

Tu explícale a una peluquera que es una factura rectificativa, por sustitución o por diferencias, una factura de subsanación. No son contables. El sistema se tendrá que adecuar a los usuarios sin ningún conocimiento del RD de facturación.

Bueno para eso está la pericia del equipo de programación. Si caemos en lo más bajo porque programáticamente no somos capaces de darle esa información al cliente, si debe hacer una cosa u otra, quizás el problema lo tengamos nosotros. Hay que recordar que tenemos que firmar una declaración de responsabilidad en la que no sólo estamos obligados a cumplir con el reglamento Verifactu sino que además tenemos que cumplir con el reglamento de facturación.
Pero bueno, yo sólo expongo mi opinión, para eso está el foro. Luego cada uno se responsabilizará de lo que estime oportuno.

En esto tiene toda la razon, pero si los que contestan de la AEAT, no nos dejan claro el camino que tenemos que seguir, que tenemos que ser adibinos, o en ete caso crear 3 opciones de como sustituir el cliente final de una factura??

Si, estoy de acuerdo. Pero habrá que capar algunas opciones. Mejor que no lo hagan a que lo hagan mal. Por ejemplo en caso de rectificativas una sola opción. Anulando la factura con una factura negativa y emitiendo una nueva factura marcada como rectificativa. Nada de diferencias o sustitución.

duda
 

vi el XM, lo he copiado a pelo, he intentado enviar, cambiando algunas cosas, nif y nombre x si las moscas y q no estuviera duplicada, por así decirlo, @ermendalenda , pero al ejecutar el curl.exe me marca errores:


== Info: Trying 195.77.198.76:443...
== Info: Connected to prewww1.aeat.es (195.77.198.76) port 443 (#0)
== Info: schannel: disabled automatic use of client certificate
== Info: schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030E) - No hay credenciales disponibles en el paquete de seguridad
== Info: Closing connection 0



le he realizado con un certificado que está comprobado que funciona, no se si a alguien le ha pasado lo mismo.

Yo es que no entiendo porque nos liamos con la emisión de facturas rectificativas, parece que como no la entendemos entonces tendemos a torcer el reglamento. Aceptamos cosas como que hay que desglosar las bases tipos y cuotas en la factura completa y nadie lo discute. Yo sigo un 'abc' claro en este aspecto.

1.- Se produce una devolución de mercancía a posteriori de una operación de venta ->. Se emite Rectificativa x diferencia con la cantidad devuelta con la marca R1, o si hay una operación posterior con el mismo cliente y la operación tiene el mismo tipo de Iva que lo que me devuelven, aprovecho esa factura para hacer la devolución sin rectificativa.

2.- Se produce un descuento en factura a posteriori de una operación de venta (por ejemplo un Rapell o un Pronto pago) ->. Se emite Rectificativa x diferencia con el descuento aplicado con la marca R1

3.- Te equivocaste en la identificación de destinatario ->. Se emite una factura de abono anulando la factura original y luego emites una Rectificativa x sustitución con la clave R4

4.- Te equivocaste en los tipos impositivos ->. Se emite una factura de abono anulando la factura original y luego emites una Rectificativa x sustitución con la clave R4 ó como segunda opción, anulas la factura original y emites rectificativa x sustitución con clave R4 para que no te rechacen por segunda vez el tipo impositivo incorrecto.

5.- Te equivocaste en la fecha de expedición de la factura ->. Se emite una factura de abono anulando la factura original y luego emites una Rectificativa x sustitución con la clave R4 y la fecha correcta.

6.- No sabes en qué coño te has equivocado ->. Se emite una factura de abono anulando la factura original y luego emites una Rectificativa x sustitución con la clave R4.

Creo que, salvo recuperación de cuotas por impago, no hay más casos de emisión de rectificativas.

Este tema está muy acotado. Si me he dejado algún caso, por favor, que alguien lo apostille.

Y en cuanto las sustitutivas de una simplificada por una completa, es que no hay ni que pensar, se copia el contenido exacto de la simplificada sobre una completa con el cliente identificado y se emite una simplificada idéntica a la original en negativo para anularla. Siempre utilizando como fecha operación de ambas facturas la de la factura simplificada que queremos sustituir para evitar rechazos debido a Ivas que en el momento de la sustitución ya no están vigentes.

Espero que esto quite un poco de hierro al asunto y pido disculpas por ser tan pesado con las rectificativas