[Erp5-dev] tutorial

[Yoshinori Okuji]

In the description of PaySheetTransaction:

Cette classe d?rive de la classe de base Folder via Invoice. Nous avons choisi
cet h?ritage car les objets de type PaySheetTransaction vont nous servir ?
regrouper au m?me endroit les objets relatifs ? une feuille de paie. C'est
pour cela que PaySheetTransaction n'a pas comme classe anc?tre l'une des 5
classes de base d'ERP5. Folder est en quelque sorte une "classe utilitaire"
qui nous permet de r?duire l'entropie du syst?me.

This paragraph is impossible for me to understand. I don't see why
PaySheetTransaction does not derive from any of the 5 basic classes, only
from this description. What does "? regrouper endroit les objets relatifs ?
une feuille de paie" mean here?

Kevin, could you elaborate on this?

YO

[Kevin Deldycke]

Post by Yoshinori Okuji
Cette classe d?rive de la classe de base Folder via Invoice. Nous avons
choisi cet h?ritage car les objets de type PaySheetTransaction vont nous
servir ? regrouper au m?me endroit les objets relatifs ? une feuille de
paie. C'est pour cela que PaySheetTransaction n'a pas comme classe anc?tre
l'une des 5 classes de base d'ERP5. Folder est en quelque sorte une "classe
utilitaire" qui nous permet de r?duire l'entropie du syst?me.
This paragraph is impossible for me to understand. I don't see why
PaySheetTransaction does not derive from any of the 5 basic classes, only
from this description. What does "? regrouper endroit les objets relatifs ?
une feuille de paie" mean here?
Kevin, could you elaborate on this?

PaySheetTransaction is a subclass of Invoice. As we can see in
Products/ERP5/Document/PaySheetTransaction.py :
** class PaySheetTransaction(Invoice)

Invoice is a subclass of AccountingTransaction:
** class Invoice(AccountingTransaction)

Invoice is a subclass of AccountingTransaction:
** class Invoice(AccountingTransaction)

AccountingTransaction is a subclass of Delivery:
** class AccountingTransaction(Delivery)

Delivery is a subclass of XMLObject:
** class Delivery(XMLObject)

And XMLObject is a subclass of folder (see Products/ERP5Type/WMLObject.py) :
** class XMLObject( Folder )


So the PaySheetTransaction is a subclass of the Folder Class. That's a fact.
When I have build the payroll system, I used Accouting Transaction module as
a model. And at this moment, Folder was a parent of AccountingTansaction (and
it's always the case). If you think that this class relationship is not
correct, please tell me.

In my paragraph I try to explain why PaySheetTansaction is not a subClass of
any of the 5 basic class : because PaySheetTansaction is a place where
paysheet-related objects are stored. Folder is just a utility class to
classify and regroup objects. If you have a better way to explain this, I
will be happy.

"objets de type PaySheetTransaction vont nous servir ? regrouper au m?me
endroit les objets relatifs ? une feuille de paie" -> We will use
PaySheetTransaction objects to store every paysheet-related sub-objects (like
PaySheetLine and PaySheetTransactionLine).

Kev

[Yoshinori Okuji]

Post by Kevin Deldycke
So the PaySheetTransaction is a subclass of the Folder Class. That's a
fact. When I have build the payroll system, I used Accouting Transaction
module as a model. And at this moment, Folder was a parent of
AccountingTansaction (and it's always the case). If you think that this
class relationship is not correct, please tell me.
In my paragraph I try to explain why PaySheetTansaction is not a subClass
of any of the 5 basic class : because PaySheetTansaction is a place where
paysheet-related objects are stored. Folder is just a utility class to
classify and regroup objects. If you have a better way to explain this, I
will be happy.
"objets de type PaySheetTransaction vont nous servir ? regrouper au m?me
endroit les objets relatifs ? une feuille de paie" -> We will use
PaySheetTransaction objects to store every paysheet-related sub-objects
(like PaySheetLine and PaySheetTransactionLine).

Thank you for your help. I now understand what you meant.

But this suggests that ERP5 actually has 5+1... This is a bad sign.

YO

[Yoshinori Okuji]

A mistake in the tutorial is that the permission is 755. There is no reason
why you should enable executable bits. So it should be 0644, instead.

YO

[Kevin Deldycke]

Post by Yoshinori Okuji

Post by Kevin Deldycke
So the PaySheetTransaction is a subclass of the Folder Class. That's a
fact. When I have build the payroll system, I used Accouting Transaction
module as a model. And at this moment, Folder was a parent of
AccountingTansaction (and it's always the case). If you think that this
class relationship is not correct, please tell me.
In my paragraph I try to explain why PaySheetTansaction is not a subClass
of any of the 5 basic class : because PaySheetTansaction is a place where
paysheet-related objects are stored. Folder is just a utility class to
classify and regroup objects. If you have a better way to explain this, I
will be happy.
"objets de type PaySheetTransaction vont nous servir ? regrouper au m?me
endroit les objets relatifs ? une feuille de paie" -> We will use
PaySheetTransaction objects to store every paysheet-related sub-objects
(like PaySheetLine and PaySheetTransactionLine).

Thank you for your help. I now understand what you meant.
But this suggests that ERP5 actually has 5+1... This is a bad sign.

No no no. The 5 basic classes are designed to represent any businness in any
company. The "+1" class has no connection with the Universal Business Model.
It's just a convenient way to classify documents and it doesn't change the
fundamental model. The rules and statements that drive the UBM are not
invalidated by removing the "+1".

So IMO it's not a bad sign.

[Yoshinori Okuji]

I found a bug in the tutorial. In the section "Le reporting", it says Page
Template, but actually it uses PDF Template.

YO