[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!
>
>I hope I am not asking anything stupid:
>
>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