Produits Entr'ouvert » Passerelle

J'ai un peu de mal à saisir. Dans le travail que nous avons fait à l'époque à Orléans, Arnaud a accès au répertoire des PDF : il les ajoute (ou les retire) à sa guise. Quand un PDF est présent, la facture du CSV est considérée existante (publiée, payable, whatever). Quand le PDF n'est pas là... la facture n'est pas là.

La raison : le PDF c'est la "vraie" facture, celle qui est émise par la ville (en papier) et donc Arnaud les envoie au système seulement quand le train de facturation est fait, terminé, validé par le service. Le CSV des factures contient des factures qui ne sont pas forcément encore validées. C'est le PDF qui "active" vraiment une facture.

Bref.

En tout cas selon moi, on ne touche pas au PDF, y'a pas de truc comme « invoice.write_pdf(file(invoice_file_path).read()) » à faire.

(mais j'ai pas tout lu du système d'import, je relève juste ça, le système d'import Orléans ne devrait pas jouer avec les PDF, uniquement vérifier leur présence pour activer les factures correspondantes)

Thomas Noël a écrit :

J'ai un peu de mal à saisir. Dans le travail que nous avons fait à l'époque à Orléans, Arnaud a accès au répertoire des PDF : il les ajoute (ou les retire) à sa guise. Quand un PDF est présent, la facture du CSV est considérée existante (publiée, payable, whatever). Quand le PDF n'est pas là... la facture n'est pas là.

La raison : le PDF c'est la "vraie" facture, celle qui est émise par la ville (en papier) et donc Arnaud les envoie au système seulement quand le train de facturation est fait, terminé, validé par le service. Le CSV des factures contient des factures qui ne sont pas forcément encore validées. C'est le PDF qui "active" vraiment une facture.

C'est le cas dans le code actuellement (sans ce patch): un objet facture est créé uniquement si le fichier correspondant existe dans l'archive. Sauf que créer l'archive avec des miliers des factures sa pose des problèmes d'espace disque et des perfs.

Je vais réflechir à une alternative pour garder l'ancien fonctionnement.

Je vais réflechir à une alternative pour garder l'ancien fonctionnement.

Inclure dans le zip le nom du répertoire où se trouvent les PDF, end of story ?

Mais le fichier PDF est recherché dans l'achive même: invoice_filename in archive.namelist() et non sur l'espace disque.
Je ne suis pas sûr de comprendre.

... Sauf que créer l'archive avec des miliers des factures sa pose des problèmes d'espace disque. ...

Je propose donc de ne pas « créer l'archive avec des miliers des factures »; à la place de mettre dans l'archive le nom du répertoire qui sera utilisé par le code d'import pour vérifier l'existence de la facture, et alors si os.path.exists(le pdf) alors la facture est créée et le pdf copié au bon endroit. (tout cela étant dit de loin, je n'ai pas suivi ce projet).

J'avoue m'y perdre. Pourquoi tripoter le zip ou déplacer les PDF ?

J'avais pensé décrire le truc existant dans mon commentaire 3, qui est l'aboutissement d'un long dialogue avec Orléans à l'époque : c'est une procédure qui ne doit pas changer. Orléans gère un répertoire avec des PDF d'un côté, et envoie des CSV zippé d'un autre côté. Et ca doit vraiment nous suffire pour faire un loader à la con.

Dans ce que dit Fred « alors si os.path.exists(le pdf) alors la facture est créée et le pdf copié au bon endroit » je dis que non. On ne doit pas du tout toucher aux PDF gérés directement par Orléans, pas les déplacer, rien. Une fois l'import des factures effectué (lecture du CSV), on active les factures du CSV qui ont des PDF, on désactive les autres, on supprime les PDF qui ne sont pas dans le CSV. Comme "avant".

Y'a pas à avoir dans le zip le nom du répertoire : il ne peut pas y être, Orléans ne connait pas l'emplacement réel des PDF. C'est un argument à passer lors de l'import des CSV, genre.

• c'est sans doute pas la peine de mettre 25 faux PDF dans les tests, je pense que 3 ou 4 fichiers devraient suffire ?
• attention aux print : c'est une commande qui sera lancée par cron, elle ne doit rien dire si tout va bien (si besoin, gérer un mode verbose)
• le "raise CommandError('Command already running.')" doit arriver juste après le fcntl.lockf ; sinon il peut y avoir eu d'autres IOError dans le reste du try/except
• last but not least, le lock ne doit pas être fait sur un fichier tempfile mais toujours sur le même fichier (si possible dépendant du tenant, genre via un truc dans /media si y'a pas d'autre méthode tenantisée)

(putain de retard, désolé)

Je suis pas à l'aise avec un gros « try:...except:pass » dans un test. Y'a une raison valable, en dehors que "comme ça le test marche toujours" ?

LOCK_FILENAME n'est pas une constante, pas de majuscule

Pour le reste il faut qu'on relise ça ensemble parce que je ne comprends pas la logique (genre "--data-directory: Directory containing archive and invoice files" alors que les invoices semblent devoir être dans DefaultStorage)

Ack