ARubenC

Bonjour, Effectivement, en ayant accès à la base de donnée + les données en clairs + le code source, la certification ne sert à rien : l'utilisateur peut toujours modifier ses données. C'est bien là le fond du sujet : ce projet de loi tue le logiciel libre du point de vue encaissement/facturation/compta, n'autorisant que les logiciels propriétaires/fermés ou les intermédiaires payants pour cette fonctionnalité. Ma question est donc : comment Prestashop aborde le sujet ? Cordialement, Ruben

Bonjour, Nos chers politiques luttant contre la fraude fiscale à la TVA, envisage dans le PLF 2016 (Projet Loi de Finances 2016) de rendre obligatoire pour 2018 l'utilisation d'un logiciel certifié rendant impossible la modification des encaissements. Le gouvernement communique sur les "caisses enregistreuses" mais le texte proposé est beaucoup plus vaste, avec lourdes sanctions et responsabilité juridique illimitée des éditeurs de logiciel. art. 38: Lorsqu'elle enregistre les règlements de ses clients au moyen d'un logiciel de comptabilité ou de gestion ou d'un système de caisse, utiliser un logiciel ou un système satisfaisant à des conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données en vue du contrôle de l'administration fiscale, attestées par un certificat délivré par un organisme accrédité dans les conditions prévues à l'article L. 115-28 du code de la consommation ou par une attestation individuelle de l'éditeur, conforme à un modèle fixé par l'administration. Lire : https://lite6.framapad.org/p/PLF2016 Les logiciels libres sont fortement impactés. Ex: Dolibarr, Odoo, OpenBravo... Qu'en est-il de Prestashop (qui stocke les facturations) ? Et des "caisses enregistreuses" pour Prestashop ? Quel avenir pour les changements de versions Prestashop si la partie facturation est inaltérable ? Cordialement, Ruben

Merci pour votre réponse. Je constate sur Github, que seules les traductions FR et EN sont prévues. Peut-être est-il préférable de passer par http://www.prestashop.com/fr/contribute-prestashop-localization. Je suppose qu'une personne doit fusionner toutes les contributions pour une langue donnée ? J'ai oublié de préciser que je suis sur la v1.5.6.0, mais les erreurs de traductions le sont aussi sur les versions ultérieures. Ruben

Bonjour, J'ai constaté quelques erreurs dans le fichier de langue PT_PT. Je les ai corrigées sur mon site, mais comment les signaler à Prestashop pour les corriger dans le package officiel ? Fichiers joints. Ruben Hi, I noticed some errors in the language file pt_PT. I have corrected them on my site, but how to report Prestashop to correct in the official package? Files included. Ruben Ex: VAT_number -> NIPC (not "N° contribuinte") Sometimes: "envio" but in English is "entrega" ("delivery" in English but translated as "shipping"). lang_PT_PT.zip

Hello, Perhaps it's too late, but it can help someone else. The solution to see your own modules in the Payment page, it's to override the AdminController class. Ex: for v1.5.6.0, in the function getModulesList, in line 2302, add this code: //Modif start: for AdminPayment module, add our module to the Prestashop'filter_modules_list to display them if ($this->controller_name == 'AdminPayment') { $my_payment_modules = $this->payment_modules; if (!is_array($this->payment_modules) && !is_null($this->payment_modules)) $my_payment_modules = array($this->payment_modules); if (count($my_payment_modules)) { foreach ($my_payment_modules as $my_module) { if (!in_array($my_module->name, $filter_modules_list)) $filter_modules_list[] = $my_module->name; } } } //Modif end Don't forget to delete the "class_index.php" file in the "cache" folder if you don't yet override this class. Well, enjoy!