pinky a écrit 184 commentaires

Et pour re-compléter l'info :)

nous avons également 6 gros clients français dont nous sommes presques sûrs qu'ils intégrerons d'ici peu. Nous publirons donc le PCG et les modifs française très rapidement.

Pour compléter l'info; nous avons déjà des revendeurs français et certains sont déjà en train d'adapter le plan comptable. S'ils décident de publier leurs ajouts (ce dont je ne doute pas), un plan français sera disponible d'ici qq jours/semaines.

Bonjour,

La comptabilité française est supportée par Tiny ERP sans problèmes.

Le plan comptable fourni par défaut est le PCMN (plan comptable minimum normalisé belge). Les taxes fournies par défaut sont les belges mais tout cela se change en 5 minutes, sans nécessiter de programmation. Nous supportons même le système de taxes canadien.

Par contre, Tiny ERP ne sera jamais agréé, pour de nombreuses raisons;
. ce n'est pas ce que l'on recherche dans un ERP; on préfère un programme flexible à un programme agréé (par exemple, l'annulation de factures est très importante dans certaines métiers, mais illégal - cette fct peut bien sûr être inhibée).
. c'est trop spécifique à un pays, cela ne convient pas au développement libre

Mais la comptabilité est utilisée par tous nos clients sans aucuns problèmes depuis plus de 3 ans.

Je ne peux bien sûr pas offrir les frais de livraisons alors les voici pour vous éviter de tester:
. 1 poster: 4.99 EUR
. de 3 à 4 posters: 7.34 EUR
Pour la Belgique c'est moins cher. Ils sont postés dans des tubes pour ne pas les plier. S'il y a des t-shirts/sweats en plus, ils postés en 2 colis: 1 tub et une boite.

Ceux qui ne désirent pas payer la livraison peuvent passer en prendre chez moi: 18/002 rue de l'hocaille. 1348 LLN. Belgique.

Voila, le texte est changé; une erreur de ma part.
Et la référence à la GPL est mise dans les sources.

En effet ce dernier dispose d'un client en Java et d'une alternative en client léger (HTML, JSP) avec serveur d'application JBoss.
En fait, nous n'en avons jamais eu la demande mais on l'a déjà fait pour certaines choses (requêtes clients arrivent dans le système). Développer un client réduit Web ne doit prendre que quelques heures. Le rôle du client est très simple: parser un fichier XML décrivant l'interface et renvoyer le résultat. (par XML-RPC, SOAP ou via le système d'objets distribués), toutes les opérations sont traitées par le serveur (rapports, workflow, logique de la gui, ...)

son achitecture modulaire et flexible, permet-elle d'utiliser JasperReport ou JFreeChart en lieu et place d'OpenReport?
Plusieurs méthodes sont supportés:
* Les rapports créés et personnalisés via le client GUI directement: http://tinyerp.com/pict/screenshots/vente/terp29.jpg(...)
* Les rapports utilisant XSL:RML ou XSL:FO (sans programmation):
http://openreport.org/files/xsl:rml/product_catalog/openstuff.net/o(...)
Je conseille de loin XSL:RML à XSL:FO
* Tout autre méthode mais avec programmation: dans ce cas, il ne faut programmer que les appels, le serveur fournit les données dans un fichier XML (ou directement via SQL) à la structure de notre choix -> Seule la couche de présentation est à faire.

Oui, le terme PGI convient mieux. Des modules ERP sont on dével.
Il faudrait dire: ERP+CRM+SCM+GROUPWARE+...

Dans ce cas, on dit souvent ERP (en anglais)

Quelle lib python est utilisée pour la partie serveur SOAP (ZSI, SOAPpy, autre ) ?

Coté server, voir http://ose.sf.net(...)
Coté client, j'utilise xmlrpclib

Et aussi, la partie Load-Balancing est-elle effectuée au niveau PostgreSQL ou au niveau du serveur global ?
La distribution (load-balancing ou services différents sur différents ordis) se fait au niveau du serveur. Le serveur offre une interface au dessus de postgresql avec les fonctionnalités suivantes:
* orienté objets (héritages, méthodes, ...) -> orm
* row-level security
* gestion des contraintes, valeurs défauts,
* intégration dans le système de workflow, ...
La distribution ainsi que le serveur objet est du code à moi. Les patterns utilisés dans la distribution (publish/subscribe, request/reply, annoucement, ...) proviennent de http://ose.sf.net(...)

Il y a juste quelques "TODO" qui mériteraient d'être commentés (au niveau code pour ne pas apparaitre sur le site en ligne) afin de ne pas effrayer le client potentiel :)
C'est pour cela qu'il y a un site .com et un .org. Les clients sont redirigés vers le .com qui est complet. Malheusement, je n'ai pas bcp le temps de compléter le .org.


Le client en Python + GTK a l'air très abouti
Oui, il l'est et très ergonomique.

mais a t'il été envisagé de développer un client en XUL ? Mozilla a effet une lib standard pour faire des requètes SOAP. L'avantage principal d'un client XUL est un déploiement super simplifé : il suffit de mettre un .xpi sur le serveur ou même directement un fichier .xul si le client n'a pas besoin de composants XPCOM non standard.
Dans Tiny ERP c'est totalement différent:
* Seul le client fait du GTK. Tous les forms et trees sont automatiquement générés en fonction de la desription des objets. Il faut voir cela comme un méta-programme: on décrit les objets Tiny ERP et comment ils fonctionnent et le framework fait le reste (la gui, les interfaces, les relations, ...)
* L'interface SOAP (ainsi que xml-rpc, net-rpc et les accès objets) est gérée par OSE et le système de modules distribués de Tiny ERP.

Oui, c'est envisageable mais je ne le ferais pas.

Beaucoup de facilitéss de postgresql sont très utiles dans ce genre de logiciel: les contraintes, les références, les triggers, la réplication, ... Mettre tout cela au niveau de l'application augmenterais de beaucoup le développement à fournir et n'apporte que peu d'avantages.

J'ai oublié les liens:
* présentation commerciale: http://tinyerp.com(...)
* Site .org avec sources: http://tinyerp.org(...)
* Présenation (screenshots): http://tinyerp.com/tour.php(...)

Moi j'ai fais mon ERP/CRM en python avec la comptabilité automatisée. La compta n'est pas encore à la hauteur d'un prog. pro mais l'ERP et CRM si.
Le programme est assez mature: il est en production dans plusieurs PME depuis 8 mois.

Je viens de terminer le site web: http://tinyerp.com(...)

Actuellement je le donne sous licence Open Source à mes clients mais je ne diffuse pas encore la version Open Source. On travaille à la version .org du site qui devrait sortir vers le mois d'aout. (le temps de faire la doc, le prog d'install, ...)

Je peux donc envoyer le tar.gz si ca intéresse.

Oui, je suis d'accord. Mais comment faire ???

Oui, je trouve aussi que XSL:FO est trop complexe. Sans compter que FOP est trop lent, plante et ne supporte que la moitié des tags FO.

Pour ceux que ca intéresse, XSL:RML est une alternative à XSL:FO. C'est à la fois beaucoup plus simple, plus puissant et plus flexible. Le renderer est environ 15 fois plus rapide que FOP et supporte tous les tags de RML. (plus complet que FOP)

Quelques exemples de PDF générés en moins de 30 min de travail:
* http://auction-in-europe.com/docs/aie.pdf(...)
* http://openstuff.net/index.py/products_all(...) (cliquer sur le lien)
* http://openreport.org/download/devis.pdf(...)

Tout est dispo sur http://openreport.org(...)

Si tu as certains textes dont tu connais la langue, tu peux utiliser un filtre bayesien.

Quelques liens:
http://www.divmod.org/Home/Projects/Reverend/index.html(...)
http://www.lbreyer.com/gpl.html(...)
http://freshmeat.net/search/?q=bayesian&section=projects(...)

Perso, j'utilise le module reverand en python pour classer des objets selon leur description et je suis satisfait. Je recois en entrée des descriptions d'objets et je dois déterminer si c'est un meuble, de l'argenterie, un tableau, une sculpture, ...
Par exemple, 90% des objets de cette page sont classés automatiquement de cette manière: http://auction-in-europe.com/index.py/ant_arts(...)
J'ai environ 5% d'erreur mais les conditions sont dures: classer une description d'une ligne dans l'une des 30 catégories.

Un temps plein, travail divers mais surtout du développement.70% est en python.

Tiny ERP est un logiciel libre mais non encore distribué/publié car il n'y a pas d'install, de doc, de site. J'espère le publier dans 4 mois. Mais il est vendu en temps que libre chez mes clients, ils peuvent le modifier, publier, ... Je pense qu'il va fournir une alternative vachement meilleure que Compiere :) Il y a certaines personnes qui ont le code car ils en avaient besoin. Il y a par exemple une société qui paie un employé mi-temps pour m'aider dans le dével. Il tourne chez 4 sociétés. (LGPL) Mais je ne veux pas le sortir tant qu'il n'a pas d'install, de doc, ...
Openreport: Openreport.org (LGPL)
Openstuff: openstuff.net, le source du site eCommerce est libre. Les t-shirts c'est diffile de les mettre en libre. Une bonne partie des ventes vont en donations à des assoc Linux.
Tiny Commerce: on va travailler pour le publier bientot en GPL (site web, doc) car on vient de trouver qq'un qui va payer pour cela
Auction-in-Europe.com: pas libre car le source n'a aucun intérrêt à être publié. C'est juste un site web.

Je recherche un développeur de logiciels libre. On ne travaille que sur logiciel libre et on ne vend le dével. et fournit du service que pour logiciels libres.

Actuellement je suis seul mais je gagne assez pour 3 employés. J'ai du mal à suivre les commandes, alors j'engage 1 emplyé et 2 stagiaires.

Pour la création de PDF, je peux te conseiller: http://openreport.org(...)

Moi je me suis lancé.

Il fait/fera tout ce que fait compiere mais il est assez différent. Il est plutôt fait pour être rapidement spécialisé dans des domaines complètement différents. Bcp de chose de haut niveau n'existait pas ou n'était pas assez bien: un bon système de reporting (j'ai fait: openreport.org) , un bon ORM avec gestion des droits au niveau des rows, un système de workflow complet, la gestion des patterns d'applications distribuées et webservices (merci ose.sf.net), ...

Il fonctionne déjà depuis qq mois des des PME mais il n'est pas encore terminé (il fonctionne très bien mais il manque des features, et des grosses). Il gère déjà deux salles de vente publiques: compta/stocks/crm/logistique/suivi des requêtes. Je l'utilise aussi pour ma compta depuis... hier. J'espère le publier dans 3/4 mois avec doc, prog d'install, ...

En attendant, voila les screenshots: http://tiny.be/download/tiny_erp/screenshots/(...)

Les assert c'est bien aussi.

Contrairement au SPAM papier, c'est l'utilsateur qui paie lorsqu'il recoit du spam électronique. Ca permet aux entreprises, PME, indépendants, arnaqueurs d'abuse du SPAM électronique car ca ne coute presque rien. Et ca, c'est pas normal.

Ce qui est dérangeant dans le spam électronique ce n'est pas d'en recevoir un mais c'est le fait qu'on en recoit 100 par jour et qu'on est 'forcé' de les downloader. Je connais des gens pour qui le SPAM leur pourri la vie. Y'en a bcp qui n'ont pas encore de bons anti-spam.

Par contre, je suis pour la publicité sous toutes formes car c'est un bon moteur pour l'économie. L'idéal serait de faire payer l'envoi de SPAMS au nombre d'email envoyé.
On aurait alors une pub de qualité, moins abondante et plus ciblée.

Mets $i entre guillements: "$i"

Non, de décembre à maintenant, ca fait 8 semaines.

Evite la poste en mode non prioritaire.
Les 4 derniers que j'ai envoyé le mois passé ont pris 6 semaines.

J'oubliais:

J'écris ce journal car j'ai vu dans le code d'une application qu'on pouvait faire cela avec Oracle.

En gros, on peut mettre une fontion policy à un shema qui ressemble à un morceau de code qui s'ajoute au where pour vérifier les droits. Mais je ne connais pas Oracle. Est-ce possible en Postgresql.

Ca a l'air cool, vu dans le code de compiere:

DBMS_RLS.ADD_POLICY (
'Compiere', -- object_schema
t.TableName, -- object_name
t.TableName || '_Pol', -- policy_name
'Compiere', -- function_schema
'Compiere_Context.GetPredicate', -- policy_function
NULL, -- statement_types 'SELECT,INSERT,UPDATE,DELETE'
TRUE, -- update_check
);

Et la fontion Compiere_Context.GetPredicate:

...
Predicate := 'AD_Client_ID IN (' || SYS_CONTEXT('CompiereInc','ClientList')·
|| ') AND AD_Org_ID IN (' || SYS_CONTEXT('CompiereInc','OrgList') || ')';
...

De plus

Je pense qu'une page d'intro bien faite doit sufir à conscientiser le traducteur.
Du genre: si c'est mal fait on paie pas.

J'aurais du préciser.

Je réserve cela à mes petits sites ou aux miens.

Pour les miens, je préfère de loin avoir un site avec plusieurs langues quitte à avoir des petites erreurs (que l'on peut corriger) sur certaines pages. C'est très important quand l'on vend par VISA car: les gens préfèrent acheter dans les sites de leur pays (leur langue). C'est bon aussi pour Google.

Pour les petits sites, ce sont des sites où le client paie très peu et il crée/administre le site par lui même. Il peut donc corriger les éventuelles fautes lui-même. C'est juste pour lui éviter une partie du travail de création car cela complexifie tout et les gens sont très bêtes.

Pour mes gros clients, il est évident que je n'utiliserai pas ce système.

Par exemple, je viens de passer 3 jours à traduire l'un de mes plus gros sites en français. Je préfère de loin que quelqu'un le fasse quitte à passer 2 heures à améliorer les tournures de certaines phrases. J'ai fait le test avec ma copine: elle a traduit pdt 1 jour et demi un site de l'anglais vers le français, il m'a fallu une heure pour améliorer certaines choses.

Bien sûr, il y aura un système de validation.

Pour un traducteur professionnel:

1. c'est 8 fois plus cher que mon système. Je veux traduire mes sites où je vends par VISA en bcp de langues.
2. c'est bcp de travail car il faut lui donner dans un bon format et réintégrer tout cela dans les templates. La plupart des pages dynamiques n'ont que quelques mots plic-ploc à traduire.
3. Quand je modifie juste la description d'un seul produit, je ne peux pas passer par 10 traducteurs. Il faut que le système s'améliore constement de lui même en faisant quelques EUR de réduction par ci par là sur les commandes.