Department Request (DPRQ) Contents Introduction Workflow rules Overview of DR routing Routing for a division or an experiment Routing for a project DPRQ amount over 200k CHF Commercial Signature Buyer Signature Access Rights How to approve/reject a DR? How to cancel a DR? In case of problems Introduction Purchase procedures such as Departmental Requests, Market Surveys, Invitation to tenders or Price Inquiries are potential commitments to make expenditures and, as such, have to follow precise authorization procedures before they can be launched. As a first step in the introduction of workflow for CFU, it is possible to automatically route and authorize Departmental Requests. You will find in this page all the information you need to be able to start the routing of/approve/reject or cancel your DR. Divisional Request and Divisional Request Document It is important to clearly define the following terms: • A Divisional Request (DR) is a request initiated in the Divisions to launch a Purchase Procedure, Market Survey, Price Enquiry, Invitation to Tender etc ... in the SPL services. Departmental Requests and all related data are created in EDH. When Departmental Requests are created they generate a unique EDH document number, once sent the DR generates a unique ID number (in the format DR- nnnnn/Division/Project). This number is generated using the department (figure 1, point 3) and project (figure 1, point 4), it will appear at point number 2 in figure 1 below.
Transcript
Department Request (DPRQ)
Contents
IntroductionWorkflow rulesOverview of DR routingRouting for a division or an experimentRouting for a projectDPRQ amount over 200k CHFCommercial SignatureBuyer SignatureAccess RightsHow to approve/reject a DR?How to cancel a DR?In case of problems
Introduction
Purchase procedures such as Departmental Requests, Market Surveys, Invitation totenders or Price Inquiries are potential commitments to make expenditures and, as such,have to follow precise authorization procedures before they can be launched.
As a first step in the introduction of workflow for CFU, it is possible to automaticallyroute and authorize Departmental Requests. You will find in this page all the informationyou need to be able to start the routing of/approve/reject or cancel your DR.
Divisional Request and Divisional Request Document
It is important to clearly define the following terms:
• A Divisional Request (DR) is a request initiated in the Divisions to launch aPurchase Procedure, Market Survey, Price Enquiry, Invitation to Tender etc ... inthe SPL services. Departmental Requests and all related data are created in EDH.When Departmental Requests are created they generate a unique EDH documentnumber, once sent the DR generates a unique ID number (in the format DR-nnnnn/Division/Project). This number is generated using the department (figure1, point 3) and project (figure 1, point 4), it will appear at point number 2 infigure 1 below.
Fig 1: Overview of DR number generation and EDH Document number
• A Divisional Request Document is created when a user presses the "Send"button, it is a document which summarize DR data and which is used to collect allauthorizations which are requested before the Purchase Procedure may belaunched. It is possible that several DR Documents are created for one singleDepartmental Requests. This may happen for example if not all authorizationshave been collected on the first attempt to route the DR, and a subsequentrouting is started.When a DR document is created it receives an internal EDH document number(See Figure 1 above, point 1.) , which is then used to retrieve the document: forexample, https://edh.cern.ch/Document/DivisionalRequest/2493666
It is important to understand that the content of the Divisional Request and theinformation related to the routing of this Divisional Request are clearly separated.
Workflow rules
The rules for the authorization of Departmental Requests have been discussed andagreed during meetings of the CFU Coordination group, between representatives of allsectors. The coordination group has successfully defined workflow rules common to allDivisions/Projects and Experiments. These rules are based on role assignments held inthe AIS Foundation database, which are made available to the CFU application.
General principles of DPRQ routing
For all type of organization Units involved, the following principles apply:
• If the person contacted for authorisation is absent, the DPRQ document will berouted to his/her deputy, as defined in the AIS Foundation database;
• Nobody is asked twice for an authorization. Once a person has approved thedocument if his/her approval is required for another role automatically is skipped;
• 3 days absence delay.
Overview of DR routing
2
3 4
1
Fig 1: Overview of DR routing
As you may see in Fig 1, routing takes place following axes:
• within the Organization or Experiment hierarchy, with the process named " Multiorganization Unit"
• Within the Project hierarchy, with the process named "Multi project"• If the amount is over 200K CHF special routing is called "Over200K"• If there is a person with a COMM or COMM2 role Commercial Sign is required.• The function "cern:DPRQ_getDefaultBuyer" is called when a Activity and a Budget
are added in the Document. This function will return the PID of the person whohas to sign the Document as a Buyer. If there is a COMM or a COMM2 the BuyerSignature won't be needed.
• TransferDocument.
Routing for a department or for an experiment(SingleOrganizationUnitRouting)
Fig 2: Workflow rules for Organization Units
For a department organization unit
For every organization unit indicated in the document, routing will start at the lowestlevel specified in the Department/Group/Project or Team part of the DPRQ module.
The different Organization Unit that we can find in the document are:
• Sub-section (SUBSECT), the authorisations required are: Sub-Section Leader(SSL), Section Leader (SL), Group Leader (GL), *, Departmental Planning Officer(DPO)
If more than one organization unit appears in the DPRQ's procedure requesters, aseparate routing will take place for each organization in parallel, but the DPRQ will onlybe authorized if all Single Organization routings are completed.
Example:
Fig 3: Example of requesting organization Units
In the example shown in Fig 3, we know that authorizations will be required:
• on one side for the IT division and IT-AIS group,• and on the other side from the sub-system GCH16ZA1 for the GCH (LHC) project
It is only after all authorizations have been collected on these two axes that the routingwill go on and take place in Purchasing Services, for the commercial validations of theDR.
Routing for a Project (SingleProjectRouting)
Fig 3: Workflow rules for Projects Units
For each authorized project which appears in the list of Procedure Requesters. The DPRQwill be routed as explained on the diagram above: the system leader will have toapprove, followed by the Project Planning Officer, always depending the project type.
• If project INTO [SUBSYS, SYSTEM] -> Authorisations required: System Leader(SL) and Project Planning Officer (PPO).
• If project INTO [AUTOPRJ, AUTPRB, SYSGRP, SUBPRJ] -> Project Planning Officer(PPO).
Rules:CheckLHC.Check if there is any LCH project -> is there any project whose name starts with 'GCH'?
Is there is at least one LCH project, the DH of LHC must sign.
CheckExperiment.Check if there is any Experiment -> is there any 'ORGANI' Unit whose name not in['CERN','LAA','PF','HF','GPM']
If there is at least one experiment, the DDG of CERN must sign.If there aren't LCH projects and Experiments, the CFO of CERN must sign.
Commercial Signature
If there is a COMM or COMM2 role will be need the Signature of this person. We only need theauthorisation of one Commercial person so if there are more than one COMM or COMM2 we'llchoose the COMM of highest priority.The lowest COMM priority value is more priority than the highest COMM2 value.The value 1 is more priority than the value 2 and the value 2 is more priority than the value 3 and soon.
The replacements of this signature will be the rest of the COMM or COMM2 roles ordered by highestpriority.
Buyer Signature
First of all the routing gets the Budget with the highest percentage, and after the first Activity of thedocument. Finally the function "cern:DPRQ_getDefaultBuyer" is called to obtain the PID ofthe person who has to sign the Document as a Buyer.
If there is not a budget, an activity or a Buyer we won't need the Buyer Signature.
DPRQ Specific access rights
These rules apply from the moment the document is sent for routing until it is transferred intoQualiac (or cancelled/rejected).
Read only data (nobody can modify these fields once document is sent):
• DR Reference• Date Raised• Estimated Amount CHF• Needed From• Needed To• Options Needed From• Options Needed Until• Estimated amount for Options CHF
Data modifiable by DPO, DDPO, PPO, DPPO or PURCHOFF only (users holding these roles canmodify these fields any time during the routing, nobody else can touch them)
• Short Description• Long Description• Details• Specific Conditions or Qualification criteria• Market Survey needed• If not needed, give reason• Planned date for MS• Planned date for IT/PE• Activity codes
Data modifiable by DPO, DDPO, PPO or DPPO only
• Budget codes• Future expenditures
Data modifiable by DPO, DDPO, PPO, DPPO, PURCHOFF, TPPO, DTPPO, GL, DPL, GAO and rolesdefined in Specific roles for the document TECHNICAL, TECHNICAL2, BUDGET:
• Departments, Groups, Projects or Teams• Specific roles
How to approve/reject the DR?
After the routing of the DR has started, you may approve/reject the DR exactly as youmay do for any other EDH document. You will receive in your email invitation toauthorize the Divisional Request, which you may do or on the contrary decide to reject.
If you reject a DR, the DR document will automatically reflect the fact that the routingwhich was started has been rejected. It is then possible, for the Technical responsible tomodify the DR and start another routing.
Finally, when all necessary authorizations have been collected, the EDH document willappear as approved.
How to cancel the routing of a Divisional Request?
The creator of a DR Document, which is the person who initiates the EDH documentcorresponding to a DR , has the possibility to cancel the routing of the DR document ,just as any EDH document.
In case of problems
If you meet problems using the EDH Workflow, please do not hesitate to contact the AIShelp desk . Especially for workflow problems, it is very important that you specify whereprecisely you have met the problem:
• Which DR were you working on ?• Was it when you sent the DR ?• Was it when you actually tried to approve/reject a document?• Was your DR not routed to the persons whom you expected?
