Hay que hacerlo en fifo, 2 equipos con la misma serie, inevitablemente leen el siguiente njnero de factura en orden cronológico, por tanto da igual quien lo genere que tendrá un orden cronológico, lo que sí se ve es que el envío tiene que ser común para la misma serie.
Yo por ejemplo eso no voy a tener problemas por qur para distintos tpvs tengo números de serie diferente y si hay algún dispositivo más enganchado al tpv(una.pda por ejemplo o un cajón de cobro automatico, o incluso otro tpv satelite) leen y escriben en el mismo sitio, controlando bien los índices únicos no existe problemas.

Sí, las hay.

Es un problema clásico de cola, con un recurso único. Cuando cualquier programa (de varios) está listo para encadenar (es decir, XML del registro generado hasta la parte EncadenamientoRegistroAnterior), se pone en cola para obtener esta información. Él que está en cabeza de la cola entra en sección crítica (mútex), recupera la información del último registro (ID, huella y hora de generación), recupera la hora actual, acaba de completar el XML, calcula su huella, graba el registro ya completado con su DatosControl (la firma se podrá actualizar más tarde, y evidentemente las incidencias también), este registro pasa a ser el último, y puede salir de la sección crítica, liberando para el siguiente en la cola.

El tema de los números de nueva factura pueden gestionarse de la misma manera, es decir atribulándose dentro de la sección crítica; pero no tengo claro si es un requisito imprescindible de los sistemas de facturación que los registros de factura tipo S0 sigan encadenados en orden estrictamente ascendente de número de factura en cada serie (muy posible que me he perdido algo aquí). Obviamente es muy preferible, pero creo que se puede haber circunstancias como las que describes que hacen que los números pueden resultar desordenados a veces, en caso de incidencia en la generación del registro después de haber obtenido un número de futura factura. Y desde luego, dado que el número de factura está mezclado con el número de serie en el campo IDFactura, no veo como Hacienda puede automatizar un control de este requisito.

Se te ocurre cómo incluir esos espacios de nombres con el objeto serialiazer

Dim AltaRegistro as ServicioVeriFactu.AltaFactuSistemaFacturacion
Dim serializer As New System.Xml.Serialization.XmlSerializer(GetType(ServicioVeriFactu.AltaFactuSistemaFacturacion))
Dim writer As New System.IO.StreamWriter("RegistroAltaFactura.Xml")

serializer.Serialize(writer, AltaRegistro)
writer.Close()

¿Has intentado crear dos objetos del mismo tipo ServicioVeriFactu.AltaFactuSistemaFacturacion?
Algo como... y luego pasar por dos objetos XmlSerializer, uno que escribe dentro del segundo (si se ve mucho que no tengo práctica, concretamente nula con dotNet, es que es así :o ).

La idea subyacente es que hay que separar las dos partes, de una parte la generación del registro (y su posterior almacenamiento) del envío a Hacienda con el servicio web. El segundo se debe alimentar del resultado del primero, no se debería volver a crear el XML entero porqué, como bien has dicho antes, es problemático volver a generar el mismo contenido que él con cual se calculó la huella.

Sanción por facturas no correlativas
La sanción por emitir facturas que no guardan correlación y seguimiento numérico se considera una falta leve según Hacienda y por la que tendrías que pagar llegados al caso unos 150€ por cada factura que no se haya emitido correlativamente.
Una de las reglas básicas es que deben llevar un orden numérico y cronológico sin saltos y sin vueltas atrás en el orden de tiempo.
Que sancionen o no, antes dependía del inspector, a partir de ahora no sabemos.

Se podría crear el registro inicial que se va a almacenar del tipo ServicioVeriFactu.AltaFactuSistemaFacturacion, luego no hay problema al crear el mensaje de envío con todos los registros pendientes ya que se puede extraer de cada registro individual el objeto <Registrofacturación> y añadirlos al mensaje de envío para enviar varios a la vez. Este método si funciona pero lo que me echa para atrás es que en el diseño que proponen DR_Alta CE, que se supone que es para almacenar los registros individuales, exigen que el objeto sea del tipo <FacturaExpedidaType> y no sé si eso puede crear problemas.
En resumen, entiendo que los registros de facturación generados deben almacenarse en Xml bajo la estructura <FacturaExpedidaType> y una vez que los vas a comunicar construyes el objeto ServicioVeriFactu.AltaFactuSistemaFacturacion

El tema del orden no debería de ser problema. Aprovechando que todavía no sé cómo aislar el nodo de cada factura para generar el hash lo que estoy barruntando es que al emitir la factura se genere un XML con el nodo de esa factura en alguna carpeta, que haya un programa que esté leyendo esa carpeta y que según vayan entrando vaya leyendo el XML, generando el hash y meterlo en una "pila" donde se irá generando el XML definitivo con su cabecera para enviarlo. Claro, esto obligaría a crear y enviar el XML de forma manual, cosa que no sé si mola mucho.


No sé vosotros cómo lo veis.


Saludos.

Ya. El problema es saber dónde está la norma de tiempo. Hasta ahora, era claro que la norma era la fecha (día) indicada en la factura; y es lo que sigue diciendo el artículo 6.1 b del reglamento de facturación. Todas las facturas de un mismo día deben tener un número superior a las de los días anteriores, sin salto.
Implícitamente, le estas sustituyendo como norma de tiempo la fecha-hora (con ±1 minuto de precisión) del registro S0 de la factura dentro del sistema de facturación. Esta fecha-hora solo se puede ver si se mira el registro S0; no hay que perder de vista que este registro S0 puede ser «mejorado» por un registro S1 ulterior, que será el registro al cual está ligado la factura real.

Hay otro tema relacionado con las fechas que no tengo claro: ¿es correcto emitir una factura que lleva fecha (el día impreso) distinto a la fecha del registro?
El reglamento 2007/23 dice (artículo 9) que un registro debe ser generado simultáneamente o inmediatamente anterior a la expedición; por tanto parece decir que fechas distintas no son posibles, solo se pueden expedir facturas llevando fecha de expedición de hoy.
Sin embargo, en muchos pequeños comercios veo a gente que hacen sus facturas cuando tiene tiempo de hacerlo, por ejemplo los finales de semana, y ponen como fecha a menudo la de final del mes; ¿tendrán que cambiar de costumbre?
Al mismo tiempo, veo a una empresa nacional de telecomunicación que emite sus facturas con 7 días de antelación (hoy emiten las facturas con fecha 19/1/2024); cierto que están en el S.I.I. (y no sé en qué día reporten en SII, supongo que dentro de 7 días) entonces no veré un QR, pero la práctica no para de sorprenderme.

Sí, se pueden emitir facturas que tenga fecha de emisión distinta de la fecha de registro. El caso más claro es la factura rectificativa por sustitución. Si se emite una factura con error en la fecha de expedición se puede emitir una rectificativa por sustitución con la fecha de expedición correcta, y en este caso, obviamente tendrías fechas diferentes de emisión y registro

Otro caso muy común es emitir facturas un viernes con fecha del lunes (ya que la empresa no trabaja los fines de semana) para adelantar trabajo y que el lunes salgan los repartidores temprano.

La fecha de emisión de la factura debe ser la misma fecha de la prestación de servicio o entrega de mercancía, según el caso, también se puede dar el caso de las entregas a cuenta para un servicio, que tengo entendido que hay que emitir también una factura y ya después descontarla en la factura total. Sobre los reglamentos de facturación yo ya le daba carpetazo para los temas específicos, el reglamento verifactu es claro diciendo que este reglamento está por encima de cualquier otro reglamento existente, a ver uqe nos cuenta cuando cierren el proyecto.

Creo que este problema está resuelto. Si el sistema es VeriFactu, no estamos obligados a almacenar, conservar y exportar los registros de facturación, por lo tanto, se pueden generar de inicio como si lo fuéramos a enviar de 1 en 1 <AltaFactuSistemaFacturacion>. Dependiendo luego del control de flujo, podemos enviarlos de 1 en 1 ó empaquetarlos para su envío según indique la tupla (n,t)

Buenas noches,

Estan disponibles los entornos de prueba? Estoy intentando buscar y no llego a encontrar. Veo en el XSDL (SistemaFacturacion.wsdl) sale address location="xxxxxxxxxx".

<wsdl:service name="sfService">
<!-- Entorno de PRODUCCION -->
<wsdl:port name="SistemaFacturacion" binding="sfWdsl:sfBinding">
<soap:address location="xxxxxxxxxx"/>
</wsdl:port>
<!-- Entorno de PRODUCCION para acceso con certificado de sello -->
<wsdl:port name="SistemaFacturacionSello" binding="sfWdsl:sfBinding">
<soap:address location="xxxxxxxxxx"/>
</wsdl:port>
<!-- Entorno de PRUEBAS -->
<wsdl:port name="SistemaFacturacionPruebas" binding="sfWdsl:sfBinding">
<soap:address location="xxxxxxxxxx"/>
</wsdl:port>
<!-- Entorno de PRUEBAS para acceso con certificado de sello -->
<wsdl:port name="SistemaFacturacionPruebasSello" binding="sfWdsl:sfBinding">
<soap:address location="xxxxxxxxxx"/>
</wsdl:port>
</wsdl:service>

¿Eso quiere decir que aun no estan disponibles?

Muchas gracias.

Según Newton. Hacienda respondió

Eso creo que impide que existan terminales que envíen de forma independiente. Mi idea: Pienso que los terminales generarán prefecturas (por poner un nombre) y se irán encolando en un sistema que procederá a la “facturación” con todo lo que impliqque (generación del xml, encadenado, huella, envio, QR…). Si el sistema es ágil el cliente saldrá por la puerta con su factura verificable… si se produce una sobrecarga o una avería o desconexión de la central, se le podrá poner un QR para que en breve pueda descargarse en el móvil su factura verifactu, o reclamarla posteriormente. Tengo cadenas de supermercados y te aseguro que me cuelgan si se crean colas en las cajas por culpa de tener que esperar por esta normativa… varias están en SII, pero me han pedido cumplir con el verifactu también, y otras varias están fuera del SII…. Es lógico que la entrega de mercancía o prestación de servicio pueda ser en fecha y hora diferente a la de su fiscalización. Y la fiscalización será secuencial, ordenada, inmediata, fehaciente y bla, bla, bla….

Bueno, según lo que cada uno interprete por cada sistema informático.
Si tienes 4 tpvs en un supermercado y cada uno tiene sus series independiente, posiblemente te acepten cada tpv como un sistema independiente, quizás tengas que reformular la pregunta para que sean más claros.

No sé... creo que la frase "Para un determinado obligado tributario, el sistema informático producirá una única cadena de registros de facturación" no deja lugar a dudas, el obligado tributario no es cada TPV o PDA de un negocio, seguramente se refiere a un CIF/NIF. Creo que si te dan la posibilidad de empezar tantas cadenas de facturación desde cero como uno quiera no tendría mucho sentido encadenar la factura, incluso se podría llegar a la paradoja de tener tantas series de facturación como facturas, y ya no sería necesario encadenar.

Otra discusión que tenemos es si el envío debe ser inmediato a la emisión de la factura o puedo hacerlo en momentos más propicios... Según el desarrollo técnico del sistema Verifactu dice que tras cada comunicación recibiremos instrucciones de cuando o cuantos registros tendremos que comunicar la siguiente vez, pero no sé si nosotros podemos decidir también la cantidad de registros y establecer ciclos periódicos de comunicación. Varios de mi equipo piensan que debemos ir almacenando los XML y proceder al envío en los tiempos de poca actividad... incluso en la madrugada del día siguiente. Creo haber leído que para que sea Verifactu no se debe demorar más de 60 minutos, pero no sé donde lo vi ni la veracidad que pueda tener.

Te copia la consulta que le hice al correo de Verifactu y su respuesta

"Buenos días.
Adjunto hilo de conversación relativo a la última comunicación mantenida para aclarar un concepto importante.
El SFC (sistema de facturación central) genera su propia línea de registros de facturación, generando un encadenamiento exclusivamente, de los registros de facturación que se generan en este sistema informático.
El Tpv, deslocalizado geográficamente, es independiente del sistema de facturación central y genera su propia línea de registros de facturación, generando un encadenamiento exclusivo de los registros de facturación que éste genera.
Tenemos por tanto, dos líneas de registros de facturación independientes pertenecientes al mismo obligado tributario que van a ser enviadas al Aeat. Se entiende por tanto, que no habrá problemas con la trazabilidad de los registros ya que cada línea de facturación se identifica con el Código de identificación del sistema informático que la ha generado.
Hago este planteamiento porque puede ocurrir que el tpv envíe un registro de alta de facturación creado por él a la Aeat y seguidamente, el sistema de facturación central envíe otro registro de facturación distinto creado por él. Obviamente, no existe encadenamiento entre estos dos registros, aunque sí existirá encadenamiento entre cada registro enviado y su anterior cuando ambos registros fueron generados por el mismo SIF.
Espero haber sido claro en mi exposión"

Su Respuesta

"Si lo que se está consultando es que dos SIF distintos (de un mismo contribuyente) pueden generar sendas cadenas de facturación distintas (cada uno la suya) con los registros de facturación correspondientes a las facturas (distintas) por ellos expedidas y que, por tanto, los registros de facturación de las facturas de un mismo contribuyente pueden estar repartidos entre ellos, solo estando encadenados entre sí los que pertenezcan a un mismo SIF y no los de un SIF con respecto al otro SIF: sí es correcto el planteamiento.

Esto es lógico porque el encadenamiento se realiza a nivel de SIF, no a nivel de contribuyente (solo estarían encadenados todos los registros de facturación de un contribuyente cuando tuviera un solo SIF que los generara).
Lo que no sería coherente es que dos SIF distintos enviaran el mismo registro a la AEAT (en el ejemplo propuesto, que el SFC y el TPV envíen información del mismo registro de facturación)."

Aún no están disponibles, se publicarán en la sede electrónica del aeat. Lo pone en la orden ministerial en la Disposición Adicional primera

Muchas gracias!

Claro, es lo lógico,.a nivel de tpv.
No puedes poner colas de espera para recuperar contador y huella anterior a un contribuyente por ejemplo con 100 centros y un total de 300tpvs que tienen un software de escritorio, imagina que se bloquea el registro de nuneracion por que un tpv ha dado problemas, o que no haya conexión a internet o a la vpn de la empresa por un bloqueo del router... mil cosas. Cada tpv su cadena , al menos en los programas de escritorio igual que ticketbai.

Esta leyendo como si fuese escrito "Para un determinado obligado tributario, el único sistema informático..." Pero esto no está escrito en ningún lugar. Y la respuesta a sglorka contempla claramente la posibilidad de tener más de un SIF para una determinada empresa (NIF).
Aquí vendrá el inspector diciéndote que hay abuso, y será multa por mala fe. Hay lógica de tener varios SIF por tener varios TPV, ya que son varios ordenadores. No veo tanta lógica en poner varios SIF para un mismo NIF corriendo en un mismo servidor, aunque sería para dos departamentos distintos con dos jefes muy celosos.

El sistema (n,t) te ponen límite por debajo en número de registros (n) y en el tiempo de demora (t). Entiendo que no hay límite por encima para el tiempo de demora (para n hay un límite de 10.000 registros). El único lugar dónde veo una restricción está en el artículo 16.1 del RDL (la énfasis es mía):
Es cierto que si el sistema de AEAT ha caído o la conexión a internet de la zona está fuera de servicio por motivos externos, no veo muy bien por qué te multen por no cumplir esta instantaneidad, aunque siga definida como "en menos de 60 minutos".
Pero para ponerlo de otra forma, no sé si es posible tener un sistema dónde la presentación al sistema Veri*factura siga suspendida al uso de certificados de usuario, dado que son certificados cuyo acceso no es (o no debería ser) posible si aquel usuario no esté presente: se podrían dar casos dónde no hay ningún usuario habilitado disponible y por tanto no sería posible remitir la información al sitio Veri*Factu, por ejemplo hasta la mañana siguiente. Evidentemente si hay posibilidad o amenaza de sanción en tal caso, habrán empresas dónde la obligación de presencia del usuario se diluirá (tipo instalación de certificados en varios cuentas de usuarios, o comunicación de contraseñas) y al final será una menor seguridad del sistema...

Creo que estás equivocado en el proceso. Me baso en lo que sabemos de ticketBAI y lo que sabemos hasta ahora.
(1) Tu sistema debe generar una factura REAL que el cliente debe llevarse cuando salga de la tienda, supermercado, peluquería,...
Los 2 procesos que hay que separar son:
* La generación de la factura, con encadenamiento y QR (en el ticket). TODO esto debe y puede hacerse sin conexión a Internet.
* El envío, que puede hacerse en ese momento o más tarde, dependiendo del sistema, de las comunicaciones, de internet o de lo que sea. Para eso sí puedes montar una cola.
NOTA: En el caso de ticketBAI la AEAT especifica expresamente que el sistema DEBE poder facturar sin conexión.

(2) El cliente DEBE irse con un ticket REAL y ese es el ticket definitivo (nada de una prefactura, borrador,...).

(3) Si es como TicketBAI como parece, el ticket del cliente DEBE llevar el QR. Con ese QR el cliente puede comprobar su factura y además asegura que esa factura ya no se modifica, ya que lleva las medidas de seguridad correspondiente (encadenamiento de la factura anterior).
Si la factura no se ha podido subir en ese momento (porque la tienda se ha quedado sin internet, por ejemplo) el ticket lleva el QR igualmente con la información de la factura (que ya debe estar generada en tu sistema -y no modificable-). Entiendo que si tú esa factura la subes al día siguiente (porque se te roto el router) el cliente podrá consultarla


Yo lo veo por ahí también.
Pienso también en empresas con delegaciones, donde lo habitual son series distintas, aunque la facturación se hace por 1 sólo ente.
Sería limitar cómo debes tú facturar (más restrictivo que la ley de facturación).

(1) El "Corte Inglés" tiene un único CIF, pero no creo que puedas obligar a todos los establecimientos/TPV/Delegaciones a enviar con la misma serie.
(2) Basándome también en TicketBAI, hay unas normas para crear una nueva serie. Esto que describes no se puede hacer. Y en todo caso la creación hay que justificarla (por ejemplo al empezar un nuevo ejercicio).

muy de acuerdo con Nefta en todo lo comentado, sería lo más lógico que se hiciera todo intentando parecerse a lo que ya está hecho con ticketbai

hola
 

No es práctico que vayan encadenados por cif, tu mismo tienes la preocupación de las colas.
Lo de que mandes antes de 1 hora no lo has interpretado bien. Dice que si tienes problemas con la comunicacion tiene que haber un intento cada hora mínimo, ya mandas cuando se pueda.
Ninguna empresa va a tener un servicio de atención tan inmediato ante una incidencia, las 24h del dia los 365 dias del año.
Cada sistema SIF será un identificador, y en cada identificador tendras una serie para los tiquets y/o facturas, para rectificaivas. Ejemplo que yo uso
Comercio numero 44
Serie tiquets (1)


tpv 1
Serie: 44.1.1
Nº Factura : xxx

tpv 2
Serie: 44.2.1
Nº Factura : xxx

tpv 3
Serie: 44.3.1
Nº Factura : xxx

Cada tpv con su numerador y su blockchain de la huella.

No te compliques de verdad.

También de acuerdo. Por algo han dado como identificado "tike" a la aplicación Veri*factu (//prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tikeV1.0/cont/ws/SistemaFacturacion.wsdl)

Hola.

Lo Primero, agradecer a todos lo que estáis involucrados en este Foro, porque está ayudando y aclarando conceptos a nuevos como yo.
Lo Dicho Muchas Gracias.

En contestación a la duda del compañero ramherfer en el post #1104.
Me pasó lo mismo, el problema lo tienes porque estás utilizando un fichero descargado en tu PC. En vez de hacer eso, pones el link al fichero en internet y te generará la unit, con todas las clases como las que puso Neftali.

Sigo en el hilo.

Salu2.

Ermendalenda, Antoine0 y Neftali... gracias por vuestra intervención, viniendo de vosotros cambiaré el planteamiento (tengo gran estima vuestra experiencia).

Tengo tres tipos de terminales de SIF: TPV de tiendas y supermercados con series independientes, ERP de escritorio tirando de una misma serie, o varias según el tipo de cliente o el tipo de venta, y Android libres, también tirando de una serie cada terminal. No quiero poner la cantidad de terminales que mantenemos, pero en un pequeño porcentaje (muy pequeño), se produce una pérdida de datos (en lo que llevamos de mes ha pasado 2 veces), desde criptolockers, pérdida o rotura del dispositivo (hablo de los androids), averías del disco duro por humedad, frío o calor en los TPV, etc... y casi siempre pasa en los dispositivos autónomos sin conexión a internet o que envían la información bajo petición del usuario, y la solución ha sido volver a meter los datos a mano... y no siempre se ha conseguido meter la realidad de lo que ha pasado... Aparte de los "truquitos" que me hacen algunos, como tener varios TPV y uno dejarlo en una especie de "Sandbox", que al terminar el día lo reinician a como estaba al inicio sin llegar a transmitir los datos de venta a la central.

No sé cómo evitar un uso fraudulento del sistema o accidentes que puedan achacarlo a negligencia de la empresa desarrolladora, por eso era lo de controlar en nuestros servidores los procesos de facturación (una especie de facturación en la nube para programas de escritorio o distribuidos). Si empieza a suceder fallos de encadenamiento por pérdidas de datos, un cambio de serie erróneo, un TPV mal configurado (que nos ha pasado también) temo que nos colapse el departamento de atención técnica con acciones de gran consumo de tiempo.

Imagino que cada uno iremos reflejando cómo atacamos esos problemas y habrá ideas geniales que podamos replicar, sobre todo por parte de los que habéis sufrido la puesta en marcha del Ticketbai.

Buff, pues quien mejor conoce la problemática y los puntos críticos de tu software para cerrar al.máximo las puertas.
Si te sirve de algo, lo que yo hago es voy poniendo en cola los xmls y los voy enviando a un servidor en la nube que es el que se va a encargar de enviarlos a hacienda, siempre respetando los parámetros que diga hacienda por dispositivo...
En la nube debes poner un primer control de encadenamiento y una alerta al cliente que tiene el tpv si se produce rotura de encadenamiento.
Los problemas técnicos por averias seguro estaran recogidos en las doctrinas/reglamento(cuando estén disponibles) y te dirán como actuar si algún registro se corrompe o se rompe el.disco.
Por supuesto tienes que i for ar claramente a tus clientes donde se meten si no cumplen con la parte que les toca.
Te recomiendo que le de mil vueltas a crear todo tipo de alertas informativas, por correo para ti y por pantalla/correo al cliente, de todas las incidencias, el control de errores es lo más trabajoso de esta normativa.

Buenos días.

Perdonarme, soy bastante nuevo en esto de programación utilizando xsd,wsdl...
Estoy un poco o un mucho perdido.
He llegado hasta aquí, para generar el xml de una factura, pero no sé de dónde sale o cómo hacer la función NewFacturaAlta

Código Delphi [-]
procedure TForm3.Button2Click(Sender: TObject);
var
  fAlta:IXMLSistemaFacturacionAltaFact;
begin

  fAlta := NewFacturaAlta;
  fAlta.Cabecera.IDVersion := '1.0';
  fAlta.Cabecera.ObligadoEmision.NombreRazon := 'EMPRESA PRUEBAS';
  fAlta.Cabecera.ObligadoEmision.NIF := '11111111H';
  fAlta.Cabecera.TipoRegistroAEAT := 'S0';

  ...

  var sXML:string;
  fAlta.OwnerDocument.SaveToXML(sXML);
  Memo1.Lines.Text := sXML;

end;

Muchas Gracias.

Aquí hemos puesto algo de código.
Una vez importado el WSDL. A ver si te sirve...

Hola Neftali, buenos días.
Muchas gracias por tu rápida respuesta.

Ya he visto este código y en mi poco conocimiento en el tema, creo que es para enviar la factura a hacienda, he conseguido generarlo, gracias a vosotros, claro.

Entiendo que este código que pusistes es para generar el xml de la factura y es lo que intentaba hacer, pero no sé exactamente de dónde sale NewFacturaAlta, es por eso el post.

Salu2.

Si no me confundo, el trozo de código que estás poniendo no se corresponde a como trabajar con el wsdl, sino a como trabajar si lo que hiciste fue importar el wsd.

Si estoy en lo cierto, el "problema" que yo tuve en su momento, no es el de dónde sale el NewFacturaAlta, sino que luego no super como crear/añadir el nodo correspondiente a los datos de la factura propiamente dichos, ya que no encontré como hacer el "NewRegistroFactura" por así decirlo para poder añadirle el resto de datos que no son de la cabecera.

Ok.

Entonces, ¿cómo estáis generando el XML de la Factura?
Con código independiente al wsdl ?

con el XML Data Binding , he pasado un xsd y me ha generado diferentes nodos

Yo entiendo que con esta clase, se podría generar el XML de la factura.
Vamos a estudiar a ver hasta dónde llego.

Saludos.

Hola, buenas tardes.

Me estoy liando y tengo la cabeza a punto de reventar :confused:

¿Qué diferencia hay entre el XML de la factura (la que se guarda y calcula el HASH) y el XML de alta (el que se envía a la AEAT ?

Siento ser tan Pesado :(

Muchas Gracias.

Hasta donde yo voy entendiendo, el xml de la factura lo vas generando cada vez que facturas, calculando su hash, etc.
Luego, cuando cada x tiempo vas haciendo los envíos, lo que hace es cargar y ficheros xml de facturas y los envías de una sola vez a hacienda. El x y el y puede variar según las necesidades que te marque hacienda en cada momento.

Aprovechando. ¿Conseguiste avanzar algo con lo que comentabas en tu post anterior de generar el xml partiendo de los xsd?.

Un saludo y espero que los que ya lo tienen más avanzando nos confirmen o corrijan.

Buenas dias.

Todavía no puedo poner enlaces, tengo el usuario limitado.

nincillo
Hasta donde yo voy entendiendo, el xml de la factura lo vas generando cada vez que facturas, calculando su hash, etc.
Luego, cuando cada x tiempo vas haciendo los envíos, lo que hace es cargar y ficheros xml de facturas y los envías de una sola vez a hacienda. El x y el y puede variar según las necesidades que te marque hacienda en cada momento.


Esto más o menos lo tengo claro.
Es la estructura de cada archivo xml. El compañero Maska10, te contestó sobre la posible diferencia en el postpost #961, página 49, que elarchivo de la factura iba sin el nodo cabecera y el archivo que se manda si la lleva, pero no he visto ningún ejemplo.

nincillo
¿Conseguiste avanzar algo con lo que comentabas en tu post anterior de generar el xml partiendo de los xsd?.


Tengo problemas y no avanzo.

Saludos.

Saludos.

Yo también le estoy dando vueltas a esto, me parece muy importante hacer ese Webservice de verificación porque, como sea como TicketBai, cada vez que subes una factura y es rechazada por algún tema de NIF...puede provocar errores de encadenamiento

Con el tema del Werbservice de Hacienda para validarlos, alguien sabe como se debería lanzarlo con curl?

Gracias

Ahora voy con una duda mía sobre los xml y el tema de la la firma


Creo que hay dos "estilos" de hacer el xml


Este
</div>

y este


</div>

Entendiendo que la verificación de la huella que va a hacer Hacienda da igual que monte el fichero de una forma u otra porque al final siempre se va calcular sobre el contenido de los dos etiquetas "RegistroFacturacion"



Voy bien

No sólo el Nif o el nombre del cliente pueden causarte este problema. También puedes tener problemas que causen el rechazo por otros motivos, tipos impositivos inexistentes (5,5% p.e.), clave del tipo de factura erróneo (F16), tipo de registro de alta erróneo (T8). Y todo esto ocurre cuando ya has generado 10 registros de facturación perfectamente encadenamos y cuando los vas a enviar (por que el control de flujo te ha marcado que hasta que no tengas 10 registros no los envíes ) resulta que se produce el rechazo de los registros 1,3 y 7 y los demás te han entrado correctamente, o no te han entrado aunque fueran correctos pero la aeat te rechaza todo el paquete. ¿ Qué hacemos ?
Yo trasladé una consulta parecida al correo de Verifactu y su respuesta fue :

Buenos días:

Tras consultarlo con los responsables, para esta casuística no podemos ofrecerle más información por el momento.
Actualmente, se está estudiando internamente cómo realizar el encadenamiento de facturas cuando existe algún rechazo por parte de la AEAT. En la futura Orden Ministerial se darán más detalles al respecto, y se incluirá en las FAQ de la sede electrónica de la AEAT.

Atentamente,
AEAT.

Hola edari

Estos códigos que has puesto, son los del envío a la AEAT, o es el formato con el que se registra cada factura?.

Muchas Gracias.