[Erp5-dev] Re: Questions on Workflows and ERP5 I

[Rogério Atem de Carvalho]

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

>
>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.


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.
>
>
>
>>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?
>
>

>>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.
>
>
>>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).

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!

>>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.

>>Also, consider the following names

>>    Purchase Tender
>>    Purchase Offer
>>    Sale Offer
>>    Sale Tender

Ok.

>>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,
>
>
>>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?
>
>
>
>>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.

>>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.

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?
>
>
>>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?
>
>

>>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,
>
>
>>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
>
>
>>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.

Sure.

>>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...

>>My feeling is that you are planning to compare the consequences of the
>>choise of one Offer against another (right ?).

Yes!

>>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.

>>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.

>>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