A ver, te explico en base a mi experiencia con Ticket Bai Vizcaya (digo Vizcaya porque parece que es el que más se asemeja a VeriFactu) .. creo que no han explicado bien la funcionalidad, el ejemplo XML (donde aparece el nodo de la cabecera) es el XML del envio donde puedes (o debes) enviar múltiples registros de alta, en concreto desde 1 hasta 1000. Sin embargo la importación del WSD te genera el XML del registro de alta único, es decir, una factura.

Por tanto debes generar un XML para cada factura/ticket (con el WSD) y luego enviarlos en bloque con el formato del XML de ejemplo (el que trae el nodo de la Cabecera).

Ahora pensarás, joer pues meto un envío por cada factura y listo .. pues no, porque leyendo un poco la descripción del servicio, en las respuestas te enviarán unos valores de registros mínimos y segundos a esperar para el siguiente envío (supongo que para no saturar servidores) ... por tanto habrá que enviarlos en bloque si o si.

En cualquier caso esto es lo que yo entiendo, la documentación no es del todo clara.

Buenos días y Feliz Navidad a todos

100% que el envio se hace en bloques de maximo de 1000
Ahora bien, el modelo de esto que pudiera ser mas parecido pudiera ser que sea el envio del SII, que ya se hace tb en bloques según se explica en https://www.agenciatributaria.es/sta...ervicioWeb.pdf

A diferencia de las forales, o al menos es mi experiencia, los envios a la agencia central son bastante seguros y rara vez está caído el servidor con lo cual son minimos (en el SII al menos) los problemas derivados del envio en bloques

Buff vaya tela
Habrá que dejarse esto tambén programado para mi los "L2" son los importantes, por que de trazabilidad, no voy a hacer procesos, ya que se presupone que va todo ok:

01 Instalación o puesta en marcha inicial del sistema informático. 02 Inicio del funcionamiento del sistema informático como sistema VERI*FACTU. 03 Fin del funcionamiento del sistema informático como sistema VERI*FACTU. 04 Lanzamiento del proceso de detección de anomalías en los registros de facturación. 05 Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de facturación. 06 Lanzamiento del proceso de detección de anomalías en los registros de eventos. 07 Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de eventos. 08 Restauración de copia de seguridad. 09 Exportación de registros de facturación generados en un periodo. 10 Exportación de registros de eventos generados en un periodo. 11 Registro resumen de eventos

Tengo dudas, si en sistemas Verifactu (Siempre envio), no es obligatorio los registros de eventos, pero hay un evento que dice " 02 Inicio del funcionamiento del sistema informático como sistema VERI*FACTU." y otro " 03 Fin del funcionamiento del sistema informático como sistema VERI*FACTU."...?
supongo que son excepciones y esos sí hay que enviarlos.

Perdón que siga preguntando, pero es por saber si al final tendré que pasar de la importación del "wsdl", (no del wsd) y hacer el envío de otra manera.

Me explico lo que te he entendido que tengo que hacer:
- Genero un xml por cada factura según voy facturando.
- Cada "x" facturas o cada "y" tiempo tendré que hacer el envío de las facturas que tenga pendiente hasta ese momento y para ese momento es cuando ya monto el xml "conjunto" con los datos de la cabecera más los datos de cada una de las facturas. Hasta ahí ¿correcto?.

Pero entonces, al importar el wsdl, que es el que incorpora la llamada getsfSoap, resulta que lo que hay que pasarle es una array de facturas.
-

Y con esa llamada me genera el xml con el detalle de las facturas, pero sin el famoso apartado de "cabecera".

Con lo cual o algo me estoy perdiendo, o al final voy a tener que pasar de él y hacerlo todo a mano como hice en su momento para enviar al SII.

Gracias por vuestra paciencia.

Hasta ahí correcto, ojo, bajo mi criterio eh, yo lo voy a hacer así y cuando se publiquen los servidores de pruebas o mas documentación ya veremos las respuestas.

Yo lo voy a hacer a mano seguramente, tanto la cabecera como el pie final.

gracias
me pongo ya a ello

En un sistema no-Veri*factu pero que ha funcionado en algún momento en modo Veri*factu, los registros de eventos no son opcionales. Esta obligación es de aplicación para todo el tiempo, sin distinguir entre el periodo de funcionamiento en un modo u otro. Por tanto, un sistema que puede funcionar en los dos modos debe registrar los cambios de modo, con la fecha-hora en que se producen (y estas fechas son importantes para interpretar correctamente los registros de facturación).

Lo que no tengo claro es si entre los dos eventos 02 y 03, es decir durante el periodo de tiempo que ha funcionado en modo Veri*factu, pueden o deben estar más registros de eventos.

Tampoco tengo claro si un sistema solo-Veri*factu debe tener un registro de eventos con exactamente dos eventos (un 01 y un 02), correctamente encadenados y firmados. O incluso si estos dos registros pueden «venir de fábrica», por ejemplo creados por el programa de instalación inicial de la base de datos.

Pero los eventos están en versión 0.3 según la hoja de Excel, habrá aclaraciones ulteriores.

Hola a tod@s.


Estoy echando un vistazo a esto y no me importa el fichero wsdl en mi Delphi 2007, a ver si alguien me puede dar luz. Hago lo siguiente:


- Inserto un objeto HTTPRIO
- Pulso en Component-Import WSDL

- Pongo la url del wsdl: https://prewww2.aeat.es/static_files...cturacion.wsdl
y pulso next-next-finish


Después de esto (que es lo que he hecho siempre para el tema sii si mal no recuerdo) me da este mensaje:





¿Alguien me puede decir por dónde van los tiros?


Gracias y un saludo.

husos horarios
 

En las descripciones de mensajes veo que están previstos husos horarios, con exactamente 3 posibilidades: 01 (GMT, Canarias en invierno), 02 (CET/BST, península en invierno o Canarias en verano) y 03 (CEDT, península en verano); una codificación fuera de estándar, poco acertada y demasiado restrictiva, diría yo. Visto los ejemplos, es una cosa que han añadido después del 29/10 :cool: Es un campo obligatorio en la fecha-hora de generación del registro, con la descripción (en el Excel) siguiente
¿Hay una cosa parecida en alguno de los Ticket*BAI?

Yo lo he hecho con Delphi 11.3 y con la 10.2.3 y me ha funcionado sin problemas.

Adjunto las units generadas (por si sirve).

Aprovecho que se ha publicado documentación para actualizar el primer hilo del mensaje con los últimos cambios y documentos.

Además se ha habilitado una nueva sección dentro del FTP del club, donde se irán copiando/almacenando los documentos, para tenerla accesible en cualquier momento. No sólo tiene que ser documentación "oficial"; Si se cree conveniente que otros documentos, códigos o información pueden ser útiles, también se pueden incorporar (basta con que aviséis a algún moderador o a mi mismo).
https://terawiki.clubdelphi.com/Otro...LeyAntifraude/

Que yo sepa y recuerde no.

Hola, eso mismo ya lo comenté yo unos cuantos post más atrás. Te pongo link al primero de los post, pero luego seguí poniendo cosas según iba descubriendo cosas.

El link es: https://www.clubdelphi.com/foros/sho...&postcount=933

Creo que al final el motivo era porque las urls eran https, pero nadie me lo "confirmó/rebatió". A ver si ahora entre los dos lo conseguimos descifrar...

¿Al intentar compilar el proyecto a ti también te da un error que que las cadenas no pueden tener más de 255 caracteres o algo así?

Gracias.

Gracias Germán, seguro que me vienen bien. Mi preocupación es que mi Delphi 10.1 no sea compatible o algo así y eso si que será un problema.


A ver si alguien que use esta versión me puede decir algo.


Gracias y un saludo.

Si, no había compilado el proyecto.
Con los archivos generados también me da ese error:

[dcc32 Error] SistemaFacturacion.pas(1599): E2056 String literals may have at most 255 elements

Simplemente edita el fichero SistemaFacturacion.pas y divide esa cadena en 2.
Es decir, donde hay algo como esto y falla:

Código Delphi [-]
 InvRegistry.RegisterMethodInfo(TypeInfo(sfSOAP), 'AltaFactuSistemaFacturacion', '',
                                 '[ReturnName="RespuestaLinea", RequestNS="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd", ResponseNS="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/RespuestaSuministro.xsd"]', IS_OPTN or IS_UNBD);

Pon esto:

Código Delphi [-]

 InvRegistry.RegisterMethodInfo(TypeInfo(sfSOAP), 'AltaFactuSistemaFacturacion', '',
      '[ReturnName="RespuestaLinea",  RequestNS="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/' + 
     'es/aeat/tike/cont/ws/SuministroLR.xsd",   ResponseNS="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplic' + 
     ' aciones/es/aeat/tike/cont/ws/RespuestaSuministro.xsd"]',  IS_OPTN or IS_UNBD);

Lo he partido en varios trozos para que se vea bien.

Pues no sé qué decirte pero me extrañaría que fuera por el https porque las de la aeat también lo son y ahí en su día no tuve grandes problemas aunque si es cierto que con las últimas versiones si que los he tenido.


Saludos.

Me suena que ya lo intenté yo y si que hay incompatibilidades.

Ok, se me ha ocurrido probar a importar el fichero desde un Delphi Berlin que tengo en un portátil y me ha funcionado correctamente por lo que deduzco que debe de ser un problema de mi Delphi local. Seguiré mirando a ver qué averiguo.


Gracias y un saludo.

Si, gracias. Ya me había sugerido esa solución otro compañero en este mismo hilo

Era por asegurarme que siguiera pasando lo mismo.

Y el otro problema que tengo es con el elemento CABECERA, que como ya comenté anteriormente en éste hilo, no consigo acceder a él para meter los datos correspondientes. Sólo puedo meter el array con las facturas a enviar, pero seguro que al hacer el envío me lo darán para atrás por no tener la cabecera.
¿Será que se les ha olvidado definirlo?

Me podrias indicar donde has visto esas posibilidades, solo he enonctrado estas en el xsd y no hacen referencia a invierno, verano...


- <simpleType name="HusoHorarioGenRegistroType">
- <restriction base="string">
- <enumeration value="01">
- <annotation>
<documentation xml:lang="es">GMT+0</documentation>

</annotation>


</enumeration>


- <enumeration value="02">
- <annotation>
<documentation xml:lang="es">GMT+1</documentation>

</annotation>


</enumeration>


- <enumeration value="03">
- <annotation>
<documentation xml:lang="es">GMT+2</documentation>

</annotation>


</enumeration>


</restriction>


</simpleType>

Según la unit que se genera al importar el WSDL no existe esa parte.
¿Exactamente cuando dices cabecera a qué te refieres?

He visto que en el EXCEL con los diseños de registro hay 3 de alta (DR=Diseño Registro):

• DR Alta.VERIFACTU
• DR Alta.Requerimiento
• DR Alta.C-E

En los 2 primeros sí aparece una sección de Cabecera, pero no en el tercero.
¿?¿?¿?¿

Me respondo a mi mismo.
He descargado el XSD desde aquí.
Lo he subido al FTP junto al resto de la documentación.

Importándolo en un proyecto de Delphi (XML Data Binding) y con un poco de código:

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;

Se genera la parte de la cabecera sin problemas...

Os adjunto el fichero generado.

Yo en el ejemplo que estaba haciendo para comparar con el wsdl del SII tengo esto código Delphi:

Y me funciona correctamente, y puedo acceder al LRfacturasEmitidas.Cabecera sin problema.

Sin embargo, el de VeriFactu no encuentro el equivalente al SuministroLRFacturasEmitidas del SII.

Estoy revisando el wsdl por dentro y me he dado cuenta de una cosa quizás puedas ser la causa de no encontrar lo que estoy buscando.

En la parte superior del wsdl aparece:
Mientras que luego en el resto del wsdl las urls siempre hacen referencia a: https://www2.agenciatributaria.gob.e.../tike/cont/ws/.... y resulta que esas páginas no existen a día de hoy. Podrá ser eso o estaré diciendo tonterías...

Si yo accedo a https://prewww2.aeat.es/static_files...nformacion.xsd hay si tengo un nodo CABECERA que quizás sea el que estoy buscando, pero el problema es que luego, en el resto del documento, la referencia se hace a: https://www2.agenciatributaria.gob.e...nformacion.xsd y esa url no funciona.

PD. Acabo de ver que mientras escribía mi post, @Neftali había editado el suyo, pero por si acaso pudiera servir de algo, lo posteo.

Ante todo, muchas gracias por tu paciencia.
Esto a base de pegarme cabezazos todo el fin de semana, ya lo había conseguido encontrar, pero entonces me atascaba en el momento de querer hacer el envío, ya que en el método GetsfSOAP requiere que sea un objeto de tipo Array_Of_RespuestaExpedidaType y no se como "calzarle" el cabecera.

Germán.


Sigo tus instrucciones del XML Data Binding pero solo me genera dos archivos, uno .pas y otro .xdb. ¿El fichero .xsd cómo se genera?


Gracias y un saludo.

El XSD es el fichero de esquema. Te lo deben dar.
Se descarga desde aquí y lo he copiado aquí en el FTP.

El .xsd, que yo sepa, como mucho lo tendrás que guardar una vez abierto en el navegador. ¿Te refieres a eso?

Gracias Germán.




Efectivamente. Entiendo que el fichero .xsd solo se usa para generar el .pas


Seguimos probando.


Gracias a los dos.

El problema con el que me he topado yo es que falta la URL del servicio.
Cuando se importa el WSDL, en la función principal hay estos datos:

Código Delphi [-]

function GetsfSOAP(UseWSDL: Boolean; Addr: string; HTTPRIO: THTTPRIO): sfSOAP;
const
  defWSDL = 'https://prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tikeV1.0/cont/ws/SistemaFacturacion.wsdl';

  defURL  = 'xxxxxxxxxx';    <==================================

  defSvc  = 'sfService';
  defPrt  = 'SistemaFacturacion';
var
  RIO: THTTPRIO;
begin
  Result := nil;
  if (Addr = '') then
  begin

¿Se me escapa algo o nos quedamos aquí parados?

En lo que a pruebas "reales" de envío se trata, me temo que sí.

Yo lo que estoy es generando el xml en el evento HTTPRIO1BeforeExecute para ver lo que estoy enviando y ahi es donde me temo que falta el famoso <cabecera>

tldr: es interpretación mía.
Son las tres posibilidades traducidas al castellano y a las abreviaciones usuales; GMT+0 es el huso horario GMT (Greenwich Mean Time) de Gran Bretaña y Canarias en invierno; GMT+1 es el huso horario del horario de verano en Gran Bretaña (BST, British Summer Time) y en Canarias, y también es el horario de invierno en el continente (CET, Continental o Central Europe Time) y entonces de la península (menos Portugal); y GMT+2 es el horario de verano en el continente (CEDT, Continental o Central Europe Daylight Time).
Todo esto, pendiente de posible cambios legislativos en las alternancias en los horarios de verano, por tanto es un poco mejor quedarse con GMT+x que poner «horario de invierno».

Sin embargo, el problema lo veo en las exportaciones, donde hay dos fechas distintas pero tal como se ve en el registro de eventos solo hay un huso horario; y me teme que habrá cosas “interesantes” cuando el periodo será los meses de marzo (sobrará una hora del 1 de abril) u octubre (faltará una hora al final del mes)... :rolleyes:

Hola a tod@s.


Dándole vueltas a este tema se me ocurren mil problemas que vamos a tener a la hora de enviar los datos y uno de ellos es que el NIF y nombre del cliente sean válidos. Imagino que si se intenta subir una factura con un nif erróneo el servidor chillará y la devolverá como no válida y a partir de ahí no sé cómo actuar, sobre todo si el cliente ya no está y no hay forma de comprobar y corregir ese dato.


Se puede hacer una consulta mediante webservice para confirmar que el nif+nombre es correcto pero estoy pensando en que se necesita hacer la llamada con un certificado válido y me temo que los clientes no van a instalar certificados en todos los posibles terminales de la red y que usen el programa. ¿Qué se os ocurre al respecto? porque ando un poco perdido con este asunto.


Gracias y un saludo.

Hola
Va a haber varios escenarios. Nif, nie, cifs..
Los códigos de identificacion españoles tienen algoritmo de comprobación y son verificables, como bien dices por webservice con un certificado, los extranjeros se los comen todos si los ponen en id_otro
Por tanto, si no instalas un certificado, que además esté vigente, sólo puedes comprobar con el algoritmo y además te pueden decir nombres erroneos, es muy frecuente en los autonomos ypor erro4, que el cliente te de un nombre xomerxial de empresa con un cif.
Que yo sepa, las verificaciones que suelen hacer es solo que el cif b
Nif(español) cumple el algoritmo(numero de caracteres y cálculo de letra/s)
Otra cosa es que hagan, posteriormente, comprobaciones, pero es raro que sancionen por eso.

Yo veo que el uso horario de España, según interpreto, es el 2. No creo que tengan que ver las estaciones ni los cambios horarios de cada país.
Saludos

Con el SII hemos tenido problemas parecidos y recuerdo (pero de esto hay años) algunas facturas han sido «parcialmente aceptadas» cuando el nombre del cliente no era lo que esperaba Hacienda. Me parece que el mecanismo prevé un caso parecido, dónde después de recibir esta respuesta de aceptación parcial, tienes más tiempo para ir a buscar el cliente y pedirle su nombre correcto, o alternativamente comprobar por ensayos sucesivos como está registrado exactamente en Hacienda usando el portal de Hacienda (nos ha pasado un par de veces con clientes del este de Asia donde el orden de los nombres y apellidos puede variar, luego era intentar varias combinaciones), luego registrar un registro de corrección (tipo S1, alta sustitutiva) y pasarlo a Hacienda.
Creo que es la forma correcta de hacerlo; con la condición que Hacienda te acepte parcialmente el registro inicial.

De hecho, aparentemente con este mecanismo de alta sustitutiva se puede «cambiar» un montón de datos de la factura, tanto en el destinatario como en los importes. Mmmm.

¿Alguien sabe lo que hay que rellenar en el campo <FechaExpedicionFacturaRegistroAnterior> de tipo "fecha" para el primer registro?
He visto que los campos <NumSerieFacturaRegistroAnterior> y <HuellaRegistroAnterior> tienen tamaño mínima de 0 caracteres, por tanto pueden quedar vacíos para tal caso (que está identificado en el RDL, 10.1.ñ). Pero el tipo "fecha" solo acepta cadenas de 10 caracteres con dígitos y guiones, y debe haber algún valor mágico...

Entiendo que estáis haciendo pruebas generando los registros aunque sin enviarlos.


¿Habéis averiguado algo en relación al registro de cabecera+lineas?


Saludos.

He estado revisando pruebas de Agosto del 22 y en la versión 0,1 si que existía la cabecera.