Veri*Factu pospuesto

Al hilo de mi anterior hilo, hoy se acaba de conocer que el gobierno ha pospuesto la puesta en marcha de la obligatoriedad del sistema un año completo.

Todo un alivio para las pymes y autónomos que estaban muy perdidos con las nuevas obligaciones que emanaban de este nuevo sistema tributario.

Podeis ver la noticia en varios medios:

Es buena hora para empezar a prepararse, ahora con más tiempo y aprovechar para utilizar herramientas como DocuFactu.

Si te suena VeriFactu, tienes que leer esto

Desde hace unos meses hay una palabra que suena mucho por todas partes, no es una peli, no es un disco, no es un nuevo escándalo financiero y no afecta a todo el mundo… Pero es algo muy importante para pymes y autónomos, esa palabra es VeriFactu (o Veri*Factu).

Facturas alocadas por Veri*Factu a la espera de DocuFactu

¿Qué es Veri*Factu?

VERI*FACTU es el nuevo sistema de emisión de facturas “verificables” definido por la Agencia Tributaria española dentro de la Ley Antifraude, pensado para que el software de facturación genere registros inalterables y, opcionalmente, los envíe en tiempo real a Hacienda.

¿Porqué se está hablando de esto?

Se habla tanto de VERI*FACTU en estos meses porque su implementación obligatoria se acerca rápidamente, con plazos clave en 2025-2026 que generan urgencia entre pymes, autónomos y desarrolladores de software.

  • El 29 de julio de 2025 era la fecha límite para que los fabricantes adapten y homologuen sus programas de facturación.?
  • Desde el 1 de enero de 2026, las sociedades mercantiles deben usar sistemas compatibles; para autónomos y personas físicas, el 1 de julio de 2026.?

Artículos recientes destacan que solo el 8% de pymes está preparado, con un mes restante para la primera fase.?

Cómo funciona en la práctica

El programa de facturación genera, por cada factura, un registro firmado electrónicamente, con huella (hash) y datos clave (número, fecha, importe, NIF, tipo de factura, etc.), y lo encadena con los anteriores para asegurar la trazabilidad.?

En modo “VeriFactu”, el software envía estos registros automáticamente a la AEAT; en modo “no VeriFactu”, los conserva y solo los remite si se le requieren, pero cumpliendo igualmente requisitos estrictos de seguridad y conservación.?

Las facturas incluyen un código QR que permite a cliente y AEAT comprobar que la factura está registrada, así como la leyenda “VERIFACTU” o “Factura verificable en la sede electrónica de la AEAT”.?

Esa marca funciona como “sello de calidad fiscal”: indica que el emisor usa un sistema que cumple con el reglamento de facturación verificable y con los requisitos técnicos oficiales.

De hecho, según las respuestas a preguntas frecuentes de la AEAT. incluso si se elige el modo «no VeriFactu» se debería incluir el código QR siempre que se haya generado con un programa informático que tenga la opción «no VeriFactu».

¿Qué puedo hacer o como desarrollador?

En primer lugar informarte sobre todo esto, ya que tarde o temprano terminará cayendo sobre ti parte de este marrón. La información principal puedes encontrarla en la AEAT, y si no queréis cambiar de sistema de generación de facturas todavía, os recomiendo utilizar DocuFactu. DocuFactu es un sistema sencillo que permite, en base a las facturas en el formato actual generar e incrustar un QR verificable en la misma para que cumpla la normativa. Además, si deseas usar el modo VeriFactu usa inteligencia artificial para extraer los datos de la factura y enviarlos al registro de la agencia tributaria en tu nombre. Tiene una API muy sencilla (REST con API KEY) y permite cumplir con la ley sin demasiados quebraderos de cabeza. Si queréis más información, solo tenéis que visitar su web (DocuFactu – VeriFactu fácil) o enviar un correo a [email protected].

En un mes justo veremos si esto echa a andar o los múltiples problemas que nos genera tener que adaptar algo tan importante como la facturación a una norma tan restrictiva hacen que se retrase su puesta en marcha.

Añadir un segundo factor a tu acceso ssh

Los piratas no descansan y las bases de datos de contraseñas no dejan de crecer. Hay filtraciones constantes y, por mucho que lo intentes, no haces más que reutilizar contraseñas y a no ser que utilices algo como nomorepass (muy recomendado) tu memoria tiene sus límites y es muy posible que lo último que hayas cambiado es tu contraseña de acceso.

En el caso de linux, que es lo que yo uso todos los días, si tienes un acceso por ssh que llegue a tu ordenador es bastante sencillo que algún escaner de puertos lo haya detectado, aunque sea por azar, y te encuentres con que están intentando acceder a tu cuenta por fuerza bruta. Hay varios métodos muy recomendables para evitarlo, pero aún así si te dejaste «olvidada» tu contraseña en algún sistema que fue comprometido, bueno, se te pueden meter hasta la cocina.

En este post te comento cómo configurar ubuntu 24.04 (probablemente funcione igual en otras distribuciones) para que te pida un segundo factor de seguridad (que tendrás en el teléfono) y puedes usar google authenticator o cualquier otro sistema compatible on TOTP (códigos generados dependientes del tiempo).

Paso 1:

sudo apt install libpam-google-authenticator

Paso 2:

Añade la siguiente línea al archivo /etc/pam.d/sshd

auth requiered pam_google_authenticator.so

Modifica el archivo /etc/ssh/sshd_config para cambiar y descomentar este valor:

KbdInteractiveAuthentication yes

Ahora reinicia el servicio ssh

sudo systemctl restart ssh

Y ya es momento de configurar tu authenticator

google-authenticator

Te mostrará un QR enorme en pantalla que podrás escanear con tu app de authenticator (yo uso nomorepass) o bien copiar la secret key. Luego siempre puedes copiar los códigos de mergencia por si pierdes el acceso al teléfono (y no los guardes en donde no debes, que nos conocemos)…

Luego ya configuras el resto de cosas de seguridad a los valores recomendados y ya estaría.

Ahora la siguiente vez que intentes entrar te pedirá la constraseña y el código de verificación… Una puerta menos para los hackers.

La herramienta correcta para gestión de tareas

Cualquier equipo, se dedique a lo que se dedique, cuando lo componen varias personas hay un momento en que alguien debe pararse y decir, ¿estamos haciendo las cosas bien? ¿en el orden correcto? ¿dedicando el tiempo necesario a cada una? ¿tenemos controlado el trabajo o el trabajo nos controla a nosotros? Lo que antes eran reuniones y encargos sencillos se ha convertido en un sin fin de recordatorios de cosas que no se han hecho, se han hecho sin necesidad o se han hecho demasiado tarde o demasiado pronto. En este punto es cuando la elección de una buena herramienta de gestión de tareas se hace necesaria.

Si esperáis que os diga cual es la correcta para el desarrollo de software, bueno, pues os equivocáis, todavía no he encontrado la que sea perfecta, pero si que puedo ofreceros mi visión sobre lo que necesitaría tener esa herramienta y los intentos de encontrarla que he tenido durante estos casi 30 años en el oficio.

Primero lo primero, cuales son las necesidades que queremos cubrir con esta herramienta:

  • Queremos poder registrar el tiempo dedicado y estimado para cada tarea sin que nos quite tiempo de trabajo efectivo.
  • Necesitamos saber la prioridad de las distintas tareas y poder ordenarlas en el tiempo.
  • Necesitamos saber quien tiene que trabajar en una tarea y qué es lo que tiene que hacer en la misma
  • Necesitamos saber el estado de cada tarea y el grado de avance general de la tarea y del proyecto al que pertenece
  • Es preciso poder descomponer el trabajo en tareas más pequeñas que puedan ser abordadas por una sola persona o, en el caso de requerir múltiples participantes al mismo tiempo que esté controlado el tiempo dedicado por cada persona
  • Queremos que cada proyecto tenga una visión clara de las tareas en curso y las que están en distintos estados del workflow de desarrollo
  • Necesitamos que haya una trazabilidad completa de las tareas desde su creación hasta que esta se termina
  • Es imprescindible disponer de documentación y una forma de asociarla a las tareas, pero de manera más independiente ya que la documentación ha de permanecer más allá de la vida de la tarea
  • Se necesita una manera ágil de comunicación entre los distintos componentes del equipo y, posiblemente, con elementos fuera de los equipos de desarrollo (usuarios, QA, dirección) aunque no es imprescindible que esté ligado al mismo sistema si que se necesita una manera sencilla de referirse a las tareas externamente.
  • Es deseable poder implementar distintos ciclos de vida a distintos tipos de proyectos y no limitarse a uno solo.
  • Si se usa un sistema el directorio de usuarios debe estar en sincronía con el de la empresa y la autenticación deberá ser compatible con la existente.

Evidentemente cada organización, empresa o grupo puede tener más o menos necesidades, pero en la lista anterior creo que he incluido las principales. El objetivo final es saber qué trabajo queda por hacer, qué hacer primero, tener previsiones de cuando estará un cierto trabajo complejo y saber cómo se están aprovechando los recursos. Obviamente cuanto más sencillo sea el sistema y cuanto menos tiempo nos quite de las tareas reales más efectivo será.

Y, para que sirva de referencia os voy a contar mi historia con los distintos sistemas de gestión de tareas que he tenido el «honor» de probar.

En el 97 empecé a trabajar profesionalmente en esto de la informática después de haber terminado la carrera y haber obtenido toda la teoría necesaria sobre gestión de proyectos y haber hecho un curso de CEPADE sobre gestión de proyectos tecnológicos. En la empresa en la que entré se gestionaba todo con Microsoft Project, por suerte generalmente la planificación moría en el momento en que el proyecto empezaba. Lo único que se esperaba respetar eran los plazos y los entregables. El tiempo dedicado no se actualizaba nunca y solo se ampliaban los plazos o, si el cliente se ponía pegigero, se cambiaba el alcance y se eliminaban o añadían tareas sin demasiado control.

Microsoft desarrolló una especie de project on-line para que los usuarios que estuviesen participando en un proyecto pudiesen imputar las horas o indicar cuando se habían acabado las tareas. Ahora mismo no recuerdo el nombre del producto, lo que si recuerdo es que era tan dificil de instalar y hacer funcionar correctamente que lo usamos solo en un proyecto antes del olvidarlo completamente. Project se quedó para el papeleo y marcar las fechas esperadas y controlar, por tanto, el retraso de las tareas y del proyecto en general.

Seguí usando project (sin ningún online y con control mediante arcaicas hojas excel) hasta que evolucioné lo suficiente (y puse mi propia empresa) como para usar Linux como mi máquina principal… Mira por donde ahí no había forma de ejecutar el project y me las vehía y deseaba para generar los gantt de manera medianamente atractiva para presentársela a los clientes (si, ya era para mis propios clientes). Llegados a este punto descubrí una herramienta online que, aunque inicialmente no creada para ello, servía perfectamente para hacer seguimiento del tiempo dedicado a las tareas de un proyecto, se trataba de trac. Tal como contaba en su página (hoy casi abandonada)

Trac es un sistema wiki mejorado y de seguimiento de incidencias para proyectos de desarrollo de software. Trac utiliza un enfoque minimalista para la gestión de proyectos de software basados en la web.

trac era un sistema de tickets, con un wiki para la documentación y conexión con subversion para el control de código. Si a esto le unimos que permitía indicar el número de horas dedicadas a cada incidencia, ya teníamos una primera forma de controlar en tiempo real las tareas. El wiki no era perfecto y la búsqueda también podía mejorarse, pero cumplió muy bien con su cometido durante unos cuantos años. De hecho el problema sobrevino cuando dejaron de mantener el producto y ya teníamos muchos proyectos gestionados con este sistema. Tengo que decir que antes de llegar a trac (que inicialmente se llamó svntrac) estuvimos usando cvstrac y cvs en lugar de subversion… Y si, tuvimos que migrar de cvs a subversion y de eso a git (es lo que tiene llevar más de 20 años produciendo código sin querer perder nada).

El caso es que descubrimos un poco después que había un programa que tenía todo lo que tenía trac (y algunas cosas más) que era completamente software libre y, además, rapidísimo y se llama Redmine. Aunque lleva creado desde 2006 no fue hasta 2018 que decidí implantarlo en mi empresa (y en la de algún cliente posteriormente). Aunque seguía sin ser perfecta nos ofrecía todo lo que necesitábamos para el control de tareas, nos permitía comunicarnos con los clientes via incidencias, llevar un tracking completo de todo en lo que hemos trabajado de cada proyecto, con múltiples proyectos completamente aislados unos de otros y con usuarios igualmente aislados y con roles diferenciados. Todos nuestros proyectos con mantenimiento se iniciaban como proyecto redmine y evolucionaba a proyecto de mantenimiento abierto a que los clientes pudieran dar de alta sus incidencias y hacer seguimiento de la evolución del mismo.

El mayor problema de redmine es que tremendamente poco intuitivo o, dicho en castellano «es feo de cojones». Aunque tiene todo lo que necesitamos para un equipo de desarrollo (aunque feo-feo), es imposible a día de hoy intentar que un cliente entre por el aro de reonocer esto como una aplicación web… Ahora se espera utilizar llamativos tableros kanvan (inutilizables cuando el número de tareas es alto o los equipos grandes) y modificaciones instantaneas via clicks y sin tener que escribir nada, solo pinchar y arrastrar. Me he pasado los últimos años buscando herramientas software libre que me permitiesen tener la misma privacidad y funcionalidad que redmine pero con un aspecto nuevo y renovado. He probado desde Trello hasta monday.com pasando por Jira y Asana (igual Jira no es tampoco demasiado atractivo). Quitando que ninguna de estas herramientas son libres de verdad y varias de ellas o son demasiado completas o carecen de alguna de las características que hemos descrito anteriormente todas ellas son carísimas… Sigo buscando ya que aunque redmine me viene bien para gestionar un equipo de desarrollo se atraganta a otro tipo de perfil menos hecho a lidiar con informes y formularios. ¿Conocéis alguno bueno y, a ser posible, open source o con una versión realmente barata?

Cómo Configurar Login con Office 365 (Microsoft Entra ID) en Authentik

Como ya vimos en la anterior entrada es bastante sencillo instalar un sistema SSO como authentik en nuestra infraestructura. De todas formas, crear un login centralizado no es más que una manera de tener que recordar menos contraseñas, pero el objetivo final es no tener que recordar más que unas pocas para poder acceder a todos los servicios, ¿qué hacemos si ya tenemos cuenta en alguno de los servicios más populares como office 365 o google? Lo suyo sería poder hacer login con estas credenciales en cualquier servicio, sea online o sea auto hospedado. Por suerte, authentik puede hacer uso de estos servicios externos de autenticación de manera «relativamente» sencilla. En este post os voy a explicar paso a paso (que sobre todo la parte a realizar con office es un poco liosa) cómo integrar el login de office 365 con authentik y así poder usarlo para acceder a nuestras aplicaciones (eso ya lo explicaremos en próximos posts).

Para poder realizar este tutorial debes tener:

  • Servidor authentik instalado y configurado (con acceso como administrador)
  • Cuenta de administrador office365 de tu organización
  • Un poco de paciencia (esto nunca viene mal)

Paso 1: registrar una aplicación de microsoft entra

Entramos como administrador en portal.office.com

Pedimos que nos muestre todas las opciones (estos de MS suelen ocultarnos cosas)

Seleccionamos la opción Identidad (nos llevará a entra)

Seleccionamos la opción Registro de aplicaciones

Y seleccionamos Nuevo registro

Y rellenamos los datos básicos (yo voy a llamar authentik a la nueva aplicación)

Hemos elegido que solo se pueda entrar con cuentas de nuestra organización, que será lo normal, aunque si queremos que cualquiera que tenga una cuenta de office365 pueda hacer logn tendremos que escoger una de las otras opciones. Atento a la ui de redirección, en principio tendrá el formato https://<direccion-de-tu-authentik>/source/oauth/callback/<nombre-de-fuente> Si no lo configuras ahora lo podrás hacer después cuando termines la configuración en authentik.

Anotamos los datos que vamos a necesitar de la aplicación y creamos un nuevo secreto:

Es muy importante que copiemos el valor del secreto que lo vamos a necesitar luego

El valor del secreto no se va a poder copiar en otro momento, mejor que lo guardes ahora.

Con esto hemos terminado (en principio) con la configuración necesaria en el portal de office. Lo que hemos hecho, básicamente, es configurar los endpoints de oauth2 que podemos consultar en la opción.

Paso 2: crear un nuevo login social

Las siguientes acciones las haremos como administrador en nuestro servidor authentik

El primer paso es crear un inicio de sesión federado

del tipo azure AD

Ahora deberemos introducir todos los datos que hemos guardado al crear la aplicación en entra:

Los endpoint serán como estos (revisar los que vimos en la pantalla del portal de office):

Cambiaremos la URL del perfil a https://graph.microsoft.com/oidc/userinfo

Y damos a terminar por ahora. Esto nos configura el método para entrar usando las credenciales de Microsoft, pero todavía nos falta un par de cosas para que sea útil del todo.

Paso 3: mapeo de atributos

Ahora necesitamos hacer la equivalencia entre los atributos que vienen de office con los que nosotros vamos a utilizar en nuestro directorio, para eso crearemos una política de expresión:

La llamamos (por ejemplo) azure-ad-mapping y ponemos este contenido:

# save existing prompt data
current_prompt_data = context.get('prompt_data', {})
# make sure we are used in an oauth flow
if 'oauth_userinfo' not in context:
  ak_logger.warning(f"Missing expected oauth_userinfo in context. Context{context}")
  return False
oauth_data = context['oauth_userinfo']
# map fields directly to user left hand are the field names provided by
# the microsoft graph api on the right the user field names as used by authentik
required_fields_map = {
  'name': 'username',
  'email': 'email',
  'given_name': 'name'
}
missing_fields = set(required_fields_map.keys()) - set(oauth_data.keys())
if missing_fields:
  ak_logger.warning(f"Missing expected fields. Missing fields {missing_fields}.")
  return False
for oauth_field, user_field in required_fields_map.items():
  current_prompt_data[user_field] = oauth_data[oauth_field]
# Define fields that should be mapped as extra user attributes
attributes_map = {
  'name': 'upn',
  'sub': 'sn',
  'name': 'name'
}
missing_attributes = set(attributes_map.keys()) - set(oauth_data.keys())
if missing_attributes:
  ak_logger.warning(f"Missing attributes: {missing_attributes}.")
  return False
# again make sure not to overwrite existing data
current_attributes = current_prompt_data.get('attributes', {})
for oauth_field, user_field in attributes_map.items():
  current_attributes[user_field] = oauth_data[oauth_field]
current_prompt_data['attributes'] = current_attributes
context['prompt_data'] = current_prompt_data
return True

Paso 4: configurar el flujo de alistamiento

Queremos que cualquiera que tenga cuenta en el dominio office pueda entrar a nuestras aplicaciones, por lo que necesitamos registrar los usuarios nuevos cuando entran por primera vez, para ello vamos a crear uun flujo nuevo.

Le ponemos un nombre

Y una vez creado, editarlo, ir a la sección d Vinculaciones de Políticas / Grupos / Usuarios y ahí a Bind existing policy

Y ahí ligar defaultsource-enrollment-if-sso

Ir ahora a vinculos de etapa -> Bind Existing stage

Añadir default-source-enrollment-write (orden 0) y default-source-enrollment-login (orden 10)

Desplegar luego la etapa con orden cero y añadir una política existente azur-ad-mapping que creamos antes:

Por último editarmos la fuente que creamos al principio (Directory -> Federation ..) y le añadimos en la configuración de flujo el flujo de inscrpción a azure-ad-enrollment (o el nombre que le hayamos puesto)

Paso 5: hacer que se vea en el login

Pues ya solo nos faltaría hacer que aparezca una opción para hacer login con este proveedor, esto se hace editando el flujo default-authentication-flow

Y editas la etapa

Y añades desde las fuentes disponibles a Fuentes seleccionadas

Ahora cuando entres en tu authentik ya te aparecerá la opción nueva para acceder. La primera vez que accedas debes aprobar unos permisos especiales a Microsoft:

Ha sido un proceso un poco largo, pero ahora ya tenéis centralizada la información de seguridad y cualquier aplicación que pueda conectarse a authentik podrá usar los usuarios de nuestro dominio… Ahora queda que lo probéis vosotros.