Platanito Rico
Vera 37,25 N L–V de 9 a 19 h
Presupuesto

python · vera

Desarrollo con Python en Vera

El estudio está en Vera, así que esta es de las pocas páginas donde «damos servicio en la zona» no es una forma de hablar: es la calle de al lado. Y lo que se mueve aquí —alquiler vacacional, hostelería, comercio, construcción— comparte un problema que no se arregla con una web: el dato entra varias veces y nunca en el mismo sitio.

Una recepción apunta la reserva en su sistema, el portal manda su confirmación por correo, el banco ingresa el cobro con otro concepto y a final de mes alguien cuadra las tres cosas a mano. Eso es exactamente lo que resuelve Python, y no requiere cambiar ninguno de los sistemas que ya usáis.

Tres fuentes que no comparten identificador —dos portales de reserva y el extracto del banco— entran en un proceso que normaliza formatos y empareja por importe y fecha. Lo que casa con una sola posibilidad se da por bueno; lo que casa con dos o con ninguna se aparta en una lista corta con el motivo escrito al lado, que es lo único que revisa una persona. lo que llega, sin nada en común portal A ref. propia portal B otra ref. banco concepto libre sin número de reserva compartido normalizar y emparejar importe + fecha cuadrado sin tocar a revisar con el motivo Lo dudoso no se decide solo: se aparta con el motivo escrito al lado, y esa lista corta es lo único que llega a una persona. Un proceso que decide por su cuenta lo que no está claro acaba colando errores en silencio, que es peor que el trabajo manual.

01 · informe

Antes de automatizar nada: el informe de seis preguntas

Este es el guion con el que empezamos cualquier encargo de datos, y sirve igual si lo aplicas por tu cuenta. La mitad de los procesos que llegan pidiendo automatización no la necesitan, y salir de esa conversación con un «no hace falta» vale más que un presupuesto.

  1. ¿Cuánto tiempo se va de verdad al mes?

    Es la cifra que decide si merece la pena, y casi siempre se estima mal. Un proceso que parece media jornada suele ser dos horas, y uno que «se hace en un rato» resulta que se hace tres veces por semana.

    cómo se mide Cronometrar dos veces reales, no recordar. Si son varias personas, cada una la suya.

  2. ¿Qué pasa cuando se hace mal?

    Un descuadre que se detecta al día siguiente cuesta un rato. Uno que se detecta en la declaración cuesta otra cosa. El coste del error importa más que el del tiempo para decidir cuánto invertir.

    cómo se mide Recordar el último fallo gordo y cuánto costó arreglarlo, incluido el tiempo de terceros.

  3. ¿El dato de origen es siempre igual?

    Es la pregunta que más presupuestos rompe. Un fichero con la misma estructura cada vez es un proceso sencillo; uno donde el proveedor cambia las columnas cuando quiere es un proceso que hay que mantener.

    cómo se mide Comparar el fichero de este mes con el de hace un año. Si no coinciden, ya está respondida.

  4. ¿Quién decide qué hacer con lo que no cuadra?

    Ningún proceso automático cuadra el cien por cien. Si no hay nadie que revise las excepciones, el sistema acaba colando errores en silencio, que es peor que el trabajo manual que sustituyó.

    cómo se mide Poner nombre y apellidos a esa persona. Si no hay nombre, el proceso no está listo.

  5. ¿Hace falta que corra solo o basta con lanzarlo?

    Un proceso mensual que alguien ejecuta a mano no necesita servidor y cuesta una fracción. La automatización completa se paga en infraestructura y mantenimiento, y muchas veces no aporta nada sobre pulsar un botón.

    cómo se mide Mirar la frecuencia real y si la persona que lo lanzaría está siempre disponible.

  6. ¿Qué pasa el día que esto falle?

    Fallará: cambiará una contraseña, caerá un servicio o llegará un fichero vacío. La diferencia entre un proceso que aguanta años y uno que se abandona a los seis meses es si avisa cuando falla o se calla.

    cómo se mide Decidir quién recibe el aviso y por qué vía antes de escribir una línea de código.

Si a la primera y la segunda respondes con cifras pequeñas, la respuesta honesta es que no automatices: sale más caro el desarrollo que el problema. Nos lo decimos a nosotros mismos con frecuencia.

02 · ejemplo

Ejemplo trabajado: cuadrar reservas y cobros

Alquiler vacacional · el sector con más peso en Vera

Un gestor de apartamentos recibe reservas por dos portales y por teléfono, cobra por transferencia y por pasarela, y a final de mes cuadra a mano qué reserva corresponde a qué ingreso. Cada concepto bancario viene escrito de una forma distinta y ninguno lleva el número de reserva.

  1. recoger

    Se leen las tres fuentes: exportación de cada portal y extracto del banco. Ninguna cambia, no hay que tocar los sistemas que ya usa.

  2. normalizar

    Fechas, importes y nombres se dejan en el mismo formato. Es la parte aburrida y la que más trabajo ahorra después.

  3. casar

    Se empareja por importe y ventana de fechas, y cuando el concepto trae el apellido del huésped se usa también. Lo que casa con una sola posibilidad se da por bueno.

  4. apartar

    Lo que casa con dos o con ninguna se separa en una lista aparte, con el motivo escrito al lado. Esa lista es lo único que llega a una persona.

El trabajo deja de ser revisar todos los movimientos y pasa a ser mirar los que no cuadran. En un proceso así lo habitual es que se resuelva solo la mayoría y quede un resto corto para revisar, aunque la proporción depende de lo limpios que estén los datos de partida.

Esto es un ejemplo de aplicación construido para explicar el método, no un proyecto entregado. Las cifras de un caso real dependen de sus datos, y no publicamos resultados que no podamos respaldar.

03 · criterio

Decisiones que tomamos, y por qué

  • Dónde corre, y por qué casi nunca hace falta un servidor

    Un proceso mensual se puede lanzar desde el ordenador de la oficina con un doble clic. Uno diario compensa ponerlo en un servidor pequeño, que cuesta unos pocos euros al mes. Montar infraestructura para algo que se ejecuta doce veces al año es gasto sin contrapartida, y conviene decirlo antes de presupuestarlo.

  • El dato de origen manda sobre todo lo demás

    Si el fichero llega en PDF generado por un escáner, el proceso es otro y el presupuesto también. Por eso lo primero que pedimos es un fichero real de los que llegan, no una descripción de cómo son: entre lo que se cree que llega y lo que llega hay más distancia de la que parece.

  • Fallar en silencio es el peor modo de fallo

    Un proceso que se cae y avisa se arregla esa mañana. Uno que se cae y no avisa se descubre semanas después, cuando ya hay decisiones tomadas con datos viejos. Todo lo que entregamos lleva registro de lo que hizo y aviso cuando no pudo.

  • El código es vuestro y se puede leer

    Se entrega con el código comentado en castellano y con las instrucciones para ejecutarlo sin nosotros. Un proceso que solo sabe lanzar quien lo escribió es una dependencia, no una herramienta.

03 · cobertura

Cómo damos servicio en Vera

El estudio está en Vera, así que aquí las reuniones son presenciales sin más trámite.

El desarrollo se trabaja en remoto igualmente: el código no necesita que nadie se desplace.

05 · dudas

Preguntas frecuentes

¿Tenéis que tocar nuestro programa de gestión?

No, y es parte de la idea. El proceso lee lo que vuestros sistemas ya exportan y deja el resultado donde haga falta. Nada cambia dentro del programa que usáis a diario, que es donde están los riesgos de verdad.

¿Cuánto tarda algo así?

Un proceso de cuadre como el del ejemplo suele ser cuestión de días, no de meses, siempre que los ficheros de origen estén disponibles desde el principio. Lo que alarga los plazos casi nunca es programar: es conseguir un fichero real de cada fuente.

Estáis en Vera, ¿eso cambia algo?

Para el desarrollo no: el código se trabaja igual en remoto. Para arrancar sí, porque la primera reunión con los ficheros delante rinde mucho más en persona que por videollamada, y aquí eso es cuestión de acercarse.

¿Y si dentro de un año cambia el formato del fichero?

Se ajusta, y suele ser un trabajo corto si el proceso está bien escrito. Por eso importa que el código sea legible y esté comentado: el coste de mantener no lo marca la tecnología, lo marca lo fácil que sea entender lo que hay.

Cuéntame qué necesitas hacer con Python

Si tienes una empresa en Vera y algo de lo de arriba te suena, con describirlo suele bastar para saber si tiene arreglo y cuánto trabajo es.

Contar el proyecto