Codigos QR
 

Estoy trabajando con los códigos QR y comparando los ejemplos que pone la AEAT con los que obtengo con distintos componentes Delphi(DelphiZXingQRCodeEx y otros). Sólo he conseguido obtener exactamente el mismo con FastReport. Todos los demás componentes que he probado muestran códigos gráficamente distintos aunque su lectura es correcta.
¿Sabéis de algún componente que cree el código tal y como nos piden?





Gracias de antemano y buenas vacaciones a todos... también a los que estamos trabajando.

Flujo
 

Muy buenas a todos,

Pensando en el flujo (y reflujo)
¿ Como lo hariais vosotros ?
Se imprime la factura y va a la cola. Cuando llegue el tiempo de espera se manda junto con las pendientes.
¿ Pero qué hacer si hay algun error que requiere enviar de nuevo el alta ? ¿ Se haria a traves de otro proceso que tambien generaria cola de envio ?

A ver si alguien lo tiene mas claro que yo

Gracias

Lo único que piden es que el control de errores sea mínimo el tipo M y las medidas. Lo de Gráficamente distinto no sé a qué te refieres pero si es por que has dejado el tipo por defecto de cada componente puede que el control de errores sea distinto y te va a salir un gráfico distinto, mientras no sea tipo L(low) será aceptado.
Por otro lado, según el procesador que tenga el equipo, un tipo de control de errores más alto que el M, necesita más recursos y te puede ralentizar la generación

Aún no han indicado el.procedimiento de reenvío, solos me ocurren una lógica según va avanzando el proyecto y es que si un registro es rechazado tendras que mandar la corrección (según el tipo de error) encadenada con el último generado NO con en anterior al registro rechazado, puesto que se rompería el encadenamiento.
De todas formas habrá que esperar a ver los detalles, pueden optar por otras opciones: reenvío con uncadenamiebto eapecial, sin encadenar o incluso enviar para tratarlos a otro servicio RESP. A ver que nos cuentan en los detalles técnicos. De momento yo he desarrollado todo según la opción que he puesto como más lógica ya que al tener que volver a generar el registro hay que seguir la secuencia
Otra cosa es que tengas incidencia en el emvio y no sea un rechazo por un registro erróneo.

También ten ecuenta que han metido una variable que es el la referencia del rechazo, la cual tendrás que hacer alusión a esa referencia en algun nodoen el envio del registro que reenvías, quizás con eso no necesite encadenamiento, y con lo que están tardando me espero bastantes modificaciones, si te das cuenta , en los webinars nos cuentan que las motivaciones son para mejorar y facilitar, pero solo facilitan para ellos, para que tengan más automatizados los controles de errores, a nosotros nos van complicando, está todo por ver

No deberías crear otra cola para estos casos, la cola debe ser única ya que todos los registros, sin excepción, tienen que estar encadenados siguiendo su fecha de generación.

En el documento de Validaciones y Errores tienes la respuesta

"4.4 Subsanación de errores
Solo podrá llevarse a cabo una subsanación cuando no se trate de una causa que exija la emisión de una factura rectificativa (u otro mecanismo contemplado en el Reglamento de Facturación).

Este mecanismo se empleará para subsanar datos en cualquiera de los siguientes casos:

- Errores admisibles (registro de facturación aceptado –con errores admisibles– por la AEAT), salvo las excepciones previstas en el apartado que explica el tratamiento de los errores admisibles.
- Errores no admisibles (registro de facturación rechazado por la AEAT).
- Dato incorrecto detectado posteriormente por el obligado a expedir factura (registro de facturación remitido y aceptado sin errores por la AEAT).

Para llevar a cabo la subsanación, será necesaria la remisión de un nuevo registro de facturación (con el mismo identificador de factura del registro de facturación que se quiere subsanar) por cada uno de los registros con datos a subsanar, con la combinación de valores de campos que proceda según el caso (ver en el anexo los cuadros de operativas de alta y anulación admisibles)."

Sólo en el caso de que la comunicación no se haya establecido correctamente con la Aeat y no se haya podido enviar el mensaje, deberías volver a reintentar el envío, tal cual estaba, las veces necesarias hasta conseguir respuesta.

Es verdad, pero insisto en que es mejor esperar antes de meter mucha historia a las correcciones, en el Sii puedes corregir directamente en la web de la AEAT, así que no me extrañaría que hubiera un servicio equivalente

Rectificativa
 

Creéis factible generar una rectificativa de una factura en un SIF distinto al que se produjo? El XM lo genero bien, pero me quedaria la duda de que comprueben que esa factura no se ha producido en el mismo SIF.
Esto puede ser necesario por que un cliente devuelve mercancía en otro punto distinto de donde la adquirió.

Una consulta relacionada ya la hice en su momento a la Aeat y dejaron claro que, cada obligado tributario puede tener distintos SIFs donde cada uno lleva su propio encadenamiento, al final, ellos ven desde su lado la relación NifObligado-NúmSerieFactura-FechaExpedición como una clave única que se debe mantener independientemente de los SIFs que tenga el obligado. Por ello, se podría rectificar e incluso anular facturas desde un SIF distinto al que las creó.

Gracias, lo aplicaré así

Hola a tod@s.

Como creo que también habrá que darle solución al tema NO VeriFactu (para no quedarme sin clientes) estoy dándole vueltas a la firma del registro que se guarda en la tabla en ese caso. ¿Alguien tiene claro cómo va este tema?

Gracias y un saludo.

Yo creo que el firmado será similar al de TBAI.
Aquí al principio de este hilo, alguien ya ha hecho algo de firmado:
https://www.clubdelphi.com/foros/sho...92&postcount=2

Y si te quieres entretener, puedes echarle un vistazo a los código de TBAI. Hay con diferentes componentes y básicamente al final es firmar un XML:
https://www.clubdelphi.com/foros/sho...31&postcount=2

Gracias Germán.

He visto el primer post que comentas, según parece es una dll que algún amable forero ha montado para firmar un XML pero estoy un poco despistado con esto. ¿Habrá que firmar y guardar el XML de alguna manera? o lo que se firma es algún campo del registro... no sé.

Echaré un vistazo al hilo de TicketBAI a ver si me aclara algo.

Saludos.

Creo que ya se ha discutido, pero diría que firmas un trozo del XML y esa firma se añade en una sección del propio XML.
Opcionalmente una parte de esa firma puede ir al encadenamiento de la siguiente (eso refuerza que una vez encadenadas no se puedan modificar)

(lo digo de memoria...)

Técnicamente, se puede (aunque no se debe) modificar registros aunque sigan encadenados y firmados cada uno: solo hace falta volver a firmar y encadenar todos los registros empezando por el más antiguo. Y hacer lo mismo con el registro de los eventos (escribiéndolo ya me parece que no está nada legal:(; pero técnicamente se puede hacer si uno tiene acceso a la clave de firma.)

Lo que permite garantizar que no haya modificaciones sería poner una marca de tiempo (timestamp) al mismo tiempo que se firme.
Evidentemente, en este caso depende de la calidad de la marca de tiempo (si el servidor TSA RFC3161 lo controle el mismo que él que opera el SIF, no sería mucha garantia:rolleyes:.)

Otra manera equivalente es depositar alguna huella del último registro (o del último registro de eventos, sería equivalente) en algún notario que le pondrá sello de tiempo.

Certificados SIF
 

Buenas,


Resulta que leyendo esta mañana me encuentro con una noticia de google en la que se expresa la necesidad de que cada sistema de facturacion contenga un certificado expedido por la administracion para poder facturar. Yo no sabia nada de eso y me gustaria saber si alguien ha leido algo al respecto porque es la primera noticia que tengo ya que pensaba que con la declaracion responsable ibamos que nos la pelabamos.



La noticia es:


https://www.autonomosyemprendedor.es...107037982.html


Un saludo y felices vacaciones al que pueda disfrutar o esté disfrutando ya de ellas.

Efectivamente, yo había leido esa noticia pero no sé si ese medio tendrá más información que nosotros por lo que lo pongo en cuarentena hasta que no se publique la normativa definitiva.


Saludos.

(he subrayado yo.)
¿Dónde está escrito que hay certificados que deben ser expedido por la administración?

Hasta ahora, en España todo se ha basado en la necesidad de cumplir unas normas, es decir, software responsable. El «certificado» será la declaración responsable, tal como pensabas.

Por ninguna parte está descrito un «proceso de certificación» por parte de la administración; y tampoco por delegación de la administración (que puede ser más lógico o más verosímil). Hasta ahora Hacienda cuenta con inspectores, no con certificadores, y no es el mismo oficio.

Los de autonomosyenpresas la lían con este tipo de noticias, ya lo hicieron hace unos meses
Ni caso.
De momento la certificación del programa pasará por la declaración responsable de que cumple con la normativa. No sé si darán algún identificador para que lo incluyas en los xmls. Pero no habrá un certificado digital no nada de eso. Lo que tendrás que tener un botón de acceso rápido para ver la declaración responsable etc.
Otra cosa es que para identificarte en el envio sí que mecesitaras algún tipo de identificación si no se envia por un tercero, y seguramente sea el de empresa o autónomo.

Hola compañeros, una pequeña duda, voy un poco perdido con el tema del envío de la petición, estoy empleando SOAP y no consigo conectarme, sabéis si se tiene que dar de alta a algún servicio , y también si hay un entorno de pruebas? Gracias

Que yo sepa todavía no hay ningún servidor de pruebas operativo.


Saludos.

¿Entonces todavía no se pueden hacer envíos o es solo es el servidor de pruebas que no esta operativo?

Gracias!

No se pueden hacer envíos de pruebas y mucho menos en producción. Todavía tienen que acabar de desarrollar la normativa técnica.

Bueno, con el tema de los certificados, creo que TODO aquel que quiera emitir una factura va a necesitar tener un certificado digital expedido por algun organismo de certificacion oficial, ya que si opta por VERI*FACTU, para subir la factura a la web va a necesitar un certificado de empresa, y si opta por NO VERI*FACTU va a tener que usar un certificado digital para firmar los XML y si por aquello de que como usa el SII no se le aplicara VERI*FACTU o NO VERI*FACTU pues resulta que para subir al SII ya tiene un certificado digital.
Pienso que habrá que ir transmitiendo a TODOS los clientes que dentro de nada, si no tienen ya certificado digital, lo van a necesitar para poder seguir facturando. Vamos esto es lo que yo he entendido desde el principio

Depende de como lo plantees
Puedes tener los servicios de envíos además dentro servicios a través de un Resp en la nube con un certificado de terceros.
De todas formas hay que esperar a la publicación del desarrollo, ya que podemos llevarnos alguna sorpresa y que también admitan el certificado de dispositivo, que es más seguro, a mi me parece que lo de los certificados personales y de Empresas puede ser un problema de seguridad bastante gordo y me extrañaría que no dieran otras opciones.

Depende de como lo plantees
Puedes tener los servicios de envíos, además de otros servicios, a través de un Resp en la nube con un certificado de terceros.
De todas formas hay que esperar a la publicación del desarrollo, ya que podemos llevarnos alguna sorpresa y que también admitan el certificado de dispositivo, que es más seguro, a mi me parece que lo de los certificados personales y de Empresas puede ser un problema de seguridad bastante gordo y me extrañaría que no dieran otras opciones.

Certificado de firma de código
 

Buenas,

¿Alguien ha probado los certificados de firma de código de Certum?

https://www.sslmentor.es/certum/certumcodecloud

Veo que el precio es significativamente menor que los habituales (Sectigo, etc.) y me caduca el que tengo en breve.

Sacado de la web SSLMENTOR:
La firma de archivos se realiza cuando se instala el programa SimplySign Desktop en la estación (PC, Mac), que emula la conexión entre una tarjeta criptográfica física y un lector de tarjetas con un certificado ubicado en la nube. Utilizando la aplicación móvil SimplySign, se genera un token de 6 dígitos, lo que hace que el certificado esté disponible para firmar durante aproximadamente 2 horas. Luego, puedes firmar archivos ilimitados en la estación, por ejemplo, utilizando la aplicación Microsoft SignTool como estás acostumbrado. Después de la expiración, es necesario ingresar un nuevo token desde el teléfono móvil (funcionalmente, es similar a la aplicación Google Authenticator, por ejemplo). La aplicación SimplySign y SimplySign Desktop están disponibles de forma gratuita.

Saludos,
David M.

A falta de que exista un entorno de pruebas, aquí dejo un ejemplo de un archivo xml que he confeccionado, partiendo de la base de los que estamos generando en nuestra aplicación para Ticket Bai, pero con la estructura de lo que está publicado hasta ahora por la AEAT, para que a alguien le siga de noción, y también para preguntar si alguien sabe qué hay que poner al principio en lugar de <T:TicketBai xmlns:T="urn:ticketbai:emision"> .

Está sin firmar y los datos son de prueba, obviamente

Yo veo que el xml, hasta hoy, debería de tener esa otra estructura...

Hasta donde yo llego

Hola algunos nodos han cambiado en la ultima version

Clarificar mensajes XML obtenidos de THTTPRIO
 

Un fragmento de los mensajes que se capturan en "OnBeforeExecute" del "THTTPRIO" es del estilo a este:

Muy engorroso de leer. ¿Alguien conoce alguna forma de eliminar la parte "sobrante" de las etiquetas?
Es decir:



Gracias de antemano por vuestro tiempo.

supongo que una forma seria capturar el string completo en una variable y usar la función stringreplace(stringcapturado,cadenassustituir,'',
.rfReplaceAll) con cada cadena que quieras eliminar

Siguen los lios
 

Despues de tanto tiempo con la ley Crea y crece y la Ley antifraude siguen mezclando ambas y metiendo Verifactu y Factura eletrónica en una batidora:
https://www.externalix.com/retraso-f...a-obligatoria/

Ya sabes, "en río revuelto... ganancia de pescadores".
Así que lo revuelven todo, confunden a la gente y así "pescan" a algunos.

Pufffffffffffffff.... pues anda que están informados estos...


Entre los que no se enteran y divulgan información errónea y los que quieren pescar engañando a las empresas y diciéndoles que ya tienen sus sistemas preparados para estas "ñapas" vamos aviados.


Saludos.

Me respondo a mí mismo, funciona perfectamente para firmar aplicaciones. En lugar del dispositivo físico al que obligan últimamente, te descargas una app en el móvil donde te generan un token cuando vayas a realizar la firma y deja la sesión iniciada durante 2 horas para firmar archivos de forma ilimitada.
Tenedlo en cuenta, cuesta menos de 100€ al año en la modalidad de 3 años.

Saludos,
David M.

Divagaciones
 

Hola a tod@s.


Estoy dándole vueltas al tema de VeriFactu/No Verifactu y (si no me equivoco) parece que en los programas "No VeriFactu" hay que guardar la factura en un fichero XML firmado para que en caso de requerimiento se puedan enviar del tirón. Yo estaba preparando el tema VeriFactu con los componentes SOAP que generan y envían el fichero pero estoy viendo que si no se va a enviar por ser "No VeriFactu" no tengo forma de generar el fichero XML para firmarlo y guardarlo.


Mi pregunta es ¿hay alguna opción de generar el fichero XML con el componente y sin enviarlo o hay que crear el XML "a pelo" para poder firmarlo y guardarlo?


Gracias y un saludo.

Si utilizas los componentes SOAP de delphi (THTTPRIO), puedes hacer la 'trampa' de en el evento BeforeExecute, guardar el XML y luego cancelar.
Algo así:

Código Delphi [-]
    if(SaveDialog.Execute) then
    begin
      ss:=TFileStream.Create(SaveDialog.FileName, fmCreate);
      SOAPRequest.Position := 0;
      ss.CopyFrom(SOAPRequest,SOAPRequest.Size);
      ss.Free;
      SOAPRequest.Position := 0;
    end;
    raise Exception.Create('XML exportado');

Donde ss es un TFileStream
A nosotros nos funciona

Si, eso ya lo uso para el SII pero para poder interceptar ese evento tienes que enviar mediante el componente (que no es la idea).



Gracias y un saludo.

Nuevas publicaciones
 

Han publicado detalle de la Firma Electrónica, del QR y del Hash

Se pueden ver en:
https://www.agenciatributaria.es/AEA...ERI_FACTU.html

Un saludo.