New resources available for OpenERP: Process and Training Plans

Greetings,

There’s definitely a lot of things happening this month, and not just the V6 which begin to come. Here at Synerpgy, there is no less than three new important process that was modeled and two training plans now freely available on our website.

Thus, we can include :

About training plans, the entire accounting training plan is now available on the site. Moreover, the first part (development through graphical interface) of the technical training plan is also available. I hope these training plans can help people who can’t or don’t want to pay for training.

Unfortunately, and as usual, these resources are only in French, sorry for the english-speaking people. If someone want to translate, feel free.

All these documents are licensed as Creative Commons by-sa, do not hesitate to use it as long as you meet the conditions of the license. See you later!

De nouvelles ressources disponibles pour OpenERP : Processus et Plans de formation

Bonjour à tous,

Il y a décidément beaucoup de choses qui bougent en ce moment, et pas seulement la V6 qui commence à pointer doucement le bout de son nez. Chez nous c’est ni plus ni moins que trois nouveaux processus importants qui sont modélisés et deux plans de formation désormais librement accesible sur notre site internet.

Citons ainsi :

Au niveau des plans de formation, l’intégralité du plan de formation comptabilité est désormais accessible sur le site. Par ailleurs, la première partie du plan de formation technique concernant le développement par interface graphique est également disponible. J’espère que ces plans de formation pourront aider les personnes qui n’ont pas forcément les moyens de payer une formation, et quand aux autres et bien vous savez qui appeler ;).

Tous ces documents sont comme d’habitude sous licence Créative Common by-sa, n’hésitez pas à vous en servir tant que vous respectez les conditions de la licence. A la prochaine!

Release of the first process OpenERP: Sales Management

Greetings,

In order to keep improving our services and our customers’s satisfaction, we continue to refine our various working papers that we publish as usual.

The document published today is a BPMN diagram of sales process OpenERP’s. These diagrams, which I call “generic processes” are our working basis when we work with the customer during the study phase. Beware that these diagrams are only in French, cause of a leak of time. Feels free to translate it if you want.

Then, according to this diagram, we can adapt the document thanks to customer’s comments and thus shape very precisely the future operation of the client company under OpenERP. Thus, we can more easily identify during the study phase of the main points that the client wants to see revised at this time an adequate vision of the future operation of his company.

For now, only the sales process is modeled, as well as mini-processes of creation of partners and products. I think it was also about one of the most complex processes, because it is the central process, the one which is connected to virtually everyone else.
I hope to release other processes quickly (we need them) including the billing process, the manufacturing-stock-purchase process, the project-analytic accounting process, CRM processes and finally Magento synchronization process. I hope (probably foolishly) release them before the end of the month, so keep an eye on the site.

I finally point out that the goal of the “generic processes” is completeness. When we work with the customer, the main purpose is is to simplify the process and not the opposite. Processes by sector will be created later on this basis so as to refine the matching between the processes and pave the way for other types of performances.

As usual, all our documents are available under CC by-sa license, so feel free to use them, modify them if necessary and to send us your improvements. Especially if Tiny would come to use them for the futures versions, would be great, otherwise you can rely on us to keep them updated.
We will be careful about just one thing: the respect for the assignment clause. Please do not remove our name, it’s still a lot of work that is done and that’s the bare minimum we can ask.

You can find diagrams here : http://www.synerpgy.fr/processus

See you soon, I’ll prepare another surprise for the next few days.

Sortie du premier processus OpenERP : Gestion des ventes

Bonjour à tous,

Dans l’objectif de toujours améliorer nos prestations et la satisfaction de nos clients, nous continuons à perfectionner nos différents documents de travail, que nous publions comme d’habitude.

Le document qui est publié aujourd’hui n’est ni plus ni moins qu’un diagramme BPMN du processus de vente d’OpenERP. Ces diagrammes, que je nomme “processus génériques” sont notre base de travail quand nous intervenons chez le client lors de la phase d’étude. Attention, par manque de temps le schéma est uniquement en français. Sentez-vous libre de le traduire si vous le souhaitez.

Sur la base de ce diagramme, nous pouvons ensuite l’adapter suite aux remarques du client et modéliser ainsi très précisément le fonctionnement futur de la société cliente sous OpenERP. Ainsi, nous pouvons beaucoup plus facilement repérer lors de la phase d’étude les principaux points que le client voudra voir corriger et lui donner à ce moment là une vision suffisante du fonctionnement futur de sa société.

Pour l’instant seul le processus de vente est modélisé, ainsi que des mini-process de création de partenaires et de produits. Je pense qu’il s’agissait également d’un des plus complexes car il s’agit du processus central, celui qui est relié à pratiquement tous les autres.
J’espère sortir les autres processus rapidement (nous en avons besoin) notamment le processus de facturation, le processus fabrication-stock-achat, le processus projet-comptabilité analytique, processus CRM et enfin processus synchronisation Magento. J’espère (probablement follement) les sortir avant la fin du mois, donc surveillez le site.

Je précise enfin que l’objectif des “processus génériques” est l’exhaustivité. Quand nous intervenons chez le client, l’objectif et de surtout avoir à simplifier le processus et pas l’inverse. Des processus par secteurs d’activités seront plus tard créés sur cette base afin d’affiner l’adéquation des processus et de préparer le terrain pour d’autres types de prestations.

Comme d’habitude, tous nos documents sont disponible sous licence CC by-sa, donc n’hésitez pas à les utiliser, à les modifier si nécessaire et à nous faire parvenir vos améliorations. Notamment si l’éditeur en venait un jour à les utiliser pour les futures versions cela serait génial, mais sinon vous pouvez compter sur nous pour les tenir à jour.
Nous serons juste vigilant sur un point : le respect de la clause attribution. Ne vous amusez pas à retirer notre nom, c’est quand même un gros travail qui est abattu et c’est bien le strict minimum que nous pouvons demander.

Vous pouvez trouver les processus ici : http://www.synerpgy.fr/processus

A très bientôt, je vous prépare une autre surprise pour les prochains jours.

Suggestion d’amélioration au niveau des droits d’accès d’OpenERP

Bonjour à tous,

J’aimerai vous faire part de quelques réflexions que je me fais au niveau du support des droits d’accès dans OpenERP, et comment je pense qu’il serait souhaitable de les améliorer.

Les droits d’accès dans OpenERP sont déjà très bien implémentés, en permettant notamment :
-De mettre des droits d’accès sur les différents menus, ou au niveau de l’action sur lesquels ils pointent.
-De mettre des droits d’accès sur l’objet lui-même, avec droit lecture/écriture/création/suppression.
-De définir des droits sur les champs eux-mêmes, soit au niveau de la vue soit au niveau de l’objet.
-De définir de la segmentation avec un moteur de règles d’accès qui est à mon sens déjà très puissant.

Ces outils permettent selon moi de faire face à une bonne partie des situations où les droits d’accès sont nécessaires, que ce soit si on veut interdire globalement l’accès à un objet, bloquer un menu spécifique, agir sur un champ en particulier ou ne donner accès qu’à une partie des enregistrements d’un objet (une partie des partenaires par exemple).

Il y a toutefois un cas qui n’est pas couvert, et je pense que les besoins des entreprises sont tels que ce cas pourrait se révéler très rapidement bloquant. Ce cas c’est la dualité lecture/écriture sur les droits d’accès.

Certes on le retrouve au niveau des objets, mais pas au niveau des droits des champs ou au niveau des règles d’accès.
Ainsi, si on met un droit sur un champ, alors ce champ disparait de l’interface de l’utilisateur n’ayant pas les droits même si on aurait voulu qu’il conserve un droit en lecture sur le champ et que seul le manager ait le droit en écriture.
De même, si par exemple un utilisateur ne remplit pas les conditions pour les règles d’accès sur un enregistrement de partenaire, alors il ne pourra même pas consulter l’enregistrement en lecture.

Pourtant, le cas où une entreprise a besoin de donner accès en lecture au plus grand nombre à une information tandis que seuls quelques personnes peuvent le modifier est très courant.
Par exemple, imaginer les commerciaux qui ont accès aux devis de la gestion des ventes. Aujourd’hui, tous ont accès en écriture aux devis de tous les commerciaux, alors que normalement ils ne devrait avoir accès en écriture qu’à leurs devis, et en lecture sur les autres car ils peuvent avoir le client d’un autre commercial au téléphone et avoir besoin de consulter l’offre qui lui a été faite.
Je pense ainsi que c’est une amélioration importante à effectuer sur le coeur d’OpenERP, OpenObject.

Je propose de remplacer le many2many des droits d’accès au niveau des droits des éléments des vues, des champs des objets et des règles d’accès par deux many2many, l’un qui renseignerai les groupes ayant le droit en lecture et l’autre qui renseignerai les groupes ayant le droit en écriture sur le champ ou l’enregistrement.

Bien entendu, le principe de cumul qui prévaut dans le système de droit d’OpenERP s’applique aussi ici.
Si l’utilisateur est membre d’un ou plusieurs groupes ayant le droit en lecture, il aura le droit en lecture. (Je précise que le droit en lecture n’est pas suffisant pour activer les boutons de workflow de l’enregistrement, par exemple confirmer une commande de vente)
Si il est membre d’un groupe ayant le droit en lecture et un autre ayant le droit en écriture sur le même champ ou enregistrement, alors il aura le droit en écriture.
Si il n’est membre d’aucun groupe ayant au moins le droit en lecture, le champ n’apparaitra pas sur son écran.

Il s’agit réellement du seul reproche que je peux faire à l’actuel système de droit d’accès. Avec cette correction, je pense que il n’y aura plus une seule situation où le système de droit d’accès ne sera pas capable de faire face.

J’ai déjà transmis mes remarques à Tiny, attendons de voir ce qu’ils en pensent. En attendant, n’hésitez pas à réagir dans les commentaires.

Improvement suggestion about access right in OpenERP

Greetings,

I’d like to share with you some thoughts that I had about support of access rights in OpenERP, and how I think it should be improved.

Access rights in OpenERP are already well implemented, in particular by:
-To set access rights on various menus, or at the level of the action on which they are linked.
-To set access rights on the object itself, with the right read / write / creation / deletion.
-To define the rights to the fields themselves, either at views or at the object level.
-To define the segmentation between records with access rules which I think are already very powerful.

These tools allow to deal with a lot of situations where access rights are needed, for example if we want to prohibit access to an object, block a specific menu, act on a particular field or allow access to only some records of an object (some of the partners, for example).

But there is a case not covered, and I think that business needs are such that this case could be very fast blocker. This case is the dual read / write access rights.

It is found in objects, but not in the fields or at the level of access rules.
Thus, if we put a right in a field, then this field disappears from the user interface who does not have the rights even if we wanted him to keep right on reading the field while the manager has the right to write.
Similarly, if for example a user does not qualify for access rules to access a record partner, then he can not even see the record.

However, case where a company needs to give read access to the largest number to information while only few people can change it is very common.
For example, imagine the case where salesmen have access to specifications of sales management. Today, everyone has write access to the quotation of all salesmen, whereas normally they should have write access to their quotations, and read about others because they can have a call with a customer of another salesman and need to consult the offer that was made.

I propose to replace the many2many access rights on elements views, fields on models and access rules by two many2many, one with groups with the read rights and the other with groups with write rights to the field or record.

Of course, the principle of accumulation of rights that prevail in the OpenERP system also applies here.
If the user is a member of one or more groups with the right reading, it will have the right read. (I should note that the read right is not sufficient to activate the buttons workflow of the record, for example to confirm an order of sale)
If he is a member of a group with the right reading and another with the right write which applied to the same field or record, then he will have the right to write.
If he is not a member of any group having at least the right read, the field will not appear on the screen.

This is really the only criticism I can make to the current access right system. With this correction, I think there will be no situation where the access right system will not be able to cope.

I already sent my comments to Tiny, let’s see what they think. In the meantime, feel free to respond in the comments.