Ten un registro por ticket emitido de todas las incidencias. EstadoEnvio, EstadoRegistro, CodigoErrorRegistro, DescripcionErrorRegistro. Y haces un listado con los tickets con incidencias y un botón para rectificar o subsanar.

Mientras tiene que poder seguir emitiendo facturas o ponerlas en espera.

Lo suyo es verificar que este bien escrito y ademas si esta censado, si da como no censado, yo saco un mensaje de verifique si esta corecto, etc y marco el chec de no censado n7, con id otro, que es lo que ellos indican, he provado con un par de clientes con nif empezando por x que daba no censado y ok, sin ninguna incidencia.
A vostros que os parece?

Si, es mejor que le demos una solución por nuestros medios. Pensaré en hacerlo de esa manera.

Gracias y un saludo.

https://www1.agenciatributaria.gob.e.../ws/VNifV2SOAP

Permite comprobar NIF/CIF de contribuyente válido.

Exactamente ese es el que utilizo ademas de una opcion para verificar la estructura del mismo.

Agradecemos mucho tu ofrecimiento, pero debes tener en cuenta la protección de datos, cada consulta que hagas a la aeat se va a quedar registrado con que certificado la has hecho(supongo que haces así la consulta) No te recomiendo que des el servicio así sin más. Las que tú hagas o de tus clientes las tienes controladas.

Hombre, lo dudas?
ya verás la publicidad jejeje. Se les ve el plumero. Aqui manda don dinero.

Creo que he leído los 3247 mensajes publicados en el CLUB. Es por esto que mi lio mental es descomunal. En un post se definen unas normas a seguir, y unos cientos posteriores estas normas cambian.
He conseguido mandar y recibir contestación OK por parte de Hacienda de facturas emitidas conseguimiento huella y demás especificaciones.

Ahora bien, he estado hablando con un cliente de la situación que se encuentra su negocio actualmente.
1 - Local situado en Valencia donde se genera/fabrica el producto base a partir de la materia prima.
Se emite factura, hacemos el seguimiento de la huella anterior y la incorporemos a la generación del has/huella de la emitida. Como ya tenemos claro, la
secuencia es por orden de emisión/envió , indistintamente de la serie-factura que sea.
Hay un servidor local donde esta ubicada la base de datos con sus ficheros.
SIF instalado : 1 instalación por terminal (5 terminales). Todos trabajan con los mismos datos
Asumo que solo vamos a tener 1 solo control de seguimiento para el has/huella.

2 - Local venta situado en Sagunto, 1 solo ordenador con su correspondiente Base de Datos y su instalación SIF. El titular de la explotación es el mismo.
Pero no tenemos comunicación directa con el Local situado en Valencia. Actualmente se emiten tickets venta que no tienen nada que ver con los
emitidos en Valencia y llevan su propia numeración Serie-Factura independiente. Actualmente no pueden trabajar en linea por falta de comunicación.

3 - El titular de ambas empresas es el mismo, se ha realizado 6 instalaciones, 5 en la empresa de Valencia con una sola base de datos compartida
1 en la empresa de Sagunto con otra base de datos distinta. Cada una de ellas tiene sus datos particulares

En este caso y otros similares como tenemos que actuar para reflejar el seguimiento de la ultima factura emitida para enlazar con la actual.

Cual seria la mejor forma de actuar.

Hola, lo 5 que estan en la misma base y comparten base de datos, han de encadenar juntos por ordende emision de facturas, deverias de tener en cuenta intentar encadenar la numerocion delas facturas enorden cronologico tambien.
La 6ª es un SIF independiente al que tendra que dar cobertura de internet , para poder emitir encsdenar apropiadamente sus facturas generadas.
No puedes vender en sagunto ahora y esperar a que comuniquen la venta despues en la fabrica.

Me comentas que tendrían que encadenar al emitir los 5 de Valencia + 1 de Sagunto y enlazar todas las facturas a la vez. ?????
No podría ser como esta ahora que los 5 de Valencia enlazan entre ellos y el de Sagunto va por su parte como una empresa distinta ????
Podría dar problemas con AEAT ????

Hola, esa norma de encadenamiento es la misma desde el inicio de los post,
son 2 SIF independientes y tienes que crear 2 colas de envios independientes.
Aunque sean del mismo identificador fiscal(CIF) son interpretados para el reglamento Verifactu como distintos SIF (Sistemas Informáticos).
Debes diferenciarlos en el Nodo <NumeroInstalacion>XXXXXX</NumeroInstalacion> para que al enviar sean interpretados como distintos SIF para el mismo obligado tributario y puedan comprobar independientemente los envios y encadenamientos los servidores de Verifactu.

Si a eso me referia, a que has de abilitar que el 6º facture y encadene el solo, si no tiene acceso a internet ahora porque no llega alli la fibra o demas, pues tendran que contratar al gun servicio de internet satelite , por movil o similar.
Un mismo cif, puede tener varias delegacione facturando para el con cadenas independiente, sin pega.

Efectivamente
Si las bases de datos no estan conectadas entre ellas, ni usan la misma base de datos, ni el mismo equipo, todo apunta que envían por separado no hace falta interconexiones
consulta ya está hecha en verifactu.
Lo que si tienes que usar es distintas series para ls facturas y números de instalacion

Ya los veo patrocinando "La Cuponera"

La retención va aparte de la factura fiscal. Es lo mismo si debes sustraer al importe de la factura algo que ya ha sido pagado y que al final el precio que debe pagar el cliente no tienen nada que ver con la suma imponible+IVA.

Ya lo hacen: las empresas que están en el SII tienen un 303 pre-rellenado que está bastante bien. Y tengo la sensación que con Veri*factu podrán hacer la parte devengado acertadamente.

Otra cosa: en el SII puedes consultar las declaraciones SII de tus clientes y proveedores (por la parte que te afecta, obviamente).
Supongo que las facturas subidas por Veri*factu también podrán ser visto por los clientes de los comercios.
Lo que no tengo idea es si habrá posibilidad para todo el mundo, incluso si no estás en el SII, de consultar de la misma manera las facturas presentadas por los que son tus proveedores, sigan del SII, de Veri*factu o, sigamos locos, por los TicketBAI de las comunidades forales.

La AEAT tiene dos procedimientos distintos.
Para empresas («CIF»), coge el NIF siga el que siga y devuelve el nombre. No creo que controlan mucho el nombre que pases.
Para individuos («DNI» y «NIE»), necesitan una buena aproximación de dos de las palabras (nombres o apellidos); con esto te devuelven lo que tienen en base, nombres y apellidos.

Perdon, me ha salido repetido el mensaje

Este enlace del VIES no me está funcionando, es problema mío o es que lo han cambiado? No encuentro alternativas, sólo consultas manuales

¿podéis poner el formato de la consulta o donde se puede encontrar?

Gracias!!

cDataSend := '<?xml version="1.0" encoding="UTF-8"?>'+;
'<soapenv:Envelope xmlns:urn="urn:ec.europa.eu:taxud:vies:services:checkVat:types" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">'+;
'<soapenv:Body>'+;
'<urn:checkVat>'+;
'<urn:countryCode>PAIS</urn:countryCode>'+;
'<urn:vatNumber>VAT</urn:vatNumber>'+;
'</urn:checkVat>'+;
'</soapenv:Body>'+;
'</soapenv:Envelope>'

cUrlService := "http://ec.europa.eu/taxation_customs/vies/services/checkVatService"

Ya he restringido las peticiones a solamente los clientes registrados y a los que les voy a dar el servicio en mis aplicaciones.


Gracias ermendalenda

Interpretar respuesta AEAT Verifactu
 

Como puedo chequear la respuesta de la AEAT respecto a el envio efectuado.

Necesito saber si ha sido OK o a generado algún error y al mismo tiempo detectar el tipo de error.

Gracias

Como haces la consulta??, mejor dicho como estas enviando la informacion, porque el mismo metodo de envio que uses te devuelve un response, del que has de extraer esa informacion.

Se me ocurre otrq solución para verificar posteriormente
El 5 parámetro del qr.
Haces la consulta con los datos que tiene el qr pero con el quinto parámetro que te devuelvela respuesta en json, estaba pensado para incluirla por ejemplo en la factura electrónica y otras necesidades de comprobación del estado se envio.

Aparte de la respuesta de verifactu puedes posteriormente comprobar el estado, pero la respuesta te da unos datos que el qr no te lo da.

El quinto parámetro es importante ya que devuelve el importe enviado, cosa que el XML de respuesta no. Esto sirve para cotejar lo enviado con lo facturado, y debe coincidir.

Hola, de momeento y hasta que teoricamente a futuro, todo lo enviado , asi como la respuesta, lo podamos consultar al portal, lo logico no es guargdarse una copia del XML enviado y el de respuesta par apoder comprobar todo eso?

Quieres decir, ¿incitar a denunciar malos contribuyentes? ¿Seria legal esto en España? (denuncia es legal; la cuestión es incitar.)

Interesante idea. Daría la oportunidad para malhechores y empresas de «AI» de montar «aplicaciones para averiguar sus QR», interceptando la llamada a la web de AEAT, recuperando datos de contribuyentes (un poco como ocurrió hace años con los tiquetes de compra con informaciones de tarjetas de crédito; luego se anonimizaron los números).

Yo lo guardo absolutamente todo en cada registro de facturación. XML enviado, XML recibido, desgloso parámetros del XML recibido y los comparo con los del XML enviado, además de todos los parámetros y estados de la transacción desglosados. Toda comprobación es poca con los de la AEAT.

Mi aplicación es de escritorio con base de datos local. Pues también envío mediante API todo lo anterior a una base de datos ubicada en un servidor para tener yo toda la información por si acaso.

Soy de VB 6.0 (Carca) y utilizo xmlDoc = New MSXML2.DOMDocument60, aconsejo usar el chatgpt para muchas dudas. Si le indicas buenos prompts te resuelve en el 90% de dudas.

Hola Buenas Tardes,

He visto que en las facturas electrónicas de ejemplo que comparte la AEAT, existe un campo que dice TipoHuella, y quería saber si es algo importante o si alguien sabe algo sobre esto.

Un saludo.

Muchas gracias xevi.

Ole, no soy el único:)

yo de momento voy muy atrasado, sólo he conseguido el hash y el qr, ahora estoy haciendo mis primeros pinitos (cuando me dejan un rato) con los envíos con MSXML2.DOMDocument60 precisamente.

Acaban de publicar esto (25/20/2024 14:06):

VERI*FACTU - Actualización esquemas XSD de sistemas VERI*FACTU
----------------------------------------------------------------------------------------------------------
A peticiones de varias empresas desarrolladoras y habiéndose estudiado por parte del DIT-AEAT, se ha modificado levemente la estructura de los esquemas XSD, entendiéndose la necesidad de generar y realizar validaciones registros de facturación de forma independientemente, sin necesidad de incluirlos en un envío para ello. El esquema actual no permitía dicha posibilidad.
El cambio supone tan solo un cambio en el namespace de alguno de los nodos XML que forman parte de los esquemas (Cabecera, RegistroAlta y RegistroAnulacion). Con el cambio realizado los esquemas dan cabida a este requisito y son más fácilmente comprensibles.
También se incluye un cambio en la respuesta de las remisiones en el formato del campo TimestampPresentacion, añadiendo el huso horario de los servidores de la AEAT.
Estos cambios no afectan a la información necesaria para la remisión de registros de facturación, pero puede requerir de algún ajuste en los sistemas informáticos de facturación para poder seguir operando con el sistema VERI*FACTU.


La url es esta, que con el sistema de publicación que tienen, los ficheros estarán por ahí... :confused::confused::confused:
https://www.agenciatributaria.es/AEA...ERI_FACTU.html


Actualizo el mensaje#1

Entiendo que los namespaces de los esquemas tienen que ser dinámicos y no ponerlos de forma estática al generar el xml. Espero que no se les ocurra cambiar "Correcto" por "Escorrecto" en el nodo "EstadoRegistro" por ejemplo.

Vaya, estuve intentando usarlo y no lo consegui hacer funcionar, si alguna vez puedes poner alguna funcion de envio de ejemplo te lo agradeceria.
Actualmente envio con curl y funciona bien, pero lo mejor es integrarlo.

Hola Becario, recuerda que esto no es factura electrónica, es VERIFACTU. que es un tipo de reporte de facturas a hacienda. La factura electronica es el intercambio de facturas entre el emisor (El que vende) y receptor (ek que paga).

El TipoHuella es una variable que indica con que tipo de hash estamos calculando el string, ya que hay multiples de tipos de hash, de momento es una tonteria que lo pongan por que solo dan la opcion del tipo SHA256, pero intuyo que en unos años va a haber cambios con estos algoritmos y habrá que calcular con otro tipo de hash, ya que vendrán los ordenadores cuanticos, que previsiblemente, dejaran esos hashes en bragas. de momento no se me ocurre otro motivo de que haya que informar que tipo de huella vas a poner.

Por cierto Becario, si necesitas mas ayuda para el proyecto fin de carrera nos dices. XD.
Saludos

2. Agregar Referencia a MSXML en Visual Basic 6.0:

Ve a Project > References.
Selecciona "Microsoft XML, v6.0" (o una versión compatible si no tienes la 6.0).


El envío lo hago mediante:
Si el moderador considera que no hay que poner códigos que no sean DELPHI, me lo indica.

Si alguno puede traducir donde se produce el cambio, a nivel del xml, se lo agradeceria, ya que yo genero los xlm a pelo y me cuesta muchisimo leer el xsd

gracias gracias, lo probaré.

Esperemos que sí. El moderador ha sido flexible, los de vb también aportamos.

Si, lo que han cambiado es que, en algunos nodos pasa de "sum" a "sum1" y viceversa.
Por ejemplo:
- la cabecera antes era "<sum1:Cabecera>" uy ahora es "<sum:Cabecera>"
- "RegistroAlta" justo al reves,

y sigo mirando.

Uno más:
- "<sum:RegistroAnulacion>" pasa a "<sum1:RegistroAnulacion>"