Professional Documents
Culture Documents
Functional Specification DOA Work Order Approval Rev 1
Functional Specification DOA Work Order Approval Rev 1
Document Signoff
2. Scope of Work
2.1 DOA Approval
The new solution will ensure that the process of DOA approval is
implemented when a Maintenance order is created but require material
activation as part of the approval process for all maintenance order. The
activation of Work Orders is Standard SAP functionality and will be enhanced
to ensure that when an order requires activation the original requirement for
the planned value is approved. The Labour portion of the approval is
excluded from the total value. Also any changes made after the initial DOA
approval for the material reservations or/and purchases for material and
services get the necessary re-approval if the value overrides the original
approved value by plus or minus 10 %. This means that the PM order
planned value can increase or decrease by 10% which then require the DOA
process to start again. This solution will be implemented across all current
infra work Order types in table 1 below.
Table1
Type Order Description
I001 Infra - Electrical Equipment
I002 Infra - Signal Equipment
I003 Infra - Track Equipment
I004 Infra - Capital Projects
I005 Infra - Potential Claims
I006 Infra - Services to external parties
I007 Infra - Non-Network Activities
I008 Infra - Technical Support
I009 Infra - Mechanical Maintenance
I010 Infra - Transnet Telecoms
2.3 Substitution
The requirement has a major impact on the plant maintenance process and
will result in some delays during the maintenance process because of human
factors like people not available for approval.
As per picture 1 the Order has been created and the requirements like Stock
material, Purchases and Services have been created. The business has
approved the budget expenditure for the order and the new budget period is
starting. (In some cases the activation is needed before budget approval
especially items with a long lead-time items which has the highest priority).
The Order now needs to be activated for material requirement.
Example:
Table 3: Relationship for the approval responsible person(s) per Cost Centre
The initial process of approval for the MCTR user profile will default and the
maintenance controller will be able to approve the PM Order if it falls within
his level (0 to R2000) of approval. As soon as the Level is higher than the
Maintenance Controllers level the full DOA process will kick-in. As soon as
the program has identified the amount and the next Level for approval the
program must identify the approver(s) in the Table. The workflow will then
root the PM order to the inbox of the identified user ID of the approver and be
reflected as an outstanding item for him to approve. If the approver is a
Purchase Order or Purchase Requisition approver the PM orders will be
included in his total list of approvals. Once the item is opened for approval
and on acceptance of the PM Order the user status will be updated and move
to the net level of approval. The next Level of approval will be the same as
the previous described steps. When the last (this could also be the first)
approver has approved the PM Order Planned value the system must now
change the status of the user to ‘Approved’ which will now allow activation of
the material requirements for the specific PM Order. This means that the
order is now approved and the business can commence with release and
execution of the work according to the requirement of the PM Order.
If one of the DOA approvers decline the approval at any point in the process
the PM orders user status will move to the “Rejected” user status. This means
that the program will ignore any previous approval and move the user status
to “rejected” and let the originator to move from the “created” to “Awaiting
Maintenance Controller” now that his order has been rejected. He can change
the order to suite the requirements of the approver. This requirement will be
part of the reasons that the approver need to give for the rejection of the PM
order to continue back to the originator.
The Order can be changed after approval as long as the system status of the
Order is created with activation, rejected and/or release. If the Status of the
PM Order is Technical complete (TECO) no opportunity for approval will be
available.
Picture 2
Approval Criteria:
The program must look at 2 options to determine the approval hierarchy. The
Main Work Centre must be entered in the PM Order and the Planner Group
need to be available on the header data of the PM Order
This means that the DOA table must have 2 criteria that will drive the
approval hierarch. Only 1 of the criteria needs to be prevalent to identify the
approver(s). The Planned value for all expenses on the order will be used to
calculate the value for approval
Example:
Table 5
Criteria for
any one of
Objects 3 Koos Piet Johan Stephen
Below < R Below Above R
Below < 10,001 <R500 001 1,000,001
R R R R 5,000,000
Piet and Koos is seen as DOA approvers and will now have to approve the
PM order to allow for further processing of the order. Workflow will take the
user Id’s of Koos and Piet and will then move the PM Order to the inbox of
Koos for approval. The workflow for Piet can only happen when Koos has
approved his DOA then the PM order is moved to the next level.
Within the approval process the user cannot approve a level that is not his
DOA level which makes the responsibility of each PM Order for approval to
follow the hierarchy level as defined in the Z- table.
The big difference when approving the DOA approvals for Emergency
PM Orders is that the Orders is created after the fact and must only be
approved by the maintenance controller for the first DOA approval if the value
is less or equal to TWP thousand rand OR Deport Engineer for the first DOA
approval if the value is above two thousand rand.
For any changes made to total material costs above or less than 10% the
DOA must follow the full approval as used with the planned orders.
The User defined profile for the order type I005 will be the same as the other
order types .
A list report for all approvers should be available to view all outstanding
approvals for a User Id, Planner group, PM order or group of PM Orders. This
would allow the person to run the report to get access to a list of approved,
The normal work order list edit/display report will be used with selection by
user status.
BW Report
The workflow design for DOA must be structure is such away that at all levels
of approval the standard SAP workflow as based on the current TFR P2P
design and using the same function within the procurement design. The steps
during workflow must be bases on the save of the PM order.
Step 2: Order is saved and the workflow will now kick-in. The workflow must
now identify the user as the approver for the cost centre, planner group, the
value and as per his approval group.
Step 3: The workflow will move a message to the inbox of the specific user to
allow user to approve the specific order. If Outlook solution is set-up for the
P2P solution this must be implemented.
Step4: Once order is open the user now can select the next level of approval
or reject/approve the user status and save the order.
a. If reject is selected the order originator need to receive a message
within SAP inbox to tell him the order need re-evaluation.
b. If approved is selected the order originator need to receive a
message within SAP inbox to tell him the order ready for release.
c. If next level of approval has been selected the inbox message will
be sent to user’s inbox and process will continue as above
mentioned.
The workflow need to have the option to allow substitutions for users to
approval work but only in an upwards level and not down or sideways.
Picture 3
No
2.20
Work Order
Creation
Process 40
Was this a
Emergency
Order?
No
50
List Work
Orders for
Schedule
Period
( IW38 )
Yes
60
Select
Schedule Work
70
Orders for
Was it a Call-out
Release
Order? ( IW38 )
No
80 30
List of Work Work Order
Order(s) Approved Release
for printing if ( IW32 )
required
( IW38 )
90 2.50
Print Work Order(s) Work Order
Yes
Released for Confirmation
scheduled period (IW41 )
( IW38 )
ZPMORDER_Impleme
ntation_Name.txt
z_check_amount_ch
anges_include.txt
z_release_include.tx
t
zpmo_doa_cheq_FU
NCTION.txt