Una firma solo garantiza que el firmante (él que tiene la clave privada del certificado de firma) tenía a mano los datos firmados.
Si después de la (primera) firma, los datos se modifican fuera del poder del firmante, entonces la firma resultará inválida; pero técnicamente los datos modificados se pueden supuestamente firmar de nuevo (nota: es delito hacerlo; también es delito proponer de hacerlo) si lo hace el firmante...

El día o la hora no vienen en la firma; solo se puede añadir una marca (o sello) de tiempo a lo que se está firmando.

Si usas Veri*factu, la firma la realiza efectivamente Hacienda y sus sistema dan la hora y por tanto Hacienda tiene la garantía que los datos no se modifican en el momento de la generación.
Si es otra clase de SIF, el programador puede añadir una marca de tiempo a la hora de firmar; así sí se garantiza que no se modifican después (a no ser que se manipulen las marcas de tiempo; otro probable delito). Pero la marca de tiempo no es una obligación en lo que sabemos ahora de las especificaciones, entre otras cosas porque no hay un sistema de marca de tiempo disponible que resulte de agradecimiento tanto de Hacienda como de todos los grandes productores de software.

¿Uh? ¿Dónde está escrito que un proveedor de sistema de facturación debe proponer ejercitar, o no, la opción propuesta en el artículo 15, acudir al Veri*factu?

Cierto que el cliente puede elegir. Pero una posibilidad de elección es decidir entre dos proveedores.

No entiendo lo que dices

Técnicamente, el Reglamento está redactado al revés: dice que los sistemas de Hacienda cumplen al menos las mismas normas (artículos 16.1 y 16.4). Dicho de otra forma, que no se puede pedir a los productores más de lo que ofrece Hacienda (y ya es algo). Entonces no exactamente parecido; de hecho no hay comparación entre los métodos técnicos.

Luego, los artículos 8.2 a y b obligan a usar un «proceso técnico fiable» y a que «Todos los datos registrados deberán encontrarse correctamente fechados, indicando el momento en que se efectúa el registro.» Si por «registros originales» tu entiendes «registros con los datos originalmente grabados», entonces sí, están pidiendo esto (con la excepción de la palabra «parecido»); tanto a Hacienda para la aplicación quien soporta Veri*factu como a cualquier otro proveedor de SIF que usan el método del registro local encadenado y firmado.

A ver si me explico mejor... (la énfasis es mía)
A lo cual he contestado:
Quiero decir que, al mi entender, un proveedor de SIF puede proponer, y certificar, un sistema que SOLO propone la opción de usar el sistema Veri*factu, sin la posibilidad de desactivar la remisión automática del artículo 15. Sin implementar ni firma, ni archivo de los registro (pero sí de los eventos del 8.3)

La opción la tiene el cliente; pero no dentro del ámbito del programa, sino dentro del ámbito de sus obligaciones de tributación, que es más amplia.
Por ejemplo, en el artículo 15 está escrito «podrán remitir [...] todos los registros de facturación generados por los sistemas informáticos» (mi énfasis); no «generados por [strike]el sistema informático[/strike]».

Ok aclarado. En mi mente estaba que los desarrolladores de SIF deberían tener ambas opciones para ampliar el público objetivo. Pero estoy de acuerdo en que si tu solución desarrolla sólo una de ellas entonces el cliente no puede elegir.

Entonces como proveedores podemos hacer un sistema verifactu, no verifactu o con las dos opciones. Creo que se puede explicar al cliente q un sistema no verifactu complica el tema y puede finalizar con requerimientos. Podían haber definido solo verifactu como sistema único y no enredar mas

Cumplir Articulo 8.3 SIF Veri*Factu
 

Yo creo que un SIF Veri*Factu tampoco tiene que cumplir con el Articulo 8.3 ya que al principio del BOE dice textual: "Con ser importantes, los anteriores propósitos encuentran su sentido en un objetivo aún más amplio que desde las organizaciones internacionales (OCDE y Unión Europea) han dado en llamar «cumplimiento tributario por diseño»." y luego refiriéndose al cumplimiento por diseño dice:
"Asimismo, el texto reglamentario prevé la posibilidad de que, voluntariamente, los
obligados tributarios remitan inmediatamente a la Administración tributaria, de forma
automática y segura por medios electrónicos, todos los registros de facturación
generados en sus sistemas informáticos, en cuyo caso se entenderá que esos sistemas
informáticos ya cumplen por diseño los requisitos técnicos anteriormente mencionados."
y luego en el CAPITULO III cuando habla de Sistemas de emisión de facturas verificables dice:
"A los efectos de este Reglamento, se presumirá que los «Sistemas de emisión de facturas verificables» cumplen por diseño los requisitos establecidos en el artículo 8 de este Reglamento, y por lo tanto tampoco les será de aplicación lo dispuesto en el apartado 2 del artículo 14 de este Reglamento."

Cuidado no te fíes. A mí también me pareció entender eso pero fíjate en el punto 1 del Artículo 16
[/i]Aquellos sistemas informáticos indicados en la letra a) del artículo 7 de este
Reglamento que, cumpliendo con todas las obligaciones que impone este Reglamento y
de acuerdo a las especificaciones técnicas que se establezcan[i]

O sea, por un lado dicen que si es VeriFactu no tienes que cumplir pero por otro dice que para ser VeriFactu debes cumplir con todo.

Creo que hacer un sistema sin Veri*factu solo tiene sentido si tienes un encargo de hacerlo. Si no conoces los clientes de antemano, me parece imprescindible.:o

En lugar de «finalizar con requerimientos», que me parece demasiado negativo, yo pondría que la empresa que no quiere Veri*factu se está colgando a si misma una diana enorme a la atención de los inspectores de Hacienda.:rolleyes:
Claramente está hecho para ser disuasivo, un poco como el sistema del «criterio de caja» para el IVA: algunas empresas lo necesitan de verdad y no pueden vivir sin él, pero la intención de Hacienda es que se quede marginal.

No. Hay muchas empresas que no entran en el ámbito del SII pero son «grandes», es decir suficientemente grandes como para tener informáticos capazos de gestionar un sistema en interno que sabe gestionar esto (o contratar a un desarrollador experimentado que sabrá hacerlo ;)). Y pueden tener serías razones para no enviar en tiempo real o casi real cada una de sus facturas por Internet al sistema Veri*factu; como por ejemplo si están fuera de cobertura más tiempo que pueden asumir sus clientes, o que no quieren arriesgar que las facturas viajan por HTTPS, o que el número de tiques están en los millones...

Todo lo que dice antes de DISPONGO no tiene efecto directo para nosotros meros mortales (está para los juristas y los jueces, y también es lectura interesantes para entender).:cool:

Luego sobre lo dicho en el artículo 16.2, no sé exactamente cómo leer «se presumirá que [...] cumplen por diseño los requisitos establecidos en el artículo 8».
Si te eximen del sistema de comunicación de los registros (14.2) sin quitarte la consultación en interactivo de los registros y de los eventos (14.1), significa que debes tener en tu programa tales archivos, de registros y de eventos, ¿no? Y el 8.3 solo dice que debe estar un registro de eventos... (y que su contenido y diseño estarán en el futuro O.M.)
Ahora bien, si resulta que el registro de eventos solo registra las operaciones de grabar, firmar, iniciar serie y poco más, es cierto que son las operaciones que se pueden deducir de los registros de Veri*fatu y por tanto efectivamente ya no es realmente necesario un registro de eventos en el programa en casa del cliente (con la condición para cumplir el 14.1 de implementar una interfaz viva de consulta del Veri*factu).

Como ya se ha dicho varias veces, en realidad debemos esperar a leer la O.M. para entender realmente como comérselo.

En un sistema que va con Veri*factu, en realidad el SIF está compuesto por la reunión de tu programa y del programa Veri*factu de Hacienda con su propia base de datos, su sistema de firma y sello de tiempo con los CSV etc. Lo que dice el 16.2 es que la parte requerida por el artículo 8 está en efecto cumplida por el programa Veri*factu.

¿A qué te refieres de si os está funcionando?

Yo estoy intentando utilizarlos desde Delphi 2007 y me salta un mensaje de errro de Empty Documento cuando hago la llamada para dar de alta una factura.

Gracias.

Como ya han pasado más de 25 minutos ya no puedo editar el mensaje original, así que sigo en este otro post.

Estoy intentando importar los wsdl desde dos versiones diferentes de Delphi:
+ Delphi 2007, al intentar importarlos me dice: Error [Empty document].
+ Delphi 11, importar me los permite importar, pero luego, al compilar me da error en dos líneas en las que me dice que los literales de tipo string no pueden medir más de 255 caracteres y de ahí no paso.


¿Alguien los ha importado recientemente?. ¿Ha podido sin problema?

Gracias y un saludo.

Edito: He retocado las líneas que se suponen que miden demasiado (no se que implicaciones traerá luego), pero el caso es que al darle a enviar una petición, me dice "URL Pendiente de definir", con lo cual de momento tampoco podemos probar nada por este "lado".

En unes pruebas que hice hace un tiempo, recuerdo que me daba ese error de compilación.

Lo que hice en ese momento para continuar con las pruebas fue descomponer la línea en varias cadenas y funcionó. Pude compilar y continuar con mis pruebas.

Código Delphi [-]
'cadena de mas de …….  255 caracteres';

se convirtió en

Código Delphi [-]
'cadena de mas de …'+'….  255 caracteres';

Si nadie ofrece una solución más elegante, a mí me funcionó.

Saludos

Lo probaré... Gracias.
Pero de momento, pocas pruebas de envío se pueden hacer porque no tienen definida la url. ¿Verdad?.

Me funcionó el "truco" que me sugeriste. Muchas gracias de nuevo.
Ahora he atascado en otro punto.
A ver si alguien me puede ayudar.
Estoy empezando a rellenar los diferentes apartados de la factura antes de enviarla y he atascado al llegar al punto "Desglose", que se supone que es un Array of Detail.

Este es el código que llevo desarrollado hasta ahora.

y si pruebas con

antes de hacer

Me respondo a mi mismo por si le puede servir a alguién:



Por favor, ¿alguien que tenga Delphi 2007 podría intentar cargar a día de hoy los WSDL haber si puede o si le da error de "Document Empty"?.

Yo recuerdo haberlos importado hace unos meses sin problema, pero algo han modificado desde entonces que ahora no soy capaz.

Gracias.

No había visto este mensaje antes de enviar el como lo solucioné.

De todas formas voy a probarlo.

Muchas gracias.

Ahora he conseguido ver algo más tras descargarme el wsdl previamente a un fichero local.

Ahora no me da error, pero no me lo importa "completo". Al ver el código fuente generado, veo lo siguiente a ver si puede servir de ayuda:

Hola, parece que el problema es debido a que las urls utilizadas son https y el Delphi 2007 no debe de aceptarlas.
Al final lo que he tenido que hacermes es una copia local tanto del wsdl como de los wsd y "retocarlas" para que trabajen localmente. Así parece que por fin he conseguido que me las reconozca también en el Delphi 2007.

Articulo 16, punto 3: Los «Sistemas de emisión de facturas verificables» no tendrán la obligación de realizar la firma electrónica de los registros de facturación a la que se refiere el artículo 12 de este Reglamento, siendo suficiente con que calculen la huella o «hash» de dichos registros.

Ahora digo yo ... que yo sepa (o al menos con Ticket Bai lo hacíamos así), la huella o hash la hacemos con el resultado de la firma electrónica de la factura anterior, ¿que huella quieren que hagamos sin firmar?

Cómo se calculan las huellas y esta clase de detalles no están en el RDL que se ha publicado la semana pasada; se publicarán en un Orden Ministerial que está por venir (en breve según se dice).
Mientras tanto, ¡pasad unas buenas fiestas! ;)

Estos de hacienda han pensado en que no nos aburramos en Navidad. Ya lo han publicado.

https://www.agenciatributaria.es/AEA...ERI_FACTU.html

Acabo de verlo también
Habéis visto si ya han puesto servicios de envío para pruebas y/o QR?

Cambios
 

Veo cambios en los nombres de varios nodos
Y han agregado algunos nodos..
No parece que haya cambios que compliquen mucho a los que lo tengan ya diseñado. Por ejemplo a mi

Respetan el calculo del hash como sha256(menos mal).

Acabo de hacer la importación de los nuevos wsdl y al compilar, la primera (entre otras) en la frente.

¿Se han cargado del todo los periodos de liquidación?. Supongo que será una errata...

Al final con el registro de transacciones sigue vigente? Se relajó la norma?

Me temo que no.

Si, efectivamente lo había visto. Supongo que lo pueden extraer de las fechas que mandamos.

Por cierto.puedes indicarme coml te has descargado wl nuevo wsdl, por favor?

Del link que puso un poco más arriba @keys.

El primero de los link que aparecen en esa pagins, es un pdf que tiene los wsdl, wsd, etc.

Registro de eventos
 

Veo que nadie hacer referencia a los registros de eventos que vienen definidos en la hoja de Excel https://www.agenciatributaria.es/sta...23-12-20).xlsx

¿ Qué os parece ?

Incluir en el Indice de la página (por favor)
 

Si y el enlace no esta puesto en el indice del hilo en la primera página, y seguia consultando el antiguo y me preguntaba que narices había cambiado. Es más haciendo pruebas con los antiguos dándome de narices contra un muro ;).

Creo que hay diferencias entres los wsdl y el xml de ejemplo
 

La comparación la estoy haciendo entre los nuevos wsdl recién importaros y los xml de ejemplo que vienen indicados en el siguiente documento: https://www.agenciatributaria.es/sta...ioWeb_v1.0.pdf

En los wsdl importados no encuentro el apartado correspondiente a:
Ni el apartado correspondiente a:
Me parece que hay bastantes más "diferencias" entre ambos, pero éstas son las primeras con las que me he encontrado junto con la que comenté en un post anterior que se han cargado el apartado del período de liquidación.

¿Alguien mas lo ha notado o estoy yo haciendo algo mal?

Me parece que hay bastantes más "diferencias" entre ambos, pero éstas son las primeras con las que me he encontrado junto con la que comenté en un post anterior que se han cargado el apartado del período de liquidación.

¿Alguien mas lo ha notado o estoy yo haciendo algo mal?[/quote]

Este apartado ha sido sustituido por
<Destinatarios xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDDestinatario>
<NombreRazon>aaaaaaaaa</NombreRazon>
<NIF>436**49E</NIF>
</IDDestinatario>
</Destinatarios>

Y este está correctamente localizado

Hola de nuevo.
Tras hacer la importación del wsdl, relleno todos los apartados a los que tengo acceso, pero comparando con los ejemplos de los xml publicados, veo que hay una "parte" a la que no tengo acceso, o al menos no se como hacerlo.

Yo el xml resultando lo obtengo en el evento HTTPRIO1BeforeExecute.

Y lo que obtengo con datos de prueba es:

Pero en el ejemplo de xml que tienen publicado veo que antes del nodo <RegistroAltaFacturas> hay metido un nodo Cabecera que en mi captura anterior no aparece.

Y ahí es donde me estoy pegando cabezazos con ello y no consiguo avanzar.
E importado los wsd y entonces en ellos si llego a esa "cabecera", pero lo que luego no consigo es como añadirle las facturas y menos hacer la llamada SOAP, ya que me exige que el parámetro sea del tipo ArrayOf_FacturasEmiitidasType.

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

Muchas gracias y Felices Fiestas!!!

Siento no poder ayudarte. Yo importo el Wsdl con visual studio y trabajo en Net. Pero el resultado de tu importación me parece extraño. No puede desaparecer un nodo así como así