Bertrand Benjamin
6a638df1ab
La carte d'un lot n'affichait que quatre des huit colonnes du compte rendu, la colonne Total absente, et le bandeau replié montrait un total figé : corriger un règlement ne le changeait pas. Pire, les quatre agrégats modifiables ne sont jamais enregistrés — seules les lignes partent en base (`service.py`) — pendant que les colonnes réellement écrites, dont Regles et Impayé, n'étaient éditables nulle part. On corrigeait donc un champ sans effet, et pas celui qu'il fallait. Le détail des lignes reprend maintenant le tableau du compte rendu, colonne pour colonne, la ligne « Totaux » comprise en pied. Les dix champs d'une ligne et les huit de la ligne Totaux sont modifiables, sans exception : cette page sert à vérifier une extraction avant de l'enregistrer, l'utilisateur y a le dernier mot. Rien n'est plus recalculé à l'affichage ni reporté d'un champ sur un autre. Corriger une colonne ne déclenche que ce qui a été demandé — un total réécrit d'office effacerait sans le dire ce que le compte rendu porte. Un seul contrôle subsiste, en signalement pur : chaque colonne de la ligne « Totaux » est confrontée à la somme de cette même colonne sur les lignes. Le recoupement est celui que fait l'œil sur le tableau. Déduire le total des autres colonnes laissait passer le cas le plus parlant — une colonne Total qui ne somme visiblement pas, faute d'avoir extrait la valeur d'une ligne. Sur les 388 lots des documents extraits, ce contrôle signale quatre lots, tous de vraies extractions incomplètes : un règlement de 707,29 € qu'aucune ligne ne porte, un « divers » de 308,76 € sauté à un changement de page, deux lots réglés sans ligne. La colonne fautive passe en surbrillance et affiche la valeur calculée sous le montant extrait, sans jamais s'y substituer. Le solde antérieur quitte la colonne Loyers pour la colonne Période, où le compte rendu l'imprime. Compté à part sans être affiché à part, il donnait une colonne Loyers qui semblait ne pas sommer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Plesna Gerance
Extracteur de comptes rendus de gerance Oralia/ICS.
Prerequis
- Python >= 3.10
- uv
- Node.js >= 22
L'extraction de PDF utilise
pdfplumber(Python pur) : aucun binaire systeme requis (plus besoin depoppler-utils/pdftotext).
Installation
uv sync
cd frontend && npm install
Developpement
Lancer backend et frontend dans deux terminaux separés :
make dev_back # Backend sur http://localhost:8000 (auto-reload)
make dev_front # Frontend sur http://localhost:5173 (hot-reload)
Ou les deux en parallele :
make dev
Ouvrir http://localhost:5173 — le proxy Vite redirige /api vers le backend.
Production (Docker)
Un conteneur unique : l'image embarque le frontend Vue builde, servi par le backend FastAPI (API + interface web sur le meme port). Pas de nginx.
L'image est publiee par la CI Gitea (.gitea/workflows/docker-publish.yml)
sur git.opytex.org/lafrite/plesna-gerance. Le docker-compose.yml la tire
directement (pas de build local) :
make docker # podman-compose pull && podman-compose up -d
# ou : docker compose pull && docker compose up -d
Accessible sur http://localhost:8080.
Les donnees (base SQLite + documents) sont declarees via PLESNA_DATA_DIR
(voir docker-compose.yml) et persistees dans un volume nomme dedie
(plesna-data), donc conservees entre les redemarrages et recreations du
conteneur.
Build local de l'image (test avant publication) :
make docker-build(podman build -f backend.Dockerfile -t plesna-gerance:local .).
Application de bureau (Windows, sans ligne de commande)
L'application peut etre empaquetee en executable Windows autonome : un seul fichier que l'utilisateur final installe et lance via une icone, sans Python, sans Node, sans terminal. L'extraction etant en Python pur, aucun binaire externe n'est requis.
Tester le mode bureau (depuis les sources)
Sous Windows (pywebview utilise WebView2, deja present) :
uv sync --group desktop
cd frontend && npm run build && cd ..
uv run plesna-gerance desktop # ouvre une fenetre native
Sous Linux, pywebview a besoin d'un moteur de rendu. Le groupe
desktop-linux fournit un backend Qt entierement pip-installable :
uv sync --group desktop-linux
cd frontend && npm run build && cd ..
uv run plesna-gerance desktop # necessite un environnement graphique ($DISPLAY)
Ce backend Qt ne sert qu'a tester le mode fenetre sous Linux : il n'est pas embarque dans le build Windows.
Produire l'executable + l'installeur
Deux options (le build doit se faire sur Windows, PyInstaller ne croise pas les plateformes) :
-
Sur une machine Windows — installer uv, Node.js et (optionnel) Inno Setup 6, puis :
powershell -ExecutionPolicy Bypass -File packaging\build_windows.ps1Produit
dist\PlesnaGerance.exeet, si Inno Setup est present,dist\PlesnaGerance-Setup.exe. -
Sans machine Windows — via GitHub Actions : le workflow
.github/workflows/build-windows.ymlcompile sur un runner Windows. Le declencher (onglet Actions ou en poussant un tagv*) puis telecharger l'artefactPlesnaGerance-windows.
Cote utilisateur final
Lancer PlesnaGerance-Setup.exe, suivre l'assistant (installation par
utilisateur, sans droits administrateur), puis cliquer sur l'icone Plesna
Gerance. Les donnees (base et documents) sont stockees dans
%APPDATA%\PlesnaGerance et conservees entre les mises a jour.
Assistant IA (optionnel) : la page IA necessite Ollama installe separement. Sans Ollama, l'application fonctionne normalement et la page IA indique simplement que le service est indisponible.