|
Los ejemplos de nuevo
1 Archivos Adjunto(s)
Os dejo aquí los ejemplos de ficheros VERIFACTU vs FACTURAE, que le he cambiado algun error a los ficheros de facturae equivalentes a los de verifactu
y aqui os dejo un validador y visualizador de la facturae https://face.gob.es/es/facturas/vali...lizar-facturas |
Cita:
|
Cita:
No había visto esto. Gracias de nuevo. ^\||/ |
Hola a todos.
Estoy ya implementando con wsdl V0.11.5 y me encuentro con que al importar la wsdl correspondiente me aparece la definicion del dato FFechaHoraHusoGenRegistro: TXSDateTime; Al utilizarlo segun la definicion de Soap.XSBuiltIns me genera un valor 2024-04-10T11:38:56.000Z , cosa que se separa ligeramente del formato indicado. Lo he resuelto incluyendo al principio de la unit SistemaFacturacion una redefinicion: type TXSDateTime=string; y el valor lo he formateado adecuadamente segun el formato indicado: AAAA-MM-DDThh:nn:ss+0x:00 la x varia entre 0, 1 2 segun corresponda. En principio está resuelto para la generacion del xml. La pregunta es ¿esto solo me ha ocurrido a mi, o es que he utilizado un importacion incorrecta del wsdl? He importado (desde Studio 10.1 Berlin) https://prewww2.aeat.es/static_files...cturacion.wsdl y utilizo la opcion Porcess only WSDL Binding extensions por the SOAP 1.2 Protocol |
Formato fecha hora con huso horario
Cita:
Al importarlo en Embarcadero Studio Enterprise con el compilador C++ builder 11 no genera ese mismo nombre de campo. La importación al framework del wsdl se hizo en modo automático. De todos modos, no creo que sea difícil hacer un conversor a string. Si usa sql server para generar datos y por si le sirve de ayuda le paso una simple instrucción : print SubString(convert(varchar(14),getdate(),112),7,2) + '-' + SubString(convert(varchar(14),getdate(),112),5,2) + '-' + SubString(convert(varchar(14),getdate(),112),1,4)+' ' + SubString(convert(varchar(14),getdate(),114),1,8)+'+0'+TRIM(STR(datediff(hour,getutcdate(),getdate() )))+':00' Le generará el diferencial transformado entre la fecha utc y la fecha real de su sistema. Todo en uno ! Saludos. |
Cita:
|
Sí, si eso lo tengo codificado, sin problemas:
Y HusoHorario me devuelve ese diferencial que indicas, solo que yo devuelvo en HusoHorario '+00:00' '+01:00' o '+02:00' Yo realmente preguntaba si al importar el wsdl el dato FechaHoraHusoGenRegistro se habia importado como TXSDateTime en cuyo caso la asignacion al dato sería algo así: ....FechaHoraHusoGenRegistro:=DateTimeToXSDateTime(Fecha); --> aaaa-mm-ddThh:nn:ss:ddddZ p pero no sale el HusoHorario por ello, he redefinido dicho tipo como un string (podría ser como un dato TextMax25Type o similar) con la redefinicion planteada le asigno ....FechaHoraHusoGenRegistro:=DTHuso(Fecha); --> aaaa-mm-ddThh:nn:ss+0x:00 (normalmente la fecha será el timedateactual, now() pero quería preparar una funcion) |
Fecha texto
Cita:
De todas formas personalmente trato ese dato como un texto. Actualmente estoy cambiando el modelo creado con el wsdl a un modelo manual, "todo hecho a pelo". A menos que vea algo insalvable lo dejaré manual. Me da mucha mas libertad para actuar y para las actualizaciones. Ayer tomé la decisión y ya casi lo tengo terminado. Voy a probar de una manera local y ver que genera. (Respetando el código actual por si acaso):D Un consejo si me lo permite, preste mucha atención a la fechahora actual y la la fechahora dtc. No vaya a sacar esto de cada terminal si tiene un modelo de soft centralizado. Podría ocurrir que si una máquina no está en hora generaría un registro que no esté ordenado por fechahora y eso daría errores en la AEAT. Mejor dejar que el sistema centralizado ofrezca tales datos si es que así lo ha concebido. Un saludo. |
Recordáis si en el webinar dijeron algo, de nuevo, de tener que recomprobar los encadenamientos de los últimos 5 registros al generar cada factura? No recuerdo que lo repitieran no?. Es que es un lastre.
|
Buenas,
Los que trabajáis con el programa en local tenéis pensado hacer algún tipo de control sobre el certificado? Estado del mismo? Fecha de caducidad? |
Cita:
Pues dependerá de lo que contesten los de verifactu a esto :) " Hola Se sabe ya si cuando una empresa que no haga envíos, tenga algún problema con el certificado, por temas de caducidad, técnicos , etc.. tiene que cerrar la tienda y enviar a los trabajadores a casa , hasta solucionar el problema técnico o puede seguir haciendo tiquets sin firmar hasta la solución? Muchas Gracias. Saludos " |
Cita:
Muchas gracias por la indicación, CarlosR, pero de momento todos los clientes utilizan un servidor centralizado al que se conectan por escritorio remoto y cada uno , en su perfil ejecuta la aplicacion. Todos tienen la misma hora del sistema, que es la del servidor, y se actualiza segun el huso horario actual. (horario verano/ horario invierno) |
Cita:
Lo que pasa es que lo tengo en php, instalado en local, y un servicio de php corriendo en el mismo ordenador al que le hago la llamada con curl y me devuelve todo lo que quiera del contenido del certififado, fecha caducidad, empresa, nombre e incluso cuando está cercana la fecha de caducidad mando un email al que creo el certificado (asesoria...)para avisarlo, ya que el mismo certificado contiene el email. Lo que hay que tener en cuenta es que si pides de nuevo el certificado el que tengas instalado ya no vale, y puede haber un periodo que no puedas usarlo pero se quedarán los envíos en standby. En sitios muy delicados tienen 2 certificados para ticketbai, uno de izempe y otro normal con fechas distintas y van cambiando cuando se acerca la fecha o intenta con uno y si no con el otro |
Cita:
Respuesta de la AEAT Buenos días: El desarrollo normativo(*) a que se refiere su consulta aún no está completado y se encuentra en fase de estudio y elaboración definitiva. Por ello, sería aventurado adelantarle alguna respuesta con el riesgo de que esta cambiara tras la publicación oficial en el BOE de la orden ministerial y en la Sede electrónica de la AEAT de la documentación que completará dicha orden. Además, es muy probable que la lectura de dicha documentación oficial pudiera responder total o parcialmente su consulta. Por lo tanto, le emplazamos a que espere a dicho momento en el que podrá disponer de toda la información oficial necesaria. Si entonces aún siguiera teniendo dudas, por favor, remítanoslas por esta misma vía. En cualquier caso, ya hemos tomado nota de sus consultas y se tendrán en cuenta para su estudio y, en su caso, incorporación a la documentación final del proyecto. Muchas gracias por contactar con la AEAT. (*) Artículos 29.2.j) y 201 bis de la Ley 58/2003, de 17 de diciembre, General Tributaria, y Real Decreto 1007/2023, de 5 de diciembre, por el que se aprueba el Reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación. La orden ministerial que desarrollará el RD 1007/2023, publicada en enero de 2024 en el portal del Ministerio de Hacienda para dar cumplimiento a su trámite de audiencia e información pública, está en fase de estudio y elaboración definitiva, así como la documentación que completará dicha orden y que estará disponible en la Sede electrónica de la AEAT tras la aprobación y publicación oficial de la orden ministerial. Atentamente, Atención al Usuario Departamento de Informática Tributaria Email: [email protected] |
No creo que den un periodo de gracia en el que puedas seguir enviando con el certificado caducado o revocado, eso es difícil de controlar correctamente. Dejarán un periodo de gracia sin envíos y cuando lo soluciones envias marcando (I)ncidencia=S y si detectan que se repite mucho en el tiempo te enviarán avisos.
|
Cita:
No , si yo les he preguntado para los usuarios que decidan no enviar por el motivo que sea , funcionamiento NO*VERIFACTU , hay que darles un poco de guerra por mail , que comparado con la guerra que nos dan a nosotros no es nada. :) A ver que nos cuentan al final... |
caducidad del certificado
Buenas, señores
Este procedimiento en .net devuelve la fecha de caducidad y el nombre y dni del titular de un certificado pfx para poder dar el aviso pertinente antes de que dicho certificado caduque. La renovacion creo que se puede solicitar dos meses antes de su caducidad ( por si a alguien le viene bien ) Código:
Imports System.Security.Cryptography.X509Certificates |
Cita:
|
Certificado
Cita:
Pregunto, ¿ no le sería mas fácil tener una tabla en donde tienes el certificado, la fecha de expiración, el número de serie y el pass y todo ello cifrado ? Y del registro de certificado en vigencia hacer uso para la certificación del xml. Con el campo fecha expiración ya podrá tener el control de si está activo o no. Salvo que lo revoquen antes. Otra cuestión es como se certifica el xml. Tengo dudas sobre esto. Si está puesto en ello le agradecería un par de consejos. Supongo que se hará igual que la factura electrónica. Estoy en esa misma tesitura, no tengo claro si al final cerraré mi soft a solo veri*factu o lo dejaré dual. Si lo dejo para los dos tendré que tener todos los requisitos de no veri*factu. Lo decidiré el último día. Hay que hablar con abogados que sepan lo que se hacen. Tendrá que esperar a que la AEAT saque la documentación. Para ellos es un trámite nada mas, para cualquier desarrollador es un rompecabezas. Ya no solo por el código sino también por las actualizaciones. Un saludo. |
Cita:
lo hago así por que me aseguro que el contenido es correcto, pero si se hace metodicamente, como dices, también está perfecto. Lo que yo hago es: -1 Consulto el fichero del certificado y extraigo los datos que necesito de comprobación: fecha caducidad, busco el nif, email... -2. (que esto si lo podrias hacer por que en la tabla no puedes verlo) Para asegurarme que no está revocado hago una consulta de mi nif al webservice de la aeat de consultas de nifs, que me devolveria el cliente y nombre, sí es todo correcto, o el estado del certificado, si está revocado o caducado. Cita:
pero hay otros campos que hay que tener en cuenta en las firmas que no van a coincidir por ejemplo la signPolicy(Política de firma) que contiene 3 campos : -Name -url -digest(hash) que en facturae son: Código:
"name" => "Politica de Firma FacturaE v3.1",Cita:
|
Firma
Cita:
Respuesta : Buen consejo sí, pero los letrados son quienes te defenderán ante posibles demandas. Hay bufetes especializados en el tratamiento de datos. Y que el desarrollador ponga su patrimonio a disposición de algún cliente, no mola. Un desarrollador no puede garantizar que nadie pueda dañar los datos de un cliente. Aunque estén en posesión del desarrollador. Por supuesto que hay que echar mano de asesores fiscales y a poder ser varios. Gracias por tu inestimable apoyo. Estaremos vigilantes con las especificaciones de la firma. Un saludo. |
Gracias por las repuestas.
Voy a intentar a ver si consigo alguna forma para recuperar los datos del cerficado y poder validarlo... |
Creo que si tiene clientes en SII y clientes que no, va a haber que crear el programa con una opción de Verifactu = SI o Verifactu = No, cumpliendo el reglamento según el caso. Yo pensaba solamente llevar verifactu pero no puedo obligar a los del SII a trabajar como verifactu. No sé si estoy equivocado pero con todo lo que he leído creo que es la conclusión que he llegado.
|
muchas gracias
|
Cita:
Verifactu(con o sin multiempresq) No verifactu (com o sin muñtiempresa) SIi |
Pues realmente es todo un lio!!!
De hecho, para aclarar un poco el tema con los clientes que utilizen mi SIF voy a hacer lo siguiente. Clientes acogidos al SII, en la factura poner una mención como "Facturación acogida al SII" Resto de clientes, obligatorio sistema VERI*FACTU Si la factura a imprimir no está en SII o no he recibido la respuesta afirmativa de cada registro en VERI*FACTU, no se imprime la factura. Posibilidad de FacturaBORRADOR, FacturaPROFORMA... Los clientes que NO quieran acogerse a una de esas 2 opciones, no les llevaré contrato de mantenimiento ni actualizaciones del software. |
Cita:
La respuesta afirmativa de cada registro...? A que te refieres? Por que el envío te pueden solicitar que acumules varios o esperes cierto tiempo |
Cita:
|
Cita:
|
Cita:
Si están en distintas maquinas corriendo. Si están en la misma ya hay que tener separadas la generación (que eso no lo entiendo muy bien, por que di haces encadenamiento deparado, por que se meten en eso) y en cada registro enviar que está funcionando en un sif multiempresa. A mi me ha tocado tb SII, multiempresa y empresa sola. Todo es un lío de cojones |
Habéis tenido en cuenta que cuando tengáis que regenerar un registro , no os rompa la hilera de comprobaciones que hacéis? Se supone que vais crear de nuevo un registro con una fecha/hora diferente al priginal y vais a encadenar con el último generado, todo esto puede causar incongruencias si a la vez estáis comprobando el numerador de la serie que regenerais.
|
Me estoy liando.
Cuando se trata de una empresa acogida al SII el programa debe de funcionar como "no verifactu", no? (trazabilidad, guardar xmls, log de eventos, etc) Supongo que para este caso en el que la empresa del cliente esta acogida al SII habra que seguir todos los requisitos de un programa no verifactu pero los envios se realizan atraves del SII y asi el software cumpliria con la normativa antifraude teniendo en cuenta que solo los programas verifactu se eximen de guardar los logs,xmls, bla bla bla Si esto es asi,...... bastaria que un cliente dijese que iba ha estar en el SII y que trabajara con nuestro software para obligarnos a tener el modo no verifactu implementado en nuestro software. ¿en que me equivoco?, ya no atino. Demasiada informacion para tan pocas neuronas vivas a estas horas del viernes |
Cita:
Personalmente no lo veo así. 1er caso : La empresa realiza operaciones por un valor mayor a 6 millones de euros por lo que se ha acogido por Ley a SII. (Tambien se pueden acoger otras empresas si así lo solicitan aunque no lleguen a esa cifra de operaciones) Sólo tiene una empresa. Aunque sean varias licencias fiscales. Otro caso sería si forma parte de un grupo de empresas. Si es una empresa acogida al SII queda exenta de las normativas veri*factu y NO veri*factu. Tiene ciertas ventajas con respecto al resto de empresas. Al menos actualmente. 2do caso : La empresa no está en SII y su software SOLO permite veri*factu. En tal caso estará sujeto a las normas de veri*factu. 3er caso : La empresa opta por veri*factu aunque el software permite tanto veri*factu como No veri*factu. En tal caso el software está obligado a cumplir las normas mas restrictivas de NO veri*factu. 4to caso : La empresa forma parte de un grupo de empresas que tienen el software compartido. Si alguna de ellas no está sujeta a SII entonces el software debe cumplir los requisitos de veri*factu o NO veri*factu en función de si se acoge o no a sólo veri*factu o si el software permite las dos modalidades. No sé si me habré dejado algún caso mas, seguro que sí. Pero creo que su caso está circunscrito en alguno de los anteriormente reseñados. De todos modos si lo desea puede ir a la AEAT en la sección de desarrolladores bajo el epígrafe verifactu. Allí hay preguntas y respuestas de las conferencias hechas por la AEAT y asociados. En un PDF se puede ver la combinatoria que puede darse en distintos tipos de empresas. Espero que le haya servido de algo. Un saludo. |
encadenamiento
Cita:
Ojo con las series y tipos de documento. La AEAT quiere llevar un registro ordenado indistintamente de la serie que sea. Solo en cada serie el documento debe llevar un orden de fecha. Pero la fecha de registro, la huella y otras cuestiones de encadenamiento son indistintas de las series. Un saludo. |
Gracias, carlos
|
Cita:
|
Cita:
Si el software tiene las 2 modalidades verifactu y no verifactu o he visto en ningún sitio que tenga que cumplir con las reglas de no verifactu, |
En referencia al tema de clientes acogidos al SII, y la tesitura de aplicar Verifactu o No Verifactu a dichos clientes o al resto de clientes yo tengo una opinión muy clara al respecto.
De ninguna de manera aplicaría No VeriFactu a ningún cliente, esté acogido al SII o no. Esta recomendación no la hago yo, la hacen los responsables del desarrollo de Verifactu. Lo han dicho en la conferencia de hace unos meses, lo han desaconsejado en las respuestas a las preguntas formuladas en la Aeat, los gabinetes de asesoramiento para la implantación de Verifactu te dicen que es imposible que puedas cumplir sin estar al filo de la sanción ya que el registro de eventos que han propuesto es indescifrable y por no decir el problemón que puedes tener por perder los registros de facturación de los últimos 4 años, o al menos una parte de ellos por fallo de copia de seguridad, secuestro de datos, etc. Al cliente que se le ofrece No Verifactu hay que explicarle cuáles son las consecuencias y que como desarrolladores tendría que firmarnos un documento en el que, es la empresa, la que se hace responsable de las copias de seguridad, de tener los certificados al día, etc. El hecho de estar en el SII te permite una demora de 3 días en remitir los registros de facturación a la Aeat, pero esto no quiere decir que le permitas editar la factura una vez expedida para que la modifique antes de enviarla si detecta un error. Esto está prohibido por el Reglamento de Facturación incluso antes de el desarrollo normativo de Verifactu y estarías incumpliendo el punto 201.bis de la ley. Por lo tanto, si estás acogido al SII te da igual que tu sistema sea Verifactu ya que no podrás modificar la factura expedida. Lo que debes hacer es, en vez de remitirla a Verifactu, la remites al SII. Las compras también se remiten al SII pero Verifactu está fuera de este tema así que no habría que hacer nada. Esta es mi opinión por si a alguien le vale. |
Cita:
|
Cita:
Eso mismo pensaba yo cuando se puso en marcha TicketBAI en el País Vasco: que muchos pequeños comercios no podrían cumplir por no tener conexión a Internet. Ahora, casi 2 años después y dando servicio a más de 300 negocios (en su mayor parte TPVs de bazares, pequeños comercios y bares), no hemos tenido ni un solo caso donde no pudiesen cumplir por falta de conexión. Los que no tienen contratado Internet por ADSL, cable o fibra, funcionan perfectamente con routers 4G con SIM de tarifas de datos baratas. Ejemplo de router 4G barato: https://www.amazon.es/TP-Link-MR100-.../dp/B085PFRFKX Y tarifas de datos baratas de operadoras móviles: - Simyo 4GB de datos mensuales sin llamadas: 2€ al mes (https://www.simyo.es/?homeNav=mobile) - Digi tarifa Mini de 3GB de datos mensuales: 3€ al mes (https://www.digimobil.es/movil/) Incluso para los que sí tienen conexión permanente a Internet por ADSL, cable o fibra, siempre recomendamos tener uno de estos routers 4G (con SIM de tarifa de datos económica) configurado como backup: si se les cae su conexión fija de Internet, su tráfico sigue saliendo, sin problemas por 4G. Saludos |
| La franja horaria es GMT +2. Ahora son las 01:51:16. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi