[Erp5-dev] Questions on Workflows and ERP5 I

[Rogério Atem de Carvalho]

Hi,

this message contains an email exchange between I an JP about workflows and
ERP5. I asked once and JP answered. I will also post a second message, with
some more questions.

Read the text below.
--
Prof. Rog?rio Atem de Carvalho, D.Sc.
CEFET Campos

Hi!
1)We use DCWorkflow to model the process inside ERP5. This means
that we create state machines to represent processes.

Yes.

2)A process is a collaboration of many objects of many different
classes, instances of subclasses of the 5 basic concepts.

Yes. In a certain sense only.

The 5 basic concepts of ERP5 are essential for analysis but they are
unrelated to the documents which are managed by workflows.

For example, in a packing list, the main concept is Movement. Movement
can be at the level of lines or cells of the packing list.

However, the workflow is attached to the Packing List (which contains
Delivery Lines which contain Delivery Cells) because, from the user
point of view, the meaningful document concept is not the movement but
the "group of movement" ie. the Packing List.

The 5 core classes of ERP5 are therefore only a model for analysts.
Because workflows must be attached to documents (so that user can
understand them), workflows should not be considered based on the ERP5
model but on the processes in the company to handle "real world" documents.

3)Inside Zope, a workflow must be associated to a type, or a class in UML
terms.

Yes. A workflows is actually associated to multilple classes.

However, some classes (ex. Packing List Line) are not associated to any
worklow yet acquire workflow state (ex. simulation_state) for parent
Packing List. This is an example of the combination of workflows and
acquisition to map workflow states onto documents which are closer to
the core ERP5 classes.

4)Does that mean that I have to create a type that represents the process
and then associate it to the workflow that actually implements
the activities of the process?

This is right. If there is a process, then the process must be visible
on corporate documents (ex. a Packing List, ex. a Sourcing Order, etc.).
Everything about the current state in a process and the history of
decisions related to that process should be readable on that document.

For instance, let?s suppose I have a purchasing process.

OK.

I have to create a new python class called Purchase and

It is better to call it something else. Reserved are:
Purchase Order -> the actual purchase order
Purchase Packing List -> the actual purchase order
Purchase Invoice -> the actual purchase order

Now first of all, before you think about classes, think about documents
(I forgot a bit our work last year, sorry). You must answer to the question
"if we are in a paper world, which papers would be used to manage
the company"

Also, consider the following names

Purchase Tender
Purchase Offer
Sale Offer
Sale Tender

You must also make sure that things are 100% symetric. For example
Purchase Invoice from A to B == Sale Invoice from B to A

then create a DCWorkflow that will implement the business process itself,

Before you implement the DCWorkflow, you must answer the question
"what stamps would people use to track the status of this document"

associating this specitfic workflow to the Purchase type.
This workflow will manipulate many objects of classes derived from Item,
Resource,
and Node. Is that correct?

Once the document analysis is completed, you are going to analyse each
part in the documents using the 5 core abstract classes, the decide
which implementation subclasses of teh core abstract classes will be used.

I suppose that a Purchase Tender would look very similar to a Purchase Order
Purchase Tender
includes
Purchase Tender Line
includes
Purchase Tender Cell

With property sheets which define some criteria (predicates).

Once you know which predicates you need, I will have to explain to you
how I had to simplify ERP5 predicate system.

Other question: is a movement object a instantiation of a Path object?

In a sense yes. However, an order line (path) in an order can serve as a
template template for an order line (movement) in a future order. This
shows that an order line is both a subclass of movement and a sublass of
path.

I mean, path objects represent the abstraction and movements represent
the realization of this abstractions?

Yes. Path movements are associated a predicate which define the
conditions under which they server as a "factory" of realized movements.

Last question: are the process subclasses of Path, I mean, in the example
above,

No, I do not think so. There are no processes in ERP5 besides
DCWorkflows. ERP5 is document oriented, which means that processes are
always handles through or as a document.

I would create Purchase as a subclass of path and then associate a

see suggestion above
Purchase Tender (subclass of Delivery or similar to Delivery)
Purchase Tender Line
Purchase Tender Cell

workflow to it that would make many Item and Resource objects collaborate
to achieve the business logic? What is the relation between Paths, Movemen

Resources are only use as a way to define what is being tendered on each
Purchase Tender Line.

ts
and DCWorkflows?

DCWorkflows are used to track the decisions related to the Purchase Tender.

At some point, I suppose that Purchase Offer s will be created and
related to the Purchase Tender. I think that Purchase Offer are nearly
like Purchase Orders. For simplification, it might be a good idea to
implement Purchase Offers as Purchase Orders by adding an additional
workflow to Orders in ERP5. Of course, it is also possible to split
Offers and Orders in 2 different modules. It is always the same
question: "simplify or provide detailes implementation ?".

My feeling is that you are planning to compare the consequences of the
choise of one Offer against another (right ?). It might be useful in
this case to use the ERP5 simulation to calculate all consequences
(financial, etc.) of one Offer against another. This will require an
extra state in the simulation system and an extra argument in the
ZSQLCatalog to identify multiple scenarii.

Supposing all this is implemented, the choice of one Offer against
another will be implemented as a workflow step, with scripts to provide
informatin about the consequences of each offer and scripts to clean up
the system after an offer has been chosen. (an order must be generated
from the Offer).

I will spend more time on this.

JPS.

Thanks for the help,
keep in touch,
Rogerio

________________________________________________
Mensagem envida por CEFET -
CAMPOS 2.7

[Rogério Atem de Carvalho]

Hi! This email continues the previous one, with some more questions.

1)We use DCWorkflow to model the process inside ERP5. This means
that we create state machines to represent processes.

Post by Rogério Atem de Carvalho
Yes.

2)A process is a collaboration of many objects of many different
classes, instances of subclasses of the 5 basic concepts.

Post by Rogério Atem de Carvalho
Yes. In a certain sense only.
The 5 basic concepts of ERP5 are essential for analysis but they are
unrelated to the documents which are managed by workflows.
For example, in a packing list, the main concept is Movement. Movement
can be at the level of lines or cells of the packing list.
However, the workflow is attached to the Packing List (which contains
Delivery Lines which contain Delivery Cells) because, from the user
point of view, the meaningful document concept is not the movement but
the "group of movement" ie. the Packing List.
The 5 core classes of ERP5 are therefore only a model for analysts.
Because workflows must be attached to documents (so that user can
understand them), workflows should not be considered based on the ERP5
model but on the processes in the company to handle "real world"

documents.


at the current moment, we are pushing our efforts (master thesis,
informal discussions and even code generation) towards a "UMLish"
process for ERP5 based modeling and deployment.

This means that we need to map ERP5 "way of thinking" to UML
artifacts, like Class, State and Use Cases Diagrams. And also,
create a specific variation of the Unified Process to it.
Attention: it is not the Rational Unified Process, but the
IEEE standard Unified Process.

I see a possible solution as follows:

1) The 5 concepts are used to derive subclasses that represent
the entities of the bussiness process. They collaborate to actually
realize the process. They are relatively passive.

2) For every process there is also a "Controller" class that represents
the own process: it holds attributes and is associated to the
workflow (a state machine) that, in the end, will implement the process.
This controller class is in Zopish language the document. And it is
active.

In your example above this means that, in UML, the Packing List is the
controller, that send commands to the entities (lines and cells), which are,
in turn, based on the 5 basic concepts.

3)Inside Zope, a workflow must be associated to a type, or a class in UML
terms.

Post by Rogério Atem de Carvalho
Yes. A workflows is actually associated to multilple classes.
However, some classes (ex. Packing List Line) are not associated to any
worklow yet acquire workflow state (ex. simulation_state) for parent
Packing List. This is an example of the combination of workflows and
acquisition to map workflow states onto documents which are closer to
the core ERP5 classes.

Ok. Really the document is the controller. Very nice, althoug note usual.
One question: Can a workflow be associated to more than one type (class)
of document, each type related to different phases of the business process?
For instance, in a planning process I would have a document type to
represent
the aggregated planning, another to represent productions orders and others,
associated to one "planning" workflow?

4)Does that mean that I have to create a type that represents the process
and then associate it to the workflow that actually implements
the activities of the process?

Post by Rogério Atem de Carvalho
This is right. If there is a process, then the process must be visible
on corporate documents (ex. a Packing List, ex. a Sourcing Order, etc.).
Everything about the current state in a process and the history of
decisions related to that process should be readable on that document.

Ok. This is one more thing that points us to the use of the "controller"
concept
(pattern).
The controller reflects on its attributes the state changes of the process.

For instance, let?s suppose I have a purchasing process.

Post by Rogério Atem de Carvalho
OK.

I have to create a new python class called Purchase and

Post by Rogério Atem de Carvalho
Purchase Order -> the actual purchase order
Purchase Packing List -> the actual purchase order
Purchase Invoice -> the actual purchase order
Now first of all, before you think about classes, think about documents
(I forgot a bit our work last year, sorry).

No problem. We think in terms of modeling a document as a class, inside a
class diagram. This is very important to:

1)Given the ever growing acceptance of UML, including for business modeling,
we have to create a UMLish dialect for ERP5 modeling.
2)With things represented in UML we can generate (and even validate, at some
extent) code!

Post by Rogério Atem de Carvalho
You must answer to the question
"if we are in a paper world, which papers would be used to manage
the company"

Ok. This is being considered to the creation of the reference process
for modeling.Actually, this is where "everything starts" for us.

Post by Rogério Atem de Carvalho
Also, consider the following names
Purchase Tender
Purchase Offer
Sale Offer
Sale Tender

Ok.

Post by Rogério Atem de Carvalho
You must also make sure that things are 100% symetric. For example
Purchase Invoice from A to B == Sale Invoice from B to A

Interesting. But I didn?t stop to think about this yet.

then create a DCWorkflow that will implement the business process itself,

Post by Rogério Atem de Carvalho
Before you implement the DCWorkflow, you must answer the question
"what stamps would people use to track the status of this document"

Ok. Also being considered for the reference process.

associating this specitfic workflow to the Purchase type.
This workflow will manipulate many objects of classes derived from Item,
Resource,
and Node. Is that correct?

Post by Rogério Atem de Carvalho
Once the document analysis is completed, you are going to analyse each
part in the documents using the 5 core abstract classes, the decide
which implementation subclasses of teh core abstract classes will be used.

Ok.

Post by Rogério Atem de Carvalho
I suppose that a Purchase Tender would look very similar to a Purchase

Order

Post by Rogério Atem de Carvalho
Purchase Tender
includes
Purchase Tender Line
includes
Purchase Tender Cell
With property sheets which define some criteria (predicates).
Once you know which predicates you need, I will have to explain to you
how I had to simplify ERP5 predicate system.

Ok. It was only an example, but since you started to talk about
the real thing, could we use the purchase process as an example, to
help people think in broader terms?
I mean, we could use this example to show people how to things
inside ERP5, and then, afterwards, expand this to the reference process.

Other question: is a movement object a instantiation of a Path object?

Post by Rogério Atem de Carvalho
In a sense yes. However, an order line (path) in an order can serve as a
template template for an order line (movement) in a future order. This
shows that an order line is both a subclass of movement and a sublass of
path.

Ok.

I mean, path objects represent the abstraction and movements represent
the realization of this abstractions?

Post by Rogério Atem de Carvalho
Yes. Path movements are associated a predicate which define the
conditions under which they server as a "factory" of realized movements.

Can you talk more about predicates, and give an example?

Last question: are the process subclasses of Path, I mean, in the example
above,

Post by Rogério Atem de Carvalho
No, I do not think so. There are no processes in ERP5 besides
DCWorkflows. ERP5 is document oriented, which means that processes are
always handles through or as a document.

Ok.

I would create Purchase as a subclass of path and then associate a

Post by Rogério Atem de Carvalho
see suggestion above
Purchase Tender (subclass of Delivery or similar to Delivery)
Purchase Tender Line
Purchase Tender Cell

workflow to it that would make many Item and Resource objects collaborate
to achieve the business logic? What is the relation between Paths, Movemen

Post by Rogério Atem de Carvalho
Resources are only use as a way to define what is being tendered on each
Purchase Tender Line.

ts
and DCWorkflows?

Post by Rogério Atem de Carvalho
DCWorkflows are used to track the decisions related to the Purchase

Tender.

Post by Rogério Atem de Carvalho
At some point, I suppose that Purchase Offer s will be created and
related to the Purchase Tender.

Sure.

Post by Rogério Atem de Carvalho
I think that Purchase Offer are nearly
like Purchase Orders. For simplification, it might be a good idea to
implement Purchase Offers as Purchase Orders by adding an additional
workflow to Orders in ERP5. Of course, it is also possible to split
Offers and Orders in 2 different modules. It is always the same
question: "simplify or provide detailes implementation ?".

I would go for detailed...

Post by Rogério Atem de Carvalho
My feeling is that you are planning to compare the consequences of the
choise of one Offer against another (right ?).

Yes!

Post by Rogério Atem de Carvalho
It might be useful in
this case to use the ERP5 simulation to calculate all consequences
(financial, etc.) of one Offer against another. This will require an
extra state in the simulation system and an extra argument in the
ZSQLCatalog to identify multiple scenarii.

Yes.

Post by Rogério Atem de Carvalho
Supposing all this is implemented, the choice of one Offer against
another will be implemented as a workflow step, with scripts to provide
informatin about the consequences of each offer and scripts to clean up
the system after an offer has been chosen. (an order must be generated
from the Offer).

Yes.

Post by Rogério Atem de Carvalho
I will spend more time on this.

Great!

If you could tutor me in the creation of this module (UMLish
speaking: a component), it will be a huge help for everybody here in Brasil.

Thanks for the help,

keep in touch,

--
Prof. Rog?rio Atem de Carvalho, D.Sc.
CEFET Campos

________________________________________________
Mensagem envida por CEFET -
CAMPOS 2.7