Implementing Business Solutions using UML

Implementing BusinessSolutions using UML

Rubico (Pty) Ltd

and

Jay van Zyl and Anthony Stewart

Copyright 1999. All rights reserved.This may not be reproduced without the written permission of

Rubico (Pty) Ltd

IMPLEMENTING BUSINESS SOLUTIONS USING UML

25 March, 1999 Version: 1.0.0 Page: iDocument: business solutions using uml 100 us format.doc

Table of ContentsChapter 1 Introduction ................................................................................................................1

1.1 Purpose of this document ..............................................................................................11.2 Intended Audience.........................................................................................................1

Chapter 2 Introduction to the Rubico Methodology......................................................................22.1 Initial Phases .................................................................................................................22.2 Project Initiation.............................................................................................................2

2.2.1 Purpose..................................................................................................................22.2.2 Rubico Project Team Responsibility........................................................................32.2.3 Client Responsibility ...............................................................................................32.2.4 Deliverables............................................................................................................3

2.3 As Is Phase ...................................................................................................................42.3.1 Purpose..................................................................................................................42.3.2 Rubico Project Team Responsibility........................................................................42.3.3 Client Responsibility ...............................................................................................42.3.4 Deliverables............................................................................................................5

2.4 Strategic Step................................................................................................................52.4.1 Purpose..................................................................................................................52.4.2 Rubico Project Team Responsibility........................................................................52.4.3 Client Responsibility ...............................................................................................52.4.4 Deliverables............................................................................................................5

2.5 To Be Phase..................................................................................................................62.5.1 Purpose..................................................................................................................62.5.2 Rubico Project Team Responsibility........................................................................62.5.3 Client Responsibility ...............................................................................................62.5.4 Deliverables............................................................................................................6

2.6 Design Phase ................................................................................................................62.7 Design Phase ................................................................................................................7

2.7.1 Purpose..................................................................................................................72.7.2 Rubico Project Team Responsibility........................................................................82.7.3 Client Responsibility ...............................................................................................82.7.4 Deliverables............................................................................................................8

2.8 Construction Phase .......................................................................................................82.8.1 System Validation...................................................................................................82.8.2 Purpose..................................................................................................................82.8.3 Rubico Project Team Responsibility........................................................................92.8.4 Client Responsibility ...............................................................................................92.8.5 Deliverables............................................................................................................92.8.6 System Verification – Testpacks .............................................................................92.8.7 Purpose..................................................................................................................92.8.8 Rubico Project Team Responsibility......................................................................102.8.9 Client Responsibility .............................................................................................102.8.10 Deliverables..........................................................................................................10

2.9 Implementation Phase .................................................................................................102.9.1 Mock Runs ...........................................................................................................10

2.9.1.1 Purpose ............................................................................................................102.9.1.2 Rubico Project Team Responsibility ..................................................................102.9.1.3 Client Responsibility..........................................................................................112.9.1.4 Deliverables ......................................................................................................11

2.9.2 Final User Training ...............................................................................................112.9.2.1 Purpose ............................................................................................................112.9.2.2 Rubico Project Team Responsibility ..................................................................112.9.2.3 Client Responsibility..........................................................................................112.9.2.4 Deliverables ......................................................................................................11


25 March, 1999 Version: 1.0.0 Page: iiDocument: business solutions using uml 100 us format.doc

2.9.3 Data Take-ons......................................................................................................112.9.3.1 Purpose ............................................................................................................112.9.3.2 Rubico Project Team Responsibility ..................................................................122.9.3.3 Client Responsibility..........................................................................................122.9.3.4 Deliverables ......................................................................................................12

2.9.4 Live Date ..............................................................................................................12Chapter 3 Build Cycle...............................................................................................................13

3.1 Building the Solution....................................................................................................133.2 Project Plan.................................................................................................................143.3 Requirements ..............................................................................................................143.4 Validations...................................................................................................................143.5 Technical Documentation ............................................................................................143.6 UML Bridge .................................................................................................................14

Chapter 4 Standards and Patterns............................................................................................154.1 Pattern: Transaction ....................................................................................................154.2 The System Diagram...................................................................................................15

4.2.1 Setting Up the Rose Model ...................................................................................154.3 Use Cases...................................................................................................................174.4 Class Diagrams ...........................................................................................................18

Chapter 5 Conclusion: Methodology .........................................................................................19Chapter 6 Case Study: Acme Manufacturing ............................................................................20Chapter 7 Introduction to the To-Be Document for Acme Manufacturing ...................................21

7.1 Purpose of this document ............................................................................................217.2 Scope of the project.....................................................................................................217.3 Definitions, acronyms and abbreviations ......................................................................217.4 References..................................................................................................................21

Chapter 8 Process Architecture ................................................................................................228.1 Business Process Overview.........................................................................................22

8.1.1 Process Package Overview ..................................................................................228.1.2 Interfaces .............................................................................................................22

8.1.2.1 Interface 1< Source Process to Target Process >..............................................238.1.3 Purchase Order Processing ..................................................................................23

8.1.3.1 Place Order.......................................................................................................238.1.3.1.1 Scenario: Analysis: Placing an Order ...........................................................24

8.1.3.2 Maintain Order ..................................................................................................248.1.3.2.1 Scenario: Analysis: Create Purchase Order..................................................258.1.3.2.2 Scenario: Analysis: Maintain Purchase Order...............................................268.1.3.2.3 Scenario: Analysis: Close Purchase Order ...................................................27

8.1.3.3 Monitor Order....................................................................................................278.1.3.3.1 Scenario: Analysis: Monitor Order ................................................................28

8.1.3.4 Order Inquiry.....................................................................................................288.1.3.4.1 Scenario: Analysis: Inquire on Orders ..........................................................29

8.1.4 Goods Receiving ..................................................................................................298.1.4.1 Receive Goods..................................................................................................30

8.1.4.1.1 Scenario: Analysis: Receive Goods..............................................................318.1.4.2 Monitor Deliveries .............................................................................................32

8.1.4.2.1 Scenario: Analysis: Monitor Goods Received ...............................................328.1.4.3 Capture GRA Details.........................................................................................32

8.1.4.3.1 Scenario: Analysis: Return Goods To Supplier .............................................338.1.4.4 Accept Goods ...................................................................................................33

8.1.4.4.1 Scenario: Analysis: Release Goods..............................................................348.1.4.5 GRN Generated ................................................................................................34

8.1.5 Order Monitoring...................................................................................................358.1.6 Supplier Selection.................................................................................................35

8.1.6.1 Maintain Supplier Master File ............................................................................368.1.6.1.1 Scenario: Analysis: Supplier Master File Maintenance..................................36


25 March, 1999 Version: 1.0.0 Page: iiiDocument: business solutions using uml 100 us format.doc

8.1.6.2 Maintain Master Files ........................................................................................378.1.6.2.1 Scenario: Analysis: Master File Maintenance ...............................................37

8.1.7 Requisition Processing .........................................................................................388.1.7.1 Maintain Requisition..........................................................................................38

8.1.7.1.1 Scenario: Analysis: Create Requisition.........................................................398.1.7.1.2 Scenario: Analysis: Maintain Requisition ......................................................41

8.1.7.2 Authority Checking ............................................................................................418.1.7.2.1 Scenario: Analysis: Authorise Requisition.....................................................42

8.1.7.3 Monitor Requisitions..........................................................................................428.1.7.3.1 Scenario: Analysis: Monitor Requisitions ......................................................43

8.1.8 Roles and Security ...............................................................................................448.1.9 Reporting Requirements .......................................................................................45

8.1.9.1 PO Report.........................................................................................................458.1.9.2 Trade Discount/Price Exception Report .............................................................478.1.9.3 GRV Exception Report ......................................................................................478.1.9.4 Supplier Master File Report...............................................................................478.1.9.5 Item Master File Report.....................................................................................47

8.1.10 Rubico Structures .................................................................................................488.1.10.1 Product..........................................................................................................488.1.10.2 Supplier Structure ..........................................................................................488.1.10.3 Warehouse Structure .....................................................................................49

8.2 Class Diagram.............................................................................................................498.2.1.1 Purchase Order.................................................................................................538.2.1.2 Purchase Order Header ....................................................................................538.2.1.3 Purchase Order Detail.......................................................................................538.2.1.4 PO Inquiry.........................................................................................................538.2.1.5 PO Status .........................................................................................................538.2.1.6 Transaction Type ..............................................................................................548.2.1.7 Split line Item ....................................................................................................548.2.1.8 Goods Received Voucher..................................................................................548.2.1.9 Goods Returned Note .......................................................................................548.2.1.10 GRV Inquiry...................................................................................................548.2.1.11 GRN Inquiry...................................................................................................548.2.1.12 GRV Status ...................................................................................................548.2.1.13 Class Name: Item Master File ........................................................................55

8.2.1.13.1 Attribute Name: Item Code .........................................................................558.2.1.13.2 Attribute Name: Item Description................................................................558.2.1.13.3 Attribute Name: Default Warehouse Code ..................................................558.2.1.13.4 Attribute Name: Standard Cost ...................................................................558.2.1.13.5 Attribute Name: UOM.................................................................................558.2.1.13.6 Attribute Name: TAX ..................................................................................558.2.1.13.7 Attribute Name: Material Cost.....................................................................558.2.1.13.8 Attribute Name: Last Cost Price..................................................................568.2.1.13.9 Attribute Name: Inventory Unit....................................................................568.2.1.13.10 Attribute Name: Forecast Method .............................................................568.2.1.13.11 Attribute Name: MRP - Lead time .............................................................568.2.1.13.12 Attribute Name: MRP - Supplier Code.......................................................568.2.1.13.13 Attribute Name: MRP - W/H......................................................................56

8.2.1.14 Employee Master File ....................................................................................568.2.1.15 Class Name: Supplier Master file ...................................................................57

8.2.1.15.1 Attribute Name: Supplier Code ...................................................................578.2.1.15.2 Attribute Name: Supplier Name ..................................................................578.2.1.15.3 Attribute Name: Supplier Status..................................................................578.2.1.15.4 Attribute Name: Settlement Discount ..........................................................578.2.1.15.5 Attribute Name: Standard Trade Discount...................................................578.2.1.15.6 Attribute Name: Chain Code.......................................................................57


25 March, 1999 Version: 1.0.0 Page: ivDocument: business solutions using uml 100 us format.doc

8.2.1.15.7 Attribute Name: Banking Details .................................................................578.2.1.15.8 Attribute Name: E-mail Address..................................................................58

8.2.1.16 PO Requisition Header ..................................................................................588.2.1.17 PO Requisition Detail.....................................................................................58

8.2.2 Take-on Data Requirements .................................................................................588.2.2.1 Is the scope of the above process in line with the scope definition per the Orientationphase? 59

Chapter 9 Introduction to the Design Document for Acme Manufacturing..................................609.1 Purpose of this document ............................................................................................60

Chapter 10 Design Interfaces..................................................................................................6110.1 System Overview.........................................................................................................61

10.1.1 Warehousing ........................................................................................................6110.1.2 Accounts Payable.................................................................................................6110.1.3 Accounts Receivable ............................................................................................6110.1.4 Cash Book............................................................................................................6110.1.5 General Ledger.....................................................................................................6110.1.6 MPS .....................................................................................................................6110.1.7 MRP.....................................................................................................................6210.1.8 Production ............................................................................................................6210.1.9 Order Processing..................................................................................................6210.1.10 Planning & Distribution ......................................................................................6210.1.11 Procurement .....................................................................................................6210.1.12 Demand Planning..............................................................................................6210.1.13 Third Party ........................................................................................................62

10.1.13.1 Access...........................................................................................................6210.1.13.2 VIP ................................................................................................................62

Chapter 11 Identify Business Processes .................................................................................6311.1 Map Processes............................................................................................................6311.2 System Diagram..........................................................................................................63

Chapter 12 System Design .....................................................................................................6412.1 Rubico Structures ........................................................................................................6412.2 Roles and Security ......................................................................................................65

12.2.1 Roles and Securities Table ...................................................................................6712.3 Design Processes........................................................................................................69

12.3.1 Design: Purchase Order Processing .....................................................................6912.3.1.1 Class Diagram: Design: Purchase Order Processing......................................6912.3.1.2 Use Case Diagram: Design: Purchase Order Processing ...............................6912.3.1.3 Use Case Breakdown ....................................................................................70

12.3.1.3.1 Use Case: Place Order ..............................................................................7012.3.1.3.2 Analysis: Placing an Order .........................................................................7112.3.1.3.3 Design: Placing an Order ...........................................................................7112.3.1.3.4 Use Case: Maintain Order ..........................................................................7212.3.1.3.5 Analysis: Create Purchase Order ...............................................................7212.3.1.3.6 Design: Create a Purchase Order...............................................................7312.3.1.3.7 Design: Create a Purchase order - HDR Attribute Triggers .........................7412.3.1.3.8 Design: Create a Stock PO - DETL Attribute Triggers .................................7412.3.1.3.9 Analysis: Maintain Purchase Order.............................................................7512.3.1.3.10 Design: Maintain Purchase Order .............................................................7512.3.1.3.11 Analysis: Close Purchase Order ...............................................................7612.3.1.3.12 Design: Close Purchase Order .................................................................7712.3.1.3.13 Use Case: Monitor Order..........................................................................7712.3.1.3.14 Analysis: Monitor Order ............................................................................7812.3.1.3.15 Design: Monitor Purchase Order...............................................................7912.3.1.3.16 Use Case: Order Inquiry ...........................................................................7912.3.1.3.17 Analysis: Inquire on Orders.......................................................................7912.3.1.3.18 Design: Order Inquiry ...............................................................................80


25 March, 1999 Version: 1.0.0 Page: vDocument: business solutions using uml 100 us format.doc

12.3.2 Design: Goods Receiving .....................................................................................8112.3.2.1 Class Diagram: Design: Goods Receiving......................................................8112.3.2.2 Use Case Diagram: Design: Goods Receiving ...............................................8212.3.2.3 Use Case Breakdown ....................................................................................83

12.3.2.3.1 Use Case: Receive Goods .........................................................................8312.3.2.3.2 Analysis: Receive Goods............................................................................8312.3.2.3.3 Design: Receive Goods..............................................................................8412.3.2.3.4 Design: Update W/H Item & QC .................................................................8512.3.2.3.5 Use Case: Monitor Deliveries .....................................................................8512.3.2.3.6 Analysis: Monitor Goods Received .............................................................8512.3.2.3.7 Design: Monitor GRV's ...............................................................................8612.3.2.3.8 Analysis: Return Goods To Supplier ...........................................................8612.3.2.3.9 Use Case: Accept Goods ...........................................................................8712.3.2.3.10 Analysis: Release Goods..........................................................................8712.3.2.3.11 Design: Release Goods............................................................................8812.3.2.3.12 Use Case: GRN Generated ......................................................................88

12.3.3 Design: Order Monitoring......................................................................................8812.3.3.1 Use Case Diagram: Design: Order Monitoring................................................8812.3.3.2 Use Case Breakdown ....................................................................................89

12.3.4 Design: Supplier Selection....................................................................................8912.3.4.1 Class Diagram: Design: Supplier Selection ....................................................8912.3.4.2 Use Case Diagram: Design: Supplier Selection..............................................9012.3.4.3 Use Case Breakdown ....................................................................................90

12.3.4.3.1 Use Case: Maintain Supplier Master File ....................................................9012.3.4.3.2 Analysis: Supplier Master File Maintenance................................................9112.3.4.3.3 Design: Supplier Maintenance....................................................................9212.3.4.3.4 Use Case: Maintain Master Files ................................................................9212.3.4.3.5 Analysis: Master File Maintenance .............................................................9312.3.4.3.6 Design: IM Maintenance.............................................................................93

12.3.5 Design: Requisition Processing.............................................................................9412.3.5.1 Class Diagram: Design: Requisition Processing .............................................9412.3.5.2 Use Case Diagram: Design: Requisition Processing.......................................9412.3.5.3 Use Case Breakdown ....................................................................................95

12.3.5.3.1 Use Case: Maintain Requisition..................................................................9512.3.5.3.2 Analysis: Create Requisition.......................................................................9512.3.5.3.3 Analysis: Maintain Requisition ....................................................................9712.3.5.3.4 Use Case: Authority Checking....................................................................9712.3.5.3.5 Analysis: Authorise Requisition ..................................................................9812.3.5.3.6 Use Case: Monitor Requisitions..................................................................9812.3.5.3.7 Analysis: Monitor Requisitions....................................................................99

Chapter 13 Approved............................................................................................................100Chapter 14 Introduction to the Rubico Object Documentation for Acme Manufacturing..........101

14.1 Purpose of this document ..........................................................................................10114.2 Definitions, acronyms and abbreviations ....................................................................10114.3 References................................................................................................................101

Chapter 15 Visual Object Documentation..............................................................................10215.1 Visual Alias Documentation:PO_ORD_MAN..............................................................102

15.1.1 Business Class: Purchase Order.........................................................................10215.1.1.1 Purchase Order Header ...............................................................................10215.1.1.2 Purchase Order Detail .................................................................................104

15.2 Visual Alias Documentation:PO_Buyer2Supplier........................................................10715.3 Visual Alias Documentation:DYNAMIC_MESS...........................................................10715.4 Visual Alias Documentation:PO_Enquiry....................................................................107

15.4.1 Business Class: PO Inquiry.................................................................................107Chapter 16 Visual Alias Documentation:GRV_Form..............................................................108

16.1.1 Business Class: Goods Received Voucher .........................................................108


25 March, 1999 Version: 1.0.0 Page: viDocument: business solutions using uml 100 us format.doc

16.1.1.1 GRV Header................................................................................................10816.1.1.2 GRV Detail ..................................................................................................109

16.2 Visual Alias Documentation:PO_LIST_GRV...............................................................11016.3 Visual Alias Documentation:GRV_CAP......................................................................111

16.3.1 Business Class: PO 2 GRV Selection .................................................................112Chapter 17 Hidden Object Documentation ............................................................................113

17.1 MA_PO_NO_GEN.....................................................................................................11317.1.1 MA_PO_NO_GEN Documentation:....................................................................113

17.1.1.1 Object Input Parameters ..............................................................................11317.2 MA_ITEM_DESC.......................................................................................................113

17.2.1 MA_ITEM_DESC Documentation: .....................................................................11317.2.1.1 Object Input Parameters ..............................................................................11317.2.1.2 Object Output Parameters ...........................................................................113

17.3 MA_ALLOWED_ITEM ...............................................................................................11417.3.1 MA_ALLOWED_ITEM Documentation: ..............................................................114

17.3.1.1 Object Input Parameters ..............................................................................11417.3.1.2 Object Output Parameters ...........................................................................114

17.4 MA_CHECK_ITEM ....................................................................................................11517.4.1 MA_CHECK_ITEM Documentation:...................................................................115


17.5 MA_VERSION_CONT...............................................................................................11517.5.1 MA_VERSION_CONT Documentation:..............................................................115

17.5.1.1 Object Input Parameters ..............................................................................11517.6 MA_READ_CUBE .....................................................................................................115

17.6.1 MA_READ_CUBE Documentation: ....................................................................11517.6.1.1 Object Input Parameters ..............................................................................11517.6.1.2 Object Output Parameters ...........................................................................116

17.7 MA_DATE_CALC......................................................................................................11617.7.1 MA_DATE_CALC Documentation:.....................................................................116


17.8 MA_CHECK_PREV...................................................................................................11717.8.1 MA_CHECK_PREV Documentation:..................................................................117


17.9 MA_SEND_INFO.......................................................................................................11717.9.1 MA_SEND_INFO Documentation: .....................................................................117

17.9.1.1 Object Input Parameters ..............................................................................11717.10 GRV_Form_Hidden................................................................................................118

17.10.1 GRV_Form_Hidden Documentation: ..............................................................118Chapter 18 Purchase Order Transactions .............................................................................119Chapter 19 Purchase Order Transactions Attributes..............................................................122Chapter 20 GRV Transactions ..............................................................................................128Chapter 21 GRV Transactions Attributes...............................................................................130Chapter 22 Master File Maintenance.....................................................................................133Chapter 23 An Extract from the Rubico Bridge Manual..........................................................138

23.1 Structure Information .................................................................................................13823.2 Transaction Information .............................................................................................142

Appendix A: Capability.............................................................................................................147Appendix B: References ..........................................................................................................148


25 March, 1999 Version: 1.0.0 Page: 1Document: business solutions using uml 100 us format.doc

Chapter 1 Introduction

1.1 Purpose of this documentThe purpose of this document is to provide Rational with an overview of howRubico handles the UML in business design. It is specifically created toshow some of the elements that are used in building an enterprise solution.

It gives a complete overview of the Rubico Methodology and then showslinks to the UML (unified modeling language). Also included is a samplemodel with its related project plan to show how a real life project wasimplemented.

1.2 Intended AudienceThis document is aimed at providing people with a complete overview ofusing the UML in the context of business delivery. It is assumed that somebusiness process knowledge exists, as the components are not discussed indetail.



Chapter 2 Introduction to the Rubico Methodology

Delivering enterprise wide solutions require complex process and projectmanagement activities and skills. This abstract only covers the componentsas relevant to this case study.

2.1 Initial PhasesThe Methodology is broken into discreet elements that were designed tosolve problems in large scale projects.

SALES

AS IS

INITIATION

PR

OC

ES

S M

ET

HO

DO

LO

GY

PR

OJE

CT

MA

NA

GE

ME

NT

PR

OJE

CT

MA

NA

GE

ME

NT

CH

AN

GE

MA

NA

GE

ME

NT

DO

CU

ME

NT

AT

ION

MA

NA

GE

ME

NT

AS IS

STRATEGICSTEP

TO BE

OOAD

OOAD

Figure 1. Initial Stages on the Rubico Methodology

The “OOAD” indicator is next to the process elements that require discreetanalysis and design activities. UML is used to model the business rules.

2.2 Project Initiation

2.2.1 Purpose

During this phase, resources will be allocated/assigned to the project. Manyof these resources will not have been exposed to the Client staff during theSales phase, and the staff will therefore need to be briefed by both theRubico Sales department as well as the Client Sponsor.The resources will be introduced to the Client Sponsor and the Client staff.The environment in which the project team will be working will be set up.If the project has been sold at a price to be revisited subject to anOrientation, then the Rubico project team will conduct an Orientation, whichwill be fairly “low key”. The purpose of this orientation is as follows:§ To familiarise the Rubico Project Team with the Client’s business

process, and the Client’s culture.§ To define the scope of the project with respect to the various business

processes; the Scope will have a list of inclusions and exclusions ifrequired.



§ To provide an estimate of the duration of the project, i.e. the estimatedtime that it will take to deliver the scope that will now be defined.

§ To revise the proposed costs, if necessary.The Orientation Investigation is conceptual and will become more detailedduring the “As Is” and “To Be” phases. Rubico will facilitate the Orientationworkshops and document the process conceptually in order to achieve thedeliverables below. This document will then form the basis of the Scope untilit is further defined at the end of the “To Be” phase.

2.2.2 Rubico Project Team Responsibility

Rubico will facilitate the Orientation workshops and document the processconceptually in order to achieve the deliverables below. This document willthen form the basis of the scope until it is further defined at the end of the“To Be” phase. Assign resources, prepare templates and prepare a plan forthe workshops up to the end of the “To Be” phase.

2.2.3 Client Responsibility

The Client must identify the process owners and process users who willprovide the Rubico project team with information during the orientation.These process owners need to be knowledgeable of the business processand must be in favour of the project. They must be given time off theirnormal duties to attend the orientation workshops.A plan detailing the duration, time, venue and agenda will be prepared bythe Rubico and Client project teams prior to the commencement of theorientation.

2.2.4 Deliverables

Template environment prepared.Once the orientation has been completed, an Orientation Scope Definitiondocument will be prepared. The Scope, estimated duration and cost of theproject will be finalised. It must be noted that there are many variables thatthe project will have to contend with, and it is only after the system has beenspecified in detail at the end of the “To Be” phase that an accurateassessment of the Live date will be made.After considerable planning with the Client, the combined project team willprepare a plan to the end of the “To Be” phase. This plan will take intoaccount the timing of the workshops for the “As Is”, “Strategic Step” and “ToBe” phases of the project. Plan toward the “To Be” phase.



2.3 As Is Phase

Client/User Rubico Consultant

UML

Orientation & As-Is Phase

Figure 2. From Orientation to As-Is to To-Be Phases

2.3.1 Purpose

The purpose of this phase is to provide the Client and the Rubico ProjectTeam with a detailed understanding of the current state of the Client’sbusiness and respective business processes. This will be achieved bymeans of a series of workshops with the Client.During this phase, the Client staff will be presented with a Project Launchpresentation which will explain the Project Delivery Methodology to theClient staff that will be involved in the project. It is important that thispresentation be introduced by senior management of the Client, showingtheir support of the project.


Rubico will conduct the Project Launch presentation. A detailed plan of theforthcoming workshops will be compiled and adhered to. An agenda for theworkshops will be prepared and the workshops will be facilitated by Rubico.The business architecture and processes will be documented and modelled,and the “As Is” Definition document will be prepared.


The Client must identify the process owners and process users, and providefacilities for the workshops. The Client must assist in managing theperceptions and the change factors that the Client staff may be nervous ofat the start of the project.



2.3.4 Deliverables

• Understanding of the current business processes by both Rubico andthe Client, so as to allow both parties to be well poised for theforthcoming phase.

• An “As Is” Definition document.

2.4 Strategic Step

2.4.1 Purpose

The purpose of this phase is to attain agreement on the strategy for theupcoming “To Be” phase. Certain issues must be considered during thisphase:§ Base practise and knowledge§ Timing, budget, organisational structure§ Radical thinking§ Maturing of the organisation§ Implications of proposed/potential changes§ Expectations of the Client§ Deviations from the Scope as per the Orientation Scope Definition.Workshops will be conducted with senior management. Carefulconsideration must be applied to the “Change Management” aspect of theproject, to lay the foundation for the Client’s smooth transition from the “AsIs” to the “To Be” phase.


Rubico will facilitate the workshops and, based on the experience of theRubico Process Specialists, will advise the Client as to the way forward.


The Client must:§ Provide the facilities§ Ensure the availability of the relevant Client staff§ Provide suggestions as to the proposed way forward.The Client must assist in managing the perceptions and the reality of currentand potential change that the Client staff are experiencing, or mayexperience in the future.

2.4.4 Deliverables

A document explaining:§ The strategy for the upcoming “To Be” phase§ Potentially redesigned business processes and organisational

structure at a conceptual level.



2.5 To Be Phase

2.5.1 Purpose

The purpose of this phase is to accurately document the Client’srequirements for the new system. A series of iterative workshops will beconducted wherein the Client and the Rubico Project Team will agree on thedetailed functionality required for the new system.This phase will be conducted in accordance with the strategy as per theprevious phase.Any deviations from the Scope, as defined in the Orientation ScopeDefinition, will have an impact on the cost and duration of the project.


Rubico will facilitate the workshops, and will document and model theClient’s requirements.


The Client must:§ Provide the facilities§ Ensure the availability of the process owners and process users§ Carefully evaluate the User Requirements as detailed in the “To Be”

Process Definition document§ Assess whether the User Requirements are in fact in line with the

strategy and are achievable from the Client’s perspective§ Sign off the User Requirements, confirming that the requirements are

what is expected of the Rubico Project Team to deliver.§ The Client must assist in managing the perceptions and the reality of

current and potential change that the Client staff are experiencing, ormay experience in the future.

2.5.4 Deliverables

§ An understanding and agreement of the detailed functionality required inthe new system.

§ A signed off “To Be” Process Definition document detailing the UserRequirements of the new system.

2.6 Design PhaseThe following elements are needed to get the business processesimplemented with supporting technology.



SALESP

RO

CE

SS

ME

TH

OD

OL

OG

Y

PR

OJE

CT

MA

NA

GE

ME

NT

PR

OJE

CT

MA

NA

GE

ME

NT

CH

AN

GE

MA

NA

GE

ME

NT

DO

CU

ME

NT

AT

ION

MA

NA

GE

ME

NT

DESIGN

CONSTRUCTION

IMPLEMENTATION

CONFIG

SERVICEMANAGEMENT

OOAD

CONFIGOOAD

Figure 3. Completion Stages of the Rubico Methodology

The above diagram indicates that analysis and design activities areperformed right up to the point where the solution gets implemented. Theobvious benefit is that the customer is actively involved in “creating” thesolution.

2.7 Design Phase

Rubico Consultant Rubico Core Competence

UML

Design Phase

Figure 4. Design Phase

2.7.1 Purpose

The purpose of this phase is to technically design the system (blueprintformat). This design is based on the signed off User Requirements from theprevious phase.



The design of the system involves the Rubico Core Competence divisionand is used in the Construction phase as the system blueprint. Once theDesign has been done, a “Plan to Implementation” will be prepared,detailing the rollout of the project from this phase to the implementationdate.


To design the blueprint of the system based on the signed off UserRequirements.


The Client must maintain momentum of the project while the design of thesystem is in process. The Client must also assist in managing theperceptions and the reality of current and potential change that the Clientstaff are experiencing, or may experience in the future.

2.7.4 Deliverables

A technical blueprint detailing the design of the system which will beadhered to during the Construction phase.Plan to Implementation.

2.8 Construction Phase

Rubico Consultant

UML

Construction

Rubico (The Product)

Figure 5. Construction Phase

2.8.1 System Validation

2.8.2 Purpose

During the Construction phase, the Rubico team will configure the Rubicoproduct to the requirements laid down in the signed off “To Be” ProcessDefinition document. During the course of configuration, Rubico will conduct



formal System Validation sessions with the Client Project Team. Thepurpose of these sessions is to validate that the Rubico product isconforming to the User Requirements per the “To Be” Process Definitiondocument.At each session, a portion of the functionality will be demonstrated. Thesessions are set up in such a way that, by the end of the Configurationprocess, the entire system will have been validated.


§ Rubico will configure the system in accordance with the design as perthe User Requirements. This configuration will take place at the Rubicooffice.

§ Rubico will demonstrate the system functionality to the Client staff.


During each session, when a section of the functionality is demonstrated, itis an obligation of the Client to sign off that the specific functionality ispresent in the system. (Please note that Rubico will conduct formalTestpacks with the Client team at a later stage to ensure that thefunctionality is working correctly.) Our approach is firstly to confirm that thecorrect system has been built before we start to formally test it.These Validation sessions are designed to ensure efficient and effectiveproduct delivery, and should not be used as opportunities to sell the systemto the balance of the organisation. In the event that the meeting hosts anexcessive number of people, or comprises people that were not involved inthe original specking of the system, these sessions will not run efficientlyand the Plan to Implementation will have to be revised. The number ofpeople that the Client may bring to the session should be limited to no morethan 5 to 7. The process leaders and key members of the process teammust be present. It is the process leader who must sign off the SystemValidation at the end of each session.The Client must also assist in managing the perceptions and the reality ofcurrent and potential change that the Client staff are experiencing, or mayexperience in the future.

2.8.5 Deliverables

A signed off System Validation document confirming that the correct systemhas been built.

2.8.6 System Verification – Testpacks

2.8.7 Purpose

The purpose of this phase is to ensure that the system functionality isoperating correctly.In performing System Verification, the Project Team confirms whether thesystem processes data correctly. The system is tested by means of UserTestpacks.A Testpack consists of prepared information packs that will be entered intothe system. The expected results of the prepared information must beavailable as part of the Testpack and will indicate to the Users whether thesystem processing of the information is accurate.



The Testpacks will be run in a secure environment at the Client’s site.System training will be performed for those Users that will conduct theTestpack. A limited take-on of data will also be performed.


Rubico will prepare the environment for the Testpack and will train theselective Users prior to the Testpack. Rubico will be present during theTestpack.


It is the Client’s responsibility to prepare a representative Testpack, with theassistance of the Rubico Project Team members. The first of the series ofTestpacks must be fairly simple; this will then build up to more complexscenarios as the Testpacks progress. Between each Testpack, there will bea period of rework allowed for by the Rubico team.The Client must process the Testpack data through the system and evaluatethe results. Users must be made available for this.The Client must assist in managing the perceptions and the reality of currentand potential change that the Client staff are experiencing, or mayexperience in the future.

2.8.10 Deliverables

A signed off System Verification confirming that the system functionality isoperating correctly.

2.9 Implementation Phase

2.9.1 Mock Runs

2.9.1.1 Purpose

Once the Testpack phase has been completed, we will conduct a series ofMock Live Runs. Training and take-ons will take place for the Mock Runs.These Mock Runs will run in the envisaged Live environment, taking LANand WAN into account. Actual Live situations must be tested. The systemmust be placed under the stresses and strains that would be expected tooccur in a Live environment.The plan will take into account a series of Mock Runs, but not all of themmay occur. At the end of the Mock Run, the results will be evaluated and adecision by the Project Team (Rubico & Client) will be made as to whetheror not to proceed to the Live stage.Should the decision be made to proceed to the Live Run, the Final UserTraining will be conducted.

2.9.1.2 Rubico Project Team Responsibility

Rubico will prepare the environment for the Testpack and will train theselective Users prior to the Testpack. Rubico will be present during theTestpack.



2.9.1.3 Client Responsibility

The Client is to process the data through the system simulating a Live Run.Users must be made available for the Mock Run.The Client must assist in managing the perceptions and the reality of currentand potential change that the Client staff are experiencing, or mayexperience in the future.

2.9.1.4 Deliverables

A system that is operating correctly in a simulated Live environment.

2.9.2 Final User Training

2.9.2.1 Purpose

This sub-phase is intended to train the Users in the functionality of thesystem. This training will comprise two stages:a) Rubico Concepts Training

This is a 1day course. Users will be exposed to the generic Rubicoconcepts and understand how the system works in general.

b) Specific Process TrainingThe duration of this training is dependent on the complexity and size ofthe process. The User will be trained on how to operate the Rubicosystem in respect of the relevant process. At the end of the training, theUser will understand the business process as well as how the systemworks.There will be a fully documented on-line help facility within the systemand reference to this will be made during training.


Rubico will conduct the formal User training.


This training will take place at the Client’s premises. A suitable venue withnetwork connectivity and computers must be made available. All Users mustbe formally trained. They must be given time off from their daily workfunctions in order to be focussed on the training.The Client must assist in managing the perceptions and the reality of currentand potential change that the Client staff are experiencing, or mayexperience in the future.


All Users will be trained on the functionality of the system.

2.9.3 Data Take-ons

2.9.3.1 Purpose

The purpose of this sub-phase is to take on the Transaction data andMaster File data prior to Live date.




It is the Rubico Project Team’s responsibility to perform the data take-ons.


During the Construction phase, certain Master File information will be takenon into the new Rubico database. The Client is responsible to ensure thatthe Master File data is “cleaned up” and correct prior to take-on into Rubico.It is the Client’s obligation to sign off acceptance that the Master File data iscorrect. Before the system goes Live, all Master File data will be in theRubico system. Prior to Live date, any relevant Transaction data will betaken on into the Rubico system. Once again, it is the Client’s responsibilityto ensure that the data provided for the take-on is correct. Once it has beentaken on, the Client will have to sign acceptance that the take-on is correct.


Complete and accurate Transaction and Master File data take-on.

2.9.4 Live Date

The new system will go Live and the old system will be switched off. It isimportant that full commitment is given to the new system. The Rubico teamwill be on standby to resolve any issues that may arise during the initialstages of going Live.It must be acknowledged that sometimes a system goes Live when theUsers are not ready to accept the changes that the new system will create,and if the Client Project Team allows the User to become negative or tosabotage the process, the system will never be given a fair chance ofsuccess.It is crucial that the Client Project Team is not only supportive of the newsystem, but is also seen to be supportive. This is especially relevant oncethe system is Live, and either User induced or System induced errors arebeing experienced.



Chapter 3 Build Cycle

Delivering enterprise wide solutions require complex process and project

3.1 Building the SolutionThe following abstract shows only the basic elements that form part of thefinal “to-be” business definition upto a generated Rubico solution. Variousdocuments form part of this process and are shown under workproducts.The process components are the relevant elements for this businesssolution.

Input from previous phase:1. Business case2. Project timing based onpast performance3. Initial product sizing

Primary ProcessComponents

ComponentLibrary provides

input

SystemArchitectutal

signoff

Customer signoff TechnicalArchitectual

signoff

CustomerUsability signoff.

Rubico UMLBridge.

CustomerUsability signoff.

Rubico UMLBridge.

"To Be" BusinessCase

Workproducts Version 1 Design

Version 1 RubicoObjects fromComponent

Library

Version 2 Design

Version 2 RubicoObjects fromComponent

Library

Version 1 UserValidation of

Software

Version 2 UserValidation of

Software

Figure 6. Detailed Process View

This part of the process starts once the business case is defined and theproject is sized based on previous statistical figures.

The consultant works with the customer in defining the businessrequirements that will be used in this build. Component library specialistsassist the consultant with the analysis. Best practices are consideredthroughout the analysis and design phases.

System architectural design takes into account all elements of how thesystem will be constructed and deployed. The Systems Architect signs offthe validity and business readiness of the business design models.

The analysis is now baselined and design is completed. Analysis modelsare used with customer workshops to get to point of signoff. Existing Rubicoobjects are shown to the customer to get buy-in of the user interfaceobjects. Any changes are recorded and added to the action list for the nextvalidation. Final re-work is performed and the design is signed off.

Technical Architectural definition is the process of defining all the elementsof how the design will physically be implemented. Rubico objects from thecomponent library can be altered with the Rubico toolset (rules engine, statetransition engine, visual designer, etc.) to satisfy the user requirements.

The Rubico UML (Rational to Rubico) Bridge can generate the systembased on design patterns in a number of areas including masterfiles,transactions, reports and security and role definitions. Once all this is donethe user needs to get involved to look at requirements implementation



issues and usability. A formal process is followed whereby all requirementsare validated against the system functionality.

Functionality issues and recorded and added to the next build. The sameprocess is repeated whereby the user’s involvement guarantee a successfulproduct.

3.2 Project PlanThere are a number of project plans when implementing this kind ofprocess. The project plan for the above build cycle includes all rolesneeded, workproducts produced, process activities, and previous learningsto complete the work.

Ideally the project plan becomes the glue that holds together all theprocesses to be implemented for a customer. It reflects all business rulesas modeled in the UML i.e. all UML elements are considered businessrequirements.

3.3 RequirementsThe Requirements document has many versions. It evolves with the projectand is seen and authorized by many stakeholders. Appropriate reviewstake place as and when elements are added such as design documentation.

This document only describes a small and specific process in context of theenterprise solution.

3.4 ValidationsValidations are needed to make sure that the system is functioning asintended. These are fundamental in delivering a high quality system.

3.5 Technical DocumentationRubico Technology product documentation describes the internal objectsthat are available to a consultant in delivering the software solution to thecustomer. These kernel objects are extended and re-used with the rulesengine to make up functional rich business objects.

The components are re-used by business consultants. Some of theprocesses available in the Rubico Component Library are; full financials,manufacturing, salaries and wages, human resource management, planningand distribution, sales order fulfillment and business planning.

3.6 UML BridgeThe Rubico UML Bridge uses business patterns that are taught to theconsultants to generate an outline system in the component library. Itobviously re-uses elements out of, and can place items back into, thecomponent library.



Chapter 4 Standards and Patterns

This section shows an extract from the Rubico Standards and Patternsdocument that is used by consultants when executing the abovemethodology.

4.1 Pattern: TransactionOnce the consultant and the client have together defined the ‘As Is’ Processand the ‘To Be’ Process, it is necessary for the consultant along with theprocess specialist to design the technical model of the system.

4.2 The System DiagramThe Design model is seen as an evolution of the Analysis model. Thereforthe System diagram defined in the analysis phase should be set up correctlyso that it can be used for the Design model.

4.2.1 Setting Up the Rose Model

Only one model will be used for both the analysis and design processes foreach business. That means that the design sequence diagrams and classdiagrams as well as packages must be added to the specific analysis model.

An example in different stages is shown below:

The diagram shown above reflects the Cash Book system, which is brokenup into CB Reports, CB Reconciliations etc.



CB Transactions has four Use case diagrams. Each use case has one ormore analysis sequence diagrams. Each analysis sequence diagram musthave one or more design sequence diagrams.

The Logical View has a design package for each Use Case View package.(Note: This Design package must have the exact same name as theapplicable Use Case View package except that it must be prefixed with"Design:" in its heading documentation.) Also note that all the classes(including analysis classes) must be within a package as illustrated above.



The following additional package must also be added :• A Rubico Structures package containing the different Rubico structures

for the Cash Book system.• A Roles and Security Package: Drag and drop all actors onto the main

diagram of this package. All the associations created throughout themodel will then be highlighted here. The generation of the SoDADocument will bring out additional information. (This will be discussedat a later stage)

Each design package must have a class diagram containing the differentRubico objects for the specific design process.

4.3 Use CasesRubico is a business-orientated tool that allows the consultant to stillinterpret the use case diagrams as a design solution. I.e. the use casediagrams used to describe the business rules as explained by the client canalso be used to create the basic business objects in Rubico.



4.4 Class DiagramsThe design class diagram will be an extension of the analysis class diagram.The Analysis model should be saved and baselined as the analysis modelfor the To Be phase. The design model evolves from the analysis model. Adesign package (with its own class diagram) for each business processmust be created under the Logical View. This is done so that the analysisclass diagram doesn’t get to big. Therefor the design class diagram is splitinto different logical groupings. All applicable analysis classes must bemoved to their relevant design packages. This way the consultant canensure that all the analysis classes are catered for in the design phase.Note how the class diagram will evolve from the class diagram in section2.4.1.1 of this document.

Requisition Enquiry<<Enquiry>>

Requisition Header

Requisit ion Status : Status

Created ByRequested ByAuthorised By

Requisition Detail

Requisit ion Status : StatusItem RequestedQty Requested

UOM

1

0..*

1

0..*

Requisit ion Order

Status

0..*

1

0..*

1

RGT002

< < Co re>>

MAH200

<<Core>>

MA_Read_Master

<<Hidden>>

PO_Req_Ord

< < V isua l>>

Employee MasterAD_empl_Mast

< < V isua l>>RGF004

<<Core>>

Figure 7. Masterfile and Transaction Pattern

This class diagram is created under the “Design: Requisition Processing”package in the Logical View. The class diagram now shows that thebusiness class Requisition Order is made up of a Rubico Object Class



called PO_Req_Ord which is simply an alias of RGT002. It also shows thatthe PO_Req_Ord is dependent on MA_Read_Master, which is an alias of aMAH200. The MA_Read_Master is dependant on the AD_Empl_Mast whichis an alias of RGF004. These Rubico objects are now used in SequenceDiagrams to replace the business objects. Operations in the analysisdiagrams may also be replaced with Rubico objects.

Note that the following stereotypes must be added :1) Core – For all Rubico core objects2) Visual – For all Rubico alias objects which are visual to the user3) Hidden – For all Rubico alias objects which are hidden objects.

Chapter 5 Conclusion: Methodology

The above is a conceptual overview of the Rubico Methodology. There isconsiderable detail contained within the Methodology Toolset, which allRubico Consultants strictly adhere to.

As Rubico is a learning organisation, many aspects of the Methodology willbe revised and enhanced based on the experiences that projects willprovide.

The Client can feel confident of the Rubico Methodology, as it has provensuccessful over many implementations.



Chapter 6 Case Study: Acme Manufacturing

The following chapters cover a case study about a manufacturing company.It covers the analysis documentation, design documentation, Rubico objectsand the testing documents needed to implement a solution.

The last section covers the Rubico UML Bridge. This is where the designpatterns are used to generate the final solution.

Only a small portion of the actual documentation is used here.



Chapter 7 Introduction to the To-Be Document forAcme Manufacturing

7.1 Purpose of this documentThe purpose of this document is to describe the “To Be” business operationof the client. It encapsulates the current vision, strategic considerations,processes and activities used to manage and execute the day to dayoperation of the organisation.

This document will form the basis for the establishment of processes andsystem requirements in a “to be” scenario.

7.2 Scope of the projectThis Document will cover Phase 1 of the Acme Manufacturing Project asoutlined in the Conceptual process Requirements Document

7.3 Definitions, acronyms and abbreviationsGRV - Goods Received VoucherGRN - Goods Returned NoteGRA - Goods Returned AdviceGL - General LedgerCB - Cash BookUOM - Unit of MeasureW/H - WarehouseC.R.U.D - Create, Read, Update, DeleteQC - Quality CheckPO - Purchase OrderPPV - Percentage Price Variance

7.4 ReferencesThis document was generated from version 115 of the ProcurementAnalysis Model.



Chapter 8 Process Architecture

8.1 Business Process OverviewThe purchasing function involves the procurement of materials, supplies,equipment and services at certain costs with required quality standards.This is done to support the production of merchandise and products.The objective of a procurement system should be the following: - Placing purchase orders - Acceptance of goods delivered - Validation.

8.1.1 Process Package Overview

Requisition Processing

Purchase Order Processing

Goods Receiving

Order Monitoring

Supplier Selection

The procurement function will consist of tasks starting at requisitioning and ordering throughto goods receiving. Quotes, vendor selection and contracts will not be included. For thisProject import documentation has been excluded. Requisition processing and Supplierselection are not requirements for Phase 1 of this project. This document contains bothanalysis and some design information. The Client does not ever see the design sequencediagrams or classes. Sequence diagrams seldom contain attribute dependant operations,due to the fact that in the product Rubico can dynamically change attributes.

8.1.2 Interfaces



8.1.2.1 Interface 1< Source Process to Target Process >

Item DescriptionInterface Description This interface consolidates account payable transactions and allocates

their amounts to general ledger accounts.Frequency DailyLevel Interface to GL account by cost centreComments

8.1.3 Purchase Order Processing

Replenishment Planner

Order Authoriser

Supplier

(from Supplier Selection)

Buyer

Stock Item only

Place OrderReceives Order

Maintain Order

Informs of Exceptions

Inform

Monitor Order

Own Orders Only

Master Planner

Inform

Inform

All Orders

Order Inquiry

<<Uses>>

The objective of Purchase Order Processing is to capture and send ordersto a Supplier. (Sending Orders to the Supplier may be via fax, e-mail or amanual process.) The Buyer can maintain the order. This includes creatingand deleting orders. Once the Buyer has received the signed copy of theRequisition, the order can be placed with the Supplier. Once a purchaseorder number has been generated, it becomes the controlling number for allactivities relating to the order and delivery of goods.

The customers 'Authority No' is a manually generated number the Buyer willassign to a system PO. The Authority no. will default to the Order number.This Authority number can be overwritten with a 'Authority number' given tothe client. A check must be put in to confirm that the authority number isunique. Purchase Orders can be entered manually or created automaticallywhen the Replenishment Planner confirms the suggested orders from thematerial requirement planning run. The Replenishment Planner can playthe role of the Buyer for stock items only.

8.1.3.1 Place Order

The order can be forwarded as: - a hardcopy. - a system generated fax - e-mail - a manual process



8.1.3.1.1 Scenario: Analysis: Placing an Order

: Buyer : Purchase

Order : PO Report

: Supplier

1: Complete( )2: Create( )

3: Select Fax, E-mail or Print Order( )4: Inform( )

8.1.3.2 Maintain Order

A Buyer creates an order from a signed requisition (Non-stock items) or byconfirming recommended orders. A Non Stock order should be linked to anrequisition document.

The date can be amended on a Purchase Order. Quantities can bechanged but only down, not up. If quantities need to be amended up, anadditional PO must be created for the increased amount.



8.1.3.2.1 Scenario: Analysis: Create Purchase Order

: Buyer : Purchase Order Header

: Order Authoriser

: Purchase Order Detail

1: Create( )

2: Create( )

3: Inform of Exceptions( )

Note: Depending on whether the Transaction type is for Stock of Non-Stock Items, the Detail Attribute will change. For Stock items, Item code, Supplier code and special instruction will be added. For Non-Stock items, the GL code, Type and Quote Ref. No. Attributes will be added. (See Class Diagram)

The buyer can create an order. An order is normally linked to one or manyrequisitions. Orders can be created without a requisition system (Phase 2issue) but will be listed as exceptions and printed. If the requisition has thecorrect authority check completed, then the Buyer will be able to Order theGoods as long as the order does not exceed the maximum stock levels.



8.1.3.2.2 Scenario: Analysis: Maintain Purchase Order

: Buyer : Purchase

Order : Supplier : Master Planner

1: Modify/Delete( )

2: Inform( )

Modify Date and quantity down only. 3: Inform of PO Changes( )

Depending on whether the amended order is accepted or declined, the supplier must be informed.

The Buyer can amend an existing order. If the buyer has the authorisationto amend the order, the supplier and the Master Planner must be informed.Quantities can be move down and Dates modified.



8.1.3.2.3 Scenario: Analysis: Close Purchase Order

: Buyer : Purchase

Order

1: Close( )

The Buyer will change the status manually to 'Completed' even if not all theline items have been received.

8.1.3.3 Monitor Order

Depending on the business rules, various employees can have the ability toview or Monitor their relevant orders (On-line or via a hard copy) The Buyer,creditors clerk and the master planner should be allowed to view the orders.This Report, the "PO Report", can be found in the 'Reporting Requirements'section of this document.



8.1.3.3.1 Scenario: Analysis: Monitor Order

: Buyer : Purchase

Order : Master Planner : Replenishment

Planner

1: View( )

2: View( )

3: View( )

The Buyer can monitor an order online or via a hardcopy. A requestor canmonitor the order via the requisition status and quantity ordered. The Storekeeper might also need to view relevant orders.(e.g. Warehouse)

8.1.3.4 Order Inquiry



8.1.3.4.1 Scenario: Analysis: Inquire on Orders

: Buyer : Master Planner : PO Inquiry : Purchase

Order

1: View( )2: Read Buyers Only( )

3: View( )4: View All( )

8.1.4 Goods Receiving

Requestor

(from Requisition Processing)

Buyer

(from Purchase Order Processing)

Master Planner


Creditors Clerk

Accept Goods

Informed if Non Stock

Notified of Exceptions

Monitor DeliveriesOwn

All

Capture GRA Details

Copy to

GRN Generated

Inform

Receive Goods

Receiving Clerk

If goods are returned before GRV'd

StoremanQA Inspector

QA Required

Inform of QA Results

Inform

The Receiving Clerk along with the Buyer can monitor for expecteddeliveries. Once the goods have been received a Goods Received Voucher



(GRV) is generated on the system. From there the goods can be released tostock or go for a quality inspection.

Once goods have been released to stock, only the Storeman and the QAinspector can return goods. For this a Goods Returned Note (GRN) must begenerated by the system.

The Buyer should always be notified of exceptions.

When non-stock items are received, the Requestor must be informed. AGRA (Goods Returned Advice) is manually prepared when goods arereceived but returned before a GRV has been created.

Two scenarios exist when returning goods- Firstly, return goods on receipt(GRA) and secondly, return goods (GRN) after they have been GRV'd. TheGRA (Goods Returned Advice) is to be a manual process. No stock writebacks or financial entry write backs are done. The GRN will be a systemfunction and will also write back stock and create the appropriate financialentries.

When the Storeman creates a GRN the Creditors Clerk must be informed.The user must have the ability to print a GRV or a GRN

8.1.4.1 Receive Goods

A Goods Received Voucher (GRV) needs to be generated for the receipt ofevery Stock and Non-stock items. i.e. a GRV is created for all payments.

It is important to note that an order can have many deliveries, but that aGRV can only belong to one order.

Receiving clerk can over receive. The Clerk must be informed (prompted) ofthe excess and decide whether to receive the goods or not. The PO detailline must be closed automatically when the Qty accepted is equal to the Qtyordered.



8.1.4.1.1 Scenario: Analysis: Receive Goods

: Supplier : Receiving Clerk : Goods Received

Voucher : Item

Master File : Warehouse

Item : QA Inspector : Requestor

: Purchase Order

1: Deliver Goods( )2: Record Delivery( )

3: Validate( )

4: Status Change( )

The status is changed to Received. (See State Diagram)

5: Check for QA Requirements( )

6: [If No QA Required] Release to Stock( )

9: Capture QA Results & Change Status( )

7: [If QA required] Forward( )

Depending on the business rules, the delivered goods may need a QA and must be forwarded for a QA inspection. If no QA is required, the goods are release directly to stock.

Depending on the QA requirements, the goods will be marked as 'Received' or 'QA Waiting'.

If the Goods Pass QA, then the goods can be released to stock. The status on the GRV changed from 'Open' to 'QA Waiting'. Only when the Receiving Clerk releases the goods to stock will the status of the GRV change from 'QA Waiting' to 'Closed' (See State Diagram)

11: Informed of Received Goods( )

8: Informed of QA Results( )

10: [If QA Passed] Release to Stock( )

Record Counted Qty

Validate the goods before a GRV is recorded. If incorrect Generate a manual GRA

Goods are delivered to the Receiving Clerk from the Supplier. A GRV isgenerated (The GRV Status is now "OPEN"). When the order no iscaptured, the status of the PO will change from 'Ordered' to 'Received' TheGRV provides proof that the listed quantities of goods have been delivered.Depending on the goods delivered, a QC inspection may be necessarybefore the goods are released to stock (A status of 'QC Waiting' is allocatedto the GRV). If no QC is required, the Receiving Clerk releases the goodsdirectly to stock. The status of the PO line item will then change from'Received' to 'Completed' if the Qty Accepted >= Qty Ordered. A GRV detailline must be linked to a PO detail line.

If a QC is completed the status will change from 'QC Waiting' to 'CLOSED'once the goods have been received. This is when the Requestor is informedof the availability of the goods. If the goods received were for a suggestedorders, then the Replenishment Planner is informed.

Report needed at month end or prior to stock take to inform Storeman ofstock that have been received but not yet been GRVed. System must checkthat quantity received is not more than the quantity ordered. The Systemmust not stop the over receipt of goods - the order line item mustautomatically be closed as complete for over supplies. An exception reportwill highlight all over supplies.



8.1.4.2 Monitor Deliveries

Depending on the business rules, the Buyer and the Receiving Clerk will beable to view expected deliveries online or on a hardcopy. Need the ability tolist outstanding PO's by supplier, due date, item etc. (See the availablefilters in PO 'Reporting Requirements' within this document.) This will be anon-line inquiry and reporting function.

8.1.4.2.1 Scenario: Analysis: Monitor Goods Received

: Receiving Clerk : Buyer : Master Planner : PO 2 GRV

Selection : Goods Received

1: View( )

2: View( )

3: View( )

4: View Selected GRV( )

8.1.4.3 Capture GRA Details

This is a manual process.



8.1.4.3.1 Scenario: Analysis: Return Goods To Supplier

: Receiving Clerk :

GRA : Creditors Clerk : Suppl ier

1: Create( )

2: Copy of GRA( )

3: Inform of Returned Goods( )This is a Manual Process an will not be included in the design.

The Receiving Clerk and the QA Inspector both have the authority torequest the return of goods for various reasons. Goods are returned againsta GRV detail line. If the supplier delivers defective goods, the ReceivingClerk will not accept the goods delivered and return them to the supplier.This means that some or all of the goods will not be recorded on the GRV.In this instance, a GRA details (Goods Returned Advice) must be captured.

8.1.4.4 Accept Goods

When the goods/services are delivered, the line item status on the GRV ischanged to 'Received'. From there it can undergo a quality assurance checkand/or be accepted to stock. This is were the GRV is printed.



8.1.4.4.1 Scenario: Analysis: Release Goods

: Warehouse

: Receiving Clerk : Goods Received

Voucher

The Buyer is informed of the goods received. This includes exceptions. E.g. quantities that need to be re-ordered.

1: Record Accepted Qty( )2: [If GRV for Stock] Update Stock( )

6: Print( )

Creditors : GL

: Purchase Order

3: Update

4: Update Qty Amended( )

5: [If final GRV] PO closed( )

Prompt if Qty is still outstanding.

Prompt:" Is this the Last line item entry?" This may related to a Role.

The Receiving Clerk releases goods. There are two types of goods namely:Stock Items and Non stock items. The Buyer must have the ability to re-open PO's only when there is still an outstanding Qty on the PO. Once thetotal quantity accepted equals or exceeds the total quantity ordered thesystem must close the order line item as complete. The system must allowrelevant users to manually close the order line item as being completed,even if the quantity ordered does not equal the quantity accepted for thatorder line.

8.1.4.5 GRN Generated

Only the Storeman can create a GRN (Goods Received Note for itemsreturned.) GRNs will be covered in detail in the Warehousing module -Inventory Management.



8.1.5 Order Monitoring

Order Authoriser


Requestor


Monitor Requisitions(from Requisition Processing)

Only Own Requisitions

Monitor Order(from Purchase Order Processing)

Receiving Clerk

(from Goods Receiving)

Buyer

(from Purchase Order Pro cessi ng)

Relevant

Own Orders Only

Master Planner


All Orders

Monitor Deliveries(from Goods Receiving)

Own

All

All the monitoring reports required for this section can be found in 'ReportingRequirements' within this document.

8.1.6 Supplier Selection

Maintain Mas ter Files

Accountant Supplier

Procurement Manager

Buyer


Maintain Supplier Master File

View

View



The Procurement Manager has the ability to maintain the Item master File,linking a particular stock item to a suitable supplier. Supplier Selection is apurely manual process for phase 1 of this project, and no systemfunctionality will be developed to cater for this process. All relevant parties(Buyer, Creditors Clerk) will fill in a form containing supplier details. Once ithas been completed and authorised, it is captured into the system by theAccountant. Supplier Details will be listed and signed off by the Supplier.

8.1.6.1 Maintain Supplier Master File

Data pertaining to each active supplier including evaluations and pastpurchases need to be maintained.

8.1.6.1.1 Scenario: Analysis: Supplier Master File Maintenance

: Accountant : Supplier Master File

: Procurement Manager

: Buyer

1: Create( )

2: Read( )

3: Update( )

4: Delete( )

5: Read( )

Need a structure to link/chain suppliers into a hierarchy. This to be only 2 levels, one the parent company, the 2nd level all the branches of that supplier. (E.g. Plascon National (top level), each Plascon branch/supplier nationally on the lower level.) This is purely for reporting requirements only. The User must be able to maintain the Supplier Structure.

6: Read( )

Depending on the Business rules, the Accountant will have the authority tocreate, read, update and delete information on a supplier master. The buyerwill only have the ability to view the Supplier Master file.



8.1.6.2 Maintain Master Files

In this particular instance a material must be linked to a preferred supplierby W/H. Material Items must have a list of up to 3 preferred suppliers. Ifpreferred supplier 1 is filled in, this will then serve also as the defaultsupplier. System must keep the last three purchase prices per item per W/Hwith the purchase date.

8.1.6.2.1 Scenario: Analysis: Master File Maintenance

: Item


: Supplier Master File

1: Read( )

2: [If Stock Item] Retrieve Default Supplier( )

: Supplier W/H Item Matrix

: Warehouse Item

3: Maintain( )

4: Maintain( )

The Procurement Manager can only maintain the Item master File with thedefault supplier of that particular stock item. The Procurement manager alsohas the ability to maintain item related master File such as the Supplier W/HItem Matrix and the W/H Item.



8.1.7 Requisition Processing

Requisit ion Authorisor

Requestor

Authority Checking

Declined

Monitor Requisitions

Only Own Requisitions Maintain Requisition

Inform of Unauthorised Req.

Buyer

(from Purchase Order Processing)Confirmed

Relevant

Get Quote

The purchase requisitioning task is a request to the purchasing departmentto procure a certain quantity of material or service on or by a certain date. Inthe diagram above, the Buyer can play the role of a Requestor. TheRequestor will create a requisition in the 'Maintain Requisition' use case. Ifthe requisition does not contain a quoted price, then it must go to the Buyerbefore it can get authorisation. If the Requestor does not have the correctauthorisation for the requisition, then the Requisition Authorisor must benotified of the request. The process does not prevent the requestor fromcompleting the transaction, but only warns the requestor of the insufficientauthority. The Requestor can also monitor all relevant requisitions.

8.1.7.1 Maintain Requisition

The Requestor of the requisition has the ability to maintain (C.R.U.D) theirown requisitions. Should a requisition require prices, the Buyer is notified toobtain quotes for the relevant goods/services. All requisitions mustfurthermore be authorised by the Requisition Authorisor before therequisitions can be sent to the Buyer.



8.1.7.1.1 Scenario: Analysis: Create Requisition

: Requestor : Requisition Authorisor

: Buyer : Employee Master File

: Item Master File

: PO Requisition

1: Select Requisition Type( )

2: Capture Requisition Details( )

7: Inform( )


4: Retrieve Default W/H( )

5: Retrieve Item Cost( )

6: [If Non-Stock Item] Check validity of GL code( )

If the requisition is for an existing stock item, then the default supplier must be allocated to the requisition item.

The Role of the Requestor can be played by the Buyer and the Replenishment Planner

If the Item is a stock item the amount is allocated against the stock account for the material.

Summary and Detail report per day (Trevor Van Rooyen to investigate) Check for over ordering & authorities. This is the Requisition Report.

Display Message if level is exceeded. The Buyer can still continue or abort.

8: Modify/Delete( )

11: [If Authority Insufficient ] Get Authorisation( )

10: Informed( )

9: Check Authority Level( )

A requisition can be created for four different reasons namely: To CaptureReplenishment Requisition; Capture direct Services; CAPEX and theCapture of Non-Stock Item Requisition. For Acme Manufacturing, theserequisition types will fall into two main categories namely: Stock Items andNon-Stock Items. Non-Stock items are also known as Direct Items.

Replenishment type requisition: (Stock Item) The request for a requisitioncould be Manual or Automatic. This process requires Item Details to becaptured. The System will validate that the item code exists. A date requiredwill default to the lead time of the material which can be amended. Thestock availability will show this as being due-in. Costing is based onstandard cost kept on the Item master file. If a default Warehouse for thereplenishment material exists this will automatically be allocated on therequisition. This default Warehouse must be maintained for all materials. AGL Stock account must be kept per product group. Posting to GL accountsneed to be done in a logical grouping. (An inquiry report per order no. &some logical grouping will be required for audit trails. This Report, the"Requisition Report", Can be found in the 'Reporting Requirements' sectionof this document.) If a default Supplier for the material exists in the system,they can be found automatically and the purchase requisition can beallocated to the correct supplier. If a Supplier is not known, the requisitioncan be selected for the quoting procedure when the buyer receives therequisition. Stock items do not have budgets, rather stock levels.Replenishment of stock items must be checked against stock levelswhereas all other types of requisition are checked against budgets.



Direct Services type requisition: (Non-Stock Items) would be expenses thatneed to be incurred i.e. not item codes, a receiving process will take place.An expense code needs to be recorded and must be a valid GL accountwith a budget value against it.(The budget value could be zero.) The valueaffecting the GL will be based on the value of the service entered.(Excl. Vat)

A Capital Expenditure requisition (Non-Stock Item): would be for capitalexpenses that need to be incurred. A work in process account needs to berecorded and must be a valid GL account with a budget. Once the asset istransferred to fixed assets, only then will the asset be recorded and the workin process account reduced. The value affecting the GL will be based on thevalue of the asset entered.(Excl. Vat).

A non-stock type requisition:(Non-Stock Item) would be items that do notget recorded in the stock master but needs to be received (GRVed). A validGL expense code and budget must exist. The value affecting the GL will bebased on the value of the item received.(Excl. Vat)

Validations to stop a requisition if budget/stock levels are exceeded mustNOT be built in - the transaction must be allowed to continue. (System toonly warn user that maximum stock level or budget is being exceeded.)Instead an exception report to show where stock levels/Budgets wereexceeded is required at end of day ( - part of Warehousing). This Report,the "Requisition Exception Report", can be found in the 'ReportingRequirements' section of this document The system must have a matrix(requestor, Authorisor, stock item, cost centre etc) of authority levels built inthat is checked at time of capturing - the system must NOT stop the processbut allow the user to continue or abort the transaction.

Purchase requisitions can be approved for ordering based on certaincompany policies. These policies must specify who must approve therequisitions and in what order/sequence. The authorising of requisitions canbe based on the type of requisition, value and / or grouping of materialsrequired.



8.1.7.1.2 Scenario: Analysis: Maintain Requisition

: Requestor : PO

Requisition : Requisition

Authorisor

1: Modify/Delete( )

2: Modify/Delete( )

The requestor can only modify or delete their own requisitions. A requisitioncan only be deleted if there are no orders generated against it. If theRequestor submits a requisition without a quote, the buyer must get thequotes for the relevant items and then maintain the requisition with theupdated values.

8.1.7.2 Authority Checking

The Requisition Authorisor has the ability to authorise or decline POrequisitions.(For Non-Stock Items only) If it is authorised the Buyer isnotified. If it is declined the Requestor and the Buyer are notified. Shouldthe Requisition Authorisor not have sufficient levels of authorisation, aprocess of escalation is initiated until a Requisition Authorisor with theappropriate authority level is found.



8.1.7.2.1 Scenario: Analysis: Authorise Requisition

: Requisition Authorisor

: PO Requisition

: Buyer : Requestor : Employee Master File

: Budget

1: View( )

2: View( )

If the Authority level is insufficient then the requisition is referred to the next level of authority.

Depending on the decision made by the Requisition Authorisor, the requisition can be approved, declined or modified.

7: Inform( )

8: [If Declined] Notify( )

9: [If Requisition Modified] Notify of Changes( )


4: [If Authority Insufficient] Determine Next Level of Authority( )

5: Inform( )

6: Status Change( )

In this sequence diagram, the Requisition Authorisor has already read theexception report for unauthorised Requisitions. If a requisition was createdand the user did not have a sufficient authority level, the requisition must beforwarded to the relevant user to authorise. Once the correct level ofauthority has been obtained, then the Authorisor must inform the buyer ofthe out come of the decision. If the requisition is refused or modified, theRequestor and the Buyer must be notified. Purchase requisitions can beapproved for ordering based on certain company policies. These policiesmust specify who must authorise the requisitions and in what order. Thereleasing of requisitions can be based on the type of requisition, value and /or grouping of materials required.

8.1.7.3 Monitor Requisitions

Depending on the business rules, various employees can have the ability toview or Monitor their relevant requisitions (On-line or via a hard copy)



8.1.7.3.1 Scenario: Analysis: Monitor Requisitions

: Requestor : Buyer : PO


Authorisor

1: View( )

2: View( )

3: View( )

The Requestor, Buyer and Replenishment planner all have the ability toview their relevant requisitions. This may be via an online function of via ahardcopy. This is a phase two requirement, but the report "RequisitionReport", can be found in the 'Reporting Requirements' section of thisdocument. The viewing of Requisitions must be limited to the role of theuser. Note this process is for Non-Stock Items only.



8.1.8 Roles and Security

Buyer


Order Authoriser

(from Purchase Order Processing)Replenishment Planner


Stock Item only

Master Planner


Creditors Clerk


Receiving Clerk


QA Inspector


Inform of QA ResultsSupplier


Deliver Goods & Documentation

Storeman


Inform of QA ResultsInformDeliver Goods & Documentation

Accountant


Procurement Manager


Requestor


Requisition Authorisor


Person

(from Use Case View)



8.1.9 Reporting Requirements

PO Report

Supplier CodeSupplier DescriptionOrder NoAuthority NoBuyerDateTime CreatedOrder TypeItem CodeItem DescriptionW/H CodeRequest NoUOMQty RequiredDue DateQty ReceivedQty OutstandingPriceTrade Discount 1Trade Discount 2StatusExtended Value Outstanding

<<Report>>GRV Report

Supplier CodeSupplier Description GRV NoPurchase Order NoAuthority NoSuppliers Invoice/Delivery NoteDate ReceivedGRV StatusItem CodeItem DescriptionW/H CodeUOMQty on Delivery NoteQty CountedQty Inspected OKQty RejectedQty AcceptedQty On GRA

<<Report>> GRN Report

GRN NoSupplier CodeSupplier DescriptionSuppliers Invoice/Delivery Note GRV Ref. NoPurchase Order NoAuthority NoDate ReturnedItem CodeItem DescriptionQty on GRNQty ReturnedUnit Net PriceReason CodeReason DescriptionExtended ValueSupplier Credit NoteSupplier ValueSub TotalGrand Total

<<Report>>

Trade Discount/Price Exception Report

Purchase Order No.Supplier CodeSupplier DescriptionItem CodeItem DescriptionWarehouse CodeTrade Discount 1PriceTrade Discount 2Trade Discount 1 (Matrix)Trade Discount 2 (Matrix)Price (Matrix)Date On (Matrix)Date Off (Matrix)

<<Report>>

Over Supplies Exception Report<<Report>>

GRV Exception Report<<Report>>

Daily Over Order Exception Report

WarehouseItem MaximumStock On HandOrder no.Date CreatedCreated ByQty on OrderGrand Total

<<Report>>

Supplier Master File Report

Supplier CodeSupplier NameSupplier StatusSettlement DiscountStandard Trade DiscountStreet No.Street NameSuburbCityPhysical Postal CodeP.O. Box No.SuburbPostal CodeChain CodeBanking DetailsE-mail AddressCreditor Contact PersonMD NameMD NumberPhone NumberFax NoOrder Placement MethodStatement Delivery MethodPayment TermsMethod of PaymentSupplier RatingDate Created

<<Report>>

Item Master File Report

Item CodeItem DescriptionDefault Warehouse CodeStandard CostUOM TAXMaterial CostLast Cost PriceInventory UnitForecast MethodD/Note inquiryMRP - Lead timeMRP - Supplier CodeMRP - W/H

<<Report>>

Supplier W/H Item Master Matrix Report

Supplier CodeSupplier DescriptionWarehouse CodeMaterial Item CodePriceTrade Discount 1 Trade Discount 2Date OnDate OffMaximum Stock LevelMinimum Stock LevelMultiplesType (MRP or ROP)

<<Report>>

Stock Adjustments By Supplier Report

Supplier CodeSupplier DescriptionItem CodeItem DescriptionQty AdjustedExtend ValueDateSupplier TotalGrand Total

<<Report>>

PPV Report

GRV QtyGRV Std PricePO QtyPO PriceInvoice ValueGRV <-> PO DifferencePO <-> Invoice DifferenceTotal DifferenceDifference By SupplierDifference By RequestorGrand Total

<<Report>>

Where possible, printing must be on the cheapest format. User requireseconomical, speedy and quality printouts for reporting Selection criteriamust be displayed on the first page of the report.

Attribute information will not be repeated...but at the header on each pageonly.Zeros must be printed, but not with decimal places.

Not all the reports and properties are shown in this sample.

8.1.9.1 PO Report

FILTER BY: From To Supplier * * Warehouse * * Item * * Product Group * * Order No. * * Due Date * * Date Created * * Buyer * * Status * *

SEQUENCE INFORMATION BY:



Supplier/Item Warehouse/Item Item/Due Date Product Group/Item Order no./Item Due date/Item Date Created/Item Buyer/Item

BUSINESS REQUIREMENTS

Role of Consumer:Distribution Type (Online, batch etc.):Executed from Rubico (Yes/no):Special Stationery (Pre-printed, etc.):Type of Printer:Printing layout (Landscape, portrait, size, etc.):Number of copies:Controlled copies (Legal req. etc.):3rd Party Approval (Banks etc.)Data Security / Sensitivity:Branch data Access:Report requirements:Report Name on Page header:Report Type:Page number required? (Yes/no):Business Rules:Business Terms:Mass / kg:Customer/ client:Prompts and filters (Date range, branch, user-id etc.):Special formats (Dates, numbers):Special requirements:

TECHNICAL REPORTING REQUIREMENTS:

Report Name:Catalog Name:Show report and user name? (Yes/no):Are hotfiles required?:Business rules and requirements (Filters, flags etc.):Special requirements: (Colours, fonts, borders etc.):Report field names:Business terms:Mass / kg orCustomer / client:Dates - give format:Amounts - (show format e.g. 0.00):Are there any optional fields?:Groupings, associations, sorting:Calculations:Special formulas:Totals:Running page totals:Running totals:



Totals per group etc.:Page Breaks:Page Headers/Footers:List Headers/Footers:

8.1.9.2 Trade Discount/Price Exception Report

This report displays PO for when the purchase order trade discount is notequal to trade discount on supplier material item matrix.(To be Run Overnight or Daily)

FILTER BY: From To PPV -5% +5%

8.1.9.3 GRV Exception Report

This Report will highlight GRV's for any of the following:

Qty Counted <> Qty Inspected + Qty RejectedQty inspected OK <> Qty To StockQty on d/note > 0 & Qty Counted = 0 & Qty on GRA = 0.

8.1.9.4 Supplier Master File Report

FILTER BY: From To Supplier * * Supplier Status * *


Supplier (ascending)

8.1.9.5 Item Master File Report

FILTER BY: From To Item * * Product Group * * Description * *


Supplier/Item Warehouse/Item Item/Due Date Product Group/Item Order no./Item Due date/Item Date Created/Item Buyer/Item

Filters - from and to ranges for: Material Item Code, Material Description,Product Group



Sequence: 1. Material Item Code 2. Material Description 3. Product Group

8.1.10 Rubico Structures

Product<<Structure>>

Major Reporting<<Structure Group>>

Sub Reporting<<Structure Group>>

Major Products<<Structure Group>>

Minor Products<<Structure Group>>

Item<<Structure Group>>

Supplier Structure<<Struc ture>>

Warehouse Structure<<Structure>>

Region<<Structure Group>>

Suppliers<<Structure Group>>

Company<<Structure Group>>

Profit Center<<Structure Group>>

Area<<Structure Group>>

Warehouses<<Structure Group>>

8.1.10.1 Product

Description: This is the main item structure for all products for theprocurement system.Type: Non-RecursiveValidations: Main product structure for Acme Manufacturing companiesComments: None

8.1.10.2 Supplier Structure

Description: This is the only Supplier structure for all suppliers referenced inthe procurement system.Type: Non-RecursiveValidations: Main Supplier structure for Acme Manufacturing companiesComments: None



8.1.10.3 Warehouse Structure

Description: The warehouse structure holds all logical storage areas for thesystem. It also doubles up as a location/Company structure for the financialsystem.Type: Non-RecursiveValidations: Warehouses for Acme Manufacturing companies onlyComments: None

8.2 Class Diagram



Stock Account(from Design: Supplier Selection)

Cardex Report(from Design: Supplier Selection)

<<Enquiry>>

Supplier Inquiry(from Design: Supplier Selection)

<<Enquiry>>

Item Inquiry(from Design: Supplier Selection)

<<Enquiry>>

Requisition Inquiry(from Design: Requisition Processing)

<<Enquiry>>

GRV Inquiry(from Design: Goods Receiving)

<<Enquiry>>

PO Inquiry(from Design: Purchase Order Processing)

<<Enquiry>>

GRN Inquiry(from Design: Goods Receiving)

<<Enquiry>>

Employee Master File

Employee No. Employee NameEmployee Surname Employee ID No.

(from Design: Supplier Selection)

Non-Stock Item

Expence CodeCost CenterDescription of ProductQuoted Reference No.

(from Design: Purchase Order Processing)Stock Items

Item CodeItem Description

(from Design: Purchase Order Processing)

Budget

Budget Amount


Employee GL Accounts(from Design: Supplier Selection)

0..*

1

0..*

1

GL Account(from Design: Supplier Selection)

0..*

1

0..*

1

0..*

1

0..*

1GRN Header

GRN NoSupplier CodeSupplier DescriptionSuppliers Invoice/Delivery Note GRV Ref. NoPurchase Order No.Authority No.Date Returned

(from Design: Goods Receiving)

GRN Detail

Item CodeItem DescriptionQty on GRNQty ReturnedUnit Net PriceGRN Reason CodeReason DescriptionSupplier Credit NoteSupplier Value


GRV Header

GRV NoSupplier CodeSupplier Description GRV StatusAuthority NoPurchase Order No.Suppliers Invoice/Delivery NoteDate Received


GRV Detail

UOMQty OrderedQty Received to DateQty on Delivery NoteQty CountedQty Inspected OKQty RejectedQty AcceptedUnit Net PriceQty On GRASupplier Invoice No.Supplier Invoice ValueGRV Total (Excl. Vat)


Requisition Status(from Design: Requisition Processing)

PO Requisition(from Design: Requisition Processing)

10..*

10..*

Buyer


Buyer Role

WarehouseProduct Group


1

0..*

1

0..*

Warehouse

Warehouse CodeWarehouse Description


0..*1 0..*1

Item Master File

Item CodeItem DescriptionStandard CostStocking UOM TAXMaterial CostLast Cost PriceInventory UnitForecast MethodD/Note inquiryMRP - Lead timeMRP - Supplier Code MRP - W/H


0..*

1

0..*

1

Warehouse Item

W/H CodeItem CodeInventory on HoldInventory on OrderSupplier CodeLead timeInventory on HandMinimum Order QtyMaximum Order QtyRe-order Point


1..*

0..1

1..*

0..1

1..*

0..1

1..*

0..1

PO Requisition Header

Request NoRequisition TypeCreated ByRequested ByAuthorised ByDateTime CreatedRequest Status

(from Design: Requisition Processing)

Transaction Type(from Design: Purchase Order Processing)

0..*

1

0..*

1

Supplier Status(from Design: Supplier Selection)

Supplier W/H Item Matrix

Supplier CodeItem CodeW/H CodeSupplier PriceDate OnDate OffMax Stock LevelMinimum Stock LevelMultiplesType (MRP or ROP)Record Qty on D/Note?Record Qty Counted?Record Qty Inspected OK?Record Qty Rejected?Record Qty Accepted?EOQSupplier Lead TimeOrdering UOMConversion Factor


11..* 11..*

PO Requisition Detail

WarehouseSupplier CodeUOMQty RequiredDue DatePriceTrade Discount 1 Trade Discount 2Line Status

(from Design: Requisition Processing)

11..*1

1..*

0..*

1

0..*

1

Purchase Order Header

Purchase Order NoSupplier CodeSupplier DescriptionOrder TypeBuyerDateTime CreatedOrder Status : PO StatusSettlement DiscountAuthority NoW /H CodeW /H DescriptionVersion No


0..* 10..* 1

Split line Item

Date RequiredQty Required


Supplier Master File

Supplier CodeSupplier NameSupplier StatusSettlement Discount %Payment Terms (Days)Street No.Street NameSuburbCityPhysical Postal CodeP.O. Box No.SuburbPostal CodeBanking DetailsE-mail AddressCreditor Contact PersonMD NameMD NumberPhone NumberFax NoStatement Delivery MethodMethod of PaymentSupplier Rating Date CreatedTrade Discount 1 Trade Discount 2


0..*

1

0..*

1

1..*1 1..*1

0..*

1

0..*

1

Purchase Order Detail

Special InstructionsRequisition NoOrdering UOMQty RequiredQty ReceivedDate RequiredStandard CostSupplier PriceTrade Discount 1Trade Discount 2Requested ByTotal Value (Excl.Vat)Line Item Status : PO Status


0..*

1

0..*

1

0..*

1

0..*

1

PO Status(from Design: Purchase Order Processing)

GRV Status(from Design: Goods Receiving)

Goods Returned Note(from Design: Goods Receiving)

Purchase Order(from Design: Purchase Order Processing)

0..*

1

0..*

1

0..*

1

0..*

1

Goods Received Voucher(from Design: Goods Receiving)

0..*

1

0..*

1

1

0..*

1

0..*

1

0..*

1

0..*GRA

GRA No.Qty ReturnedReason


1

0..*

1

0..*



8.2.1.1 Purchase Order

Both the Header and Detail must have a notes field. Amended PO must behighlighted if the PO is changed.

Note: Depending on whether the Transaction type is for Stock of Non-StockItems, the Detail Attribute will change. For Stock items, Item code, Suppliercode and special instruction will be added. For Non-Stock items, the GLcode, Type and Quote Ref. No. Attributes will be added.

Once the PO has been Printed, the status must be changed to Printed....See new Printing status diagram.

8.2.1.2 Purchase Order Header

8.2.1.3 Purchase Order Detail

Note: Depending on whether the Transaction type is for Stock of Non-StockItems, the Detail Attribute will change. For Stock items, Item code, Suppliercode and special instruction will be added. For Non-Stock items, the GLcode, Type and Quote Ref. No. Attributes will be added. (There must be theability to duplicate detail lines.)

8.2.1.4 PO Inquiry

Must be able to view per item & view detail lines per order.

8.2.1.5 PO Status

CancelledOrdered

Received Archived

Null

Captured

Complete

Cancel PO

Partial Receipt

Goods / Services Received

After Elapsed Period

Capture PO

Release to Stock



8.2.1.6 Transaction Type

Both Purchase orders and Requisitions have got the same transactiontypes; Namely: Stock and Non-Stock Items.

8.2.1.7 Split line Item

There must be the ability to split a detail line to cater for multiple deliveries.i.e. Have different deliveries for various dates.

8.2.1.8 Goods Received Voucher

If the Qty on the delivery note varies from the Qty GRN then a GRN must begenerated (Pop-up)

8.2.1.9 Goods Returned Note

Need to monitor reprints on GRN's

8.2.1.10 GRV Inquiry

Must have a view only function of transaction.

8.2.1.11 GRN Inquiry

Must have a view only function of transaction.

8.2.1.12 GRV Status

C L O S E D

Q C W a i t i n g

D / N o t e R e c e i v e d , G o o d s C o u n t e d

N u l l

O p e n

N o Q C R e q u i r e d

Q C R e q u i r e d

Q t y A c c e p t e d

Q t y In s p e c t e d O K , Q t y R e j e c t e d



8.2.1.13 Class Name: Item Master File

The Material Master file contains information on materials used forproduction purposes. There can be preferred suppliers for a particularmaterial. Further attributes are still to be added to this class. All master fileswill need an electronic White board function.

Only some of the attributes are included for the case study.

8.2.1.13.1 Attribute Name: Item Code

Description: Unique code of the material item.Type: Item Code, Lower level of product structureValidations: Product StructureAttribute Triggers:Comments:

8.2.1.13.2 Attribute Name: Item Description

Description: Description of the material item code.Type: String, Mixed.

8.2.1.13.3 Attribute Name: Default Warehouse Code

Description: Default location of the material item.Type: Item code,Validations: warehouse location structure

8.2.1.13.4 Attribute Name: Standard Cost

Description: Standard cost of an item set by management on a periodicbasis.Type: Numeric, 2 Decimals, Precision 4Comments: All kilo & Rands readings should be to 4 decimals for Vaal and 4decimals places for EBP & AC Pipes.

8.2.1.13.5 Attribute Name: UOM

Description: Unit of MeasureType: Item codeValidations: UOM structureAttribute Triggers:Comments: Must define a UOM structure with the users. i.e. what differenttypes of UOM are there?

8.2.1.13.6 Attribute Name: TAX

Description: Define whether the item is taxable or notType: Boolean (Yes/No)

8.2.1.13.7 Attribute Name: Material Cost

Description: Displays the cost of the itemType: Numeric, 2 Decimals, Precision 4Validations: Cannot be negitive



8.2.1.13.8 Attribute Name: Last Cost Price

Description: Diplays the last cost price of the itemType: Numeric, 2 Decimals, Precision 4Comments: This can be used to check for exceptions. i.e. Used to comparethe last cost price of an item to the current cost.

8.2.1.13.9 Attribute Name: Inventory Unit

Description: The primary unit of measure for this item. This is the unit that isused for Inventory Valuation, Costing and the unit that all others arecompared to when defining conversions.Type: Item codeValidations: UOM Structure

8.2.1.13.10 Attribute Name: Forecast Method

Description:The Forecast Method is used to calculate Demand Forecast byItem.

The following Forecast Methods could be supported: - Moving Average - Exponential Smoothing - Previous Year's Calculation - Last Period's Demand

Type: item codeValidations: Forecast methods structure

8.2.1.13.11 Attribute Name: MRP - Lead time

Description: The time in working days it takes to procure an item.Type: Numeric, no decimalsComments: There are five woking days in one week. i.e. a lead time of 6days actually could end up being 8 calander days.

8.2.1.13.12 Attribute Name: MRP - Supplier Code

Description: Default supplier codeType: item codeValidations: Supplier Structure

8.2.1.13.13 Attribute Name: MRP - W/H

Description: Default W/H for the itemType: Item CodeValidations: W/H structure

8.2.1.14 Employee Master File

Master file of all employees. The attributes in this class are still to beexpanded. All master files will need a electronic White board function.



8.2.1.15 Class Name: Supplier Master file

Will need a supplier structure with groups. E.g. 2 levels. One with thesupplier name, next with the supplier branch.Will need a separate supplier master files...All master files will need a electronic White board function.

8.2.1.15.1 Attribute Name: Supplier Code

Description: Unique code of the supplier.Type: Item codeValidations: supplier structureAttribute Triggers: Manditory

8.2.1.15.2 Attribute Name: Supplier Name

Description: Name of the supplier.Type: String, Mixed.Attribute Triggers:Manditory

8.2.1.15.3 Attribute Name: Supplier Status

Description: A supplier can have different statuses limiting certain actions onthe supplierType: Item codeValidations: Supplier Status StructureAttribute Triggers: ManditoryComments: The various statuses that a supplier can go through can befound in the state diagram for Supplier Status.

8.2.1.15.4 Attribute Name: Settlement Discount

Description: A supplier may give a discount for settling an account oroutstanding amount.Type: numeric, percentageValidations: 0 -100 %Attribute Triggers:Manditory

8.2.1.15.5 Attribute Name: Standard Trade Discount

Description: Standard discount given for purchasing from a particularsupplierType: numeric, Percentage

8.2.1.15.6 Attribute Name: Chain Code

Description: The supplier chain codeType: might be an item code linked to a supplier structure.Comments: To link suppliers together. (This might not be necessarydepending on how the supplier structure is created.

8.2.1.15.7 Attribute Name: Banking Details

Attribute Triggers:ManditoryComments:· Banking Details (system to only cater for one bank account).



8.2.1.15.8 Attribute Name: E-mail Address

Description: E-mail addressType: String, mixedValidations: none

Nul l

Act ive

Orders Only

Payments On ly

No Payments/Orders

Archive

A Supplier can have a status of Active, Orders only, Payments Only or NoPayments/Orders

8.2.1.16 PO Requisition Header

Must be able to default to previous transaction.

8.2.1.17 PO Requisition Detail

There must be the ability to duplicate detail lines. There must be the abilityto split a detail line to cater for multiple deliveries. i.e. Have differentdeliveries for various dates.

8.2.2 Take-on Data Requirements

The client must provide the data in an ascii file format.

• Master file• Transactional• How far back is historical data required• Why• What about transactional data that relates to master file records that will

not be taken on.



8.2.2.1 Is the scope of the above process in line with the scope definitionper the Orientation phase?



Chapter 9 Introduction to the Design Documentfor Acme Manufacturing

9.1 Purpose of this documentThe purpose of this document is to describe the System “Design”requirements for the client. It encapsulates the current vision, strategicconsiderations, processes and activities used to manage and execute theday to day operation of the organisation but from a Rubico systemsperspective.

This document will form the basis for the explanation of processes andsystem requirements in a “Design” scenario.



Chapter 10 Design Interfaces

10.1 System Overview

Warehousing Accounts Payable

Accounts Receivable

Cash Book

General Ledger

MPS

MRPProduction

Order Processing

Planning & Distribution

Procurement

Demand Planning

Access

(from Third Party)

VIP

(from Third Party)

10.1.1 Warehousing

(Not Included in Sample Document)

10.1.2 Accounts Payable


10.1.3 Accounts Receivable


10.1.4 Cash Book


10.1.5 General Ledger


10.1.6 MPS




10.1.7 MRP


10.1.8 Production


10.1.9 Order Processing


10.1.10 Planning & Distribution


10.1.11 Procurement


10.1.12 Demand Planning


10.1.13 Third Party

10.1.13.1 Access

(Not Included in Sample Document)10.1.13.2 VIP




Chapter 11 Identify Business Processes

11.1 Map ProcessesBusiness Process Rubico

SystemRubicoProcess

Comments

Purchase OrderProcessing

RG PO None

Goods Receiving RG PO NoneOrder Monitoring RG PO NoneSupplier Selection RG PO NoneRequisition Processing RG PO None

11.2 System Diagram

Requisition Processing

Purchase Order Processing

Goods Receiving

Order Monitoring

Supplier Selection

The procurement function will consist of tasks starting at requisitioning andordering through to goods receiving. Quotes, vendor selection and contractswill not be included. For this Project import documentation has beenexcluded. Requisition processing and Supplier selection are notrequirements for Phase 1 of this project. This document contains bothanalysis and some design information. The Client does not ever see thedesign sequence diagrams or classes. Sequence diagrams seldom containattribute dependant operations, due to the fact that in the product Rubicocan dynamically change attributes.



Chapter 12 System Design

12.1 Rubico Structures

Product<<Structure>>

Major Reporting<<Structure Group>>

Sub Reporting<<Structure Group>>

Major Products<<Structure Group>>

Minor Products<<Structure Group>>

Item<<Structure Group>>

Supplier Structure<<Struc ture>>

Warehouse Structure<<Structure>>

Region<<Structure Group>>

Suppliers<<Structure Group>>

Company<<Structure Group>>

Profit Center<<Structure Group>>

Area<<Structure Group>>

Warehouses<<Structure Group>>

These Rubico Structures have already been described in the Analysisdocument.



12.2 Roles and Security

Buyer


Order Authoriser

(from Purchase Order Processing)Replenishment Planner


Stock Item only

Master Planner


Creditors Clerk


Receiving Clerk


QA Inspector


Inform of QA ResultsSupplier


Deliver Goods & Documentation

Storeman


Inform of QA ResultsInformDeliver Goods & Documentation

Accountant


Procurement Manager


Requestor




Person

(from Use Case View)



12.2.1 Roles and Securities Table

Process Role Design Object Bussiness Object CRUDDesign: Create a Purchase Order Buyer

Order AuthoriserPO_ORD_MANDYNAMIC_MESS

CRUDRU

Design: Create a Purchase order - HDR AttributeTriggers

Buyer PO_ORD_MAN CRUD

Design: Create a Stock PO - DETL Attribute Triggers Buyer PO_ORD_MAN CRUD

Design: Maintain Purchase Order BuyerMaster PlannerSupplier

PO_ORD_MANDYNAMIC_MESS

CRUDR

RDesign: Close Purchase Order Buyer PO_ORD_MAN CRUD

Design: Placing an Order BuyerSupplier

DYNAMIC_MESSPO_ORD_MAN

RR

Design: IM Maintenance ProcurementManager

MA_GMFMA_GMFMA_GMFMA_GMF

CRUD

Design: Supplier Maintenance AccountantProcurementManagerBuyer

MA_GMF CRUD

Design: Monitor GRV's Receiving ClerkBuyerMaster Planner

GRV_CAPGRV_Form

RCRU

RDesign: Receive Goods Receiving Clerk PO_LIST_GRV

PO_ORD_MANGRV_Form

R

Design: Update W/H Item & QC Receiving Clerk GRV_Form CRU



Design: Release Goods Receiving Clerk GRV_FormDYNAMIC_MESSPO_ORD_MAN

CRURR

Design: Monitor Purchase Order BuyerReplenishmentPlannerMaster Planner

PO_EnquiryPO_ORD_MAN

RRR

Design: Order Inquiry BuyerMaster Planner

PO_EnquiryPO_ORD_MAN

RR



12.3 Design Processes

12.3.1 Design: Purchase Order Processing

12.3.1.1 Class Diagram: Design: Purchase Order Processing

PO Status

Pu rchas e O rder

1

0..*

1

0..*PO Inquiry

<<Enquiry>>

P O _O RD_MA N

Store()Cancel()Update Header()Update Detail Line()Call Selected PO()

<<Visual>>

RGT009<<Core>>

MA_PO_NO_GEN

Prefix : InputSufix : InputBody : Input

<<Hidden>>

MAH200

<<Core>>

MAH100<<Core>>

MA _ITEM_ DE S C

ATTR_TKEY : InputTYPE : InputATTR_LIST : InputST_ITEM_CODE : OutputST_DES_DESC : OutputST_GROUP_CODE : OutputST_T_STGROUPH : OutputST_STDES_CODE : OutputMAP_L_USERLIST : OutputCHILD_ITEMS : Output

<<Hidden>>

MA_ALLOWED_ITEM

ATTR_TKEY : InputALLOWED_ST : InputLIST : InputMA_VALUE : OutputST_WORK_LIST : Output

<<Hidden>>

PO_Buyer2Supplier

<<Visual>>

STF062

<<Core>>

MA_CHECK_ITEM

LIST_A : InputLIST_B : InputRESULT : Output

<<Hidden>>

DYNAMIC_MESS<<Visual>>

MAH020

Stock Items


Transaction Type

Purchase Order Header

Purchase Order NoSupplier CodeSupplier DescriptionOrder TypeBuyerDateTime CreatedOrder Status : PO Status

Settlement DiscountAuthority NoW/H CodeW/H DescriptionVersion No 1

0..*

1

0..*

Purchase Order Detail

Special Inst ruc tio nsRequisiti on NoOrdering UOMQty RequiredQty ReceivedDate RequiredStandard CostSuppli er Pri ceT rade Dis co unt 1T rade Dis co unt 2Requested B yT otal Val ue (E xcl .Vat)L ine Item St atu s : PO Status

1

0 ..*

1

0 ..*

Split line Item


1

0..*

1

0..*

Non-Stock Item


MA_VERSION_CONT

ATTR _TKE Y : Input

<<Hidden>>MA_READ_CUBE

TKEY_LIST : InputATTR_LIST : InputCUBE_NAME : InputTYPE : InputMAP_L_USERLIST : Output

<<Hidden>>

CAPEX Item (Detail)

GL CodeDescriptionQuoted Reference No.

CAPEX Item (Header)

Ca pital V ote N o.

MA_DATE_CALC

DATE_1 : InputDATE_2 : InputVALUE : InputT YPE : InputRESULT : OutputRESULT_LIST : OutputT EST_RESULT : Output

<<Hidden>>

MA_CHECK_PREV

ATTR_TKEY : InputPROCESS_TKEY : InputVALUE : InputRESULT : Output

<<Hidden>>MA _S END _INFO

ATTR_TKE Y : InputT YPE : Inp utR E POR T : Inp ut

<<Hidden>>

PO_Enquiry<<Visual>>

RGL003<<Core>>

12.3.1.2 Use Case Diagram: Design: Purchase Order Processing

Replenishment Planner

Order Authoriser

Supplier


Buyer

Stock Item only

Place OrderReceives Order

Maintain Order

Informs of Exceptions

Inform

Monitor Order

Own Orders Only

Master Planner

Inform

Inform

All Orders

Order Inquiry

<<Uses>>



The objective of Purchase Order Processing is to capture and send ordersto a Supplier. (Sending Orders to the Supplier may be via fax, e-mail or amanual process.) The Buyer can maintain the order. This includes creatingand deleting orders. Once the Buyer has received the signed copy of theRequisition, the order can be placed with the Supplier. Once a purchaseorder number has been generated, it becomes the controlling number for allactivities relating to the order and delivery of goods.

The customers 'Authority No' is a manually generated number the Buyer willassign to a system PO. The Authority no. will default to the Order number.This Authority number can be overwritten with a 'Authority number' given tothe client. A check must be put in to confirm that the authority number isunique. Purchase Orders can be entered manually or created automaticallywhen the Replenishment Planner confirms the suggested orders from thematerial requirement planning run. The Replenishment Planner can playthe role of the Buyer for stock items only.

12.3.1.3 Use Case Breakdown

12.3.1.3.1 Use Case: Place Order

The order can be forwarded as: - a hardcopy. - a system generated fax - e-mail - a manual process



12.3.1.3.2 Analysis: Placing an Order

: Buyer : Purchase

Order : PO Report

: Supplier

1: Complete( )2: Create( )

3: Select Fax, E-mail or Print Order( )4: Inform( )

12.3.1.3.3 Design: Placing an Order

: Buyer : DYNAMIC

_MESS : MA_

SEND_INFO : Supplier

: PO Report : PO_ORD_MAN

1: Complete( )2: Ask: Fax, E-Mail, Print( )

3: Select Fax, E-Mail or Print( ) 4: Create( )

5: [Depending on Selection] Send Info( )

6: Inform( )



12.3.1.3.4 Use Case: Maintain Order

A Buyer creates an order from a signed requisition (Non-stock items) or byconfirming recommended orders. A Non Stock order should be linked to anrequisition document.

The date can be amended on a Purchase Order. Quantities can bechanged but only down, not up. If quantities need to be amended up, anadditional PO must be created for the increased amount.

12.3.1.3.5 Analysis: Create Purchase Order

: Buyer : Purchase Order Header

: Order Authoriser


1: Create( )

2: Create( )


Note: Depending on whether the Transaction type is for Stock of Non-Stock Items, the Detail Attribute will change. For Stock items, Item code, Supplier code and special instruction will be added. For Non-Stock items, the GL code, Type and Quote Ref. No. Attributes will be added. (See Class Diagram)

The buyer can create an order. An order is normally linked to one or manyrequisitions. Orders can be created without a requisition system (Phase 2issue) but will be listed as exceptions and printed. If the requisition has thecorrect authority check completed, then the Buyer will be able to Order theGoods as long as the order does not exceed the maximum stock levels.



12.3.1.3.6 Design: Create a Purchase Order

: Buyer : PO_

ORD_MAN : DYNAMIC

_MESS : Order Authoriser

: MA_SEND_INFO

: MA_VERSION_

1: Create( )

3: Store( )

7: Cancel( )

2: [If Qty > Max Stock] Display Error Message( )

8: Update Header( )

9: Update Detail Line( )


This Could be Via I-mail or via a Report

4: Ask: Fax, E-Mail, Print( )5: Send E-Mail, Fax or Print( )

6: Update Version no. if Modified( )

To See More information See Seq Diag. Placing an Order



12.3.1.3.7 Design: Create a Purchase order - HDR Attribute Triggers

: Buyer : PO_ORD_

MAN : Purchase Order Header

: MA_ITEM_DESC

: MA_CHECK_ITEM

: MA_CHECK_PREV

: MA_ALLOWED_ITEM

1: Create( )

2: Select Supplier( ) 3: Get Supplier Information( )

6: Select Status( )

4: Get Allowed Suppliers for Buyer( )

5: Check Allowed Suppliers against Buyers( )

7: Get Allowed Status for PO( )

8: Check if status selected is allowed( )

9: Enter Authority No.( )10: Check if Auhtority no. has been used( )

11: Select Warehouse( )12: Get Allowed Warehouses against Supplier( )

13: Check is Warehouse selected is allowed( )

12.3.1.3.8 Design: Create a Stock PO - DETL Attribute Triggers

: Buyer : PO_ORD_

MAN : Purchase Order Header


: MA_DATE_CALC


: MA_ALLOWED_

: MA_READ_CUBE

1: Create( )

2: Capture Header Attributes( )

3: Capture Item Code( )4: Get Allowed Status for PO( )

5: Get Supplier W/H Item Info( )

7: Do Lead time Calcs( )

6: Read( )



12.3.1.3.9 Analysis: Maintain Purchase Order

: Buyer : Purchase

Order : Supplier : Master Planner

1: Modify/Delete( )

2: Inform( )

Modify Date and quantity down only. 3: Inform of PO Changes( )

Depending on whether the amended order is accepted or declined, the supplier must be informed.

The Buyer can amend an existing order. If the buyer has the authorisationto amend the order, the supplier and the Master Planner must be informed.Quantities can be move down and Dates modified.

12.3.1.3.10 Design: Maintain Purchase Order

: Buyer : PO_

ORD_MAN : MA_CHECK

_PREV : Master Planner : Supplier

: MA_SEND_INFO

: DYNAMIC_MESS

1: View( )

2: Modify Quantity Received( )3: Check that Qty amended is < Previous( )

4: [If Qty > Max Stock] Display Error Message( )

5: [If PO is for a Stock Item] Inform of Changes( )

6: Ask: Fax, E-Mail, Print( )7: Send E-Mail, Fax or Print( )

8: Inform( )



12.3.1.3.11 Analysis: Close Purchase Order

: Buyer : Purchase

Order

1: Close( )

The Buyer will change the status manually to 'Completed' even if not all theline items have been received.



12.3.1.3.12 Design: Close Purchase Order

: Buyer : PO_

ORD_MAN

1: Status Change( )

12.3.1.3.13 Use Case: Monitor Order

Depending on the business rules, various employees can have the ability toview or Monitor their relevant orders (On-line or via a hard copy) The Buyer,creditors clerk and the master planner should be allowed to view the orders.This Report, the "PO Report", can be found in the 'Reporting Requirements'section of this document.



12.3.1.3.14 Analysis: Monitor Order

: Buyer : Purchase

Order : Master Planner : Replenishment

Planner

1: View( )

2: View( )

3: View( )

The Buyer can monitor an order online or via a hardcopy. A requestor canmonitor the order via the requisition status and quantity ordered. The Storekeeper might also need to view relevant orders.(e.g. Warehouse)



12.3.1.3.15 Design: Monitor Purchase Order

: Buyer : Replenishment Planner

: Master Planner : PO_Enquiry

: PO_ORD_MAN

1: Find specific PO( )



4: Call Selected PO( )

12.3.1.3.16 Use Case: Order Inquiry

12.3.1.3.17 Analysis: Inquire on Orders

: Buyer : Master Planner : PO Inquiry : Purchase

Order





12.3.1.3.18 Design: Order Inquiry

: Buyer : Master Planner : PO_Enquiry : PO_ORD_

MAN





12.3.2 Design: Goods Receiving

12.3.2.1 Class Diagram: Design: Goods Receiving

G R V I n q u i r y< < E n q u i r y > >

G R N D e t a i l

I t e m C o d eI t e m D e s c r i p t i o nQ t y o n G R NQ t y R e t u r n e dU n i t N e t P r i c eG R N R e a s o n C o d eR e a s o n D e s c r i p t i o nS u p p l i e r C r e d i t N o t eS u p p l i e r V a l u e

G R N H e a d e r

G R N N oS u p p l i e r C o d eS u p p l i e r D e s c r i p t i o nS u p p l i e r s I n v o i c e / D e l i v e r y N o t e G R V R e f . N oP u r c h a s e O r d e r N o .A u t h o r i t y N o .D a t e R e t u r n e d

G R N I n q u i r y< < E n q u i r y > >

G R V _ F o r m< < V i s u a l > >

R G T 0 0 9( f r o m D e s i g n : P u r c h a s e O r d e r P r o c e s s i n g )

< < C o r e > >

P O _ O R D _ M A N( f r o m D e s i g n : P u r c h a s e O r d e r P r o c e s s i n g )

< < V i s u a l > >

P O _ L I S T _ G R V< < V i s u a l > >

R G L 0 0 4< < C o r e > >

G R V _ C A P< < V i s u a l > >

R G L 0 0 4< < C o r e > >

S t o c k I t e m s

I t e m C o d eI t e m D e s c r i p t i o n

( f r o m D e s i g n : P u r c h a s e O r d e r P r o c e s s i n g )

N o n - S t o c k I t e m

E x p e n c e C o d eC o s t C e n t e rD e s c r i p t i o n o f P r o d u c tQ u o t e d R e f e r e n c e N o .

( f r o m D e s i g n : P u r c h a s e O r d e r P r o c e s s i n g )C A P E X I t e m ( D e t a i l )

G L C o d eD e s c r i p t i o nQ u o t e d R e f e r e n c e N o .

( f r o m D e s i g n : P u r c h a s e O r d e r P r o c e s s i n g )

G R A

G R A N o .Q t y R e t u r n e dR e a s o n

G R V D e t a i l

U O MQ t y O r d e r e dQ t y R e c e i v e d t o D a t eQ t y o n D e l i v e r y N o t eQ t y C o u n t e dQ t y I n s p e c t e d O KQ t y R e j e c t e dQ t y A c c e p t e dU n i t N e t P r i c eQ t y O n G R AS u p p l i e r I n v o i c e N o .S u p p l i e r I n v o i c e V a l u eG R V T o t a l ( E x c l . V a t )

G R V H e a d e r

G R V N oS u p p l i e r C o d eS u p p l i e r D e s c r i p t i o n G R V S t a t u sA u t h o r i t y N oP u r c h a s e O r d e r N o .S u p p l i e r s I n v o i c e / D e l i v e r y N o t eD a t e R e c e i v e d

T r a n s a c t i o n T y p e( f r o m D e s i g n : P u r c h a s e O r d e r P r o c e s s i n g )

G R V _ F o r m _ H i d d e n< < H i d d e n > >

M A H 2 0 0( f r o m D e s i g n : P u r c h a s e O r d e r P r o c e s s i n g )

< < C o r e > >

P O 2 G R V S e l e c t i o n

G R V S t a t u s

G o o d s R e t u r n e d N o t e

G o o d s R e c e i v e d V o u c h e r

1

0 . . *

1

0 . . *

0 . . *

1

0 . . *

1



12.3.2.2 Use Case Diagram: Design: Goods Receiving

Requestor


Buyer


Master Planner


Creditors Clerk

Accept Goods

Informed if Non Stock

Notified of Exceptions

Monitor DeliveriesOwn

All

Capture GRA Details

Copy to

GRN Generated

Inform

Receive Goods

Receiving Clerk

If goods are returned before GRV'd

StoremanQA Inspector

QA Required

Inform of QA Results

Inform

The Receiving Clerk along with the Buyer can monitor for expecteddeliveries. Once the goods have been received a Goods Received Voucher(GRV) is generated on the system. From there the goods can be released tostock or go for a quality inspection.

Once goods have been released to stock, only the Storeman and the QAinspector can return goods. For this a Goods Returned Note (GRN) must begenerated by the system.

The Buyer should always be notified of exceptions.

When non-stock items are received, the Requestor must be informed. AGRA (Goods Returned Advice) is manually prepared when goods arereceived but returned before a GRV has been created.

Two scenarios exist when returning goods- Firstly, return goods on receipt(GRA) and secondly, return goods (GRN) after they have been GRV'd. TheGRA (Goods Returned Advice) is to be a manual process. No stock writebacks or financial entry write backs are done. The GRN will be a systemfunction and will also write back stock and create the appropriate financialentries.

When the Storeman creates a GRN the Creditors Clerk must be informed.The user must have the ability to print a GRV or a GRN




12.3.2.3.1 Use Case: Receive Goods

A Goods Received Voucher (GRV) needs to be generated for the receipt ofevery Stock and Non-stock items. i.e. a GRV is created for all payments.

It is important to note that an order can have many deliveries, but that aGRV can only belong to one order.

Receiving clerk can over receive. The Clerk must be informed (prompted) ofthe excess and decide whether to receive the goods or not. The PO detailline must be closed automatically when the Qty accepted is equal to the Qtyordered.

12.3.2.3.2 Analysis: Receive Goods

: Supplier : Receiving Clerk : Goods Received

Voucher : Item

Master File : Warehouse

Item : QA Inspector : Requestor

: Purchase Order

1: Deliver Goods( )2: Record Delivery( )

3: Validate( )

4: Status Change( )

The status is changed to Received. (See State Diagram)

5: Check for QA Requirements( )

6: [If No QA Required] Release to Stock( )

9: Capture QA Results & Change Status( )

7: [If QA required] Forward( )

Depending on the business rules, the delivered goods may need a QA and must be forwarded for a QA inspection. If no QA is required, the goods are release directly to stock.

Depending on the QA requirements, the goods will be marked as 'Received' or 'QA Waiting'.

If the Goods Pass QA, then the goods can be released to stock. The status on the GRV changed from 'Open' to 'QA Waiting'. Only when the Receiving Clerk releases the goods to stock will the status of the GRV change from 'QA Waiting' to 'Closed' (See State Diagram)

11: Informed of Received Goods( )

8: Informed of QA Results( )

10: [If QA Passed] Release to Stock( )

Record Counted Qty

Validate the goods before a GRV is recorded. If incorrect Generate a manual GRA

Goods are delivered to the Receiving Clerk from the Supplier. A GRV isgenerated (The GRV Status is now "OPEN"). When the order no iscaptured, the status of the PO will change from 'Ordered' to 'Received' TheGRV provides proof that the listed quantities of goods have been delivered.Depending on the goods delivered, a QC inspection may be necessarybefore the goods are released to stock (A status of 'QC Waiting' is allocatedto the GRV). If no QC is required, the Receiving Clerk releases the goodsdirectly to stock. The status of the PO line item will then change from'Received' to 'Completed' if the Qty Accepted >= Qty Ordered. A GRV detailline must be linked to a PO detail line.



If a QC is completed the status will change from 'QC Waiting' to 'CLOSED'once the goods have been received. This is when the Requestor is informedof the availability of the goods. If the goods received were for a suggestedorders, then the Replenishment Planner is informed.

Report needed at month end or prior to stock take to inform Storeman ofstock that have been received but not yet been GRVed. System must checkthat quantity received is not more than the quantity ordered. The Systemmust not stop the over receipt of goods - the order line item mustautomatically be closed as complete for over supplies. An exception reportwill highlight all over supplies.

12.3.2.3.3 Design: Receive Goods

: Receiving Clerk : PO_

LIST_GRV : PO_

ORD_MAN : GRV_Form

: MA_READ_CUBE


1: Select PO to GRV( )2: Call Selected PO( )

3: Create For Selected PO Detail Lines( )

4: Capture( )

7: Update Qty Received( )

5: Get QC Info( )6: Read( )

8: Status Change( )

9: Flag for Interface( )



12.3.2.3.4 Design: Update W/H Item & QC

: Receiving Clerk : GRV_Form

: MA_READ_CUBE

: Warehouse Item

1: Capture( )2: Update Availibility( )

3: Update( )

12.3.2.3.5 Use Case: Monitor Deliveries

Depending on the business rules, the Buyer and the Receiving Clerk will beable to view expected deliveries online or on a hardcopy. Need the ability tolist outstanding PO's by supplier, due date, item etc. (See the availablefilters in PO 'Reporting Requirements' within this document.) This will be anon-line inquiry and reporting function.

12.3.2.3.6 Analysis: Monitor Goods Received

: Receiving Clerk : Buyer : Master Planner : PO 2 GRV

Selection : Goods Received

1: View( )

2: View( )

3: View( )




12.3.2.3.7 Design: Monitor GRV's

: Receiving Clerk : Buyer : Master Planner : GRV_CAP

: GRV_Form

1: Select GRV( )

2: Select GRV( )

3: Select GRV( )


12.3.2.3.8 Analysis: Return Goods To Supplier

: Receiving Clerk :

GRA : Creditors Clerk : Supplier

1: Create( )

2: Copy of GRA( )

3: Inform of Returned Goods( )This is a Manual Process an will not be included in the design.

The Receiving Clerk and the QA Inspector both have the authority torequest the return of goods for various reasons. Goods are returned againsta GRV detail line. If the supplier delivers defective goods, the ReceivingClerk will not accept the goods delivered and return them to the supplier.This means that some or all of the goods will not be recorded on the GRV.In this instance, a GRA details (Goods Returned Advice) must be captured.



12.3.2.3.9 Use Case: Accept Goods

When the goods/services are delivered, the line item status on the GRV ischanged to 'Received'. From there it can undergo a quality assurance checkand/or be accepted to stock. This is were the GRV is printed.

12.3.2.3.10 Analysis: Release Goods

: Warehouse

: Receiving Clerk : Goods Received

Voucher

The Buyer is informed of the goods received. This includes exceptions. E.g. quantities that need to be re-ordered.

1: Record Accepted Qty( )2: [If GRV for Stock] Update Stock( )

6: Print( )

Creditors : GL

: Purchase Order

3: Update

4: Update Qty Amended( )

5: [If final GRV] PO closed( )

Prompt if Qty is still outstanding.

Prompt:" Is this the Last line item entry?" This may related to a Role.

The Receiving Clerk releases goods. There are two types of goods namely:Stock Items and Non stock items. The Buyer must have the ability to re-open PO's only when there is still an outstanding Qty on the PO. Once thetotal quantity accepted equals or exceeds the total quantity ordered thesystem must close the order line item as complete. The system must allowrelevant users to manually close the order line item as being completed,even if the quantity ordered does not equal the quantity accepted for thatorder line.



12.3.2.3.11 Design: Release Goods

: Receiving Clerk : GRV_Form

: DYNAMIC_MESS

: Warehouse Item

: PO_ORD_MAN

1: Record Delivery( )2: Check if Last Line Item Entry( )

3: [If Stock] Update( )

4: Update Qty Received( )

12.3.2.3.12 Use Case: GRN Generated

Only the Storeman can create a GRN (Goods Received Note for itemsreturned.) GRNs will be covered in detail in the Warehousing module -Inventory Management.

12.3.3 Design: Order Monitoring

12.3.3.1 Use Case Diagram: Design: Order Monitoring

Order Authoriser


Requestor


Monitor Requisitions(from Requisition Processing)

Only Own Requisitions

Monitor Order(from Purchase Order Processing)

Receiving Clerk


Buyer

(from Purchase Order Processi ng)

Relevant

Own Orders Only

Master Planner


All Orders

Monitor Deliveries(from Goods Receiving)

Own

All



All the monitoring reports required for this section can be found in 'ReportingRequirements' within this document.


12.3.4 Design: Supplier Selection

12.3.4.1 Class Diagram: Design: Supplier Selection

Cost Centre

Budget

Budget Amount

Employee Master File

Employee No. Employee NameEmployee Surname Employee ID No.

GL Account

1 0..*1 0..*

Employee GL Accounts

10..* 10..*

1

0..*

1

0..*

Supplier Status

Supplier Master FileSupplier CodeSupplier NameSupplier StatusSettlement Discount %Payment Terms (Days)Street No.Street NameSuburbCityPhysical Postal CodeP.O. Box No.SuburbPostal CodeBanking DetailsE-mail AddressCreditor Contact PersonMD NameMD NumberPhone NumberFax NoStatement Delivery MethodMethod of PaymentSupplier Rating Date CreatedTrade Discount 1 Trade Discount 2

1

0..*

1

0..*

Supplier W/H Item Matrix

Supplier CodeItem CodeW/H CodeSupplier PriceDate OnDate OffMax Stock LevelMinimum Stock LevelMultiplesType (MRP or ROP)Record Qty on D/Note?Record Qty Counted?Record Qty Inspected OK?Record Qty Rejected?Record Qty Accepted?EOQSupplier Lead TimeOrdering UOMConversion Factor

1

1..*

1

1..*

Warehouse Item

W/H CodeItem CodeInventory on HoldInventory on OrderSupplier CodeLead timeInventory on HandMinimum Order QtyMaximum Order QtyRe-order Point

1..*

1

1..*

1

WarehouseWarehouse CodeWarehouse Description

0..1

1..*

0..1

1..*

Item Master FileItem CodeItem DescriptionStandard CostStocking UOM TAXMaterial CostLast Cost PriceInventory UnitForecast MethodD/Note inquiryMRP - Lead timeMRP - Supplier Code MRP - W/H

1

0..*

1

0..*11..*

11..*

0..1

1..*

0..1

1..*

Buyer RoleWarehouseProduct Group

1 0..*1 0..*

1

0..*

1

0..*

Supplier Inquiry<<Enquiry>>

Cardex Report<<Enquiry>>

Item Inquiry<<Enquiry>>

Stock Account

MA_GMF<<Visual>>

RGF004<<Core>>



12.3.4.2 Use Case Diagram: Design: Supplier Selection

Maintain Master Files

Accountant Supplier

Procurement Manager

Buyer


Maintain Supplier Master File

View

View

The Procurement Manager has the ability to maintain the Item master File,linking a particular stock item to a suitable supplier. Supplier Selection is apurely manual process for phase 1 of this project, and no systemfunctionality will be developed to cater for this process. All relevant parties(Buyer, Creditors Clerk) will fill in a form containing supplier details. Once ithas been completed and authorised, it is captured into the system by theAccountant. Supplier Details will be listed and signed off by the Supplier.


12.3.4.3.1 Use Case: Maintain Supplier Master File

Data pertaining to each active supplier including evaluations and pastpurchases need to be maintained.



12.3.4.3.2 Analysis: Supplier Master File Maintenance

: Accountant : Supplier Master File


: Buyer

1: Create( )

2: Read( )

3: Update( )

4: Delete( )

5: Read( )

Need a structure to link/chain suppliers into a hierarchy. This to be only 2 levels, one the parent company, the 2nd level all the branches of that supplier. (E.g. Plascon National (top level), each Plascon branch/supplier nationally on the lower level.) This is purely for reporting requirements only. The User must be able to maintain the Supplier Structure.

6: Read( )

Depending on the Business rules, the Accountant will have the authority tocreate, read, update and delete information on a supplier master. The buyerwill only have the ability to view the Supplier Master file.



12.3.4.3.3 Design: Supplier Maintenance

: Accountant : Procurement Manager

Supplier Master : MA_GMF

: Buyer

1: Maintain( )

This Includes Creating, reading updating and deleting

2: Read( )

3: Read( )

Read rights Only

12.3.4.3.4 Use Case: Maintain Master Files

In this particular instance a material must be linked to a preferred supplierby W/H. Material Items must have a list of up to 3 preferred suppliers. Ifpreferred supplier 1 is filled in, this will then serve also as the defaultsupplier. System must keep the last three purchase prices per item per W/Hwith the purchase date.



12.3.4.3.5 Analysis: Master File Maintenance

: Item


: Supplier Master File

1: Read( )



: Warehouse Item

3: Maintain( )

4: Maintain( )

The Procurement Manager can only maintain the Item master File with thedefault supplier of that particular stock item. The Procurement manager alsohas the ability to maintain item related master File such as the Supplier W/HItem Matrix and the W/H Item.

12.3.4.3.6 Design: IM Maintenance


Supplier Master : MA_GMF

Item Master : MA_GMF

Supplier W/H Item : MA_GMF

Warehouse Item : MA_GMF

: MA_ITEM_DESC

1: Read( )2: [If Stock Item] Get Item Info( )

3: Read( )

4: Maintain( )

5: Maintain( )



12.3.5 Design: Requisition Processing

12.3.5.1 Class Diagram: Design: Requisition Processing

PO Requisition

Requisition Status

0..*

1

0..*

1

Requisition Inquiry<<Enquiry>>

Stock Items



Non-Stock Item



PO Requisition Header

Request NoRequisition TypeCreated ByRequested ByAuthorised ByDateTime CreatedRequest Status

Transaction Type(from Design: Purchase Order Processing)

1

0..*

1

0..*

PO Requisition Detail

WarehouseSupplier CodeUOMQty RequiredDue DatePriceTrade Discount 1 Trade Discount 2Line Status

1..*

1

1..*

1

1

0..*

1

0..*

Split line Item



12.3.5.2 Use Case Diagram: Design: Requisition Processing


Requestor

Authority Checking

Declined

Monitor Requisitions

Only Own Requisitions Maintain Requisition

Inform of Unauthorised Req.

Buyer

(from Purchase Order Processing)Confirmed

Relevant

Get Quote

The purchase requisitioning task is a request to the purchasing departmentto procure a certain quantity of material or service on or by a certain date. Inthe diagram above, the Buyer can play the role of a Requestor. TheRequestor will create a requisition in the 'Maintain Requisition' use case. If



the requisition does not contain a quoted price, then it must go to the Buyerbefore it can get authorisation. If the Requestor does not have the correctauthorisation for the requisition, then the Requisition Authorisor must benotified of the request. The process does not prevent the requestor fromcompleting the transaction, but only warns the requestor of the insufficientauthority. The Requestor can also monitor all relevant requisitions.


12.3.5.3.1 Use Case: Maintain Requisition

The Requestor of the requisition has the ability to maintain (C.R.U.D) theirown requisitions. Should a requisition require prices, the Buyer is notified toobtain quotes for the relevant goods/services. All requisitions mustfurthermore be authorised by the Requisition Authorisor before therequisitions can be sent to the Buyer.

12.3.5.3.2 Analysis: Create Requisition

: Requestor : Requisition Authorisor

: Buyer : Employee Master File

: Item Master File

: PO Requisition

1: Select Requisition Type( )

2: Capture Requisition Details( )

7: Inform( )


4: Retrieve Default W/H( )

5: Retrieve Item Cost( )

6: [If Non-Stock Item] Check validity of GL code( )

If the requisition is for an existing stock item, then the default supplier must be allocated to the requisition item.

The Role of the Requestor can be played by the Buyer and the Replenishment Planner

If the Item is a stock item the amount is allocated against the stock account for the material.

Summary and Detail report per day (Trevor Van Rooyen to investigate) Check for over ordering & authorities. This is the Requisition Report.

Display Message if level is exceeded. The Buyer can still continue or abort.

8: Modify/Delete( )

11: [If Authority Insufficient ] Get Authorisation( )

10: Informed( )


A requisition can be created for four different reasons namely: To CaptureReplenishment Requisition; Capture direct Services; CAPEX and theCapture of Non-Stock Item Requisition. For Acme Manufacturing, theserequisition types will fall into two main categories namely: Stock Items andNon-Stock Items. Non-Stock items are also known as Direct Items.

Replenishment type requisition: (Stock Item) The request for a requisitioncould be Manual or Automatic. This process requires Item Details to be



captured. The System will validate that the item code exists. A date requiredwill default to the lead time of the material which can be amended. Thestock availability will show this as being due-in. Costing is based onstandard cost kept on the Item master file. If a default Warehouse for thereplenishment material exists this will automatically be allocated on therequisition. This default Warehouse must be maintained for all materials. AGL Stock account must be kept per product group. Posting to GL accountsneed to be done in a logical grouping. (An inquiry report per order no. &some logical grouping will be required for audit trails. This Report, the"Requisition Report", Can be found in the 'Reporting Requirements' sectionof this document.) If a default Supplier for the material exists in the system,they can be found automatically and the purchase requisition can beallocated to the correct supplier. If a Supplier is not known, the requisitioncan be selected for the quoting procedure when the buyer receives therequisition. Stock items do not have budgets, rather stock levels.Replenishment of stock items must be checked against stock levelswhereas all other types of requisition are checked against budgets.

Direct Services type requisition: (Non-Stock Items) would be expenses thatneed to be incurred i.e. not item codes, a receiving process will take place.An expense code needs to be recorded and must be a valid GL accountwith a budget value against it.(The budget value could be zero.) The valueaffecting the GL will be based on the value of the service entered.(Excl. Vat)

A Capital Expenditure requisition (Non-Stock Item): would be for capitalexpenses that need to be incurred. A work in process account needs to berecorded and must be a valid GL account with a budget. Once the asset istransferred to fixed assets, only then will the asset be recorded and the workin process account reduced. The value affecting the GL will be based on thevalue of the asset entered.(Excl. Vat).

A non-stock type requisition:(Non-Stock Item) would be items that do notget recorded in the stock master but needs to be received (GRVed). A validGL expense code and budget must exist. The value affecting the GL will bebased on the value of the item received.(Excl. Vat)

Validations to stop a requisition if budget/stock levels are exceeded mustNOT be built in - the transaction must be allowed to continue. (System toonly warn user that maximum stock level or budget is being exceeded.)Instead an exception report to show where stock levels/Budgets wereexceeded is required at end of day ( - part of Warehousing). This Report,the "Requisition Exception Report", can be found in the 'ReportingRequirements' section of this document The system must have a matrix(requestor, Authorisor, stock item, cost centre etc) of authority levels built inthat is checked at time of capturing - the system must NOT stop the processbut allow the user to continue or abort the transaction.

Purchase requisitions can be approved for ordering based on certaincompany policies. These policies must specify who must approve therequisitions and in what order/sequence. The authorising of requisitions canbe based on the type of requisition, value and / or grouping of materialsrequired.



12.3.5.3.3 Analysis: Maintain Requisition

: Requestor : PO


Authorisor

1: Modify/Delete( )

2: Modify/Delete( )

The requestor can only modify or delete their own requisitions. A requisitioncan only be deleted if there are no orders generated against it. If theRequestor submits a requisition without a quote, the buyer must get thequotes for the relevant items and then maintain the requisition with theupdated values.

12.3.5.3.4 Use Case: Authority Checking

The Requisition Authorisor has the ability to authorise or decline POrequisitions.(For Non-Stock Items only) If it is authorised the Buyer isnotified. If it is declined the Requestor and the Buyer are notified. Shouldthe Requisition Authorisor not have sufficient levels of authorisation, aprocess of escalation is initiated until a Requisition Authorisor with theappropriate authority level is found.



12.3.5.3.5 Analysis: Authorise Requisition

: Requisition Authorisor

: PO Requisition

: Buyer : Requestor : Employee Master File

: Budget

1: View( )

2: View( )

If the Authority level is insufficient then the requisition is referred to the next level of authority.

Depending on the decision made by the Requisition Authorisor, the requisition can be approved, declined or modified.

7: Inform( )

8: [If Declined] Notify( )

9: [If Requisition Modified] Notify of Changes( )


4: [If Authority Insufficient] Determine Next Level of Authority( )

5: Inform( )

6: Status Change( )

In this sequence diagram, the Requisition Authorisor has already read theexception report for unauthorised Requisitions. If a requisition was createdand the user did not have a sufficient authority level, the requisition must beforwarded to the relevant user to authorise. Once the correct level ofauthority has been obtained, then the Authorisor must inform the buyer ofthe out come of the decision. If the requisition is refused or modified, theRequestor and the Buyer must be notified. Purchase requisitions can beapproved for ordering based on certain company policies. These policiesmust specify who must authorise the requisitions and in what order. Thereleasing of requisitions can be based on the type of requisition, value and /or grouping of materials required.

12.3.5.3.6 Use Case: Monitor Requisitions

Depending on the business rules, various employees can have the ability toview or Monitor their relevant requisitions (On-line or via a hard copy)



12.3.5.3.7 Analysis: Monitor Requisitions

: Requestor : Buyer : PO


Authorisor

1: View( )

2: View( )

3: View( )

The Requestor, Buyer and Replenishment planner all have the ability toview their relevant requisitions. This may be via an online function of via ahardcopy. This is a phase two requirement, but the report "RequisitionReport", can be found in the 'Reporting Requirements' section of thisdocument. The viewing of Requisitions must be limited to the role of theuser. Note this process is for Non-Stock Items only.



Chapter 13 Approved

Process Date Process Specialist VersionPurchase OrderProcessingGoods ReceivingOrder MonitoringSupplier SelectionRequisition Processing



Chapter 14 Introduction to the Rubico ObjectDocumentation for AcmeManufacturing

14.1 Purpose of this documentThe purpose of this document is to describe the “To Be” business operationof the client in a design format for the design consultant.

This document will form the basis for the configuration the processes andsystem requirements in the “to be” scenario for Procurement.

14.2 Definitions, acronyms and abbreviationsAs per the To Be Document.

14.3 ReferencesThis document was generated from the Procurement model for AcmeManufacturing.



Chapter 15 Visual Object Documentation

15.1 Visual Alias Documentation:PO_ORD_MAN

15.1.1 Business Class: Purchase Order

Both the Header and Detail must have a notes field. Amended PO must behighlighted if the PO is changed.

Note: Depending on whether the Transaction type is for Stock of Non-StockItems, the Detail Attribute will change. For Stock items, Item code, Suppliercode and special instruction will be added. For Non-Stock items, the GLcode, Type and Quote Ref. No. Attributes will be added.

Once the PO has been Printed, the status must be changed to Printed....See new Printing status diagram.

15.1.1.1 Purchase Order Header

Attribute Name Attribute DocumentationPurchase Order No Description: This will be a system generated no. for uniquely identifing a

PO.Syntax: No EditType: Alpha Numeric, Must be prefixed with a Factory and Deliveryaddress. Suffix with Stock or non StockValidations: Prefix must be checked against a factory and a delivery



address.Attribute Triggers: NoneComments: Auto generate at time of creation of the PO usingMA_PO_NO_GEN.

Supplier Code Description: Unique Code for the supplierSyntax: EditableType: Item Code.Validations: Supplier structureAttribute Triggers: Leave field Trigger: MA_ITEM_DESC to get supplierdetails. Use MA_ITEM_DESC to get Supplier Description. OR AMTrules: DIPLAY SUPPLIER NAME. Use amount rules to get DateTimeCreated information.Comments: Once a Supplier Code is selected, the Supplier descriptionmust be populated with the related description.

Supplier Description Description: Displays the name of the supplier selectedSyntax: No-editType: Sting, MixedValidations: Dependant on the Supplier Code SelectedAttribute Triggers: None.Comments:

Order Type Description: The type of orderSyntax: No-editType: Drop Down List BoxValidations: NoneAttribute Triggers: None.Comments: There are two Transaction types namely: Stock and Non-Stock Items

Buyer Description: Role of the user who created the Purchase Order.Syntax: EditableType: item codeValidations: User Structure. Must check allowed suppliers for a buyer.Attribute Triggers: Field Get Focus: Use MA_Allowed_Item to get allowedBuyers for the Supplier Leave Field Trigger: Check if the Buyer entered is thesame as the allowed Buyers- Use MA_CHECK_LIST If a Message is necessary, then use DYNAMIC_MESSComments: Buyers Matrix against a supplier

DateTime Created Description: The date and time that the Purchase Order was created.Syntax: No EditType: DateValidations: NoneAttribute Triggers: NoneComments: Will get populated when the supplier is chosen.

Order Status Description: The current status of the Purchase Order.Syntax: EditableType: Item Code (Status Structure).Validations: State transitions as outlined in the State transition diagramAttribute Triggers: None.Comments: To see the various transaction types and there statetransition see PO Status.



Settlement Discount Description: This is the discount given to the client when he/she settlesthere accountType: NumericValidations: checked against the Supplier Master for the SupplierChosen.Attribute Triggers: None. Will get populated when the Supplier is chosenComments: Defaults to settlement discount on supplier master. Can beoverridden. Need a report to compare all that have been overridden

Authority No Description: This is a manual number given to a specific POSyntax: EditableType: Alpha NumericValidations: Check for duplicate order authority numbers.Attribute Triggers: Leave field Trigger to check for duplicate authoritynumbers. UseComments: This must be a manual numbering system

W/H Code Description: The warehouse where the item is to be stored.Type: Item CodeValidations: W/H Location StructureAttribute Triggers: Mandatory. (If Transaction type is Non-Stock Item,then the W/H Must Default to Consumable Stores) When the Transaction Type is Selected, the W/H Code& Description will be Populated if the Transaction Type is Non-Stock.Comments: Each material item could have a default warehouse depictingwhere the item is to be stored. This can be altered at the time that thePurchase Order is captured. If it is a non-stock item it must default toconsumable W/H (Main store W/H)

W/H Description Description: Explanation of the W?H Code ChosenSyntax: No-EditType: StingValidations: NoneAttribute Triggers: NoneComments: Must be populated

Version No Description: Every time the date or quantity is changed on the PO, thisnumber must be incrementedSyntax: non- edit.Type: numericValidations: This Starts at zeroAttribute Triggers: This does not have an attribute trigger, but will getupdated on the UPDATE Events.Comments: Starts at ZERO.

15.1.1.2 Purchase Order Detail

Attribute Name Attribute DocumentationSpecial InstructionsRequisition No Description: Request no. per line item. (i.e. Requisition no.)

Type: Numeric.Validations: None. Requisitions are a manual Process. This is areference no to the manual authorisationAttribute Triggers: None.Comments: Must duplicate this in the detail lines (Can beoverwritten).There will be no inquiry facility by requisition number.(Phase



1)Ordering UOM Description: Code that reflects the measurement that the item is

measured in (i.e. Unit of Measure).Syntax: EditableType: Item CodeValidations: Unit of Measure structureAttribute Triggers: None. This information will be obtained when the Itemis selected from the Supplier/ W/H/ Item MatrixComments: None

Qty Required Description: Total number of items to be purchased.Syntax: EditableType: Numeric.Validations: May not exceed the Maximum stock level. This value will bechecked against the Maximum stock level in the Supplier| W/H| ItemMaster.Attribute Triggers: Leave field to check value. Use DYNAMIC_MESS tonotify user of excess ordering.Comments: None.

Qty Received Description: Total number of items received on GRVSyntax: No-Edit fieldType: Numeric.Validations: Must balance against the number of GRV's received for aPO detail item.Attribute Triggers: NoneComments: This value will be obtained from the GRV

Date Required Description: Date on which the item being purchased is required.Syntax: EditableType: DateValidations: The Date can't be in the pastAttribute Triggers: Populated with the current date PLUS the lead-time ofthe ITEM chosen. This information comes from the Supplier| W/H| ItemMaster. Use MA_DATE_CHECK to see if the date chosen is in the past.Comments: Need to be able to split the order.

Standard Cost Description: This is the National Standard Cost for the Chosen item.Syntax: No EditType: NumericValidations: NoneAttribute Triggers: NoneComments: This comes from the item master (standard cost)...convert toOrdering UOM for the PO.

Supplier Price Description: Price that was quoted for the item to be purchased. It willfirst be populated with the Standard Cost, but can be overwritten.Syntax: EditableType: Numeric. 4 decimals.Validations: NoneAttribute Triggers: NoneComments: This price is the standard price and can be overridden. Needa report to compare the price to the standard cost on the item masterfile.

Trade Discount 1 Description: Percentage discount that is to be allowed for the item to bepurchased. This will be populated with values from the Supplier| W/H|



Item Master.Syntax: EditableType: Numeric. 2 decimals.Validations: Between 0.00 and 100.00Attribute Triggers: None.Comments: This discount will vary from supplier to supplier as well asfrom material item to material item. Only applies to Raw materials,trading goods and selected stock items. This may be over written at timeof entry. A report is required to compare the Trade discount to thestandard trade discounts on the supplier material master file

Can be modifiedTrade Discount 2 Description: Additional percentage discount that is to be allowed for the

item to be purchased. This will be populated with values from theSupplier| W/H| Item Master.Syntax: EditableType: Numeric. 2 decimals.Validations: Between 0.00 and 100.00Attribute Triggers: NoneComments: Additional discount after calculation of net price after TradeDiscount 1. Can Be modified

Requested By Description: Name of the user who requested the material item.Syntax: EditableType: Item CodeValidations: User StructureAttribute Triggers: NoneComments: None

Total Value(Excl.Vat)

Description: This is the Supplier Price x thw Qty required.Syntax: No EditType: Numeric. 4 decimalsValidations: None.Attribute Triggers: NoneComments: None

Line Item Status Description: The current status of the Purchase Order line item.Syntax: EditableType: Item Code.Validations: Status Structure and State transition diagram specs.Attribute Triggers: NoneComments: Goes to completed when the Qty ordered >= Qty Received.After this it cannot be amended.



15.2 Visual Alias Documentation:PO_Buyer2Supplier

15.3 Visual Alias Documentation:DYNAMIC_MESSUsed to display dynamic messages within Rubico to the user.

15.4 Visual Alias Documentation:PO_Enquiry(Excluded from this sample document – WIP)

15.4.1 Business Class: PO Inquiry

Must be able to view per item & view detail lines per order.



Chapter 16 Visual Alias Documentation:GRV_Form

16.1.1 Business Class: Goods Received Voucher

If the Qty on the delivery note varies from the Qty GRN then a GRN must begenerated (Pop-up)

16.1.1.1 GRV Header

Attribute Name Attribute DocumentationGRV No Description: A system generated, sequential number, unique to each

GRV.Syntax: No EditType: Numeric. No decimals.Validations: NoneAttribute Triggers: NoneComments: This no. is generated at the time of the creation of a GRV.

Supplier Code Description: Unique code of the supplier.Type: String, Mixed.Validations:Attribute Triggers: MandatoryComments:

Supplier Description GRV Status Description: The different states that a GRV can go through.

Type: item codeValidations: GRV Status structureAttribute Trigger:Comments: See the class diagram of State transition diagram for the



various GRV states.Authority No Description: The number of the order that this GRV relates to.

Type: Numeric.Validations:Attribute Triggers:Comments: This attribute relates to the manually generated PO number.

Purchase Order No. Description: The number of the order that this GRV relates to.Type: Numeric.Validations: This number cannot be referenced unless the order hasbeen generated in the system.Attribute Triggers: MandatoryComments: This order reference number is related to the order numbergenerated by the system. Not the manual order number.

SuppliersInvoice/DeliveryNote

Description: The invoice number or the supplier.Type: String, mixed. The supplier invoice number might be alpha-numeric. i.e. string)Validations:Attribute Trigger:Comments:

Date Received Description: The date that goods were receivedType: dateValidations:Attribute Triggers:Comments:

16.1.1.2 GRV Detail

Attribute Name Attribute DocumentationUOM Description: Code that reflects the measurement that the item is

measured in (i.e. Unit of Measure).Type: Item CodeValidations: Unit of Measure structureAttribute Triggers:Comments:

Qty OrderedQty Received toDateQty on Delivery Note Description: Total number of items delivered according to the supplier

invoice.Type: Numeric, decimals dependant on UOMValidations: Must check against UOMAttribute Triggers:Comments:

Qty Counted Description: Total number of items that were counted as received fromthe supplier.Type: Numeric.Validations:Attribute Triggers:Comments:



Qty Inspected OK Description: Total number of items that were inspected during the QAinspection.Type: Numeric.Validations:Attribute Triggers:Comments:

Qty Rejected Description: Total number of items that were rejected during the QAinspection.Type: Numeric.Validations:Attribute Triggers:Comments:

Qty Accepted Description: Total number of items released to stock.Type: Numeric.Validations:Attribute Triggers:Comments:

Unit Net PriceQty On GRA Description: Goods returned advice amount

Type: Numeric, decimals dependant on UOMValidations: Must check against UOMAttribute Triggers:Comments: GRA is created if the goods are returned before they areGRV

Supplier Invoice No.Supplier InvoiceValue

Populated from AP

GRV Total (Excl.Vat)

16.2 Visual Alias Documentation:PO_LIST_GRV(Excluded from this sample document – WIP)



16.3 Visual Alias Documentation:GRV_CAP



16.3.1 Business Class: PO 2 GRV Selection



Chapter 17 Hidden Object Documentation

17.1 MA_PO_NO_GEN

17.1.1 MA_PO_NO_GEN Documentation:

This object will create the unique no. for PO depending on what the numberprefix,body and suffix are.

17.1.1.1 Object Input Parameters

Input DescriptionPrefix The characters that will be placed on the front

of the number created.Sufix The characters that will be back on the front of

the number created.Body This is normally system generated, but the

user can specify the main body of the numbergenerated.

Object Output Parameters

17.2 MA_ITEM_DESC

17.2.1 MA_ITEM_DESC Documentation:

Just put in a tkey of an item & it will give you a complete description of thatitem… If you also give it a list of attributes, it will pass back the informationstored against that item for the given attributes if the type is set to pass. Italso gives structure information, like the items group and structure, what itsparent item is and what its child items are.


Input DescriptionATTR_TKEY Put the technical key of the item that you want

described into this local. This is a mandatoryinput.

TYPE This local will determine whether the user willread information from or store informationagainst ATTR_TKEY. Putting PASS into thislocal will read attribute values and PASS willstore attribute values. This is not a mandatoryinput.

ATTR_LIST Put a keylist of attributes that you would like tostore or read in this local. This is not amandatory input

17.2.1.2 Object Output Parameters

Output Description



ST_ITEM_CODE The Item COde of ATTR_TKEY

ST_DES_DESC The Description of the Item codeST_GROUP_CODE The Item code of the group in which the item

ATTR_TKEY is foundST_T_STGROUPH The tkey of the parent item of ATTR_TKEY

ST_STDES_CODE The item Code of the structure in which theitem is found

MAP_L_USERLIST Is populated with the attribute values when thePASS word is chosen.

CHILD_ITEMS This is a keylist with all the child items ofATTR_TKEY in a structure.

17.3 MA_ALLOWED_ITEM

17.3.1 MA_ALLOWED_ITEM Documentation:

Pass this object the tkey of an item, the ALLOWED_ST ructure name andal-presto it will pass back a work list with the allowed items… If LIST is setto true… then a list object will pop up asking the user which allowed item hewould like to select. The selected item is put in to MA_VALUE


Input DescriptionATTR_TKEY This it the tkey of the item against which all the

items are allowed.

ALLOWED_ST This is the item code of the structure which hasall the allowed items in it.

LIST This input needs a T (TRUE) or F (False) if alist object must pop up with the allowed items.This is useful for when the attribute is an itemcode and you only want the user to selectallowed items.


Output DescriptionMA_VALUE If the list option is set to T, then when the list

box pops up, the user will select one item. Theselected item will be in $$MA_VALUE

ST_WORK_LIST This is a keylist with the allowed items againstATTR_TKEY



17.4 MA_CHECK_ITEM

17.4.1 MA_CHECK_ITEM Documentation:

Pass this object two key lists and it will tell you if items in list A are in list B.List A & List B can have one or many items in its list.


Input DescriptionLIST_A This can be a keylist or a single item which the

user will use to see if any of the items inLIST_B

LIST_B This is the keylist againt which LISt_A isChecked.


Output DescriptionRESULT This will pass back a T or And F depending on

if there is an Item that excists in LIST_A andLIST_B

17.5 MA_VERSION_CONT

17.5.1 MA_VERSION_CONT Documentation:

This object will read the version no saved against a technical key andincrement it by one.


Input DescriptionATTR_TKEY The technical key of the item that you want to

do version control on.

17.6 MA_READ_CUBE

17.6.1 MA_READ_CUBE Documentation:

This Object will read a keylist of attributes from a cube.


Input DescriptionTKEY_LIST A keylist which will contain the legs the of the

cube that the user would like to read.ATTR_LIST Put a list of attributes that you would like to

read/write from/to the cubeCUBE_NAME The name of the cube as set up in the cube

structure.TYPE If you want to read information from the cube

this input will contain; "PASS". If you want to



write to the cube, it will contain; "POST"


Output DescriptionMAP_L_USERLIST The results of the POST can be found in this

global variable.

17.7 MA_DATE_CALC

17.7.1 MA_DATE_CALC Documentation:

This object will allow the user to add/subtract values to a date in years,months and days. It can also give the difference between to dates. Anddetermine which date is the larger of the two dates.


Input DescriptionDATE_1 Put the date that you would like to add onto in

this local.

DATE_2 If you want to subtract 2 dates from oneanother, then put the second date in this local.This local is not mandatory

VALUE This is the amount which you would like to addor subtract from DATE1. e.g. : Subtract 10days to DATE1, Value must be -10.

TYPE This local defines the date type to be added orsubtracted from DATE1. Populate this localwith "d" for days, "m" for months and "y" foryears.


Output DescriptionRESULT A Value has been added to or subtracted from

DATE1, the result of this calculation can befound in this local.

RESULT_LIST This local will contain a keylist with thefollowing format : Y;M;D;TD where Y is thedifference in years, M is the difference months,D is the difference in Days, and TD is the totaldifference in DAYS only. The Values in thislocal will be absolute values. i.e. if thedifference in the two dates is -5 then thevalues held in the list will just be 5.

TEST_RESULT This local will be 'T' (True) if Date_1 is greaterthan DATE_2 and 'F' is DATE_1 is less thanDATE_2



17.8 MA_CHECK_PREV

17.8.1 MA_CHECK_PREV Documentation:

This Object must check a previous value against the New value and returnwhether it exists or not. It allows the consultant to search through a processfor a particular value and return a True of False depending if it has found amatch for a particular value stored in the ATTR_TKEY attribute.


Input DescriptionATTR_TKEY This stores the Technical Key of the Attribute

that you would like to check.

PROCESS_TKEY This stores the RG Process Technical Key.

VALUE This should store the current value (The valuethat you would like to check)


Output DescriptionRESULT T/F True is when the value does exist in the

database. False is when the value does notexist on the database.

17.9 MA_SEND_INFO

17.9.1 MA_SEND_INFO Documentation:

This Object will sent a message To a Printer, Fax machine or E-mail. One ofthe Inputs must specify P to print, F to fax and E to E-mail


Input DescriptionATTR_TKEY Put the technical key of the supplier/person

that you want to send information to.TYPE In this input place a F for Fax, E for E-mail, P

for Print to determine the method of transfer ofinformation.

REPORT The technical key of the report that you wantgenerated. (The format in which theinformation is sent)



17.10 GRV_Form_Hidden

1.1.1 GRV_Form_Hidden Documentation:

This will create copy of the PO form selected and create a GRV form in thebackground.



Chapter 18 Purchase Order Transactions

Objective Yes No Correct

1. The objective of Purchase Order Processing is

to capture and send orders to a Supplier� Yes

2. This Authority number can be overwritten with a

'Authority number' given to the client.Yes

3. A check must be put in to confirm that the

authority number is unique� Yes

4. Purchase Orders can be entered manually or

created automatically when the Replenishment

Planner confirms the suggested orders from the

material requirement planning run

N/A

YES

5. The order can be forwarded as: - a hardcopy. - a system generatedfax - e-mail - a manual process

�

YES

6. The date can be amended on a PurchaseOrder. � YES

7. Quantities can be changed but only down, notup. � YES

8. The Buyer will be able to Order the Goods aslong as the order does not exceed themaximum stock levels. The PO order can stillbe captured, but the transaction must beflagged as an exception.

YES

9. If the buyer has the authorisation to amend theorder, the supplier and the Master Planner mustbe informed

Check YES

10. The Buyer will be able to change the statusmanually to 'Completed' even if not all the lineitems have been received.

YES

11. Depending on the business rules, variousemployees can have the ability to view orMonitor their relevant orders (On-line or via ahard copy) The Buyer, creditors clerk and themaster planner should be allowed to view the

YES



Chapter 18 Purchase Order Transactions

Objective Yes No Correctorders

12. The Buyer must have the ability to re-open PO'sonly when there is still an outstanding Qty onthe PO

� YES

13. Depending on whether the Transaction type isfor Stock of Non-Stock Items, the DetailAttribute will change. For Stock items, Itemcode, Supplier code and special instruction willbe added. For Non-Stock items, the GL code,Type and Quote Ref. No. Attributes will beadded.

�YES

14. Once the PO has been Printed, the status mustbe changed to Printed

YES

15.





Chapter 19 Purchase Order TransactionsAttributes

AttributeName Description

Yes

No

Correct

1. PurchaseOrder No

Description: This will be a system generated no. foruniquely identifying a PO.Syntax: No EditType: Alpha Numeric, Must be prefixed with aFactory and Delivery address. Suffix with Stock ornon StockValidations: Prefix must be checked against afactory and a delivery address.Attribute Triggers: NoneComments: Auto generate at time of creation of thePO

Yes

2. SupplierCode

Description: Unique Code for the supplierSyntax: EditableType: Item Code.Validations: Supplier structureAttribute Triggers: (Design)Comments: Once a Supplier Code is selected, the Supplierdescription must be populated with the related description.

�

Yes

3. SupplierDescription

Description: Displays the name of the supplierselectedSyntax: No-editType: Sting, MixedValidations: Dependant on the Supplier CodeSelectedAttribute Triggers: None.Comments:

�

YES

4. Order Type Description: The type of orderSyntax: No-editType: Drop Down List BoxValidations: NoneAttribute Triggers: None.Comments: There are three Transaction typesnamely: Stock, Non-Stock Items and CAPEX

�

YES

5. Buyer Description: Role of the user who created thePurchase Order.Syntax: EditableType: item codeValidations: User Structure. Must check allowedsuppliers for a buyer.Attribute Triggers: (Design)Comments: Buyers Matrix against a supplier

�

YES





Yes

No

Correct

6. DateTimeCreated

Description: The date and time that the PurchaseOrder was created.Syntax: No EditType: DateValidations: NoneAttribute Triggers: NoneComments: Will get populated when the supplier ischosen.

�

YES

7. Order Status Description: The current status of the PurchaseOrder.Syntax: EditableType: Item Code (Status Structure).Validations: State transitions as outlined in theState transition diagramAttribute Triggers: None.Comments: To see the various transaction typesand there state transition see PO Status.

YES

8. SettlementDiscount

Description: This is the discount given to the clientwhen he/she settles there accountType: NumericValidations: checked against the Supplier Masterfor the Supplier Chosen.Attribute Triggers: None. Will get populatd when theSupplier is chosenComments: Defaults to settlement discount onsupplier master. Can be overridden. Need a reportto compare all that have been overridden

�

YES

9. Authority No Description: This is a manual number given to aspecific POSyntax: EditableType: Alpha NumericValidations: Check for duplicate order authoritynumbers.Attribute Triggers: Leave field Trigger to check forduplicate authority numbers. UseComments: This must be a manual numberingsystem

�

YES





Yes

No

Correct

10. W/H Code Description: The warehouse where the item is to bestored.Type: Item CodeValidations: W/H StructureAttribute Triggers: Mandatory. (If Transaction typeis Non-Stock Item, then the W/H Must Default toConsumable Stores)Comments: Each material item could have a defaultwarehouse depicting where the item is to be stored.This can be altered at the time that the PurchaseOrder is captured. If it is a non-stock item it mustdefault to consumable W/H (Main store W/H)

YES

11. W/HDescription

Description: Explanation of the W/H Code ChosenSyntax: No-EditType: StingValidations: NoneAttribute Triggers: NoneComments: Must be populated

�YES

12. Version No Description: Every time the date or quantity ischanged on the PO, this number must beincrementedSyntax: non- edit.Type: numericValidations: This Starts at zeroAttribute Triggers: This does not have an attribute trigger, but willget updated on the UPDATE Events.Comments: Starts at ZERO.

�

YES

13. SpecialInstructions

Description: Field to capture documentation for POlineSyntax: EditableType: String, MixedValidations: NoneComments: None

�YES

14. OrderingUOM

Description: Code that reflects the measurementthat the item is measured in (i.e. Unit of Measure).Syntax: EditableType: Item CodeValidations: Unit of Measure structureAttribute Triggers: None. This information will beobtained when the Item is selected from theSupplier/ W/H/ Item MatrixComments: None

�

YES





Yes

No

Correct

15. Qty Required Description: Total number of items to be purchased.Syntax: EditableType: Numeric.Validations: May not exceed the Maximum stocklevel. This value will be checked against theMaximum stock level in the Supplier | W/H| ItemMaster.Attribute Triggers:Comments: None.

YES

16. Qty Received Description: Total number of items received onGRVSyntax: No-Edit fieldType: Numeric.Validations: Must balance against the number ofGRV's received for a PO detail item.Attribute Triggers: NoneComments: This value will be obtained from theGRV

�

YES

17. DateRequired

Description: Date on which the item beingpurchased is required.Syntax: EditableType: DateValidations: The Date can't be in the pastAttribute Triggers: (Design)Comments: Need to be able to split the order.

YES

18. StandardCost

Description: This is the National Standard Cost forthe Chosen item.Syntax: No EditType: NumericValidations: NoneAttribute Triggers: NoneComments: This comes from the item master(standard cost)...convert to Ordering UOM for thePO.

YES





Yes

No

Correct

19. SupplierPrice

Description: Price that was quoted for the item tobe purchased. It will first be populated with theStandard Cost, but can be overwritten.Syntax: EditableType: Numeric. 4 decimals.Validations: NoneAttribute Triggers: NoneComments: This price is the standard price and canbe overridden. Need a report to compare the priceto the standard cost on the item master file.

�

YES

20. TradeDiscount 1

Description: Percentage discount that is to beallowed for the item to be purchased. This will bepopulated with values from the Supplier| W/H| ItemMaster.Syntax: EditableType: Numeric. 2 decimals.Validations: Between 0.00 and 100.00Attribute Triggers: None.Comments: This discount will vary from supplier tosupplier as well as from material item to materialitem. Only applies to Raw materials, trading goodsand selected stock items. This may be over writtenat time of entry. A report is required to compare theTrade discount to the standard trade discounts onthe supplier material master file

Can be modified

YES

21. TradeDiscount 2

Description: Additional percentage discount that isto be allowed for the item to be purchased. This willbe populated with values from the Supplier | W/H|Item Master.Syntax: EditableType: Numeric. 2 decimals.Validations: Between 0.00 and 100.00Attribute Triggers: NoneComments: Additional discount after calculation ofnet price after Trade Discount 1. Can Be modified

YES

22. RequestedBy

Description: Name of the user who requested thematerial item.Syntax: EditableType: Item CodeValidations: User StructureAttribute Triggers: NoneComments: None

�

YES





Yes

No

Correct

23. Total Value(Excl.Vat)

Description: This is the Supplier Price x the Qtyrequired.Syntax: No EditType: Numeric. 4 decimalsValidations: None.Attribute Triggers: NoneComments: None

�YES

24. Line ItemStatus

Description: The current status of the PurchaseOrder line item.Syntax: EditableType: Item Code.Validations: Status Structure and State transitiondiagram specs.Attribute Triggers: NoneComments: Goes to completed when the Qty ordered >= QtyReceived. After this it cannot be amended.

YES

25.



Chapter 20 GRV Transactions


1. The Receiving Clerk along with the Buyer canmonitor for expected deliveries

� Yes

2. Once the goods have been received a GoodsReceived Voucher (GRV) is generated on thesystem

� Yes

3. From there the goods can be released to stockor go for a quality inspection

� YES

4. When non-stock items are received, theRequestor must be informed

� YES

5. The user must have the ability to print a GRV YES

6. A Goods Received Voucher (GRV) needs to begenerated for the receipt of every Stock andNon-stock items. i.e. a GRV is created for allpayments.

�YES

7. It is important to note that an order can havemany deliveries, but that a GRV can onlybelong to one order.

�YES

8. Receiving clerk can over receive. The Clerkmust be informed (prompted) of the excess anddecide whether to receive the goods or not.

YES

9. The PO detail line must be closed automaticallywhen the Qty accepted is equal to the Qtyordered.

�YES

10. When the GRV is captured, the status of the POwill change from 'Ordered' to 'Received' � YES

11. The status of the PO line item will then changefrom 'Received' to 'Completed' if the QtyAccepted >= Qty Ordered

� YES

12. A GRV detail line must be linked to a PO detailline.

YES

13. If a QC is completed the status will change from'QC Waiting' to 'CLOSED' � YES

14.

15.





Chapter 21 GRV Transactions Attributes


Yes

No

Correct

1. GRV No Description: A system generated, sequentialnumber, unique to each GRV.Syntax: No EditType: Numeric. No decimals.Validations: NoneAttribute Triggers: NoneComments: This no. is generated at the time of thecreation of a GRV.

Yes

2. SupplierCode

Description: Unique code of the supplier.Type: String, Mixed.Validations:Attribute Triggers: MandatoryComments:

�Yes

3. SupplierDescription

Description: Displays the description of thesupplier selectedSyntax: Non EditableType: String, MixedValidations: NoneComments: None

�YES

4. GRV Status Description: The different states that a GRV can gothrough.Type: item codeValidations: GRV Status structureAttribute Trigger:Comments: See the class diagram of Statetransition diagram for the various GRV states.

YES

5. Authority No Description: The number of the order that this GRVrelates to.Syntax: Non EditableType: Numeric.Validations:Attribute Triggers:Comments: This attribute relates to the manuallygenerated PO number.

�

YES

6. PurchaseOrder No.

Description: The number of the order that this GRVrelates to.Type: Numeric.Validations: This number cannot be referencedunless the order has been generated in the system.Attribute Triggers: MandatoryComments: This order reference number is relatedto the order number generated by the system. Notthe manual order number.

�

YES





Yes

No

Correct

7. SuppliersInvoice/Delivery Note

Description: The invoice number or the supplier.Type: String, mixed. The supplier invoice numbermight be alpha-numeric. i.e. string)Validations: NoneAttribute Trigger: NoneComments: None

�YES

8. DateReceived

Description: The date that goods were receivedType: dateValidations: NoneAttribute Triggers: NoneComments: None

�YES

9. UOM Description: Code that reflects the measurementthat the item is measured in (i.e. Unit of Measure).Type: Item CodeValidations: Unit of Measure structureAttribute Triggers:Comments:

YES

10. Qty Ordered Description: Displays the Qty ordered from the POFormSyntax: Non EditableType: NumericValidations: Against Related PO Detail LineComments: None

�YES

11. Qty Receivedto Date

Description: If any other GRV’s were done for aparticular PO line, then the total qty received todate will be displayed hereSyntax: Non EditableType: NumericValidations: Against Po LinesComments: None

�YES

12. Qty onDelivery Note

Description: Total number of items deliveredaccording to the supplier invoice.Type: Numeric, decimals dependant on UOMValidations: Must check against UOM. Capturedependant on Master file for supplierAttribute Triggers:Comments:

YES





Yes

No

Correct

13. Qty Counted Description: Total number of items that werecounted as received from the supplier.Type: Numeric.Validations: Capture dependant on Master file forsupplierAttribute Triggers:Comments:

�

YES

14. QtyInspected OK

Description: Total number of items that wereinspected during the QA inspection.Type: Numeric.Validations: Capture dependant on Master file forsupplierAttribute Triggers:Comments:

�

YES

15. Qty Rejected Description: Total number of items that wererejected during the QA inspection.Type: Numeric.Validations: Capture dependant on Master file forsupplierAttribute Triggers:Comments:

�

YES

16. Qty Accepted Description: Total number of items released tostock.Type: Numeric.Validations:Attribute Triggers: Capture dependant on Masterfile for supplierComments:

�

YES

17. Unit NetPrice

Description:Syntax: EditableType: Numeric.Validations:Attribute Triggers:Comments

YES

18. Qty On GRA Description: Goods returned advice amountType: Numeric, decimals dependant on UOMValidations: Must check against UOMAttribute Triggers:Comments: GRA is created if the goods arereturned before they are GRV

YES





Yes

No

Correct

19. GRV Total(Excl. Vat)

Description: GRV Line TotalSyntax: EditableType: Numeric.Validations:Attribute Triggers:Comments

YES

Chapter 22 Master File Maintenance


1. The Procurement Manager has the ability tomaintain the Item master File

Yes

2. All relevant parties (Buyer, Creditors Clerk) willfill in a form containing supplier details. Once ithas been completed and authorised, it iscaptured into the system by the Accountant.

�Yes

3. Depending on the Business rules, theAccountant will have the authority to create,read, update and delete information on asupplier master

�YES

4. The buyer will only have the ability to view theSupplier Master file. �

YES

5. Material Items must have a list of up to 3preferred suppliers.

YES

6. If preferred supplier 1 is filled in, this will thenserve also as the default supplier � YES

7. System must keep the last three purchaseprices per item per W/H with the purchase date. YES

8. The Procurement manager also has the abilityto maintain item related master File such as theSupplier W/H Item Matrix and the W/H Item.

YES

9. YES



Item Master File

Supplier Warehouse Item Master



Warehouse Item Master



Buyers To Suppliers

Supplier To Warehouses





Chapter 23 An Extract from the Rubico BridgeManual

The Rational Rose model should contain information in a specific format.Different patterns of information are required:

• Structure Information• Transaction Information

• Header and Detail Information• Transaction Type Information• Enquiry Information

23.1 Structure InformationEach Rubico structure is to be modelled as a class of stereotype<<Structure>>. The groups are modelled as subclasses (specialisations) ofthis class, with stereotype <<Structure Group>>. The groups are linked viaaggregations in the required sequence.

In order to generate Rubico Generic Transactions, at least the followingstructures are required:

• Attribute Structure• Attribute Classification Structure• Process Structure• Transaction Type structure

In addition to these structures, additional structures can be specified.Attributes on the transaction can be declared as attributes of type item code,and these structures can be the structures for these attributes.

The following model gives an example of a structure:



Attribute Structure

< < S t ructure>>System

<<Structure Group>>

Attributes

<<St ruc ture G roup>>

AttributeClassification

<<Structure Group>>

The following table gives the detail of the properties to be completed foreach class, and for which Rubico configuration this property is used.



Model Element or property Configuration

Structure: Class with stereotype<<Structure>>. The followingproperties are required:

Rubico Structure (View configuration with STF112)

• Name (General tab) • Structure Description• Recursive (Rubico tab) • If Recursive = True, then structure Type =

[Structure Type Defaults]. Recursive (frombridge.ini file)

• If Recursive = False, then structure type =[Structure Type Defaults].nonRecursive (frombridge.ini file)

• Item Code (Rubico tab) • Structure Code• Structure Usage (Rubico tab) • If structure usage = Attribute, this structure should

be a 3-level structure. An item will be created onlevel 1 of this structure (according to [DefaultStructure Items].AttributeStructure in bridge.ini).On the second level, items will be generated forheader and detail, and on the lowest level, allattributes of the header and detail will be created.The AMOUNT AMOUNT validation structure ispopulated with attribute structure code and lowestlevel group code.

• If structure usage = Attribute Classification, thisstructure should have 5 groups. A default item foreach of the first 3 groups are created as perbridge.ini file: [Default Structure Items].AttributeClassificationStructure. An entry is createdon level 4 from the business object (discussedlater) and two items are created on level 5,corresponding to the header and the detailrespectively.

• If structure usage = Process, the structure will bepopulated with a default process as per bridge.ini:[Default Structure Items]. ProcessStructure. Thisstructure is used to populate the PROCESS eventof the RGTxxx form.

• If structure usage = Transaction Type, a statediagrams will be used to populate the structure withtransaction type items. The MATTYPE validationstructures is populated with this structure and thelowest level group.

Structure Group: Class with stereotype<<Structure Group>>, which is aspecialisation of the <<Structure>>class. Groups are linked viaaggregations. The following propertiesare required:

Group of a Rubico Structure. (View configuration withSTF112).

• Name (General tab) • Group Description• Item Code (Rubico tab) • Group’s item code





23.2 Transaction InformationEach transaction has two levels of information on the same diagram: theanalysis and the design. The analysis consists of a business class with twosubclasses, the header and the detail. The header and the detail are linkedvia an aggregation.

The design information consists of a class of stereotype <<core>> whichindicate which Rubico object is to be used, and a class of stereotype<<visual>> which gives the alias information for the object. The <<visual>>object is a specialisation of both the business object and the <<core>>object.

If an enquiry is required for the transaction, it is modelled as a class ofstereotype <<Enquiry>>. The design thereof is again gives by classes ofstereotype <<visual>> and <<core>>.

The transaction types are given by a structure linked to the header. For thestructure, a state diagram is created to give the possible transaction typesand possible transitions between them.

The following diagram gives an example transaction model:

R G T 0 0 8

<<Core>>

P O _C A P _ M A N

< < V i su a l > >

P u rchase Order

P O Inqu i ry

<<Enqu i r y>>

P O _ E NQ 1

<<Visu a l> >RG L 0 0 1

<<Core>>

Stock I tem

I t e m C o d e

D e scr ipt ion

<<St ruc ture>>

Sta tus S t ru c t u re

<<S tr u c tu re > >

P O D e t a i l

I t em : S tock Item

Quan t i t y

Un i t Pr ice

L i n e T o t a l

P O H e a d e r

P O N u m b e r

P O Tran Type

S u p p l i e r : A ccount No

Da te

Accoun t No

<<St ruc tu re Group>>



The following diagram is a sample state diagram:

P O Q u o t e

Enqu i r y

An alias of RGT008/009 will be generated. Sufficient other configuration willbe generated so that the RGT008/9 alias can be executed and a visual formwill be displayed corresponding to the model. The visual form will containthe attributes listed in the header and detail classes respectively. A statetransition will be set up for the RGT008/9 form for the transaction type field,corresponding to the state transition diagram. An enquiry form will beavailable corresponding to the <<Enquiry>> class specified in the UMLmodel. The only enquiry object supported is RGL001.

The UML model should contain diagram(s) according to the format givenabove. The bridge will, however, work from the core model information, andnot from a specific diagram. This ensures data integrity.

The following table gives the details on which properties are required togenerate the configuration. This tables should be used for a manual checkof the model and of the import file once it is generated. When any errorsoccur during the import, this table might also be used to determine whichmodel elements/properties might have caused the problem.

Source Configuration

Alias of RGTxxxs: Class withstereotype <<visual>>. This class is aspecialisation of a class withstereotype <<core>>. E.g.,PO_CAP_MAN (refer to example classdiagram). Properties:

Alias object (ADF003). At this stage, only RGT008 andRGT009 are supported. Many of the object fields areretrieved from bridge.ini, e.g. [Rubico ObjectDefaults].DefaultExecutionType; DefaultRepeating andDefaultIPath.

• Name (General tab) • Object code• Description (Rubico tab) • Object description• Sort Descending (Rubico tab) • Used to populate the SORT DESCENDING event

of the RGTxxx form



Core object: Class with stereotype<<core>>, which is a generalization ofthe alias object. E.g., RGT008.Properties:

Core Rubico object (object to execute for alias)

• Name (General tab) • Object’s code and object to execute for the aliasobject

• Description (Rubico tab) • Object’s description (if the core object didn’t existbefore the import)

Business object: Class with nostereotype, which is a generalization ofthe <<visual>> class (the alias), andhas as specializations the header anddetail classes. E.g., Purchase Order.Properties:

Used to populate items in the attribute classificationstructure in group 4 . (view config via STF112)

• Item code (Rubico tab) • Item code of item in attribute classification structure• Name (General) • Description of item in attribute classification

structure

Header and Details. Class with nostereotype, which is a specialisation ofthe business object, and there is anaggregation between the header andthe detail. Properties:

Used to populate items in the attribute classificationstructure in group 5, and attribute structure in group 2.(View configuration via STF112).

• Item Code (Rubico tab) • Item code of item in attribute classification structureand attribute structure.

• Name (General tab) • Description of item in attribute classificationstructure and attribute structure.

Header attributes and Detail Attributes.Properties:

Items in the Attribute structure in group 3, and Rubicoattributes (amounts). View configuration via STF112and STF026. An allowed linked is created between theattribute structure and the attribute classificationstructure, and the attributes are set up as allowed itemsagainst the attribute classification item (header & detailrespectively). Some default values for attribute fieldsare read from bridge.ini: [Attribute TypeDefaults].Precision; Layout; Security. The HEADERATTRIBUTES and DETAIL ATTRIBUTES events of theRGTxxx object are populated.

• Attribute Item Code (Rubico tab) • Item code of the attribute (item code for item inattribute structure).

• Name (General tab) • Name of the attribute (item description of the itemin the attribute structure)



• Data type & Layout (Rubico tab) • Data Type and layout fields in Rubico. If the datatype is item code, then the type property (Generaltab) gives the name of the class (with stereotypestructure or structure group). The structuredefinition will be read to populate the structure codeand group code for the attribute. If data type isform field, this attribute is not created in theattribute structure. The name of the attribute isused to populate the LABEL event on the RGTxxxobject.

• Syntax (Rubico tab) • Syntax field of Rubico Attribute• Type (General tab) • Only required for attributes of type item code as

discussed above.

Enquiry for RGTXXX form. Object withstereotype <<Enquiry>>, and subclassof the business class, e.g. PO Inquiry

Link RGTxxx with alias of enquiry object.

Alias for enquiry. Specialization ofEnquiry. Stereotype = <<Visual>>,e.g. PO_ENQ1

The Rubico Alias of the core object. This alias (theenquiry alias) is used to populate the LIST OBJECTevent of the RGTxxx form. Many of the object fieldsare retrieved from bridge.ini, e.g. [Rubico ObjectDefaults].DefaultExecutionType; DefaultRepeating andDefaultIPath.

• Name (General tab) • Object code in ADF003 of alias• Description (Rubico tab) • Description of object in ADF003 of alias

Enquiry Core: Class with stereotype<<Core>>

Object to execute for enquiry alias.

• Name (General tab) • Name of object. Object to execute for alias• Description (Rubico tab) • Only used of core object doesn’t exist yet: Object

description in ADF003.

States transition diagram fortransaction types: State diagram for aclass with stereotype <<structure>>,linked to the business object. , whichhas a state transition engine linked toit. The state diagram will contain thestates (transaction type) and thepossible transitions between them. Foreach state, the following properties arerequired:

State diagram gives all possible transaction types. Thesates are created as items in the transaction typestructure. The transitions on the diagram will be usedto populate the Rubico state transition for thetransaction type. (The states are used to populate theHDR TRAN TYPES event and the transitions topopulate the TRAN TYPE CHANGE event of RGTxxx).

• Name (General tab) • Name of item in transaction type structure• Item Code (Rubico tab) • Item code of item in transaction type structure• Default (Rubico tab) • Indicates whether this transaction type is the

default transaction type. Should only be true forone state. Used to populate the DEF HDR TRANevent of the RGTxxx form



None There are some events of the RGTxxx form which arepopulated with default values. The model does notimpact the configuration generated for these events.

• AUTO NUMBER : True• AMTS REFRESH : True• TOTAL LIST : Nothing (since this is the first event,

it is used to nullity $$RG_T_RGHDR, but no total information is populated)

• RGDETL AMOUNTS: Calls RGF001• RGHDR AMOUNTS: Calls RGF001• The following events are created, but no rules are

created for them:• LINE VAL FAIL• CHECK PERIOD• HEADER VALIDATION• DELETE RGHDR• STORE• DELETE RGDETL• LINE VALIDATION

The alias will be created as an open item in the configuration managementstructure.

Certain configuration is assumed to exist, e.g. keywords, the rules forMA_ALLOWED_ITEM,etc. The bridge will not generate any keywords –they are all assumed to exist.



Appendix A: Capability

The CMM defines five levels of software maturity for an organization and provides a framework formoving from one level to the next (from level 1 to 5). The CMM guides the organization throughactivities designed to help improve software processes with the goal of achieving repeatability,controllability and measurability.

Level Key Process Area Rubico1. InitialAd hoc, even chaotic; successdepends solely onIndividual heroics and efforts.

not applicable not applicable

2. RepeatableBasic project management to trackfunctionality of application, and costand schedule of project.

Requirements ManagementSoftware Project PlanningSoftware Project Tracking andOversightSoftware Subcontract ManagementSoftware Quality AssuranceSoftware ConfigurationManagement

Process MethodologyRubico Quality FrameworkProduct Management

3. DefinedThe process for management andengineering is documented,standardized, and integrated, Allprojects use an approved, tailoredversion of the process.

Organization Process FocusOrganization Process DefinitionTraining ProgramIntegrated Software ManagementSoftware Product EngineeringIntergroup CoordinationPeer Reviews

Forum ManagementLearning ModelRubico People Maturity Model

4. ManagedDetailed measures of the softwareprocess and software quality metricsare collected. Both process andsoftware products are understood andcontrolled.

Quantitative Process ManagementSoftware Quality Management

Strategic Product ManagementManagement ForumLearning Model

5. OptimizingContinuous process improvement isenabled by use of metrics and frompiloting innovative ideas andtechnologies

Defect PreventionTechnology Change ManagementProcess Change Management

Learning Model with People, Processand Technology assessmentsInnovation Cycle



Appendix B: References

James Rumbaugh, Ivar Jacobson, Grady Booch, The Unified Modeling Language Reference Manual (1999), Addison Wesley,ISBN 020130998-X

Ivar Jacobson, Object Oriented Software Engineering (1998), ACM Press, ISBN 0201544350

Philippe Kruchten, The Rational Unified Process, An Introduction (1998), Addison Wesley, ISBN 0201604590

Walker Royce, Software Project Management, A Unified Framework (1998), Addison Wesley, ISBN 0201309580

Ivar Jacobson, Martin Gross, Patrik Jonsson, Software Reuse, Architecture, Process and Organization for Business Success(1997), Addison Wesley, ISBN 0201924765

Geri Schneider, Jason P. Winters, Applying Use Cases, A Practical Guide (1998), Addison Wesley, ISBN 0201309815

Hans-Erik Eriksson, Magnus Penker, UML Toolkit (1998), Wiley Computer Publishing, ISBN 0471191612

Jay van Zyl, Object Oriented Analysis and Design using the UML, A Complete Reference, Version 3.0.0 (1997-1999), RubicoEducation

Mark Pardini, Rubico Methodology Team, Rubico Methodology Overview (1998), Rubico Professional Services

Rational Software Corporation, OMG Unified Modeling Language Specification 1.3r9 (draft) (1999)

Anthony Stewart, Project Documentation (1999), Selected diagrams

Rubico UML Standards and Patterns Forum, UML standards and Patterns Version 1.0.8 (1998), UML Forum

Rubico Engineering, Rubico Generic Patterns (1996-1999)

Rubico Engineering, Rubico UML Bridge Version 1.0.0 (1999)

o

Implementing Business Solutions using UML

Documents