FiveTech Software tech support forums

Posted: **Thu Oct 10, 2024 7:51 am**

Garbi wrote:Hola Paquito,
Con la curl que me has indicado que si que he podido enviar y recibir una respuesta, que por supuesto me da error como respuesta porque es un ejemplo sin datos validos.
Muchísimas gracias por tu aporte.

Tengo una consulta que me ha preguntado el jefe para todos:
Si montamos el sistema Veri*Factu lo que es la programación de los programas actuales que tenemos de facturación ( en total son 4) por que nuestro trabajo principal es otro, no hay que controlar que no se puedan modificar facturas, registro de las modificaciones de facturas,etc ¿Correcto?

Voy a seguir revisando los aportes de Victor y Carlos para poder montar .xml y espero que se una más gente.
Pero hay algo que no tengo claro, si debe ser 9 meses desde su aprobación, si no esta todavía reglamentado todo como indica Victor, entonces que pasa con la entrada en vigor del 1 de julio de 2025

El control de la modificación de facturas, borrado, etc... ya se implantó cuando se publicó la primera ley antifraude. En ese momento incluí un sistema de control que detectaba cualquier cambio de las facturas por un software diferente al mío mediante un sistema de tokens, pero con Verifactu, no permitiré modificar los datos que afecten al tema fiscal, una vez se haya impreso ( fecha, cliente, importe ) el resto de información sí que se podrá modificar ( forma de pago, representante, observaciones, etc... ) Tampoco permitiré que la fecha de la factura sea diferente a la fecha actual, para fechas diferentes la el reglamento de facturación https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696 incluye la fecha de operación que es la fecha en la que se ha realizado el servicio o entregado el producto. La fecha de la factura ha de ser la fecha en que se emite la factura.
Realmente, durante muchos años se ha tratado el documento "factura" en los programas como una ficha más con toda la libertad, pero eso ya ha pasado a la historia, ahora una factura es un documento con muchas restricciones. Esto, por supuesto, provoca algunas "charlas" con los usuarios que están acostumbrados al libre albedrio respecto a las facturas, pero en el momento que la Agencia tributaria ha puesto en el punto de mira de la responsabilidad a la empresa que "desarrolla" el software, ahí ya ha cambiado la cosa, ahora hay que ir con mucho cuidado de lo que se deja hacer con una factura. Recordemos que una factura es un documento oficial que se emite desde nuestros programas y ha de cumplir el reglamento de dicho documento.
Otra cosa es que nos guste más o menos, pero eso ya es otro debate...

Salud!

Posted: **Thu Oct 10, 2024 8:42 am**

VictorCasajuana wrote:El control de la modificación de facturas, borrado, etc... ya se implantó cuando se publicó la primera ley antifraude. En ese momento incluí un sistema de control que detectaba cualquier cambio de las facturas por un software diferente al mío mediante un sistema de tokens, pero con Verifactu, no permitiré modificar los datos que afecten al tema fiscal, una vez se haya impreso ( fecha, cliente, importe ) el resto de información sí que se podrá modificar ( forma de pago, representante, observaciones, etc... ) Tampoco permitiré que la fecha de la factura sea diferente a la fecha actual, para fechas diferentes la el reglamento de facturación https://www.boe.es/buscar/act.php?id=BOE-A-2012-14696 incluye la fecha de operación que es la fecha en la que se ha realizado el servicio o entregado el producto. La fecha de la factura ha de ser la fecha en que se emite la factura.
Realmente, durante muchos años se ha tratado el documento "factura" en los programas como una ficha más con toda la libertad, pero eso ya ha pasado a la historia, ahora una factura es un documento con muchas restricciones. Esto, por supuesto, provoca algunas "charlas" con los usuarios que están acostumbrados al libre albedrio respecto a las facturas, pero en el momento que la Agencia tributaria ha puesto en el punto de mira de la responsabilidad a la empresa que "desarrolla" el software, ahí ya ha cambiado la cosa, ahora hay que ir con mucho cuidado de lo que se deja hacer con una factura. Recordemos que una factura es un documento oficial que se emite desde nuestros programas y ha de cumplir el reglamento de dicho documento.
Otra cosa es que nos guste más o menos, pero eso ya es otro debate...
Salud!

Factura y libre albedrío. Ni Schopenhauer lo habría calculado
Voy a ver si digo una burrada. Con el sistema Si VF casi podemos hacer que el usuario haga lo que quiera con el programa. Lo que se mande va a ser responsabilidad suya en tanto en cuanto estaría enviando datos que contradicen lo reglamentado. ¿ Responsabilidad del programa aquí ? Pues no lo sé

En todo caso muy buenas y necesarias tus apreciaciones.
Esto en _ puede provocar revoluciones en algunas empresas: Reorganización, quizás ahora usar albaranes y facturar a final de mes, más empleados, advertir a los clientes. Sólo sé que esto, como las películas, no es apto para cardíacos

Posted: **Thu Oct 10, 2024 8:55 am**

Garbi,

Tengo una consulta que me ha preguntado el jefe para todos:
Si montamos el sistema Veri*Factu lo que es la programación de los programas actuales que tenemos de facturación ( en total son 4) por que nuestro trabajo principal es otro, no hay que controlar que no se puedan modificar facturas, registro de las modificaciones de facturas,etc ¿Correcto?

No sé qué responsabilidad vamos a tener, pero ya me imagino yo que en cuanto empiecen a llegar a Sede agencia errores nos vamos a enterar.
Dicho en román paladino: Antes de que un registro de factura sea emitido (generado y enviado) debemos asegurarnos de que reúne los requisitos de orden numeral, fecha y hora, que el cliente tiene un nif valido, que.... etc..

Evidentemente es mi opinión y puedo estar equivocado

Posted: **Thu Oct 10, 2024 2:29 pm**

Hola de nuevo,
Victor o Paquito tenéis algún xml correcto para poder comprobar que la conexión es correcta y el resultado que me envía también.
Si no queréis que use datos vuestros en los datos de emisor y cif poner xxxx y cliente y ya pongo yo datos reales para hacer la prueba. (muy lógico por otra parte)

Muchas gracias por vuestro apoyo y ayuda.

P.D. Victor, aunque estamos a una hora y media si que podríamos organizar algo.

Posted: **Fri Oct 11, 2024 8:51 am**

Garbi wrote:Hola de nuevo,
Victor o Paquito tenéis algún xml correcto para poder comprobar que la conexión es correcta y el resultado que me envía también.
Si no queréis que use datos vuestros en los datos de emisor y cif poner xxxx y cliente y ya pongo yo datos reales para hacer la prueba. (muy lógico por otra parte)

Muchas gracias por vuestro apoyo y ayuda.

P.D. Victor, aunque estamos a una hora y media si que podríamos organizar algo.

Yo hice la prueba con esto que me bajé de las especificaciones de hacienda: https://www.agenciatributaria.es/static ... istros.pdf
Le puse datos reales de CIF y me lo aceptó, por supuesto con los errores que tiene este documento a nivel de huella, etc... pero la comunicación fue correcta.

Garbi, una hora y media es un paseo.

Code: Select all | Expand

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:sum="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd"
    xmlns:sum1="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd"
    xmlns:xd="http://www.w3.org/2000/09/xmldsig#">
    <soapenv:Header />
    <soapenv:Body>
        <sum:RegFactuSistemaFacturacion>
            <sum1:Cabecera>
                <sum1:ObligadoEmision>
                    <sum1:NombreRazon>NOMBREEMPRESA</sum1:NombreRazon>
                    <sum1:NIF>CIFEMPRESA</sum1:NIF>
                </sum1:ObligadoEmision>
            </sum1:Cabecera>
            <sum:RegistroFactura>
                <sum:RegistroAlta>
                    <sum1:IDVersion>1.0</sum1:IDVersion>
                    <sum1:IDFactura>
                        <sum1:IDEmisorFactura>CIFEMISORA</sum1:IDEmisorFactura>
                        <sum1:NumSerieFactura>2024/0001</sum1:NumSerieFactura>
                        <sum1:FechaExpedicionFactura>13-09-2024</sum1:FechaExpedicionFactura>
                    </sum1:IDFactura>
                    <sum1:NombreRazonEmisor>NOMBREEMPRESAEMISORA</sum1:NombreRazonEmisor>
                    <sum1:TipoFactura>F1</sum1:TipoFactura>
                    <sum1:DescripcionOperacion>Factura de Venta ordinaria</sum1:DescripcionOperacion>
                    <sum1:Destinatarios>
                        <sum1:IDDestinatario>
                            <sum1:NombreRazon>NOMBRECLIENTE</sum1:NombreRazon>
                            <sum1:NIF>CIFCLIENTE</sum1:NIF>
                        </sum1:IDDestinatario>
                    </sum1:Destinatarios>
                    <sum1:Desglose>
                        <sum1:DetalleDesglose>
                            <sum1:ClaveRegimen>01</sum1:ClaveRegimen>
                            <sum1:CalificacionOperacion>S1</sum1:CalificacionOperacion>
                            <sum1:TipoImpositivo>4</sum1:TipoImpositivo>
                            <sum1:BaseImponibleOimporteNoSujeto>10</sum1:BaseImponibleOimporteNoSujeto>
                            <sum1:CuotaRepercutida>0.4</sum1:CuotaRepercutida>
                        </sum1:DetalleDesglose>
                        <sum1:DetalleDesglose>
                            <sum1:ClaveRegimen>01</sum1:ClaveRegimen>
                            <sum1:CalificacionOperacion>S1</sum1:CalificacionOperacion>
                            <sum1:TipoImpositivo>21</sum1:TipoImpositivo>
                            <sum1:BaseImponibleOimporteNoSujeto>100</sum1:BaseImponibleOimporteNoSujeto>
                            <sum1:CuotaRepercutida>21</sum1:CuotaRepercutida>
                        </sum1:DetalleDesglose>
                    </sum1:Desglose>
                    <sum1:CuotaTotal>21.4</sum1:CuotaTotal>
                    <sum1:ImporteTotal>131.4</sum1:ImporteTotal>
                    <sum1:Encadenamiento>
                        <sum1:RegistroAnterior>
                            <sum1:IDEmisorFactura>CIFEMISOR</sum1:IDEmisorFactura>
                            <sum1:NumSerieFactura>2024/0002</sum1:NumSerieFactura>
                            <sum1:FechaExpedicionFactura>13-09-2024</sum1:FechaExpedicionFactura>
                            <sum1:Huella>HuellaRegistroAnterior</sum1:Huella>
                        </sum1:RegistroAnterior>
                    </sum1:Encadenamiento>
                    <sum1:SistemaInformatico>
                        <sum1:NombreRazon>NOMBREEMPRESASOFTWARE</sum1:NombreRazon>
                        <sum1:NIF>CIFEMPRESASOFTWARE</sum1:NIF>
                        <sum1:NombreSistemaInformatico>NOMBREPROGRAMA</sum1:NombreSistemaInformatico>
                        <sum1:IdSistemaInformatico>77</sum1:IdSistemaInformatico>
                        <sum1:Version>VERSIONPROGRAMA</sum1:Version>
                        <sum1:NumeroInstalacion>383</sum1:NumeroInstalacion>
                        <sum1:TipoUsoPosibleSoloVerifactu>N</sum1:TipoUsoPosibleSoloVerifactu>
                        <sum1:TipoUsoPosibleMultiOT>S</sum1:TipoUsoPosibleMultiOT>
                        <sum1:IndicadorMultiplesOT>S</sum1:IndicadorMultiplesOT>
                    </sum1:SistemaInformatico>
                    <sum1:FechaHoraHusoGenRegistro>2024-09-13T19:20:30+01:00</sum1:FechaHoraHusoGenRegistro>
                    <sum1:TipoHuella>01</sum1:TipoHuella>
                    <sum1:Huella>Huella</sum1:Huella>
                </sum:RegistroAlta>
            </sum:RegistroFactura>
        </sum:RegFactuSistemaFacturacion>
    </soapenv:Body>
</soapenv:Envelope>

Posted: **Fri Oct 11, 2024 8:54 am**

tenemos una cita!!!!

https://www.agenciatributaria.es/AEAT.d ... _DIT.shtml

vamos haciendo una lista de preguntas que luego se nos quedan en el tintero y nos las preguntamos entre nosotros...

La mía sería la siguiente: Cuando pasarán los documentos de borrador a versión 1 para empezar a picar tecla? ( aunque la respuesta ya me la se )

Posted: **Fri Oct 11, 2024 9:37 am**

VictorCasajuana wrote: Cuando pasarán los documentos de borrador a versión 1 para empezar a picar tecla? ( aunque la respuesta ya me la se )

Respuesta: ¡ Cuando se pueda !
Siempre es así ¿ Por qué habría de cambiar esta vez la respuesta ?

Posted: **Fri Oct 11, 2024 9:37 am**

La prueba me da como resultado este fichero de salida :

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.webapp.WebApp.handleRequest(WebApp.java:5096) at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.handleRequest(DynamicVirtualHost.java:328) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1047) 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) ... 33 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) ... 35 more </callstack>
</detail>
</env:Fault>
</env:Body>
</env:Envelope>

¿Eso quiere que se ha conectado pero que hay fallos?

Madre mia que verde estoy en esto.

La mía sería la siguiente: Cuando pasarán los documentos de borrador a versión 1 para empezar a picar tecla? ( aunque la respuesta ya me la se )

Si, ¿ cual es la respuesta ? y además supongo que dirán más cosas que podrán dejar claro si todo el mundo podrá adherirse o harán prorrogas. O como me pregunto el otro día una amigo que solo hace 12 facturas al año ¿Sacaran algo para poder hacer esas facturas sin tener que comprar un programa para hacerlas y si es una CB que no tiene certificado digital que pasa? y me quede con cara de que me dijeran que hemos llegado a Marte.

Y si la respuesta es la que dice Paquito, "que cuando se pueda", entonces cuando contamos 9 meses o ya es independiente el tiempo, ¿es el 1 de julio de 2025 si o si?

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.

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

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