FiveTech Software tech support forums

Posted: **Fri Oct 11, 2024 10:28 am**

Sí has conectado y te dicen:

<callstack>XML no válido o mal formado

desde el servidor java de la agencia:

es.aeat.adws.jdit.imp.ws.WSFilterSrvImpl.verificarFirma(WSFilterSrvImpl.java:845)

Probablemente la agencia hara un programa gratuito para todo ese tipo de casos, gente que factura poco y sólo necesita lo más parecido a una máquina de mecanografiar pero que cumpla VF

Posted: **Sun Oct 13, 2024 6:30 pm**

Hola a todos,

Hoy mientras me duchaba (ahí no me distrae nadie), estuve pensando en como afrontar el envío de los XML a Hacienda.

El caso es que supongo que muchos (todos?) lo harán con un servicio, creo que sería lo adecuado.
Yo intentaré abordarlo con una aplicación FWH que se dedicará a eso específicamente, a enviar los XML a Hacienda; no será un servicio.

Cuando desde la aplicación de gestión se haga una factura, se guardará un registro en una DBF concreta, imprimirá la factura y comprobará que la otra aplicación (la que enviará el registro a Hacienda) esté levantada, si no es el caso la levantará (por tanto, siempre estará operativa).

Esa segunda aplicación (la que envía el XML a Hacienda) tendrá un TIMER de manera que irá chequeando la DBF mencionada y hará lo que convenga.

¿Por què?
Por que no se mucho de servicios ni de los miles de utilidades que utiliza Windows 'por detrás' para gestionar su propio funcionamiento. Además me gusta ver que lo que depende de mi funciona. Y si hay un problema, le podré preguntar qué ve el usuario.

¿Cómo lo ven?

Posted: **Sun Oct 13, 2024 8:23 pm**

FiveWiDi wrote:Hola a todos,

Hoy mientras me duchaba (ahí no me distrae nadie), estuve pensando en como afrontar el envío de los XML a Hacienda.

El caso es que supongo que muchos (todos?) lo harán con un servicio, creo que sería lo adecuado.
Yo intentaré abordarlo con una aplicación FWH que se dedicará a eso específicamente, a enviar los XML a Hacienda; no será un servicio.

Cuando desde la aplicación de gestión se haga una factura, se guardará un registro en una DBF concreta, imprimirá la factura y comprobará que la otra aplicación (la que enviará el registro a Hacienda) esté levantada, si no es el caso la levantará (por tanto, siempre estará operativa).

Esa segunda aplicación (la que envía el XML a Hacienda) tendrá un TIMER de manera que irá chequeando la DBF mencionada y hará lo que convenga.

¿Por què?
Por que no se mucho de servicios ni de los miles de utilidades que utiliza Windows 'por detrás' para gestionar su propio funcionamiento. Además me gusta ver que lo que depende de mi funciona. Y si hay un problema, le podré preguntar qué ve el usuario.

¿Cómo lo ven?

Pues básicamente lo veo como tu. Un demonio en modo servicio o en modo llamada lateral que haga el trabajo.
Ahora bien. Hay que tener en cuenta:

Flujo de datos (tiempo t). El envío sólo se puede hacer cuando haya pasado el tiempo que la última respuesta de la agencia indicó
Levantar programa enviador. ¿ Qué pasa si hay facturas sin enviar y cayó el programa enviador y el usuario no genera nuevas facturas ?

Me gusta mucho el tema que has iniciado que es una subpata de la generación y envío, que son la otra pata, igual de importante, o quizás más IMHO, que la generación del .xml

Posted: **Sun Oct 13, 2024 9:53 pm**

paquitohm wrote:Pues básicamente lo veo como tu. Un demonio en modo servicio o en modo llamada lateral que haga el trabajo.
Ahora bien. Hay que tener en cuenta:

Flujo de datos (tiempo t). El envío sólo se puede hacer cuando haya pasado el tiempo que la última respuesta de la agencia indicó
Levantar programa enviador. ¿ Qué pasa si hay facturas sin enviar y cayó el programa enviador y el usuario no genera nuevas facturas ?

Me gusta mucho el tema que has iniciado que es una subpata de la generación y envío, que son la otra pata, igual de importante, o quizás más IMHO, que la generación del .xml

Si, si. Eso del valor 't' se deberá capturar a cada respuesta, se crea una función que chequee si ha transcurrido el tiempo que indica Hacienda, cuando el Timer indique que se debe enviar se usa esta función y se envía o no; hasta el siguiente Timer.

La aplicación de facturación al arrancar siempre levantará el sistema de envío a Hacienda.
Si se cae el sistema de envío, sencillo. Lo que se ha hecho toda la vida.
'Sal y vuelve a entrar' o 'Pincha' en el icono 'talcualverifactu' y dale Intro.

Posted: **Mon Oct 14, 2024 6:15 pm**

El tema del servicio es una solución muy buena, pero yo en mi caso intentaré hacerlo todo desde dentro del programa por varios motivos:
- Tener que instalar un segundo programa me genera más trabajo x cliente, en algunos pc's hay que configurar antivirus para que no mareen, permisos, etc... y en caso de reinstalación no es tan fácil como copiar la carpeta y a funcionar
- Si trabajo con librerías externas, cuando las actualizo, he de aplicarlas a ambos programas y testearlas ( más trabajo )
- Tener un servicio, requiere de una programación algo "diferente", el usuario no ve nada, no hay GUI, todo se gestiona en un log y si "peta" por algún motivo, hay que configurar bien el servicio para que reinicie y no se quede parado, pero claro, hay que realizar alguna acción adicional para que el servicio informe de que ha fallado, de lo contrario no nos enteramos.
- El servicio deberá tener un sistema de comunicación con el programa ( a nivel de log, sockets, o lo que sea ) para informar de los resultados de los envíos al usuario, por lo que el programa "Base" deberá tener también algún timer para recibir estos resultados o ya meterse en comunicaciones entre programas ( multihilo )

Bueno, creo que son cosas a tener en cuenta, igual las tenéis solucionadas, Perfect!!! yo por mi parte voy a intentar lo siguiente:

- El usuario hace una factura y el programa la mete en una cola de envíos
- Inmediatamente se envía a procesar la cola de envíos ( normalmente habrá 1 factura para enviar )
- Si se envía, Perfect!
- Si no se envía, se queda en cola pendiente, la cola se ejecutará en la próxima factura que se realice o también un proceso manual que el usuario pueda ejecutarla cuando quiera.
- Posible opción de meter un timer que revise la cola y cada X minutos y si hay algo que la ejecute

El tema de no hacer el envío con la opción de la factura y meterlo en la cola es por centralizar los envíos desde un solo proceso, así no tengo una llamada al envío al finalizar la factura y otra en el proceso de la cola de envíos incompletos.

Se que esto puede crear alguna pausa ya que no utilizo el multihilo y si el timer ejecuta el envío quizás moleste, pero esto solo pasará cuando haya algo en la cola que no se haya podido enviar, creo que ocurrirá muy pocas veces o casi nunca ( espero ). Otra opción sería activar el multihilo, pero solo por esta opción no creo que me valga la pena, ya que el rendimiento de las aplicaciones HB cuando compilas con -mt baja considerablemente.

Rectificadme y dadme un cachete si lo que pongo no tiene sentido

Buen debate!

Posted: **Mon Oct 14, 2024 7:58 pm**

Muy bueno todo.
Propongo algunas ideas:

VictorCasajuana wrote:El tema del servicio es una solución muy buena, pero yo en mi caso intentaré hacerlo todo desde dentro del programa por varios motivos:
- Tener que instalar un segundo programa me genera más trabajo x cliente, en algunos pc's hay que configurar antivirus para que no mareen, permisos, etc... y en caso de reinstalación no es tan fácil como copiar la carpeta y a funcionar
- Si trabajo con librerías externas, cuando las actualizo, he de aplicarlas a ambos programas y testearlas ( más trabajo )
- Tener un servicio, requiere de una programación algo "diferente", el usuario no ve nada, no hay GUI, todo se gestiona en un log y si "peta" por algún motivo, hay que configurar bien el servicio para que reinicie y no se quede parado, pero claro, hay que realizar alguna acción adicional para que el servicio informe de que ha fallado, de lo contrario no nos enteramos.

Programa ENVIADOR:
Pensando en los inconvenientes de configurar algo, yo lo que haría sería en el momento que se genera una factura:

Code: Select all | Expand

IF Ejecutable_Enviador.exe != EN_USO
   IF !File("Ejecutable_enviador.exe")
      Copiar Ejecutable.exe Ejecutable_enviador.exe
   ENDIF
   WinExec("Ejecutable_enviador.exe")
ENDIF

- El servicio deberá tener un sistema de comunicación con el programa ( a nivel de log, sockets, o lo que sea ) para informar de los resultados de los envíos al usuario, por lo que el programa "Base" deberá tener también algún timer para recibir estos resultados o ya meterse en comunicaciones entre programas ( multihilo )

Yo creo que esto no es necesario. El enviador irá marcando las facturas en la .dbf (o tabla que sea) según se van enviando. Ahora mismo no comprendo la necesidad de establecer un dialogo entre programa enviador y programa principal

Bueno, creo que son cosas a tener en cuenta, igual las tenéis solucionadas, Perfect!!! yo por mi parte voy a intentar lo siguiente:

- El usuario hace una factura y el programa la mete en una cola de envíos
- Inmediatamente se envía a procesar la cola de envíos ( normalmente habrá 1 factura para enviar )
- Si se envía, Perfect!
- Si no se envía, se queda en cola pendiente, la cola se ejecutará en la próxima factura que se realice o también un proceso manual que el usuario pueda ejecutarla cuando quiera.
- Posible opción de meter un timer que revise la cola y cada X minutos y si hay algo que la ejecute

El tema de no hacer el envío con la opción de la factura y meterlo en la cola es por centralizar los envíos desde un solo proceso, así no tengo una llamada al envío al finalizar la factura y otra en el proceso de la cola de envíos incompletos.

Se que esto puede crear alguna pausa ya que no utilizo el multihilo y si el timer ejecuta el envío quizás moleste, pero esto solo pasará cuando haya algo en la cola que no se haya podido enviar, creo que ocurrirá muy pocas veces o casi nunca ( espero ). Otra opción sería activar el multihilo, pero solo por esta opción no creo que me valga la pena, ya que el rendimiento de las aplicaciones HB cuando compilas con -mt baja considerablemente.

Una cosa que el otro dia pensé: Tenemos que poner un flujo de datos en nuestro programa. No debemos poder estar mandando una factura desde el programa principal y mandando desde un ENVIADOR. Tenemos que poner un semaforo o mutex para que sólo si el semaforo es verde se pueden enviar facturas, bien directamente, bien desde el enviador, bien desde el usuario A, bien desde el usuario B.

Me gusta mucho este debate. Me pareciera que esto es quizás mas importante que el diseño del .xml porque el diseño del .xml no afecta (mucho) a la estructura de nuestro programa, quizas algun campo nuevo, pero el envío si afecta a la forma en que debe funcionar, y que no funciona, nuestro programa, ademas de que hay que crear campos y tablas y directorios donde albergar la informacion de envio y recoger la respuesta.

Posted: **Tue Oct 15, 2024 7:05 am**

paquitohm wrote: Una cosa que el otro dia pensé: Tenemos que poner un flujo de datos en nuestro programa. No debemos poder estar mandando una factura desde el programa principal y mandando desde un ENVIADOR. Tenemos que poner un semaforo o mutex para que sólo si el semaforo es verde se pueden enviar facturas, bien directamente, bien desde el enviador, bien desde el usuario A, bien desde el usuario B.

Me gusta mucho este debate. Me pareciera que esto es quizás mas importante que el diseño del .xml porque el diseño del .xml no afecta (mucho) a la estructura de nuestro programa, quizas algun campo nuevo, pero el envío si afecta a la forma en que debe funcionar, y que no funciona, nuestro programa, ademas de que hay que crear campos y tablas y directorios donde albergar la informacion de envio y recoger la respuesta.

En el caso de tener un enviador, no pondría la opción de enviar desde el programa, pero este caso no lo analizaré mucho ya que mi opción principal será tenerlo todo en un único programa.
Referente a lo que comentas de la importancia del envío, es lo importante, el xml es un fichero con unos requisitos, sin más, pero el tema del t nos afecta bastante al tema del envío. Por mi parte sigo con mi idea principal, una cola de envíos en mi programa principal. Solo un usuario puede procesar la cola, no pueden haber envíos simultáneos desde diferentes puestos, además, no sé si esta opción la contempla hacienda, igual te banea la segunda petición a su servidor. Esto lo veo fácil, simplemente bloqueando en exclusivo la tabla que gestiona la cola y listos.

Posted: **Tue Oct 15, 2024 8:00 am**

En el caso de tener un enviador, no pondría la opción de enviar desde el programa, pero este caso no lo analizaré mucho ya que mi opción principal será tenerlo todo en un único programa.

Lo que yo propongo también es una especie de "unico programa". El mismo ejecutable se puede duplicar porque no exista O POR FECHA anterior al exe principal. Todo se haria automaticamente: Solo se actualizaria un ejecutable. Se podria utilizar taskkill para matar el enviador activo, siempre que no esté haciendo un envio, naturalmente.
Al lanzar el enviador con winexec() estamos dando capacidades multiproceso al sistema que quedará abierto y a la espera para subsiguientes envios.

Quizá mis metodos no sean los más ortodoxos. Pero creo que buscamos ser practicos utilizando soluciones sencillas y probadas

Posted: **Tue Oct 15, 2024 11:27 am**

Buenos días,

Debo estar 'cruzado'.

Alguna alma caritativa puede darme la URL en donde está la documentación de desarrollo de Verifactu en Hacienda?

Vaya mie@~€@#~€da de ayuda que tiene la web de Hacienda. Además de tener links en el pié de página de web que no encuentra.

Posted: **Tue Oct 15, 2024 11:29 am**

URL en donde está la documentación de desarrollo de Verifactu en Hacienda

https://www.agenciatributaria.es/AEAT.d ... FACTU.html

Venga que entre todos podremos hacerlo.

Posted: **Thu Oct 17, 2024 6:56 am**

De diez items que aparecen en la lista de la web de la AEAT, uno se refiere a documentación obsoleta y otros 5 a que son un borrador.
De modo que, según eso, solo un 40% de la información que han colgado parece "definitiva".
Nosotros ya hemos desarrollado un sistema para comunicar con la AEAT para el asunto de impuestos especiales (sistemas SILICIE y SIANE) y no empezó con tantas incertidumbres, aunque a pesar de ello el desarrollo fue largo y con muchas pruebas y error, teniendo que comunicar muchos fallos a los servicios de informática de la propia AEAT.
Lo que quiero decir es que con tantas incertidumbres y correcciones pendientes, el trabajo que ahora se haga puede tener que sufrir muchas correcciones todavía.

Para montar los xml, en el caso de desarrollo comentado, al final lo más eficiente fue tomar los modelos de los pdf de la documentación y montarlos con la librería hbmxml.lib
Otro consejo, no traten de abarcar toda la casuística prevista, céntrense en la necesaria para sus usuarios concretos, o el proceso se hará eterno.
Y otro más, eliminen todos los CRLF de los xml, en nuestro caso nos dió dolores de cabeza hasta descubrir que a la AEAT no le gustaban.

En fin, a ver si se lo toma la AEAT en serio y con plazos técnicos realistas, porque como está lo veo muy verde todavía para pensar en que podamos desarrollar algo "definitivo" a corto plazo.

Posted: **Thu Oct 17, 2024 11:38 am**

Noticia de hoy Se ha detectado un problema en el servidor de la AEAT que afecta a la presentación de Modelos Fiscales y envíos al SII

Como para añadir más cosas a esos servidores. Madre mía la que viene.

Yo particularmente estoy intentando hacer un envio de xml, si consigo conectar pero no consigo hacer ninguno valido.
Ya no se que probar.

A ver si a partir del 28 de octubre ponen algo más claro todo. porque yo voy hecho un lio.

Posted: **Fri Oct 18, 2024 9:15 am**

Hola, estoy enviando un fichero .xml y el resultado de pantalla es el siguiente :

Code: Select all | Expand

.\curl\bin\curl --cert "empresa.pem" --key "empresa_key.pem"  --data 1.xml --output respuesta.xml https://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP -v
Note: Using embedded CA bundle, for proxies (234847 bytes)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Host prewww1.aeat.es:443 was resolved.
* IPv6: (none)
* IPv4: 195.77.198.76
*   Trying 195.77.198.76:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [310 bytes data]
*  CAfile: h:\segjose\HABOUR\gesman.new\xml\curl\bin\curl-ca-bundle.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [87 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4208 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [461 bytes data]
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
{ [16652 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
} [2263 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS handshake, CERT verify (15):
} [264 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / [blank] / UNDEF
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: C=ES; L=Madrid; O=Agencia Estatal de Administración Tributaria; CN=*.aeat.es
*  start date: Oct 23 08:43:06 2023 GMT
*  expire date: Nov 23 08:43:05 2024 GMT
*  subjectAltName: host "prewww1.aeat.es" matched cert's "*.aeat.es"
*  issuer: C=US; O=Entrust, Inc.; OU=See http://www.entrust.net/legal-terms; OU=(c) 2012 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1K
*  SSL certificate verify ok.
*   Certificate level 0: Public key type ? (3072/128 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type ? (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type ? (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Connected to prewww1.aeat.es (195.77.198.76) port 443
* using HTTP/1.x
> POST /wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP HTTP/1.1
> Host: prewww1.aeat.es
> User-Agent: curl/8.10.1
> Accept: */*
> Content-Length: 5
> Content-Type: application/x-www-form-urlencoded
>
} [5 bytes data]
* upload completely sent off: 5 bytes
< HTTP/1.1 200 OK
< content-type: text/xml;charset=UTF-8
< dit-niu: 46020459447
< content-length: 5883
< dit-tarea: 66
< dit-servidor: WLP00302
< dit-idpeticion: 20241018105610810011
< date: Fri, 18 Oct 2024 08:56:10 GMT
< x-ua-compatible: IE=7
< set-cookie: CERT_WWW1=67CB69976D0E5FF41C7D26D010D2496F34BBC1197F7129B33126A25E9F60203B57E4A39D9C9F297C88FB5C679F33081E2CF44B049719987D86F02B4D441DA1144C34115264A99FB92774379AF3BC72C58AE5832BMxLYRXkJCCaAIY6SI0r2y2/XOFrur37gO+PI2Fkr5ULtoklOCJSncsfa2bAk4bP/iRnbPH9MyEjNh2YAsCqmsBXF3x+zf7q8+SKHvTqRExdXrJYJvMcwvgRHDmuMM+Yicw62wxgqE/7PrP4U/EdvOvvbJdPA0QeRPIHE8dkIGIqEc4xm76lelNcTEyBdX+M6UpgaV9pL7oMCzuisTl/fnH76G+dXCnQYpIi6SCUe4DG5LL80yLn53JeXiYeHQKOWXRuU9GVAb0yvb1JNnvpL3FdXaVB1BUE/nPN3eGWwN4WSM1HdLa+qUz+Gi2/Ax7bsvOuaRQismxMmLK3NdvWuisE6KNH4Uk+7x99/INZMOtFjb6WUvV5ZbGsQkM3ecenVFs8j+IrpxAV/HuOYV8HPASq/v6irMVkSr+qxov+XRUtqqKQ6xwR47eBY+kc6aCxZ+Q==; Domain=.aeat.es; Path=/; HttpOnly; Secure
< set-cookie: CERT_WWW1V=20241018-10261080; Domain=.aeat.es; Path=/; Secure
< set-cookie: sgat_id_usr_sede=%7B%22tipoAcceso%22%3A%22C%22%2C%22fechaYHora%22%3A%2220241018105610810%22%2C%22nombre%22%3A%22MAN%20SOFT%20COMPUTER%20SL%22%7D; Domain=.aeat.es; Path=/; Secure
< dit-codigo-respuesta: 0
< content-language: es-ES
< expires: Thu, 01 Dec 1994 16:00:00 GMT
< cache-control: no-cache="set-cookie, set-cookie2"
< x-site: Sede
< referrer-policy: strict-origin-when-cross-origin
< x-xss-protection: 1; mode=block
< strict-transport-security: max-age=31536000; includeSubDomains
< content-security-policy: frame-ancestors 'self' *.aeat.es
<
{ [2828 bytes data]
100  5888  100  5883  100     5  24593     20 --:--:-- --:--:-- --:--:-- 24843
* Connection #0 to host prewww1.aeat.es left intact

Y la respuesta es :

Code: Select all | Expand

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body>
<env:Fault>
<faultcode>env:Client</faultcode>
<faultstring>Codigo[1304].El contenido no está permitido en el prólogo. (1,1)</faultstring>
<detail>
<callstack>XML no válido o mal formado WSExcepcion [faultcode=null, detailMap=null, version=0, faultstring=El contenido no está permitido en el prólogo. (1,1), faultactor=null, faultSubCode=null, reasonText=null, detail=null, nameSpaceUriDetail=null] at es.aeat.adws.jdit.imp.ws.WSFilterSrvImpl.verificarFirma(WSFilterSrvImpl.java:845) at es.aeat.adws.jdit.imp.ws.WSFilterSrvImpl.doFilter(WSFilterSrvImpl.java:225) at es.aeat.adws.jdit.api.ws.WSFilter.doFilter(WSFilter.java:24) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:203) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:93) at es.aeat.adht.jdit.imp.infra.JDitFilterSrvImpl.filtroIni(JDitFilterSrvImpl.java:288) at es.aeat.adht.jdit.imp.infra.JDitFilterSrvImpl.doFilter(JDitFilterSrvImpl.java:101) at es.aeat.adht.jdit.imp.infra.JDitFilterSrvImpl.doFilter(JDitFilterSrvImpl.java:74) at es.aeat.adht.jdit.api.filter.JDitFilter.doFilter(JDitFilter.java:24) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:203) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:93) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:1069) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1260) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1078) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:77) at com.ibm.ws.webcontainer40.servlet.CacheServletWrapper40.handleRequest(CacheServletWrapper40.java:87) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:978) at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.run(DynamicVirtualHost.java:293) at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink$TaskWrapper.run(HttpDispatcherLink.java:1260) at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.wrapHandlerAndExecute(HttpDispatcherLink.java:476) at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.ready(HttpDispatcherLink.java:435) at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:569) at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleNewRequest(HttpInboundLink.java:503) at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.processRequest(HttpInboundLink.java:363) at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.ready(HttpInboundLink.java:330) at com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:169) at com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:77) at com.ibm.ws.tcpchannel.internal.WorkQueueManager.requestComplete(WorkQueueManager.java:516) at com.ibm.ws.tcpchannel.internal.WorkQueueManager.attemptIO(WorkQueueManager.java:586) at com.ibm.ws.tcpchannel.internal.WorkQueueManager.workerRun(WorkQueueManager.java:970) at com.ibm.ws.tcpchannel.internal.WorkQueueManager$Worker.run(WorkQueueManager.java:1059) at com.ibm.ws.threading.internal.ExecutorServiceImpl$RunnableWrapper.run(ExecutorServiceImpl.java:280) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source) Caused by: es.aeat.adws.jdit.api.xml.XmlExcepcion: El contenido no está permitido en el prólogo. (1,1) at es.aeat.adws.jdit.imp.xml.DomUtilsSrvImpl.isToDoc(DomUtilsSrvImpl.java:87) at es.aeat.adws.jdit.imp.xml.DomUtilsSrvImpl.isToDoc(DomUtilsSrvImpl.java:53) at es.aeat.adws.jdit.imp.ws.WSFilterSrvImpl.verificarFirma(WSFilterSrvImpl.java:773) ... 34 more Caused by: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; El contenido no está permitido en el prólogo. at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown Source) at java.xml/javax.xml.parsers.DocumentBuilder.parse(Unknown Source) at es.aeat.adws.jdit.imp.xml.DomUtilsSrvImpl.isToDoc(DomUtilsSrvImpl.java:83) ... 36 more </callstack>
</detail>
</env:Fault>
</env:Body>
</env:Envelope>

Como me indico Paquito, el fallo creo que es la firma, ¿pero exactamente a que firma se refiere?
Alguna indicación para poder enviar y devuelva que correcto e indicando la dichosa "t".

Muchas Gracias

Posted: **Fri Oct 18, 2024 9:17 am**

Personalmente creo que os estáis precipitando.
Recuerdo hace años cuando implementamos el SII, los primeros meses fueron un caos por parte del dpto. de informática de la Agencia Tributaria y las correcciones eran un no parar.
Si algo aprendí de eso es que conviene apartarse un poco, darles tiempo, y esperar a que esté toda la documentación ( mínimo versión 1.0 ) , fijaros que ahora todo es 0.xx ...
Y por supuesto que los entornos de prueba estén operativos al 100%. Siguiendo otros foros, un día fallan y al otro también.

Pensad que una vez aprobada la orden ministerial, tendremos nueve meses para hacer el proceso ...

https://www.youtube.com/watch?v=KOHKnrZfUS0

Posted: **Fri Oct 18, 2024 9:39 am**

Buenos días,

Garbi,

Veo que no usas el command line que puse o quizás lo has tratado de simplificar.
Tirando de memoria, creo que alguno de los parámetros es necesario para que warnings en la firma no tiren abajo la comunicacion. Concretamente, creo recordar, que era el parámetro -k, aunque yo te sugiero usar TODOS los parámetros, porque si están supongo que, en su día, los pondría por algún motivo.

Code: Select all | Expand

\Pw\Conta\Dat\Sii\Utilidades\Curl.Exe -k --connect-timeout 60 -m 300 -s -S -L --header "Content-Type: text/xml;charset=UTF-8" --cert "\Pw\Conta\Dat\Sii\Certificados\Certificado.Pem" --key "\Pw\Conta\Dat\Sii\Certificados\Certificado_key.Pem" --data @\Pw\Conta\Err\Nif_Envio_3754552.xml https://www1.agenciatributaria.gob.es/wlpl/BURT-JDIT/ws/VNifV2SOAP --output \Pw\Conta\Err\Nif_Respuesta_3754552.xml -v

AngelSalom,

IMHO tienes razón en parte. La otra parte es que:
+ Verifactu obliga a cambiar la estructura de nuestros programas y eso dificilmente va a cambiar con las releases tecnicas finales de la Agencia
+ Bien está, por lo anterior, que empecemos a plantearnos cosas, empecemos a probar a enviar, quizá sin entrar en honduras, pero si coger el pálpito de cómo si o si va a ser: Envio agrupado de facturas cada t tiempo

FiveTech Software tech support forums

España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

URL de información de Hacienda para el desarrollo Verifactu

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos