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í.

En mi caso cada terminal es un SIF distinto.
Una cola en cada uno.
Ahira que te leo a ver si hago una prueba de enviar 1000 registros a ver como se comportan los servicios.

Hola a todos.

¿Alguien sabe si hay que incluir las retenciones que pueda llevar una factura ?

Pues la verdad no he visto ninguna mención sobre irpf ni ninguna otra retención en verifactu, es raro no?
Por que si se lo descuentas de la factura para que el clientebpague el irpf en tu nombre pero no lo declaras en verifactu, mmmm, cuando den el próximo paso que hagan el modelo 303 automáticamente, como lo contemplan?
Vaya lio

Hola buenas

Tengo este esquema de XML

Preguntaba por si asi estaria bien para hacer un envio a verifactuSOAP o faltaria añadir algo mas como por ejemplo esto

Y si es esto entonces como se implementaria

Muchas gracias.

Hola, eso es una factura electronica , tipo Factura-E no tiene nada que ver con verifactu...
Para verifactu ha de rellenar el Xml que rige el envio de alta a la aeat.

@Becario127 Le recomiendo que heche un vistazo a la dcumentacion que encorara en el primer hilo de este mis post y en la web del desarrollador Aqui

Van a pegarse años confundiendo factura electrónica y verifactu.
Confiemos que RTVE, a través eel ministro de transformación digital y el de Hacienda nos informe adecuadamente

Me da que van a hacer ingeniería social para que todo el mundo pase su QR por el móvil con algún tipo de subvención.

Hola a tod@s.


Independientemente de que voy avanzando (con mucho trabajo) con esto del envío me viene a la mente (de nuevo) los nifs equivocados. Según he podido comprobar si el nif no es válido la factura va directamente "patrás" y tendrá que manejarlo el usuario a posteriori.


El tema es que quiero implementar en mis programas la consulta por api de si el nif es válido o no pero te pide un certificado y la verdad es que el instalar un certificado en cada terminal de una red para poder hacer esas consultas me parece una barbaridad. ¿Cómo manejáis vosotros ese asunto?


Saludos

Yo tengo montado un ServidorWeb que se encarga de esas peticiones, tanto para NIFs como para VAT/VIES europeos.

Si lo quieres probar y te sirve... igual lo dejo activo y abierto por si puede servir a alguien.
https://xevicomas.duckdns.org:8443/C...=Pruebas&msg=N

Gracias Xevi pero ¿compruebas que sea un NIF/CIF registrado con ese nombre en la aeat?

Yo lo que hago es de "puente" entre mi servidor y lanzo la petición a SOAP de AEAT
https://www1.agenciatributaria.gob.e.../ws/VNifV2SOAP
o al de VIES
http://ec.europa.eu/taxation_customs...heckVatService
Para detectar si se trata de un VAT/VIES europeo, se necesita el código de país incluido en el campo id
así pues id=FR1234567890 o IT1234567890


Tengo instalado MI certificado personal y así me saco el tremendo marronazo de tener que decirles a mis clientes que deben de tener uno instalado en CADA máquina que van a dar de alta un cliente o a generar un Albarán para luego facturar.

Con la respuesta que devuelvo "Si" o "No" me vale para desde mi aplicación de escritorio lanzar mensaje de NIF Correcto o no...

Es que he hecho precisamente la prueba de poner un CIF válido pero con un nombre inventado y me dice que es correcto, por eso te preguntaba.

https://xevicomas.duckdns.org:8443/C...=Pruebas&msg=N

Este da resultado "No"... El id/nif se que es correcto, pero como el nombre no se corresponde, pues devuelvo "No"

Está probado con multitud de NIFs i algunos que otros VAT/VIES y funcionando correctamente.

Ahora he probado con un CIF y nombre inventado... si el CIF existe, con eso ya devuelve "Si"... igual AEAT no hace lo mismo que con un NIF y no se comprueve la relación CIF/NOMBRE

Le hecharé una ojeada!!!

Gracias compañero aunque también estoy pensando en intentar hacer una llamada al webservice cargando el certificado desde fichero y pasándole la clave para no sobrecargar tu certificado (o el que sea) con tantísima consulta. No sé si alguien por aquí tendrá mejores ideas.


Saludos.

Hoy nos llamó un cliente que quería comprar nuestro software y nos preguntó si le enviábamos un CD a domicilio.
Ese es el nivel que tienen todavía muchos empresarios. Vete a decirle a esta gente que tienen que instalar un certificado digital y enviar las facturas a la AEAT en tiempo real, imprimir tíckets con un QR, etc. :D

Ahora he estado viendo que hace AEAT al consultar un CIF... y pasa olímpicamente del nombre que le mandes.
Su respuesta es IDENTIFICADO - y el nombre registrado en AEAT

https://www1.agenciatributaria.gob.e...BUGC-JDIT/Cnec

Si pones a consultar un CIF
B123456789;nombre inventado

Verás que si le pones un CIF correcto, independientemente del nombre que le des a consultar, te devuelve el nombre que deben tener ellos registrado.

Lo mejor es SIEMPRE no depender de terceros, por lo que si te puedes montar un simple servidor que haga esta tarea que necesitas, pues será mucho mejor.

A mí me llamó uno hace unos meses para que le enviara un diskette para reinstalar el programa. Va a ser merienda de negros.

¿Cómo tenéis prevista la forma de actuar cuando haya que subsanar una factura que haya sido "aceptada con errores" o simplemente sea "incorrecta"?

Partiendo primero de que lo ideal sería que no se produjera el error, y que habría que asegurarse de que todo funcionase bien evitando posibles problemas, etc... En un TPV (por ejemplo un comercio, cafetería, etc.) que hace muuuchas ventas continuamente... ¿cómo tenéis pensado actuar en caso de que en una factura concreta haya que subsanar algo (factura parcialmente correcta, incorrecta...)?

Porque la cafetería, comercio, etc. tiene que seguir vendiendo, pero algunos "errores" requieren cambiar el cliente, NIF mal escrito, etc. y no todos los empleados de la empresa tienen permisos. Muchos TPVs solo permiten vender y punto (no hay acceso al "backoffice" general donde reabrir esa venta y tocar lo que haya que tocar).

¿Mostráis un mensaje en pantalla, indicando que "se requiere modificar tal cosa" y que el usuario se apañe para poder seguir enviando? ¿Bloqueáis los envíos hasta que se corrija ese error? ¿Marcáis esa factura como "hay que corregir X" pero el usuario puede seguir enviando facturas? Y si este fuera el caso... ¿y si se olvida de subsanar esa factura? ¿Y si son 100 las que tiene pendientes de subsanar?

No sé, a lo mejor me estoy liando y no debería preocuparme tanto, pero intento ponerme en situación y me preocupa este tema.

Al principio seguro que dejan pasar que no corresponda nif con nombre después lo rechazarán.
También puedes usar algoritmos de cálculos para ver si está bien formados el cif/nif pero no te comprobara los que están dados de bajas por la aeat, los que sean erróneos de correspondencia de nombres y los revocados. Que hace poconosmpidio un cliente con nif español letra pero com la primera letra X de esctranjero una factura con el nie revocado.