Por lo tanto, entiendo que una empresa que está en "régimen de recargo de equivalencia" NO puede emitir facturas a sus clientes CON recargo de Equivalencia. Solo con IVA.
Así que la "clave regimen" sería "recargo equivalencia", pero SOLO tendría IVA en las facturas.

Y en el caso del "proveedor" (siguiendo tu ejemplo), sí le añade el RE a las facturas a este cliente, por lo que entiendo que el proveedor debe tener Clave Régimen = 01, para poder emitir facturas con RE.

O sea, que lo que está claro es que no se puede estar en ClaveRegimen = Recargo Equiv Y ADEMÁS emitir facturas con RE

¿Correcto?

Pues suerte con la "reparación" a ver si al final consigues algo...

Yo de momento estoy haciendo pruebas con la Delphi 12 Community, los WSDL y el HTTPRio y he atascado en un punto que de momento no he conseguido "desatascar".
Ya genero una parte del xlm, ya hago hago el envío y ya recibo la respuesta del servidor diciendo que me falta rellenar tal o cual campo. Hasta ahí todo normal. El problema lo tengo con el certificado y más concretamente con la contraseña de éste.

Opciones que se me han dado:

1) Si no relleno el CertName, me sale una ventana donde seleccionar el certificado y posteriormente, si el certificado no tengo instalado con contraseña, entonces me sale otra ventana para introducir la contraseña.
2) Si relleno el CertName con un valor correcto, entonces ya no me sale la ventana para seleccionar el certificado, sino que ya me sale directamente la ventana para escribir la contraseña (si la tiene)
3) Si relleno el CertName y el Password, me pasa lo mismo que en la opción 2, me selecciona el certificado correcto pero también me pide que introduzca la contraseña y de momento, de ahí no paso.

A ver si alguien me puede dar un empujón...

Un saludo.

Hola,

Efectivamente. Así es.

Saludos

Hola,

En el caso de TicketBAI, se excluyó de la obligatoriedad a los negocios de autónomos con jubilación próxima.
Tal vez hagan lo mismo en Verifactu.

Saludos

Hola de nuevo,

Ya conseguí subir mi primera factura a pruebas...voy por la segunda :D gracias por toda vuestra ayuda


Tengo una duda de como guardáis los xml (en modo VERIFACTU)


Vamos a imaginar que subo un envío de 20 facturas en un mismo "paquete"


Guardáis el xml "individual" de cada factura en vuestro ERP? Entiendo que sí


Y si es que sí, la fecha que ponéis en FechaHoraHusoGenRegistro entiendo que es la misma en las 20 facturas, con la que subió el fichero de las 20 a Veifactu. Voy bien?


Gracias de nuevo

Edari, podrias compartir un xml que te haya funcionado.
Yo estoy estancado en la seccion DESGLOSE no consigo pasasr

Gracias

Yo entiendo que ese campo es la hora fecha de cada factura, ya que se emite la factura y el qr a una hora determinada junto con el registro individual, otra cosa es que mandes varios registros en el mismo paquete. Pero el fechahorausogenregistro es de cada registro.

Nos está ocurriendo al hacer algunos envíos de pruebas, que si en alguno nos lo rechaza o no hay conexión justo en el momento de generar la factura y crear el registro del xml(que ya nos coge la fechahora en ese momento), y se envía algo después, nos lo acepta como "Aceptado con errores" indicando:
"El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos."

Esto vemos que ocurre aunque el envío se haga indicando la marca de "Incidencia" y aunque sea un envío del xml con subsanar y la marca de "RechazoPrevio", lo cual parece un poco raro, porque estos casos pueden darse si hay una incidencia de internet o similar y se envían con algo de retraso.

Se sabe si eso será siempre así y también si los registros aceptados así con ese error, pueden dejarse así, o requerirán que se haga luego otro envío con subsanación sólo para enviar un registro nuevo igual pero con fechahora actual? os está pasando lo mismo en estos casos?

120segundos?
Vaya tela me acabas de dar un disgusto. Yo lo envío a u tercero para que lo reenvíe a verifactu y se acaba de complicar con eso.

Aquí tienes


Es mi primera factura, no tiene encadenamiento


Saludos

Bueno al menos le meteré 1 min de adelanto a la generación que creo que admiten 1 minuto de margen de error así pasaré a tener 180segundos en vez de 120.

Bueno al menos le meteré 1 min de adelanto a la generación que creo que admiten 1 minuto de margen de error así oasare a tener 180segundos en vez de 120.

¿Te está dando algún error cuando lo envías?. ¿Cuál?

¿Tienes dudas de como definir los "objetos" en el propio código fuente?

A mi me estaba dando error al enviar en el TipoImpositivo y el problema era que aunque yo tenía programado:

Al xml realmente le estaba llegando 10,00.

Supongo que será como dices, que por cierto me viene mejor,...


El tema nace porque en esa primera factura subida me ha dado también el error del compañero Mlopez "El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos."


En mi prueba era normal porque entre que cree el fichero y luego lo subí pasó una hora porque estaba atendiendo otras cosas etc...pero el mensaje me hizo pensar que claro, cuidado con la que nos pude venir


Gracias

Gracias Edari, a ver si puedo seguir

Hola, yo no uso delphi, pero en c# lo que hago es cargar el certificado en una variable, puedes hacerlo desde el archivo de guardado o desde el propio winfdows y luego pasarselo talcual.

¿Alguien más está recibiendo estos errores de repente?

El XML no cumple el esquema. Falta informar campo obligatorio: "TipoUsoPosibleSoloVerifactu"
El XML no cumple el esquema. Falta informar campo obligatorio: "TipoUsoPosibleMultiOT"

¿Que yo sepa esos dos campos del nodo SistemaInformatico son opcionales, no? Vamos, que no están en rojo en el Excel...

Acabo de subir mi segunda factura y ok



Solo te puede decir eso

Segun leo en el esquema es obligatorio informar de estos campos:

TipoUsoPosibleSoloVerifactu

Especifica si para cumplir el Reglamento el sistema informático de facturación solo puede funcionar exclusivamente como «VERI*FACTU» (valor "S") o puede funcionar también como «NO VERI*FACTU» (valor "N"). Obligatorio en registros de facturación de alta y de anulación. No aplica en registros de evento.

TipoUsoPosibleMultiOT

Especifica si el sistema informático de facturación permite llevar independientemente la facturación de varios obligados tributarios (valor "S") o solo de uno (valor "N"). Obligatorio en registros de facturación de alta y de anulación, y opcional en registros de evento.

IndicadorMultiplesOT

Obligatorio en registros de facturación de alta y de anulación, y opcional en registros de evento.

Muchas gracias :-). Creo que me queda claro.

Sí, sacándolo del documento de validaciones porque de la descripción del Excel con el diseño de registro de facturación no se entiende esto...
Es que hay que mirarlo todo. Menos mal que estáis ahí. Muchas gracias.

el cliente manda con respecto a VERIFACTU o NO VERIFACTU, pero en nuestro caso ya lo hemos decidido y no vamos a hacer la opción NO VERIFACTU, es decir, el que quiera seguir con nosotros será VERIFACTU si o si y nuestros clientes en principio todos van a coger VERIFACTU.
Mi humilde consejo como desarrollador es no dar opción a NO VERIFACTU y no complicarse la vida tontamente.

Disculpa, verás que tengo un lio impresionante. Me desdigo de lo dicho antes (que creía que lo entendía). A pesar de las evidencias y de que has dicho que se ha contrastado con Verifactu a través del correo electrónico... me cuesta entender ni siquiera la necesidad de estas etiquetas.

Yo lo veo contradictorio porque el artículo 7.2 del decreto mencionado (1619/2012) dice que "cuando el destinatario de la operación sea un empresario o profesional y así lo exija, el expedidor de la factura simplificada deberá hacer constar, además, los siguientes datos": CIF y cuota IVA. Está hablando de factura simplificada en la que se indican datos que, podríamos decir, la convierten en factura "normal" ¿No? Porque si se cataloga como F1 el tipo de factura y, además, el artículo al que hace referencia dice que hay que identificar al destinatario (indicar el CIF), en la práctica, al menos, la veo como una factura "normal" sin necesidad de hacer uso de la etiqueta. Las ventas a un cliente de la Unión Europea sin identificar sería una factura simplificada sin más.

Fíjate que en la definición de tipos de facturas (lista L2) se indica para F2: "Factura Simplificada y Facturas sin identificación del destinatario art. 6.1.d) RD 1619/2012". Como si la factura sin identificación del destinatario se tratase de una factura "normal" en la que por alguna razón no se identifica al destinatario (siendo en la práctica o pudiéndose considerar, entiendo yo, como una factura simplificada). Seguro que tengo un lío monumental, pero ahora entiendo que hay que poner "S" en esta etiqueta si no se ha identificado el destinario y se trata de factura simplificada, factura "normal" sin identificación del destinatario (que hemos de tipificar como F2) o factura rectificativa de factura simplificada. No hay que etiquetarla o etiquetarla con "N" en caso contrario, o sea, si no se cumplen estas condiciones.

Perdón por haber vuelto sobre un tema en el que básicamente lo que hice fue repetir lo ya dicho; me había quedado atrás, en la página ciento-treinta-y-poco y según iba leyendo participaba... Ahora me parece que mi participación no ha aportado nada ya que considero que el asunto quedó resuelto fundamentalmente con las contribuciones de sglorka y delphiGar.
Gracias.

Pues sí, también estamos pensando aplicar algo así para ampliar un poco el rango de aceptación, pero claro eso funcionaría cuando todo vaya "normal", en el momento que haya cualquier incidencia de internet o algún registro rechazado que haya que regenerar para volver a enviar, pues ya se nos superaría esos 120 segundos y se quedarían como aceptadas con errores. Le voy a pasar la consulta al correo a ver que indican, no veo lógico que si se envía con la marca de "Incidencia" sigan aplicando ese control, porque entonces para que sirve ese check?

Otra cosa que nos estamos dando cuenta al hacer algunos envíos de pruebas, es que al parecer el servicio web no está haciendo ninguna comprobación sobre los datos de <Encadenamiento>, al fallarnos un registro de un bloque que iba todo encadenado correlativo entre sí, vimos que las posteriores que tenían esa como anterior las aceptaba como correctas sin errores a pesar de que esa no había sido subida. Y para asegurarnos hemos hecho la prueba de generar tres encadenadas entres sí, no enviar la primera a propósito, y luego enviar las dos siguientes que van encadenadas a una que no existe para ellos, y responde correcto. Incluso hemos forzado a enviar a propósito 2 encadenadas contra la misma origen, provocando claramente una ruptura del encadenamiento y lo acepta todo como "Correcto".
Esto nos indica que no están comprobando nada del encadenamiento, esto tiene algún sentido o los errores de encadenamiento se verían después en la plataforma o algo así? se sabe algo al respecto?
Es que claro así es bastante complicado testear nuestros desarrollos y saber si funcionan correctamente.

Creo que la web de pruebas se lo esta tragando todo, teoricamente si envias una factuar y la rechazan , la tienes que reenviar con el check de rechazo previo, la verdad es que ayer al darme error en algunos clientes por los datos de nif extrangero ,lo he reenviado tal cual y lo acepta correcto sin ninguna notificacion mas, simplemente cambiando el cliente??

He notado lo mismo (ya lo comento en un post previo). El sistema acepta facturas incluso si están encadenadas con números inexistentes. Por ejemplo, si le proporcionas una factura con el formato '00001/pepitodelospalotes/2024', la procesa sin alertar de ningún error. Esto refleja una falta de validación adecuada, y no me parece serio que no se revisen estos detalles básicos.


var encadenamientoFacturaAnterior = new EncadenamientoFacturaAnteriorType();
encadenamientoFacturaAnterior.IDEmisorFactura = cifEmisor;
encadenamientoFacturaAnterior.NumSerieFactura = "00001/pepitodelospalotes/2024";//numero factura nunca añadida anteriormente
encadenamientoFacturaAnterior.FechaExpedicionFactura = "02-02-2024";//fecha factura anterior
encadenamientoFacturaAnterior.Huella = "7F3D68A9B8C39A1D29C7B4F54E6FA318CBD26317F02C89DF1A6477E3952D8F3E";//huella generada por ia

Lo acepta como correcto.

Gracias por responder, acabo de ver que exponías lo mismo la semana pasada.
Le he consultado este tema de la validación de los encadenamientos al correo de consultas de la aeat y me acaban de responder esto:

Buenos días:

Aunque existan saltos en la cadena de registros de facturación, algo que desde la AEAT asumimos y prevemos que ocurra, tenemos la forma de detectar esta circunstancias excepcionales ya que quedarán marcadas convenientemente con los indicadores de la operativas comentadas y serán fáciles de trazas con nuestras herramientas de explotación. El sentido de tener encadenados cronológicamente a través hash de la forma que se solicita en el reglamento es porque en la mayoría de las casuísticas esta cadena estará bien formada y sólo existirán casos excepcionales que estarán bajo control. No debería ser una preocupación como empresa desarrolladora, la responsabilidad de detectar el mal uso o incumplimiento reiterado corresponde a la AEAT.

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria

Gracias por tu respuesta. Vamos que no validan nada de esto y si lo haces mal ya te lo indicarán.

Una duda que me surge es que si tu SIF lo usan varias empresas (es mi caso), ¿tienes que empezar el encadenamiento por cada empresa? Es decir.

Empresa 1: primer registro -> encadenamiento sobre anterior registro de esta empresa
Empresa 2: primer registro -> encadenamiento sobre anterior registro de esta empresa

Agradeceria respuesta.

Gracias.

Sí, a nosotros también se nos da ese caso y efectivamente lo hacemos así por empresa, es decir para cada cif emisor, su primer registro va como "PrimerRegistro" y los siguientes encadenamiento sobre el anterior de esa empresa/cif emisor.

Gracias por tu rápida respuesta.

Muchas gracias, ya estaba pensando que había sido publicada y era el único que no me había enterado.

Si una empresa tiene múltiples TPV's con el mismo NIF/CIF. ¿El encadenamiento puede ir referenciado a cada TPV con su nº de factura diferenciado con un prefijo que identifique el TPV?.

Por lo que yo se, el encadenamiento va por NIF/CIF y para todas las operaciones (alta, anulación y subsanación), osea que diría que la respuesta es que no puedes distinguir entre TPVs que tengan el mismo NIF.

Y distinguir por series se puede?

Por ejemplo nuestro programa tiene contadores distintos para facturas simplificadas, para facturas contado y para facturas de albaranes.
Nosotros de momento estamos encadenando las facturas de cada contador.
Si se crea la factura simplificada FS3, la encadenamos con la FS2 creada anteriormente.
Si después se crea la factura contado CO8, la encadenamos con la CO7 y no con la FS3
Ya lo hacemos de esta forma para TicketBAI y no hemos tenido ninguna queja pero en VeriFactu no se si será un problema...
De momento los envíos que hacemos no se queja pero por lo que he leído tampoco valida el encadenamiento...

Que opináis?

Muchas gracias

yo creo que el encadenamiento lo van a tratar como ticketbai (sería lo lógico).
Si está justificado que tengas que usar series separadas, ejemplo, tengo 2 tiendas físicas, y la base de datos es física, pues es imposible encadenar una con otra, así que cada tpv me lleva una serie y cada serie lleva un encadenamiento.
Ahora bien, si tienes todo montado en el mismo sitio, o base de datos online (web etc), pues no puedes hacer encadenamientos por series distintas, tendrás que meter todo en el mismo encadenamiento

Creo que tampoco.
Nosotros tenemos SERIES distintas, pero tenemos que obviarlas al generar el encadenamiento.

Muchas gracias Neftali y pablog2k por vuestras respuestas.

Leyendo la normativa creo que tenéis razón, pero voy a enviar una consulta por si a caso

Tan contento que estaba yo utilizando el mismo sistema que para TicketBAI :(

Gracias

consulta sobre encadenamiento y serie
 

rci cuando te conteste Hacienda por favor si es posible coméntala por aquí, estoy en el mismo caso y me gustaría aclarar eso. Gracias! :)