Crear App de finanzas personales

te refieres a linkear la app a tu metodo de pago directamente? no entiendo si no como evitarás meter todas las transacciones manualmente.
ya existen unas cuantas que acceden a tu cuenta bancaria y demás, al menos en US

Yo me llegué a hacer una, pero al final me da pereza reclasificar movimientos, por ejemplo si envías un bizum a alguien para pagar una cena o un regalo, o hay un cobro de paypal que puede ser un videojuego o ropa que te has comprado

#9 si quieres lo hablamos, del tema del diseño / frontend me encargo yo si quieres

#10 Pues mira, justo lo que me falta a mí es front end. Juguetear con el backend lo tengo más sencillo y, de hecho, me atrae más.

Actualmente el proyecto lo tengo tal que así. Recordemos que todo apunte de gasto es manual.

1. Diariamente, por la maña, después de cuadrar los gastos del día anterior en la app de android exporto la base de datos
2. Después de exportarla ejecuto un script en el móvil que me sincroniza el archivo de bbdd con mi nube privada (antiguamente la app tenía integración con dropbox, se perdió hace mucho)

Ahora, desde el PC, si quiero juguetear con los datos:

1. Ejecuto un script python que me actualiza la bbdd con la última versión que esté en mi nube
2. Con otro script cargo la bbdd y hago analíticas y dashboarding.

La app de android tiene un dashboarding limitado y para ciertos filtros me es más cómodo desde python. Así que lo que he hecho es estudiarme el esquema de la bbdd de la app de android (SQLite) para cargar y jugar con los datos.

Mis objetivos para el proyecto serían:

1. Desarrollar un servicio web, posiblemente mediante fastAPI o Flask (esto es entretenido para mí, nunca lo he hecho, pero me veo capaz), que termine exponiendo el dashboarding usando grafana (por mi carencia de frontend).
2. Comenzar a desarrollar una interfaz con los casos de uso idénticos de la app android (interactuar con la bbdd)
3. Que el frontend sea en kotlin o ionic sería ideal

El punto 2 me queda bastante lejano porque hace mil que no hago gestión, como comentaba antes. Entiendo que si le meto esfuerzo suficiente lo podría sacar adelante. Ahora bien, el punto 3 me queda a años luz XDDDD

#11 Mira, aquí te dejo las tablas y te las explico por encima:

1. tbl_notes: es una tabla sin relacionar que se puebla con notas que sirven de plantilla en los apuntes
2. tbl_budget: es una tabla que sirve para crear presupuestos máximos por categoría
3. tbl_account: las cuentas y su información (nombre, posición en la que se muestra, si está activa o no, si es de crédito o no, el color en el que se muestra) y su inicialización (saldo inicial o límite de crédito máximo si es de crédito)
4. tbl_cat: para las categorías de los gastos (Nombre, color, icono asociado, si es de gasto o de ingreso)
5. tbl_transfer: tabla de transferencias entre las diferentes cuentas. El tipo, en vez de crear un apunte de ingreso y uno de devengo, monta esta tabla de transferencias. Ejemplo práctico: cuando saco dinero del banco a mi cartera para tener metálico. Esta tabla entraña: desde qué cuenta (de tbl_account) hasta qué cuenta (de tbl_account), cantidad transferida, fecha y nota
6. tbl_trans (de transaction): tabla para los apuntes. Necesita de las id de categoría del apunte e id de la cuenta sobre la que se produce. Obviamente, se necesita la cantidad; además: la fecha, el nombre para el apunte, nota para el apunte. La app incluye información sobre notificación y apuntes recursivos
7. tbl_r_trans: una tabla para los apuntes recursivos. Necesitas la categoría y la id de la cuenta sobre la que se producen. La cantidad y la frecuencia del apunte. También integra la información sobre el apunte (nombre y nota del mismo) y si se produce notificación. Cuando se ejecuta el apunte recursivo se registra en tbl_trans. Esto permite luego editar apuntes recursivos efectuados sobre la tabla de tbl_trans. Ejemplo práctico: yo tengo el apunte recursivo de luz con un valor estimado de 80€ al mes. Cada vez que se me cobra la luz edito el apunte en tbl_trans que tbl_r_transfer ha creado para ese mes con la cuantía específica de ese mes.

Más o menos es así todo. ¿Cómo lo ves?

PD: ¿Este hilo no debería estar en el subforo de desarrollo?

#13 te he contestado a la intención del proyecto pero no a la pregunta del caso que presentas. Tiene muy fácil solución, pienso, lo que propones. Porque está la tabla de transferencias, que justamente es para acciones entre cuentas. La característica que propones podría integrarse con facilidad. Simplemente sería algo como: si el apunte es sobre la cuenta A y la cuenta A tiene activado la opción de "restos". Básicamente, añadiría un bool en tbl_account, y un campo de "truncamiento" y un campo destino (con el id a dónde en tbl_account). Cada vez que se ejecutase un apunte sobre la cuenta con "restos" true, la cuantía se truncaría según lo deseado siendo esa diferencia con lo truncado el apunte adicional que se registra en tbl_transfer (desde esa cuenta a la cuenta que tenga asociada esa cuenta para restos).

#16 Hostias, estás a full de curro, ya leí por el foro lo de profesor asociado, leyéndote seguro que te va a ir genial.

Aclarado con lo de la tabla de transferencias, thanks!

Yo voy a intentarlo, aunque sea por mi cuenta, me vendrá bien para controlar los gastos y seguir aprendiendo, así de paso aprovecho el datalake que me monté en local con un docker

#19 Es que me parece complicar muchísimo algo relativamente sencillo, la injesta del dato (que serán estos csv's) la tendrás que hacer igual, tanto te da tener esos csv's en una bbdd, en una carpeta en tu pc o dropbox, etc

Actualmente el proyecto lo tengo tal que así. Recordemos que todo apunte de gasto es manual.
Diariamente, por la maña, después de cuadrar los gastos del día anterior en la app de android exporto la base de datos
Después de exportarla ejecuto un script en el móvil que me sincroniza el archivo de bbdd con mi nube privada (antiguamente la app tenía integración con dropbox, se perdió hace mucho)

A esto justo me refiero, una vez tienes esto me conectaría directamente a ello con power BI (dropbox mismo vale, google sheets, etc) pero incluso sin ello, teniendolo en tu pc el análisis/resultado final es el mismo (claro que toda modificación de un dato historico lo tendrías que hacer en el excel en vez bbdd, pero no cambio la salida)

#21 Si yo sólo digo que me parece sobrecomplicar algo que de base ya tienes. Ya sea por que te lo vas a tener que bajar si o si de las web bancarias/inversiones/app o por que si o si te va a tocar meter registros manuales para añadir datos que no tienes (extractos de cajero y en que se gasta cada cosa de eso) esta parte te toca hacerla siempre (la automatices o no)

Vamos, yo por mi parte lo que hice en su momento fue bajarme todos los tipos de datos que tenía (banco, indexa, etc) a diferentes csv, la extructura es común (fecha, tipo de gasto) y lo trato con power query o similares para crear un modelo sencillo juntando los diferentes orígenes de datos. Pero admito que fue algo más por curiosidad que otra cosa y ahí quedo to feo.

#27 Pues no estaría mal un fork a lo tuyo y sobre ello implementar los casos de uso y la estructura de bdd que presento en #12, para terminar con un front react o similar.

La caracterísitca de poder integrar apuntes vía PSD2 estaría muy chula. A mí me simplificaría el flujo de trabajo, pienso, aunque luego tuviese que editar cada apunte importado vía API manualmente.