Si claro. Eso es una verificación de la longitud que tiene que tener 64 caracteres y si mandas todo en minúsculas tb falla. Eso no es un check de crc ni nada parecido, prueba a cambiar cambiando un carácter por otro hexadecimal en mayusculas

La url de pruebas es


https:// prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP


Saludos

Planteamiento envios
 

Con lo fácil que es en ticketbai cierro factura/ticket envío, cierro envío etc

Tengo verifactu funcionando a la manera ticketbai para hacer pruebas ....

Y ahora con esto hay que tener en cuenta el TiempoEsperaEnvio, como lo vais a plantear ? proceso centralizado con cola de envíos por tiempo o por número de envíos :

CITO Descripción Servicio WEB :
Para poder realizar el siguiente envío, el sistema informático deberá esperar a que transcurran <TiempoEsperaEnvio> segundos desde el anterior envío o deberá esperar a tener acumulados un número de
registros de facturación igual al límite establecido en el diseño de registro para cada envío, la circunstancia que ocurra primero.


Aprovecho para agradecer a todos vuestras aportaciones, esperando con ansias :cool::D la cita con AEAT del día 28
Saludos

En el caso habitual de parámetros (1,0), el sistema informático enviará los registros de facturación individualmente y sin tener en cuenta tiempos de espera entre envíos.

Gracias bmfranky por tu contestación.

• Intentaré hacer los cálculos antes de la factura antes de la impresión.

• EL error de los 8 registros ya está solucionado, he actualizado el certificado en el evento ONBEFOREPOST del THTTPRIO y ya he enviado bloques de 50 facturas.

• El error del NIF, no consigo corregirlo ya que si envío una factura simplificada (Sin Bloque "Destinatarios") y me la acepta, la siguiente factura en el bloque "Encadenamiento" debería ir sin NIF, y me da error tanto si pongo el [IdEmisorFactura] en blanco como si no lo pongo, solo me acepta esta nueva factura si pongo cualquier valor en el campo [IdEmisorFactura] (Y eso no es correcto).

• El error del NIF, no consigo corregirlo ya que si envío una factura simplificada (Sin Bloque "Destinatarios") y me la acepta, la siguiente factura en el bloque "Encadenamiento" debería ir sin NIF, y me da error tanto si pongo el [IdEmisorFactura] en blanco como si no lo pongo, solo me acepta esta nueva factura si pongo cualquier valor en el campo [IdEmisorFactura] (Y eso no es correcto).

Encadenamiento|RegistroAnterior|IdEmisorFactura

NIF del obligado a expedir la factura a que se refiere el registro de facturación anterior (sea de alta o de anulación) generado en este sistema informático. Este campo forma parte del detalle de las circunstancias de generación de los registros de facturación, ya que es necesario para completar la identificación de la factura contenida en el registro de facturación anterior a encadenar en casos excepcionales y puntuales en los que no coincida con el actual, como al cambiar en un momento dado el NIF tras fusiones, absorciones, etc.

No es el NIF del destinatario de la factura anterior, es el NIF del emisor de la factura anterior.

Saludos,
David M.

Tiempo envíos
 

Gracias, Carlos

En el ultimo documento especificaban :

Viene especificado en el artículo 16.2 de la orden:
2. Los sistemas informáticos «VERI*FACTU» deberán implementar un mecanismo de control de flujo basado en el tiempo de espera entre
envíos, el cual tomará inicialmente el valor de 60 segundos, y en el número máximo de registros admitidos en cada envío.
Los mensajes de respuesta de la Agencia Estatal de Administración Tributaria informarán sobre el valor de este parámetro, el cual deberá ser
tenido en cuenta para el siguiente envío.
El número máximo de registros a remitir en cada envío queda determinado por el diseño de registro incluido en el apartado 2.2 del anexo.
El funcionamiento será el siguiente:
a) El sistema informático realiza el envío del primer conjunto de registros de facturación a la Agencia Estatal de Administración Tributaria.
b) La Agencia Estatal de Administración Tributaria devuelve, entre otros datos, un valor actualizado del parámetro de tiempo de espera «t»
entre envíos.
c) Para poder realizar el siguiente envío, el sistema informático deberá esperar a que transcurran «t» segundos desde el anterior envío o
deberá esperar a tener acumulados un número de registros de facturación igual al límite establecido en el diseño de registro para cada envío,
la circunstancia que ocurra primero.
d) El sistema informático realiza un nuevo envío cumpliendo con lo establecido en la letra c). En la respuesta puede recibir una nueva
actualización del valor del parámetro «t».
Ejemplo de respuesta con el parámetro de tiempo de espera de 60 segundos entre envíos:

<sf:TiempoEsperaEnvio>60</sf:TiempoEsperaEnvio>

Y en todas las pruebas devuelven 60.

Saludos

Hola, si de momento devuelven 60 segundos, que es el minimo, pero cuando empecemos a enviar todos en serio y reciban bloques de 1 factura de 2.000.000 de usuarios a lavez, veras como te dicen que o agrupes mas o te esperes x tiempo.
por ejemplo yo hago las facturas de 1 en una, igual la siguiente la hago mañana o en 3 dias, no me voy a esperar a tener 10 facturaspara enviarlas todas en grupo, me esperare por ejemplo imaginemos 600", que a lo sumo es lo que tardaria en hacer otra factura y enviarla.

No se, me parece que han puesto ese campo para curarse en salud. Los servidores actuales pueden tragar millones de peticiones instantáneas. Y más los de hacienda. Espero que sea así, si no será otro problema.

Hablando de agrupar o no agrupar...


Yo nunca mando sin agrupar, cada factura en un xml al estilo de Ticket Bai aunque me gustaría, porque no me convence eso de que unas veces los mandas sin agrupar otras agrupado...


Cómo hacéis vosotros?

Hombre supongo que depende de tu linea de trabajo, si tienes que embiar los tickets de 10 cajas facturando al momento, igual no hace falta, pero si son 45 como en un carrefour ,lo logico es que los agrupes y envies los que se generen en los 3 minutos que tenemos de tiempo para el envio, creo yo.

Si facturas como yo , una factura cada vez que termino una reparacion, lo que pueden ser maximo 7 al dia, pues no voy a empaquetarlas y enviar 6 con incidencia, junto con la ultima sin...

Lo dificil es combinarlo con el warning que te devuelven, que has superado el tiempo de 120 segundos, no sé qué importancia le darán a la constancia de pasarse del tiempo, pero yo voy a tenerlo lo más atado posible

Hola, una cosa, no entiendo como se os puede pasar el tiempo entre que la generas y embias.
Si es porque el servidor no la acepta, pues tendras que enviarla como incidencia, deveriaias asignar El campo " altaFactura.FechaHoraHusoGenRegistro" , lo ultimo antes de serializar y visualizar la factura, y si es por empaquetar varias, poner un temporizador que cierre el registro de envio a los x segundos.

Existen varios motivos por los que puede pasar.
Si tienes 100 comercios xon 2 o 3 tpvs en cada uno y el 50 % dependiente de un router de datos por tener dificl la instalación de cableado etc..
Esta claro que sí lo pones como incidencia, aparentemente problema resuelto, pero si tienes un comercio en una zona de difícil cobertura vas a estar mandando las incidencias continuamente, lo dejas en cola, detectas que no has podido mandarlo a tiempo y lo pones como incidencia.
Para mi marcarlo como incidencia es casi igual que no marcarlo, y creo que para ellos es igual, por que, si tienen tiempo y dependiendo del numero de incidencias o de envíos fuera de hora te pueden clavar la inspección.
Lo de marcarlo como incidencia es solo para que digas "ya lo sé" antes de que te lo digan ellos.. Absurdo.

:eek::eek::eek:

Los 300 tpvs, los encadenas desde un unico servidor??, ya os digo me alucina, mi forma de pensar es monopunto como los coches antiguos... Pensar en atender tantos puntos a la vez.. bufff

Nos. Pero la intención era enviarlo a un punto común (un servidor de una empresa externa) para que hicieran el trabajo de enviarlos como terceros.
Hasta que henos visto los tiempos. Así que al ver que tu pusiste lo de que se podía hacer el soap a pelo, me puse yo a programr el envio. bufff menos mal

Ayer estuve hablando con un desarrollador que da servicios de SII que pensaba hacer servicios de Verifactu, hasta que le dije lo de los 120segundos. Entonces me dijo que ni de coña iba a dar el servicio con esas condiciones aunque sea un warning.

Nosotros tenemos una cola donde se van añadiendo las facturas (los terminales).
Por otro lado, un servicio que cada X segundos cogerá todas las de la cola y las enviará. Según la respuesta, si hay que cambiar el tiempo, pues variará el parámetro X hasta el siguiente envío.
Si se llega a las 1000 ( el valor límite Y) facturas antes de el tiempo X se envía y de nuevo a esperar.

Muchas gracias David M. me has devuelto la alegría, empezaba a tener depresión....

Entiendo que ese tiempo es variable según la respuesta de tiempo mínimo hasta el siguiente envío.
Si en la respuesta te devuelven que el siguiente envío debe ser como muy pronto en 60 sg. No deberían pasar más de 120 sg. entre generar y enviar.

Si el timpo lo suben a 300 sg. lo lógico será que el tiempo de warning sea de 600 sg. (por poner una relación).

Es una forma de asegurarse de que el envío es "inmediato"; es decir, que no envías las facturas al final del día, por decirlo así.