Functions and Features ln 61 functions and features.pdf · Table of Contents Chapter 1...

SSA® ERP LN 6.1

Functions and Features

© Copyright 2005 by Baan International B.V., a subsidiary of SSA Global Technologies, Inc.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any way or by any means, including, without limitation, photocopying or recording, without the prior written consent of Baan™ International B.V.

Important Notices

The material contained in this publication (including any supplementary information) constitutes and contains confidential and proprietary information of Baan International B.V.

By gaining access to the attached, you acknowledge and agree that the material (including any modification, translation or adaptation of the material) and all copyright, trade secrets and all other right, title and interest therein, are the sole property of Baan International and that you shall not gain right, title or interest in the material (including any modification, translation or adaptation of the material) by virtue of your review thereof other than the non-exclusive right to use the material solely in connection with and the furtherance of your license and use of software made available to your company from Baan International pursuant to a separate agreement (“Purpose”).

In addition, by accessing the enclosed material, you acknowledge and agree that you are required to maintain such material in strict confidence and that your use of such material is limited to the Purpose described above.

Although Baan International has taken due care to ensure that the material included in this publication is accurate and complete, Baan International cannot warrant that the information contained in this publication is complete, does not contain typographical or other errors, or will meet your specific requirements. As such, Baan International does not assume and hereby disclaims all liability, consequential or otherwise, for any loss or damage to any person or entity which is caused by or relates to errors or omissions in this publication (including any supplementary information), whether such errors or omissions result from negligence, accident or any other cause.

Baan International B.V., is a wholly owned subsidiary of SSA® Global Technologies™, Inc.

Trademark Acknowledgments

SSA Global, SSA and the SSA Global logo are trademarks of SSA Global Technologies, Inc. in the United States and/or other countries. Baan is a trademark of Baan International B.V., in the United States and/or other countries.

All other company, product, trade or service names referenced may be registered trademarks or trademarks of their respective owners.

Publication Information

Document code : P3496D US

Release : SSA® ERP LN 6.1

Document title : Functions and Features

Publication date : November 05

Table of Contents

Chapter 1 Introduction.................................................................................................................1-1

Chapter 2 Enterprise Modeler .....................................................................................................2-1 Introduction ..................................................................................................................................2-1

Level 1: Enterprise Structure Model ........................................................................................2-3 Level 2: Business Control Model.............................................................................................2-5 Level 3: Business Functions, Processes, and Organization diagram......................................2-6 Business Data Model – Entity Relationship Model (ERD) .......................................................2-8

Functionality.................................................................................................................................2-9 Enterprise Structure Modeling in SSA ERP ............................................................................2-9 Business Control Model ........................................................................................................2-10 Business Function Model ......................................................................................................2-11 Link to business function/process model...............................................................................2-12 Business Process Model.......................................................................................................2-13 Business Organization Model ...............................................................................................2-14 Business Data Model - Entity Relationship Models (ERM)....................................................2-14

Chapter 3 Production typologies and SSA ERP scenarios ......................................................3-1

Chapter 4 Common......................................................................................................................4-1 Introduction ..................................................................................................................................4-1 Calendars ....................................................................................................................................4-1 Unit effectivity ..............................................................................................................................4-2

ii | Table of Contents

Unit effective data ...................................................................................................................4-3 Requirements..........................................................................................................................4-3 Units and sales order entry .....................................................................................................4-4 Units in inventory ....................................................................................................................4-4 Pegging...................................................................................................................................4-4 Cost price calculation..............................................................................................................4-5

Item base data .............................................................................................................................4-5 Business partners ........................................................................................................................4-6 Taxation .......................................................................................................................................4-6

Chapter 5 People..........................................................................................................................5-1 Introduction ..................................................................................................................................5-1 Master Data Management (MDM) ...............................................................................................5-1 Time Management (TMM) ...........................................................................................................5-2

Budgeting................................................................................................................................5-3 Hours registration....................................................................................................................5-3 History.....................................................................................................................................5-5

Chapter 6 Financials ....................................................................................................................6-1 Introduction ..................................................................................................................................6-1 General Ledger (GLD) .................................................................................................................6-2

Currency system .....................................................................................................................6-2 Company structure..................................................................................................................6-2 General ledger structure .........................................................................................................6-2 Financial integration transaction mapping...............................................................................6-3 General ledger transactions ....................................................................................................6-3 Reconciliation..........................................................................................................................6-3 General ledger inquiries and reports.......................................................................................6-4 Period and year end closure ...................................................................................................6-4 Tax reporting...........................................................................................................................6-4

iii | Table of Contents

Accounts Receivable (ACR) ........................................................................................................6-4 Accounts Payable (ACP) .............................................................................................................6-7 Cash Management (CMG)...........................................................................................................6-9 Financial Budget System (FBS).................................................................................................6-11 Cost Accounting (CAT) ..............................................................................................................6-12 Fixed Assets Management (FAM) .............................................................................................6-14 Financial Statements (FST) .......................................................................................................6-16

Chapter 7 Project .........................................................................................................................7-1 Introduction ..................................................................................................................................7-1 Project Dashboard .......................................................................................................................7-5 General Project Tables (PDM).....................................................................................................7-7

General Project Data...............................................................................................................7-7 Standard Cost Objects ............................................................................................................7-8 Buy from business partner diskettes .......................................................................................7-9 Standard Revenues ................................................................................................................7-9 Standard structures.................................................................................................................7-9 User-defined structures...........................................................................................................7-9 Project templates ..................................................................................................................7-10 Standard Surcharges ............................................................................................................7-11

Project Definition (PDM) ............................................................................................................7-11 Scope definition – Dynamic menu.........................................................................................7-12 Project Data ..........................................................................................................................7-12 Project structures ..................................................................................................................7-14 Project general data..............................................................................................................7-15 Project Cost Objects .............................................................................................................7-15 Project Revenues..................................................................................................................7-16 Project surcharges ................................................................................................................7-16 Project Currency Conversion ................................................................................................7-16

Project Estimating (EST)............................................................................................................7-16

iv | Table of Contents

Project Budget (PTC).................................................................................................................7-22 Project Planning (PSS-2) ...........................................................................................................7-27

Plans.....................................................................................................................................7-28 Activities and Activity Structure .............................................................................................7-28 Activity Relationships ............................................................................................................7-29 Milestones.............................................................................................................................7-29 Integration with Microsoft Project ..........................................................................................7-29 External scheduling links.......................................................................................................7-30 Base line ...............................................................................................................................7-30

Project Requirement Planning (PSS-6)......................................................................................7-31 Generate planned orders ......................................................................................................7-32 Order line balance.................................................................................................................7-33 Planned purchase orders ......................................................................................................7-33 Planned warehouse orders ...................................................................................................7-33 History of PRP order .............................................................................................................7-34 Generate service orders........................................................................................................7-34 List of service order links by project ......................................................................................7-34

Project Progress (PPC)..............................................................................................................7-35 Progress................................................................................................................................7-36 Costs.....................................................................................................................................7-37 Cost Forecast........................................................................................................................7-38 Registering revenues ............................................................................................................7-39 Financial results ....................................................................................................................7-39 Extension Transactions.........................................................................................................7-41 Processing ............................................................................................................................7-42

Project Monitoring (PPC) ...........................................................................................................7-42 Build Actual Cost Control ......................................................................................................7-43 Control Inquiries and Reports ...............................................................................................7-43 Financial analysis (Graphs)...................................................................................................7-44

v | Table of Contents

Performance Measurement...................................................................................................7-45 Project Invoicing (PIN) ...............................................................................................................7-46

Installment invoicing..............................................................................................................7-47 Progress invoice ...................................................................................................................7-47 Unit Rate ...............................................................................................................................7-48 Cost plus ...............................................................................................................................7-49 Integration with Sales Invoicing.............................................................................................7-50

Chapter 8 Enterprise Planning....................................................................................................8-1 Introduction ..................................................................................................................................8-1 Enterprise Planning Master Data .................................................................................................8-2

Scenarios ................................................................................................................................8-2 Item data .................................................................................................................................8-3 Resources...............................................................................................................................8-4 Plan units ................................................................................................................................8-4 Sourcing..................................................................................................................................8-4

Master planning ...........................................................................................................................8-5 Item planning ..........................................................................................................................8-5 Resource planning ..................................................................................................................8-6 Channel planning ....................................................................................................................8-6

Order planning .............................................................................................................................8-7 Plan analysis................................................................................................................................8-8 Plan transfer ................................................................................................................................8-9

Order grouping........................................................................................................................8-9 Release planning ..................................................................................................................8-10

Enterprise Planning parameters ................................................................................................8-10 EP parameters ......................................................................................................................8-10 Performance parameters ......................................................................................................8-11 Work load control parameters ...............................................................................................8-11

vi | Table of Contents

Chapter 9 Order Management.....................................................................................................9-1 Introduction ..................................................................................................................................9-1 Important master data for Order Management.............................................................................9-1

Sales office .............................................................................................................................9-2 Purchase office .......................................................................................................................9-2 Dashboards.............................................................................................................................9-2

Pricing..........................................................................................................................................9-3 Sales Control ...............................................................................................................................9-4

Sales master data ...................................................................................................................9-4 Sales quotations .....................................................................................................................9-4 Sales order entry.....................................................................................................................9-5 Commission and rebate ..........................................................................................................9-7

Purchase Control .........................................................................................................................9-8 Purchase master data.............................................................................................................9-8 Purchase requisitions..............................................................................................................9-9 Purchase RFQs ......................................................................................................................9-9 Purchase order entry.............................................................................................................9-10 Vendor management.............................................................................................................9-11

Relation Management................................................................................................................9-11 Purchase contracts ...............................................................................................................9-12

Delivery contract ........................................................................................................................9-13 Purchase schedule contract.......................................................................................................9-13 Purchase contract line logistic data ...........................................................................................9-14

Purchase contract price revisions .........................................................................................9-15 Sales contracts .....................................................................................................................9-16

Purchase and Sales Schedule Management .............................................................................9-18 Introduction ...........................................................................................................................9-18 Purchase schedule management..........................................................................................9-19 Push and pull demand ..........................................................................................................9-19

vii | Table of Contents

Purchase schedule header ...................................................................................................9-20 Purchase schedule lines .......................................................................................................9-21 Integrations around the purchase schedules ........................................................................9-22 Process the purchase schedule ............................................................................................9-26 Purchase release header ......................................................................................................9-26 Purchase release lines..........................................................................................................9-29 Purchase release lines details ..............................................................................................9-29 CUM handling and FAB/RAW authorizations........................................................................9-30

Sales schedule management.....................................................................................................9-31 Introduction ...........................................................................................................................9-31 Sales releases ......................................................................................................................9-32 Sales release header ............................................................................................................9-32 Sales release lines................................................................................................................9-33 Sales schedule header..........................................................................................................9-33 Sales schedule lines .............................................................................................................9-35 Schedule shipment details/corrections..................................................................................9-37 Sequence shipping information.............................................................................................9-38 Sales schedule reconciliation................................................................................................9-38 CUM handling and FAB/RAW authorizations........................................................................9-38

Chapter 10 Electronic Commerce...............................................................................................10-1 Introduction ................................................................................................................................10-1

Master data ...........................................................................................................................10-2 Networks ...............................................................................................................................10-2 Conversion............................................................................................................................10-2 Communication .....................................................................................................................10-3 Message data .......................................................................................................................10-3 General .................................................................................................................................10-3

Chapter 11 Central Invoicing ......................................................................................................11-1

viii | Table of Contents

Introduction ................................................................................................................................11-1 Sales Invoicing...........................................................................................................................11-1

Chapter 12 Manufacturing...........................................................................................................12-1 Introduction ................................................................................................................................12-1 Engineering Data Management (EDM)......................................................................................12-2

Product structure engineering ...............................................................................................12-2 Revision control ....................................................................................................................12-2 Mass BOM changes..............................................................................................................12-2 Approval procedures .............................................................................................................12-2 Interface to SSA PDM...........................................................................................................12-3

Item Production Data (IPD)........................................................................................................12-3 Bill of Material (BOM).................................................................................................................12-4 Routing (ROU) ...........................................................................................................................12-5 Configurator (PCF) ....................................................................................................................12-8

Generic product modeling .....................................................................................................12-8 Configuration and structure generation.................................................................................12-9

Cost Price Calculation (CPR).....................................................................................................12-9 Shop Floor Control (SFC) ........................................................................................................12-11

Positioning of production typologies....................................................................................12-11 Production order control......................................................................................................12-14 Production order processing ...............................................................................................12-15 Production order completion ...............................................................................................12-16 Scrap and yield ...................................................................................................................12-16 Production order planning ...................................................................................................12-17 Production order subcontracting .........................................................................................12-18 Production order material issue ..........................................................................................12-19 Production order costing .....................................................................................................12-21 Production order history ......................................................................................................12-21 Input output monitoring .......................................................................................................12-21

ix | Table of Contents

Order grouping....................................................................................................................12-22 Project Control (PCS) ..............................................................................................................12-23 Repetitive Manufacturing (RPT)...............................................................................................12-23 Assembly Planning ..................................................................................................................12-24

Sales order entry.................................................................................................................12-24 Engineering & product configuration ...................................................................................12-24 Product variants ..................................................................................................................12-25 Master data: line/operation setup........................................................................................12-25 Solved products ..................................................................................................................12-25 Flattened parts ....................................................................................................................12-26 Assembly parts requirements calculation............................................................................12-26 Assembly order generation .................................................................................................12-26 Refresh/freeze assembly orders .........................................................................................12-26 Unit and date effectivity.......................................................................................................12-26

Assembly Control (ASC) ..........................................................................................................12-26 Line station variants ............................................................................................................12-27 Clustered line station orders (CLSO) ..................................................................................12-27 Partial freeze.......................................................................................................................12-27 Multisite assembly...............................................................................................................12-28 Finite scheduling .................................................................................................................12-28 Manual change of the sequence .........................................................................................12-28 Inventory check...................................................................................................................12-28 Work instructions ................................................................................................................12-28 Material supply....................................................................................................................12-29 Time-horizon-driven material supply ...................................................................................12-29 Closed loop .........................................................................................................................12-30

Progress overview per line segment ........................................................................................12-30 Progress overview per buffer ..............................................................................................12-30 Progress overview per line station ......................................................................................12-30

x | Table of Contents

Process triggering ...............................................................................................................12-31 Hours backflush ..................................................................................................................12-31 Line surcharges ..................................................................................................................12-31 WIP transfers ......................................................................................................................12-32 As-built structure .................................................................................................................12-32 Lean system........................................................................................................................12-32 Bar coding...........................................................................................................................12-32 Manufacturing control..........................................................................................................12-32

Tool Requirements Planning (TRP) .........................................................................................12-34 Product Classification (GRT) ...................................................................................................12-35

Chapter 13 Warehousing.............................................................................................................13-1 Introduction ................................................................................................................................13-1 Warehouse master data.............................................................................................................13-2

Introduction ...........................................................................................................................13-2 Warehouses..........................................................................................................................13-2 Items .....................................................................................................................................13-2 Warehouse order procedure .................................................................................................13-3 Miscellaneous .......................................................................................................................13-3

Inventory planning .....................................................................................................................13-4 Introduction ...........................................................................................................................13-4 Planned inventory transaction...............................................................................................13-4 Replenishment ......................................................................................................................13-5 Inventory commitment...........................................................................................................13-5

Inventory Handling.....................................................................................................................13-6 Introduction ...........................................................................................................................13-6 Warehousing orders..............................................................................................................13-6 Cross-docking .......................................................................................................................13-7 Direct Material Supply ...........................................................................................................13-7 Inbound.................................................................................................................................13-7

xi | Table of Contents

Outbound ..............................................................................................................................13-9 Value added services..........................................................................................................13-11 Handling units .....................................................................................................................13-12 Cycle counting ....................................................................................................................13-13 Inventory adjustments .........................................................................................................13-14 Blocking ..............................................................................................................................13-14

Inventory Reporting..................................................................................................................13-14 Introduction .........................................................................................................................13-14 Inventory position................................................................................................................13-14 Inventory transactions.........................................................................................................13-15

Inventory Analysis....................................................................................................................13-15 Lot Control and Serials ............................................................................................................13-16

Introduction .........................................................................................................................13-16 Lot control ...........................................................................................................................13-16 Serials .................................................................................................................................13-16

Consignment stock ..................................................................................................................13-17 Consignment (not owned) ...................................................................................................13-17 Consignment (owned) .........................................................................................................13-17 Service customer owned.....................................................................................................13-17 Consignment replenishment and payment..........................................................................13-18

Chapter 14 Freight Management ................................................................................................14-1 Introduction ................................................................................................................................14-1

Main integration scenarios ....................................................................................................14-2 Freight Master Data (FMD) ........................................................................................................14-4

General freight master data ..................................................................................................14-5 Addresses and items.............................................................................................................14-5 Transportation master data ...................................................................................................14-5 Freight order master data......................................................................................................14-6 Load building (freight planning) master data .........................................................................14-6

xii | Table of Contents

Freight Order Control (FOC) ......................................................................................................14-7 Create/maintain freight orders...............................................................................................14-7 Subcontracting freight orders ................................................................................................14-7 Freight order history..............................................................................................................14-8

Rough Planning (RPG) ..............................................................................................................14-8 Load Building (Planning) (LBD) .................................................................................................14-8

Plans, loads, and shipments .................................................................................................14-9 Graphical planning board ....................................................................................................14-10 History.................................................................................................................................14-10

Freight Rate Control (FRC)......................................................................................................14-10 To calculate freight costs and revenues..............................................................................14-11

Freight Invoicing Control (FRI).................................................................................................14-11

Chapter 15 Service.......................................................................................................................15-1 Introduction ................................................................................................................................15-1 Configuration Control (CFG) ......................................................................................................15-2

Physical breakdown structures and serialized items.............................................................15-2 Item breakdown ....................................................................................................................15-4 Methods adopted in creating configuration structures...........................................................15-5 Grouping, usage and history .................................................................................................15-6

Call Management (CLM)............................................................................................................15-6 Contract Management (CTM) ....................................................................................................15-9

Contract master data...........................................................................................................15-10 Warranties...........................................................................................................................15-10 Contract templates..............................................................................................................15-11 Contract quotations.............................................................................................................15-11 Contract control...................................................................................................................15-12

Subcontract Management (SBM).............................................................................................15-15 Field service.............................................................................................................................15-16

Planning and Concepts (SPC) ............................................................................................15-16

xiii | Table of Contents

Service Order Control (SOC) ..............................................................................................15-17 RMA and Depot Repair............................................................................................................15-24

Maintenance Sales Control (MSC)......................................................................................15-25 Work Order Control (WCS) .................................................................................................15-26

Master Data Management (MDM) ...........................................................................................15-28 Service organization............................................................................................................15-28 Service item data ................................................................................................................15-30 Reference activities and inspection templates ....................................................................15-31 Cost and the coverage types ..............................................................................................15-32 Sundry service related definitions .......................................................................................15-33

Module relationships in SSA ERP Service...............................................................................15-34

Chapter 16 Quality Management ................................................................................................16-1 Introduction ................................................................................................................................16-1 Product Testing and Control ......................................................................................................16-2

Introduction ...........................................................................................................................16-2 Master data ...........................................................................................................................16-5 Algorithm...............................................................................................................................16-7 Quality IDs ............................................................................................................................16-7 Order-specific inspections.....................................................................................................16-8 Standard inspections ..........................................................................................................16-10 Storage inspection ..............................................................................................................16-12 Inspection history ................................................................................................................16-13 Quality Management parameters........................................................................................16-14 Origin ..................................................................................................................................16-14 Series..................................................................................................................................16-15 Blocking reasons.................................................................................................................16-15 Test data .............................................................................................................................16-16

Chapter 17 Object Data Management.........................................................................................17-1

xiv | Table of Contents

Introduction ................................................................................................................................17-1 Overview features of ODM.........................................................................................................17-3 Document Management.............................................................................................................17-4

Introduction ...........................................................................................................................17-4 Libraries ................................................................................................................................17-5 Document type......................................................................................................................17-5 Documents............................................................................................................................17-6 Document revision ................................................................................................................17-6 Files ......................................................................................................................................17-9 Hard copies.........................................................................................................................17-10 Document Management integrations ..................................................................................17-11 Document Management integrations to external applications.............................................17-11 Architecture of Document Management in SSA ERP ODM ................................................17-12

Change Management ..............................................................................................................17-13 Introduction .........................................................................................................................17-13

Change Management Objectives.............................................................................................17-15 Business objectives ............................................................................................................17-15 Functional objectives...........................................................................................................17-16 Change Request .................................................................................................................17-17 Changes..............................................................................................................................17-17 Change proposal.................................................................................................................17-18 Change proposal status ......................................................................................................17-19 Change approval.................................................................................................................17-19 Linking an SSA ERP object to the change proposal ...........................................................17-19 Change orders ....................................................................................................................17-20 Task group ..........................................................................................................................17-21 Tasks ..................................................................................................................................17-21

Folder Management.................................................................................................................17-21 Introduction .........................................................................................................................17-21

xv | Table of Contents

Folders ................................................................................................................................17-22 Queries and Reports................................................................................................................17-23

Introduction .........................................................................................................................17-23 Query ..................................................................................................................................17-25 Query Conditions ................................................................................................................17-25 Reports ...............................................................................................................................17-26

Configuration ...........................................................................................................................17-27 Introduction .........................................................................................................................17-27 Masks..................................................................................................................................17-27 Authorizations .....................................................................................................................17-28 Secondary status ................................................................................................................17-29 Objects and related objects.................................................................................................17-29 Common ODM parameters .................................................................................................17-29 Business rules.....................................................................................................................17-29 Export and import of system data .......................................................................................17-30 Import Files .........................................................................................................................17-30 Integration of SSA ERP ODM with Microsoft Office applications ........................................17-31

Chapter 18 Multisite .....................................................................................................................18-1 Introduction ................................................................................................................................18-1 Multisite environments ...............................................................................................................18-2 Some multi-company terms .......................................................................................................18-3 Enterprise structure modeling ....................................................................................................18-6 Enterprise units..........................................................................................................................18-7 Multicurrency .............................................................................................................................18-9 Intra-logistic-company transactions ...........................................................................................18-9 Data sharing ..............................................................................................................................18-9 Multicompany processing ........................................................................................................18-10 Multicompany Financials..........................................................................................................18-10 Multicompany Enterprise Planning ..........................................................................................18-10

xvi | Table of Contents

Multicompany Manufacturing ...................................................................................................18-10 Multicompany Order Management...........................................................................................18-11 Multicompany Project...............................................................................................................18-11 Multicompany Service..............................................................................................................18-12 Multicompany Warehousing.....................................................................................................18-12

Chapter 19 SSA ERP LN: The technology .................................................................................19-1 Introduction ................................................................................................................................19-1 Architecture................................................................................................................................19-2

Server platform layer.............................................................................................................19-2 Server platform-dependent layer...........................................................................................19-2 Server platform-independent layer ........................................................................................19-3 Client platform-dependent layer ............................................................................................19-4

ERP LN runtime environment ....................................................................................................19-4 Virtual Machine (bshell).........................................................................................................19-4 Database driver.....................................................................................................................19-5 Application Services Manager (ASM)....................................................................................19-6 Platform and database support for SSA ERP LN 6.1............................................................19-6

Internationalization.....................................................................................................................19-7 Multibyte enabling .................................................................................................................19-7 Multi-language ......................................................................................................................19-7 Multicurrency.........................................................................................................................19-9

user interface .............................................................................................................................19-9 SSA WebTop versus SSA Worktop ......................................................................................19-9 SSA WebTop-specific user interface features.....................................................................19-11 Generic user interface features...........................................................................................19-13 SSA Web Help ....................................................................................................................19-17

SSA Integration Pack 2.0 for ERP LN 5/6 – Microsoft Office 2000/XP ....................................19-19 Product Details....................................................................................................................19-20

SSA ERP Connectivity.............................................................................................................19-21

xvii | Table of Contents

Introduction .........................................................................................................................19-21 Business Object Modeling...................................................................................................19-23

SSA ERP Exchange ................................................................................................................19-26 Introduction .........................................................................................................................19-26 Architectural overview.........................................................................................................19-27 Characteristics ....................................................................................................................19-27 Not just data........................................................................................................................19-28 Fast .....................................................................................................................................19-28 Open ...................................................................................................................................19-29 Safe.....................................................................................................................................19-29 Multisite enabled .................................................................................................................19-29 Manageable ........................................................................................................................19-30 Environment-friendly ...........................................................................................................19-30

SSA ERP Application Management .........................................................................................19-31 Job Management ................................................................................................................19-31 Device Management ...........................................................................................................19-31 User Management ..............................................................................................................19-31 Authorization Management System (AMS) .........................................................................19-31 Audit Management..............................................................................................................19-32

SSA ERP Development Environment ......................................................................................19-32 Introduction .........................................................................................................................19-32 3GL and 4GL sessions........................................................................................................19-32 Dynamic forms ....................................................................................................................19-33 Labels .................................................................................................................................19-34 Data Dictionary ...................................................................................................................19-34 Source Configuration Management ....................................................................................19-35 Product Maintenance and Control (PMC) ...........................................................................19-35

Installation and licensing..........................................................................................................19-36 Introduction .........................................................................................................................19-36

xviii | Table of Contents

SSA ERP staging wizard.....................................................................................................19-36 SSA ERP Installer ...............................................................................................................19-38 SSA License Manager (SLM)..............................................................................................19-39 Concurrent user license ......................................................................................................19-40 Named user license ............................................................................................................19-40 Server license .....................................................................................................................19-40 SLM components ................................................................................................................19-40 SLM validation procedure ...................................................................................................19-41 SLM deployment .................................................................................................................19-41

Appendix A Definitions, acronyms, and abbreviations..............................................................A-1

About this Guide

This document is a Functions and Features document that describes the functionality in SSA ERP LN. This document is a technical document focused on functionality, designed to provide a detailed background on how you can use the functionality to streamline business processes.

No detailed knowledge is required to use this document; however, understanding the contents is easier if you are familiar with the overall structure and functions of SSA ERP.

This document contains the following chapters:

Chapter 1, “SSA ERP overview,” provides a general introduction to SSA ERP LN and to this document.

Chapter 2, “Enterprise Modeler,” discusses the Enterprise Modeler functionality in SSA ERP.

Chapter 3, “Production typologies and SSA ERP scenarios,” describes the broad range of production typologies in discrete manufacturing environments that SSA ERP supports.

Chapters 4 through 18 provide a detailed description of the modules and functionality of the various packages in SSA ERP LN.

Chapter 19, “SSA ERP LN Technology,” provides detailed information regarding the technology used in SSA ERP LN.

Appendix A provides a glossary of terms used in both SSA ERP LN and in this document, as well as a list of relevant abbreviations

xx | About this Guide

Send us your comments We continually review and improve our documentation. Any remarks/requests for information concerning this document or topic are appreciated. Please e-mail your comments to [email protected] .

In your e-mail, refer to the document number and title. More specific information will enable us to process feedback efficiently.

mailto:[email protected]?subject=Documentation

mailto:[email protected]?subject=Documentation

SSA ERP LN is a flexible, modular solution for the industrial enterprise with a primary focus on discrete manufacturers. The key strength of SSA ERP LN lies in the comprehensive manufacturing functionality that supports various types of manufacturing, including make to stock, make to order, engineer to order, configure to order, assemble to order individually, or all at the same time. Surrounding this core are modules supporting financials, sales, purchasing, logistics and service functions.

The SSA ERP solutions are proven in many industries. This latest release, SSA ERP LN, extends flexibility and richness in capabilities with efficiency. Many enhancements have been introduced to simplify steps in the execution of business processes, reduce the cost of ownership, simplify implementation, and enable SSA ERP to interoperate with other systems across enterprises.

SSA ERP LN complies with many national and international business practices and legal requirements and supports multiple currencies and languages. It helps to build successful international operations in today’s global environment.

1Chapter 1 Introduction

1-2 | Introduction

Introduction

SSA is unique in offering an integrated product suite that fully supports the typical stages in a business re-engineering cycle. Companies typically re-assess their goals and strategies to enable the company to stay in the driver’s seat and ahead of the competition. As a result, companies must often redesign their organizational (processes and organization charts) and information technology infrastructure.

The SSA Enterprise Modeler provides exactly what is required to compete in the market place: the ability to redirect the processes and IT infrastructure towards the companies’ objective and strategy to stay ahead of the competition.

Although the Enterprise Modeling architecture describes company processes complete and extensive, this does not mean that a customer must go through this time consuming and costly process from scratch. On the contrary, SSA offers an Enterprise model that is designed and geared for almost every business process available in SSA ERP.

In the framework of the Dynamic Enterprise Modeling (DEM) concept, the implementation and the initial setup of SSA ERP is realized by means of the subsequent evaluation of the predefined model.

2Chapter 2 Enterprise Modeler

2-2 | Enterprise Modeler

During this evaluation process, the project teams work constantly and directly towards the target of generating an appropriate process and user interface (process-oriented) and parameter settings of the SSA ERP solution, which effectively supports the business processes.

The key message concerning these models is that best-practice vision and experiences of both SSA consultants and partners are captured in the predefined model, which serves as a catalyst in the creative and innovative process of BPR.

Using SSA ERP Enterprise Modeler and dedicated model, the effort and time required for this evaluation process is reduced significantly. Therefore, companies will not hesitate to reassess their SSA ERP implementation, when required, and without the necessity for a costly and time-consuming re-implementation. This provides the flexibility and speed companies are looking for to follow the business dynamics with the IT infrastructure.

In short, the Enterprise Modeler provides the following:

Business model geared towards strategic issues relevant in the business. This model provides visions, best practices, and experiences of experts, which will trigger the creative process of strategic planning.

Business modeling tools for designing the to-be process definitions, as well as the ways these processes are managed and monitored.

This modeling is supported on several levels of detail: multi-site modeling, business control modeling, business function modeling, process modeling, and business organization modeling.

The to-be processes are finally mapped on the SSA ERP application. In this way, an implementation model is generated that fully supports the companies’ strategy and derived process designs, and which is used at runtime.

You can use the Enterprise Modeler as a business process redesign tool and as a training tool.

Enterprise Modeler | 2-3

Because Business Modeling requires several levels of detail, the following three layers are defined:

Enterprise Structure Model

Main Process FlowsBusiness Function Model

Business Control Models

Bus. Organization Model

Level 1: Enterprise Structure Model

On a company level, the supply chain must be identified and modeled in the Enterprise Structure model. Players in the supply chain are called Enterprise Units, examples of which include:

Customers

Sales offices

Distribution centers

Assembly sites

Manufacturing sites

Suppliers

Central planning/purchasing sites


The Enterprise structure model:

Between Enterprise Units, various types of relationships exist in terms of order flows, goods flows, and money flows, and information flows on several strategic levels, including operational, tactical, and strategic levels.

The primary objective of the Enterprise Structure Model is to define a multi-site managerial model from both a financial perspective and a logistic perspective. Typical questions are:

What does the company consider to be one financial unit with bottom-line responsibilities, for example, a business unit?

What does the company consider to be one logistic unit that will be managed and controlled by means of Manufacturing Resource Planning (MRPII) concepts?

In SSA ERP, multi-site concepts provide the flexibility to define financial and logistic unit independently. The key element in the definition of this managerial model is the Enterprise Unit. By definition, an Enterprise Unit belongs to one logistic company and also one financial company and is, therefore, a building block for multi-site definitions. An Enterprise Unit represents more of a logical view on a company than a physical view.


Level 2: Business Control Model

At an Enterprise Unit level, order and goods flows are planned, managed, and executed. A Business Control Model (BCM) defines on a high conceptual level how the enterprise unit manages processes to realize the companies’ objectives. A BCM shows the following:

The company’s primary industrial processes.

The logistics characteristics of these primary processes. In other words, the part of the processes that is planning-driven, and the part that is customer-order driven, and so on.

The management and control mechanisms available to manage throughput time, quality, and, costs.

This model serves to identify the needed process control cycles to guarantee the fulfillment of the companies’ objective with respect to throughput times, quality, and costs.

The Business Control Model:


Level 3: Business Functions, Processes, and Organization diagram

On the third level, identified processes are designed in detail. The work is defined in detail and process steps are linked to the SSA ERP application. On this level, the following three sub-models are designed:

Business Function Model (BF): This model represents processes as nodes, and shows options and variants. This model provides a structured way to go through implementation decisions with respect to alternative methods to configure the workflow processes and ERP configuration, such as desktop and parameters.

Business Function Variants

Optimization Relationship

Text linked to Bus. Process

Company

Mega/MajorFunction

MainFunction

Business Function options

ABC

Business Process Model (BP):

This model defines the precise definition of the processes, and also defines where and when the appropriate SSA ERP functionality must be invoked (mapping of ERP functionality to process definition). This model also defines the work instructions on the process and process-step level, as well as roles required for authorization.


Business Organization Model: This model, the organization chart of a company, is defined in terms of business units, departments and groups. Roles are designed as responsibilities for processes or part of a process. These roles are subsequently assigned to both users/user groups and processes/process steps. In this way, the processes are mapped to the company’s organization chart.

OrganizationalUnit

StaffDepartment

Text byOrganizationalUnit Text linked

to Org. UnitUnit

Subdiagram

- Salesman- Purchaser- ...- ...

Roles by Organizational Unit

FunctionalRelationship


Business Data Model – Entity Relationship Model (ERD)

So far, the emphasis of the Enterprise Modeler was on process modeling rather than on data modeling. This makes sense because companies’ objectives and strategies are realized by people and processes and not by data. However, data is an important source for processes. Therefore, in SSA ERP, the Enterprise Modeler is extended with entity relationship models. These models serve the following purposes:

Document the logical and physical data structure of the SSA ERP applications.

Disclose the data model part that is affected by the processes and SSA ERP sessions.

Support the IT/EDP staff in activities, such as data conversion and customizations.

In addition, these models also support process teams during re-engineering by opening the application box for a better understanding of the application strengths (IT as enabler).

The Data Model:


Functionality

Enterprise Structure Modeling in SSA ERP

In SSA ERP, the Enterprise Structure model is built in an intuitive way. The managerial model is designed on a map. From a library, the user can select an icon that will represent the Enterprise Unit. The next step in the modeling process is to identify relations between the Enterprise Units. You can model the following relations:

Order flow

Goods flow

Cash flow

Information flow

You can model the various types of flows for each view of the Enterprise Structure Model. For each Enterprise Unit, you must define a number of types of data, such as:

Name and description

Logistic company

Financial company

Reference model

Quantitative data, such as volumes and frequencies

When the Enterprise Units are fully determined and characterized, expert rules will be evaluated, which are stored in the SSA ERP Enterprise Modeler Repository.

The decision made in the Enterprise structure model will be translated into consequences for the interfacing processes within an Enterprise Unit. These consequences can include:

Selection of processes

Configuration of these processes

Parameter settings

After you define the Enterprise Structure Model, the mapping on the SSA ERP application architecture is carried out.


Business Control Model

A Business Control Model (BCM) defines, on a high conceptual level, how the order and goods flows within an Enterprise Unit are managed and controlled. In SSA ERP, the Business Control Model forms an integral part of the business process models, and is one of the primary deliverables of a model development project. In theory, a Business Control Model models a hierarchy of process control measures for managing the primary processes, therefore, objectives/strategies, of a company.

A BCM characterizes an Enterprise Unit in terms of the following:

Primary process (routing)

Customer order decoupling point

Management and control on production unit level

Management and control on logistic level (total goods flow)

Management and control on aggregated level (objectives and policy definition)

In the Business Control Model, process control cycles are identified, which must be put in place to manage and control the primary process towards the companies objectives, such as throughput time, quality and costs, and so on.


FINAL ASSEMBLY

Assembly control

Sales Order

ReleasedFAS Order

Goods issueProcessControlCycle

For each process control cycle, one or more main-process flows (flow definitions in Petri-net, mapped on the SSA ERP Applications) are designed.

You must consider the Business Control Model, and the model’s process control cycles, as a context diagram that shows the business context of processes. In this way, the high-level conceptual model is linked to a more detailed and practical implementation model. For each process control cycle, the following elements are documented:

Case definition: Clear and unambiguous description of the job to be handled in the business process.

Start event: Which events trigger this process?

End event: What is the resulting event generated by the process?

Main-process identification: Link to the main-process definition elaborated in Petri-net and mapped on the SSA ERP application, which must handle the case.

Supporting processes: Link to supporting processes, such as master data setup and so on.

Business Function Model

The Business Function Model is a functional decomposition of a company up to the level of the main-functions. This model serves as a structured implementation agenda that covers the following:

Best-practices business knowledge recorded by experienced consultants.

Guide to support the dialogue between management and consultants during visioning workshops and implementation-scope definition.


Main-process selection and configuration (alternative routings in main-process)

The Business Function Model includes the following characteristics:

Business functions are displayed as nodes in a tree diagram through which the user can navigate.

Business functions can have texts linked to them in which the characteristics of a particular business function are described.

Business function variants can have optimization relationships, through which you can indicate that these business functions can be implemented in phases. Optimization relationships can be linked to texts in which the organizational aspects of the optimization of processes are described.

Business function variants combined with optimization relationships can have implementation phases linked to them in a project business function model.

Link to business function/process model

Before you actually design the process steps, best practices, options, and variants that are built into the process definitions, various alternative methods are available to exploit the SSA ERP functionality in the processes, which are built-in as alternative routings through the main processes. A customer must decide on which alternative is appropriate to the customer’s actual situation.

The main-process is represented in the function model as a main-function. Options and variants are presented under the main-functions as implementation decisions.

The implementation decisions for each process control cycle are made in the function model.


Link to business function / Process model:

Main Process Flow

Select Processes

Static Conditions

What How

Wizards:• Parameters• Master Data

Main Function

Mega/MajorFunction

Company

ProcessOptimization

ImplementationWizards

• One main-process per workflow case• Represented by one main-function in function model

Business Process Model

The business process model defines how the process control cycle is realized by defining activities that must be run. These business process flow definitions are projected on the SSA ERP functionality. Therefore, on the lowest level of the process definition, SSA ERP sessions are modeled. This can be seen as a real paradigm shift.

In the past, consultants used to present the ERP package module by module, showing the richness of the provided functionality. Now, the business process is leading. Discussing the process definition with the key-users, the appropriate functionality is showed at the right time and the right place with an emphasis on what the functionality does. The business process model serves the following purposes:

The process definitions describe how the business functions, therefore, the process control cycle, are realized.

The processes form the perfect vehicle for describing the SSA ERP functionality and, even more importantly, what SSA can do for the customer’s business.

The processes form a starting point for generating the user environment.

To document administrative procedures (ISO9000), which results in owners for each activity, roles, authorizations, and job instructions.


The business process model includes the following characteristics:

A business process consists of a number of components, namely states, activities, and controls. Each activity is preceded and followed by a state. An activity can be an SSA ERP session, a non-SSA application, a manual activity, or a (nested) business process.

You can model business processes according to the Petri-net formalism. The components, as well as a number of constructions that can be used for Petri-net modeling, are described extensively in the Dynamic Enterprise Modeling Manual.

You can link job instructions, AO documents, and utility codes to activities. Job instructions can contain specific help information for a session within a particular business process. From within an activity, you can refer to an AO document that is created in that activity. Utility codes are clusters of sessions that can be used as auxiliary sessions, such as display sessions and print sessions, during the execution of an activity.

You can use a graphical display of a business process as a user interface rather than a menu structure.

You can link roles and employees to business process activities.

Business Organization Model

The Business Organization Model describes the structure of the organization in terms of division, business units, and departments. A key concept in this is the identification of roles in the company. A role defines which activities/tasks in the process execution are usually assigned to one person or group. In addition, the hierarchical and functional relationships can be described between the departments.

Business Data Model - Entity Relationship Models (ERM)

The graphical data model editor enables the user to edit an Entity Relationship logical data model to create a new conceptual database design or document in an existing one. Entity Relationship diagramming is used for modeling in compliance with the James Martin notation standards for information engineering, that is:

1:1 A one-to-one relationship.

1:n A one-to-many relationship.


n:m A many-to-many relationship.

Optional Signifies that a relationship does not always exist.

The ERM Model can be defined at various abstraction levels:

Data cluster: Clusters a number of logical entities.

Logical entity: Entities relevant to the real world and that are comprised of several physical entities.

Physical entity: Database table definitions of the SSA ERP application.

SSA ERP supports a broad range of production typologies in discrete manufacturing environments, including the following:

Job shop

Production cell

Flow

A production typology is characterized by the type and volume of products produced, in combination with the layout of the factory and the material flow, as depicted in the following figure:

Many Products

Few of Each

Many ProductsMedium Volume

Several Products

High Volume

One ProductVery HighVolume

FunctionalLay-out

Job-shop

CellularLay-out

ProductionCell

Repetitive Paced Line Flow

FlowContinuous

Flow

Products & Volume

Lay-

out &

Mat

eria

l Flo

w

In a production typology, various manufacturing strategies are followed. In a job shop environment, you can distinguish between anonymous production to stock and production to customer order.

3Chapter 3 Production typologies and SSA ERP scenarios

3-2 | Production typologies and SSA ERP scenarios

In a flow environment, you can distinguish between anonymous multi-model production, and mixed-model production to customer order, as depicted in the following figure:

Manufacturing Strategies

Product - Standardization

Pro

cess

-St

anda

rdiz

atio

n

High Low

High

Functional lay-out

Flow lay-out

StandardProduction in

Job Shop

Customer SpecProduction in

Job Shop

StandardProduction inMulti ModelFlow Line

Customer SpecProduction in

Mix ModelFlow Line

Low

3

1 2

4

Manufacturing Strategy 1: Standard production in job shop

This strategy contains the following main characteristics:

Low volume production of standard products

High variability of routing

Shop floor control with work-orders

In this situation, the products are sold and delivered from stock. Stock must be replenished regularly and several mechanisms can be used to trigger production and purchase. For some products, only the stock level (SIC) can control the replenishment, and some products require extra planning and forecasting (MPS, MRP). Production is organized around work centers that operate relatively independently. During production, each product can follow a different route through the factory. Production planning must bring about a balance between workload planning on work centers, order lead times, and inventory levels.

Production typologies and SSA ERP scenarios | 3-3

Manufacturing Strategy 2: Customer-specific production in job shop

This strategy has the following main characteristics:

Low volume production of standard products (STO), configured products from generic items (MTO/CTO, options and features), or fully customized items (ETO).

High variability of routing.

Shop floor control with work-orders, Project-controlled custom engineering, and manufacturing processes.

In this situation, products are produced to customer order. No stock of end items is available, but stock can be present for component items and intermediate products. The products can be fully customized to customer requirements (engineer to order), configured from generic items, based on features and options, or standard used (make to order). Although the products are produced to order, you can often achieve results that are more favorable if you plan and forecast end-item production. From these forecasts, production and purchase plans for component items and intermediate products can be derived.

Production is organized around work centers that operate relatively independently. During production, each product might follow a different route through the factory. Production planning must balance workloads on work centers, coordinate the production and purchase of component’s end items, and deliver the end products on the agreed date. In the engineer-to-order situation, delivery times can be long and a considerable portion of the total cost is operations cost or cost for other activities such as engineering. In the make-to-order situation, delivery times are generally shorter and materials comprise a higher percentage of the total cost.

Manufacturing Strategy 3: Standard production in multimodel flow line

This strategy has the following characteristics:

High volume production of standard products

Low variability of routing within batch

Shop floor control with production schedules

The products are sold and delivered from stock. Stock must be replenished regularly and several mechanisms can be used to trigger production and purchase.


Replenishment of some products can be controlled only by the stock level (SIC), while other products require extra planning and forecasting (MPS and MRP). Production is organized around production lines. A line is a work center or a set of work centers that can be physically connected, but that connection is not a necessity. A product that enters the line must pass all work centers on that line. A line has a rate, and production time is constant in every work center. In a multimodel flow, standard items are produced in order of varying quantities and various cycle times. Between products, the line rate can differ and possibly change over time, depending on the sequence of the items. Production planning must balance inventory levels, order quantities, and changeover time.

Manufacturing Strategy 4: Customer-specific production in mixed-model flow line

This strategy has the following characteristics:

High-volume production of customer-specific products

High level of product and process conformity enables production in line.

Line assembly control with sequencing and line station variants

Products are produced to customer order. No stock of end items exists, but stock for component items and intermediate products can be present. The products are customer-specific but are based on a predefined product model with features and options. Although the products are produced to order, plan and forecast end-item production might be desirable. From these forecasts, production and purchase plans for component items and intermediate products can be derived. Production is organized around production lines. A line is a work center or a set of work centers that can be physically connected, but this connection is not a necessity.

A product that enters the line must pass all work centers on that line. A line has a constant rate per period and production time is constant in every work center on that line. Several lines can be connected, one line feeding into the other. In a mix-model flow, an order usually consists of one product, and no two products are the same. Depending on the product options, the required production tasks are determined. Production planning must coordinate the sequence in which orders are put on the lines by balancing the characteristics of production tasks and the product options. The total cost of the item consists mainly of materials cost. A strong incentive is present to shorten delivery times.


Mapping the Manufacturing Strategies to SSA ERP LN 6.1

When you map the SSA ERP LN 6.1 key manufacturing functionality, you see that the SSA software covers the entire spectrum of the production typologies and manufacturing strategies:

SSA ERP LN 6.1 Manufacturing Solutions

Product - Standardization

Proc

ess

Stan

dard

izat

ion

High Low

High

Low

SFC SFC/PCS

LES

RPT ASC

Project

RPT is the Repetitive Manufacturing module in SSA ERP LN 6.1

Manufacturing, which supports multimodel flow line environments.

ASC is the Assembly Control module in the SSA ERP LN 6.1 Manufacturing, which supports supporting mixed-model flow line environments.

LES is the SSA ERP LN 6.1 Lean Execution System, which supports production cell environments with lean manufacturing concepts.

SFC is the Shop Floor Control module in SSA ERP LN 6.1 Manufacturing, which supports standard and customer-specific production in job shop environments.

PCS is the Project Control System in SSA ERP LN 6.1 Manufacturing, which supports tracking and costing for customer-specific production in job shop environments.

Project is the SSA ERP LN 6.1 Project, which supports one-time, customer-specific projects.


Hybrid Manufacturing

SSA ERP LN 6.1 supports hybrid manufacturing, which means that, in the multilevel bill of material, intermediate products can be produced by a manufacturing strategy that differs from the strategy for end products. In short, different manufacturing strategies can be used for different items. The following figure shows various scenarios to set up the production environment in SSA ERP LN 6.1:

Assemblybased

SFCbased

Leanbased

LeanProcurement

KANBANFor End Prod.

SFC orderFor End Prod.

Assembly OrderFor End Prod.

Lean

SFCASC

Lean

SFC

SFC

Lean

Lean

Repetitivebased

RPT scheduleFor End Prod.

Lean

SFC

SFC

SSA ERP LN 6.1 Scenarios

Of course, the packages and modules mentioned previously are simply the key manufacturing software components that can best be utilized for each manufacturing strategy. SSA ERP LN 6.1 fully supports the other major business functions, such as sales, purchasing, planning, warehousing, service, freight, and Financials, and creates a complete business flow for each environment. The following scenario is a business flow scenario in SSA ERP LN 6.1 for each manufacturing strategy.


Scenario for Manufacturing Strategy 1: Standard production in job shop

Products are forecasted in Enterprise Planning (EP). The forecast in combination with the desired safety stock level serve as input for the material and capacity requirements planning, performed by means of the order planning in EP. The production, purchase, and distribution advices are transferred to the shop floor, the purchase department, and the warehouse.

The production order in Shop Floor Control is checked for capacity and material availability, and the order sequence is determined to level the workload. Subsequently, the order is executed and reported complete in SFC, after which the end product is put on stock.

In addition, materials and hours are posted on the production order. When sales orders for the standard item come in, the forecast is consumed in EP and the product is delivered from stock to the customer. The costs for producing the standard item are only captured for each production order, not for each item. The following figure illustrates this scenario:

Scenario for Standard Production in Job Shop

Sales Order - Forecast

Production Orders

SFC -> Execution

SFC

MRP / Cap planning

Scheduler Seq. /Capacity


Scenario for Manufacturing Strategy 2: Customer-specific production in job shop

In make-to-order, configure-to-order, and engineer-to-order environments, the trigger for production activities is the sales order. However, in all situations, you can use forecasting in EP to produce or purchase components beforehand, which reduces the delivery lead-time for the customer.

The incoming sales order consumes the forecast and the components that were produced or purchased to stock.

In make-to-order and engineer-to-order situations, you can use a product template during sales order entry that will be copied to a PCS project, based on the sales order. In configure to order, the product is configured during sales order entry and the resulting product variant is created by means of the Product Configurator (PCF).

Based on the sales order product template or product variant, the PCS project is generated, which enables cost control and tracking for customer-specific products. If necessary, you can make engineering changes on the product under the PCS project. Subsequently, Enterprise Planning performs the order planning for the customer-specific items under the PCS project and for the standard components that might be required, particularly in make-to-order and configure-to-order. These standard components might already be on stock if forecasting is used.

The resulting advices are transferred to the shop floor, the purchase department, and the warehouse. All production orders are executed in SFC, however the orders for the customer-specific items are directly related to the PCS project.

The progress and the costs of the production orders can, therefore, be tracked on the PCS project, which gives the exact information on the costs of each product and whether delivery times are met.

In engineer-to-order environments, in which one-of-a-kind products are engineered in cooperation with the customer, SSA ERP LN 6.1 Project is a valuable tool to budget, estimate, and control costs and lead times on these complex customer-specific projects. The trigger for production activities is the project budget that states, among other things, the materials and hours required on each stage of the project.


The materials budget creates customer-specific demand for the order planning, which is performed in Project. You can also connect a PCS project to the large project to manufacture the customer-specific parts.

In addition, standard components might also be required. Both are planned by means of the order planning in Enterprise Planning.

The advices from EP are transferred to Shop Floor Control, where the production orders for both the PCS project and the standard components are executed.

When production is complete, the products are transferred to the large Project to supply the requirements from the budget. The costs are aggregated to the large Project, and are also still visible on the PCS project.

The following figure depicts both of the two previously depicted scenarios:

Scenarios for customer specific production in job shop

Sales Order - (Forecast)

Production Orders

SFC -> Execution

PCS

Project planning -MRP

Scheduler Seq./Capacity

Budget

Production Orders

SFC -> Execution

Project

Project planning -MRP

Scheduler Seq /Capacity

Project

PCS project

Scenario for Manufacturing Strategy 3: Standard production in multimodel flow line

The production lines are planned based on forecast quantities in Enterprise Planning (EP). The resulting production advices are organized in a repetitive production schedule, which is a list of quantities to produce per time frame, for example, daily or weekly schedules.


The production line produces rate based, therefore the production advices in EP are adapted to this rate. The rate is determined by means of the bottleneck workstation on the production line. When sales orders come in for the repetitive items, the forecast in EP is consumed.

The sequence of the items to be produced on a production line can be changed from the schedule. The execution and progress of the production schedule can be monitored for each production line. Completion of quantities is reported from the schedule and materials and hours are backflushed, which enables minimal interaction for the operator with SSA ERP LN 6.1.

The following figure depicts this scenario.

Scenario for standard production in multi-model flow line


Repetitive Schedule

RPT -> Execution

RPT

Mixing / Cap planning

Sequencing / Capacity

Scenarios for Manufacturing Strategy 4: Customer-specific production in mixed-model flow line

The Lean Execution System (LES) is suited for both multimodel and mixed-model environments for less-complex products in which lean concepts such as KANBAN and production cells are fully integrated in the production organization.

Forecasting on the end products is performed in Enterprise Planning. The LES explodes the forecast through the bill of materials and create Kanbans for production and purchase. Capacity planning is performed by means of graphical boards where the loads on the production cells can be leveled.

The Kanbans can be placed in the correct sequence and reported complete in LES.


Assembly Control (ASC) is suited for mixed-model environments where complex production variants are produced on assembly lines. The production speed of the lines is determined by the task time of the line, which can vary by time period, for example, on hourly or daily basis. A sales order is the trigger for starting production activities on the line. The configuration of the product variant is assumed to be performed in an external system and the resulting customer-specific bill of material is then loaded to ASC. An alternative is to use unit effectivity to directly configure from the sales order.

Based on the product variants, the assembly planning engine calculates the requirements for the assembly components and transfers the components to Enterprise Planning, where the order planning will create the necessary advices for production, purchase, or distribution.

Based on the sales orders, the assembly orders are created in Assembly Control. Then, the mixing process determines which orders are to be produced on a particular day, based on the assembly line capacity. Based on the mixing result, the orders are sequenced in each day. Subsequently, execution and progress monitoring is performed in ASC. The material supply of is based on triggers coming from the assembly line. Costs for materials and hours are accounted for by means of backflushing. The costs can be posted and retrieved on assembly-order level or on assembly-line level.

Scenarios for customer specific production in mixed-model flow line

Sales Order

Assembly Orders

ASC -> Execution

ASC

Mixing / Sequencing


KANBAN

LES -> Execution

LES

Parts req. planning


Of course, the scenarios described in this chapter for all manufacturing strategies are not fixed. Rather, these scenarios represent a common way of working according to best practices. Various scenarios are, however, supported for each strategy to create optimum fit to customer-specific processes.

Introduction

SSA ERP Common provides quick access to data that is shared throughout the SSA ERP applications.

Calendars

Calendars define the working hours for resources in the company, such as work centers, employees, warehouses, purchase offices, and sales offices. The calendars are used for to determine lead times and start and end dates for activities that are carried out in a company, such as production, purchasing, warehousing, service and maintenance, and project activities.

You can also define calendars on higher levels, such as enterprise unit and company level. When you plan a resource, the calendar on the most detailed level will be selected. If the calendar is not found on this level, for example, on the resource itself, the calendar on a higher level will be used, for example, on company level.

For easy calendar definition, you can define parent – child calendar structures through which a calendar on a lower level inherits the working hours of the parent.

4Chapter 4 Common

4-2 | Common

This enables you to only define the exceptions on the lower levels, for example, the holiday of an employee. The other working hours are simply inherited from the work center the employee works in. In addition, you can define an exception as a recurrence.

For example, the work center is not available on Monday morning every three weeks due to maintenance.

You can also split the calendar of a resource based on the activity for which the resource is used. If an employee is deployed both for manufacturing and service, the calendar can be divided in manufacturing hours and service hours. When planning a service order, only the service hours in the calendar of the employee are considered as available hours.

The simplest calendar you can define is a standard calendar representing a general workweek with available hours per working day. These working hours are then valid for the entire period of a calendar.

Unit effectivity

The unit effectivity functionality provides the possibility to define multiple occurrences, called units, for one item without the need to define multiple item codes.

Usually, a unit identifies an exception to one standard configuration. A great deal of item-related data can be included or excluded in a unit, which is managed by means of so-called exceptions.

A unit is a system-generated number, and also consists of a user-defined series and sequence number.

Common | 4-3

Unit effective data

Exceptions can be linked to the data described in the following list. As a result, this data is unit effective. Depending on the unit of the end item, the data that is effective for that unit will be used.

Engineering BOM lines: You can link a unit of an end item to E-BOM lines at multiple lower levels.

Bill of material: Also multi-level unit effectivity.

Routings

Routing operations

Sourcing strategies

Item purchased business partners

Operation assignments: Assembly Planning module

Generic Bill of Material: Assembly Planning module

Flattened Assembly Parts and Operations: Assembly Planning module

Requirements

You can group together multiple units in a so-called requirement. You can then also link this requirement to unit-effective data, such as BOM line and routing. In this way, you can assign multiple units simultaneously.

Conceptually, a requirement stands for a property of the unit. A unit can have multiple properties. For every property of the end item, some data can be included or excluded.

Example: The requirements [2.6 GHz] and [120 GB] are defined. Unit 1 is linked to [2.6 GHz]. Unit 2 is linked to both requirements and Unit 3 is only linked to requirement [120 GB].

The standard BOM of PC PC001 consists of a 2.4 GHz processor and an 80 GB hard disk. To sell and produce a different configuration, you can select one of the units for PC001.

4-4 | Common

The following figure displays the requirements to BOM lines:

PC001

80 GBHard disk

120 GBHard disk

2.6 GHzProcessor

2.4 GHzProcessor

120 GB(units 1,2)

2.6 GHz(units 2,3)

Requirement

Requirement

Units 1,2,3

Valid

Valid

Not Valid

Not Valid

This picture learns that, for example, Unit 2 consists of the BOM lines 120GB hard disk and 2.6 GHz processor.

Units and sales order entry

During sales order entry, you can select one existing unit. You can also configure a new unique unit. During this process, requirements are assigned to the new unit code.

Units in inventory

Items that are selected for a specific unit can keep the unit information during storage in inventory. This unit code is linked to a lot number that in turn is linked to the inventory information of the item. Referring to this example: Inventory of the 2.6 GHz processor can be distinguished for each unit of PC001.

Pegging

If a unique unit is configured for every sales order, you can use the unit as a peg to that sales order.

Common | 4-5

Cost price calculation

The standard cost price is based on the standard configuration of the unit effective product. You can perform an estimated cost price calculation. If you use the inventory valuation method lot pricing and actual costing, the actual costs can be calculated per unit, as well.

Item base data

You define the characteristics of an item in the item base data. You can indicate general characteristics such as the item type. An item can be of type Manufactured, Purchased, Generic, Cost, Service, Subcontracting, List, or Engineering module. You can also predefine the choice between manufactured and purchased to support, for example, temporary external purchasing. In addition to the item type, you can indicate if the item is lot controlled, serialized, unit effective, and/or revision controlled.

In addition to the general characteristics, you can also set ordering and costing-specific item parameters. Item ordering data indicates, for example, the order policy (to order or anonymous), the order system (supply mechanism, for example, planned or SIC), and the order method (lot size rule) of the item.

The item costing data indicates the standard cost price of the item. All other specific item parameters can be defined in the package to which the parameters functionally belong.

By means of default, you can also predefine the characteristics. In this way, you can quickly create items and then change the exceptions to the defaults.

If you defined the characteristics of the item, you can indicate if the item has alternative items that are interchangeable and if the item has alternative item codes, used by customers and/or suppliers.

4-6 | Common

Business partners

Suppliers and customers are defined in SSA ERP as business partners, because today’s business extends beyond simple straightforward supplier – customer relationships. Therefore, you can define both supplier and customer roles for a business partner. In addition, common practice is that a supplier uses, for example, an external party to ship the goods to your company, and the invoice can be sent from a central office. For this reason, you can distinguish various roles for each business partner. This business partner or another business partner can carry out a role. These features enable you to define a network of business partners that you deal with to purchase or sell products.

You can define affiliated business partner when a supplier – customer relationship exists between your site and another site that belongs to the same company. This function supports purchase – sales between the sites, both for the logistic and financial flow between two logistical SSA ERP companies.

When you define supplier – customer relationships between sites within one logistical company by using enterprise units, you can use internal business partners to support both the logistic and financial flow between the sites.

Taxation

SSA ERP LN supports value added tax, sales and use tax and withholding of income tax and social contribution. Tax calculation is based on a flexible rule based tax model in which a set of standard tax rules are supported. Together with user definable exceptions and exemptions every tax situation can be modelled. In addition to the standard sales and use tax functionality, an interface with Vertex O Series is available for advanced US and Canadian tax calculation.

A comprehensive set of standard and user definable tax reports are available for analysis and declaration. Submitted tax declarations can be paid to the appropriate collection offices through the regular payment process.

Next to tax reporting, also European sales listing and European intrastat reporting are available.

Introduction

You can use SSA ERP People in a fully integrated SSA environment or as a stand-alone time registration system. SSA ERP People supports the needs of organizations to capture time and expenses as spent by employees from business units operating in different environments. SSA ERP People provides flexible entry screens for business units in Manufacturing, Project, and Service environments.

This chapter describes the functions and features of the following modules:

Master Data Management (MDM)

Time Management (TMM)


The Master Data Management (MDM) module forms the basis of the SSA ERP People application. The MDM module enables you to register relevant employee information, as well as codes to be used for general hours and expenses. All this in addition to the information on roles, skills, rates and surcharges that are part of the People (PPL) module as part of Common.

5Chapter 5 People

5-2 | People

The information on the employee to be captured by means of Employees – People is crucial to be able to record time and expenses. This is because the data helps to establish whether or not an employee is still being employed (first and last date of employment), is internal or external, the number of employment hours, and so on.

The general task and expense codes are to be used as part of hours and expense accounting. The standard codes for tasks and expenses can be related to departments. If so, this department will be defaulted while recording tasks and expenses. If no (default) department has been indicated the department from the employee will be defaulted while recording tasks and expenses.

Tasks are differentiated in two types: absence and indirect.

The MDM module also enables you to capture assignments. These assignments are planned allocations of time that you can use to speed up the hours registration process by loading the assignments on your timesheet. This way you could for example, define a recurrent meeting to show on your timesheet.

User profiles cater to the need to be able to preset several settings, for example, what time period to default while starting the hours-entry screen.

The Employees Dashboard enables employee administrators to handle the following two procedures:

Check and maintain data on employees

Check and, if necessary, maintain hours and expenses

Time Management (TMM)

You can use the Time Management (TMM) module to record and budget hours worked by employees. This module has three basic functions:

Budgeting

Hours Registration

Hours and Expense History.

People | 5-3

Budgeting

Entering hourly budgets is an optional function. However, you can use this method to compare budgeted hours to actual hours. You can enter the hourly budgets by department, by team, and/or by employee.

Features are available to create budget based on the calendar or to copy from another entity.

Hours registration

The hours-registration functions uses separate entry screens for various transaction types. Different needs justify the use of different screens. Using icons and shortcuts, you can easily switch types. The transaction types are the following:

General Tasks

Project

PCS Project

Production

Assembly

(Field) Service

Depot Repair:

Some specific aspects for Manufacturing to be mentioned are:

Machine Time: For Manufacturing-related types besides employee time, also machine time can be captured.

Backflushing. The automatic accounting of hours spent based on the theoretical usage and the quantity of the item reported complete.

Transaction Status. A line can be active, interrupted, or closed. This is relevant if direct time recording is being used, where online employees will record that they have started or finished a specific task.

To cater for General and Project expenses, a specific entry screen is provided in addition to the entry available for General and Project hours.

5-4 | People

All entry sessions enable you to register time by employee. An alternative for recording time by employee is the registration by team. After the team hours have been recorded, the hours can be distributed, in other words, copied to all employees in the team.

Other features available as part of the registration include the following:

Use of Assignments: You can use planned allocation of time-recorded assignment as input for the hours-registration process. Of course, you can still make changes.

Copy Hours and Expenses: Extensive copy options enable you to copy transactions for one employee to several others or to other time periods.

Global Registration: Global registration is best suited to take care of dealing with time spent as relevant for a wider range of employees, for example public holidays.

The following figure shows a brief recap:

The purpose of hours-registration is most likely the computation of labor costs by employee. Processing the transactions results in calculation of:

Rates

Surcharges

The labor costs by employee will be posted to:

Respective logistical packages

Financials

People | 5-5

The following two options are available to perform processing:

Batch processing

Direct processing

Direct processing does not require approval or separate trigger to process hours recorded. The processing will be performed while closing a registration session, or using the shortcut on the Specific menu. Because processing must be carried out, the session will take longer to finish.

Registration and processing are part of the normal flow. Whether or not approval of transactions is required depends on parameter settings.

Using working time schedules, you can split one line recorded into several lines. A working time schedule is a prerequisite for overtime calculation. The number of hours, entered as one line will be split while saving the record according to the working time schedule. As much as possible, hours will be placed on normal hours.

Note: You cannot use working time schedules for general and project hours, because these hours do not use exact time while recording time spent.

History

The history is based on employee and transaction origin and enables you to view the following:

Hours

Labor costs

Various surcharges

An Archive and Delete option is provided.

5-6 | People

Introduction

SSA ERP Financials can be used in a fully integrated SSA environment or as a stand-alone financial system. SSA ERP Financials supports the needs of organizations consisting of multiple companies or business units operating in different environments. SSA ERP Financials provides flexible account structures for recording, analyzing, and monitoring the activities of each company or business unit.

This chapter describes the functions and features of the following modules:

General Ledger (GLD)

Accounts Receivable (ACR)

Accounts Payable (ACP)

Cash Management (CMG)

Financial Budget System (FBS)

Cost Accounting (CAT)

Fixed Assets Management (FAM)

Financial Statements (FST)

6Chapter 6 Financials

6-2 | Financials

General Ledger (GLD)

The General Ledger (GLD) module forms the heart of the SSA ERP Financials application. This module accounts for all transactions in SSA ERP that have an accounting impact.

Currency system

SSA ERP offers a Euro compliant multi currency system with up to three base currencies and an unlimited number of transaction currencies. For high inflation countries an ‘independent’ multi currency system is available.

Currency differences and exchange gains and losses are automatically calculated and posted.

Company structure

Financial companies can be consolidated into a parent company. Companies linked to the same parent can have different base currencies as long as there is one joint base currency.

Multiple financial companies can be linked to (entities from) one logistic company allowing cross border logistic operations. Intercompany transactions are automatically created.

General ledger structure

SSA ERP Financials offers a flexible structure with user definable ledger accounts and five dimensions. Parent child structures can be built for both ledger accounts (100 levels) and dimensions (10 levels). Basic dual GAAP features are provided through the option to define a second ledger account structure.

Usage of ledger accounts and dimension can be restricted by setting a specific valid data range, by blocking them for manual entry or by blocking them for all purposes. For a ledger account a range of valid dimensions can defined.

SSA ERP Financials offers user definable financial calendars for statutory, management and tax reporting.

Financials | 6-3

Financial integration transaction mapping

SSA ERP Financials offers extensive options to map logistic and financial transactions to ledger accounts and dimensions. For each financial transaction the user can decide which elements (for example: project, warehouse, item group) must be logged and mapped on.

The mapping scheme is version controlled, so if the mapping is changed, proper auditing is still possible as it is always known according which mapping scheme version a transaction has been mapped. During activation of a new version the system checks the completeness and consistency (e.g. similar mapping on debit and credit side on interim account) of the setup.

For the different types of integration transactions, it can be defined how backdated transactions for closed periods must be handled. The transactions can be posted to the next open period, to the current period, or to the closed period. Posting to a closed period can only be performed in a controlled way, by means of creation and approval of a so-called exception request.

Integration transactions posted to wrong ledger accounts and dimensions can be reversed and remapped using a new mapping scheme version or a GL code.

The architecture of the mapping scheme allows newly created transactions (either by SSA or an external application) to be mapped and posted without software changes to the SSA ERP Financials.

General ledger transactions

Journal entries are either automatically created (for example, integration transactions from the logistic modules or other financial modules, intercompany transactions), periodically generated according predefined setup (e.g. recurring and reversal transactions) or manually entered.

Reconciliation

SSA ERP Financials offers a generic tool for reconciling financial integration transactions. For each ‘reconciliation area’ (e.g. invoice accrual, work in progress, inventory) the user can decide which elements (e.g. project, warehouse, item group) must be logged to facilitate reconciliation.

Only after reconciliation has been done it is allowed to archive and delete the logistical data needed for reconciliation.

6-4 | Financials

General ledger inquiries and reports

Many inquiry options are available to offer different views on the general ledger history. The inquiries include both actual balances, budgeted balances and budget variances. Analysis is facilitated through drill-down functionality from the top to the lower level and vice-versa.

SSA ERP offers many standard reports (for example, journal report, trial balance). User defined General Ledger reports can be set up through the Financial Statements module.

Period and year end closure

Periods and years can be closed provisionally. SSA ERP Financials enforces the proper sequence of actions to avoid user errors. The year end closure automatically balances the profit & loss accounts (either on the individual accounts or as a total amount on a predefined interim closing account) and creates next year’s opening balances.

Tax reporting

Tax records are logged in the Tax Analysis. Through inquiries and reports the user gains insight into the tax receivable and tax payable for the related sales and purchase amounts. Tax analysis information is available by tax authority and tax authority group as well as by tax code and country.

Tax declarations can be made and paid to the appropriate collection offices through the regular payment process.

Accounts Receivable (ACR)

The Accounts Receivable (ACR) module handles and monitors sales invoices and credit notes. In addition, the Accounts Receivable module handles credit checking, credit management, and customer balance management.

Financial business partner groups can be created for groups of invoice-to business partners. The classification in groups is generally based on certain common features such as area or product type. Various ledger accounts can be assigned to each financial business partner group, which allows automatic postings of transactions to be created.

Financials | 6-5

It is possible to maintain multiple control accounts for a business partner group depending on the kind of sale made.

Invoice corrections can be done. Also the credit notes can be linked to the invoices. It is also possible to link credit notes to invoices of the child business partner. Sales invoices that recur over the periods can be generated automatically based on the original sales invoice.

Fixed assets can be disposed through Accounts Receivable. Sales invoice belonging to the miscellaneous revenue originating from logistics such as Service, projects PCS projects can be registered. It is possible to register intercompany and intergroup sales invoices (and credit notes).

Problem codes can be assigned to invoices, in case a business partner does not agree with an invoice. A reference can be linked to each problem code to identify the person responsible for dealing with the problem in question.

It is possible to factor the receivables to a Factor. If factoring is done without recourse, the receivables of the business partner will be closed and new receivable will be opened for the Factor. The factor will bear the liability of the receivable. If factoring is done with recourse, in case factor is not able to collect the receivable from the business partner, then we are liable to the factor the amount he has paid us for those invoices.

Three-phase credit checking (during order acceptance, release to warehousing, shipment) can be done. During the credit checking process, the business partner’s status, credit limit, overdue invoices will be checked.

Effective credit management can be done by maintaining the customer credit profile and allowing Credit analyst driven credit control. The business partner’s credit rating, credit limit, credit availability, various document balances can be provided.

The Credit Analyst functionality, allows the credit analyst to monitor the amount of credit that is given to an invoice-to business partner. Credit analyst maintains credit diary. Using this, the credit analyst can be view the open documents and balances for different action dates. Aging analysis, reminder letters and business partner statements can be taken by credit analyst to make it convenient for the credit analyst to analyze and take action for the various business partners for whom he is responsible.

Aging of the receivables into the various buckets can be done based on the days, months, or financial periods that the invoice has remained open.

6-6 | Financials

The user can determine whether doubtful invoices, anticipated receipts can be considered for aging. Aging can either be based on the invoice date or the due date.

Reminder letters (dunning letters), urging business partners to pay their open invoices can be prepared. These reminder letters are user-definable. Different letters of different severity can be used. If the business partner does not respond to the reminder letters sent, the system could automatically select more severe letters for reminding him the next time.

The reminder method used can determine whether only due invoices or all invoices will be sent in the reminder letters. Also the reminder letter can be sent to invoice-to business partner and/or pay-by business partner. The frequency of sending reminder letters to the business partner can be fixed in the reminder method.

Business partner statements of account are available to inform business partners of the status of the invoices and payments. Also the aging summary for the open invoices will be given at the end of the statement.

Interest invoices can be generated for invoices that have been paid too late. It is also possible to create interest invoices for the unpaid invoices. The user can modify the interest advice created by the system before generating the invoices. Different interest percentages can be defined per financial business partner group, depending on the number of days of the delay for the payment.

Accounts Receivables Management is facilitated through an A/R dashboard. The dashboard provides the enquiry (open entries, factor relations), analysis (aging, credit profile) and actions (business partner statement, Reminders) on the selected business partner. With the Open Entries functionality, a sophisticated drill-down feature allows the user to zoom from the invoice to payment documents, sales order data and the entries made in the General Ledger.

Open sales invoices that have been partially paid but still have small amounts remaining can be written off. These invoices are posted to ledger accounts defined per financial business partner group. Currency differences caused by interim exchange rate fluctuations on outstanding documents (such as invoices, credit notes, advances, unallocated) can be posted as an unrealized currency loss/profit. When the payment has taken place, this currency loss/profit is posted as a realized currency loss/profit.

Financials | 6-7

If sales invoices are doubtful, they can be marked as doubtful and posted to a special ledger account for Doubtful invoices.

Invoices that are fully closed including all corresponding documents can be removed. Before doing so, the system can archive the data.

A wide range of reporting functionality is available to the user for display or listing of Accounts Receivable data. For example, open invoices pertaining to a range of business partners, or the business partner credit profile, that allows the user to compare a business partner’s outstanding orders and invoice amounts with their credit limits can be reported. In addition, an analysis can be printed showing the unrealized currency difference by currency and business partner.

Reconciliation of control and interim accounts is possible using the control account checklist.

Accounts Payable (ACP)

The Accounts Payable (ACP) module processes purchase invoices and credit notes. This includes registration, invoice matching and supplier balance management.

Financial business partner groups can be created for groups of invoice-from suppliers. The classification into groups is generally based on certain common features such as the product or the type of business partner (wholesaler, trader, retailer, or internal/external business partner). Various ledger accounts can be assigned to each financial supplier group, allowing automatic postings of transactions to be created. It is possible to maintain multiple control accounts for a business partner group depending on the kind of purchase made.

The Accounts Payable module supports both manual and automatic creation of invoices.

Manual purchase invoice entry is efficient as supplier and order data can be defaulted from the purchase order. During entry the system checks for duplicate supplier invoice numbers. Costs can be allocated through predefined schedules.

6-8 | Financials

An approval scheme can be defined for a purchase invoice that defines who should approve the invoice and the latest approval date. An approval screen is available that lists all invoices that await approval by a specific user.

Purchase invoices can be matched with purchase orders or freight orders through the automatic three-way match functionality. Manually matching with the order or receipt is also possible.

Extensive authorizations can be set for price variance acceptance. Tolerances can be set for the system, supplier and user

SSA ERP Financials also supports pay from receipt. A warehouse receipt triggers the automatic creation of a purchase invoice. As this invoice is automatically matched and approved, it is ready for payment. For rejected goods a debit memo is generated.

Purchase invoices can also be received through EDI.

Legal withholding for income tax and social contribution can be applied to subcontractors’ invoices. For these invoices a specific withheld percentage can be paid to appropriate collection office. Purchase invoices can also be marked for 1099 MISC reporting to the IRS.

Procurement Card Statements can be registered and matched with purchase requisitions. When the statement is approved it becomes an invoice payable to the procurement card company.

Accounts Payables Management is facilitated through an A/P dashboard. The dashboard provides the enquiry (open entries, factor relations), analysis (aging, balances) and actions (registration, matching, approval) on the selected business partner. With the Open Entries functionality, a sophisticated drill-down feature allows the user to zoom from the invoice to payment documents, matched purchase order data and the entries made in the General Ledger.

Aging of the payables into the various buckets can be done based on the days, months, or financial periods that the invoice has remained open. The user can determine whether anticipated receipts should be included or not. Aging can either be based on the invoice date or the due date.

The Accounts Payable module allows writing off of small remaining amounts of invoices that have not been paid. Currency differences caused by interim exchange rate fluctuations on outstanding invoices expressed in a foreign currency can be posted as an unrealized currency loss/profit.

Financials | 6-9

When the payment has taken place, this currency loss/profit is posted as a realized currency loss/profit.

Invoices that are fully closed including all corresponding documents can be removed. Before doing so, the system can archive the data.

The Accounts Payable module offers a wide range of reporting functionality, such as the ability to print invoices at different stages (received, registered, matched, or approved), and reports of all the related documents (including postings) that are linked to an invoice.

Cash Management (CMG)

The Cash Management (CMG) module manages all cash related transactions. This mainly consists of payments to and receipts from business partners. All transactions can be entered manually, but electronic banking capabilities are also available for processing of automatic payments, direct debits and electronic bank statements. Different methods for processing the payments and receipts are supported; examples are bank transfers, checks, trade notes, and automatic payments/direct debits.

A company can be set up to either process its own receipts and payments or to have these handled by its financial group company. Transactions can be performed in any currency. Multi currency support allows you to register financial postings in up to three home currencies in addition to the document currency.

The Master Data business object sets up the basic data that will be used throughout the Cash Management module, such as bank relations, payment methods, data by bank/payment method, electronic bank statements, etc. Authorizations can be defined for employees allowed to process payments, as well as maximum amounts that can be paid per business partner.

The Cash Management module supports a wide range of payment transaction types, such as receipt and payment transactions, unallocated payments and receipts, advance payments and receipts, anticipated payments and receipts, journal vouchers and receipt and payment reconciliation.

6-10 | Financials

In addition, the Cash Management module contains a check master functionality, that keeps track of all checks by banks, and a functionality allowing the processing of standing orders or stand alone payments.

The payment procedure section in the Cash Management module supports 1099 MISC-Income Payments, providing the capability of reporting payments for services that fall under the definition of 1099-MISC Income as defined by the United States Internal Revenue System (IRS). 1099-MISC Income payment information may be reported to the IRS in a paper or electronic format. Test filings and correction runs may be performed in addition to original filings. Important details used in a 1099 filing are stored for 1099 business partners and the 1099 payer (company) in the Common Data module.

The payment procedure also supports electronic payments. The electronic formats for many banks and countries are available for transferring payments.

The receipt procedure in the Cash Management module allows direct debits from business partners, both automatically and manually. Open items that are due for payment are stored in a direct debit batch, which will be debited from the business partner's bank account. Manually composed direct debit orders must be audited before they can be processed. A report will be printed of any errors that were found. Remittance letters, containing a specification of the invoices included in a direct debit can be printed and sent to the business partners.

Payment statistics functionality, providing commonly required information on a business partner’s payment behavior, is also available.

A cash forecast is available for money requirement planning purposes. The forecast can be generated based on selected item ranges from purchase invoices, sales invoices, non order related sales invoices, purchase orders, sales orders, project orders, sales quotations, standing orders and budgets.

The Electronic Bank Statements (EBS) module in SSA ERP Financials offers all the functionality to define and process electronic bank statements. An audit of created EBS files is performed to prevent errors in the generation of financial postings. Extra amount received through EBS can be automatically converted into unallocated receipt.

Financials | 6-11

Financial Budget System (FBS)

The Financial Budget System (FBS) module registers, handles and monitors all budget amounts and quantities necessary for planning by ledger account or dimension, which allows the planning of overhead costs of cost centers and other dimension types.

The Financial Budget System supports the performance dependency of costs to achieve flexible budgets. Rates and surcharges are calculated using dimension, cost type, and cost driver. The calculated rates and surcharges can be exported to the Cost Price Calculation and Project Control System modules.

The budget data, amounts, and quantities are used as input for the cash flow forecast in the Cash Management module, for allocation and analysis in the Cost Accounting module, for analysis of the difference between actuals and budget figures in the General Ledger module and in the Financial Statements module.

The Financial Budget System has a particularly strong connection with the Cost Accounting module. While planning of the budget values is performed in the Financial Budget System, analyses of the actual values and the allocation procedures for budgets and actuals are carried out in the Cost Accounting module. After the allocation procedure in Cost Accounting has been performed, recalculated allocations can be reintegrated into a budget.

By defining budget codes, budgets can be created for a large number of periods per year. The original data of a budget can be copied to a new budget code and, by means of a multiplier, this data can be calculated into a new budget. Budgets may be linked through a distribution code so that the values of a child budget are directly calculated from the values of the parent budget.

Ledger accounts can be made dependent on each other. A ledger account is defined with a plan amount dependency from which other ledger account values have to be calculated. The source accounts can be from the same budget or from a different budget.

Cost drivers are available to carry out performance dependent budgeting. The cost driver is the base for calculation of rates and surcharges. Budget amounts can be split up into fixed and variable cost portions.

6-12 | Financials

Multiple hierarchies can be defined on ledger accounts and dimensions. These hierarchies are addressed with a hierarchy code. Budgeting can be performed according to chosen hierarchies.

Budgeting can be carried out with the ledger account as the leading key, in which case the dimensions are specified, or with a dimension as the leading key, in which case a set of ledger accounts is to be planned.

Budgets can be closed, so that any planning action is no longer allowed. The amounts and quantities of the budget can be distributed over the budget periods by means of percentages and factors. In addition, budgets can be defined as a percentage of a previously defined budget for a specific ledger account or dimension.

Budgets may be combined so that some budgets are dependent on other budgets. Tree structures are allowed for budget dependencies.

Cost Accounting (CAT)

The Cost Accounting (CAT) module provides cost analysis and cost allocation functionality on both a detailed and a summarized level. The Cost Accounting module registers, handles, and monitors all actual amounts and performance quantities necessary for controlling costs by dimension. Cost accounting calculations results in actual rates and surcharges.

A main objective is to control the overhead costs of cost centers or other dimension types. For this purposes, the "costs by nature" which exist as general ledger accounts can be defined as fixed (overhead costs) or variable (direct costs) cost types depending on their behavior in relation to the activity ratio (output) of a company. A 100% fixed or 100% variable is required: any variance can be entered by the user for any dimension/general ledger account combination. These determinations are a base requirement for the results of the Cost Analysis.

The Cost Analysis business object handles the actual amounts and performance quantities that are necessary to generate the deviations and the comparison data. The planning per dimension is performed in the Financial Budget System. The resulting values are the basis of cost analysis in the Cost Accounting module. Actual cost amounts are integrated from the General Ledger module.

Financials | 6-13

If the relevant dimensions have performance dependent budgets, actual performance quantities can be derived from the Hours Accounting module in order to calculate the allowed costs as a flexible budget.

After entering the actual figures of cost and performance amounts the analysis information for dimension control is derived with the cost analysis business object. The results are allowed costs and deviations per dimension and cost driver. Any price variance or efficiency variance can be detected and traced per dimension and cost driver, and a comparison with past periods can be done as well. Actual cost allocation sheets are predefined for reporting of plan amount, actual amount, and deviation amounts. You can post the deviations into the General Ledger module in order to show them in the Financial Statement module.

In the Financial Budget System, you can define multiple hierarchies on ledger accounts and dimensions. The Cost Analysis business object allows the user to present budget and actual figures of the Cost Accounting module in inquiries and reports according to chosen hierarchies.

A drill-down facility is implemented, so information can be shown on every level of detail and in every combination of ledger accounts and dimensions within one dimension type.

Actual rates or surcharges are calculated per cost driver respectively. This cost analysis functionality offers the facility to copy the results to the cost price calculation master data of the Cost Price Calculation and Project Control System modules in a rule driven way.

As for Inventory valuation analysis, both Standard and Actual Costing methods are available to report the value of a companies' inventory. Apart from the Fixed Transfer Price, the methods that can be used to value inventory based on actual purchase or production costs are Last In First Out (LIFO), First In First Out (FIFO), Moving Average Unit Cost (MAUC: average cost per warehouse) and Lot Costing (specific price per lot).

The Cost allocation business object in Cost Accounting allows the user to build a model of performance and allocation relations between dimensions. The quantity net is built first, and then the relations are evaluated with costs. Allocations may be based on budget amounts from the Financial Budget System and on actual amounts from the Cost Accounting and General Ledger modules. Allocation results can be reintegrated into the Financial Budget System or posted to the General Ledger module.

6-14 | Financials

If a waterfall model is not sufficient for cyclic allocation relation nets, an iterative method is used to determine the exact solution for allocation amounts: the so-called price iteration.

The Cost Accounting module in SSA ERP Financials also contains the functionality to perform Activity Based Costing. In order to perform Activity Based Costing, one of the dimension types must be selected for the activities. Activities can be combined with cost drivers. Allocations to cost objects may be based on the entered quantities or amounts of the cost drivers. After the collection of costs from other dimension types on activities, consumption rates for activities are calculated. There are even cost drivers defined for the cost objects, such as the number of sold items of a special kind. Actual quantities can be derived from logistics in the Cost Analysis business object. These cost drivers serve as surcharge base for the cost objects. After costs are allocated from activities to cost objects, actual surcharges can be determined and transferred into the Cost Price Calculation module and the Project Control System module’s cost price calculation master data.

Special reports and inquiry facilities are available in the Cost Accounting module to show budget and actual figures per dimension: for example, cost allocation sheets and hierarchical analysis. If you want more data, specific data, or data printed in another way, the OLAP system or another external reporting package can be used.

Fixed Assets Management (FAM)

In the Fixed Assets Management (FAM) module a company's fixed assets can be registered and managed. Financial transactions such as investment, depreciation, revaluation, transfer and disposal are posted to the general ledger.

The Fixed Assets Management module supports different asset books for different purposes (e.g. commercial, statutory, tax, calculatory etc.). These books can post into the dual ledger structure.

An asset has a quantity linked to it, so if there are multiple identical assets it only needs to be entered once.

Financials | 6-15

Location tracking can be done through a segmented location code. The location code can contain up to eight user definable segments (e.g. country/city/site/building/floor).

Fixed Asset Management supports numerous depreciation methods, such as straight line, declining balance, sum of the year’s digits, fixed amount, units of production, net book value oriented, annuity etc. Next to these predefined methods, customized depreciation methods can be defined.

The averaging convention taken for the calculation of the depreciation is flexible. Depreciation can start the period in service, first day service year, half-year, modified half-year, mid-month, mid-quarter and so on.

When not in use, depreciation of assets can be suspended in the specified periods. The life of the asset will then increase to the number periods suspended. Based on the real usage of an asset, it is possible to accelerate the depreciation of assets for the selected years.

Additional, user defined, asset information can be stored for an asset.

The costs of an asset can be filled through the Accounts Payable module as you can link a purchase invoice to an asset. An asset can also be created from a capital project in SSA ERP Project

Assets can be revaluated based on indices.

To facilitate efficient asset management, one central asset screen is available through which all relevant actions (both inquiries and transactions) on the asset can be taken.

Reports are available to document entered master data and to report all asset transactions. Also specific reports for registration, reconciliation, analysis, and tax are available.

Assets can be transferred or disposed by quantity or percentage. Disposed assets can be invoiced through the Sales Invoicing module.

6-16 | Financials

Financial Statements (FST)

In the Financial Statements (FST) module user definable reports, such as balance sheets or profit & loss statement can be generated for internal and external reporting purposes.

Statement structures for ledger accounts and dimension are defined in the Financial Statements module. SSA gathers data from the General Ledger and the Financial Budget System, calculates the statement values (e.g. periodical balances, year-to-date balances) and stores them in its ‘datawarehouse’.

Report layout (incl. graphs) is defined in SSA Enterprise Reporting for ERP LN. This application takes the prepared data from the datawarehouse and prints the actual reports.

Introduction

SSA ERP Project provides Project Management solution that enables general contractors, equipment suppliers, engineering firms, and other project-oriented companies to effectively manage and improve their business processes. SSA ERP Project supports the project supply chain consisting of customers, prime contractor, subcontractor, suppliers, and various other entities of project supply chain.

The solution caters to the total lifecycle management of projects that includes engineering, procurement, manufacturing, construction, warranty service, and maintenance. The goal is to manage each project in a cost-effective manner according to the established time schedule and within the specified budget. It is especially suited for project-driven companies for coordinating multiple projects.

SSA ERP Project is a highly integrated offering as part of SSA ERP . It is integrated with Order Management, Warehousing, Manufacturing, Service, People, Financials, and Central Invoicing. Further, integration with Microsoft Word and Microsoft Excel is present for various calculations and reports. Finally, a seamless integration with Microsoft Project is provided to leverage the powerful and easy functionality of scheduling within Microsoft Project.

7Chapter 7 Project

7-2 | Project

This includes the integration to Microsoft’s Client-Server based Enterprise Project Management offering of Microsoft Project 2002 Server and Professional version, which includes such functionality as centralized resource management through resource pools and centralized calendars.

SSA ERP Project supports all the business process of Project Management, such as project-definition, estimation, budgeting, planning, baseline establishment, execution, control and closure.

SSA ERP Project consists of the following modules:

General Project Tables (PDM)

Project Definition (PDM)

Project Estimating (EST)

Project Budget (PTC)

Project Planning (PSS-2)

Project Requirements (PSS-6)

Project Progress (PPC)

Project Monitoring (PPC)

Project Invoicing (PIN)

In addition, a Project Dashboard is provided for a complete overview of each project.

The following integrations illustrate the integration between SSA ERP Project and other packages of SSA ERP, along with the integration in the various modules of SSA ERP Project:

Request for Quotation.

Order to payment.

Project | 7-3

CHL11a: Request for Quotation (Process-driven Project)------------------------------------------------ 1. Request for Quotation to be Managed 2. Customer Data to be Managed 3. Project to be Engineered 4. Purchase Inquiry to be Managed 5. Request for Quotation to be Processed 6. Process to be Engineered 7. Project to be Defined 8. Project to be Estimated 9. Financial Plan to be Managed 10. Quotation to be Accepted

Purchase Engineering

Account Management

Project Management

Financial Planning & Budgeting

Customer DataManagement

Product Engineering- w ith EDM (MRT,

MJS)Process EngineeringPurchase Inquiry

Management

Financial Planningand Budgeting

Project Estimating -Process Oriented

Project Definition -Process Oriented

CustomerSupplier

5.4. 6.

1.

2.3.

7.

8.

9.

10.

7-4 | Project

CHL12a: Order-to-Payment (Process-Driven Project)---------------------------------------------- 1. Project to be Defined 2. Product to be Engineered 3. Production Process to be Engineered 4. Project to be Defined 5. Project to be Budgeted 6. Project to be Planned 7. Project Execution to be Controlled 8. Purchase Order to be Created 9. Purchase Order to be Fulfilled 10. Purchase Order to be Received 11. Project to be Administrated 12. Project to be Controlled 13. Components to be Picked 14. End Product / Components to be Stored 15. End Product / Components to be Shipped to BP / Project Site 16. Product / Components to be installed at Project Site 17. Project to be Evaluated and Closed 18. Invoice to be Created 19. Invoice to be Paid 20. Open Entry to be Controlled 21. Bank Statement to be Processed

Service

Purchase Engineering

Project Management

Warehousing

Account Receivable Invoices

Cash Management

Purchase OrderEntry

Product Engineering- Change Ordersw ith EDM (MJS,

MRT)

ProcessEngineering

Project Evaluation &Closing - Process

Oriented

Project Definition -Process Oriented

Project Budgeting -Process Oriented

Project Planning -Process Oriented

Project Control -Process Oriented

Execution ControlProject

Administration

Store Goods Picking - AdvancedStore GoodsPicking - Advanced Inspection Shipping - BasicReceiving -Advanced

Invoice CreationCredit Control

Electronic BankStatementProcessing

Service ExecutionControl

Goods Flow

CustomerSupplier

Bank

15.

14.

8.

20.

21.

19.

9.

16.

18.

17.

2.4.

10.

6.

5.

3.

1.

7.12.

11.

13.

The following sections describe each module of the SSA ERP Project with all the modules’ functions and features.

Project | 7-5

Project Dashboard

In project-driven companies, irrespective of the role, all the users access Projects to execute their tasks. Typically, different users must perform tasks in different phases of the project. For example, an estimator will estimate a project, a sales engineer will prepare the quotation, the project manager will perform project definition, and the design engineer will set up the budget, and so on.

However, one common thing is common to all the users and that is to view the various phases of the project in one single overview. Project Dashboard is created to present a complete overview, from estimating to invoicing, of Project information in one session.

Project Dashboard present the following details (field values) in one window:

Status

Contract Amount

Contract Type

Invoice Type

Holdback Percentage

Organization Breakdown Structure (0BS)

Budget By

Control By

Budgeting Method

Estimate (Total Cost Amount)

Budget or EAC

Actual Cost or ACWP

Commitments

Forecast Costs / ETC

Total Costs

Project Progress Percentage (schedule progress)

Performed or BCWP

Project Revenues

7-6 | Project

Forecast Revenues

Total Revenues

Cost Variance

Cost Variance at Completion

Received amounts from customer

Paid amounts supplier

Customer overdue amounts

Overdue amounts to Supplier

In addition, the Project Dashboard provides access to all the relevant project information at one place. The Dashboard contains links to the most important sessions that are present in SSA ERP Project, from a Project Managers perspective. You can start the following sessions from the Project Dashboard:

Business Partners

Extensions

Structures

Milestones

Estimate

Budget

Time Phased Budget

Purchase & Warehouse Orders

Service Orders

Progress

Cost Control

Performance Measurement

Revenues

Project | 7-7

General Project Tables (PDM)

This module provides the functionality to maintain project master data. The master data is the standard data that is used across all projects within the company. In addition to the logistics tables and the financial tables of SSA ERP Common, this module contains the general data that is used in SSA ERP Project.

The features in this module are the following:

General Project Data

Standard Cost Objects

Buy From Business Partners Diskettes

Standard Revenues

Standard Structures

User-defined Structures

Project Templates

Standard Surcharges

General Project Data

Here, the master data used in SSA ERP Project is centralized for use across projects. Most of these tables are used for grouping, sorting, and reporting projects. These tables are also used as various dimensions for financial postings.

Employees and trade groups involved in projects are defined here.

You can also define an organization’s responsibility matrix. In this matrix, you can assign the responsibility for certain parts of a project to the right employees.

The general project data consists of following tables:

Acquiring Methods

Appointment types

Business sectors

Categories

7-8 | Project

Competitors

Document types

Financing methods

Groups

Phases

Employees – Project

Responsibilities

Sufferance tax

Third party types/third parties

Trade Groups

Standard Cost Objects

Define standard cost objects used in projects. These cost objects are used as the detail lines of estimates, budgets, and for the registration of hours and costs. If a project-dependent cost object is required, standard cost objects can be copied to project cost objects. Cost objects can be controlled through control codes. If cost components are used, each cost object has a reference to a cost component. You can update prices and rates of cost objects collectively.

Five (cost) types of cost objects are available:

Item: This cost object cannot be maintained in this business object, but in the material Business Object. The cost object is only mentioned here to indicate that five types of cost objects are available.

Labor

Equipment

Subcontracting

Sundry costs (miscellaneous)

Global updates of prices and rates of cost objects are possible by means of percentages and fixed amounts. For the labor cost objects linked to reference activities of SSA ERP Service, you can update the prices from the reference activity directly.

Project | 7-9

Buy from business partner diskettes

If a supplier can provide a file or diskette with item prices and discounts, this information can be imported. This enables you to define the relationship between supplier codes and your own codes, as well as the relationship between items and the supplier discount groups. The latter indicates which discount applies to an item from a certain discount group. You must only do this once. For each supplier, discount types are defined to describe discount variables, and the layout of the file is stored.

The following three discount levels are available by discount type:

Company level

Discount Group level

Quantity level

Standard Revenues

The user can link revenues to a revenue code. You can maintain standard revenue codes, which are available for all projects. If a project-dependent revenue code is applied, standard revenue codes can be copied to project revenue codes. Revenue codes can be used to combine revenues or to refer to revenues. The revenue code can be used for the integration with SSA ERP Financials or to function as a dimension. If cost components are used, each revenue code has a reference to a cost component. You can also assign standard revenue code by cost type and cost object.

Standard structures

You can define a library of standard elements and activities to be copied to project structures or to template projects.

User-defined structures

Various additional structures that are used in projects either for reporting purposes or for responsibility assignment and subsequent performance measurement are maintained in user-defined structures.

These structures can be of the following three types:

User-defined, Flat

7-10 | Project

User-defined; Hierarchical

Organization Breakdown Structure (OBS)

The first two types of User defined structures are currently limited to estimating module only. They are used for reporting purposes.

Using OBS, you can define the various organization levels of your own organization, or of subcontractors, for example, in a treelike structure. You can define various organization levels in an OBS, for example, company, work center, employee, and so on. These levels are called OBS elements.

You can use this OBS to link the responsibility for specific activities to an OBS element. These responsibilities consist of the work for an activity. In a single activity, you can define the work linked to a single OBS element. This intersection point between the OBS and activity structure represents a project cost account.

After you define an OBS, you can use OBS for several projects simultaneously. If an OBS is linked to a project, you can extend the OBS, which has no consequences for the project. However, if particular parts of the OBS are deleted, the consequences for related projects must be checked. If, for example, responsibilities are defined for an OBS element, you cannot delete the element.

Project templates Companies can reduce costs on administration of the project setup with the new template functionality. A standard template can consist of three templates:

Project data template: With the help of this template, you can predefine a set of project types for a company. If you select a predefined template during the project definition, the project settings are created automatically.

Element template: With the help of element templates, standard elements can be structured in a hierarchy. When a project is created, the element structure is automatically defined according to the selected element template. The template can also be used when the project and/or element structure already exists. You can add substructures.

Activity template: You can also store the activity structure in a template. This template functions in the same way as the element template.

Project | 7-11

Standard Surcharges

Surcharges are intended to cover overheads. These surcharges are posted to sundry cost codes. You can maintain and copy standard surcharges. If no surcharges are available for a project, you can use standard surcharges.

You can enter standard surcharges by:

Cost type or for all cost types

Cost component

Revenue code

Cost object

The user can apply multiple surcharges to budgeted costs, actual costs, and revenues. Surcharges are defined as percentages. Surcharges by cost object can be defined as percentages and/or amounts. The user can also define an effective date and an expiry date by surcharge. To support multisite cases, you can post surcharges to the enterprise unit in charge of the project, to the delivery enterprise unit, and to a fixed enterprise unit.

Project Definition (PDM)

This module provides the functionality to define a project contract with all the terms and conditions, as well as the definition of all the internal processes, which will be used for each specific project. Any changes to the scope of the project is handled with the use of extension contracts, which contain pretty much the same information as that of a project.

The scope of the project in terms of WBS is defined using project structures. All the master data setup that is project specific, such as, project cost objects, project revenues, project surcharges, and project structures are all defined here.

The features in this module are the following:

Scope Definition: Dynamic Menu

Project Data

Project Structure

Project General Data

7-12 | Project

Project Contract

Project Cost Objects

Project Revenues

Project Surcharges

Project Currency Conversion

Scope definition – Dynamic menu

Dynamic menu is a new concept along with maps. A dynamic menu adds more structure and overview to SSA ERP Project. A dynamic menu is navigation to one project in a specific area, for example, budgeting or scope definition. The sessions are linked in a dynamic menu. The objective of a dynamic menu is to group actions, which are relevant to this particular project (settings). In this way, you can more easily navigate to the business processes you need instead of listing all options. With the dynamic menu, the user can perform actions on the selected object. Examples of actions include: insert, register, view, and print. Some of the actions must be performed in a specific order, while some can be performed independently.

Project Data

Master data for each specific project is stored in this Business Object.

One central project table contains only the basic project data. Therefore, the user can use and access this table from SSA ERP Project and SSA ERP Manufacturing. In this business object, you can define the project-specific data of projects. The central project table can be maintained in the MCS module.

A project can be defined as a main project, a subproject, or a single project. In the case of a main project, the project structure is composed of subprojects. Subprojects can be registered and monitored at main project level. You cannot define additional subprojects (you can define just two levels). You can choose whether or not the budgeted costs of the subprojects must be included in the budget cost analysis and the control data for the main project. A single project does not have any relationships with other projects.

Another definition of Project is if the project is a contract project or an internal project or a template project. An internal project has no contractual obligations to a business partner.

Project | 7-13

No revenue can be related to an internal project. Next to the internal project, there is also a possibility to create a capital project.

A capital project is an internal project that becomes a fixed asset on the balance sheet, on completion. You can now choose between just an internal project and a capital project.

Example A training program for the employees is an internal project.

Constructing production facilities for a new product line is a capital project.

Depending on the agreement type of the project, the project contract amount can be calculated as a fixed price contract or as cost plus. This affects the invoicing in SSA ERP Project. In case of a fixed price contract, the method of invoicing can be unit rate, installment, or progress. In the case of cost plus, the invoice method can be cost plus or unit rate. In case of cost plus contracts, cost plus markup percentages for each cost type can be defined for determining the sales amount. In case of fixed price contracts, the project contract amount is the total of the contracts amount of all the customers of the project. Multiple customers by projects, multiple contract types by customer by project, multiple contract sub amounts with different currencies by customer by project are also possible. Advances on the customer can be split to different installments of that customer.

Various methods of revenue recognition and cost of goods sold are available for selection.

Projects are controlled depending on the project status, which can be free, active, finished, closed, or archived. The level of project progress registration can be maintained by project. When a new project code is created, particular fields will be filled with default values. You can define the extent of detail for the project's cost control.

The available cost control levels are:

Project and/or by cost type/cost object/cost component.

Activity and/or by cost type/cost object/cost component.

Element and/or by cost type/cost object/cost component.

Extension and/or by cost type/cost object/cost component.

7-14 | Project

To support multisite cases, an enterprise unit is linked to each project. You can refer to all sorts of information and sort/selection fields, such as business sector, category, project group, acquiring method, and financing method.

The project data can be copied, archived, and deleted (status driven). Copying project data from one project to another saves a lot of work. You can indicate whether the following data groups must be copied: general project data, project-related cost objects, planning data, cost registration master data, and/or accounts.

The relationship between projects in SSA ERP Project and projects in SSA ERP Manufacturing (PCS projects) can be defined.

Project data can be archived or retrieved from the archives. You can choose whether to copy or to move the project data to a separate archive company number, and which data groups must be archived.

Project structures

Use this Business Object to define the scope of the project in terms of work breakdown structures (WBS). Two types of project structures are supported in the solution: element structure and activity structure.

Elements and element structure

Element structure is purely deliverable oriented structure, which is built from elements. The number of levels in a structure is unlimited. Based on the parent/child principle, relationships are defined between elements. These relationships can be multiparent (network).

In a parent/child relationship, you can define a frequency, which is the number of times a child occurs in a parent. The end result is a networked element budget structure.

Activities and activity structure

You can use activity structure to define both the deliverables and work in an integrated WBS. In the activity structure, you can define WBS elements, work packages, cost accounts, and planning packages. Activity structure is enhanced in functionality to offer all the features and functions that are present in the element structure. Here, you are recommended to use activity structure wherever possible.

Project | 7-15

Every activity structure is part of a project plan.

Various milestones for the project can be defined as part of a plan. The milestones can be used for project control, invoicing, and performance measurement

For more details about this feature, refer to the Project Planning (PSS2) module.

Project general data

Additional information about specific projects is stored in this Business Object: third parties, employees responsible, appointments, documents, and locations.

Project contract

Project contract information includes the definition of business partner-related information in regard to project invoicing. Any extensions to project contract and the agreed terms and conditions are captured in project extensions.

Extensions

Extensions are used to flexibly cope with uncertainties as quantities, prices and invoiceable variations of work in the future. The types of extensions are variations, provisional amount, fluctuation settlement, and quantities to be settled. An extension is linked to a project. The work performed under an extension will be invoiced to the customers.

These extensions are linked to the budget lines where the variation in work is anticipated.

Project Cost Objects

In addition to standard cost objects, from the corresponding Business Object, cost objects for a specific project can be defined in this Business Object. Standard cost objects can be copied to project cost objects. The five types of project cost objects are the same as for standard cost objects.

If cost components are used, each project cost object has a reference to a cost component.

7-16 | Project

Global updates of prices and rates of project cost objects are possible by means of percentages, fixed amounts and from standard cost objects. For the labor cost objects linked to reference activities (of SSA ERP Service), you can update the prices either from the standard labor or from the reference activity directly.

Purchase contracts for the procurement of standard item used in projects can be defined here.

Project Revenues

Maintain the unique revenue codes for a specific project or project activities or project elements here. These revenue codes can be used to combine revenues, for example, cost-plus. Revenues can be posted to a revenue code (installments and advances).

The revenue code can be used for the integration with SSA ERP Financials. If cost components are used, each project revenue code has a reference to a cost component.

Project surcharges

Project specific surcharges for budget, cost, and revenues are maintained here. If project specific surcharges are present, only the project surcharges are used and the standard surcharges are ignored.

Project Currency Conversion

Using this feature, you can convert the project, budget and project business partner currencies. The contract amount, budget line amounts and revenues present in multiple currencies will be converted to the new currency.

Project Estimating (EST)

Estimating is usually the first phase within the project. Estimating is often the most critical phase within the project as proper estimating and bidding will result in obtaining the project contract.

Project | 7-17

This module provides the following functionality:

Cost price estimation

Sales price calculation

Schedule estimation

Estimate analysis

Preparation of bids

Copy project including estimate data

Launching an estimate to budget

The user can create an estimate project. For each estimate version, a complete estimate can be simulated and, if the estimate is accepted, a bid can be created from the estimate version. Estimating is often continued after submitting the bid, for example, if the customer asks for changes or more details. If the customer accepts the bid, the actual project can start. The following two scenarios are possible:

Launch the estimate to budget.

For the sake of continuous project series, the estimate project is blocked and a new project (with a recognizable series and number) is created for the contract with the customer.

The Estimating (EST) module relies heavily on the integration with the Microsoft Project Office suite, particularly Microsoft Excel for calculation, Microsoft Word for bids, and Microsoft Project for determining the schedule. With SSA ERP Object Data Management, you can link the documents. The new module is a base solution that fulfills the basic customer requirements and is a professional user-friendly and integrated piece of software.

The features of estimating solution are:

Estimate versions

Estimate structures

Estimate lines

Microsoft Project integration

Microsoft Excel integration

Aggregate amounts by PSE

Verify top-down estimate consistency

7-18 | Project

Bid

Launch estimate to budget

Message log

Estimate versions

An estimate goes through multiple changes and iterations before resulting in a final bid. Many factors lead to the changes, which are either due to changes in scope by the customer or due to changes in estimating process within the company. Most of the times the changes could be simply due to progressive elaboration of project scope.

The best way to keep track of these changes is by the use of version control. Therefore, every estimate will be captured under a version. Multiple versions can be created for a project. You can copy one estimate version to another.

Estimate Structures

You are not required to use structures for estimating, because you can estimate using descriptions. However, you can also estimate using various structures. You can use all the structures that are supported by SSA ERP Project, such as activity structure, WBS, OBS, extensions, and cost components. You can also use new user-defined structures for reporting purposes. Activity structure will be used for the purpose of schedule estimation.

A project life cycle generally includes one primary structure, which undergoes changes as the structure passes from one phase to another. Some of the phases in the life cycle of the project are estimating, budgeting, and execution, followed by service and maintenance. This is analogous to as-designed, as-planned, as-built, and as-maintained BOM. One of the structures can be used as a primary structure. Though only one primary structure exists, the project can have many other structures used for various purposes.

An estimate undergoes multiple iterations as described in the previous feature, “Estimate versions.” In each new version, the scope and the resultant structure can vary. Therefore, the structure with which the estimate is prepared must be captured for each estimate version for baseline, analysis, and tracking purposes. All this information is captured in estimate structures. You can synchronize the estimate structures from the base structures, including activity, WBS, OBS, and so on, at any time.

Project | 7-19

Estimate lines

This feature is the single most important feature of the module, in which you can perform nearly the entire estimating on one screen. In one estimate version, you can use both the top-down and bottom-up estimate type and several calculation methods. You can also perform the estimation at various levels of detail for the same structural element. You can perform estimation either at total level or detailed level.

The user can define the estimate with or without cost objects, control codes, cost types, descriptions, and structures. You can calculate the cost, as well as sales estimates, in the same version.

Estimate lines at all levels only signify the amounts (cost & sales) for the primary structural element. Other structures that are linked to the lines are used for the purpose of various views of the cost and sales information, which belong to primary structure.

Because both bottom-up and top-down estimates can exist simultaneously, for each element of the primary structure, you can make a choice as to which type of estimate must be used for the purpose of bid. Leading estimate type facilitates combined top-down and bottom-up estimating for the same primary structure. For a bid, the user must choose between top-down and bottom-up, which is a property of each element of the primary structure. If the bottom-up cost at any level of the element is included in the bid, the top-down cost for that element is automatically excluded, which is represented as the leading estimate type. This type will be entered either on the estimate line or in a separate table.

Include in scope in the estimate lines is to establish whether or not the work represented by the line is included in the scope of this estimate. This will affect the cost and sales price of the estimate. The main purpose of this field is for arriving at a final quotation based on customer choice to exclude parts from estimate. The flag will also serve as a work around for alternatives.

You can use adjustments, escalations, and contingencies for fine-tuning the estimate to improve the accuracy of the estimate.

Many fields such as landed cost, direct and indirect costs, margins and discounts, alternatives, user-defined statuses, in scope and out of scope are available in estimate lines providing rich estimating functionality.

7-20 | Project

Integration with Microsoft Project

The current integration between SSA ERP Project and the external scheduling package - Microsoft Project is used to set the estimate structural elements (of type Activities) in time. These elements can be scheduled and the new dates update estimate lines cost and sales dates. For cost, the activity start date releases the costs for an estimate line, and for sales, the finish date sets the expected sales date.

Integration with Microsoft Excel

A large number of customers/prospects are currently using Microsoft Excel to perform project estimation. They defined various cost models and parametric models in Microsoft Excel.

Microsoft Excel is a powerful tool that can perform complex cost price and sales-price calculations. An extensive repository of formulas exists in Microsoft Excel, and new formulas can easily be defined. Integration with Microsoft Excel is developed to exploit all the mentioned features and to provide the possibility for the customers to reuse existing data. SSA ERP Project offers predefined Excel templates. However, these can be fine-tuned or you can build your own Excel integration. The integration with Microsoft Excel is mainly to use the following functionality:

After a calculation in Microsoft Excel of, for example, the Quantity field, the Cost Price field, or the Sales Price field of an estimate line, the value of the equivalent numeric fields in SSA ERP Project’s estimate lines are updated.

After a calculation in Microsoft Excel of, for example, surcharges defined and applied in Microsoft Excel, you can update field values for a range of records in SSA ERP Project’s estimate lines.

You can create a range of records in SSA ERP Project’s estimate lines, after calculation in Microsoft Excel of, for example, new estimate lines from Microsoft Excel.

You can draw charts/graphs to provide a more visual representation of the data imported from SSA ERP Project’s estimate lines, for example, cash flow in the project.

An additional feature of the Microsoft Excel integration is that the integration offers integration with other industry-specific estimating packages. Many packages use the Microsoft Excel format.

Project | 7-21

Aggregate amounts by PSE (primary structural element)

When you conduct estimation at various levels, you must get a summery view of both the cost and sales amounts, which will give the estimator a quick view of totals. Note that the estimate totals can be calculated for each structure maintained in the estimate lines. However, the estimate totals, which are displayed on the top of the estimate entry screen, are for primary structure only. Use this process session to calculate the amounts.

Verify top down estimate consistency

You must ensure that the amounts of parent and children are consistent, such that the total of children amounts do not exceed the parent total amount. Performing these checks and giving error messages during estimate entry will be very restrictive to the user.

Therefore, only warnings will be given during the estimate entry. In addition, these warnings are given in a separate window, so that the estimating process flows on uninterrupted.

Therefore, a separate session is provided to verify top-down estimates, which provides an error report on all the inconsistencies. The top-down consistency will be performed only for cost data and field used for verification is either Landed Cost Amount or Total cost amount, depending on a parameter. No consistency check is performed for sales amount, because no check is required.

Bid

You can prepare a bid even for a part of the project structure, which means multiple bids can be created for one project. Moreover, multiple bids can be made from one estimate version. Note that only one business partner is available for one bid. All the relevant information that went into the bid is stored for future reference.

The actual bid itself will consist of a document listing the scope and terms and conditions in Microsoft Word, the sales (/ cost) summery sheet in Microsoft Excel and all the supporting documents, such as the CAD drawings, project plan from ESP, scope documents, contingency documents, and so on, that are related to the bid in SSA ERP Object Data Management.

All the estimate lines of a version, which are included in a certain bid, are captured in the bid lines table.

7-22 | Project

Launch estimate to budget

The main feature of this function is to reuse all the data created during the estimating process for execution. Another useful feature is the possibility of re-launching the estimate. Various options are available for launching an estimate to budget as described in the following list:

Relaunch estimate to budget.

Launch either part or complete structure.

Launch to bottom up budget or top down budget or both.

Launch to element or activity budgets or both.

Launch adjustment, escalation, and contingency as sundry budget lines

Message log

If any errors exist in the processes of Verify top down budget and Launch estimate to budget, the errors are captured in Message log for each login by run date. In addition, many other messages, which are not errors, are also captured here for information. For example, a cost object code is generated for the project. This is not an error, but you launched an estimate to a project budget and the cost object code is generated in the process.

Project Budget (PTC)

The purpose of this module is to prepare, control, and maintain the project budget throughout the lifetime of the project, as a baseline. Two methods are available to set up the project budget, namely element-based and/or activity-based.

Many other setups are required before you can create a project budget. The activity structure, which is required for activity budget, can be maintained in the PSS module or in the external scheduling package, Microsoft Project. Standard codes, norms, items, factors, and so on, are maintained in the Project Data Management (PDM) module.

The Project Budget (PTC - Project Technical Calculation) module’s features are:

Bottom Up Budget

Element Budget

Project | 7-23

Activity Budget

Budget Adjustments

Budget History

Budget Cost Analysis

Purchase Budget

Control Data

General Budget Sessions

Top Down Budget

Time-Phased Budget

Element Budget

The Element Budget Business Object provides detailed information about the elements. This detailed information consists of budget lines. A budget line contains all the budgeted costs and quantity information for the cost object. Each budget line gets a code (cost object/control code). These codes are very useful to analyze the cost patterns in a project.

A budget line can have the following cost types:

Material

Labor

Equipment

Subcontracting

Sundry costs

You can use cost components, for example, Paintwork, to have an extra control dimension of the budget (lines). You can also copy budget data to another element budget.

Activity Budget

The Activity Budget Business Object is similar to that of the Element Budget Business Object. However, some differences exist:

You cannot define a frequency between parent and child.

Relationships cannot be multi-parent.

7-24 | Project

The activities and their hierarchical relationships are maintained in the PSS module. Budget detail lines of the activity budget are used in the planning package Microsoft Project. The number of levels in an activity structure is unlimited. Based on the parent/child principle, relationships are defined between activities. The use of this structure is according to the bottom-up budgeting principle.

After the activities in a project have been recorded, the corresponding budget detail lines are recorded in this Business Object. Like element budget, cost components are applicable. You can also copy budget data to another activity budget.

For information about activities and activity structure, see the feature description in Project Structure in the PDM module.

Budget Adjustments

Use this feature to implement change control on budget. After a budget is finalized, you can no longer modify the budget information. The only way to modify the information is to use adjustments or extensions. The main difference is that adjustments cannot be invoiced to customer, while the extensions can be.

All the adjustments can be captured under various adjustment codes for better tracking and control under different heads.

Budget history

Use this feature for tracing the complete changes to budget right from insertion of a budget line. Any modifications made to a specific budget line are captured per login and date.

Budget Cost Analysis

At various stages in constructing the actual budget for your project, you will want answers to such questions as:

What is the total amount budgeted?

What amounts are budgeted for certain elements or activities?

What amounts are budgeted for certain cost components, control codes or cost objects?

What numbers of hours are budgeted for labor costs?

Project | 7-25

What amounts are budgeted for extensions or surcharges?

SSA ERP Project provides a budget cost analysis facility to help you display and print the information you need. Note that you do not analyze the actual budget directly. Instead, you generate a new type of data called analysis data, and run inquiries and reports on that derived data. You can think of the analysis data as an overview of the actual budget. You can create multiple overviews for a single project, and assign a unique budget cost analysis code to each one.

Control Data

The control data is a derived budget based on the project budget and surcharges. You can use the control budget as a frozen budget for the following operations:

Generate planning orders in the PSS module.

Record progress in the PPC module.

Record actual costs in the PPC module.

Generate invoices for customers in the PIN module.

Purchase Budget

A typical actual budget contains cost objects with long purchase periods. In addition, the quantities to be purchased can be uncertain. To wait until such information is available can delay the project and prove costly. Instead, you can use the Purchase Budget sessions to procure these types of cost objects before project execution starts. You can create a purchase budget by entering cost objects directly, or by copying them from the actual budget. You can purchase part quantities by specifying a percentage of the budgeted value. The Project Requirements (PSS6) module uses the purchase budget to generate purchase orders. The purchase budget does not affect the actual budget. It is used simply to bypass the step-by-step process of project budgeting and execution.

General Budget Sessions

The functionality is used in both the element budgets and the activity budgets. You can update the changed prices and rates in the actual budget with their latest values. You can also update the budget dates and budget line currencies.

7-26 | Project

If the budget type for project control is an activity budget, you can copy the element budget to an activity budget. You cannot copy an activity budget to an element budget.

You can create and update assignments for employees in SSA ERP People for project tasks

The user can customize an item based on customer specifications using the integration with the PCS module of SSA ERP Manufacturing.

Top Down Budget

The user can budget in a top-down method (instead of bottom-up). In this method, the user can first assign a budget to a parent activity and distribute the budget to all the activity’s children. The budget of the parent will be a constraint for all the children. You are not required to distribute all the budget of the parent to the parent’s children. This process is repeated all the way to the lowest level activities of the activity structure.

Time-Phased Budget

A time-phased budget is a top-down, time-scaled budget that uses activity structure created in the PSS module. The time phased budget sessions in PTC enable you to do the following:

Create budget versions to keep track of changes in your top down budget.

Distribute amounts to charge elements of the ChBS that have been created in the PSS module.

Assign earned-value-method-related data to manage which part of the budget amount must be released.

Generate the BCWS.

To support changes in a project, you can define more than one version of a time-phased budget and trace changes through the versions.

Currently, only top down budget can be time phased. However, a workaround is available for time-phasing bottom-up budget: first create a top-down budget from the bottom-up budget. A utility is provided to perform all this automatically: Generate Structure and Top Down Budget, then time-phase the created top down budget.

Project | 7-27

Project Planning (PSS-2)

The Project Planning (PSS-2) module contains the scheduling information of the project. The project plans and their activities and milestones are defined here. SSA ERP Project does not have the scheduling functionality, so we use the functionality present in External Scheduling Packages (ESP) for project schedule development. SSA ERP Project is integrated seamlessly with Microsoft Project 2002 Standard, Professional, and Server versions.

Schedule development consists of activity definition, activity sequencing and activity duration estimating. You can create an activity definition either in SSA ERP Project or in Microsoft Project and sent to the other system for next process steps. You can only perform activity sequencing using relationships and constraints in Microsoft Project and import into SSA ERP Project. The activity duration estimating using the resource allocations along with resource calendars, leveling and capacity analysis must be performed in Microsoft Project. The resultant activity start and end dates are transferred to SSA ERP Project through the integration.

The Project Planning module serves as the main interface between SSA ERP Project and Microsoft Project 2002 to exchange the scheduling data. Various views of the actual project schedule itself will be available in Microsoft Project.

The activities contain a lot of other information required for requirements planning, execution, progress, and control. The earned value method used for time-phasing the top down activity budget is also defined in the activities.

The project baselines for performance measurement are carried out in this module.

The Project Scheduling System’s (PSS-2) features are:

Plans

Activities (Scope Definition)

Activity Relationships

Milestones


External Scheduling Links

Baselines

7-28 | Project

Plans

To register plans. A plan is used to identify an activity structure, and it contains the planned start and end dates of the project. Multiple plans can be used within one project for simulation purposes and scenario planning.

Activities and Activity Structure

The Activity structure is a commonly used hierarchical structure to split a project’s scope into smaller manageable work packages. For more details, refer to the PDM section. The scheduling information of activities consists of both planned and actual start and finish dates, and progress (percentage completed). The start date and finish date of a parent is equal to the earliest start date and latest finish date of the child activities.

The definition for spreading the budget in time periods is achieved through earned value concept. Each activity can have a separate earned value method. With the earned value concept [Cost Schedule Control System Criteria by Flemming, 1983], you can carry out the performance measurement of the project.

In Project, activities can be distinguished into three main levels. The activities in each main level are grouped into a specific type.

Main level 1: This level describes the components of the project to be executed, which are usually the deliverables of the project. A level is the roughest subdivision of the project. Activities are indicated as WBS elements.

Main level 2: At this level, WBS elements are subdivided into cost accounts. A cost account can be assigned to an organizational unit. Several cost accounts can be assigned to the same organizational unit.

Main level 3: A cost account can be subdivided into work packages for the short-term, and planning packages for the long-term. The actual project execution takes place at work packages. Planning packages are high-level budget and schedule planning. They will eventually result into one or many work packages.

In other words, activities are arranged according to a tree-like structure, with these three levels. In this structure, cost accounts cannot be structured into a hierarchy, unlike WBS elements, work, and planning packages. In addition, an activity cannot have more than one direct parent.

Project | 7-29

Activity Relationships

An activity relationship means a relationship between two activites or relationship between activities and budget lines. Activities are sequenced with respect to work and specific dates to provide realistic schedules. The relationship indicates that a certain activity (successor) cannot start or end until another activity (predecessor) starts or ends. There can be four types of relationships :

Finish-to-start: The initiation of the task of the successor depends upon the completion of the task of the predecessor.

Finish-to-finish: The completion of the task of the successor depends upon the completion of the task of the predecessor.

Start-to-start: The initiation of the task of the successor depends upon the initiation of the task of the predecessor.

Start-to-finish: The completion of the task of the successor depends upon the initiation of the task of the predecessor

Milestones

A milestone is an activity with zero duration, and represents a relevant event. Milestones determine the moment of invoicing, and the calculation of the earned value.


The main function of using Microsoft Project is to determine scheduling information for both work packages and budget lines. The main function is also used to determine the expected cost date and expected sales dates fields of estimate lines. All the resources, which include cost objects, employees, and trade groups, along with calendars that are present in SSA ERP, can be transferred to Microsoft Project for use in scheduling.

The activity structure and activity relationships are transferred to Microsoft Project and forms the basis for scheduling. The activities in Project can be divided within Microsoft Project into several subprojects. For each cost account, you can, therefore, set up a different schedule in Microsoft Project. In addition, a user can schedule a range of cost accounts, for example, all cost accounts related to an organizational unit, in one project in Microsoft Project.

7-30 | Project

Microsoft Project offers the following functions:

Use of activities, precedence relationships, resource lines (budget lines in Project terms), and calendars

Maintaining WBS

Network planning

Resource Leveling

Capacity analysis

Multi-project planning with distributed projects

Recording and display of the baselines

Modern windows functionality including user defined-columns, filters, and so on.

In Microsoft Project, you can detail the lowest level activities from SSA ERP Project, for the benefit of scheduling. One or more Microsoft Project activities can be linked to a work package of SSA ERP Project.

External scheduling links

Here, the various Microsoft Project’s projects that are linked to SSA ERP Project, along with the top linked activity, are stored. The user can delete the link manually, however, SSA does not recommend this. The proper way to disconnect the integration is from the disconnect process that you can invoke from Microsoft Project.

Base line

The base line can be seen as a snapshot of the project schedule. The base line contains the start and finish dates of all the activities and milestones. You can use these items to keep the original plan. You can also store several base lines. Whenever a new base line is planned for the project, this signifies that the scope of project has deviated considerably from the original plan and the previous baseline is no longer relevant.

You can also save baselines in SSA ERP Project from Microsoft Project.

For performance measurement, you must store one or more base lines.

Project | 7-31

Project Requirement Planning (PSS-6)

The Project Requirement Planning (PSS-6) module offers the functionality to generate and/or maintain recommendations for material, equipment, and subcontracting during the project. The recommendations are divided into purchase orders and warehouse orders and, after you confirm these recommendations, transfer the recommendations to the Purchase Control module and SSA ERP Warehousing. Another feature of this module is the generation of service orders for labor budget lines, which are linked to a reference activity. Order generation is called the project requirements planning, and also includes the generation of rescheduling messages.

This module has functionality to generate recommendations through a project requirements planning run from the control data, which is based on the actual (and final) budget. This control data is defined in the Project Budget (PTC) module.

In addition, all requirement transactions for purchase and warehouse orders are registered in order line balance. The purchase and warehouse deliveries for the project are registered in the Order History.

The service order generation works differently compared to purchase and warehouse order. You can generate service orders for free budget, as well. As a result, generating control data is unnecessary. This provides the advantage of advance notification to Service for planning purposes. The actual execution of the service order takes place only after the project is Active and budget is Actual.

Refer to the Project Progress (PPC) module for the cost flowing back to SSA ERP Project from the purchase, warehouse, and service orders.

The features of the PSS-6 module are the following:

Generate planned PRP orders

Order line balance

Planned PRP purchase orders

Planned PRP warehouse orders

History of PRP orders

Generate service orders

List of service order links by project

7-32 | Project

Generate planned orders

Using this feature, you can generate or regenerate planned orders from the Project Technical Calculation (PTC) and the Project Planning (PSS) modules.

Use this feature to generate planned PRP purchase orders and planned PRP warehouse orders required to do the following:

Order goods

Rent equipments

Mobilize subcontractors

The orders are generated based on the start date of the activity budget lines. If not present, then activity or element start date, or if this is also empty then using project start date. You can divide all the orders that have been generated into three types of orders.

Material recommendations

Equipment recommendations

Subcontracting recommendations

Material recommendations are subdivided into:

Purchase Orders: Orders for items that must be purchased by SSA ERP Order Management.

Warehouse Orders: Orders for items that are handled by SSA ERP Warehousing, which are further divided into:

Orders for standard items that have inventory in any of the warehouses. This, of course, depends on the way the warehouse clusters are setup. For standard items, SSA makes a warehouse reservation when you enter a planned warehouse order or when you confirm a planned warehouse order. At which moment this reservation will be made depends on a parameter.

Orders for customized items that are produced by SSA ERP Manufacturing and will be stored in a warehouse.

Equipment and subcontracting recommendations always result in purchase orders.

Project | 7-33

When you generate planned orders, you can use an interval for planned orders to reduce the number of orders. A time fence is also available to automatically confirm planned orders.

If this concerns a purchase contract concluded with a business partner, SSA ERP creates planned orders with a reference to that contract. If budget and or planning data are changed, rescheduling messages are generated to take action on actual orders.

Order line balance

You can see the ordering flow from budget to delivery to project. All the planned PRP purchase orders, purchase order advices, actual purchase orders, planned warehouse orders, and actual warehouse orders are displayed. Not only the orders but also the request for quotations and manually entered purchase requisitions are also captured and displayed here.

Planned purchase orders

Use this feature to plan purchase orders, and to transfer the orders to SSA ERP Order Management. You not only can create these orders from the Generate Planned PRP Orders process, but you also can enter these orders manually. All the planned PRP purchase orders must be approved before transfer the orders to SSA ERP Order Management. When you transfer the PRP purchase orders, these orders will result in purchase order advices.

These advices will be confirmed in Purchase, and result in purchase orders.

You can commingle multiple PRP purchase order advices with other purchase advices to create one purchase order, using the commingling feature present in SSA ERP Order Management.

Planned warehouse orders

Use this feature to plan warehouse orders, and to transfer them to SSA ERP Warehousing. You not only can create these orders from the Generate Planned Orders process, but also can enter these orders manually. All the planned PRP warehouse orders need to be approved before transferring them to SSA ERP Warehousing.

7-34 | Project

You can combine multiple PRP warehouse orders into one warehouse order to save a great deal of administrative work involved for processing each warehouse order.

History of PRP order

You can see the history of all the purchase and warehouse orders that are delivered at a project warehouse or to a project site. All the details regarding the cost objects, the objects’ quantities, and the project information are presented.

Generate service orders

Apart from the purchase and warehouse orders, you can generate service orders for project labor requirements. A mapping between project labor cost object and reference activity of service is done to define any service requirements for projects. You can generate service orders to do the following:

Handle the contract lifecycle, including warranty and maintenance

Execute project-driven organizations, including installations.

Unlike PRP purchase and warehouse orders, no planned service orders are generated. As a result, no approval step is required. Here, you will directly create a service order in SSA ERP Service. The labor budget line will provide the planned start and finish times for the service order activity. Similarly, the resource requirements for the generated service order activity will be based on the reference activity linked to the labor budget line.

To create clusters, you can use the as-built structure of project product for service and maintenance. Refer to the description of physical breakdown sources features in the Configuration Management module of SSA ERP Service.

List of service order links by project

Use this feature to view the progress of the service orders and service order activity lines linked to the project. You can enter new service order activity lines. You can also edit all the existing service order activity lines that do not have the status Costed.

Project | 7-35

You can view the statuses of service orders and their activities and their start and end dates.

Project Progress (PPC)

The Project Progress (PPC) module contains functionality to measure, register, and monitor progress, cost, and revenues during the execution of a project. This module is divided into two parts:

Project Progress is the part where the actual data is registered or where entries are collected for confirmation and processing to SSA ERP Financials and project cost history. Use this part to register and control all the information needed when you carry out a project.

Project Monitoring is the part where you compare the budgets with the actual and permitted data and where the (possible) consequences are visible. Use this part to monitor the project based on the progress, revenues, and costs that have been recorded in Project Progress (PPC) in regard to the project budget. The Project Monitoring part is described in the following section.

The features that belong to PPC Progress are:

Progress This feature offers the possibility to maintain the project progress for all cost types, at various levels, including activities, elements and extensions.

Costs: Here, the actual costs and commitments are registered or collected from other packages.

Revenues: All the revenues of a project are registered. This registration is either the result of project invoicing or you can perform this procedure manually.

Financial Results: This feature is intended to take profits, losses, and/or financial reservations during the execution of projects, for example, at the closing of the financial year. The final result is taken when the project is closed.

Extension Transactions: Project contract quantities, prices, and/or the time spent for specific project parts can vary and be billable. Use this feature to maintain the required information and generate transactions for invoicing.

7-36 | Project

Processing: This feature enables you to send the costs, revenue, extension transactions, financial results to project history and SSA ERP Financials. The costs and revenues from SSA ERP Financials and the revenues, which are generated by SSA ERP Central Invoicing, are processed as well.

Progress

The progress of a project can be registered for the following:

Elements: element, element/cost type, element/cost object.

Activities: activity, activity/cost type, activity/cost object.

Extensions: extension/cost type, extension/cost object.

Progress registered at the cost object level is the physical progress based on the units and quantities completed.

Progress is used to determine the quantities and costs permitted and can be used for invoicing. Progress invoicing is intended to register at element/cost type level and activity/cost type level. Progress at activity/cost type level is used for performance measurement. At the other levels, registration is intended for monitoring.

Progress can be updated globally for ranges of elements, activities, specific cost types or all cost types.

You can register progress based on generated control data. You can register progress on element budgets, while your generated control data is based on activities. But, if your generated control data is based on elements, you cannot register the progress of activities.

The activity progress can provide the same information as the activity progress does in the external scheduling packages (schedule progress). The progress of activities can be derived from the planning progress of an external scheduling package, for example, Microsoft Project.

If the project invoicing method is progress or unit rate, the interim valuations (progress) can be registered to create progress invoices.

Forms can be printed to note down progress on site.

Project | 7-37

For an SSA ERP Project activity, you can see the time-based progress of the accompanying PCS projects. You can link activities (or milestones) to customized items in PCS. You can also report the progress for each customized item in the PCS product structure to the SSA ERP Project project.

After the progress is recorded, the progress can be processed to Project Monitoring. In addition, invoicing can be carried out based on the progress of the project.

Costs

Use this to register actual costs and commitments. The user can separately store the costs for hard and soft commitments. Cost objects are used at the most detailed level of a project and register the actual hours, quantities, and costs.

Costs and/or commitments can be entered manually or result from:

Registering hours in SSA ERP People.

Purchase orders in the Purchase Control (PUR) module of SSA ERP Order Management.

Transferring project inventory or anonymous inventory from a project.

Warehouse to a project. You can perform this procedure in SSA ERP Warehousing.

Costing the lines of service order or service order activities that are linked to projects in SSA ERP Service. All the costs of service order and its activities will flow into labor cost object.

The Accounts Payable (ACP) module in SSA ERP Financials.

You can register costs for all cost types. Each of these cost lines has a unique currency. In case of Cost Plus contracts, each cost line can be marked as Billable or Non-Billable for invoicing purposes. Commitments can be entered manually for all cost types (except labor). When the actual costs are available at a later stage, these costs can be linked to commitments, based on cost object code or document number.

Every placed order or registered receipt can be a commitment, and is recorded in the commitment accounting system until the corresponding invoice is entered.

7-38 | Project

Using cost, commitment, and revenue surcharges, you can cover indirect costs. PPC provides the option to use several surcharges.

If costs and commitments are the result of actions in SSA ERP Financials or SSA ERP Order Management, SSA ERP Warehousing, SSA ERP Service, then these transactions will be created automatically. The template of surcharges (percentages) applied to registered costs can be defined by project, cost type, cost object, and by cost component. Extensions are included or excluded, depending on the extension definition.

Project costs can also be booked from the Accounts Payable module in SSA ERP Financials to SSA ERP Project, for example, an invoice with project-related costs is entered directly in SSA ERP Financials without intervention from SSA ERP Purchase.

You can maintain forecast for final results and store information by date. Hours entered in the SSA ERP People package will be recorded as labor costs. All registered and processed transactions are stored in history.

You can enter subcontracting hours to monitor subcontractors.

The Costs table provides input for the extension transactions. If the extension settlement method is provisional amount, the invoicing depends on the actual costs registered.

Cost Forecast

You can forecast the costs that would be incurred on the project so as to reflect the true performance measurement and interim results.

The cost forecast, which is the estimate at completion (EAC) of a project, is determined by one of the following formulas:

EAC = original budget + changes to the budget

EAC = actual costs + estimate to complete (ETC)

A parameter indicates which method, ETC (formula 2) or changes to the budget (formula 1), is used to determine the EAC. If the EAC is entered manually, this parameter determines whether the changes to the budget or the ETC are calculated.

Project | 7-39

Registering revenues

All the revenues of a project are registered. You can perform this registration manually or the registration can result from project invoicing. When a project invoice is printed in the Sales Invoicing (SLI) module of SSA ERP Central Invoicing, the project revenues will automatically be available. Surcharges can also be applied to revenues.

In addition, you can maintain the forecast deviations of the revenues by element and by activities against the contract. In this way, you can monitor the result in the Monitoring module. You can also enter the revenues in various currencies.

Financial results

The project costs, revenues, and profits are recognized when the project is completed. This enables you to view over/under billings and over/under costs, and the revenues situation.

Revenue recognition can also be carried out for projects that are not completed. These interim results are determined while you carry out a project.

Two interim results types are available:

Interim result revenues: Revenue recognition

Interim result costs: Cost of goods sold

These types are linked to default journal entries in SSA ERP Financials.

When you generate financial results, you can make various selections on related topics. If required, you can modify the generated interim results.

To calculate the revenue recognition of a project, you can use the following methods:

Percentage of Completion This revenue recognition method is based on the percentage of completion of the entire contract, or the percentage of completion of an extension. This method is often used for projects that do not have hardware deliverables, such as engineering or development projects. The percentage of completion is entered manually or is the result of the costs divided by the estimate at completion.

7-40 | Project

The revenue recognition Milestone method is based on the completion of milestones. This method is often used for projects that do no have hardware deliverable such as engineering and development projects.

The revenue recognition method Reimbursement Contract is based on actual costs transactions and their sales values, sometimes based on a margin. This method will be used for reimbursement contracts (Cost Plus Contracts).

Earned Revenue Factor (ERF) This method is similar to the reimbursement contract method, however, the contract type is fixed price instead of cost plus (cost reimbursement). The recognized revenue is based on multiplying the costs with an earned revenue factor. In other words (cumulative) earned revenue = (cumulative) costs for current period*ERF. You can enter the ERF manually or the ERF is calculated as project contract amount / total budgeted costs.

Actual Revenues The recognized revenues are based on the revenue amounts. The recognized revenue can be calculated based on several revenue components, which are invoiced revenues, expected revenue, and forecasted revenues.

To calculate the cost of goods sold, you can use the following methods:

Profit Percentage: This costs of goods sold is based on the recognized revenues and a profit percentage. This method is often used for projects that do no have hardware deliverables, for example, engineering and development projects.

COGS = Total Revenue Recognized to date * (1 – profit %)

In other words, the revenue is calculated and secondly the costs of goods are calculated based on the recognized revenue and the profit percentage.

Reimbursement Contract Calculate the total accrued costs, including the unbillable costs and the unpaid transactions, which are the costs that originate from unpaid purchase order invoices. Apply the overhead using the surcharges on the incurred costs.

Project | 7-41

When a project is finished, the processed financial results will be reversed. After a project is closed, the final result is available in the Monitoring module. However, during a project, you can also see the result in this module.

Extension Transactions

Progress provides input to fluctuations in extension settlements, which determines the data that is required to invoice the variations of a project contract. When the quantities or the price vary, the invoicing of these variations is based on the registered progress.

If quantities, prices, and/or the time spent vary, PPC can signal any deviations and generate the basis for invoicing the fluctuations. The project forecasts will be handled in addition to the registration of relevant project information. The expected forecast deviation of costs can be recorded.

In the extension settlement, various types can be distinguished: index fluctuations, price fluctuation settlement, quantities to be settled, and provisional amounts.

Index fluctuations means that a percentage of the contract price can be settled according to price indices. The billable amount is based on invoiced installments or on the progress. In the price fluctuation settlement procedure, the data for the price variations, for example, wage fluctuations, can be registered and maintained. The results of the procedure are generated invoices in regard to the billing of price variations. These invoices are processed by the SSA ERP Central Invoicing (CI) and can be sent to the customer, based on the invoicing method defined in the PDM module.

Budget entries that contain specific materials can be settled while taking account of possible price fluctuations for those materials. Price indices are maintained by material and date. Billing is based on progress.

Transactions will be generated for quantities to be settled. Billing is based on the element progress or the extension progress.

Provisional amount transactions will be generated for this extension type. Billing is based on the difference between actual transactions and the preliminary amount in the contract.

7-42 | Project

Processing

Costs, commitments, and revenues must be confirmed before processing. After you confirm these factors, these items are processed to Project History, Project Monitoring, and SSA ERP Financials, and enables cost invoicing. If cost surcharges are defined, extra sundry costs are generated when processing.

Project Monitoring (PPC)

Project Monitoring is the monitoring part based on the progress, budget, revenues, and costs. In this part, you compare the budgets with the actual and permitted data and where the (possible) consequences are visible. Information from various modules is combined to generate project-monitoring reports. The reports are based on quantities and amounts, and can be presented for any project level. Monitoring is based on the project currency.

A wide range of selection criteria ensures that the right data is presented to the right people. For example, including or excluding expected costs (commitment accounting) for the current or cumulative period, and with or without final result forecasts. In addition, you can see the estimated cost for the end of a project while the project runs.

The features that belong to PPC Monitoring are the following:

Build Actual Cost Control The cumulative permitted and actual cost up to a period from the start of the project will be handled here.

Control Inquiries and Reports Inquiries and reports for project control purposes is the main feature here. You can make reports not only for the current period but also for periods in the past.

Financial Analysis (Graphs) This feature provides the functionality to display costs and revenue graphs, as well as performance indicators.

Performance Measurement Provides data and reports required for effective analysis of variances. Performance measurement results from comparing of budgeted costs of work scheduled (BCWS), budgeted costs of work performed (BCWP),

Project | 7-43

actual costs of work performed (ACWP), estimate to completion, and estimate at completion.

Build Actual Cost Control

The permitted and actual cost calculation both for the current period and the accumulation from the start of the project will be determined here. The build actual cost control must be carried out to obtain up-to-date control, inquiries, and reports. The permitted costs are determined based on the budgeted costs and the progress at the element/cost object or activity/cost object level.

Monitoring is based on the project currency. Therefore, the budget and cost lines with their various currencies are converted to the project currency when you run the build actual cost control.

Control Inquiries and Reports

Inquiries and reports for project control purposes is the main topic of the Control Inquiries and Reports Business Object. For inquiries, the level of detail depends on the definition of the project control levels.

Project control inquiries are available by:

Project, project/cost type, project/control code, project/cost component

Project element, element/cost-type, element/control code and element/cost component

Project activity, activity/cost-type, activity/control code and activity/cost component

Project extension, extension/cost-type, extension/control code and extension/cost component

Zoom to details (history)

Within the control levels, the results can be reported as:

Including or excluding commitments

Quantities or amounts

In current period or cumulatively

With of without the forecast for final results

Including variances, budget, revenues, and result

7-44 | Project

A large number of reports are available to meet the organization’s requirements, for example, project control with references to purchase and warehouse orders and the status of these orders. SSA ERP enables the user to (easily) drill down to the desired level of cost control.

Financial analysis (Graphs)

Use this session to create a graph of the progression of costs and revenues during the project execution time. By analysis of the costs and revenues within a specific period, you can make a planning of the required or remaining amounts in the future. The graph shows a cost line and a revenue line. Both lines consist partly of actual amounts and partly of planned amounts. Before the reference date the actual costs and actual revenues are shown. After the reference date, the planned costs and planned revenues including the forecast are shown.

The purpose of the financial analysis is:

Liquidity forecasting

Performance measurement

Two types of graphs are available both on worktop and webtop, depending on the method of monitoring used:

Financial Analysis graph

Performance Measurement graph using EVM

The following table lists the fields that appear in each graph and their inter-relationships:

S.No Control Inquiries concept Earned value concept

1 Planned costs (budget) BCWS

2 Actual costs ACWP

3 Permitted costs (progress BCWP=EV

4 Forecasted costs ETC

S.No 1: These costs are the budgeted costs, time scaled according to a base line. The cost distribution depends on the concept used:

Control Inquires: At the beginning of the activity, or distributed

Earned Value: According to the chosen method on the activity level (see PSS)

Project | 7-45

S.No 2: The actual costs posted to the project history.

S.No 3: Determined on basis of performance according to the used concept.

S.No 4: Forecast costs inclusive of commitments. Forecasting in EV method depends on the cost forecast approach as explained in the Project Progress (PPC) module.

For both concepts:

Planned, forecasted, and actual revenues are displayed

Performance Measurement

Performance measurement is an objective measurement of how much work has been accomplished on a project. Using the performance measurement methods, members of management can readily compare how much work has actually been completed against the amount of work planned for completion.

This method integrates cost and schedule into an integrated cost schedule control system for measuring the project performance.

Therefore, the following is determined:

The budget costs of work scheduled (BCWS)

The budgeted costs of work performed (BCWP)

Actual costs of work performed (ACWP)

Budgeted costs at completion (BAC)

Estimated costs at completion (EAC)

Schedule variance, SV, the permitted costs minus planned costs (BCWP-BCWS)

Cost variance, CV, the allowed costs minus planned costs (BCWP-ACWP)

These performance measurement values are generated on four levels:

Activity

Activity/cost type

OBS element

OBS element/cost type

7-46 | Project

Project Invoicing (PIN)

To collect, prepare, and provide invoice data, with the purpose to transfer this data to the Sales Invoicing (SLI) module of SSA ERP Central Invoicing package. Several invoicing methods are supported.

The Project Invoicing (PIN) module sets up the invoicing of fixed price contracts, cost plus contracts, holdback, and extensions. Several invoicing methods are supported, as listed in the description of the module. The use of advance payment requests is supported.

In Sales Invoicing, you can manually change, finalize, and print invoices. In addition, the generic features such as discounts, VAT, and late payment surcharge are processed in Sales Invoicing.

The Project Invoicing (PIN) module’s features are the following:

Advance Payment Requests Enables you to define advances payment requests.

Installments Enables you to define installments to periodically invoice parts of the contract amount.

Progress Generates progress invoice installments.

Cost Plus Use this feature to select cost transactions for invoicing.

Integration to Sales Invoicing Collects project invoice data and transfers the data to Sales Invoicing.

Settlement of a project can take place based on a contract price, or based on the actual costs (Cost Plus). In the latter case, additional surcharges can also be settled. Settlement of extensions takes place separately.

To invoice projects and extensions, you can use several methods. The available methods can be arranged as follows:

Agreement Methods

Project - Fixed price contract Installment, progress invoice, unit rate

Project - Cost plus Unit rate, cost plus

Project | 7-47

Extension – Variations Contract amount, budgeted costs, actual costs

Extension - Provisional amount

Fluctuation settlement

Quantities to be settled

Actual costs

The following sections describe each of these methods. For each method, the PIN module is used to collect data for Central Invoicing. In this package, the invoice is generated. One invoice can cover several installments, advances, cost plus lines and so on, combined with a number of projects by using the Sales Invoicing module.

Installment invoicing

You can use installment invoicing to arrange a time-phased settlement of the contract amount. You must register predefined installments, including the installment amounts. To register the amounts, you can use a ratio of distribution based on points or percentages. In the case of points, a total number of points is assigned to the project. These points are distributed over several installments. Each point represents a proportional part of the contract amount. The use of percentages is based on the same principle.

You can use several invoices to invoice each installment can be invoiced by using several invoices.

You can make the moment of invoicing of the (remaining) installment amount dependent on completing an activity or a milestone.

Progress invoice

This concerns a special way of installment invoicing, in which the installment amounts are based on the actual progress, and the sales rates on the elements or activities. This data is collected to be sent to Sales Invoicing. In the PIN module, the data appears on the installment motivation, which serves as a basis for the installment amount. The remaining amount will be invoiced through the last installment.

In this method, a distinction is made between direct and indirect elements or activities. For direct elements or activities, costs are budgeted that can directly be charged to a product or service.

7-48 | Project

For example, budgeting asphalt in m2 to construct a road. On indirect elements or activities such as site setup, surcharges are budgeted.

Each element or activity is assigned a budgeted quantity, and a sales rate. For direct elements or activities, an agreement determines if variations can be settled. For indirect elements or activities, you must determine whether settlement takes place on basis of the progress (quantity) of the element or activity, or on basis of the total progress of the direct elements or activities. The latter method is called project progress.

Example

The example includes three elements.

E12, direct element, variations can be settled

E21, indirect element, settlement on the basis of progress quantity

TOP, indirect element, settlement according project progress

The following data applies to the elements:

Element Quantity Sales Rate Total Settlement Price

Progress

E12 110 16 1760 20 40

E21 5 200 1000 2

TOP 50.000 60 3000

The billable amounts are:

E12: 16*40 = 640

E21: 200*2 = 400

TOP: 3000*(640/1760) = 1091

Example settlement of variations:

Suppose that the progress of E12 is 135. In this case, a variation of 25 units applies. The variation will be invoiced by a separate invoice: 25 * 20 = 500.

Unit Rate

Unit rate invoicing is based on the progress and the sales rates of the elements or activities.

Project | 7-49

Cost plus

In the case of cost plus invoicing, the sales amounts are based on cost amounts plus the margin applied to each cost line. The cost plus markup percentages (margin) defined by cost type in Project Definition (see PDM). When the margin percentages are empty, then the sales amounts are calculated based on the quantities multiplied by sales prices/rates of the cost objects. To determine the invoice amounts, you can register the related quantities of cost objects during cost registration.

Extension-contract amount

This concerns a single invoice with the total amount recorded for the extension.

Extension-budgeted costs

This also concerns a single invoice, with the amounts specified by cost type. The total quantities and the sales prices/rates on the budget lines result in the amount to invoice.

Extension-actual costs

You can perform multiple invoices with this method, which is similar to cost-plus invoicing. The invoice amount is equal to the quantities and the sales prices/rates of the actual cost lines.

Advance payments

An advance payment is an agreement between the customer and the contractor as part of the contract. An advance payment is received at the beginning of the project, when the contractor has incurred some initial costs. Advance payments are registered separately. When you deal with installment invoicing, you can choose the installment, with which you want to settle the advance. Also advance-installment settlement mapping can be maintained to split the advance amount with different installments defined for that business partner. For the cost plus and unit rate invoicing methods, the amount of the advance payment will be settled with the next invoice.

7-50 | Project

Holdback

Holdback means that a part or percentage of the invoice is paid when the job is completed. This amount is determined by taking the percentage, which is recorded in the Project Definition (PDM) module and apply this percentage to the invoiceable lines. Holdback can be applied to all invoicing methods.

Integration with Sales Invoicing

The Sales Invoicing module of SSA ERP Central Invoicing receives the amounts and supporting information, such as quantity specification, milestones reached, and activities completed, from PIN for invoicing. The invoices are created, confirmed and printed in Sales Invoicing. The invoice amounts are then posted to the project revenues and the accounts receivable are created. These revenues are transferred to the General Ledger and the Revenue History.

The definition of advances takes place in Project. The remaining processing, including the settlement using the next invoice, is handled by Sales Invoicing.

VAT and discount settlement, and processing late payment surcharge and terms of payments, are centralized in Sales Invoicing.

Introduction

Enterprise Planning executes and controls the planning process in both multisite and single-site environments. The planning run supports master planning and detailed order planning for production, purchase, and distribution. Extensive analysis tools support the planner in evaluating the plan, such as simulation scenarios, planning signals, and performance indicators. Subsequently, the plan can be released to execution level.

This chapter describes the modules of SSA ERP Enterprise Planning in more detail. This chapter describes the functions and features of the following modules:

Enterprise Planning Master Data (RPD)

Master Planning (RMP)

Order Planning (RRP)

Plan Analysis (RAO)

Plan Transfer (PAT)

Enterprise Planning Parameters (RPD)

8Chapter 8 Enterprise Planning

8-2 | Enterprise Planning

The following figure illustrates the relationship between these modules:

Define Demand Plan

Plan Analysis

Adjust Planning

Master PlanningOrder Planning

Plan Transfer

PlanningHorizon

Planning Parameters Planning Master Data

Enterprise Planning Master Data

In the master data, the planning structure is set up. The structure consists of simulation scenarios, plan items, capacity resources, and plan units. In addition, you can set up rules for supplier and distribution sourcing and for lot size values.

Scenarios

You can use scenarios to simulate planning runs for various business situations. Only one scenario can be the actual scenario, representing the actual plan that can be transferred to production, purchase, and warehousing.

You can divide the scenario-planning horizon in plan periods of various lengths.

Enterprise Planning | 8-3

This enables you to forecast and plan in small periods on the short term, and in larger periods in the longer term. You can define the scenario as rolling, which periodically will re-divide the scenario-planning horizon in plan periods starting at the current date. This offers a consistent period division for the planner as time passes.

You can copy both static data, such as supplying and sourcing strategies, and dynamic data, such as planned orders, between scenarios.

You can define relationships between a central scenario and local scenarios in a multisite environment. This enables a central planning run that triggers the local planning runs. You can also aggregate and disaggregate data such as forecast and orders between the local scenarios and the central scenario.

Item data

You can define the planning settings for an item in the Item Planning Data. The plan item can be defined as Family item, which is an aggregate of multiple plan items. Another important setting is the default source, which determines if the item is supplied via production, purchase, or distribution. When you select the default source production/purchase, the actual source is determined by means of the Date-Effective Item Data session. You can also define the horizons to generate planned orders and plans for each plan item. In addition, you can define whether the plan item has an item master plan, and the types of capable to promise that are used for promising the item to customers.

Item planning default data can be used to default the previously mentioned planning settings when you insert a new item.

Aggregation relationships define which data can be aggregated and/or disaggregated between a family plan item and its child plan items, both in multisite and single-site environments.

A bill of critical materials and bill of critical capacities can be set up for a plan item. The bill of critical materials and the bill of critical capacities are used in the master planning run to explode critical material and capacity requirements, based on long term production plans. You can insert the critical materials and capacities manually or generate them based on the Critical in Planning check box in the Item Planning Data and the Critical in CTP check box in the Resource.


Resources

Resources are used to provide information about available capacity, capacity utilization, the resulting free capacity, and capacity capable to promise. All work centers that you define in SSA ERP Manufacturing are automatically inserted as resource in Enterprise Planning. However, other type of resources for which you want to plan capacity can also be defined as resource directly in Enterprise Planning.

Plan units

You must set up plan units if you want to use the workload control engine as part of master planning. Workload control performs finite leveling of capacity. This requires plan items that use the same resource to be planned simultaneously. These plan items and resources are gathered in one plan unit, which enables simultaneous planning.

Sourcing

Sourcing is the method to determine the source of supply for a plan item to satisfy demand. Sourcing can be defined on two levels.

The first level determines if the item is produced, purchased, and/or distributed. This method is called the sourcing strategy. You are not required to define a sourcing strategy. If the sourcing strategy is not defined, the default source from the Item-Planning data is taken.

The second level determines the rules that specify which suppliers and warehouses must be selected for purchasing and distribution, which is the supply strategy. For production, no second level applies in the sourcing Business Object. The supply strategy is not mandatory to use. If you do not define supply strategies, the suppliers are selected based on the priorities in the Item Purchase Business Partner session. The warehouses are then selected based on the priorities in the supplying relationships session.

You can define the supplying relationships between clusters. These relationships represent the possible supplies between warehouses. Enterprise Planning always translates the cluster to the default warehouse in that cluster. The supplying relationships are selected based on the supply strategy, or, if no supplying strategy is applicable, based on the priorities in the supplying relationships.


Master planning

Master planning calculates and controls the master production schedule, representing the long-term production plan of a company. Derived from the production plan, the resource master plan is automatically calculated, representing the capacity utilization of the critical capacities in the company. Also derived from the central production plan is the channel plan, representing forecast, actual sales volumes, and allowed sales volumes for each demand channel.

Item planning

You can generate the master planning for an item, which will, based on the demand, create a production plan, purchase plan, and/or planned distribution orders depending on the sources of the plan item. The demand can be of type Forecast, Sales Orders, Sales Quotations, Sales Schedules, and more.

The master planning runs from the order horizon of a plan item up to the planning horizon. You can run the master planning in infinite and finite mode by using workload control. In addition, you can run master planning in regenerative or net change mode. In net change mode, only plan items for which changes have occurred are selected during the run. You can also generate signals based on the master planning, warning the planner for exceptions in the resulting plan.

The master-planning engine cannot be run over the same time period as the detailed order-planning engine to avoid overlap in planning control. This approach is a horizontal instead of hierarchical approach, which means that you either generate plans or planned orders in a plan period. Usually, only planned orders can be transferred to actual orders on the shop floor and in purchasing. However, a special function is in place to move the production and purchase plans from master planning to plan orders or directly to actual SFC and purchase orders. With these functions, you can also calculate plans in the short term, which can be required when you run the master planning in finite mode by means of workload control.

An item master plan is mandatory if you want to generate the master planning for a plan item. The resulting production, purchase, and/or distribution plan can be viewed in the item master plan. In addition, the forecast and inventory plan can be maintained, and the calculated production plan and purchase plan can be edited.


The item master plan is divided in plan periods according to the plan period division as defined on the scenario in which you are working. Manufactured, purchased, and generic items can have a master plan.

The forecast and inventory plan can also be generated automatically. The forecast can be copied from a sales budget, calculated based on sales history, or aggregated or disaggregated from another plan item. The inventory plan is calculated based on the desired safety stock level in combination with a seasonal pattern.

An item master plan is also mandatory if you want to aggregate or disaggregate data between family plan items and child (family) plan items. Forecast, inventory plans, production and purchase plans can be aggregated or disaggregated, but also planned orders, actual orders, and inventory on hand. You can define aggregation or desegregation percentages for each data type.

The item master plan contains available to promise figures both for each plan period and cumulative over plan periods. These figures serve as input for available and capable-to-promise calculations, which are techniques to support order promising. Between the order horizon and planning horizon of the plan item the ATP and CTP is calculated by means of the master planning. The components and capacities to be checked for CTP are part of the bill of critical materials and capacities.

Resource planning

You can indicate for each resource whether a resource master plan applies. The resource master plan is a view on the available capacity, capacity utilization, and the resulting free capacity for each plan period as defined on the scenario in which you work. Capacity capable to promise is automatically calculated and viewed in the plan to support order promising. In addition, you can view the sources of the capacity utilization, which can be critical capacities, planned orders, actual SFC orders, service orders, and PCS activities.

Channel planning

You can determine for each plan item whether the module is channeled. A channel consists of one or more customers, for example, all customers in a region. You can maintain forecast and compare the forecast with actual sales in the channel master plan.


In addition, you can maintain allowed demand per channel. The allowed demand represents the part of the central production plan that is assigned to a certain channel.

Based on the allowed demand, the channel available to promise is automatically calculated to support order promising. Both forecast and allowed demand can also be automatically calculated by means of disaggregation from the central item master plan.

Order planning

Order planning combines material requirements planning, distribution requirements planning, and capacity requirements planning. The entire product structure, consisting of supplying relationships and bill of material relationships, is exploded. The net requirements of each plan item in the product structure are balanced by creating planned orders. The net requirements are based on the netting of firm supply, inventory, and demand, which is an integral part of the order planning. Demand can be of type Forecast, Sales Orders, Sales Quotations, Sales Schedules, and more.

Items of type manufactured, purchased, and generic can be planned by means of order planning. Based on the source of the plan item, the order planning run creates detailed planned production, purchase, and/or distribution orders for the short and middle term, dependent on the order horizon that is set for each plan item. The planned orders for manufactured and purchased items in the actual scenario can be confirmed and transferred as actual orders to the shop floor, purchase department, and the warehouse. The planned orders for generic items cannot be transferred. They only serve to explode the material requirements on the lower levels in the generic bill of materials.

Purchase items can also be ordered by means of purchase schedules rather than (planned) purchase orders. Purchase schedules support high-volume, repetitive purchase supply based on contracts. When an item is ordered by means of purchase schedules, based on changed or new demand, the order planning will directly change existing purchase schedule lines, or create new lines, taking into account the supplier’s delivery patterns.

The planned production orders result in capacity use of resources.


You can view for each resource the detailed capacity utilization based on the order planning in the resource order plan and compare it with the available capacity. In addition, all other sources of capacity use, critical requirements, SFC orders, service orders, and PCS activities are shown. This view provides a complete view on the capacity utilization for the planner.

You can create an item master plan for plan items that are fully controlled by means of order planning. You are not required to control a plan item with master planning to create an item master plan. This feature enables you to use item master plan-related functions for order-planned items. These functions are forecasting, inventory planning, and capable to promise.

In addition to the demand forecast in the item master plan, you can also use another type of forecast, which is called special demand. Consumption of special demand by actual sales demand is supported. To define special demand an item master plan is not mandatory. In this way, you can define forecast for order-planned items without item master plan.

The item order plan contains all demand and supply data of a plan item and provides a complete time-phased overview for the planner. The item order plan also contains available to promise figures. An item master plan is, therefore, not mandatory if you want to use capable to promise techniques. In the order horizon of the plan item these figures serve as input to calculate ATP and CTP as technique to support order promising. The components and capacities to be checked for CTP are part of the bill of material and routing. You can specifically indicate which materials and capacities in the entire product structure of the item must be checked for capable to promise.

Plan analysis

You can evaluate the plan resulting from the order planning and master-planning run by means of the plan analysis. The analysis consists of signals and performance indicators. A signal represents a warning for the planner that a particular element, for example, an order date or quantity, deviates from the desired planning. This facilitates planning by exception, which limits the planning effort for the planner as much as possible.

You can define signals by planner. A planner is responsible for a group of plan items. This results in signals that are only relevant to that particular planner. You can prioritize the signals, define a time horizon in which they are generated, and apply tolerances for each signal. In this way, you can customize signaling for each planner.


More than 40 types of signals are supported, such as reschedule-in, reschedule-out, and cancel order signals. Signals can apply to the order planning or to the master planning. In addition, signals can also apply to a plan item or to a resource.

Signals that are created for planned orders in Enterprise Planning can be processed automatically after evaluation by the planner. For example, a reschedule-in signal that is processed automatically changes the planned dates of the planned order to which the signal applies. Again, this is a way to minimize the efforts for the planner. Note that this functionality does not apply to actual orders, but only to planned orders.

Performance indicators translate a planning situation into the delivery performance, financial performance, capacity utilization performance, and inventory level performance of the scenario, a plan item or a resource within that scenario. You can also compare scenarios with each other on these indicators.

Plan transfer

The plan transfer converts planned orders into actual orders for the shop floor, the purchase department, and the warehouse. Often the orders are from this point onwards handled by individuals other than the planner, for example, shop floor planner, buyer, and warehouse manager. The planner, however, still controls the total plan by means of the planning views, including the actual order information, and the signals that are still generated for the actual orders, if required.

Order grouping

You can use order groups to limit the handling of individual orders. Instead, you create work packages that contain multiple orders that can be handled as one large order. You can group planned orders that share a particular characteristic into an order group.

Characteristics can be the work center where the planned orders must be produced, the warehouse to which the orders must be delivered, the date the orders must be produced, the tools the orders use, and other selection criteria. The business procedure for these planned orders will, from that point onwards, be handled on order-group level. This is also valid for the transfer of the planned orders, which means that all planned orders within one order group are transferred as a whole in one action.


Release planning

You can release the planning to the execution level by transferring the planned orders and/or the production and purchase plans. Extensive selection criteria can be used, such as planner, shop floor planner, and item group.

You can transfer planned orders independent of the status, which can be Planned, Firm-planned, or Confirmed. You can transfer in interactive mode, which gives you an overview of the planned orders selected for transfer. You can still decide in this view not to transfer particular orders, before you actually transfer to production, purchase, and warehousing.

For planned production orders and production plans, the ser can also transfer up to a predefined workload in hours on the shop floor.

Enterprise Planning parameters

You can control the behavior of certain functionality in Enterprise Planning by means of high-level parameters. Specific parameters are available to tune the performance of the order-planning run.

EP parameters

You can define the actual scenario, which is the only scenario from which you can transfer planned orders to execution level.

You can block the use of master planning and order planning. The user cannot use the sessions related to these functions.

You can decide if available and capable-to-promise must be checked during sales quotation or sales order insertion.

You can indicate if multisite planning is applicable to scenarios and plan items in the company in which you are working.


Performance parameters

You can indicate the internal memory space that will be reserved to load calendar working times that are used during the order planning and master-planning run.

You can set up the way that parallel processing is carried out. Parallel processing means that plan items are planned simultaneously on multiple bshells to speed up the order-planning run.

Work load control parameters

You can define the rules based on which the work load control engine will determine the priority of plan items that must be planned simultaneously on one resource with finite capacity.

Introduction

Order Management supports the entire sales and purchase process from start to finish. For this purpose, abundant functionality is available including Pricing; Purchase Control, including requisitions, RFQs, contracts, schedules, orders, and vendor management; Sales Control, including quotations, contracts, schedules, orders, and commissions and rebates; and Relation Management.

Important master data for Order Management

When conducting business, users today are confronted with increasingly complex organizations, internally and externally, in buying and selling processes. To support this type of complexity, a new business partner structure has been introduced in SSA ERP.

Internal business partners

You can define purchase and sales offices. A purchase or sales office is a department clearly identified in the company business model in charge to manage business partners’ sales or purchase relationships.

9Chapter 9 Order Management

9-2 | Order Management

Purchase and sales offices can be used for setting up defaults, authorizations, pricing, and so on. This entity will be handled as a cluster according to the multisite structure.

Sales office

Sales representatives can be assigned towards a sales office.

A sales office is a criterion for price agreements.

A sales office retrieves defaults concerning the applicable warehouse, order series, quotation series and contract series.

A sales office can be used as selection criterion for printing reports.

Purchase office

Buyers and ranges of items/item groups can be assigned towards a purchase office.

A purchase office is a criterion for price agreements.

A purchase office retrieves defaults in regard to the applicable financial company, warehouse, output device, and order series.

A purchase office can be uses as a selection criterion for printing reports.

External business partners

Suppliers and customers can be defined as business partners and a business partner can perform various roles. A supplier can have the following roles: buy-from, ship-from, invoice-from, and pay-to. A customer can have the following rolls: sold-to, ship-to, invoice-to and pay-by.

Dashboards

In Order Management, two dashboards are created: one for a buyer, known as the Buyer’s Dashboard, and one for an account manager, known as the Account Manager Dashboard. A dashboard is an overview session that provides a quick insight into the status of a particular object. The user is not required to go into the menus to open related sessions to see whether data is available. In the dashboard, all sessions related to the object are visible (buttons), and check boxes indicate whether data is available.

Order Management | 9-3

Pricing

The new Pricing module can manage sales prices, including promotions and discounts and purchase prices & discounts. Main enhancement is the flexibility of defining prices & discounts and enables for complex pricing requirements of each business partner. A matrix can be set up, up to six levels, with a choice of a wide range of various attributes related to business partner, order data, and item data. You can set the line item discount, up to five levels. A line item discount can be an aggregation of several discount schedules. The module enables you to make prices & discounts based on quantity or value and to simulate the changes before you make decisions. Prices for configured items are handled in the PCF module. Prices for kits can be handled, as well as transfer prices in case of triangular invoicing, in which the sales office where goods are sold from does not belong to the same financial company as the warehouse from which goods are shipped.

Prices are stored in price books. Price books are broken down in order value or quantity.

Discounts are stored in discount schedules. Discount schedules are broken down in order value or quantity.

A flexible search engine will search for the right price or discount. Every price or discount is assigned to a combination of various attributes. The order data must match these attributes before a price or discount will be applied. Attributes can be a combination of business partner data, item data, and order data.

Both order and line item discounts are available.

The Pricing application enables you to apply several discounts at line-item level, however, discount strategies, such as accumulating ordered quantities for a particular item, are also supported.

Fixed amount and percentage discounts by multiple units of measure along with advanced tracking of conditions to evaluate margins and income.

The Pricing application handles multicurrency environments.

Tools to automatically increase or decrease prices or discounts.

Simulation capabilities to support “what if” scenarios are also available.


Sales Control

Sales Control can handle the entire sales order fulfillment process, including the control of quotations, contracts, schedules, orders, and commissions & rebates.

Sales master data

In Sales Control, the following items can be handled: standard items, generic items, customized items, service items, list items, costs items, and phantoms. In addition, you can maintain the alternative item codes by alternative code system, customer, or item. The company’s item code is used throughout the procedure, but the alternative code is available and can be used in customized reports.

In Sales Control, you can add additional sales-related item data. Item descriptions for each customer are also handled here.

You can maintain profiles with user-specific default data. You can define a print device for each external document such as, for example, the order acknowledgement. You can also specify values that are used when new sales orders are created, for example: order type, warehouse, or order series. You can define various order types. Each order type defines the steps that are mandatory in the order procedure and how the steps will be executed: automatic or not.

Sales quotations

You can type in sales quotations manually or generate the quotations from sales budgets. You can quote multiple alternative lines for every quotation line, and you can attach price and discount structures to quotations. You can copy quotations from other quotations, even if the source quotation belongs to another customer or if the quotation is in history. You can copy all lines, alternative lines, and missed quotation lines in the quotation copy process.

After the sales quotation has been registered in SSA ERP, you can print and send the quotation to the customer.

You can accept or reject each separate quotation line. You can maintain and link reasons for success/failure to the quotation lines. You can also maintain and link reasons for competitors. You can generate sales orders for the accepted sales quotation lines.


If insufficient inventory is available, a parameter determines if you can block copying to a sales order.

After the inventory is processed, the sales quotation is handled as a regular sales order.

You can maintain the expected success percentage for every quotation, and change the percentage for every line of the quotation. Enterprise Planning handles the planned inventory transactions for quotations.

However, Enterprise Planning only handles the inventory if the success percentage of a line at least equals the percentage determined by the corresponding parameter or the value entered while running the program.

You can view or print the history of sales quotations. You can call the history data for each customer and for each item. You can also print and delete the quotation history.

Sales order entry

You can create sales orders manually, or by means of E-Commerce (EDI and Internet). You can also copy a sales order from another sales order. The original sales order can belong to another customer, and you can even copy a sales order from history.

Every sales order is associated with an order type. The order type enables you to indicate the settings for the order; an order can be a collect order, a return order, a cost order, a combination of these, or a regular sales order only. A cost order can only contain cost and service items, while a return order contains negative quantities only. Items sold on a collect order are issued from inventory immediately on order entry.

The way a sales order is entered in a system can be carried out in an easy way: one screen for both the order header and the lines. To support fast order entry in cases where large ranges of product references exist, you can use item proposal lists, such as kits, options, accessories, menus, Order Templates and Catalog. A close integration with the SSA Configurator is available for assemble-to-order environments. Product substitution and replacement is also supported specifically for industries with short product life cycles.


During order entry, many processes are initiated, such as credit checking, during three events: order entry, releasing to Warehousing, and confirm shipment; margin control; price & discount simulations and calculations; order promising by means of the Available To Promise (ATP) and/or Capable to Promise (CTP) functionality of the Extended Enterprise Planning application; check on available inventory in the (multisite) distribution network; inventory commitment; and so on. In addition, order-blocking capabilities are also important.

SSA ERP has been extended with multiple hold reasons, a separate release process, and a blocking history. After you maintain the sales order, you can print and send an order acknowledgment to the customer, which you can also send by means of EDI. Functionality for return management has been extended and you can now link a return order to the original document, such as an order number, shipment ID, or invoice number, which also enables you to copy relevant data from the original order to the return order. You can also print an RMA document.

Delivery constraints are a flexible way to handle deliveries based on customer requirements. Multiple delivery constraints that determine whether or not the customer will accept multiple shipment and/or backorders are managed.

The following constraints are supported: ship line complete, ship set complete, ship order complete, and ship line & cancel. Actual delivery takes place after sales orders are released in Warehousing.

You can specify the quantity for every item when the item is delivered directly from the supplier to the customer. If a sales order is booked and the quantity exceeds the predefined quantity, the Delivery Type field is automatically set to Direct Delivery and the Warehouse field is cleared. The other values of the Delivery Type field are: Warehouse and Cross-docking. Depending on a parameter, a purchase order is created directly or is created manually later on. This purchase order is delivered directly from the supplier to the customer. After processing, the purchase order the sales order that initialized the purchase delivery can be processed and invoiced

Sales orders can either be invoiced by installments or on delivery of goods. You can maintain up to nine default installment schedules. An installment schedule can be used to invoice the sales order. In addition, self-billing facilities are incorporated in the sales order procedure. The actual invoicing takes place, after sales orders are released, in the Central Invoicing module. The user can add additional costs, such as freight costs, to the sales invoice.


Change management of order is supported by the use of predefined change reason codes for display, reporting, and analyzing purposes.

To analyze the order entry process, periodically you can also view demand and lost sales information. This type of information is automatically updated during order entry.

In sales order history, you can view, print, or delete the history of sales orders. Historic data that is no longer relevant can be deleted.

The deleted data is printed out. Similar to printing or displaying data, you can select created orders, invoiced orders, or both.

The user can also generate freight orders directly from a sales order, depending on a parameter setting.

The sales order header also includes a status to support a better integration with CRM product. This sales order header status is a derived from status, and can have the following values: Free, Approved, In Process, Modified, Closed, Canceled, or Blocked.

The status is Free when the order is entered manually or generated automatically by CRM or EDI. The status is Approved at the moment the user clicks the icon to check the sales order so that the order header changes from Free to Approved. As soon the order status is Approved, the order is ready for execution. This means that, if the first activity on a line is set to Automatic, the activity will be executed immediately. The order header receives the status In Process when one of the activities is executed. The order header receives the status Modified when an existing line is changed or a new line is added. The order status changes to Closed when all requirements are delivered and invoiced. The status of the order becomes Canceled when the user clicks Cancel on the order header. As a result, a canceled order is not available for execution. The order header status is Blocked if blocking checks are applicable and being set in the order type.

Commission and rebate

Commission and rebate functionality supports the calculation and control of commissions and rebates payable to trade relations. Trade relations can either be own employees (sales people), agents (suppliers), or customers. Commissions are paid to employees or agents (suppliers). Rebates are paid to customers. Because commissions and rebates are based on quantities or amounts sold, this module is closely integrated with the sales order entry.


Agreements can be recorded on which the calculation of commission and rebates is based. From global to detailed, you can record agreements on various levels, such as: customer, relation, agreement group, project, item, and commission/rebate group.

A calculation for the relations linked to a sales order (line) is based on the relevant sales order. A parameter determines whether you can carry out a calculation interactively or automatically while you create a sales order.

You can even postpone a calculation, for example, by executing a calculation as a periodic process. This can be useful if multiple agreements are based on cumulative sales.

If you require a reservation procedure and a link exists to SSA ERP Financials, reservations are transferred to Financials. Approval procedures are applicable.

Reservations for calculated commissions for employees are always transferred to SSA ERP Financials.

History of commissions and rebates is created immediately during the calculating procedure. This history can be displayed or reported.

Purchase Control

Purchase Control can handle the entire procurement process, including the control of purchase requisitions, RFQs, contracts, schedules, orders, and vendor management.

Purchase master data

In Purchase Control, the following items can be handled: standard items, generic items, project items, service items, subcontracting items, list items, costs items, and phantoms.

In Purchase Control, additional purchase-related item data can be added. For each item, you can name a preferred supplier and an alternative supplier. You can specify the percentage of requirements to be divided among the alternative suppliers. The user can also maintain various types of data for each supplier/item combination, for example, an approved supplier list.


Purchase Control also enables you to define multiple manufacturers for each item/supplier combination.

In addition, you can register receipt tolerances for each item group, item, supplier/item, supplier, and supplier group. These tolerances are used in Warehousing to determine whether a receipt quantity unequal to the order quantity is acceptable.

You can also maintain profiles of user-specific default data. Users can type default values to specify the method of order entry they prefer. In addition, you can define some values that will probably be used when new RFQs or purchase orders are created as default values, for example, the warehouse, order series number, and order type.

Order types determine the steps that must be carried out and how these steps will be executed: automatic or manually.

Purchase requisitions

The purchase requisitions functionality will be to front end the purchasing process.

Purchase requisitions are used to enter non-system planned requirements for various types of items, including standard inventory, cost, service, and subcontract items.

The requester can also submit a requisition for an item that does not exist on the system by simply describing the item.

A requisition can result in a RFQ, a contract, or a purchase order.

Purchase RFQs

RFQs can be sent to various suppliers. You can type the quotations sent by suppliers into SSA ERP. Together with the vendor rating data, the information presented enables you to select the most suitable supplier for the items on the inquiry.

Based on existing price information, additional information also appears, which enables you to compare existing price lists and new quotations.

If suppliers do not return their quotations on time, you can print reminders.


After you make a decision, you can copy the inquiry to contract or order. You can select more than one supplier for each item. In that case, SSA ERP asks for a percentage of the total quantity to be ordered for each supplier.

After you make a decision, you can print and send a letter to thank the suppliers who were not selected.

Historical information is available related to created inquiries, copied inquiries (into an order or contract), and deleted inquiries.

Purchase order entry

You can create purchase orders manually or generate the purchase orders from various applications. Order (advices) generated by the various applications can be grouped into one Purchase Order (commingling). You can also copy a purchase order from another purchase order. The original purchase order might belong to another supplier, and you can even copy a purchase order from history.

Every purchase order is associated with an order type. The order type enables you to indicate the settings for the order. An order can be a collect order, a return order, a cost order, a subcontracting order, a combination of these various types, or simply a regular purchase order, which can be workflow-enabled. A cost order can only contain cost and service items, while a return order contains negative quantities only. Items bought on a collect order are added to inventory immediately on order entry.

During order entry, various processes are initiated, such as retrieving the right price and discount. After you maintain the purchase order, you can print an order acknowledgment after you receive a confirmation from the supplier, which can also be received by means of EDI.

Purchase orders are released to Warehousing, where a global receipt function is available. If the actual delivered goods do not match the packing slips in Warehousing, you can send a report (claim note) to the supplier and print reminders if deliveries are late.

The user can also add additional costs, for example, freight costs, to the purchase invoice. Pay-on-use and pay-on-receipt are supported. Extensive purchase matching capabilities triggered by Accounts Receivable are available.


Change management of order is supported by the use of predefined change reason codes for display, reporting, and analyzing purposes.

In purchase order history, you can view, print, or delete the history of purchase orders. Historic data that is no longer relevant can be deleted. The deleted data is printed out. Similar to printing or displaying data, you can select created orders, invoiced orders, or both.

Vendor management

Vendor management has been substantially extended by the introduction of sourcing rules, an Approved Supplier List (ASL) and vendor rating functionality.

With sourcing rules, you can predefine what percentage of products you want, such as to receive from which supplier. For more information, see also Purchase item and master data.

ASL enables to identify a supplier status for each item, such as approved, preferred, fixed, blocked, and a particular rating.

Vendor rating is based on objective and subjective criteria. The system can calculate the results of objective criteria related to receipts, quality approval, invoicing, and purchase order confirmation. The user can determine the subjective criteria by the user on a case-to-case basis. Every criteria can be rated by giving a weighting factor expressed in a percentage.

Relation Management

This module is designed to place the focus on your business partners both customers and suppliers.

This enables you to define additional information on your customer and supplier profile through the use of feature sets.

This module also enables you to assign activities to employees to handle your business partners’ needs.


Purchase contracts

The purchase contract can be defined as a normal contract or as a specific contract. The specific contracts are used in specific circumstances, for example, to support special promotion actions, such as around Christmastime.

For this reason, you cannot define two normal contracts that are both valid at the same time for the same business partner, despite the fact that this is permitted for special contracts.

If desired, you can print a purchase acknowledgment. In the contract, all relevant information around business partners can be stored, including the following:

Buy-from business partner, ship-from business partner, invoice-from business partner, and pay-to business partner, including the related address data

Delivery warehouse

Terms of delivery

Carrier

Currency and tax information

Terms of payment and late payment surcharge.

In the purchase contract, the relevant item information is stored. This information can be based on own item-codes. However, using item code systems, you can also store external used item codes in the contract lines, to make communication between customer and supplier easier.

You can also fill the applicable effectivity unit for the purchase contract lines, together with the engineering revision information.

Each contract line must be valid, as indicated with dates, between the boundaries, set on the purchase contract header.

In the contract line, you can fill the agreed quantity with other relevant quantity information, such as the following:

Order quantities:

Minimum order quantity

Maximum order quantity


Economic order quantity

Order quantity multiple

Evaluation quantity data

Other relevant data that is present on the contract line includes the delivery warehouse and the flag to indicate whether self-billing is available.

The purchase contract can be used as a delivery contract or as a means to support the purchase schedules.

Delivery contract

You can use a delivery contract for situations in which multiple purchase/sales orders lines must be defined, all covered by the same purchase/sales contract, but each order line having a different delivery date.

After you mark the contract line as being a delivery contract, you can specify at which moment these items must be delivered with the purchase/sales order. The total quantity, as specified in the Delivery Contract session, cannot exceed the contract line quantity. Each line, as defined in the Delivery Contract session, results in a separate purchase/sales order line.

Purchase schedule contract

As soon as the item that is defined in the purchase contract line can be used in purchase schedules, as indicated by a flag on the General Item data, the Purchase Schedule in Use check box will be selected. This indicates that the relevant data, such as the pricing and logistic data, which is used as input for this type of schedule, must be entered. The pricing data is also relevant for contracts that are not linked to a schedule. After you enter that information, you can set the purchase contract line to Active and link the line to a purchase schedule.


Purchase contract line logistic data

As mentioned previously, if an item defined in the purchase contract line will be used in a purchase schedule, the related logistic data must be filled in. The default data for this session is retrieved from the item- purchase business partner data, but can be changed in the logistic data itself. If no item–purchase business partner data is defined, you cannot save the contract line.

The logistic data contains the following data:

Whether the buy-from business partner is the preferred supplier or the single-source supplier. This information is required for Enterprise Planning to determine whether multiple or only one purchase schedules can be generated for that item. The priority and the sourcing percentage specify that, if demand can be spread for multiple buy-from business partners, how that demand must be spread, for example, 30 percent to supplier A and 70 percent to supplier B.

The frozen period, which indicates if changes are permitted in the short-term demand of the purchase schedule.

Capacity-related information, for example, the supplier capacity.

Lead-time information, which is used as input for Warehousing, such as:

Carrier

Internal procurement time

Safety time and supply time

Lead-time horizon

Minimum and maximum tolerances for delivery and quantity

Schedule information: Indicates what information must be exchanged, which can be:

Only the material release: You can select this option if the item is marked as a Push in the general item data, because pull items, by definition, require the material release information.

Only the shipping schedule information.

Both material release and shipping schedule information

Only the sequence shipping schedule information.


How the information exchange is carried out: EDI or other methods: If you choose EDI, the user can choose to send the related EDI message directly, without manual interaction in the process of managing the schedules.

How the exchange of information is performed, EDI or another method: If you choose EDI, the user can choose to send the related EDI message directly, without manual interaction in the process of managing the schedules.

The segment sets and the issue patterns, which are required for that schedule.

The authorization information, such as FAB and RAW period, which indicates if the supplier can start to produce end-products or purchase raw material for a particular period, which is covered under the financial responsibility of the customer.

Delivery data: How is the delivery calculation carried out and what package definitions are used for this item?

You can only make the contract line active after you activate the purchase contract line logistic data. To change the data again, you can deactivate.

Purchase contract price revisions

During the contract’s lifetime, the agreements about the price can change, for example, due to inflation. For this reason, while other data remains exactly the same, only the price information must be updated. To update this information, you must enter all the price information.

Without at least one line, you cannot make the purchase contract active. The price is set for a particular period, which is set by the effective date. If you must the change the price, enter a new effective date, and the new price becomes valid from that moment onward.

In addition, you can also store discount information using a line discount session, in which the user can enter gross or net discount amounts.

You can process the purchase contract in several ways:

Check history information.

View turnover of the contract.

Terminate or delete purchase contract.


Evaluate the purchase contract by checking if the deliveries are on track, and compare an actual situation with the contract’s end date.

Copy lines of the purchase contract to a Request for Quotation (RFQ).

Check purchase contract overview information.

Sales contracts

Sales contracts are a type of mirror of the purchase contracts, although the functionality is a somewhat more straightforward and slightly less enhanced. No options are available to define price revisions, no separate logistic data is available and the way in which sales delivery contracts are set up--always using a sales schedule, and not directly generating a sales order--is rather confusing.

You can also define the sales contract as a normal contract or as a specific contract, as is applicable to the purchase contracts.

The effective date of the contract is, by default, set to the first day of the coming month. If, for example, the current date is March 3rd, the effective date of the contract will, by default, be set to April 1st. If the current date is March 28th, the default effective date is also set to April 1st, which is also applicable for the purchase contracts.

The sales contract also consists of a header and the header’s lines. The header mainly contains the business partner-related data, while the lines contain the item-specific-related data.

In the header, you can store all the relevant information in regard to business partners:

Sold-to business partner, ship-to business partner, invoice-to business partner, and pay-by business partner, including the related address data

Sales representative employees.

Terms of delivery

Carrier

Currency and tax information

Terms of payment, payment method, and late payment surcharge


The sales contract also stores the relevant item information. This information can be based on your own item codes, but also on external used item codes, using item code systems, can be stored in the contract lines, to enable easy communication between customer and supplier.

The applicable effectivity unit can also be filled in for the sales contract lines, together with the engineering revision information. Each contract line must be valid, as indicated with dates, between the boundaries set on the sales contract header.

In the contract line, the agreed quantity, together with other relevant quantity information, can be filled in, such as price, sales price unit, related price book, discount percentages, or discount amounts, discount schedule, quantity-related information, such as the minimum order quantity.

An option is also available that indicates if quantity binding is applicable. This option enables you to compare and check, during the evaluation of the sales contract, if the called quantities covered by that contract are within the limits set as maximum and minimum contract quantity. Other relevant data that is present on the contract line is the tax code, tax-exempt reason, and the tax exemption certificate.

In addition, you can use the sales contract as a delivery contract or as a means to support the sales schedule functionality. If the user wants to generate sales orders out of this type of delivery contract, the user must enter the applicable delivery dates in a sales schedule of type Shipping Schedule.

This type of delivery schedule must be generated out of the contract lines. If the sales schedule is defined manually, this sales schedule cannot serve as a delivery contract, but then the sales schedule behaves as a normal sales schedule.

You can only generate this type of delivery schedule after you activate the line. You can activate the sales contract lines if at least the price is filled in. You can also terminate the sales contract lines.


Sales schedule contracts

No separate mark indicates that the item, as defined in the sales contract line, is dedicated for use in sales schedules, as present on the purchase side. As a result, the sales contract is valid for normal sales orders and for sales schedules, and all relevant logistic data must be filled in on the sales contract lines.

Sales contract processing

You can process the sales contract in several ways:

Check contract history information.

Check contract turnover history.

Evaluate the sales contract by checking whether the deliveries are on track, and compare the actual situation with the end date of the contract.

Terminate or delete the sales contract.

Purchase and Sales Schedule Management

Introduction

In some industries, such as the Automotive and Aerospace & Defense industries, in which the goods flow between two business partners--often the manufacturer, which can be OEMs such as Volkswagen and Boeing, and the supplier--is intensive, demand tuning is essential, and a timely execution of the delivery is crucial. The exchange of information is carried out on a regular base and, in most cases, supported by means of the Electronic Data Interchange (EDI) medium. Standards in this industry can be used to enable both parties to determine how to interpret the content of this type of electronic message.

In the SSA ERP software, a standard messaging system is used, which is called the Baan Electronic Message Interchange Standard (BEMIS), which enables communication with other standards.

In this document, the focus will be on the way in which communication is carried out. This document also describes the main characteristics.


The concept can be split into two main parts: 1) the focus is on the demanding organization that requires the items, which means a definition of the purchase schedules, and communicate that demand by means of the purchase release to the 2) sales organization, which receives that demand as a sales release and will execute delivery according to the related received sales schedule. The purchase release, which contains the schedule information of the demanding organization, is, therefore, transformed into a sales release, which also contains the related sales schedule information that is required at the delivering organization.

Purchase schedule management

The purchase schedule can be defined for these items, which require a timely delivery with high quantities. Therefore, the first step is to define in the general item data that this type of item will be used in the purchase schedules.

In addition, you must decide how this item will be triggered: using a push mechanism or using a pull mechanism.

Push and pull demand

The following two options are available:

Push demand The demand is push-driven, as defined in the purchase schedule, and is grouped from a central location, such as Enterprise planning, which has a top-down approach, which means that the delivery of the product will be performed to a central warehouse and, from there, these items will be transferred to the shop floor/assembly line. Working with push means that the delivered quantity is, in fact, more than the actual required quantity to prevent out-of-stock situations or that always the economical order quantity is delivered.

Pull demand If the demand is pull-driven, the opposite is the case: the actual demand is not determined from the top, but comes from the bottom. What is required in the warehouse, Kanban or TPOP, or at the shop floor on the assembly line, becomes the actual demand. Working with pull means that the actual demand is exactly equal to the to be delivered quantity. The planning organization determines which concept must be applied.


Purchase schedule header

The purchase schedule consists of a header with the related line. The purchase schedule header, with the header’s number, will be communicated between the two parties and that number will usually exist for a long period, for example, four years. Each purchase schedule is made specific for one item, which must be purchased and delivered in a regular interval. For example: every car needs seats. These seats must be delivered exactly on time somewhere in the production process of the car. The demand for such for such a chair is entered in the Purchase Schedule lines, while the Purchase Schedule Header contains the chair itself.

The Purchase Schedule Header can only be used after having defined a Purchase Contract for this item and having defined the Item – Buy-from Business Partner data. The data defined in these two other sessions is used as input for the Purchase Schedule.

The following information is stored in the Purchase Schedule Header:

Generation date

Purchase contract number + Contract office

Buy-from Business Partner + Address + Contact

Ship-from Business Partner + Address + Contact

Item for which Schedule is applicable

Purchase office and planner and buyer

Segment sets + Issue patters for Material Release and for Shipping Schedule

Invoice-from Business Partner + Pay-by Business Partner, together with tax information and self-billed invoice option and payment method

Purchase order type

Currency information: currency, exchange rate type, rate determiner, rate factor

How shipment is performed: shipment based or delivery based

Which warehouse receipt must be carried out + the Ship to Address

Flag to indicate if Consignment is applicable

The status of the schedule header can be active, Termination in Process, Terminated, Schedule Positions Full and Processed.


Purchase schedule lines

In the Purchase schedule line, for the item, as defined in the header, the required demand is entered or filled in by other methods, such as KANBAN, TPOP, or EP, for a particular date. The entered lines will be processed and result in related warehouse orders, to receive these purchased goods. For the push items, only one warehouse order is created, a blanket warehouse order, while for the pull items, each requirement results into a new warehouse order.

The following information is stored in the purchase schedule line:

Item, which is by definition the same as the item on the header.

Related project.

The scheduled quantity.

The planned delivery date + the planned shipment date.

The requirement type, which is determined and based on the segment and the issue date of the purchase schedule header. If the demand, as defined by the planned delivery date, lies already in the past, compared with the issue date of the header, because before the issue date, the supplier will not receive this purchase schedule, then the requirement type is set to Immediate. If the demand is for the short-term period, for example, the coming two weeks, the requirement type is set to Firm. Changes in this period may not always be fulfilled, because the period is on a very short term. The demand after the firm period, which can be defined by the user in the segments, will automatically become the planned period.

The reference ID, which is filled for call-off schedules and linked to the schedule as a reference.

The purchase release, which is communicated to the supplier. This release number is only filled in case the schedule is of type call-off, because then the demand is actually dedicated and known. For schedule lines that Enterprise Planning generates, you cannot fill this field because in a next run of EP, the old schedule lines are removed and new lines are inserted again. Therefore, it is not known if the related release has been sent or not. So, only for call off schedules the release number will be filled after that release has been sent.


Some flags, which indicate if transactions are logged – schedule text is present and – if line is Firm Planned. Firm planned means that Enterprise Planning cannot change the demand on that line.

The business partner data.

The warehouse and address, which is usually equal to the warehouse of the header, can be changed in case the purchase schedule is generated by EP and of type pull forecast. The planner can decide that, in that case, another warehouse is applicable. In addition, the Intrastat info can be filled in.

Pricing information is shown: the purchase price per unit, including the total schedule amount.

The quantities, which are shipped, received, approved, rejected.

The Advanced Shipment Notification (ASN) number, which triggered the receipt, including the receipt number + receipt date.

Some invoicing data, the purchase type, tax data and invoice related data, including invoiced quantity, invoiced amount, and invoice date.

The lines can be processed and receive the following statuses:

Created

Approved

Disapproved

Canceled

Order generated

ASN-received

Partial Received

Final receipt

Invoiced

Processed

Integrations around the purchase schedules

As mentioned previously, you can generate the purchase schedule in several ways. A short overview will be given of what integrations are present and how the integrations work.


Enterprise Planning integration

If a centralized planning is required, the items that must be treated in this way will have the flag indicator push in the General Item Data (tcibd0501m000) session. As a result, if demand is known in EP, the planning will result into purchase schedule of type Push. An integration with the SIC functionality is also available.

The condition to generate a push schedule (and not a purchase order) is that an active purchase contract must be available for this item. If this condition is not available, EP cannot generate this type of purchase schedule and will, as a type of fallback mechanism, create a purchase order.

If a decentralized planning is made, this implies that the actual demand comes from the assembly lines or from the KANBAN-warehouse orders or TPOP-warehouse orders. If for these items, which are marked as pull in the general item data, demand is entered and known in Enterprise Planning, after running the Generate Order Planning (cprrp1220m000) session, this results in purchase schedules of type Pull Forecast. These Pull Forecast schedules can then be exchanged to the supplier, so that the supplier knows what to expect and wait for the pull call-off schedules, which will actually consume the forecast. Good to know is that the pull call-off schedule receives the same identification number as for the pull forecast.

The EP planning can be run in case the item is also defined in the Item-Planning (cprpd1100m000) session and the order horizon is filled for that item.

Warehousing integration

For the decentralized planning, the actual demand comes from the warehouse. Two sessions are available, which can result in this type of pull call-off schedule. KANBAN orders are present, which is in fact a system that requires new items in case the other bin has become empty. The bin usually contains a fixed quantity.

Therefore, in the Item – Warehouse data (whwmd2510m000) session, the supply system must be specified, together with the supply quantity.

In the Generate Orders (KANBAN) (whwmd2200m000) session, you can fill in the item and the warehouse where the actual demand comes from and where these items are required. The items must be supplied from another warehouse or from a supplier. After you run the session, a purchase schedule line with purchase schedule type Call-off is added.


As mentioned previously, the condition is that first a pull schedule of type Pull-Forecast must be generated by EP.

Warehouse orders can also be of type Time Phased Order Point (TPOP), based on the reorder point of the item in a particular warehouse. You can run the Generate Orders (TPOP) session, which also results in the generation of purchase schedules of type Call-off.

In addition to the methods of generating purchase schedules by means of the Warehousing module, there are the standard integrations exist between the purchase schedules and the receipt of the items by means of warehouse orders.

Push schedules

One important distinction is related to the type of the purchase schedule. If the purchase schedule is of type Push, the warehouse order related to the schedule is a so-called blanket warehouse order.

The expected receipt is equal to the total agreed quantity, as specified in the contract. As time passes, the central demand will be consumed and each time, a part of that total agreed quantity will be received with that warehouse order. This means, in other words, that each line of such a push purchase schedule will not result in a specific warehouse order–inbound line, but result in only one warehouse order and one inbound line, which is kept open, so that multiple receipts can be booked on this inbound line.

The maximum quantity of these receipts can only be booked if the quantity does not exceed the quantities as totally specified on the purchase schedule lines.

Pull schedules

In case the purchase schedule is of type pull, then each line of the purchase schedule, with type Call-off, will result in a new warehouse order with a specific receipt line related to the order. After you confirm the receipt, the status of that purchase schedule line changes to Final Receipt (or Partial Receipt).

The purchase schedules of type Pull-Forecast will never result in a warehouse order, because these purchase schedules will always be consumed by the pull-call-off schedules.

If the exchange of information between customer and supplier is carried out with EDI, very often an advanced shipment notification will also be sent.


This means that the supplier sends an electronic signal that triggers the party who will receive these items that the items are being shipped from the supplier and will arrive soon.

At the moment this shipment arrives, to speed up the inbound process, you can read the data that was sent in that ASN and to confirm that. The ASN namely contains all items that are shipped with the quantities. This also will prevent typing errors during the inbound process.

At the moment this type of ASN is received in Warehousing, and these items are related to a purchase schedule, the status of that line will be set to ASN-received, which is not specific for pull-schedules, but also applicable for push schedules.

In case the items are received in the purchase schedule, the details of that receipt can be checked in the Purchase Schedule – Receipts (tdpur3115m200) session. The received quantity can be seen, or even modified, with the related delivered amount. In addition, the receipt number is visible, the ASN number, the packing slip, which is a document that shows in details the contents of a particular package, the packing slip quantity, the approved quantity and rejected quantity, the transaction date and a flag, which indicates whether or not the receipt was a final receipt. In addition, a flag Confirmed is present.

Line Assembly Control integration

The actual demand might come from the Assembly line. A good example is the automotive industry: at a particular moment in the production process, the engine of the car must be delivered and installed. That means that the engines of the cars must exactly be delivered in the right sequence, because each car can have another type of engine.

To support this, an integration is available with the purchase schedules, which enables these items to be called and results in actual quantities in the purchase schedule.

The session that will result in the generation of the so-called sequence-shipping schedule is the Transfer Part Supply Messages (tiasc8220m000) session. In the Sequence Shipping Data (tdpur3517m000) session, the user can see exactly which job sequence is applicable, which Vehicle Identification Number (VIN) is applicable, at which line station the item must be delivered, which assembly kit is involved, which quantity is required, and if the line is sent or not.


Process the purchase schedule

When all lines are present and defined in the purchase schedule, the total demand can be grouped into a purchase release. This release information will be sent to the supplier, so that the supplier can deliver according this demand.

To get the purchase schedule processed, you must perform the following steps:

1 Generate release lines: The release is composed and all lines are grouped together for that ship-from business partner/buy-from business partner.

2 Approve release lines: The release that is generated receives the status Scheduled. This step is not required for the purchase schedule call-off type, because they immediately result in an approved purchase release.

3 Process purchase schedules.

4 Delete purchase schedules.

5 Terminate purchase schedules: In the meantime, you can remove processed reference IDs.

Purchase release header

The purchase release is the result of the purchase schedule lines. The purchase release can be of several types:

Material Release

Shipping Schedule

Sequence Shipping Schedule

The type that is sent is determined by the relationship that is applicable between the customer and supplier. The material release contains the long-term information, for example, for the coming six months: one year, the shipping schedule contains the short-term information (0-14 days) and the sequence-shipping schedule contains the detailed information for delivery in the right sequence (1-24 hours information).

If both parties have a good relationship, exchanging all relevant information is easy, because the supplying partner can then make better forecasts.


The decision on which information will be exchanged is set as a default value in the Item – Buy-from Business Partner and the Item – Sold-to Business Partner information, while the final value is set in the purchase contract line logistic data, which is input for the purchase schedule.

You can only exchange the material release, or only the shipping schedule, or both material release and shipping schedule or only the sequence-shipping schedule.

The following table provides an overview of the type of information that will be sent and in which purchase release. For example: if only the material release is sent (number 1), the demand as present in the immediate period is sent, plus the demand of the planned period:

Demand of immediate period.

Demand of firm period

Demand of planned period

1 Only Material Release

In Material release In Material release

In Material release

2 Only Shipping Schedule

In Shipping Schedule

In Shipping Schedule

Not sent

3 Material Release and Shipping Schedule

In Material Release & in Shipping Schedule

Via Shipping Schedule

Via Material Release

4 Sequence Shipping Schedule

In Sequence Shipping Schedule

In Sequence Shipping Schedule

Not sent

If the user prints the Purchase Release (tdpur3422m000) session and selects Final Report, the user can also select Prepare EDI Messages. If these messages were not yet generated, the messages will now be generated so that the EDI messages can be sent in the EDI module.

This depends on the setting of Release EDI Message Directly in the Purchase Contract Line Logistic Data. If this check box is selected, the EDI message will be sent during the approval process of the purchase release. As soon as the EDI message is sent, the purchase release receives the Sent status.


For the purchase schedules of type Call-off, this means that, if that flag is set, immediately after the creation of the purchase schedule, the required purchase release is generated and approved, so that the EDI message is also sent immediately.

The following statuses are applicable for the purchase release header:

The purchase release can be of several types:

Preview

Scheduled

Sent

The following information is relevant information, which you can find in the purchase release header:

Release revision: if, for example, a new revision is sent each week containing the latest information, the old revisions automatically become invalid and a new revision number is generated. The user can also view the previous sent release revision number.

The release planner.

The release type: if the release is a Material Release, Shipping schedule, or Sequence Shipping Schedule.

Release status.

Buy-from business partner and Ship-from business partner + Ship-to Address.

The related warehouse.

The issue date: indicates at which moment the release was sent.

The Message per Vehicle check box, which indicates if the sequence shipping information must be sent for each item or grouped for each vehicle.

Communication channel: in most cases, EDI will be used to exchange the data.

Some forecast information.

The delivery method: if the delivery method is shipment-based or delivery-based.


Purchase release lines

You can never change the lines: this information is all grouped from the schedule. If a change is required, a new generation cycle must be carried out. This means that little information is stored in the lines:

The item is specified.

Some CUM information, which is input to enable the supplier to perform the right calculations:

The CUM start date

The prior required CUM

The shipped CUM

The Received CUM

Receipt information:

Last Suppliers ASN

Last received quantity, with the receipt number and the packing slip

Last receipt date

Tax information:

Tax country, tax code, tax exempt reason, and a tax certificate number

Purchase release lines details

In the release line details, only information appears:

The quantity is mentioned with the price

Start date and end date are listed

The requirement type: indicating the priority of delivery: immediate, firm or planned

A reference ID

Some dimension information: length, width, and thickness

Some schedule information, so that the both parties can refer to their own schedule number.


CUM handling and FAB/RAW authorizations

CUM handling

Related to the purchase release is the CUM handling. The purchase and sales schedules will be used in industries where high volumes are applicable. As a result, thousands of items will be delivered. The required quantities are summed up in a total, the so-called cumulative (CUM).

Using the CUM model, the supplying organization can calculate in detail the needs of the demanding organization. If the supplier has shipped already 500 items, and this fulfills a demand of 300 for a particular week, the other 200 items might already fulfill part of the demand for the coming week. These calculations can be performed by comparing the required CUM, the received CUM, and the shipped CUM.

In SSA ERP LN 6.1, two systems are supported: the order-based CUM model and the receipt-based CUM model. The supplier often must accept the method, which is determined by the customer who requests the items.

Working with the order-based CUM means that the unfulfilled requirements of the past are not sent again. The supplier must calculate whether or not an under-delivery is applicable. Shipped CUM and required CUM are compared.

Working with the receipt-based CUM means that the unfulfilled requirements of the past are sent. In this case, the shipped CUM of the supplier is compared with the received CUM of the customer. Under-delivery cannot take place and over-delivery is easily calculated.

After a particular period, an evaluation of the delivery process is performed and the CUM-values, which have reached high values, can be reset. If a difference between the values exists, the supplier has registered in their system, compared with the CUM values of the customer, a negotiation process can start how to deal with that difference and with which the value can be agreed to continue. An update session is also available to modify the received CUM and a session is also available to reset the CUM values.

FAB/RAW handling

If the purchase organization will purchase the items from the supplier, this often implies that the supplier will produce these items. The end product of his production process will be delivered to the supplier.


Because fluctuations in demand can occur in each industry, the supplier will be careful to produce too many items, because the demand can suddenly decline. On the other side, the supplier also must be flexible to fulfill the demand if that increases, which signifies a risk.

To reduce the risk, the purchasing organization can promise to take financial responsibility for the final products the supplier will manufacture, up to a particular quantity and up to a particular date, which is called the FAB authorization. An indicator is also present for how long that procedure is valid.

The same is applicable to the RAW authorization: that is an indicator that the purchasing organization will enable the supplier can purchase raw materials up to a particular date. This is all made visible in the FAB/RAW Authorizations (tdpur3534m000) session.

In case a decline in the demand takes place, the FAB authorization value will decrease, but the HIGH FAB will retain the old value, because that was promised. At the moment, an evaluation of the schedules is carried out, the decision can be made to reset the High FAB value and make the value equal to the FAB authorization, which in fact means that the supplier still got the full responsibility, or that the difference between the High FAB and the FAB Authorization quantity will be carried forward into the new period.

Sales schedule management

Introduction

As described previously, the purchase schedules are defined on the demanding side, often the OEM or Tier1 Manufacturer. By means of the EDI, the release is sent. In this document, no attention is paid to the EDI part, because that is mainly related to have defined a good set-up of the data.

The only thing that can be useful to know, that such a purchase release cannot be sent except before the release’s issue date. If the issue date is passed, the purchase release will be sent and that will result in a sales release of the supplier. Based on this information, the supplier must fulfill the demand, which means that all changes that are made after the purchase release is sent, the supplier cannot be held responsible, until the supplier is informed of this new release.


Now, the sales release is assumed to be present at the supplier and the document will describe the process how the supplier must treat and process this type of sales release and the related schedule.

Sales releases

The sales release is received and will be equal to the type the customer sent. The following types can be present: Material Release, Shipping Schedule and Sequence Shipping Schedule, representing the long-term demand, the short-term demand, and the demand each day.

Sales release header

In the release header, the following information appears. Note that this information cannot be changed, because that is what the customer demands and has asked for:

Release number.

Release Revision number.

Release type.

Sold to Business Partner - Ship to Business Partner and the address.

Reference information from the customer, as:

Customer release.

Customer revision.

Quantity Qualifier, which means that the customer has sent the actual quantities.

Shipment / Delivery method.

Generation date, Forecast Horizon start date and Forecast Horizon end date.

The information of the sales release cannot be changed and remains fixed. The sales release does not have a status.


Sales release lines

Comparable to the header, the lines also only contain display information. The following data is present:

Release and revision number.

Release position and release type

Schedule number, revision and position.

Customer release, revision and position.

Together with the release and the release’s lines, the sales schedule has been received. Because this information is also fixed information, the release lines cannot be processed and, therefore, no status of the release lines is present.

Sales schedule header

The sales schedule represents the following information:

Schedule number and schedule type and revision number

A flag to indicate if the sales schedule must be treated as referenced. If the schedule is referenced, this signifies that the demand of the schedule is coming from an assembly line or from a dedicated warehouse and that a reference number is present to refer to that location.

The related release

Business partner information, such as Sold-to Business Partner + address + contact and the Ship-to Business Partner + address + contact and the Invoice-to Business Partner + address

The item that must be delivered to the customer

Some reference information: what is the delivery method, the sales office, the lot selection, the old schedule number,

The name of the planner and seller

Relevant contract information

CUM related info:

Generation start date

Start date

Prior required CUM


Received CUM

Shipped CUM and the applicable CUM model (order-based or receipt-based)

Invoiced CUM

FAB and RAW data:

FAB through date

RAW through date

FAB authorization

RAW authorization

High FAB quantity

High RAW quantity

Last shipment ID

Last receipt quantity with the last receipt date and the last ASN.

Currency information such as currency, exchange rate type, rate determiner, and the rate factor

Tax information: tax country flag for self billed invoicing and if consignment is applicable.

A reason for termination can be filled in.

As you can see, the sales schedule header contains quite a lot of the same information as is present in the purchase schedule header.

The sales schedule can be processed and have the following statuses:

Created

Adjusted: during the approve process a check is made if over-delivery or under delivery is applicable. If so, this can result in an adjustment of the quantity and, therefore, the status is set to Adjusted.

Approved: the schedule is approved including the adjusted quantities

Terminated: the schedule is no longer valid

Terminated in process: the schedule header is terminated, but not all lines of the schedule are canceled or processed

Schedule positions full: the available sales schedule line numbers are full and occupied.


Processed: the sales schedule is processed

Processing in progress: the sales schedule header is processed, but not all lines are invoiced yet.

Based on these statuses, clearly the sales schedule can be treated as processed during the schedule’s life cycle and pass by various statuses.

The following processes are available:

Approve: All lines of the schedule are approved

Release to order: The related warehouse order (or sales order) is created.

Release to invoicing: Invoices are sent to Central Invoicing module

Process delivered Sales Schedules: Sales Schedule receives the status Processed

Terminate: Sales Schedule receives the status terminated

Delete Sales Schedules: Sales schedule is deleted

Delete Sales Schedules revisions: all revisions are deleted

Restore schedule: the system attempts to undo the last approval step.

Sales schedule lines

In the sales schedule lines, the quantities to be delivered are listed, based on the delivery date. The demand is made visible for each release type: the demand that belongs to the material release is shown and the demand belonging to the shipping schedule is shown. An overlap, for example, of the immediate demand, can occur.

The following information is present in the sales schedule lines:

Schedule, schedule type, schedule revision with the position

Status of the line

A flag if the demand must be put on hold.

The planned receipt date with the start date

The time unit

The end date

The quantity and unit: this should be delivered to the customer

The requirement type of the customer: immediate, firm, or planned


The own requirement type

The warehouse from which delivery must be carried out

A lot number

Some contract information

Sold-to business partner and ship-to business partner information

Customer schedule number and customer schedule position

The reference number, for example, the VIN number

The dock location: this information is required for Warehousing

The ship-to address

More details about the item: length, width, and thickness

The price of the item with the total schedule line amount

Tax information: country, tax code, tax exempt reason, and tax certificate

Invoicing info: Intrastat info, sales type, last invoice date, last invoice company, last transaction type, and last invoice

The linked order information: the order origin, warehouse or sales (or sales order for the delivery contracts and schedules), with the order number, position, and sequence.

The deliveries already made:

Quantity

Adjustment quantity

Delivered quantity

Start date

Last delivery date

Last shipment ID

A flag if shipment correction was carried out

The lines of the sales schedule will result in a warehouse order, and the goods are then shipped to the customer. If delivery must be carried out in a fixed sequence, the sequence-shipping schedule will be used as input. After delivery, the invoice can be sent to the customer.


The following statuses are applicable for the sales schedule lines:

Created

Adjusted

Approved

Canceled

Canceling in process

Order generated

Partially shipped

Goods delivered

Released to invoicing

Invoiced

Processed

By means of the lines, more detailed information about the shipments can be viewed in the Schedule Shipment Details/Corrections (tdsls3140m000) session. If the quantity that was shipped must be corrected, the user can make that correction.

Schedule shipment details/corrections

If something went wrong, you can correct the quantities. The following information is available:

Schedule information

The shipment ID number, with the delivery date, delivered quantity, and the delivered amount and the costs of goods sold amount

You can make a shipment correction: the correction quantity can be filled with the correction date. A confirmation flag is present.

In addition, some invoicing information is also displayed.

By means of this session, you can make and confirm several new corrections.


Sequence shipping information

This session will contain data in case the Assembly Control module triggers the actual demand that must be delivered. The following information is visible in the Sequence Shipping Information (tdsls3517m000) session:

Schedule ID

Schedule position

Schedule revision

Item

Sold-to business partner and Ship-to business partner

Quantity with delivery date and receipt date

Sequence info:

Vehicle

Job sequence

Dock location

Assembly kit

Reference

This detailed information is required to perform the delivery on exactly the specified location in the assembly line.

Sales schedule reconciliation

Finally, some remarks about the sales schedules in general. Suppose, during the evaluation process, a discrepancy arises between the CUMs so that customer and supplier do not have the same information available. After discussion, the shipped CUM can be modified in the Sales Schedule Reconciliation (tdsls3131m000) session. The user can choose to adjust the shipped CUM, or can reconcile the received CUM or can adjust and reconcile.

CUM handling and FAB/RAW authorizations

In addition, on the sales schedule side, sessions are available that contain specific CUM-related information.


The shipped CUM info can be viewed in the Shipped CUM (tdsls3532m000) session and contains the transaction date, the shipment ID, the shipped quantity, the shipped CUM, the received CUM, and the status.

The invoiced CUM info can be viewed in the Invoiced CUM (tdsls3533m000) session and contains the invoice date, the invoice number, the invoiced quantity, the cumulative invoiced quantity, and the status.

CUMs can be reset in another session, the Reset Cumulatives (tdsls3230m000) session, so that the reset date will be filled and CUM value is set back to zero.

In the FAB/RAW Authorization (tdsls3134m000) session, the user can see the following information:

Schedule with reset date

Item and the description

Release date

Sequence number + Schedule type + Revision

The FAB authorization

The RAW authorization

The High FAB and the high RAW

The received CUM

The prior required CUM

Last shipment ID

The Last Receipt date

Based on this information, the supplier knows for how many items the supplier can start production and purchase raw materials without having the risk that these items cannot be sold.

Introduction

SSA ERP LN 6.1 supports numerous business processes. An important step within this type of process is the sending of relevant data to other stakeholders. To do this, you can send hard copies through the mail, but a preferred way to exchange data is to use the Electronic Data Interchange possibilities.

The advantages of using EDI are the following:

No misinterpretation of data is possible

Fast medium to exchange data

Can be an automated part of an ERP business process.

In the following sections, the basic function and features of the EDI module are listed, although no significant changes have been made compared to previous releases.

An important note is that within the SSA ERP system, an own defined EDI message structure is developed, called Baan Electronic Message Interchange Standard (BEMIS), which means that EDI messages must be converted to other EDI formats, such as EDIFACT or ASC X12, using a so-called EDI box. The BEMIS structure has a generic setup, so that whenever possible the mapping of the data with other EDI-systems can be made.

10Chapter 10 Electronic Commerce

10-2 | Electronic Commerce

Master data

Before you can use EDI, a great deal of setup must be made. As a result, codes for organizations, such as BEMIS, must be entered, the messages that must be exchanged, such as MRL001 for sending data related to material releases, the messages that are relevant for each business partner (not all business partners will need EDI messages) and the moment (the SSA ERP session) the EDI message must be generated. For example, during the Approve Release Lines (tdpur322m100) session an EDI Message for the Material Release (MRL001) must be generated.

Networks

All the EDI messages must be stored somewhere, because all the information is all electronic data. The user must define in the Network session, where the data must be stored. The business partner data is linked to this type of network.

Conversion

The conversion sessions are an important of the entire EDI module. You can enter the codes, for example, for addresses, currencies, countries, and schedule types in the system. This helps to interpret the meaning of the EDI message.

The user can see, in the conversion setups for each message, which table fields will become part of this type of message, what level the table field has in that message, and the length of the message.

When all codes are defined, the setup can be made for conversion-in data, so that incoming EDI messages can be transferred in the standard SSA ERP data, and for conversion-out data, so that messages are correctly transformed from the SSA ERP system. A good example where this functionality is required is the item code. In the SSA ERP system, an item can have code ABC, whereas at the other party, the same item has code 123. To make sure that the other party will get the right information, this type of conversion must be made.

In addition, you can define specific conversions for each business partner, and you can perform import and export of messages.

Electronic Commerce | 10-3

Communication

A separate module is present that handles the processing of the EDI messages. Messages can be generated for a particular network or being imported from a particular network.

If message-generation fails, and required changes are made (either in ERP or in the EDI module), you can try again to generate EDI messages.

Message data

You can view the messages that were received. If the conversion failed so that the message could not be processed, the old data remains there, and you can retry to perform the conversion. The user can always see the old data.

In the outgoing file, the EDI-messages are stored, which must be processed. If processing the message was successful, the data for being processed is removed from the Messages to Be Generated session. In the history sessions, all relevant data is still available for the user.

General

In EDI, the sessions that are triggering the BEMIS EDI message are defined. As a result, the functional session, for example, the Print Release session checks if the session is defined in EDI and, if so, a trigger is set in EDI that a BEMIS EDI message must be created for the printed release.

10-4 | Electronic Commerce

The following table lists the messages that can be generated from the various SSA ERP entities:

Code Name of the message Related Business Object where message is used

DIS Dispatch Advise ASN

FML Load info to Carrier Freight Management

FMS Carrier Status info Freight Management

INV Trading Invoice Invoice

MRL Material Release Purchase Schedule

OCA Order Change Acknowledgement

Purchase Order & Sales Order

ORC Order Change Purchase Order & Sales Order

ORD Orders Purchase Order & Sales Order

ORS Order Response Order Management

RAD Remittance Advise Financials

SEQ Sequential Shipping Schedule Purchase Schedule

SHP Shipping Schedule Purchase Schedule

ERN Error Notification

RDN Receipt Discrepancy Notification

Receipt

You can group data from multiple Business Objects into one EDI message. The order information, for example, also contains address information, which is another Business Object.

To be able to compare data present in an EDI message, a print session called the Print Compare Conversion Setups (ecedi5400m000) session is available, which provides an overview of which data is present in the incoming messages and which data is present in the outgoing messages.

Introduction

The Central invoicing package only contains the Sales invoicing module.

Sales Invoicing

The Sales Invoicing (SLI) module creates invoices and credit notes from a central point within SSA ERP. It is possible to centrally control the creation and sending the invoices to the business partners. Order data from the various logistic and financial modules belonging to the same business partner can be composed into a single invoice. Thus it is possible to send consolidated, few invoices to the business partner. These invoices can be printed or they can be sent to business partners via EDI.

The links to the various modules are depicted in the next Figure.

11Chapter 11 Central Invoicing

11-2 | Central Invoicing

SLS

INH

SOC

CTM

MSC

CLM

PIN

CMS

FOC

ACR

CMG

SLI ACR

EDI

COM MCS

GLD

Invoice data that can be received from logistics can be Sales orders, Warehouse orders, Service orders, Service Contracts, Maintenance Sales orders, Service Calls, Projects, Rebate orders, Freight orders. Invoice data that can be received from Financials can be Interest invoice data, Debit/Credit note data. For the non-order related sales, manual sales orders can be raised within Sales Invoicing.

By using Billing Request Templates, the data from the various logistic and financial modules can be selected for invoicing. Billing request templates indicate on what criteria selections must be made, and whether one or several orders should be selected. The selections in the template will determine which ranges can be entered on the actual billing request. The order data from the various logistic and financial modules that is selected in the Billing request can be composed into invoices depending on the composing criteria. Once the invoices are printed (or sent via EDI), they can be posted to the Accounts Receivable open entries and to the General Ledger.

Central Invoicing | 11-3

Composing of the invoice data is done using some fixed composing criteria like Invoice-to Business Partner, Invoice-to address, Currency, Terms of payment. User-definable composing options will determine whether invoice data can be combined into one invoice. These user-definable composing options (such as tax code, shipment, department, sold-to business partner, sold-to address) can be defined by each Invoice-to Business partner. Using the user-definable composing options it is possible to collect invoice data from several business partners in the hierarchy to one invoice that can be sent to say the parent business partner.

While invoicing the sales order invoice data, the sales order has to be settled with the invoiced advance and normal installments. Also the not yet invoiced guarantee installments will be settled with the sales order invoice data. While invoicing the project installments, the installments will be settled with the invoiced advances on that project.

The invoices can be printed or be sent to the business partner through EDI. Invoices can be automatically sorted automatically based on the delivery method and the postal code applicable. The invoices get printed in the language of the business partner and the language of the tax country. For the currencies selected, it is possible to do a grand total rounding on the invoice level for the required currencies.

A payment slip can be sent to the customer along with the invoice. Customer uses the payment slip to make a payment.

The invoice will be posted to accounts receivable, Cost of goods sold and Revenue will be posted to general ledger (through integrations).

Invoice interval given by business partner gives flexibility to define different interval between invoices for each business partner. For the Counter sales, it is possible to automatically process invoice without user interaction in between.

Sales Invoicing has integration with a tax provider. When the tax provider is on, the integrated tax provider software will be used to calculate taxes on the invoice.

Disposing of the fixed assets is possible through manual sales orders in Sales Invoicing. An invoice can be created for the disposed asset and can be sent to the business partner.

11-4 | Central Invoicing

The Sales Invoice module supports triangular Invoicing and bilateral invoicing. In the below processes, the external and internal sales invoice generation is handled by Sales Invoicing. The automatic creation of purchase invoice is handled in Accounts Payable.

Warehouse can send internal invoices to other warehouses in case of warehouse transfer). Work center can send internal invoice to other work center in case of WIP transfer. Warehouse can send internal invoice to sales office in case a warehouse not belonging to the same financial company as the warehouse executes the order. Purchase office can send internal invoice to the sales office in case of direct delivery. Shipping office can send internal invoice to the sales office in case the shipping office not belonging to the same financial company as the sales office ships the goods.

Inter-company settlement: If there is transaction between two logistic companies, then such a transaction is treated as an Inter-company transaction. Such a relation is regarded as a normal buy-sell relation. But if the two entities belong to the same financial company then open entries for Accounts Receivable and Accounts Payable will be suppressed. All purchases and sales between logistic companies will be booked to a inter company billing and clearing account respectively. A report for such inter-company settlement transactions is available.

Introduction

This chapter describes the following SSA ERP Manufacturing modules in more detail:

Engineering Data Management (EDM) Item Production Data (IPD)

Bill of Material (BOM) Routing (ROU) Configurator (PCF)

Cost Price Calculation (CPR) Assembly Planning (APL) Assembly Control (ASC)

Manufacturing Control (MFC) Shop Floor Control (SFC) Project Control (PCS)

Repetitive Manufacturing (RPT) Tool Requirements Planning (TRP)

Product Classification (GRT)

12Chapter 12 Manufacturing

12-2 | Manufacturing

Engineering Data Management (EDM)

Throughout a product life cycle, the product specification is often changed. It is important that the product specifications are kept up to date. The EDM module enables you to maintain revisions linked to items.

This module consists of the functionality described in the following sections.

Product structure engineering Product structures are defined and maintained in EDM. After the engineering phase, the new product structures are available for use in SSA ERP .

Revision control

Engineering is performed per revision. In the ERP package, you can refer to the revisions defined in EDM.

Mass BOM changes Mass BOM changes enable you to update multiple BOMs in Manufacturing in one go. Actions are defined for MBCs. The actions inform you which changes must be performed on the items that are linked to the MBC.

Approval procedures

Revisions and Mass BOM Changes must be approved before the engineering changes can be made available to other modules (Item Data and Bill of Material). By default, a two-step procedure is available. First, the revision and MBC is approved for production. This status identifies that the engineering changes are approved. After engineering changes are ready to be copied to the Item Data and Bill of Material modules, the revisions and MBCs are approved for engineering.

Linking a change proposal defined in Object Data Management to the revision or MBC can extend the approval procedure.

Manufacturing | 12-3

Interface to SSA PDM

EDM can be connected to SSA PDM. The following is a short summary of the main SSA PDM features:

Definition of item data and BOMs

Definition of item revisions

Linking of documents (revisions) to items (revisions)

Workflow management to support the engineering processes

Transfer of data from multiple CAD systems

Direct access from the SSA PDM module to linked documents and CAD drawings

And more.

Item Production Data (IPD)

The item data in SSA ERP is completely restructured. In SSA ERP, there is now one central module, called Item Base Data (IBD) in which general item data such as the item description, item type, item grouping, and so on, is maintained. The IBD module is used to control item data that is not application-specific and that is used in most of the other SSA ERP modules. Each SSA ERP application uses its own specific item data module but has access to the IBD module.

Several new submodules exist to maintain item data concerning specific functional areas such as: manufacturing, purchasing, costing and, for example, sales. Item data related to SSA ERP Manufacturing is located in the Item Production Data (IPD) module.

The Item Production Data (IPD) module is the central module in SSA ERP Manufacturing that provides support to other components in Manufacturing. The IPD module contains manufacturing-related item data such as:

BOM data

Routing data

Backflush data

Repetitive data


Order parameters

Routing units

Default item production data can be defined before maintaining item production data. This option saves entry time during the definition of item production data, because default information automatically appears when an item is defined for a specific item type and item group combination.

The item code now consists of 50 characters (alpha-/numerical) in multiple user-definable and flexible segments. Per segment, you can zoom to the separate subprocesses.

Information about customized items, standard-to-order items, and calculation parts are also stored in the IPD module. Most attributes of plan items (MPS items) are maintained in Enterprise Planning; other more manufacturing-related attributes are maintained in the IPD module.

The new item base data and item production data allows:

A more modular and decoupled setup of the SSA ERP applications

A more user-friendly and flexible approach to the item data

SSA ERP to be more open to other packages. SSA ERP packages communicate with each other through DLLs. These DLLs can also be used to communicate with other software packages of partners.

Bill of Material (BOM)

Bills of material are used to define the product structure of standard and customized items. The BOM establishes the relationship (parent/child) between the end item and the components that are related to the end item. This data is important for material planning and material requirements processes.

A production bill of material can contain both manufactured and purchased items.

There are three different ways to represent bills of material:

Multilevel bill of material: A multilevel bill of material consists at level 0 (level of the end item) of at least one component that also consists of one or more components. An indented BOM is used to represent the multilevel BOM.


Single-level bill of material A single-level bill of material consists of one level of components.

Summarized multilevel bill of material In a summarized bill of material, all used bills of material in the main bill of material are replaced by their components. A compressed BOM is displayed.

Quantity-independent lines in a BOM can be used. In other words, the quantity of a component is independent of the quantity of the main item. In the production bill of materials, to model this amount, you can define quantity zero and define a scrap quantity at a BOM line.

There might be several routings by item. This configuration is recorded in the ROU module. In the bill of material, you can issue a operation number to a component. In this way the materials are connected to the operation in which they are consumed. It is also possible to link a component to different operations for different routings. This can be defined in the material-routing relationships.

Within the production BOM business object, bills of material are stored and maintained for both standard and customized items. The item code indicates whether an item is standard or customized.

Scrap quantity and scrap percentage can be maintained on production BOM line level. Per BOM line, an additional scrap percentage can be specified. Scrap percentage on BOM level does mean loss of a certain percentage during the production process. It is not defined during which process step a component will be lost. If an operation was linked to the material line, it can be expected that it is lost during the operation. This operation must be known to calculate costs/value during or at the end of an operation. If there is a combination of scrap on operation level and BOM-line level, the scrap defined for the BOM line is used as extra scrap.

Routing (ROU)

The planning data for the method of manufacturing is defined in the Routing (ROU) module. In this module, the different tasks used in the production process, along with the work centers and machines are defined. Routing consists of operations, and each operation identifies a task to be carried out in a work center and possibly on a certain machine.


Routings can be:

Standard, which means it can be attached to multiple items

Item specific.

In addition, routings can be quantity-dependent and can be defined for standard and customized items.

Routing operations can be split in operation steps to provide work instructions and other relevant production information to the operators. In addition, required tools can be defined on this detailed level.

The routing procedure consists of defining the elements (work centers, machines, and tasks) used in the operations and that must be performed to produce a standard or customized item. The result of the procedure is the routing for a particular manufactured item. Optionally, the operation steps with document numbers, process variables, and/or required tools can be defined per operation.

For anonymous environments, standard-to-order environments, and multimodel flow (repetitive-) environments, standard routings are defined in this module. For make-to-order/engineer-to-order situations, customized routings are defined. In these situations, non-generic items are manufactured.

Generic routings can be defined in the Product Configuration (PCF) module. In PCF, the entire generic model is defined. Customized routings can be generated by the PCF module based on these generic routings, according to the specific wants of the customer.

Tools (or kits containing multiple tools) can be linked to machines, tasks, and operations. This is especially important for meeting the ever-increasing demand for quality and to comply with, for example, ISO or QS 9000 quality standards. For more information on this subject, refer to Chapter 12 the section on, “Tools Requirement Planning (TRP).”

The Routing module contains the following objects:


Work Centers

This business object enables you to maintain data pertaining to the company’s work centers. Resources (people and machines) are linked to a work center. A work center is a group of resource units used as a functional planning unit. The operation rate code, linked to the work center, can be used to calculate the cost price of an item or the estimated and actual costs. The capacity load on a work center can be used in the production planning.

Work centers can be part of enterprise units that are used for multisite modeling purposes. The Enterprise Modeling (EMM) module in Common Data supports multisite modeling functionality.

Line stations (linked to an assembly line, can be used for line sequencing) and buffers (can only be part of an assembly line) are supported as special kinds of work centers, only used in Assembly Planning and Control (APL and ASC).

Machines

This business object enables you to maintain data pertaining to the machines that are linked to work centers and are used to plan operations. The rate defined for a machine can be used to calculate the actual machine costs. The capacity load on a machine can be used in the production planning.

Tasks

Tasks are used to describe activities that take place on the shop floor, and tasks are classified according to the nature of the work performed. Tasks can be linked to operation rate codes, which are used to calculate the cost price of an item or the estimated and actual costs. Tasks are also used in production planning.

Operations

This business object enables you to maintain the operation data for standard and customized manufactured items. Operation data is stored and maintained for both standard- and customized items. A series of operations is performed to manufacture an item. The sequence of operations is defined as a routing in this business object. Yield and scrap can be defined per operation.


Norm Tables

Norm tables are used to determine the run time and production rate of an operation. After a matrix is defined for two physical characteristics (for example, length and thickness), a set of standard operation times can be maintained for the X-Y coordinates. When tasks and routings are defined, the run time and production rate can be calculated by using a norm table.

Configurator (PCF)

The Product Configurator (part of Manufacturing) enables customers to specify the desired features and options for a configurable product (called a generic item) at sales quotation/order entry.

PCF has two core tasks:

Product configuration control; enforce constraints at sales time to guarantee that only buildable products are stated by the selected features and options.

Structure generation for product variants; generate the BOM and/or routings for the product based on the selected features and options.

In support of these, PCF provides:

Generic product modeling; to define the generic product, its features, and options.

Generic engineering data; to define the rules that transform the selected features and options into bills of materials ,routings, item codes, item descriptions, and other item properties.

Generic product modeling

In simple terms, these are the steps that an engineer or product modeler must perform to prepare a configured item to be ordered and produced. These steps include the following:

Define a product structure with the possible components that can make up the product

Define the routing that show the possible paths that it may take during production

Establish the constraints that control the options a user may select


Establish the rules to decide when to use which component and routing

Planning data is also defined for the BOMs and the routings. For example, a planning percentage can be defined to calculate component requirement based on a forecast for the generic item. Similarly, process time requirements can also be planned to determine operation start time and required capacity.

PCF supports sales and purchase price lists:

Base price

Option price

Price list matrix to calculate surcharges based on combination of options

Total and subtotals for reporting

Configuration and structure generation

The Sales/Customer Service representative enters the code for the desired item. For configured products, the application takes the user to the PCF module where he/she must enter values/answers in a sequence predetermined at modeling time.

PCF validates each response against the constraints until all required values are entered; the configuration is saved with the order. PCF also supports stored variants that can be used as a template to support quickly ordering look-alikes.

The sales order line with its features and options are used to generate the specific BOM and routing for the order. Depending on the order policy of the top-generic item, a PCS project is created (or used) if cost tracking is required; when the order policy is anonymous, a configured standard structure is created.

Prices can be calculated online after the product is configured; prices can also be calculated offline.

Cost Price Calculation (CPR)

Cost Accounting calculates cost prices for standard and customized items based on data related to those items, such as: bills of material, (simulated) purchase prices, routings, and surcharges.


For standard items, suggested sales prices can be calculated based on the cost-plus method. If the item’s inventory is valued by Fixed Transfer Price (FTP), the CPR module will calculate the valuation price.

The application of surcharges is flexible regarding the realization moment and warehouse. Surcharges can be defined by item, item group, warehouse, a combination of item and warehouse, or by a combination of item group and warehouse. Surcharges have a realization moment that defines the moment the surcharge value is added to the inventory value or transfer value. Item receipt surcharges are added at purchase receipt, direct receipt in production WIP (purchased items), or the completion of the production order (manufactured items). Item issue surcharges are added at issue to production WIP, or at sales delivery to the customer. Warehouse receipt surcharges are added when the items are entered into inventory. Warehouse issue surcharges are added when the items leave the warehouse.

Surcharges and operation rates attribute to the fixed or variable costs. A parameter setting enables you to exclude the fixed costs from the inventory value. This is only possible for items that are valued against the fixed transfer price. Item and warehouse surcharges are also possible for customized items.

In addition, two cost prices can be distinguished: full cost price and the variable cost price. Various simulation features enable the effects of changed prices, changed production rates, or order quantities to be assessed.

Standard cost prices are used for cost reporting and analysis. Cost prices are also used to determine planning, calculation, and financial analysis of standard items and customized items. Standard cost prices can be used for inventory valuation and contribution margin on sales prices. In the Cost Accounting module, the basis for the valuation price is only calculated if the valuation method for the item is FTP. For items that are valued against First In First Out, Last In First Out, Moving Average Unit Costs, or Lot Costing, the warehouse surcharges increases the inventory value per transfer.

The CPR module is used for calculating the estimated cost price of customized items in a project-based environment (low volumes, high number of variants, see also “Routing (ROU)”) in this chapter. The Project Control (PCS) module performs the calculation of the total project cost. The general project surcharges are stored in the PCS module.


Shop Floor Control (SFC)

The Shop Floor Control module handles creation of production orders, proper planning of production orders and the procedure related with the execution of these orders. The procedure, at macro level, consists of availability of materials and capacity, determining the order sequence, providing the necessary information through the help of various documents (including kanban labels) to the operators on the shop floor, recording all transactions of issuing material, and receiving the finished product into the warehouse. The time spent by a worker on a production order is also recorded, so the actual cost of a production order, and the production efficiency can be obtained. Controlling production orders is performed differently in SFC depending on the type of item and the type of production environment.

Positioning of production typologies

The actual manufacturing of items is handled within SFC. Production orders can be classified and controlled in several different ways, depending on the level of customization that is required for an item, and on the order policy of that item (anonymous or to order).

The following classifications are possible:

Level of customization Derived from Standard item

Derived from Generic Item

Standard item

Customized item

Fully customized A D H

Using a Lean Project B E

Not using a project at all C F

Anonymous production G

Table Chapter 12-1 Positioning of different production typologies

The situations that are not applicable are left empty. Also, situation C and E are not supported by SSA ERP ; however, some comments these situations are provided.


All other situations are explained in more detail below.

A: Fully customized, derived from standard item This situation represents when standard items are produced according to specific customer wishes. The item is fully customized, and customized BOMs, routings, and cost structures are created based on the product structure of the standard item, which serves as a template. Afterwards, engineering can take place on the customized structure. Through a PCS project, the sales order is then transferred to an SFC order. This situation applies to Engineer-to-Order / Make-to-Order. Through the PCS project code, the SFC order is pegged to the SLS order.

Material explosion is performed based on the customized BOM and routing through order planning in Enterprise Planning. If required, a run can be started for one specific PCS project. The explosion results in project-specific planned production orders, planned purchase orders, and planned distribution orders. For the lower anonymous part of the BOM, non-project-specific planned orders are generated that also supply other PCS projects that require the same anonymous parts.

B: Using a Lean Project, derived from standard item In this situation, the items are standard, but are only produced on order; consequently, standard BOMs, routings, and cost structures are used. Because items are produced on order for a specific customer, it is necessary to use some functionality of a PCS project to know the costs and to be able to peg. However, it would be too cumbersome to use all the available PCS functionality (for example, network planning or engineering is not required). Therefore, a lean project is generated, which means that all the items used in the lean project have the characteristics of Standard-to-Order (based on a parameter that can be set per individual PCS project, full PCS functionality or lean project functionality is used). A sales order will go from SLS through a lean project to SFC. Through the project code, the SFC order is pegged to the SLS order.

Through order planning in Enterprise Planning, material explosion is performed based on the standard BOM and routing. If required, a run can be started for one lean project. The explosion results in project-specific planned production orders, planned purchase orders, and planned distribution orders. For the lower anonymous part of the BOM, non-project-specific planned orders are generated that also supply other PCS projects that require the same anonymous parts.

Per lean project, the cost price can be calculated of the items related to the lean project.


C: Not using a project, derived from standard item This situation is not supported by dedicated functionality. Standard SSA ERP functionality can be used to produce these types of items.

D: Fully customized, derived from generic item There is a sales order for a normal generic item (not FAS). This item will be fully customized. Planning, forecasting, and material explosion will be performed in Enterprise Planning. PCF will be used for generating a customized BOM and a routing for a PCS project. Through this PCS project, the sales order will be transferred to an SFC order. This situation applies to Make-to-Order/Engineer-to-Order environments with relatively low volumes.

For high volumes, you can create unique standard items based on the configuration in the sales order. A PCS project is not used to avoid too much handling and to process a high volume of transactions, but full PCF configuration is, nevertheless, supported. The product variant number enables you to trace back the standard item to the sales order.

E: Using a Lean Project, derived from generic item This situation does not apply because lean projects are not possible for generic items. However, lean projects do enable you to control the manufactured items used on the lower levels of a generic product structure.

F: Not using a project at all, derived from generic item This situation is related to situation D; however, situation F applies more to high volume production environments. For these production types PCF can be used without using PCS projects.

For high volume flow production of complex products and many variants for example, Automotive) generic items with order system FAS (Final Assembly Schedule) are used, (suited for mixed-model flow environments). For this situation, refer to the sections on Assembly Planning, and Assembly Control in this chapter. PCF is not used for FAS items

G: Anonymous production, standard item This situation describes the situation in which production is purely anonymous. Items are produced to stock. Ordering systems can be SIC, MRP, MPS, or manual, which makes no real difference for the manufacturing execution in SFC. The only difference in SFC compared to customized production (situation A, and (partly) D and H), is that no project code is available, so the SFC order is not pegged to an SLS order.


H: Fully Customized, customized item This situation differs from situation A because in H, customized production is started from PCS, so it is not derived from a standard item. A project code is available and will be printed on the order documents. The SFC order is pegged to an SLS order. This is applicable in real engineer-to-order environments, where the design of the item starts from scratch based on customer requirements.

Production order control

This business object is used from the start of production to its completion. The production orders are not only created in this business object, they are also reported as completed. When entered, BOMs and operations for manufactured items (both standard and customer order driven) are linked to production orders. Production orders can be entered manually, or automatically through Enterprise Planning, Statistical Inventory Control, or several warehousing supply systems such as kanban. The production process can roughly be divided in changing estimates if necessary, issuing the required materials from the warehouse, producing the items, and storing the finished products in the warehouse.

Multiple order statuses are used to control production. This mechanism enables you to determine at what stage in the production, materials can be issued, hours can be booked, and subcontracting orders can be generated. The status of the production order is updated automatically after certain steps in the production process.

Operations of released production orders can be blocked with the use of blocking reasons. Blocked operations cannot be reported completed.

This business object also enables you to record rejects for individual operations and for a production order. Recording rejects is related to the concept of scrap and yield. When scrap/yield occurs, production losses are recorded. It is possible that some items are not qualified (for example, according to an inspection) at the end of an operation.

These items can then be rejected. Rework orders can be issued to rework already finished production orders.

Reporting completed of operations can be followed by a financial transfer of WIP to the next work center.


SFC supports serialized items. On a specific moment (specified by a parameter) in the production process serial numbers are generated for every end item of the production order. On the same moment the as built structure is generated for every serial. The as-built structure is stored in the manufacturing control module. The user can fill the serial numbers of the components in this structure during the production process. The as-built structure can be adjusted too.

Production related “status” information is stored for every serialized end item. The following statuses are examples: “created”, “rejected”, “assigned”, “sent to warehousing”.

SFC handles as-built structures in two ways (defined by a parameter):

SFC is leading: In this mode SFC determines the quantities to report completed, rejected and send to or return from warehousing. The statuses of serialized items are set based on the information in the production order.

The as-built is leading: In this mode the user specifies in the as-built structure which serials are completed, rejected, sent to warehousig or returned from warehousing. Based on this information the quantities in the production order are determined.

Production order processing

In SSA ERP , during order processing, routings defined on phantom items will be included. Both the routing operations as the bills of material of subassemblies defined as phantoms are exploded during the generation of the production order. In other words, when the production order is closed, the material and hours used for the phantom component routings are taken into account when calculating the actual production results. Offsetting will be performed based on the requirement place of a phantom in the end item routing. The result is a network routing structure in SFC.

Processing of production orders implies the following:

The hours are estimated. Hours for phantom components will also be estimated. The Tools requirement is estimated.

Production order planning is set. Capacity utilization is determined.


The materials are estimated, which means that the materials estimate is filled with the components from the standard or the customized BOM (also performed for phantom components).

Allocation of materials is performed by means of planned warehouse orders (you can have negative stock on hand). Depending on the feedback from Warehousing (while executing a warehouse order), issued materials will be recorded in SFC. Therefore, both allocation and issues are performed by a warehouse order (for backflushing, a faster procedure is available).

Relation management data will be used for multisite transfers (for example, transfers of WIP between work centers, issues of materials to WIP of SFC order, settlement, and invoicing).

Production order completion

When a production order is reported completed, the completed quantities are posted to inventory by creating a warehouse order, which will be handled separately. You can post partial quantity or total production order quantity to inventory.

The quantity rejected for a production order can also be recorded. Posting to inventory will, at this moment, be performed at standard cost price or actual cost price dependent on the valuation method.

Scrap and yield

Because there can be loss in production during or after processes, often within the discrete manufacturing environment it is necessary to specify scrap and/or yield for these processes, which can be total production orders (routings) or operations.

Scrap can be both material-related and operation-related, and is always defined as a process input (such as materials, hours or semifinished products).

Yield is always operation-related and is defined as a process output (end product quantities). In addition, scrap may be specified both as a percentage and a fixed quantity, while yield always is expressed as a percentage.


There are two levels on which scrap and yield can be applied:

BOM-line level On BOM-line level, scrap may be both defined as a fixed quantity or as a percentage.

Operation level On operation level, scrap can be defined as a fixed quantity, and yield can be defined as a percentage. The fixed scrap quantity can be seen as a loss during input of the process. Yield defined on operation level means that only a percentage of the gross input will result as output after the operation is finished. Both scrap quantity and yield percentage on operation level influence planned materials and hours. In addition, subcontracting operations can have scrap and/or yield (in this situation, subcontracting costs are calculated based on the quantity of the planned output of an operation).

Production order planning

Production order planning provides the facility to modify and re-plan the production order. The planning of a production order is a process of determining the start and end dates of the individual operations and the production order. When the production order is planned, the lead-time of the operations and the production order is calculated. The load on the corresponding machines and work centers is also calculated and displayed.

The planning of a production order is based on the different factors such as the operation times (cycle time and set-up time), the normal work time of resource units, the queue-, waiting-, and move time for work centers, and the company calendar (such as number of holidays and working time intervals per day). Scrap and yield also affect the production planning. In addition, if a service order is present for service activities to run on a machine, the machine might not be available to carry out the operation.

If a production order was planned, the start date of operations, cycle time, setup time, work center, and machine on which the job must be performed can be changed. You can also change the task. New operations can be added or existing operations can be removed. The change in planning might change the due date of a production order and the cost estimate. These changes can be reflected in the planning and are based on parameters.


You can associate a single task to multiple work centers. This association allows better visibility of resources at plan creation, gives the capability to establish default setup and cycle time values at the work center/task level rather than the task level, and provides the capability to perform a work center/task validation.

Several reports show the differences between the estimates and actuals. Production delays are shown in days/hours.

Tools can be linked to operations. For more information on this subject, refer to the section, “Tools Requirement Planning.” in this chapter.

Production order subcontracting

Subcontracting is a common practice in manufacturing industries. A part of a production process can be subcontracted due to several reasons. For example, a specialized operation is needed for which the company does not have the proper facilities, enough capacity is not available, or the work is voluminous and could be expensive if carried out internally. In some companies, subcontracting is a well-planned production strategy used to decrease the cost and lead time of the product to improve customer service.

The Production Order Subcontracting business object facilitates the planning and procedure required to carry out the subcontracting of an operation. Subcontracting is based on the concept of outsourcing an operation.

Two types of subcontracting are possible:

Planned subcontracting: defined as an operation in Routing or in Project Control.

Unplanned (ad hoc) subcontracting: In unplanned subcontracting, the operation to be subcontracted is not defined on a subcontracting work center in the routing. You can shift the planning from the normal work center defined in the routing to the subcontracting work center. The capacity utilization on the work center is also transferred from the original work center to the subcontracting work center. The purchase order can be generated after the operations are subcontracted.

Subcontracting operations is only possible if the production order was released.


Production order material issue

This business object comprises the entry of issues and issuing of inventory as a part of the order procedure for production orders.

Entering of issues is required to issue the required materials from the warehouse to the shop floor. Issuing can be done manually or by the system while the estimate is being built up. When backflushing applies, issuing of inventory is carried out automatically.

Floor stock

Items can be defined as floor stock in the Item Production Data (IPD) module, and, consequently, floor stock is not formally issued against the production order. These materials are consumed directly at the shop floor and the estimated quantity is deducted.

In addition, these materials will appear on a bill of material but are not printed on order documents by default. In SFC, a warehouse order is automatically generated when releasing a production order. Next, two possibilities can occur:

The warehouse order is directly activated upon the release of the production order. Materials can be either directly issued (current date/time) or issued at the allocation date/time (requirement date/time of the material for a specific operation). This process is especially useful when using floor stock.

The warehouse order is not directly activated but will be activated as soon as materials are (manually) issued. Then, materials are also directly issued against the current date/time.

When backflushing applies, materials will always be directly issued at the moment of backflushing.

Backflushing

Backflushing is a concept in which materials are issued and hours are posted automatically (based on estimates) when the operation/production orders are reported completed.

The quantity of backflushing is based on the quantities reported back on operations and/or orders. You can either manually backflush or enable the system to automatically perform backflushing.


You can also backflush hours for individual operations when establishing the Production Order Planning. The backflushing quantity is based on the estimated man hours and the order quantity. The book date of backflushing hours is a date entered by the user, or is the planned start day of the SFC order. You can also enter a past date (antedating).

Because transfer of materials will be performed by warehouse orders, the backflushed materials imply that the system automatically generates and activates a warehouse order with a quick warehouse order procedure. These warehouse orders will be processed without user interaction.

Backflushing can be performed:

By schedule (RPT)

By SFC order

By operation

Backflushing is possible even if there are shortages for the material. In addition, negative backflushing is possible under every condition. With negative backflushing, receipt booking is performed in Warehousing.

Shop floor warehouses

SFC warehouses are a special kind of warehouses that store and control the materials needed for production. An SFC warehouse is linked to a work center, by which you can pull the materials needed for operations from inventory in the SFC warehouse linked to that operation (for example, a location in the line). Initially, the components are allocated in the BOM warehouse. Supplying is controlled through the supply system Time Phased Order Point, KANBAN, or Order Controlled/Single that both directly create warehouse orders on execution level to replenish the SFC warehouse.

If the materials in BOM are not linked to operations, inventory is issued at the first operation.

An SFC warehouse can be linked to several work centers.

If SFC warehouses are not used, inventory will be issued directly from the warehouse to the SFC order.


Production order costing

A new entity is introduced: the calculation office. The calculation office is a non-physical work center that collects the production results that are booked on order level. The calculation office also defines the employee and Financial company (enterprise unit) responsible for the order results.

This business object is used to monitor the cost of production orders by comparing the actual cost of production to the estimated cost. The estimated end item unit cost is based on the production order characteristics and must be frozen at one point in time. The value of Work-in-Process can be recorded by work center. You can transfer the value of WIP from one work center to the next work center. Production results are split out in efficiency variances, price variances and calculation variances. Efficiency variances and/or prices variances can be assigned to the work center results or the order result separately.

Production order history

The Production Order History business object provides the history of item production, cost of items, item groups, and the variations in the norm times for operations. This business object also tracks the history of the quantity rejected for an operation and for the production order as well as the scrap and yield. The history of closed production orders for anonymous end items can be archived to a history company in this business object.

The record of past production performance is required to analyze the production process. For example, the actual operation times, the actual cost incurred, and the number of rejects indicates the performance of the production process. The analysis of actual time spent on an operation can be used in setting up a standard time for the operation. The actual cost analysis provides information regarding the variations in the actual cost of an item. Past performance information is useful in setting up the projected standards for the future. Statistics analysis features must be supported in an extended way. To perform archiving, you can use replicate tools.

Input output monitoring

Input/Output Control is the Capacity Control tool very well practised in the industry. With this tool it is possible to monitor and control the queues and order lead times, by balancing the inputs and outputs.


Input/Output reporting is a fundamental component of an MRP II system and provides the visibility to manage work center queues. It is a technique for capacity control where planned and actual inputs and planned and actual outputs of a work center are monitored. Planned inputs and outputs for each work center are developed by capacity requirements planning(CRP) and approved by manufacturing management. Actual input can be compared to planned input to identify when work center output might vary from the plan because work is not available at the work center. Actual output can also be compared to planned output to identify problems within the work center. Without Input/Output reporting, the following risks apply:

Unfeasible labor costs to produce manual Input/Output Control reports,

Difficult and costly monitoring of standard setup and run time accuracy due to the inability to efficiently calculate demonstrated realization factors,

More difficult, less accurate, and more labor intensive maintenance of the planned capacity profile, due to inability to efficiently calculate demonstrated load factors,

More difficult, less accurate, and more labor intensive maintenance of optimal wait time due to inability to efficiently report I/O on queue level, and

Risk of CRP tools not being used due to feedback from I/O Control reporting on the performance to the CRP plan.

Order grouping

SSA ERP provides the ability to group production orders. This improves the efficiency of the user that must interact with the system by reducing the number of individual transactions that they are required to process. A group may also be used to increase throughput at critical work centers by minimizing tooling changeovers.

Order Groups are created by selecting orders that share common attributes and then associating them together into a group identified by a group number. Orders processed in the same work center, or that consume the same material, or that share a common machine setup or tool are examples of selection attributes. After a group is created, it should be possible to perform numerous procedures on the group, such as reporting operations completed.

Order grouping should not be confused with nesting, in which case orders can be planned in such a way that a piece of material can be used more efficient; for example sheet of metal.


Project Control (PCS)

The PCS module is used for customer-order-driven production. Various project types and various item types can be distinguished resulting in different functionality. The PCS module can perform estimating, planning, and manufacturing of fully customized items and standard-to-order items. Network planning and module planning can be used to generate an activity network, possibly linked to customized BOMs and routings. Network planning can be used to estimate lead time and cost of the project. For a project, specific operation rates, subcontracting rates, surcharges, bills of materials and routings can be defined. However, for standard-to-order items, the standard BOM, routings, and costing structures are used. Project results are calculated based on actual purchase data, sales data, and production data.

A budget can generate a cost estimated and estimated sales price. In addition, budgets can be linked to sales orders and sales quotations and can be copied into a project.

Subprojects and main projects can be defined. A project structure can be built by linking subproject activities to main project activities. The main project activity drives the sub project dates. A main project can be used to accumulate budgeted costs, estimated costs, and actual costs.

Repetitive Manufacturing (RPT)

The Repetitive Manufacturing (RPT) module facilitates production control in a repetitive-type manufacturing environment. The RPT module is used for high-volume production in a multimodel-flow environment. An RPT scheduling area can be used as a multimodel flow line.

The RPT module enables you to control orders both for standard anonymous and standard-to-order (limited number of options) items. Production is planned and carried out through a schedule, which consists of planned and actual orders with end dates that coincide with a specific period. Production orders are planned based on capacity of the work center that controls the production rate (bottleneck work center). Production orders are consolidated for the schedule and then production is controlled by the schedule.


The RPT module is not meant for production in a mix-model flow environment; an assembly line defined in the Assembly Control package can be used for a mix-model flow line. A repetitive type of manufacturing environment is characterized by a high speed, large volume of production and not many variants. As such, this environment is specifically used within a Just-in-Time (JIT) environment. Components that are required in a repetitive production process can be JIT items that can also be called off through shipment schedules. SSA ERP supports all relevant EDI messages for a repetitive production environment. The production in a repetitive type of manufacturing environment is rate based (as governed by the production setup).

Assembly Planning

The Assembly Planning and Assembly Control modules support production environments characterized by high volumes and many variants. In these environments, complex configurable products are produced on flow lines.

This production type is called mixed-model flow production. Companies of this production type (for example car manufacturers), require a system that enables them to plan, schedule, and control many complex orders per day.

Assembly planning (APL) is used to calculate material requirements and generate assembly orders. The assembly orders are executed in the Assembly Control (ASC) module.

The module assembly planning provides functionality described in this section.

Sales order entry

Sales orders are entered in Order Management for products that are sold. A product variant is created at sales order entry.

Engineering & product configuration

Product structures can be defined in APL or in an external system. The generic end item, for example, a car, is defined. Underneath this item, the generic sub-items or modules are defined.


Below a module, to assemble the generic end item, a fixed BOM can be defined consisting of assembly parts that must be supplied to the assembly line.

The unit effectivity functionality can be used to define variety in the generic product structures. It can also be used to configure a customer-specific product variant.

An external PDM system can also be used to create customer-specific product structures based on the selections performed in an external configurator.

This creation process is also called “solve”. Products that have a customer-specific BOM are called “solved products.”

Product variants

After a product is configured a product variant and a specific product is created in APL. The product variant is the central entity for storing logistic-related information of the product concerned, such as the assembly order and sales order related to the product. For another package, such as ASC, the product variant is also the reference to the specific product. The generic item and the product variant together identify the specific product.

A product variant is created on sales order entry.

Master data: line/operation setup

The assembly layout is maintained in ASC.

Operations are defined in APL. The operations are assigned to the line stations.

Solved products

Solved products contain the specific product structures of every individual end item. This unique item is linked to a product variant. Solving can be done in APL. You can also retrieve the solved product from an external system.


Flattened parts

The content of every module is stored in the flattened parts. This is a one level BOM consisting of all the assembly parts. The flattened assembly parts can be defined in APL or sent from an external PDM system.

Assembly parts requirements calculation

The assembly parts requirements calculation process calculates the lower level requirements and sends those requirements to Enterprise Planning. Solved products and the flattened parts are input for those products.

Assembly order generation

Assembly orders are generated and sent to the Assembly Control module. The generation process is based on solved products and flattened parts.

Refresh/freeze assembly orders

Within a certain time fence, assembly orders are frozen. At the same time, the content of the assembly order is refreshed. In addition to this automatic refresh, there is also a manual refresh before orders are frozen.

Unit and date effectivity

Both unit and date effectivity can be used. For unit effectivity, the data will be effective for a range of unit numbers.

This is what unit effectivity can be used for.

Assembly Control (ASC)

The assembly orders generated by the Assembly Planning module are scheduled and executed in the Assembly Control module. ASC consists of the following functionality.


Line station variants

Line station variants are used to reduce the data storage and to improve performance in the execution system. It uses the similarity of order data per line station. When the order content on a specific line station is the same for multiple orders, that content is only stored once. This similar information is stored in a line station variant. The assembly orders just have a link to LSVs.

Clustered line station orders (CLSO)

Instead of performing transactions per order, transactions can be performed per line station for a specific period (bucket). Material requirements for the orders that are part of the bucket can be combined, which enables you to reduce the number of transactions and improve performance. When the transaction is performed, the system refers to a clustered line station order instead of an assembly order. Therefore, a CLSO represents all the material requirements for a line station for a day. A CLSO contains the materials for a particular line station. A CLSO contains the combined material requirements per bucket.

There are also companies that do not want to use the concept of line station based assembly control. These are low-volume companies that want to control the actual costs of each individual order. These companies can also use the assembly functionality. A parameter available enables you to indicate whether transaction processing is line station or order based.

When the transaction processing is line station based, costing is not performed per order, but per line. Production results are calculated and stored per line per period. When the user works order based, all part allocation and financial transactions are per assembly order.

Partial freeze

You can freeze assembly orders partially, which means that depending on the position of the assembly order in the process, some parts of the assembly order can no longer be refreshed. However, you can still refresh other parts.

This is handled as follows; you can link a time fence to a line segment. Suppose this time fence is called ‘F’. When on a specific moment say “now” (planned start date on segment – F) <= “Now” then everything of the order that is related to segment with freeze time fence = ‘F’ is refreshed and frozen. (This order part is within the freeze horizon now).


The frozen parts of the order can still be changed manually. You can manually change operation data (including assembly parts), if required.

Multisite assembly

In many mixed-model-flow companies, the assembly process is executed over multiple companies that have their own logistical data set. These companies can have several assembly lines in different logistical companies. A generic sub-item is assembled on a supplying line and supplied to the main line on which the final end item is assembled.

Finite scheduling

Assembly orders that are generated by APL can be finite scheduled resulting in a line mix and line sequence. During this scheduling process, priorities are taken into account. For example, sold orders have precedence of non-sold orders.

Manual change of the sequence

The sequence is recorded in a control panel. This easy to use control panel can be used to manually change the generated sequence. You can move orders to another position or to exchange the position of two orders (swapping).

Inventory check

An optional inventory check can be performed. A list of problem parts and problem orders having shortages can be displayed.

Work instructions

For each operation, work instructions can be printed. These work instructions can be printed based on triggers in the process of, for example, reporting completions. This is handled through process-triggered workflow. The user can partially determine what kind of information is printed on these instructions.


Material supply Material supply concerns the way materials must be supplied to the line.

ASC distinguishes internal and external supply. Internal supply is the movement of assembly parts from a main warehouse to the line (shop floor warehouse). External supply is the movement of goods from a supplier to the line.

Triggers can be used for pulling materials from supplier of warehouse to the right destination. For some supplying methods, these triggers can be based on events in production.

Different supplying methods can be used. These methods are defined per item/shop floor warehouse combination. The following methods are available:

KANBAN The supply of items is based on a manual trigger, such as a bar-code scan.

TPOP (time phased order point) The supply is triggered by a SIC run for the shop floor warehouse concerned. When the time phased inventory drops below a certain point, material supply must be performed.

Order controlled / batch Material supply is performed anonymously for multiple orders together, based on triggers in the assembly process.

Order controlled/ SILS (supply in line sequence) Through this method, you can supply items as part of a KIT. Material supply is performed for every assembly order separately based on triggers in the production process (although a single trigger can be used to generate kit supply for a number of consecutive orders in the assembly schedule).

For internal warehouse transfer, orders are created to supply the parts. For external supply, a shipping schedule or sequenced shipping schedule generates a purchase schedule (generation and sending of sequenced shipping schedules).

Time-horizon-driven material supply

Instead of initiating material supply based on process triggers, you can also do this based on time fences. Material supply is initiated for a line station order when that line station order coincides with a predefined time fence.


Several time fences are defined to control the generation and update of supply messages.

Closed loop

The ASC call-offs are stored in sales schedules and in sales releases. These releases (shipping and sequenced shipping schedules) are communicated to the supplier through EDI. In addition, a unique reference per KIT, station, and part is included in that information. At the supplier’s (SSA) system, this information is stored in sales schedules and sales releases. After sending the parts, they can be received by reference ID.

Progress overview per line segment

Typically, a planner is responsible for a segment. This planner can be linked to a segment. All information related to assembly orders will be visible per segment planner.

The status/progress overview per segment shows orders on the segment, based on line sequence, whereby toggle mode is available to show the orders in various modes. In addition to showing all orders, you can, for example, show the actual order on the segment or the late ones.

Progress overview per buffer

A control panel is available on which the schedule orders per buffer are displayed. A toggle function enables you to select different overviews.

Progress overview per line station

Comparable to the progress overview per buffer the progress can also be monitored per line station. This control panel enables you to perform many activities.

The control panel can be used to report line station orders (that contain the work on that order) completed easily. In addition, different views are available by a toggle function; for the line station concerned, you can display all orders or only the orders that are not yet completed.


Instead of using this line station for reporting line station orders completed, you can also use barcode functionality for this.

Process triggering

In mixed model flow production environments many activities are based on the progress information of individual orders. Consequently, when an event (selected by the user) occurs for an order on a certain line station, another activity can be started. In the system, process triggering covers the automatic start and execution of a process based on an event.

Events can trigger processes; the following are examples of events:

Complete line station order.

Offset line station order.

When an event occurs at a certain station, it can trigger the start and (automatic) execution of activities on a specified other station for example:

Request assembly start at a (supplying) line.

Print work instructions.

Generate call-off (shipping schedule or sequenced shipping schedule) against purchase schedule (for supply of shop floor warehouses).

Hours backflush

The calculation of the man and machine hours that must be backflushed differs for high- and low volume. For high-volume situations, backflushing is based on the rate specified for a line and the number of employees

In low-volume situations, backflushing is based on the duration of every operations and the number of employees required per operation.

Line surcharges

During the assembly process, line surcharges can be booked. Surcharges that are booked on an assembly line are defined per:

Assembly line for line station based transaction processing.

Assembly line and generic item for order based transaction processing.


WIP transfers

WIP transfers between lines are supported. The following steps are distinguished

Generation of a WIP transfer warehouse order line.

Issuing of the WIP from the last line station of the line.

Receipt of WIP on the first line station of the next line.

As-built structure

For every end item, a unique Vehicle Identification Number (VIN), Tail number, and so on, can be generated (in general, serial number). This number is generated when the sequence of the order is confirmed. The serial format can be any, which means that the standard legal formats can be supported, for example, ISO norm for VIN numbers for road vehicles)

As-built structure information can be collected during the assembly process (in terms of engineering modules, assembly parts with serial numbers, and so on). After closing the assembly orders, the as-built structure is copied to the as-maintained structure in SSA ERP Service.

Lean system

ASC has been designed to minimize system tasks to be performed by the users. Some examples:

When an order is reported complete on a certain line station, the system will automatically report it complete on the previous line stations.

Bar coding

ASC supports the use of bar coding. There are dedicated sessions for printing and for reading bar code.

Manufacturing control

The manufacturing control module provides easy to use dashboards and stores the as-built structures of production and assembly orders.


Dashboards: A dashboard is a quick way to access multiple sessions that are used to perform certain tasks of an end user. The dashboard is based on one objecr (f.e. Item, Business Partner, Order, etc) which the user needs to start to carry out his task. Relevant details of this object are presented on the dashboard, as well as the possibility to open the sessions in which the relevant information for this/these tasks is stored.

The following dashboards are available:

Items dashboard: From this session the following session can be accessed for an item selected on the screen:

Bill of material.

The items where the item is used in.

The routings of the item

The alternative items

The related engineering revisions

The business partners that supply the item.

Production orders

Purchase orders

Purchase schedules.

Some other relevant data is available in the dashbard for a selected item like:

Item signal

Inventory on hand

The time phased inventory presented in graphical mode.

Work center dashboard: From this session the following sessios can be accessed for a work center slected on the screen:

Utilization by week

Utilization by day

Input/output control

Resource order plan


Tool requests

Furthermore the following process can be started from this dashboard:

Build utilization

Generate input/output control

Delete inpute/output control

Request/return tools

Some other relevant data is available in the dashbard like for a selected workcenter like:

Basic week capacity,

Number of operators

Number of machines

Tool Requirements Planning (TRP)

The Tools Requirement Planning module is meant for integral tooling maintenance and control. Examples of the types of control available in SSA ERP are the following:

Purchasing of tools.

Maintaining tools.

Life-cycle management of tools Status control, refurbishing, and scrapping.

Applying tools for production and service Printing on production or service order documents.

Planning and tracking of tools The Tools Requirement Planning (TRP) module can be used to check the availability of the tools for the planned production orders in Enterprise Planning and in Warehousing. An availability check is also performed for tools when they are planned for actual production orders in the Shop Floor Control module and the service orders in the Service Order Control modules. If applicable, the SSA ERP system automatically displays an alternative tool when the required tool is not available.


Tool kits are supported to release multiple tools for an operation or a task at once. In addition, SSA ERP enables you to compose a tool that consists of multiple detachable components. All components of the tool are required for a proper operating end tool.

Based on the comparison between the planned life (in times used or hours used) and the actual use of the tools, SSA ERP can automatically generate a service order for the tool that must be refurbished or scrapped. When completing a service order, the tool master data and tool tracking data is automatically updated.

Product Classification (GRT)

Product Classification provides the ability to set up a classification and coding system for item data and to quickly find data that is required. In addition, new and/or existing items can be classified according to the defined product classification. Searching is performed through a combination of search arguments.

Introduction

This chapter describes the modules of SSA ERP Warehousing in more detail. This chapter describes the functions and features of the following modules:

Warehouse Master Data

Inventory Planning

Inventory Handling

Inventory Reporting

Inventory Analysis

Lot Control

SSA ERP Warehousing focuses on handling and replenishing goods under the roof of a warehouse, and the derived tasks to report and analyze inventory movements. Planned and actual inventory transactions are created by a particular demand for receiving or issuing goods. Any inventory movement results in a warehousing order to be executed. In fact, the warehousing orders are the communication layer between SSA ERP Warehousing and the other SSA ERP applications. As a result, tight integrations exist between SSA ERP Warehousing and the other SSA ERP applications, but at the same time the package is essentially decoupled from the rest of the SSA ERP applications. As a result, integrations towards external applications, such as WMS or ADC vendors, are possible.

13Chapter 13 Warehousing

13-2 | Warehousing

Warehouse master data

Introduction

The master data to be entered for Warehousing consists of the following elements:

Warehouses

In this Business Object, warehousing master data is defined. Depending on the complexity of the activities that take place in these warehouses and the level of control, you can enter zones and locations.

Zone

A zone is any part of the warehouse where goods can be stored. Locations with similar storage characteristics or locations handled by the same vehicle or employee can be grouped through the use of zones.

Location

A location is a distinct place in a warehouse where goods are stored. A warehouse can be divided into locations to manage the available space, and to locate the stored goods. Storage conditions, capacity data, and blocks can be applied to individual locations. Locations can have the following types:

Receiving

Inspection

Bulk

Pick

Staging

Reject

Items

Here, you must define the items used or handled by Warehousing. In item warehousing data, you can enter specific warehousing data, such as:

Valuation data

Warehousing | 13-3

Storage data

Dimensions

Besides the item warehousing data, you can also enter item data by warehouse. Here, you can enter specifics for each item and warehouse, such as:

Issue data

Lead times

Replenishment data

Other than items stored in warehouses, you can also define packaging items and package definitions here. Packaging definitions are used to specify how items must be packed. For this, you can use packaging items.

Warehouse order procedure

A warehouse order can initiate and control every inventory transaction in SSA ERP Warehousing. From a simple transfer to a complicated receipt, one or more warehousing orders control and account the movement of inventory. Flexibility and automatic execution of activities is possible.

Miscellaneous

In addition to warehouses, items, and warehouse order procedures, you can also enter other types of warehousing master data, such as the following:

Label layouts

Location remarks to be printed on storage and packing lists

Inventory valuation methods

Storage conditions

13-4 | Warehousing

Inventory planning

Introduction

The Inventory Planning module is all about planned inventory transactions and automated actions to replenish inventory. Inventory can also be reserved (committed) for a specific order.

Planned inventory transaction

Planned inventory transactions by item are expected changes in the inventory levels due to planned orders for items. Planned inventory transactions can be generated by several order systems, such as:

Production orders

Purchase orders

Sales orders

Warehousing orders

Service orders

DRP orders

At a particular moment, planned inventory transactions created by other packages and modules cause warehousing orders to be generated. After an order is finished or canceled, the planned inventory transaction is removed.

Planned inventory transactions are used to do the following:

Calculate the economic stock

Statistical inventory control (SIC)

Time-phased order point (TPOP)

Generate MPS orders

Generate MRP orders

Generate PRP orders

Generate DRP orders.

Warehousing | 13-5

Replenishment

Replenishment can take place in a warehouse network in between warehouses and can take place in a warehouse itself between locations.

You can define replenishment between locations in a matrix that contains the supplying zone or supplying location and the destination zone or destination location for each item and the quantities to be replenished.

Several planning options are available in SSA ERP to replenish warehouses. The most advanced option is to use Distribution Requirements Planning (DRP) of SSA ERP Enterprise Planning (EP). DRP applies demand control. Another inventory planning option that applies Demand Control is Time-Phased Order Point, which is a simpler option and is mainly intended to replenish a warehouse by a supplying warehouse.

Besides demand control, SSA ERP also offers two options for Inventory Control. One option is Statistical Inventory Control (SIC). SIC runs by item or by warehouse and creates advice that must be approved by a planner.

The other option is KANBAN, which uses a predefined setup for each item by warehouse, known by an identifier (ID) to replenish inventory.

In addition, some sessions are present to define (collectively) planning parameters for each item or for each item by warehouse, such as EOQ or Safety Stock.

Inventory commitment

Several possibilities are available to reserve inventory. You can reserve only inventory without any allocation by an order, which is useful if the user can anticipate by having particular information in advance. Another possibility is manual commitment for each order.

The user can switch on automatic commitment functionality for sales orders and work orders of the Depot Repair module.

13-6 | Warehousing

Inventory Handling

Introduction

In the Inventory Handling module, the actual inventory movements are executed with the use of warehousing orders. Warehouse activities, such as receiving, put away, picking, and shipping are handled in this module and controlled by means of the warehousing orders or handling units. In addition, activities such as cross-docking, assembly, packaging, cycle counting, inventory adjustments, and blocking are available in this module.

The Inventory Handling functionality can also be used in warehouse environments with a high volume, as well as environment with low volume throughput of goods.

Warehousing orders

A warehousing order is an order for handling goods in the warehouse. The warehousing orders are the communication layer between SSA ERP Warehousing and other applications. These warehousing orders are required for a tight integration and a decoupled package at the same time.

Warehousing orders can be of type:

Receipt: Movement of goods from an entity other than warehouse to warehouse.

Issue: Movement of goods from warehouse to other entity than warehouse, such as a work center or a business partner.

Transfer: Movement of goods from one warehouse/location to another.

WIP transfer: Movement of goods from one costing work center to another.

Item transfer: A change of the item code, and perhaps of location as well, in fact an adjustment.

Warehousing orders can be entered manually, generated by other SSA ERP packages, received from EDI or even from external applications.

Warehousing | 13-7

The to-be-executed warehousing activities can be either communicated by the application that initiates the warehousing order, or entered manually for manual warehousing orders, or determined by means of the default order types by order origin. After the warehousing order is created, the user can deviate from these initial planned activities to align the ERP process with the physical process of handling goods.

Depending on the Inventory Handling parameter, the warehousing orders are also kept as historic data.

Cross-docking

SSA ERP supports cross docking. With the use of parameters, the level of automation can be established. If cross-docking is applicable, received goods are directly assigned to the shipping process of SSA ERP, which corresponds with the physical flow of the goods, because these move directly from the receiving dock to the shipping dock. This prevents superfluous inbound and outbound handling.

Direct Material Supply

The DMS (Direct Material Supply) concept implies that goods received from suppliers or produced in manufacturing shops move directly to their point of consumption without storing it in a ‘storage’ warehouse. The DMS concept uses the Cross-docking concept to avoid storage of goods in the warehouse and the Warehouse Transfer Order concept to move the goods directly to the point of consumption, which is most likely another warehouse. By taking into account where the parts are required before storing the goods, it is possible to reduce stock sitting in a warehouse.

The end result will be a much more transparent logistical process, which will be more responsive to last minute changes in demand priorities while assigning inbound goods to outbound requirements.

Inbound

The Inventory Handling module includes inbound and outbound management. Inbound management takes care to get received goods stored in a warehouse.

During the process of storing the goods, several activities can be required. These activities can be set up and executed flexible.

13-8 | Warehousing

Even during the inbound process several activities can be switched off or on, or can be changed from execution mode. The following activities are supported by SSA ERP and can be activated flexible:

Print goods received note

Receipts

Generate inbound advice

Put away inbound advice

Generate storage list

Storage list

Approvals

Generate inbound advice

Put away inbound advice

Generate storage list

Storage list

In addition to these activities, several supportive functions are available, such as reports and overview sessions.

In addition, Advance Shipment Notifications (ASNs) are supported. ASNs can be received and sent by means of EDI or manually. Validation of ASN data is available.

A receipt can be registered based on several filter criteria, such as:

Advance Shipment Notification

Expected shipment

Expected order

Load

Item

Business partner

Handling unit

References

In addition to these filter criteria, high-volume receipts are also possible.

Warehousing | 13-9

To accept the receipt, several predefined tolerances in regard to receipt date and quantity are checked. This data can be used as input for vendor management of purchase control.

After you receive the goods, a quality inspection of the goods might be required. For straightforward inspections, inspections of SSA ERP Warehousing can be used. SSA ERP Quality Management supports more-advanced inspection functionality, to which an integration exists.

A goods receipt can also be linked to a purchase schedule. After you receive goods from a purchase schedule, an update message is sent to Purchase. Purchase Control can then conclude what goods receipts are linked to a purchase schedule. These receipts require a CUMS update. Checks on CUMS are performed manually, according to an interval. Warehousing does not check or validate CUMS itself.

After you receive and inspect the goods, you must store these goods in the warehouse. If the warehouse has locations, you must also assign a location. You can assign these locations during the inbound advice generation. Inbound advice generation is based on criteria, such as:

The location must not be blocked

The location must be an inbound location

The location must not contain other items (if wanted)

The location must not contain other lots of the same item (if wanted)

The location must have enough remaining capacity

Storage conditions must match.

If required, you can manually change inbound advices, if required. Therefore, the advice can be released and printed on storage lists.

Outbound

Outbound management handles activities to get stored goods out of the warehouse.

During the process of picking the goods, several activities can be required. These activities can be set up and executed flexible. Even during the outbound process, you can switch several activities off or on, or change activities from execution mode. SSA ERP supports the following activities, which can be activated flexible:

13-10 | Warehousing

Generate outbound advice

Release outbound advice

Generate pick list

Pick list

Approvals

Freeze/confirm shipments/loads

Print bill of lading

Print packing slip

Print packing list

In addition to these activities, numerous supportive functions are available, such as reports and overview sessions.

Based on demand, and if a warehouse has locations, goods must be picked from the warehouse locations. An outbound advice must be generated to determine the location to pick from. An outbound advice is a list generated by SSA ERP that advises the user about the location and lot from which goods must be issued, taking into consideration factors such as block locations, outbound method, and package definition.

The following two types of picking can be distinguished:

Order picking: The picking is carried out by order and picking lists are printed by order.

Wave picking: A picking wave is a group of original orders that must be picked for one destination. Usually, a picking wave consists of multiple picking missions.

The picking mission covers the picking actions that are grouped logically. For example the actions are grouped by zone, order priority, production line sequence, and so on. Next, designated employees, forklifts, and so on can execute the actions in sequence. Picking lists are generated for each picking wave.

Picked goods are moved to staging locations. Staging locations represent the dock where loading of transport means takes place. Dock assignment is also supported. Staged inventory is still visible in the system.

Warehousing | 13-11

After the goods are picked, a shipment is prepared, unless SSA ERP Freight Management is used to generate the shipments. Shipments can be for one order (single shipment concept) or for multiple orders.

After the goods are made ‘transport ready’, the shipment can be frozen. Required documents, such as bill of lading, packing lists, and packing slips can now be printed.

After the shipment is final, you can confirm the shipments, based on shipment or load number. In addition, the shipping documents can now be printed or reprinted.

Based on Advanced Shipping Information (ASN and so on), an ASN data file can be defined. This file includes information about: item, customer, dates & times, truck, delivery address, and quantity.

Value added services

Value added services such as assembly and packaging is supported by means of warehousing assembly orders. These orders are used to collect goods to assemble the orders into one item. Warehousing assembly orders are created manually.

Warehousing assembly orders transform goods in the warehouse and can be performed at any location in the warehouse as long as the order is marked as assembly permitted.

A warehousing assembly order, orders you to pick and combine a number of items to produce an end item that remains in the warehouse. The bill of material for this operation is derived from the kit definition in the list components session.

When a warehousing assembly order is created, SSA ERP generates:

Outbound-order lines for each component of the kit to be transferred to the assembly warehouse or location.

An inbound-order line to store the item to be assembled.

Performing a receipt on this warehouse order line registers that the operation has been completed and the item to be assembled can be put away as if the item were a received item.

13-12 | Warehousing

Every manual modification of the warehousing assembly order or order line is registered in the warehousing assembly order history.

Handling units

A handling unit is a uniquely identifiable physical unit that consists of packaging and contents. A handling unit can contain items and other handling units.

Structure

A handling unit has a structure of packing materials and items. A handling-unit structure can vary from a simple box that contains a particular number of items, to a more complex structure such as a pallet with a number of boxes, which in turn contain smaller boxes that contain a number of items. A handling unit structure can consist of various handling units related in a parent-child fashion.

You can manually create a handling unit structure for a given number of items, or you can define a package definition in which you set up a template that determines the handling unit structure for particular types of items.

The use of handling units

A handling unit is a single entity that is used to process goods in the warehouse. Therefore, you can use a handling unit to receive, store, and issue goods.

To use a handling unit for warehouse processing, you must link the handling unit to a warehousing order line. By linking handling units to warehousing order lines, the warehousing-order lines will represent both administrative information, as well as physical information about the contents.

You can link a handling unit to an order line in various ways, for example, by generating handling units for an inbound order line, or, indirectly, by generating handling units for a receipt. A receipt is always linked to inbound order lines.

Because users must be able to control item movements with as few keystrokes as possible, automatic identification of handling units is possible. Therefore, you can attach a label to a handling unit. Defining handling unit structures and scanning labels enables you to have a highly automated execution of warehousing activities at receiving and shipping.

Warehousing | 13-13

You can use both handling unit-based warehouse processing and item and order line-based warehouse processing.

Cycle counting

Cycle counts are intended to check the registered inventory against the actual inventory at a particular moment in time. Cycle-count orders are used to manually count the inventory by stock point and, subsequently, enter the counted quantities into the system. Cycle count orders are based on ABC parameters and counting frequencies.

Before cycle counts can be carried out, preconditions must be set. Some of these preconditions are:

Whether stock points must be blocked during cycle counts.

The cycle count intervals for the various classes.

The maximum allowed shortage or surplus of the counted inventory, measured against the item's system inventory, and expressed as a percentage of the system inventory.

The amount that indicates how much the total cost-price value of the counted inventory can deviate from the cost-price value of the system inventory.

To overrule the cycle count intervals you can force cycle counts for:

A new stock point

A stock point if its system inventory becomes zero

A specific stock point

A range of stock points during the generation of the cycle count orders

Employees can enter for each stock point the counted quantity on the printed cycle count list. Handling units can be marked as present.

If a variance occurs that falls outside the margins, a recount can be forced. If this type of variance does not occur, the cycle count order line can be approved and processed, which means an update of the quantities and related to this, an update of the financial value of inventory.

13-14 | Warehousing

Inventory adjustments

Inventory adjustments are used to manually change the inventory registered by SSA ERP at a specific stock point. Inventory adjustment orders are used to perform the inventory adjustment.

Blocking

For whatever reason, you might be required to block part of a warehouse or particular items from moving around in a warehouse. Therefore, you can block inbound movement, outbound movement, transfer (receipt, issue), or assembly of items at various inventory levels:

Zone

Location

Lot

Stock point

Serialized item

Handling unit

At most of these levels, blocking can be more particularized for one or more transactions types.

Inventory Reporting

Introduction

In the Inventory Reporting module, the actual inventory position and movements are recorded. Because inventory visibility is key for a company, several reports are offered to provide an optimal view on this data.

Inventory position

The current inventory position is recorded at various inventory levels and for multiple entities. Data as inventory on hand, inventory on order, allocated inventory, and inventory on hold is stored.

Warehousing | 13-15

The inventory position is recorded at the following inventory levels:

Item

Warehouse

Location

Inventory date

Lot

Serial number

Inventory can be displayed for the following entities:

Multicompany inventory

Project inventory

Rejected inventory

Consignment inventory

Negative inventory

Committed inventory

Inventory transactions

All transactions that influence inventory positions or movements in a warehouse are recorded by SSA ERP and logged in this module. This information is used for track and trace purposes. These transactions can be archived in time.

Inventory Analysis

This module provides functionality to analyze inventory from two perspectives, logistically and financially.

Logistically, an ABC and slow-moving analysis can be executed, which lists and, when selected, updates changes.

For the financial perspective, views illustrate the change of the inventory value due to normal transactions caused by orders, transactions caused by variances, or transactions caused by revaluation activities.

13-16 | Warehousing

Two options are available to update the Inventory Value, even if inventory is present. One option is to update the Moving Average Unit Cost (MAUC) for MAUC items. The other option is to change the valuation method.

Lot Control and Serials

Introduction

This module consists of making inventory known by attaching labels. One type of label is Lot. Lots are intended to identify and classify items based on an identical production run or repair run. In SSA ERP Warehousing, lots are also used by item revisions and unit effectivity.

Lot control

Lot numbers can be automatically generated based on a mask, which can differ for lots created by production, purchase of Warehousing itself. Some information can be added, such as a business partner, to ease the identification of a lot.

Tracking and tracing display and report facilities are present to view transaction of lot-controlled items.

To know inventory per item by revision, this information is stored at item by lots. The same is applicable to unit effectivity. Therefore, lot is mandatory to support these two concepts with handling of goods.

The most detailed method is to track the lot in inventory, which means that you can perform a check for each lot if the lot is in stock. A method with less handling is that just lot numbers are registered for printing and tracking purposes, but no actual stock position is available.

Serials

A serial, or serialized item, is an item that is uniquely identifiable by the item’s serial number. This type of item can also be part of a lot. For each item, you can set the level of control. The most detailed method is to track the serial in inventory, which means that you can perform a check for each serial if the serial is in stock.

Warehousing | 13-17

A method with less handling is that just serial numbers are registered for printing and tracking purposes, but no actual stock position is available.

Consignment stock

Consignment functionality is applicable when various parties handle inventory ownership and storage. The following three types of consignment inventory exist:

Inventory you store that still belongs to a supplier, also called consignment (not owned) inventory.

Inventory you own that is stored and controlled by a customer, also called consignment (owned) inventory.

Service customer owned, which contains parts that are owned by the customer and exist in the warehouse for repair.

Consignment (not owned)

A warehouse that is used for storing not-owned consignment inventory. Not-owned consignment inventory are goods owned by a supplier but managed by the own company and also stored in the warehouse of the own company without being paid for until after the goods are used or sold. These goods are registered as consignment inventory.

Consignment (owned)

A warehouse that is used for storing owned consignment inventory. Owned consignment inventory are goods owned by the own company and stored in a customers warehouse without receiving payment until after the goods are used or sold. The customer manages inventory. You do not register the goods as consignment inventory because the goods are still part of your inventory.

Service customer owned

This type of warehouse is a type of consignment warehouse that contains customers’ parts that must be repaired or are simply repaired. Handling of these parts is similar to parts of a normal warehouse, except that no financial transactions are initiated because the company does not own these parts.

13-18 | Warehousing

Consignment replenishment and payment

If you use consignment inventory, the sales or purchase order procedure is split into two parts:

Consignment replenishment

Consignment payment

Consignment replenishment

If you or your customer runs out of consignment stock, and replenishment is required, a sales or purchase order of type ‘consignment replenishment’ is required. With this order, the goods are delivered, but payment is postponed until the goods are actually used.

Consignment payment

If (part of the) consignment stock is used, at that moment the goods must be paid for. For owned consignment inventory, a sales order of a type ‘consignment invoicing’ must be used. For not owned consignment inventory, a purchase order of a type ‘consignment payment’ must be used. This triggers no goods movement, but only a payment flow.

Introduction

This chapter provides an overview of the functions and features offered by SSA ERP Freight Management. SSA ERP Freight Management is a Transport Management System (TMS) that enables customers to properly manage their transport orders, load consolidation and planning, as well as calculate delivery lead times. This can be done across different logistic companies. The main target group of SSA ERP Freight Management is shippers rather than mere carriers or logistic service providers. The product is a fully integrated part of the SSA ERP suite and has strong links with Warehousing, Financials, Order Management (Purchase and Sales), and Enterprise Planning. The product can, however, also be used as a stand-alone freight order and planning system.

SSA ERP Freight Management uses general master data, such as countries, business partners, addresses, items, departments, distances, and so on. In addition, the necessary transport-specific master data can be set up, such as types of transport, routes, fleet data, and so on.

The core of the package is formed by the functionality for freight order management, load building and planning, supported by a graphical planning board with drag-and-drop possibilities.

14Chapter 14 Freight Management

14-2 | Freight Management

Finally, functionality is available for estimating freight-related costs and revenues and a link to SSA ERP Central Invoicing for handling invoices from carriers or to charge transport services to customers:

FreightManagement

OrderManagement

ServiceProjectManufacturing

Invoicing & Finance

EnterprisePlanning Warehouse

Management

Freight Management within SSA ERP

Main integration scenarios

Warehousing

This integration is almost always active when you use Freight Management.

The close connection between SSA ERP Freight Management and SSA ERP Warehousing enables you to copy warehouse orders, which can be inbound, outbound, or transfer orders, to freight orders, to efficiently handle the movement of the goods involved. The freight order can go through a load consolidation and planning process, of which the warehouse personnel can retrieve the result to serve as instructions to prepare the issue or receipt of goods.

The progress of freight and warehouse procedures is always closely related.

Freight Management | 14-3

Enterprise Planning

Activating the link between SSA ERP Enterprise Planning and SSA ERP Freight Management produces freight orders on the basis of planned item transfers between warehouses (planned distribution orders).

This enables you to perform a thorough transport planning, even before the warehouses are actually involved.

Purchase Control

If a company is in charge of transporting ordered goods from the company’s suppliers to the company’s warehouses, a link between SSA ERP Order Management (Purchase) is available. This link triggers freight orders on the basis of purchase orders, which enables you to perform load consolidation, planning, and shipping items to the appropriate warehouses.

Sales Control

This integration is a frequently used connection that enables a shipper to create freight orders on the basis of sales orders. In many cases, companies that, for example, manufacture goods are interested and even involved in the process of shipping goods to customers. For these companies, goods must arrive on time and in good condition, preferably at the lowest cost possible.

Again, generating freight orders straight from sales orders, before the warehouse is involved, allows for a more thorough (and time-consuming) transport planning process.


The following figure illustrates the business process with regard to the integration between SSA ERP Sales Control and SSA ERP Freight Management, including the link to SSA ERP Warehouse Management:

Business Process Sales Control – Freight Management Integration

Sales

Shipping office

Planning

WarehouseRelease to warehouse

Cus

tom

er

Set up: Route Plans, Freight Rating, Carriers / Fleets, Transport modes / methods

Finance

Carrier

Order Receipt

Paym

ent

Create FreightOrder &

Order grouping

Load Building& Costing Execution

Car

rier

Sele

ctio

n

Invoicing

The functions and features of the following modules will be described:

Freight Master Data (FMD)

Freight Order Control (FOC)

Rough Planning (RPG)

Load Building (LBD)

Freight Rate Control (FRC)

Freight Invoicing (FRI)

Freight Master Data (FMD)

Freight-related master data must be defined before SSA ERP Freight Management can be applied. In other words, before proper handling of freight orders or efficient load planning is possible, a basic setup is required. The majority of the basic data is defined in the FMD module, but some master data from other modules will also be included in this section.


General freight master data

Some FM-related entities within the organization must be defined here, such as shipping offices and planning groups, and the relationships between these entities. Shipping offices are best regarded as expedition/transport-planning departments while planning groups can be a subdivision into specialized teams, for example, for hazardous material or tanker transport. A shipping office can be assigned to specific warehouses, to make sure that this shipping office manages all external movements of goods stored in these warehouses. On the other hand, a matrix can be defined to assign freight orders to the correct shipping offices, based on criteria like warehouse, route, country, carrier, terms of delivery, point of title passage and logistic company. This final criterion allows for multi-site freight order handling and planning.

In addition, to each combination of shipping office and planning group login codes (users) can be linked and for every user, profiles can be defined.

Addresses and items

In addition to the common address and item data, some freight management–specific details might have to be added. With regard to addresses, you might be required to indicate that particular addresses have extra long waiting times or lead times for loading or unloading, or to specify limited time windows for delivery.

Concerning the transportation of items, defining details about dimensions, special transport means and methods, mateability, carriers, and so on might be essential.

Often, FM-related instructions are included in a common data table, as is the case with business partners.

Transportation master data

This master data is where basic data in regard to the actual transportation of goods is specified. Depending on the complexity of one’s shipping activities, various transport types can be defined, such as Refrigerated, Hazmat, Express, and so on. In addition, you can specify so-called combination codes, to be used for mateability/compatibility rules.


In addition, the structure and nature of the transport fleet used is entered here by means of Transport Means Groups (TMGs), which determine the character of transport means, such as vans, tankers, ships, palletized, and so on, as well as the mode/category, capacity, speed, and so on.

In case a fleet is owned or dedicated, you might be required to fill the TMGs with individual means of transport, for which you can monitor availability by means of calendars.

Finally, you can define and link external carriers/LSPs to specific shipping office – planning group combinations. For every carrier, the capacity and TMGs that the carrier can supply are determined.

Freight order master data

This master data includes specific shipping instructions in the form of service levels and freight order procedure.

In addition, information such as freight and weight/volume classes can be specified, which can be used to calculate transport costs and/or determine the planning group or carrier to which an order must be assigned.

The allocation of freight orders to planning groups is based on the setup of the plan matrices. When the user sets up these matrices, the user can choose from a wide range of criteria to make sure that an order is assigned to the appropriate team.

Load building (freight planning) master data

Setting up basic planning data mainly amounts to defining transportation routes. These routes determine how, when, and in what order addresses are visited for loading and unloading activities. In addition, the route structure also determines which freight orders can be consolidated and planned on the same trip to reduce costs.

In SSA ERP Freight Management, you can maintain standard routes to which ranges of ZIP codes or areas can be attached, as well as a time schedule. The underlying concept is that all addresses that fall within one standard route can, in principle, be visited during one round trip.

A second concept is the route plan, which functions on a slightly higher level. A route plan can be regarded as the definition of a transport scenario from a start address to a destination address/region/country.


A route plan can consist of various legs, in case intermediate visits to (fixed) DCs must take place for grouping purposes, or if goods must be unloaded at a harbor to be put on a ship, and so on. Each leg within a route plan can be linked to a standard route, to enable local round trips.

Finally, you can perform the installation/activation of the graphical planning board here.

Freight Order Control (FOC)

You can regard the module for maintaining and handling freight orders as the core module in Freight Management, because all freight-related operations are triggered by orders. Freight orders consist of a header and one or more lines, which contain all the necessary information and instructions, such as addresses, delivery dates, items, types of transport, and so on, for moving goods to customers, from suppliers, between warehouses, and so on.

Create/maintain freight orders

As mentioned previously, freight orders often originate from warehouse, sales, purchase, or distribution (EP) orders, possibly in different logistic companies. Freight order generation can take place automatically, but can also be carried out batch-wise. You can also create freight orders manually.

Subcontracting freight orders

Depending on a shipper’s policy, you can include freight orders in the load planning. On the other hand, you can decide that all planning activities or the planning of particular transport, for example, hazardous material, is never carried out in-house but always subcontracted to a carrier. In these cases, freight orders can be clustered, based on a range of common criteria, such as delivery dates, service levels, transport requirements, and so on. The procedure for generating freight order clusters can include the selection of a suitable carrier. A next step will be the printing of subcontracting instructions, which can be sent to the selected carriers. The procedure ends with confirming deliveries, if the carrier supplies this information, and closing the clusters.


Freight order history

You can clear one’s operational tables and store information about freight orders and freight order clusters in history tables.

Rough Planning (RPG)

This module contains only one core activity, which consists of the creation of capacity requirements overviews, both on paper and on screen. These overviews can be created on a daily, weekly, or monthly basis and give insight into the transport capacity required, optionally listed by TMG, and the available capacity.

Load Building (Planning) (LBD)

In case a shipper goes further than mere freight order control, but also wants to be involved in the planning and perhaps even execution of his transport activities, the planning /load building engine of SSA ERP Freight Management must be applied. Running the planning engine in FM, for example for a range of freight orders or a particular period, will result in a freight plan containing loads and shipments. FM loads can best be regarded as truckloads or trips, while a shipment is usually the delivery made at a particular address visited during a trip.

Transport requirements may originate from different enterprise units or even different logistic companies and can be managed and planned centrally by for example, one shipping office.

As described in the following section, loads can contain multiple shipments. Shipments always consist of one or several (item) lines.


FM knows three basic planning algorithms, as illustrated in the following figure:

Planning Algorithms within SSA ERP Freight Management

A) Direct Shipping• Shipments to different addresses are not combined into one load

• Single- & multi modal

• One (full) truck load going from origin to destination

B) Consolidation (Standard Routes)• Shipment may not go directly to destination but can be combinedinto one load/round trip with shipments on the same route

• Single mode

C) Pooling (Route Plans)• Intermediate pooling points (e.g. DC’s) are used

• Route split up into multiple legs

• Single- & multi-modal

• Consolidation (B) possible on leg level

= Own site= BP= DC

The resulting loads and shipments can, and usually will, serve as instructions for the warehouse employees responsible for picking the goods from the warehouse and loading the vehicles.

Plans, loads, and shipments

The procedure starts by generating the freight plan. This session is run for each shipping office/planning group combination and for a period or a range of freight orders. Working with simulations and alternative freight plans is possible until you select one plan to be executed.

As stated previously, a freight plan consists of loads and shipments. To construct these loads and shipments, the system takes into account information such as delivery dates, transport types, combination codes, service levels, routes (depending on the algorithm), Incoterms (points of title passage), transport means groups, capacity, and so on.


In case no TMG or route has been defined yet, the system will look for a suitable one. A second aspect of generating a freight plan is the selecting of carriers that can carry out the loads. If no carriers have been allocated yet, the system will do an automatic search based on cost-related criteria.

To gain insight into the operations run by the load-building engine, you can activate an extensive planning log, which shows exactly what goes on during the freight-planning run.

The fact that a shipper has unique planning requirements and chooses to be responsible for consolidating the required loads and shipments does not automatically mean that the actual transport is not subcontracted. In case a shipper is not in possession of a fleet, all transport will be performed by one (dedicated) or more external carriers. Alternatively, a shipper might decide to subcontract particular loads that require, for example, conditioned means of transport. For this purpose, FM offers functionality for subcontracting loads to external carriers.

Graphical planning board

To facilitate the use of the core modules of SSA ERP Freight Management: freight order control and load planning, a user-friendly planning board is available. This planning board provides a clear overview of freight orders and planning data and all main (daily) operations can be executed from here.

History

You can clear one’s operational tables and store information about load plans, loads, shipments, and shipment lines in history tables.

Freight Rate Control (FRC)

The freight rate scales determine the cost and possibly revenues of transport-related activities. You are not required to have the system calculate freight costs, however, nowadays for most shippers keeping track of the costs of transporting goods is essential. In addition, the wish to be able to charge customers and other business partners for transport services (revenues) is increasing. In FM costs are based on carrier freight rates and revenues are calculated by means of client freight rates.


To calculate freight costs and revenues

Some of the main criteria that freight rates are based on are related to the character of transports, such as transport types, freight classes, and TMGs. These criteria are the attributes of the so-called rate basis numbers.

In addition, many other aspects can have an impact on the cost of transport, including the following:

Distances or zones

Quantities, weights, and so on.

Carrier involved

Service level

Item

Business partner

Delivery terms

All freight rate scales are defined in the Pricing module of SSA ERP Order Management.

FM also supports the application of additional costs. These costs are extra costs attached to a freight order, which can be caused by special conditions when moving goods. These causes can range from additional taxes, toll, insurance, or handling costs, to special safety measures when transporting valuables or dangerous goods.

Freight Invoicing Control (FRI)

If a shipper chooses to charge customers or other business partners for which the carrier arranges transportation, you must set up the required rate scales and release freight orders for invoicing. The latter action enables the SSA ERP Central Invoicing module to further handle the invoicing procedure.

You can easily access freight invoicing data from the freight orders lines to gain insight into the status of the invoice, the amounts, currencies, terms of payment, the invoice address, the open balance, and so on.

SSA ERP Central Invoicing also handles processing the invoices received from carriers for services rendered.

Introduction

SSA ERP Service is designed to provide benefits to service organizations that deal with the installation, service, and repair of field and plant-based products and equipment. A few examples of such products are copying equipment, computer systems, medical equipment, heating, ventilation, and air conditioning equipment, buildings, production machines, vehicles, forklifts, and so on. SSA ERP Service facilitates these through processes such as field service, depot repair, subcontracting, and help desk support.

SSA ERP Service consists of the following modules to cater to the various service processes:

Preventive Maintenance (Proactive or User-Based Maintenance and Condition Based Maintenance).

Corrective Maintenance (Reactive or Failure-based or Problem-based Maintenance and Product Recalls)

SSA ERP Service consists of the following modules to cater to the various service processes:

Configuration Management

Call Management

Contract Management

15Chapter 15 Service

15-2 | Service

Subcontract Management

Field Service

RMA & Depot Repair

Master Data Management

Configuration Control (CFG)

The scope of Configuration Control (CFG) is to serve the customer, production, or planning department with accurate information on the configuration of assets, called the installed base. These assets can be either serialized items owned by customers or own equipment. The Configuration Control module offers a multi-level configuration structure definition and handling.

The functionality in the module enables you to do the following:

Describe how the configuration or asset is built up, such as assets, components, or levels, as a physical breakdown structure that includes the structure relationship.

Define warranty for an asset or component. Also define if repair warranty is applicable.

Define an item breakdown template.

Generate service configurations, from Sales deliveries or Project or from production bill of material directly or directly add the configuration structure as a physical breakdown of serialized items. Customized items can also be copied using these processes.

Copy selected production bill of material as item breakdown structure.

Present a graphical overview of the configuration.

Physical breakdown structures and serialized items

Configuration Control (CFG) features provide the ability to monitor the physical breakdown structure of various customer-owned or company-owned assets. To achieve a logical grouping of serialized item structures, you can group the structures under clusters, such as a site. This section describes some of the features and benefits of Configuration Control.

Service | 15-3

Serialized items are customer-specific or owner-specific configurations that consist of items such as photocopiers, computers, air conditioners, forklifts, lathe machines, or even aircraft.

You can create a serialized item manually or modify existing items. Serialized items are the building blocks of physical breakdown structures.

These serialized items are not only uniquely numbered, but also can be status controlled. Serialized items are centrally definable and can start the respective life cycle in As-Built mode or in As-Maintained mode. Each serialized item is life cycle controlled from various parts within SSA ERP Service. Based on this, a serialized item can exist in various locations, such as either in configuration, in (depot) repair, in transit, or in a warehouse. In addition, each serialized item can have a status of Start-Up, Active, or Revision. Limited changes are possible on serialized items that have the Active status. On the other hand, the status is checked to be active or not while covering under contract or while adding service orders. You can also define a new serial number for an item as a dummy serial number, which is a temporary number that can be used to keep track of the item until a permanent number is allotted. The details on a serialized item also signify their origin, which can be from a sales order or from a project. Serialized items can also originate from an As-Built structure or directly from the production bill of material. Each serialized item, with or without its cluster (explained later), can be covered by a service contract and a warranty. Repair warranty duration can be defined on the details. Finally, for each serialized item you can define an alternative serial number that is more meaningful to a customer. This feature is useful when you search for items while you register calls, create service order activities, or register parts lines for a maintenance sales order.

Some serialized items, such as a photocopier, have a simple structure whereas other serialized items have a complex structure, such as a ship or an aircraft. The underlying parts and assemblies are depicted in a relationship definition called the physical breakdown structure, which consists of a set of serialized items with a relationship amongst each other. A top serialized item occupies the top slot, whereas the underlying structure consists of assemblies that are either effective or outdated. The view tree option enables you to view the physical breakdown structure in a graphical fashion that shows the structure in a Graphic Browser Framework view. Each serialized item in the breakdown can be linked to a functional element, with a common function across the entire structure, and can be used to group serialized items based on a functional importance.

15-4 | Service

You can find replacements based on functional equivalence while you view alternative items depicted by an augmented view of item breakdowns, as described later in this document. Reference designators indicating part positions, can be inherited from the manufacturing details or can be defined on the Physical Breakdown structures directly.

Each physical breakdown structure or serialized item can be part or member of a cluster structure. A cluster can be defined as a logical grouping of a number of assets with particular similarities, such as location address, servicing department, service area, preferred engineer, covering service contract, and so on. To achieve the inclusion of each serialized item or physical breakdown structures, you can include the item or top item in the configuration lines linked to the cluster.

A cluster is also used to make information default available to the underlying structure. By linking the cluster to a business partner, you can designate a cluster as an external cluster, or by linking the cluster to a work center or department you can designate the cluster as internal.

Item breakdown

An item breakdown is usually an origin of physical breakdown structures. An item breakdown consists of relationships between various items to form a hierarchical structure of assemblies and sub-assemblies. An item breakdown makes up a generic bill of material that is specific to Service. Each member in the item breakdown has an effective date. Expired item lines can be deleted if not required.

An item breakdown can be used to generate a physical breakdown structure. In this event, each item in the item breakdown structure is copied as a serialized item into the physical breakdown structure. Only the effective structure is used to create the physical breakdown. To enable this, the top item must be defined as serialized for the configuration control in the service item data. This is to ensure that a serialized item always occupies the top slot in the physical breakdown structure.

You can manually define an item breakdown, or you can copy the item breakdown from a production bill of material used to manufacture goods. Each line has an effective period and can be defined by you. You can also replace a selected item/range of items with another selected item/range in one item breakdown structure.

Service | 15-5

Methods adopted in creating configuration structures

Three main methods are available to create a physical breakdown structure using a process; and each method is based on relevance:

Copied as an As-Maintained structure from an As-Built structure from SSA ERP Manufacturing. Alternatively, you can also copy an As-Built structure from a Manufacturing or a PCS project as a physical breakdown structure.

Copied as an As-Maintained structure from a production bill of material from SSA ERP Manufacturing. You can copy standard items as well as customized item structures. Consistency checks applicable on production bill of material are applicable in this case.

Copied from a Project structure with the structure’s underlying Element or Activity structure along with the structure’s material lines. In this process, you can also copy the material lines that underlie any of the elements or activities being copied.

Derived from the item breakdown structure. Only the effective structure is used for this purpose.

You can also use Sales deliveries on Sales order lines as the logical point to create physical breakdown structures within the selected range of serialized items. In that case, a range of serialized items can be used to link the serialized item to the customer within the Service domain. The respective sales order is mentioned on the serialized item that resides under the selection and is linked to the customer. A new serialized item (As-Maintained) is created if this item does not already exist.

A physical breakdown structure can also be defined from an American Standard Code for Information Interchange (ASCII) file, if the output from an external production system, such as a Computer Aided design (CAD), is in the form of flat files of a pre-described format.

You can change the physical breakdown structure if required. Using a process, you can install, replace, or remove the selected serialized items from a physical breakdown structure or as a configuration line.

On the other hand, an item breakdown can be derived from only one source, which is the production bill of materials. Subsequently, you can use the Replace feature to replace or remove any item from the item breakdown structure.

15-6 | Service

Grouping, usage and history

You can classify an item breakdown by functional element, which is a term that is used to group items according to a functional similarity. An item breakdown is made visible to display alternative items in a physical breakdown for handling repairs or replacements of serialized items.

An item or a serialized item can also be grouped by serialized item group, which is especially useful in categorizing skills to be used while planning. In addition, this also forms a logical grouping for querying and reporting purposes.

A Graphic Browser Framework is available to visualize the configuration breakdown structures throughout SSA ERP Service.

You can also select any item within the browser, and, after quitting, inherit the item inherited to the calling session, such as a call or an order line. The available features provide an improved visibility of the structure and an improved ease of use in selecting the features.

Currently, a history of the physical breakdown is available to keep track of all events that happened within a structure. This log is updated irrespective of the origin of the change. A difference report can also be obtained with respect to 2 different dates the changes that occurred to a structure in the mean time.

A Serialized Item Dashboard gives insights into the various orders, order history and performance on selected serialized items. This can be useful in various situations, while providing services.

Call Management (CLM)

Call Management (CLM) is the customer’s primary link into the service environment. In Call Management, you can register and further handle calls in regard to products. You can be alerted about existing calls on the selected business partner at the time of registration. The concept of a central call center with several local call centers can be supported taking into account the various time zones. The registered calls can be assigned to any support center or support engineer. When assigned to a specific support engineer, the call goes into the individual’s queue. Subsequently, the call can be taken up for processing.

Service | 15-7

Calls can also be assigned to a business partner (subcontractor), for which e-mail is used as a carrier to transfer the call. This e-mail message contains an attachment that contains all relevant call information.

The service organization can agree to specific response times while signing contracts with the customers. Response times could be based on a specific time period or based on specific business days. To honor a possible agreed warranty or contract condition, the call is dispatched to a service center (and service engineer) for field service, to the help desk for support, or to a workshop for Depot repair through an RMA order.

The status of the call provides insight into what is done so far and what can be expected further. The status can have values such as Registered and Assigned. Each call has a response time that is controlled.

Calls can escalate if they are not solved within the agreed timeframe. In addition, logging what is done and by whom is carried out automatically. This feature enables you to trace and track calls from the start until the end.

Typical features of Call Management include the following:

An asset or configuration malfunction. A malfunction can be a breakdown, a failure, an error, or a problem in general. You can register an incoming call at a central or local level. To solve problems more efficiently, you can transfer calls from one support center to another to find the right location and skills. The call center’s dispatcher forwards the call to the appropriate engineer. Subsequently, problem solving can begin.

Questions or complaints about service delivery or the availability of the spare parts can be registered and transferred to the appropriate service center and/or employee. The employee can be the service manager.

Diagnose tree. In addition, calls can be reassigned to another support engineer or support group, which is logged in the system for later analysis. For complex equipment, you can use a diagnostic tree to solve the problem. The tree is set up following the asset structure; you can search for the problem and find the solution by walking from one asset to lower level ones. When you find a more specific problem or a failing asset, SSA ERP Service suggests a (predefined) solution through a solution control structure. Probability analysis tools can help in you finding out more effective solutions in various situations.

Call Resolution: Calls can be resolved by providing assistance to customers over a network like e-mail, telephone or such other media. Calls can be transferred to Field Service for resolution in case a visit by

15-8 | Service

Field Service engineers becomes necessary. Calls can also be transferred to Maintenance sales orders, in case parts are expected back from customers for repair or replacements.

Call invoicing. The load on the support centers increasingly requires that more time and effort is spent on supporting customer products. Customers do not mind paying if efficient service is provided. This calls for the ability to send invoices to the customer for the support provided.

Customer Call Dashboard

This dashboard is a useful tool for a support engineer and helps them in getting an overview of the calling customer. All service-related details are provided through easy lookups. In addition, the support engineer can quickly view the financial liability of the customer, the customer level response time, and priority definition.

A number of views are available to show orders specific to the customer such as service orders, maintenance sales orders, work orders, and other registered calls. These views enable you to quickly scan the various agreements with the customer, such as service contracts, service job quotations, and service contract quotations. These views also render visibility into the installed base by providing a customer-specific list of clusters and serialized item structure. In addition, these views also provide an insight into the sales orders under process for this customer, to keep better track of the possible new installations.

Repair history & bad fixes

Some details calls and service activities that have been carried out must be available for the call taker if the customer happens to call. If the same problem was already reported, there may have been a bad fix. You must take special actions to satisfy your customer, such as a free repair or repair warranty and a shorter response time.

Priority customers

When they call in, priority customers can be recognized throughout SSA ERP Service.

Service | 15-9

Escalation management

Calls that run out of time must be controlled. In addition, you must take action to satisfy the customer. A call can receive the escalation status if contractual obligations, such as response times, cannot be fulfilled. If a call escalates, a support team will provide its knowledge to the field engineer (on-site available).

Escalation management means fast rescheduling possibilities of support and field service engineers. If required, their current activities must be stopped immediately to dispatch the activities to the escalation.

Transaction logging is available on each call, which provides the opportunity to track the actions and changes that are made, about when these changes are made, and also who makes these.

Contract Management (CTM)

Service contracts are important, they describe the obligations between the service supplier and the (external) customer. Service contracts make service business more predictable with steady revenue streams. However, the contracts must be handled properly. If desired, you can use item price lists to create a quotation for a customer.

You can create templates for contracts. You can define a contract template for a model with the appropriate contract terms and conditions such as the applicable Response time, service types, prices, and so on.

To make an offer for a prospect or customer, you can easily select and customize a contract template. You can define contract terms and conditions such as pricing method, and expiry date for specific business requirements. The contract can be invoiced by installments.

Reference activities can also be included in a contract, along with various configurations (clusters or serialized items). If a sales representative concludes with a customer that a service engineer will visit the company twice a year to see what must be done, this agreement can be covered by the contract.

15-10 | Service

Contract master data

The following information can be maintained in the master data and is important to be able to successfully use service contract features:

Contract Types: A differentiator for service contracts and is used for logical grouping under various considerations.

Installment Templates: These templates define the methods of creating contract installments.

Contract Item Price list: This list offers nominal prices offered while defining service contract configuration lines.

Discount scheme: This special configuration level discount can be offered to customers for each configuration line. In addition, this discount is a multilevel discount that can be segregated according to fixed periods, as defined in the template.

Warranties

Warranties are agreements out of product assurances made with the sale of various products. The assurance is offered in terms of providing free or discounted service for particular lock-in periods, then providing free or discounted services for problems that might be faced.

Warranty details consist of the duration, effectivity period, and the type of warranty. A warranty can be offered as an Owner/Manufacturer type, Supplier type, or Non-Specific type. A number of coverage terms to be covered by the warranty can be defined on each warranty definition.

Warranties are defined in templates containing proposed terms to be covered under warranty. Warranty templates can be defined with service items that can be inherited by serialized items if the serialized items are derived from the service items.

These templates can be linked with the serialized items. After the warranty templates are linked to serialized items, the serialized items can inherit the terms. The terms can include various cost types supported in SSA ERP Service.

Service | 15-11

Contract templates

These templates are the generic contract templates and can be made specific to the item with a definition of price per period. These templates are not specific to customers, and do not have specific configuration lines because the templates themselves are specific to items.

However, contract templates provide an easy, predefined way to copy terms and agreements into contracts. You can define coverage terms and cost terms within each template, and you can copy these coverage and cost terms into the respective contract configuration line. You can set effectivity for templates so that you can always use templates in practice.

You can link templates with items while you define the item price lists. These templates can contain the price defined on each template as the suggested/ default price information when used in the service contracts.

Contract quotations

Through this business asset, you can define and manage quotations for service contracts. Successful quotations result in a service contract; unsuccessful quotations can be canceled. Both the types can be posted to contract history. Typical features include:

Registration of a request for quotation. After the request is received, an acknowledgment is sent to the customer.

Quotations can be defined for customer assets, which could be clusters or serialized items, or specific activities. Terms and conditions can be assigned, such as covered period and amounts/ discounts and types of service offered (such as reference activity or coverage type), response time, and so on.

An approval system provides the essential authority. Related to the amount of money involved, somebody must approve the quotation (using workflow management).

After approval, the entire quotation, including all related data, can be sent to the customer by fax, letter, e-mail, and so on. The quotation is valid for a limited period of time, after which the customer's decision can be discussed.

The quotations sent to the customers could or need not be accepted. If the customers accept the quotations, the quotations can be processed into active contracts. If the quotations are rejected, corrections can be

15-12 | Service

made to the quotations under selection and have them sent to the customers again. Or, you can simply cancel the quotations.

Contract control

An active contract can be derived from a processed quotation or can be defined from a directly defined contract. A contract consists of a set of financial and logistic terms. A contract consists of configuration lines that provide a list of equipment/assets that are covered by that contract. A contract consists of coverage terms that describe the type of financial coverage and the conditions for which the terms apply. Each coverage term can be linked with a number of cost terms, which provide a listing of all included/excluded cost line coverage.

You can link configuration lines with templates, and you can define the prices from the prices fetched from the item price list definitions. Alternatively, you can define the prices directly. You can also derive these prices from the underlying cost terms.

Details to be defined with respect to a service contract are similar to a contract quotation. Financial information such as currencies, exchange rates, taxes, revenue recognition methods, installment methods, as well as, logistic information such as equipment/ assets to be covered, overtime to be allowed, response times to be met, uptime to be abided by, and so on.

Price determination

Functionality is defined to control the gross margin. This can be based on the sales price or the cost price.

Each asset covered or service activity that must be carried out is related to costs, for example, material, hours, tools required, travel costs, other costs such as the costs for a hotel, or call-out charge. These service prices (based on the pricing method) together with the gross margin constitute the offered amount.

To derive the costs and sales amounts, you can use the following four methods:

By direct addition of the contract price at a header, especially when the contract price originates from a quotation.

From the underlying coverage and cost terms, which you can use to total up to the header.

Service | 15-13

Derive from the item price lists linked in the configuration lines.

Project part of the inherent values of the configuration lines.

The sales amounts participate in building the installments, which provide the customer with a periodic invoicing method. The cost amounts act as forecasted costs and are helpful in estimating the projected profitability of the contract.

The costs mentioned here are forecasted costs and you must periodically compare these costs with the actual costs.

Contract coverage and contract costs

You can skip the quotation phase and immediately create a contract.

You can register costs for each configuration line or service activity. An order or a call (partly) carried out against a contract means that the actual costs are increased.

On each coverage or cost term, the amount of coverage rendered is visible as allocated costs and spent costs. You can compare this amount with the project costs to assess whether a contract is still profitable.

For each contract, the following cost types can be agreed on with the customer (and controlled):

Traveling costs

Labor costs

Material costs

Tools costs

Subcontracting costs

Help desk costs

Other costs

Uptime, a guarantee about availability of an asset with a penalty clause connected

If you want to quickly use all of these cost types together to be covered by contracts, you can use the cost type “All”, which is useful for fast entry and simple contracts.

15-14 | Service

Coverage methods that are supported by SSA ERP Service are: Fixed Price: All the work executed on the orders is covered without

charging the customer.

Coverage percentage: The contract covers only a part (the percentage) of the executed work.

Ceiling: The contract covers only until a certain amount (the ceiling) is reached

Ceiling on Coverage percentage: The coverage percentage is limited to a certain ceiling

Own Risk: Work will initially be charged to the customer before coverage becomes active. Also with a Ceiling/ Percentage the Own Risk can be adjusted.

Contract changes

Three types of changes are considered: Renewal, Incidental changes, and Indexation. Renewal involves extending the contract period beyond its current validity period. Incidental changes involves effecting changes to an existing contract agreement, such as addition of more configuration lines, or changes to prices and discounts, and so on. Indexation is to apply price increments based on changes occurring to the consumer price index.

You can define and activate changes as might be required from time to time on various changeable contracts. You can send additional invoices for these changes through contract installments.

Subcontracting agreements

You can decide to subcontract agreements for the included configuration lines in the service contracts. When the contract is active, subcontracting agreements can be generated with suppliers for all the items covered under the contract. Alternatively, you can link a service contract to a subcontracting agreement manually.

Contract Financials

You can define and invoice the installments. You can transfer these installments to SSA ERP Central Invoicing. The accounts receivable and so on are automatically updated in SSA ERP Financials. The invoiced amounts can be booked to SSA ERP Financials, according to the defined ledger accounts.

Service | 15-15

Contract revenue recognition

The processes related to revenue recognition that are available within this module, are used to de-link the process of recognizing from the process of receiving revenue. Revenue recognition is a process by which you can allocate and recognize the revenues related to the work actually carried out, so the contract conditions are met.

In addition, you can use four methods to recognize and report revenue to the financial modules. Revenues can be recognized based on the revenues attributable to the respective financial period, or, if the recognition is to be over a period less than the financial period, the revenues can be cumulated and shown in the appropriate periods. The revenues can also be recognized based on the costs spent in servicing a customer.

The revenues recognized by these processes are reported to SSA ERP Financials into the appropriate ledger accounts and in the appropriate periods.

Contract history

Active contracts can be set to expired once they are not renewable and exceed their expiry dates. If you must terminate the agreements prematurely, contracts can also be canceled. Expired or canceled contracts must wait until all respective Financials are settled. All contracts that are either expired or canceled and that are settled in every respect can be closed.

Subcontract Management (SBM)

Often, one company does not deliver the entire offering of Service just like as in the case of Products. In some cases, the entire service of a product is subcontracted to a Supplier. The customer has still the advantage of one main contractor as contact.

For the main contractor, proper registration is required to align the contractor’s service contracts (contract with the customer) with the subcontract agreements (contract with the subcontractor/supplier).

Currently, registration is performed about what is covered by a subcontractor and some necessary information. With call dispatching, some of this data is used to route a call to the subcontractor.

15-16 | Service

Calls can be assigned to subcontractors if valid subcontract agreements are present by sending the problem details by e-mail.

If suppliers cannot respond in time, or if the problem is urgent, you can send a reminder to the supplier.

Field service

Planning and Concepts (SPC)

This module enables you to use preventive maintenance for assets in an effective and efficient way. These assets can belong to your customers or could be your own internal assets. The planned activities can be covered by service contracts. These activities could be agreed with the customers and, therefore, must be automatically controlled by the service order system.

You can define a different maintenance concept for each product. The supported preventive maintenance policies are as follows:

Use-based maintenance (UBM) based on periods or based on counter readings. A trigger for service can be based on the number of kilometers, mileage, or working hours. After certain usage, the predefined service activities must be carried out. Measurements can be used to track the usage, as not only the triggers to plan next activities agreements can be covered based on the usage of assets.

Condition-based maintenance (CBM) based on visits and measurements or reported measurements. Condition-based maintenance depends on the condition of the asset, including components, or configuration lines. You can register several measurements to describe the condition of the asset. You can carry out condition monitoring based on the reports generated from inspections or inspection history, which you can obtain from Service Order Control.

To support the definition of maintenance concepts, a library with (reference) maintenance concept can be consulted. For items, (reference) maintenance concepts can be defined and stored in a library for ease of use. When the maintenance concept is set up and agreed, the corresponding Maintenance Predictions can be generated, then subsequently maintenance planning can be generated.

Service | 15-17

Service planning process Define maintenance concepts in advance by using reference activities.

Each reference concept consists of reference activities related to a product. Reference activities and the underlying details can be defined in the Master Data module.

Define a maintenance concept for a specific instance of usage of a product by using the reference maintenance concept. For each component, you can define the following data: maintenance concept, the service activities, the frequency for each activity, tools required, man hours required, and the number of engineers for the activity. The reference concepts can be used and customized for a specific asset instance.

A maintenance planner decides which (maintenance) concept is most efficient and effective. Taking into account the customer’s wishes, a reference concept is selected and customized for the unique asset.

Generate a service planning (forecast) for the service activities based on the maintenance concept. The planning can be modified. Each time you generate a planned activity for a work center or a machine, the downtime can be reflected in Enterprise Planning.

Authorize the service planning (forecast). If you confirm the service planning, the planning is automatically transferred to Service Order Control for detailed planning. Planned activities can be transferred to Service orders either one by one or in a group by a logically selected grouping.

Based on the maintenance forecasts, a total overview of planned (preventive) activities by period or by service center can be given. If required, a cost overview of these activities or concepts can be obtained to scrutinize the cost of each activity or a group of activities.

Service Order Control (SOC)

Using the Service Order Control module, you can create the order quotations, plan the order, and monitor the execution of the order, then process the order, book costs, and trigger invoicing.

To carry out on-site repair, replace, or upgrade the serialized items or the clusters containing them, service orders are used to plan and execute effectively.

15-18 | Service

Various types of orders can be defined, such as internal and external orders, scheduled and not-scheduled orders, inspections and customer visits, and preventive and corrective work. These various types of orders must be handled within the service environment.

Based on the failure analysis, a component that fails too often can be recalled from the field. Failure analysis tools are available in the Diagnostics in the Call management module that can receive failure related updates from service orders. This process is supported by Field Change Order (FCO) functionality. You can also select all outstanding components using the item code.

An order is made to control the FCO, the costs can be charged to the production or sales department by using separate ledger accounts.

Service orders can integrate with external applications, such as SSA ERP Service Scheduler or SSA ERP Service Scheduler Assistant, to evolve intelligent and optimum planning. Service can also integrate with remote service applications to monitor and control progress at customer sites.

Service order processing

Service orders are generated from the Call Management module and Planning & Concepts module and SSA ERP Project. However, service orders can also be created manually. If required, the service order can be created from a quotation. Another way to create a service order is to generate orders out of the FCO functionality. Service orders can be defined and processed on active PCS projects, or on already delivered PCS projects.

The service order can have several statuses throughout the order life cycle, ranging from Free to Closed. These statuses enable you to control the service order. Interruption is a sub-status that you can use for parts non-availability or because the customer’s asset is not available or any other reason.

The following statuses are available with the following meaning:

Free: The order is currently not planned or scheduled. Everything can be changed.

Planned: To enable Global SRP to plan the order, which means that the parts required be allocated to the warehouse or purchased. The activities are soft allocated to the preferred service engineers for a configuration.

Service | 15-19

Blocked: The order is blocked for credit reasons; the financial department must investigate further.

Released: When the order reaches this status, the order is ready to be executed. If intelligent scheduling is required, this can be achieved by service scheduler or by service scheduler assistant. Alternatively, if fixed (preferred) engineers are allotted to service orders, a batch process can be run to plainly release a service order. In any case, this step would release warehouse material (if stock is available), and enables you to start execution of the orders. Emergency calls can be transferred to service orders in Released status directly.

Interrupted: For some reason, the order cannot be carried out, for example, hold for parts or asset not available. This is a sub-status within the status ‘Released’.

Ready (or Completed). The job is finished, material used, hours used, and so on, and can be entered in SSA ERP.

Costed: All costs and expenses are booked to the service order, the auditor can check the order. Contractual obligations and warranty obligations are checked to calculate the invoice price. This also means that costs are properly booked and the invoices for these service orders can be sent.

Closed: The invoice process is also carried out, which means that the order is entirely processed and, therefore, can be closed and deleted. However, before Orders can be closed the reconciliation processes in Financials must be carried out.

History: Orders that are costed can be posted to history.

The steps to carry out also depend on the service procedures that were selected. If, for example, the Preventive Maintenance for Plant (Internal) Maintenance service procedure is selected, no invoice is created but Service costs are booked.

If a warranty is valid for an asset, either no invoice is made or discounts are offered based on the agreements, but possibly a more detailed report about the problem will be required from the engineer. Repair warranty can be made applicable based on the company policies or based on a selection by you via a Service type; repair warranty offers 100% coverage.

15-20 | Service

Service resource planning

In the first stage, at the global service resource planning of the service order, materials are allocated to the selected warehouse or purchase orders are entered. In addition, the preferred engineers are soft allocated for the orders that must be carried out. In the second stage, the SRP or the batch process, the service orders are released if engineers are already allocated to the orders.

Service orders can also be scheduled and released more intelligently by taking into account constraints such as skills, availability, locations, and so on, by using SSA ERP Service Scheduler or SSA ERP Service Scheduler Assistant. These tools feature various planning constraints to use the engineers most efficiently and have high visibility of field service activities.

In Call Management, Contract Management, and Planning & Concepts, the service activities are defined in this module. In addition, from the service quotation, you can create a service order.

The following planning constraints and resource checks can be valid for the whole planning cycle. Bear in mind that you define the plan bucket yourself.

Area or service center: The service engineer can be responsible for an area.

Combine service activities: The service activities carried out on one configuration and/or location can be combined to work more efficiently, especially with calls.

Response time: The response time agreed in the contract, warranty, service order, or call to fix the problem.

Skills engineer: Without the right skills, the engineer may not be able to fix the problem.

Locations/sites: Service activities can apply to a whole location/site.

Calendar functionality: To check the working hours of an engineer or work center.

Appointment confirmations: In the Call Management and Maintenance Planning Concepts modules, you can make appointments with the customer.

Preferred engineers: An engineer linked to a customer asset is responsible in the first place, second place, and third place. For scheduling, these engineers must be checked first.

Service | 15-21

Overtime: Overtime allowed for an engineer is another check that can be done.

Available parts: Without available parts concerning the service order that must be carried out, you cannot reach a high first time fix rate. If the right part is not available, an alternative part can be delivered.

Service kit allocation: To carry out a service order, sometimes a service kit is required and, therefore, must be planned and allocated.

Asset calendar: A calendar in which the availability of an asset can be checked, for example, machines for plant maintenance or customer assets.

Planned maintenance: The machines must be available (no usage is planned).

Condition-based maintenance

Inspection templates, if defined and used, are copied while carrying out service activities. While recording the measurements either while performing service order activities or based on a customer or a field service report, you can register the readings into the object inspection registration. The system can prompt you to take actions if there is a major deviation from the norm or the expected values of these readings. These can result in further service order activities that can be added to the same order or can be added as a new service order.

SSA ERP Service Scheduler and SSA ERP Service Scheduler Assistant

The planning constraints can be effectively visualized or utilized to plan service orders, by using SSA ERP Service Scheduler or SSA ERP Service Scheduler Assistant.

SSA ERP Service Scheduler is a visual, graphical, and interactive tool that provides the dispatcher control over planning and scheduling of service orders. Scheduler helps visualize orders in various statuses with various resources and enables user-friendly features, such as drag-and-drop, to be used to achieve efficient scheduling.

SSA ERP Service Scheduler Assistant is a semi-interactive process that provides either the best order for each engineer, the best engineer for each order, or a list of engineers for selected orders if constraints are defined.

15-22 | Service

The user interaction comes in the form of defining the constraints under which selection can be made.

Both tools are meant for effective handling of engineer assignments for service orders, keeping in view constraints and certain other field service dynamics. However, tools such as these and SSA E-Service Remote are outside the scope of SSA ERP Service. For more information about these tools, refer to separate documentation.

Costing

All actual costs such as material labor, tools used, and travel costs can be registered. Declarations, hotel expenses, and so on can also be related to a service order. Expenses such as hotel invoices are first paid by the Account Payable module (SSA ERP Financials) and can be charged to the service order. Subcontracting costs can also be charged to a service order.

Hours spent on general issues such as car replenishment, car maintenance, collection of parts, personal problems, such as doctor’s visit, and so on can also be reported.

The costs can also be entered in the remote service application such as SSA Mobile Service (formerly called as E-Service Remote). For possible invoicing, which depends on the contract or warranty agreed, you can transfer the costs by remote access to SSA ERP Service from the field directly.

Order costs/amounts can be covered by any applicable/valid agreements such as service contracts or warranty or repair warranty or service order quotations or FCO based on the applicable discounts in each case.

The user can have a visibility into the gross margin or net margin per order, and take actions based on the perceived profitability of the order. Online margin control also makes it possible to get a quick overview of the costs on the Service orders.

Invoicing

The invoice process is triggered when you set the order or activity status to Costed. The cost lines that underlie the order or the activity are sent to SSA ERP Invoicing, from where further processing is carried out to send the invoices to the customer sites.

Service | 15-23

Depending on the case at hand, an order can be costed at once, costed at an activity level, or each cost line can be costed individually. Taxes applicable for each country are applied at the time of invoicing.

The invoice from a contract (installments) or an invoice from a maintenance sales order can be combined with a service order, into a collect invoice to prevent a bureaucratic burden in the financial department. In the background, the ledger accounts in SSA ERP Financials are updated. The order information is held until the financial reconciliation is carried out.

Spare parts logistics

The stock delivery is handled by the replenishment mechanism from SSA ERP Warehousing. For some regular parts and consumables, controlled by SIC, a service van can have unique reorder points. Expensive spare parts must be ordered. If the part is available in a central (service) warehouse, the part can be delivered by the overnight service. If the part is not available, a purchase order is created.

After the order lead time, the part will be replenished to the van related to the service engineer serving the customer. Another possibility is to ship the part by a third party to the customer’s location.

Component replacements

A replacement or a change in the customer's configuration means that the configuration is updated with the right serial number and other information. Configuration can also be updated with any changes to the anonymous items in the structure. This point is important for subsequent service and maintenance delivery, and is available in a basic form within the serialized item history/ tracking.

Field service returns

Return material can be controlled by the service order. If the service engineer must replace a component at the customer site, on the worksheet, on the SO, or by remote access, the engineer knows that the replaced component must be returned. When the parts must be returned, in the warehouse, a warehouse order of the type Receipt is created. You can send these parts back to designated warehouses, and can subsequently be taken up by work orders to carry out repair of parts.

15-24 | Service

Alternatively, the service engineer likely has drawn excess parts from warehouses to carry out replacement activities. In these cases, the excess parts can also be returned to the warehouses.

Field change order

The production department or marketing department can initiate a field change order (FCO). Production errors or component updates can trigger an FCO. The installed base must be investigated to select the appropriate configurations or assets.

The customers can be informed about a possible problem that can occur, and at what time their equipment could be repaired. You can generate, plan, and execute a service order for each customer.

The service order only differs from a usual service order in that the costs are charged to the marketing or production department, and that the customers get the replacements and the service activities free of cost, due to FCO.

Audit trail

For audit trail requirements, you can track and trace components and parts. As a result, a full overview of the repair and costs history must be available, which requires serial numbers.

You can retrieve information on where the part or component is, for example, installed in cluster XCV from customer ABC, or in work center 003 Broken Components, and so on. The full repair and cost history is available and updated for each component or part. On a high level, the history logs on the serialized items can provide basic information about the audit trail. Serialized item Dashboard provides more insights into the details on a case-by-case basis. The integration with Object Data Management applicable to document controls can also help the purpose of audit trail effectively.

RMA and Depot Repair

This section consists of the ways and means to handle parts coming into your company for repairs and replacements. This consists of two main parts: the Return Material Authorization (RMA) and the Depot Repair. RMA is achieved as maintenance sales transactions, and are handled through maintenance sales orders.

Service | 15-25

Depot repair is achieved through work order handling. Work orders also enable you to handle shop repair processes, by catering to important checkpoints such as signing off. If the parts under repair or replacement are already known, the parts are always tagged with their respective serial numbers. Unless items are consumables or items of generic interests, the parts are serialized and configuration controlled.

Maintenance Sales Control (MSC)

Maintenance Sales Control offers features not only related to RMA but also a little more than that. The maintenance sales order is the heart of Maintenance Sales Control. Maintenance sales orders can be registered either by entering them directly or by transferring the orders from a call. Each maintenance sales order can cater to handling of a number of part lines.

Basically, four types of item transactions can be handled within any maintenance sales order:

Part maintenance: When a part comes back for repairs, this can be handled as a part repair transaction. At this point, you must receive the part into a consignment warehouse to successfully carry out repair activities as a part of depot repair. A linked up work order is necessary when the repairs are executed through work orders, which you can do by using the WCS module. The part lines must wait until the completion of work orders and further delivery into a planned warehouse, also consigned, from where the item can be returned to the customer.

Part delivery: If parts must be delivered to a customer, this delivery is accomplished through a parts delivery line. The customers might possibly require new or upgrade type subassemblies or additional parts. The parts delivery lines enable you to deliver these parts to the customers.

Part receipt: Returns from the field of defective or healthy parts is addressed by the use of parts receipt lines. In some cases, return of parts might occur instead of parts delivered, or it might be parts returned as a part of rejection, or in some cases, it might be outdated parts sold back possibly at reduced prices. All of these issues are handled as parts return lines. By combining parts receipt and parts delivery lines, parts exchange is carried out. This means the customer gets a repaired or new part, while the service company will own the defect part. The opposite is true for part maintenance, for which the same part will be returned to the customer.

15-26 | Service

Part loan: During the absence of the part due to repair or due to the temporary nature of part use, the customer would require a loaner for short time which the customer can use for a limited amount of time and then return the part back.

In all the previous cases, you can invoice the customers for the services and the parts rendered. You can offer service contract or warranty coverage or repair warranty coverage for part lines involving already supplied parts.

Maintenance sales contract or warranty coverage can be achieved by defining specific coverage types on the items covered.

If the maintenance sales order originates from a call, you cannot close the call without closing the maintenance sales order. For parts maintenance lines, work order costs are rolled up to the coverage lines of the maintenance sales order.

After the parts are delivered, if required, against the replacements, and the loaner items received back after use the maintenance sales orders can be invoiced by sending the coverage lines to SSA ERP Invoicing. By seeking visibility into the gross or net margins on the coverage lines of an order, you can perceive the profitability of the order and if necessary modify before sending to Invoicing. The costs and revenues are posted to appropriate ledger accounts in the SSA ERP Financials; the maintenance sales order information is kept until the financial reconciliation is carried out.

Work Order Control (WCS)

Templates

To ease work/repair order preparation, templates can be used. First and easiest template is the reference activity, which was described previously. With the aid of the reference activities, you can compose a routing, which means that reference activities are copied and put in sequence. You can copy this routing to the work order.

An additional functionality to the routing is having routing options. By means of routing, you can model options that occur in instances to the master routing. When you copy the routing to the work order, you can also select the required options, which reduces the amount of operations on the work order.

A routing can be applicable for all items or be made specific for on item.

Service | 15-27

Work order structure

The carrier for work to be executed in SSA ERP Service is the work order. Work order creation occurs on receipt of the to-be-repaired Item, which is triggered by the maintenance sales order. The user can also create work orders manually.

A work order can have activities linked. These activities can be freely entered or can be created by using the templates as described previously.

In case of separate flows of repair of sub-assemblies and components, you can use follow-up work orders, which can result in an entire structure of diverging and converging work orders.

Work order execution

A work order can be planned, released, completed, signed off, and closed. In addition, the work order’s activities have unique statuses quite similar to the work order statuses. By parameter setting, you can decrease the number of statuses (like signing-off) to pass to support normal repair and repair according to regulations of authorities.

With the status Planned, parts (to be repaired and spare parts used for repair) are allocated at the warehouses. In addition, tools and general costs can be estimated.

When the order is released, Warehousing activities are triggered to get the parts to the shop. Actual registration of hours, materials, and other resources can be entered.

If required, an entire work order can be subcontracted to a supplier to provide the repair services. To enable this, linked purchase orders are generated with the planning process. Delivery of these types of purchase orders also indicates the completion of work orders.

If required, you can create follow-up work orders to provide repaired parts or sub-assemblies. You can also attach documents and certificates to the work orders or inherit these documents and certificates from the installed base, using the ODM features.

If the order is carried out according to the engineer, the work order status can be set to Completed. Still, the user can register still hours and so on. Subsequently, an authorized engineer can sign off on the order and finally close the order.

15-28 | Service

Closing the work order also specifies that financial transactions take place to empty the work order WIP account. If applicable, the maintenance sales order is updated with this information.

After this step, and after reconciliation takes place, the work order can be posted to history or deleted.


The data that is used throughout SSA ERP Service is maintained through Master Data Management. The data consists of the following:

Service organization

Service department/ service area

Service warehouses

Service employees and skills

Service item data

Reference activities and inspection templates

Cost and coverage types

Sundry service related definitions

Service organization

Service Department/ Service area

The service organization consists of resources and relationships, that is, service Department, service employees, service warehouses such as service cars, kits, and some details concerning these. You can define the service center at the following two levels:

Main service Department

Sub-service Department

This division of two entities is to model your organization in a way that provides information about capacity and execution abilities while for planning reasons these entities must be treated as one large group without any department borders.

Service | 15-29

Service warehouse

A service warehouse is a warehouse dedicated for service applications. Only the material required by the service engineers can be allocated in that warehouse. There are 4 types of warehouses that are allowed and used in the Service package. They are:

Normal Warehouse: A Warehouse that is used for Production, Sales, Purchase and Project can also be used in Service. This denotes a Warehouse in a fixed location. Transactions are like in any normal Warehouse.

Service Warehouse: A Warehouse similar to normal warehouse but can be used only in the Service domain. Transactions are also similar to normal Warehouse, but confined to Service domain.

Service Reject Warehouse: This is also a Warehouse like a normal warehouse except that it is used especially while returning parts that may have to be rejected or scrapped. Parts can be issued from scrap for recycling, for Maintenance Work orders or Service orders. Parts can be received for writing off on Service orders, Maintenance Sales receipts, and Maintenance Work orders.

Service Customer owned Warehouse: A Warehouse that is used to store parts belonging to Customers. So while receiving parts into this Warehouse, the company’s inventory doesn’t go up nor will it come down while issuing parts from such Warehouses.

In addition to the general/normal warehouse, two types of warehouse definitions are applicable for service from a Field Service perspective:

Service kits: A Service kit is a portable Warehouse, which is also linked with a warehouse (of the type normal or service). A Service Kit is defined and used in Service domain, whereas the inventory transactions are done as in the case of any Normal or a Service warehouse, including the replenishments.

Service cars: A Service car is a mobile Warehouse, and has similar definition and usage as a Service kit.

A service warehouse can be linked to a specific area. Warehouse planning and replenishing is carried out through the regular warehouse replenishment process. The normal warehouse can be used not only by Service, but also by Project, Manufacturing, Sales, and other applications. All warehouses can be replenished in the same way. This depends on the item type, which is either Manufactured or Purchased.

15-30 | Service

A service kit can be related to a service warehouse or to a model. You can use the service kit to store spare parts and tools that are required for the repair activities of a specific asset. To carry out service on an asset, SSA ERP Service can allocate service kits.

A service car can have the function of a warehouse. The spare parts required for the service orders to carry out can be delivered from the service car. Part replenishment is done as if the Service car is another warehouse, using the linked Warehouse.

Service employees and skills

Service employees are those who are used mostly for service-related activities, such as in carrying out orders, or in registering or handling calls, or as sales representatives for service sales, or as foreman, dispatchers, or handlers.

Each service employee must be defined with General as well as People (HR) related details for proper functioning. Each service employee can have a linked service car. Each employee must be defined with user profile details that are used during the transactions carried out by the employee.

Each employee can be listed with particular skills. These skills can be general skills in nature, such as knowledge in software coding, or electrical appliances skills, or plumbing skills. The skills also can be specific to a particular group of serialized items. For example, equipment such as aircraft will require special skills to complete repairs or address problems correctly.

Registering skills is important. To know and utilize the skills of your employees gives you a competitive advantage in getting the right person at the right place at the right time. Certain skills and employee-related data such as labor rates, labor types, can be defined and used from SSA ERP People. Skills and certifications can also be added as ODM attachments.

Service item data

Materials often form one of the important resources while executing service on products. Service item data deals with details to be used while using items for service or doing service on the items. The items defined in service data have a direct inheritance with the general logistic details specified, and also with details specified in other packages.

Service | 15-31

Similar to defining defaults to be used with an item group, you can easily define a new service item. You can define details pertaining to maintenance of that item, or details to be used while selling that service item, certain details regarding subcontracting, and particular logistic details required in the service processes.

Items of the types Manufactured or Purchased can be defined, and items of the type Service or Cost to account for subcontracting purposes. You can also define customized items, useful while servicing PCS projects identified as physical breakdown structure.

Items are used at various places in repository definition and transactions. Items can be used in defining the bill of materials, as item breakdown, and in inheriting details into serialized items that are specified by the customers. Items can be used while defining estimated cost lines with activity repository and while defining transactions. Items, particularly of type Cost and Service, are also used while raising purchase orders and accounting for subcontracting.

Price books can be defined for service contracts or transactions purposes while defining the scope of service on the items to be serviced for the customers. The existing Price & Discount book features available in SSA ERP Order Management Pricing can be used while using items as spare parts. In addition, each item inherently carries a unique generic price.

Reference activities and inspection templates

This repository of activities is based on a service organization’s experience. These activities are service activities that can be executed within a given finite time: long enough to act as buckets of planning. Any activity can be specific to field service, depot repair, or both. Reference activities are tagged with coverage types to provide visibility into the type of coverage that might apply.

A reference activity can also contain details about recommended ways to execute, such as duration, or suggested frequency of execution. This can also suggest whether the activity is recommended for subcontracting.

You can define the resource requirement lines that might be incurred while carrying out this activity. Subsequently, you can have an overview of the costs that might be incurred while you carry out this activity.

15-32 | Service

In addition, while you carry out these activities, you can also specify the inspection template, which can give the recommended list of measurements to be considered while performing this activity. You can also make the inspections specific to a given product or component, whose measurements can be recorded while executing service activities. Inspection templates are especially useful while carrying out field service, or while carrying out service, which usually involves significant movement of resources.

Cost and the coverage types

Cost types

The following cost types are supported in the service-related applications and the related integration points:

Material: Any items that are tangible, manufactured, or bought out can be accounted under this cost type.

Labor: Any task, activity, or travel performed as an operation by an employee can be accounted for under the Labor cost type.

Tools: If the help of tools is sought while executing service, or if tools are specified in the agreements, the tools can be accounted under this cost type.

Traveling costs: If travel takes significant time and effort, this cost type is useful as a separate accounting attribute. Note that the use of this cost type is minimal for depot repair.

Subcontracting: If a supplier due to various reasons, either wholly or partially, executes an activity, this can be accounted for under this cost type.

Help desk: All accounting related to providing support services to customers can be achieved by using this cost type.

Other: If any variant that cannot be accounted for in any of the earlier categories, the variant can be accounted for under this cost type.

Service | 15-33

Coverage types

Coverage types are used as a differentiator for coverage under various agreements, such as warranties, contracts, or quotations. A coverage type is also used as a differentiator while defining reference activities.

You can use a coverage type to indicate conditions under which coverage can be afforded to the customer, under an agreement. By changing the coverage type in cases not applicable when damage occurs to equipment because of a fault at the customer site, then, simply by changing the coverage type, you can deny agreement coverage.

Sundry service related definitions

Service type or Service order type

This type is a differentiator to identify the conditions under which service is provided such as preventive maintenance, breakdown-based maintenance, and so on. This also provides a basis for planning, and also for logistic and financial analysis. This can also be used to differentiate repair warranty application.

Tasks A task is a specification of short-term work carried out by employees.

Checklist

A checklist provides a list of checks to be carried out while performing an activity. These checks can be useful and can be copied while carrying out service order or work order activities.

Measurements

The measurement is a definition based on which the use-based or condition-based maintenance can be assessed. This generic definition is used elsewhere based on the context.

Maintenance concept

A list of Reference activities with a schedule proposal either attached to an Item or not is called Maintenance concept. Using the Maintenance concept it is easier to generate Maintenance planning for similar Items.

15-34 | Service

Routing

A Repository of a set of activities categorized by options, defined together which might be selected while carrying out Depot repair.

Module relationships in SSA ERP Service

This section describes the relationships between various modules in the SSA ERP Service.

This section describes the following relationships between the modules:

Master Data Management (MDM) Provides definitions and links with every other module within SSA ERP Service if service engineers, the service center, service area, skills, or any other service-specific table is used. This module enables the definition of service related details of items, and the standard activities.

Configuration Control (CFG) Asset data such as clusters and serialized items that make up the assets are used at many places in the package (and across packages). These assets are used to define maintenance concepts. Asset data, such as valid warranty or repair warranty, is checked when a service order or maintenance sales order is carried out. If a warranty is valid for an asset, a response time applies to solve the customer problem. If an invoice is created, the warranty conditions, such as discounts, are checked. Asset information, such as the installed base of a customer, can be shown to relate the call to an asset or configuration in the CTM module. Item structure data is defined in the CFG module also as prospective serialized items with clusters. If the service provider does not know all the data, for example, serial number or components, you can use this data in a contract or quotation.

Contract Management (CTM) All contract and warranty data can be required for the CLM, SOC, and MSC modules such as the agreed response time coverage if the modules are liable for contract/warranty. This includes Contract quotation management.

Call Management (CLM) Details about the problem reported and assessed can be transferred to the SOC or MSC module. Resources can be spent in processing the call, which can be invoiced directly from this module.

Service | 15-35

Calls transferred to the SOC module to send a service engineer on-site or to the MSC module for off-site repairs or replacements.

Subcontracting Module (SBM) Service and Maintenance carried out on subassemblies might require OEM service and attention. A service contract with a customer can be better handled with subcontracting agreements with the suppliers of subassemblies.

Planned Maintenance (SPC) Maintenance concepts & PM schedules are defined in the SPC module. To carry out the required service, this can result in service orders in the SOC module. The Preventive Maintenance schedule is input for generating service orders.

Service Orders (SOC) The call is reported to the CLM module and now feedback is received about the completed service order. Preventive Maintenance schedule is input for generating service orders. Condition based maintenance can be managed. Information about service orders originating from a call can be retrieved. A customer requires information about the current status, order costs, or quotation.

Return material authorization (MSC) All items in use at customer sites may require repairs, replacements, or upgrades. Complaints about items could originate from a call. Items requiring repairs are handled in the WCS module.

Depot Repair (WCS) All items requiring repairs, upgrades, and validations are carried out through work orders. Work orders can be carried out on anonymous items, by retrieving them from the warehouses directly or on customer-specific items originating from the MSC module.

Parameters Here, you can set the operating conditions of the SSA ERP Service modules. This module affects the operation of every other module.

15-36 | Service

The following figure shows at a glance the coherence of the SSA ERP Service components:

MDM

CLM CTM SBM

CFG

SOC

MSC

WCS

SPC

Item BreakdownsClusters & Physical BreakdownsSerialized Item History

Service organization Reference ActivitiesService Items

Parameters

Response TimesProblem trackAsset ID

Plan timeAppointmentActivity

PM termsPM Schedule

Sub-assemblies Support

RepairsPlan time

Product supportPart Services

Response TimeHelpdesk terms

Repair termsCost coverage

Introduction

This document provides an overview of the functions and features offered by the SSA ERP Quality Management application. SSA ERP Quality Management helps manufacturing and process industries to monitor and improve the quality of their products. The Quality Management system helps industries perform regular inspection procedures to attain the required quality. QM uses logistical flow of products to schedule inspections. In every company, products, including raw materials, end products, and products in between manufacturing steps, are regularly inspected to make sure the procedure runs smoothly, to review what went wrong, or to determine what could go wrong during production, distribution, or in the time that products are in inventory.

16Chapter 16 Quality Management

16-2 | Quality Management

Product Testing and Control

Introduction

Product Testing and Control (PTC) is the only module in SSA ERP Quality Management (QM) that governs the activities that are required to control the flow of products that are selected for inspection. The basic product data structured by the characteristics will be inspected in QM and the PTC module carries out the entire inspection procedure.

The basic data on which the products are inspected is to be setup. The inspections can be carried on the following:

Purchased products.

Sales Products.

Manufactured Products.

Products stored in Inventory

Products during Warehouse Transfer

The PTC module in SSA ERP QM:

Production

Sales

Purchase

Warehousing

QualityManagement

PTC

Quality Management | 16-3

The Modules that are related to PTC

ROU

PUR

SLS

SFC

INHIBD

ISA

IPU

IPD

WMD

Item Data Orders and

Schedules

MCS

PTCBOM COM

INR

QM inspection orders can be generated for the following origin orders:

Purchase orders in the Purchase (PUR) module: SSA ERP Order Management.

Sales orders in the Sales (SLS) module: SSA ERP Order Management.

Production orders in the Shop Floor Control (SFC) module: SSA ERP Manufacturing.

Storage inspection orders in the Inventory Reporting (INR) module: SSA ERP Warehousing.

Warehouse transfer orders in the Inventory Handling (INH) module: SSA ERP Warehousing.

The item data that is used in PTC module of QM is received from the following modules:

Item Purchase Data (IPU)

Item Sales Data (ISA)

Item Production Data (IPD)

Warehousing Master Data (WMD)

Item Base Data (IBD)


The following modules are also related to PTC:

The Bill of Material (BOM) module, the item data modules, and the Routing (ROU) module are used to create a product structure. The product structure is used to create an inspection order for a finished product or component, or to create an inspection order after a specific operation.

The Inventory Reporting (INR) module is used to select portions of the inventory that must be inspected by means of storage inspections.

The System Table (MCS) module provides PTC with information about skills, units, departments, warehouses, and so on.

The Common Data (COM) module provides PTC with employee data.

The PTC module includes the following business objects, which are described subsequently in this chapter:

Master Data

Algorithms

Quality IDs

Order-Specific Inspections

Standard Inspections

Storage Inspections

Inspection History

QM Parameters


The Main flow between the business objects in PTC:

Master Data

Standard Inspections Storage Inspections

Calibrations

Order-Specific Inspection Data

Inspection History

MCS

COM

WMD

Quality IDs

MCS

IPU

ISA

WMD

IPD

IBDItem Data

BOM

SFC

PUR ROU

SLS

Origins

INH

INR

Master data

The Master Data business object is used to specify the products and the procedure that must be inspected. The inspection of the selected products is carried out based on characteristics. The characteristics specify the part of the item that must be inspected.

The Master Data business object receives data in regard to units, departments, skills, locations, employees, warehouses, and so on from:

System Tables (MCS)

General Data (COM)


Warehousing Master Data (WMD)

Characteristics refer to a particular quality or distinctive characteristic of an item. The test data and inspection order lines are based on characteristics. Characteristic type and characteristic method governs the characteristics.

You can use Option as a characteristic type, which indicates the values a characteristic can have and whether or not that value is acceptable. For example, the set color option can contain the options red, green, and blue. The options can be linked to an option set.

You can use Aspects to distinguish between characteristics, which is useful when an item has the same characteristic more than once. For example, diameter and circumference can be characteristics of an item screw. You can use aspects to indicate the parts of an item to find out the diameter and circumference. The aspects of an item screw can be top and bottom. The characteristics can be linked to an aspect.

You can use Tests to refer to the inspections to which characteristics are subjected, and the test that is specified is to be linked to a characteristic, or to an aspect/characteristic combination. For each test, the characteristic’s value can be either qualitative, that is, the characteristic’s value is determined as good or bad, or quantitative. In other words, the characteristic’s value is a quantity such as 11 cm. The test can be destructive if the effect of the test on the item results in a destroyed item.

You can use Instruments to measure the values of a characteristic. The values measured then determine whether or not the quality of the product falls in the established quality level. You can enter the calibration data for every instrument.

Some of the instruments that are used for testing must be regularly calibrated. The base values of these instruments can change as time goes by, which results in the instruments becoming unfit for use. Instruments that are not calibrated regularly can produce misleading inspection results, which result in items being unjustly rejected or accepted. The calibration procedure is used to control the calibration data, and to indicate whether an instrument can be used, or is blocked for use because the instrument is currently being calibrated. The calibration procedure does not influence any inspection order. The calibration procedure only generates a message to indicate that an instrument is blocked for use. You can maintain the calibration history to display the calibration data, sorted by instrument or by date.

In the test area, you can carry out and define a test.


Algorithm

Quality inspections are not always simply a matter of taking measurements on characteristics. Based on measurements, some times complex calculations are also required. These calculations may or may not include product specifications as part of the calculation. Algorithms are used to perform those calculations. You can use this procedure when an algorithm is indicated as characteristic method.

Each algorithm is an expression that contains the variables and the standard mathematical expressions, such as logarithms, sine, cosine, and so on that you can use in the algorithm. The algorithm variables are assigned to characteristic, or to a characteristic/aspect combination. The characteristics must be of the characteristic type Fraction or Integer when the algorithm contains algorithm variables.

Quality IDs

You can use a quality ID to link quality standards and tests to a product. The characteristics to be tested, and all related data, are not directly linked to an item. Defining the quality standards and tests for each product separately is unnecessary. You can use a quality ID more than once, which reduces time considerably.

QM uses test groups during the generation of inspection orders. For each test group, the test type and the sample size data must be provided. The test groups must be linked to a quality ID. For each test group that is defined for a quality ID, one inspection order is generated. The characteristics are tested on the same sample. Inspection order is created for each test group, and an inspection order line is created for each characteristic. You can enter a test sequence to determine the sequence in which the characteristics of the test group must be tested. The test type in the test groups for each quality ID indicates the way an inspection order is generated. The sample size indicates the number of items that are selected for testing. The acceptable quality level determines the minimum percentage of a test sample that must be approved to have the entire item quantity approved.

The quality ID is linked to characteristics, or characteristic/aspect combinations. The data that is related to the characteristic or the characteristic/aspect combination can be modified.

The norm value that the characteristic must have in the test, and the tolerated deviations from the norm value can be entered.


The quality combination is used to establish a link between the following components:

The quality ID, with all the data that concerns characteristics and tests.

An item or a group of items (quality group). The items can be selected on the basis of the item code, on the basis of a bill of material, or on the basis of a business partner the items have in common.

The origin of the inspection:

Sales (SLS)

Purchase (PUR)

Production (SFC)

Material (BOM)

Routing (ROU)

Storage Inspection

Warehouse Transfer

Order-specific inspections

You can use the following origins for the order-specific inspections.

Sales - Sales Order Lines

Purchase - Purchase Order Lines

Production - Production Orders

BOM - Estimated Materials and Materials to issue for Production Orders

Routing - Production Planning

Inventory Handling - Warehouse Transfer

Inspection orders are used to structure the inspection of products that are purchased, produced, or sold. Inspection orders are generated automatically at a particular stage in the order procedure.

The input for the generated inspection orders is quality combinations. In a quality combination, a specific item, or all items that originate from a specific module, is linked to a quality ID. Quality IDs determine how an item is inspected.


Samples and test results are linked to an inspection order. After the test results are entered, the inspection order can be completed and processed. The inspection order can then be closed and posted to history.

An inspection order can block the items that are selected for inspection and, consequently, the purchase procedure, the sales procedure, or the production procedure depending on the parameters defined in QM. After the inspection order is finalized, the selected items are unblocked and available for use.

The result of an inspection order is the assurance that the flow of goods in a company meets the required quality standards, and that all goods have been checked according to the standards set up by the company.

Order-specific inspections are used when the inspections are deviated from how the inspections are defined in the quality combination, for example, when a specific characteristic is to be inspected on a product that is not defined in the quality ID. The quality ID is linked to the quality combination. By using the order-specific inspections, the inspection data is adapted to a specific situation. The changes in the inspection data do not influence the master data. Whether or not the order-specific inspections business object is used depends on the value of the order-specific inspection data defined in the QM parameters.

The overview of the origin order, such as Sales, Purchase, Production, Material, or Routing, for which a quality combination has been defined, can be provided in the order-specific inspection. Based on these orders, order-specific inspection data is generated. The order-Specific Inspection data includes the test data and the sample data. This data can be modified to create order-specific data. Order-specific inspection order line is available for each characteristic or aspect/characteristic combination. The data related to the characteristic can be modified to create order-specific inspection data. Order-specific inspection data is linked to the orders and the schedules in the Sales (SLS) module, the Purchase (PUR) module, and the Shop Floor Control (SFC) module. However, the actual inspection order is generated based on the warehouse order that is related to Sales, Purchase, or Shop Floor Control.

An exception to this is the origin Routing. Routing’s inspection orders are related to the operations of the Shop Floor Control order itself.


Standard inspections The overview of the standard inspection orders for which inspection orders are created can be seen easily from the standard inspections. Each inspection order is based on one of the following origins:

Sales (SLS)

Purchase (PUR)

Production (SFC)

Material (BOM)

Routing (TI)

Warehouse Transfer

You can manually create standard inspections, and the inspection-order status, along with the blocking method and the result of inspections, can be displayed. The link between the origin and the quality ID is established by means of the quality combinations.

QM uses the data in the Master Data business object and the Quality ID business object to generate the inspection orders. If any order-specific inspection data is available, QM uses this data.

The inspection order lines are used to modify the data that relates to the characteristics to be tested. The inspection orders can be printed to print the documents that accompany an inspection order, depending on the mandatory printing of inspection order, which is defined in the QM parameters. After a standard inspection order is created, but before the inspection can be carried out, a sample must be drawn that is representative of the entire order. The sample can be drawn more than once, but the total quantity of these samples cannot exceed the sample size that was specified for that inspection order. Each sample can be subdivided into test quantities. A test quantity is the smallest portion of items that is tested.

For example, if the sample size is 20 liters, a test quantity of 4 liters means five test data entries (5 x 4 liters = 20 liters) are created. To complete the inspection order, the entire sample must be used. In other words, the total sample quantity must equal the sample size.

The test data can be entered for each characteristic or by serial number, depending on the value defined in the QM Parameters. You can enter this test data only for the order lines that were maintained in the standard inspections, and that were created for each test-quantity portion:


You can collectively complete the inspection orders for which the test data is entered. Before the inspection orders are completed, QM checks whether the number of samples are sufficient, as well as the number of inspections for each inspection order line are sufficient.

After an order line has been completed, you cannot add, modify, or delete any inspection data, but you can change the status of the order line back to Active from Free.

The inspection orders must be processed and can also be used to evaluate the test results along with the effect on items and quantities. The inspection order results that have been reported as good or bad are mapped, and the rejected and accepted quantities are calculated. If the QM Only Recommended option is defined in the QM Parameters or in the quality combinations, the inspection results are only recommended and, if this option is not defined, the inspection results are mandatory.

You can check and close the inspection orders, depending on the parameters defined in QM. If the blocking method of the inspection order is Continue, the inspection order is closed. QM checks the quantities that have been reported in the purchase procedure, sales procedure, or production procedure, and compares the quantities with the quantities that have been entered in PTC. A report is generated that displays the compared quantities of the origin and PTC.

To keep track of an inspection order, you can use the inspection order status. The sequence of statuses for an inspection order is strictly regulated.

The following table shows the status changes of inspection orders:

The status changes of inspection orders

From status

To status Session

- Free Inspection Orders

Free Active Enter Test Data by Characteristic

Enter Test Data by Serial Number

Active Completed Complete and Process Inspection Orders

Completed Processed Complete and Process Inspection Orders

Processed Closed Check and Close Standard Inspection Orders


The order status is, by default, set to Free when an inspection order is maintained. You can modify the inspection orders that have the order status Free. You can print inspection orders regardless of the inspection-order status. Depending on the Mandatory Printing of Inspection Order Documents parameter defined in the Quality Management parameters, the printing of order documents will be mandatory.

The order status of the inspection order changes to Active when the test data is entered and, after the inspection order line has been completed, the order status changes to Completed. As soon as all inspection order lines have the order status Completed, the entire order is set to Completed.

After you complete an order line, you cannot longer add, modify, or delete any inspection data unless the order line status changes back to Active.

If the origin order is completed and approved, the inspection order status is set to Closed.

You can globally update the order-specific inspection data where in the existing inspection data will be deleted, and new inspection data from the master data will be generated.

Storage inspection

Storage inspections are used to maintain the inspection orders and the results of storage inspections for items in the inventory. The items for which a storage-inspection order is generated are blocked in inventory. A storage inspection is processed as an inspection order in the standard inspection-order procedure.

The samples and test results are linked to a storage inspection. After the test results are entered, the storage inspection is completed and processed and, later on, the storage inspection can be closed. In case of destructive inspections, you must manually adjust the inventory.

The storage-inspections procedure begins with storage inspection generation and the selected item’s inventory gets blocked. You can manually add the new inspections and you can modify the existing inspections in storage inspections.

To use the storage inspections to group the generated orders, you must define sequence numbers. The sequence number of an inspection order determines the characteristics that are tested on various samples.


After you create a storage-inspection order, you must inspect the allocated goods. The inventory is linked to each sequence number. The inventory under a particular sequence number is inspected together with a set of inspection orders. Only inventory of the same project or item can be inspected together. To maintain the storage inspection orders, you can also create or modify the inspection order lines.

To print the documents that accompany an inspection order, you can print the inspection orders, depending on the setting of the Mandatory Printing of Inspection Order check box in the Quality Management parameters. You can draw the sample more than once, but the total quantity of these samples cannot exceed the sample size that was specified for that inspection order. The inspection order can be completed when the entire sample is used.

After the samples have been drawn, you must perform the following two steps to finalize the storage inspection order:

1 Enter the test data, either by characteristic or by serial number accordingly.

2 Complete and process the inspection orders

After the storage inspection is processed, you can close the storage inspection where in both the accepted and rejected quantities will then be unblocked. Calculate whether the accepted and rejected quantities match the recommended quantities and, if these quantities match, the storage inspection order is closed. The status of the inspection order is then set to Closed.

If rejected quantities exist, these quantities must be subtracted to adjust inventory. Because inventory actions cannot be performed automatically, you must correct this manually.

Inspection history

You can archive inspection orders for future purposes by means of the inspection history. The data that was entered in the inspection order is stored in the inspection history. Only inspection orders with the status Closed can be posted to history.

You can delete the inspection data related to a specific order from the history.


You can print the inspection plan history to print a report of origin orders, with accompanying inspection orders and test plans, from the inspection order history. In the test plan, data is included about quality ID, test group, test type, norms, and so on.

You can print the inspection result history to have a report of inspection results from the inspection order history. In the report, an overview of the recommended quantity accepted or rejected, and the actual quantity accepted or rejected, is displayed.

A more detailed report with the inspection results that are split up into inspection order, position, and sample can also be printed but this again depends on the parameter.

Quality Management parameters

Parameters are defined in the Quality Management package according to the requirements from the respective origins.

Origin

The following three options are supported in Quality Management for the origins:

Quality Management Implemented: Quality Management can be implemented according to the necessity for the following origins:

Sales

Purchase

Production

Material

Routing

Warehouse transfer

Storage Inspections.

Specific inspections: If required, you can create specific inspection for the following origins:

Sales

Purchase


Production

Material

Routing

Warehouse transfer

QM only recommends: Quality Management will provide the recommendations for the following origins:

Sales

Purchase

Production

Material

Routing

Warehouse transfer

Series

Number group can be provided in inspection ordering

Series can be provided for:

Sales Inspection Orders

Purchase Inspection Orders

Production Inspection Orders

Material Inspection Orders

Routing Inspection Orders

Warehouse Transfer Inspection Orders

Storage Inspection Orders

Blocking reasons

You can provide the reasons for various inspection statuses for Block on Operation as well as Block on Completion of Operation:

Block on operation:

Active Inspections

Inactive Inspections


Processed Inspections

Block on completion of operation

Active Inspections

Inactive Inspections

Test data

Enter test data either by characteristic or serial number

Mandatory printing of inspection order documents

Example

An inspection order is generated for a specific origin in SSA ERP Quality Management when the order is defined in the Quality Management parameters.

Introduction

SSA ERP Object Data Management (ODM) ensures that the product data is handled properly and that the most stringent product life-cycle management processes are applied. SSA ERP Object Data Management extends the power of SSA ERP while creating an integrated product warehouse, which results in a complete life-cycle management solution.

The ODM solution exposes important product data information to any number of business entities in the enterprise, including sales, marketing, financials, customer support, and so on. ODM enables you to access, view, and even change (given the appropriate level of access) product metadata and physical files. ODM also helps you manage data in a way that enables you to increase productivity and reduce time to market. Businesses need enterprise-wide solutions to maintain the competitive edge.

SSA ERP ODM offers SSA ERP users easy access to any document in a globally distributed setup. With its revision and status control capabilities, ODM becomes an important component towards providing a complete product life-cycle management solution.

ODM provides fully integrated Document Management, Change Management, and Folder Management facilities for SSA ERP users.

17Chapter 17 Object Data Management

17-2 | Object Data Management

You can use a query to retrieve data based on user-defined conditions of any SSA ERP entity. You can use an advanced query to view ODM entities in a report format.

SSA ERP ODM enriches the power of SSA ERP through the ability to link external files to the SSA ERP entities and manage these files linked to document revisions. The life-cycle management system is available for documents that are attached to SSA ERP entities such as Items, Routing, Employees, Purchase Orders, Sales Orders, and so on.

Document Management delivers a powerful cataloging system that simplifies document retrieval and controls the authorized file access. Document life cycle and document revision management ensures that the most recent, correct version is always available. The associated files can be viewed easily redlined and edited by applying a variety of third-party applications, such as Microsoft, CAD, or any viewing application.

Dynamic market environments require the implementation of flexible yet consistent change management practices due to delivery time constraints, quality improvements, and cost reductions all of which are driven by the need to maintain customer satisfaction. Change management offers tools to control product change processes and can be used with multiple SSA ERP entities for ensuring a total customer satisfaction.

Engineering items, drawings, and work instructions can all reside in a single folder for rapid access and control by making use of Folder Management.

Advanced query and reports facilities are supplied in the SSA ERP ODM to quickly search the SSA ERP data.

The ODM browser is an advanced graphical tool that provides a user-friendly display of the data and the data links. The Graphical Object Browser enables navigation through complex hierarchies, while presenting multiple entities and their related items as a tree structure.

Object Data Management | 17-3

Overview features of ODM

Establishes a coherent product information warehouse across the extended enterprise.

Enables revision-controlled document and file links to any SSA ERP entity.

Provides secure online access to a globally dispersed product information repository.

Enables simultaneous up-to-date sharing of critical product and process information.

Automates engineering (ECO/ECN) and non-engineering approval and change management procedures.

Eliminates multiple data entry points and data redundancy risks.

Facilitates ISO/QS 9000 certification by ensuring tight control and tractability of product and process information.

Integration of ODM with other packages of SSA ERP :

SSA ERP Object Data Management includes the following modules:

Document Management

Change Management

Folder Management

Query and Reports

Configuration


Document Management

Introduction

The Document Management module in the Object Data Management package is intended to provide general document management in SSA ERP . Document Management ensures the efficient use of secure, consistent, and reliable document information through a number of features:

Controlled access to the documents

Secure storage of the document contents

Document life-cycle support

Management of the relationships between documents and other objects in the SSA ERP database

Document templates

The standard SSA ERP ODM authorization mechanism is used to determine the actions to be performed by individual users on various Document Management entities. The set of actions that a user can perform on a document, file, or any other object, depends on the user’s role.

User roles are assigned permissions to perform different operations on different objects, using the SSA ERP ODM authorization mechanism. Conditions can be associated with permissions to specify that a certain user role can only perform a specific action on an object if a particular condition is fulfilled.

The Document Management module contains the following Business Objects, each of which are described in the subsequent sections in this chapter:

Libraries

Document Type

Documents

Document Revision

Files

Hard Copies


Libraries

Logical libraries are used to organize data in a hierarchical structure. The Document Management module uses the logical library mechanism to create logical libraries for documents. These logical libraries are referred to as document libraries. Document libraries are used to catalog documents. The objects that can be contained in document libraries are sublibraries, documents, and vault areas.

Every document is assigned a document library. Document libraries are used to manage vault areas for documents and, therefore, vault areas must be associated with each library.

Vault areas are assigned to document libraries by defining one or more vault area nodes for each library. These vault areas are the primary vault areas. Multiple secondary or related vault areas can be associated with each of these primary vault areas. Files attached to documents in the library will be moved to this primary vault area when the document revision is submitted or released in case of quick approval mechanism. A copy of these files will be kept in the related vault areas, as well.

Document type

Documents types are assigned to documents. The document type is used to define the document revision mode and can also be used to define the document identifier mask, as well as the file types that can be attached to document revisions.

Revision modes are assigned to each document type. The corresponding revision mode is applied to all documents of a given document type. The revision mode is a combination of the document type, and whether hard copies and files have revisions.

Document type reviewers

To make the review process more efficient, a committee that consists of a chairperson and reviewers will review the documents. The chairperson can add reviewers to the document management review committee. A document management committee can be associated with a document type. All the reviewers who are part of that committee, including the chairperson, automatically become part of the document type. The chairperson can assign different sets of reviewers for different document types.


Document templates

Document Management provides another feature by which the user can create template files. The template file, such as any other file is attached to a document revision. The user can attach templates for each document type. In addition, you can attach more than one template file for a particular document type, provided the file type of the template file is unique. After you create a template for a document type, the contents of the template file is copied to the new file, as long as the user attaches a file to a document revision and chooses the template option.

Documents

Document information can be stored in electronic computer files (physical files) or on a non-electronic medium such as paper (hard copies). Access to this information is always from the document, which is the unit of control for the user in SSA ERP ODM, which acts as the cover page for the files and hard copies. If no file or hard copy is attached to a document, the document is a purely logical entity, generally used for grouping other documents.

Creating a document creates its first revision. Document revisions track changes to documents and their attached files and hard copies. Most work with documents is actually performed via the document revisions. Document revisions are assigned a status, which indicates their position in the life cycle such as In Design, Submitted, Approved, Released, Expired, or Withdrawn, and so on. The file operations that can be performed on a document revision depend on the revision’s status.

Document reviewers

The reviewers are imported to the document based on the document type and the associated committee to the document. The default committee can be changed at the time of creation of the document and the reviewers can be individually assigned to the document.

Document revision

The key functionality of a document life cycle is:

Document revision status as part of a life cycle.

Revision history.

Check in and check out of files.


Concurrent Engineering.

The document revision is the main object used to manage the document life cycle. Files and hard copies can be attached to document revisions, such that different revisions of one document can have different sets of files and hard copies.

The document management module provides two methods of working with documents.

The standard method is that as part of their life cycle, documents must be submitted and approved before they can be released. However, this life cycle may not be relevant to all types of documents (for example, some types of reports and some line-of-business documents). The user can specify that these documents can be released directly, without going through an approval process. These documents are referred to as light documents.

Description of the document revision status: In Design

The document revision is either a first revision of a new document, or a new revision of an existing document. When the document has this status, any user with the necessary authorization can modify it, or can attach files or can hard copies and can proceed with the life-cycle operations (by an authorized user) of document revision.

Submitted The document revision has been submitted for review. When the document has this status, any user with the necessary authorization can view the document files, and can redline the linked files. The files are moved from the work area to the vault area that is defined for the document library

Approved The review process has been completed successfully. Redlining can no longer be performed, but the redlined files (if any) can be viewed. The attached files to the document revision are not moved.

Released The document revision has been released. The development of the document has been completed successfully. The files are moved from the work area to the vault area that is defined for the document library in case of light documents.


Rejected The document revision has been rejected at some stage of the review process. No new links may be made to this document revision during this status. The attached files remain in the vault area.

Redesign The rejected document revision has been redesigned and a new In Design revision is created. The original files can remain in the vault depending on the requirement; otherwise the files are moved to the user's default work area.

Revise The released document revision has been revised which creates a new In Design document revision and all the files can be copied to the default work area of the user depending on the necessity of file.

Withdrawn The document revision has been withdrawn. The content is obsolete. No links may be made to this document revision. A document revision can be withdrawn even if it has links to any SSA ERP entity, files, and hard copies.

Expired Already released document revision will be expired, when another document revision of the same document is released.

The system administrator can define secondary document revision statuses. The secondary statuses do not affect the behavior of the life cycle of the Document Management module.

Document Revision Reviewers

The review process can be of two types – Normal or Fixed Reviewers mechanism.

For fixed reviewers mechanism, the review is done in sequential number and reviewers must to provide the recommendations to do the final review by chairperson.

Links between Document Revisions

Links between document revisions can be used to represent a document comprising many components. The compound document is seen as set of documents that are related in a particular order: either a set of parallel documents, or a main document and its subdocuments.


There are three types of links between document revisions:

Two-way reference: a mutual see also relationship.

One-way reference: an affects (is affected by) relationship with a clear asymmetry.

Parent/child: the child document is logically an element of the parent document. In addition, the physical file attached to the parent document may contain a pointer to the physical file attached to the child document.

Linking Document Revisions from SSA ERP entities

The standard main overview session for Baan entities has a toolbar icon, resembling a paper clip, for attaching documents and document revisions. The Edit menu contains the Attachments option, which provides the same function. The file can be linked directly to any ERP entity that is defined in ODM very easily while giving the minimum requirements.

Files

When a file is first attached to a document revision, it is located in a work area, and is considered to be in checked-out state. For standard documents, attached files are checked in when a user submits the document revision for review, and in case of light documents, when a user releases the document revision. When a file is checked in, file is moved to a vault area.

Files must be checked out before they can be modified in any way. Files are checked out by the system either as part of the life cycle.

SSA ERP ODM manages the files attached to document revisions. SSA ERP ODM maintains information about them, controls access to them, and facilitates working with them. The document type of the document revision determines whether or not the files are assigned with revisions.

The following cases show how a group of files may be attached to the same document:

A document consists of several chapters. Each chapter is a separate file, but the files are always part of a single unit.

A very large image, which is scanned as several pages. Each page is a separate file.


A document has neutral format files. One file is for editing, for example a CAD drawing of an item; one file is for viewing, for example an image of the same item; and another file is for printing, for example a plot file.

File types

When a file is registered, it must be assigned a file type. The system administrator is responsible for defining file types. Each file type is associated with one or more file extensions.

Registering files

A file can be registered and attached to the document revision and can be detached with the document revision depending on the requirement.

File operations

The following file operations can be done for a file that is linked to the document revision depending on the individual status and requirement:

View a File

Print a File

Edit a File

Check Out of File

Undo Check out of File

Redlining File

E-mail a File

Moving and Copying Files

Making Local Copies of Files

Archiving released Files

Hard copies

The contents of a document may be stored using paper, polyester film, or some other medium, which are referred to as Hard Copies. These Hard Copies are stored in a certain location depending upon the ease of use and requirement. Hard copies are registered in SSA ERP ODM by attaching them to a document revision, and cannot be registered independently.


The document type of the document revision determines whether or not the hard copy has revisions.

Document Management integrations

The documents links can be maintained throughout the business process flow from source entity to target entity. There are three methods in ODM that are supported:

Copy links: The document link is copied from source entity to target entity.

Copy documents: A new document is copied from source entity to target entity.

Reference documents: The documents of related object can be seen along with the documents of main object.

The Entities involved in the integration process are:

SSA ERP Services

SSA ERP Order Management

SSA ERP Manufacturing

SSA ERP Projects

SSA ERP People

SSA ERP Freight management

SSA ERP Warehousing

SSA ERP Financials

SSA ERP Quality management

Document Management integrations to external applications

Uploading the files from a specific directory in the client system to another directory of the same client system, or onto a directory of a different client system, or on to a directory of the ERP server and link the uploaded files to the ERP entities through document revision and the respective document.

Eg : Mobile Service (ESR)


Architecture of Document Management in SSA ERP ODM

Worktop scenario

Baan serverBW Client

File Server

Vault client

VaultVault server

Work Area

Vault Server

Vault Area

Work Area

BaanERP

Baan Windows

JVM

Integration

Java Code (jar file)

placed in ERP Server

Vault AreaA java function, which invokesODMC’s Vault Client on ERPServer. This Java function isinvoked by Baan4GL using JVM.

WebTop scenario

Work Area

Vault Area

Baan ServerMS Client

File Server

Vault client

VaultVault server

Vault Server

Vault Area

Work Area

Webtop

Webserver

Webtop DS Connector

Webserver

Signed

Firewall

JVM integration Java Code (jar file)

placed in ERP Server

Baan ERPA java function, which invokesODMC’s Vault Client on ERP Server. This Java function is invoked by Baan4GL using JVM

DS

HTTP/XML


Change Management

Introduction

The Change Management module provides tools for registering and controlling changes. Change control is a complex yet vital procedure in many industries, and is a very important feature of ERP applications. The Change Management module includes a number of predefined steps, such as Change Request (CR), Change Proposal (CP), Change Approval (CA), and Change Order Execution (COE), and also provides users a great deal of flexibility in defining the change procedure with reviewers to review change. Because of this flexibility, the Change Control module can be leveraged for use with a variety of entities in SSA ERP.

The Change Management module interfaces to other modules (in the SSA ERP ODM package and elsewhere) using a sophisticated interface mechanism. This mechanism also enables links of objects from other packages and modules to the Change Management module.

BOM

PUR

Change

Management

EDM

ROU

UNIT

IPD

Others


Change Management relationships with other packages of SSA ERP

A change proposal is linked to affected ERP objects that must be changed or created because of the change. The link is created using the object linking mechanism. This mechanism allows linking to a specific object and interfacing to the object’s application.

Defect in a product, improvements to a product, and customer requirements, in which all these lead to a revision, enhancement, or alteration. Changes are part of the day-to-day work of many departments and roles in a manufacturing organization. The process of Change Management is an organization’s most critical and complex process. ODM’ s Change Management module provides the flexibility of creating and maintaining a change process to optimize an organization’s Enterprise Resource Planning (ERP) system.

The following figure illustrates the component functions of the Change Management module.

Change Management Components Functions

The Change Management (CHM) module tracks, manages, and implements a change by applying four principle components of the change process.

Registration: The authorizations and rules for changing an object (items, operations, effectivity, and so on).

Identification: An identifier assigned for every managed object.

Configuration: The method of defining the product’s configuration, and maintaining the configuration throughout the product’s life.


Implementation: The method of implementing the change and completing the change process.

Requesting a change The Change Request allows an authorized user to register an object for a change. The change is accepted, rejected, or reassigned by a reviewer. If it is accepted it is linked to a Change.

Registering a change The Change is a permanent identifier, which will group all the similar CR ’s together and allows the user to track the managed object through the Change Management life cycle.

Configuring a change The Change Proposal allows the user to link affected ERP objects, set effectivity dates, attach task groups with tasks, and connect to reference items.

Review by Change Committee

The Change Proposal can be submitted for review, which will be reviewed by reviewers of a Change Committee. The reviewers will give their recommendations and the final decision lies upon the Chairperson of the Committee.

Accepting a change The Chairperson after studying all the recommendations can approve or reject the proposal of a Change.

Implementing a change

The Change Order execution function allows the user to update the task status and revise the task execution dates and finally the change is completed.

Change Management Objectives

Business objectives

Maximum options: The Change-Management module contains all the tools needed to manage Changes, the information related to Changes, approving or rejecting of the Changes by a responsible person, and the actual execution of the Change.

Business Setup: The structure of the module contains multiple options, and every enterprise will be able to adapt the module to its own practices through the Business Setup process.


Quality standards compatible: The module is consistent with accepted industry quality standards (for example ISO 9000, MIL-SPEC, and so on).

Speed: Speed up time to implement the changes.

Functional objectives

Full Change Management: Both the data (for example: Items) and the tasks are managed within the module.

Closed loop change system: Changes will be defined as completed when all work is done and the whole change has been implemented. This ensures better managerial and quality controls (ISO).

Traceability: The ability to control many Changes in the product in parallel, and the ability to insert Changes from different sources to affected objects. Similarly, the ability to maintain track on all Changes, from the original Change Request to the final Change Order (ISO) is possible.

Subcontracting: Control on changes can be sent to subcontractors.

Design: The ability to design and estimate changes and to use the design for the execution phase after the change approval.

Change Management Life-cycle diagram

The following business objects in Change management are described below.

Change Request

Changes

Change Proposal

Change Order

Task Group

Task


Change Request

The Change Request is the first part of the preliminary step that allows for the collection and examination of requests for changes from various sources, and the reduction of the number of changes being processed by eliminating trivial requests, or by combining similar requests.

The following steps are carried out using the Change Requests:

1 Registration Change Requests.

2 Check existing requests for similar Changes, and combining them if any exist.

3 Attach relevant objects.

4 Assign responsibility for the Change.

Changes

The Changes is the second stage in the life cycle of Change Management. This is a database entity that represents the Change. It provides status information of the life cycle for all Changes. The following is a list of Change Management statuses that can be assigned to a Change:

Created: The initial status for a new Change.

Freeze: The implementation of the Change Proposal has been delayed.

Unfreeze: Undoes the Freeze status.

Canceled: The Change Proposal has been canceled.

Completed: The Change is completed.

Reviewers for change

In the industry, it is regular practice to have a list of reviewers to approve or reject a change proposal related to Product or Process or documentation or work instructions, and so on. In some situations there will be a fixed group of reviewers where in they can adopt fixed reviewer mechanism or normal reviewer mechanism. For fixed reviewer mechanism every member of the group will give his/her decision in a decided fixed sequence.


The member cannot give his recommendation until the member prior to him gives his recommendation in the reviewer sequence. There is also a situation where in a member approves or rejects the change proposal with some conditions. This is called a conditional reviewer. Based on the recommendations given by the members of the reviewer group, the chairperson of the group can take a final decision to approve or reject the change proposal. The decision of the chairperson is final to approve or reject the proposal irrespective of the recommendations provided by the members.

In the fixed reviewer procedure, the reviewers are entitled to give their recommendations compulsorily and sequentially. For example, when the user opts for Fixed Reviewers option, the reviewers must provide recommendations, which means they either approve- or reject a proposal. In the list of reviewers, the first reviewer has to provide his recommendation and only after this operation the second reviewer can exercise his recommendation. In this way all the reviewers must give their recommendations one after the other. The final authority lies with the Chairman of CCB, who can exercise his recommendation without depending on the recommendations of reviewers.

The reviewers can play an indirect role in approving/rejecting any change. Whenever the reviewer gives the recommendation, all the reviewers and the chairperson existing for the change are notified by e-mail. While the suggestions are being mailed, the user is also allowed to include the comments in the mail.

Change proposal

The change proposal also comes under the second stage of the change life cycle since creating a new Change automatically establishes the default Proposal of the Change. The Change Proposal is a version-controlled entity. The Change Proposal is used to track the progress of the Change and Proposal.

The operations involved at this stage include the following:

Check the impact of the Change on affected objects (such as products, items, operations, and folders).

Attach relevant affected objects.

Link objects with quantities where needed.

Link the Task Groups and Tasks for a Change.


Estimate the cost of a Change for a specific Proposal.

Reviewers can give recommendations for a Proposal.

Change proposal status

These statuses are specific to the Proposal and are as follows:

Created: The initial status for a new proposal.

Under Review: The Proposal is ready to be submitted for review.

Approved or Rejected: The Proposal has been approved/ rejected.

Tasks are Done: All the tasks, which are attached to a Proposal, are Done.

Change approval

When the Change Proposal is submitted for review (Approved in Direct Approval mechanism), the Change Control Board convenes to make a decision. The Change Control Board decision would then be entered as the next status change for the Change Proposal. The following actions of the Change Control Board can be decided for the Change Proposal:

Approve

Reject

Revise

Linking an SSA ERP object to the change proposal

The Change Management module can control any ERP object that can be assigned an effectivity date or expiry date. Expiry date is used for old objects. For a new object, effective dates will be stamped.

Some of the SSA ERP objects that may be linked to a Change Proposal are:

Products or Assemblies.

E-Item Revisions.

Bill of Material lines.

Production Item.

Routing Operation.


Labor Types – Surcharges.

Task Groups.

Tasks.

Any object that is used to link to Change Management should be registered with the ODM package.

Change orders

Change Order provides a generic mechanism for changing any change-controlled ERP-linked entity. A Change Order date is specified in the Change Order to make the linked entity effective or expire.

Each Change Proposal has a list of proposed effectivity or expiry dates. These dates are recorded as Change Order Dates (CODs). The user can update a Change Order’s effective date or expiry date from the Change Order. A Change Order can exist independently from a Change Proposal.

Change Order can be linked to any Change, which is in Created status. The user can control the effectivity dates or expiry dates of more than one Change Order by defining a parent/child dependency with another CO. Hierarchical dependencies between COs creates a Bill of Change Orders (BOCO).

The final stage of the Change Proposal life cycle is the execution of the change order or change orders associated with it.

This step includes the following operations:

Carry out the Tasks associated with the change.

Complete Tasks.

Relative Change Orders (RCO)

RCO is based on the base Change Order date. The RCO date is determined by the “base change order date plus the duration,” defined by the user. RCO dates are used in making linked ERP entities effective or expired. The ERP entity that is linked to the proposal having relative change order is logically dependent on the ERP entity that is linked to the base change order.


Task group

The Task Group business object maintains the task group and its tasks. The Task Groups linked to the Change Proposal will describe the operation tasks for performing the change that have cost and schedule impact and can include other reminder tasks.

The tasks will store information such as the task description, the task’s role, the task’s estimated time (from date/ to date), cost and working hours, actual time, preceding task, and status (Created/In Work/Skipped/Done).

Task groups are optional. But for an organization that has hundreds of tasks, task groups are essential in the successful implementation of a group of related tasks.

Tasks

A task is the actual change that will be implemented at a prescribed date. Tasks can be linked directly to a Change Proposal.

Statuses for Tasks are as follows:

Created

In Work

Done

Folder Management

Introduction

Within any information system and particularly Product Management Systems, there are many relationships, links, and dependencies between different aspects of product data. Some of those relationships are strong or mandatory; others are weak or optional. Not all those links can be hard-coded at design phase, as these are rarely used. Moreover, not all the links and relevant data can be anticipated at the beginning.

The Folder concept addresses this problem by providing a generic flexible solution. Linking a SSA ERP object into a folder is a simple and efficient method to extend the object data domain.


A Folder is a data item that can contain a group of related objects. Folders can also link to non-contained objects. For example, a folder with pension information can be linked to a document that describes employee benefits.

Folder Management offers the following business advantages:

Providing the fast retrieval of any kind of related information.

Folders can be freely created for various subjects, and can than be divided to subfolders (as folders can contain other folders). By using this mechanism, you can create a multilevel knowledge base for different purposes of the organization.

Creating a multilevel knowledge base.

Freezing a group of related objects to be used as a baseline for further development.

Folders

The Folder Management module provides the process of creating, maintaining, and using folders in the SSA ERP system.

Folders are of two types: Shared or Personal.

Any SSA ERP object, which is defined in ODM, can be placed inside a Folder. A Personal folder can be created which is visible across the system. The authorization to amend it is determined according to its status and the rights assigned by the user that created it. The owner or the creator of the Personal Folder can mail the contents of the Folder and the mail contains the shortcut to this folder.

Folder statuses

The following statuses are defined during the life cycle of a Folder:

Created/In Design: Folder is only just created or is still under initial design process and therefore can be freely changed.

Locked: No attaching objects or removing links is allowed.

Revise: Folder can be revised with the links as per the requirements.


Linking SSA ERP entities to a folder

A list of the type of objects that can be linked to the folder will be displayed, together with the number of each type that is currently contained. The user can choose to add an object link or delete an object link from the folder. You can use the paperclip button to attach to folders the documents and document revisions to SSA ERP objects.

Queries and Reports

Introduction

Generating timely and essential information is a strategic advantage to the success of any organization. Reports are the most fundamental way of presenting information in a structured format.

Queries and reports include the following features:

Define Queries for all SSA ERP objects.

Access Reports from any native object of ODM.

Create Reports based on object definition and displaying query results in a Report.

The queries and reports feature includes the following functionality:

Define, implement, tracking, store and display the query conditions for an SSA ERP object.

Store the Query Result sets and rerunning the Queries on the stored data.

Run reports as grouped by object.

View or print reports from the Change Management, Document Management, and Folder Management modules.

Establish predefined reports for Object Data Management.


Business Objectives

Maximum options The queries and reports contain all the tools that are needed to create query conditions and complex query conditions, define reports, display and print reports from the Document Management, Change Management, and Folder Management module.

Business setup The structure of queries and reports allow for the implementation of a variety of queries and the development of reports based by object type, all of which must be adapted to the business requirements of an organization.

Quality standards compatible

The queries and reports feature is consistent with accepted industry quality standards (for example, ISO 9000, MIL-SPEC, and so on)

Functional Objectives

Query management

Create complex Query Conditions, track of Queries, and storing Query runs.

Report repository Implement reports that are grouped by object.

Print functionality Provide a standard interface for printing reports from the Document Management, Change Management, and Folder Management modules of the SSA ERP ODM package.

Standard reports Establish a set of predefined reports for Object Data Management.

Query/Report Integration

Facilitate options to execute reports on query results.

The following business objects in Queries and Reports are described below.

Query

Query Conditions

Reports


Query

Introduction

There are three different types of Queries in the query subsystem.

Queries can be defined based on a single object type or set up of combined queries. The combined query is specified in the complex conditions of the Query.

Base Query Conditions are based on attribute values from the object definition table.

Previous Run Allows the user to use the results of a previous run of a different Query but of same object type as the input for the current execution.

Linked query Allows the user to link N levels of queries on the same or different object types that can be linked together. The link types are as follows:

Link member to owner. The base query object is a member of a family owned by the linked query object.

Link owner to member. The base query object is the owner of a family and the linked query object is a member.

Combined queries. Queries based on the same object are linked.

Query Conditions

A query can be based on one or more conditions. The conditions are based on the attribute values. A single query condition can be defined for a query, or define multiple query conditions joined with connectors to build a query. Each condition consists of the following elements:

Condition Connector + Attribute + Logical Operator + System Parameter + Value


The available connectors are:

AND - to connect conditions which must both be true (by default).

OR - to connect conditions of which at least one must be true. The available range of operators are “ =, <, >, <=, >=, <>, IN, BETWEEN, LIKE, NOT IN, NOT BETWEEN, NOT LIKE.

System Parameters are a set of predefined SSA ERP Variables such as login$, Date$, and so on, which can be used in the Query condition to be more generic.

Complex query conditions

A Query can be linked to one or many Queries. This type of linkage results in Complex Conditions. Complex Conditions gives a wide option to Query the data encompassing different Object Types.

The field data is as follows.

Link member to owner - Specify the linked object family and linked object type, and then select the query to be linked.

Link owner to member - Specify the linked object family and then select the query to be linked

Combined queries - Specify the Query to be linked.

Previous query runs

The Results obtained from a Query Run can be stored for later use and such data can be available from the Previous Query Runs. The User can rerun the Query on one of the Previous Runs, the result set thus obtained will be the data filtered from the already stored data for the chosen Query Run.

Reports

The user can generate a report from the Report repository and attach the generated reports to the entities in the Document Management, Change Management, and Folder Management modules.


Configuration

Introduction

SSA ERP Object Data Management provides a number of common infrastructure services that are available to all the modules in the package.

The following business objects in Configuration are described below.

Masks

Authorizations

Secondary Status

Objects and Related Objects

Common ODM Parameters

Business Rules

Export and Import System Data

Masks

A mask is a mechanism used to generate a unique identification number for an object. The number is generated depending upon the mask defined by the user. A unique identifier represents almost all entities in SSA ERP ODM.

Mask codes

Each object parameter for which masks can be defined has one or more mask codes defined for it. The mask code is system data that identifies the masking mechanism to be used for the parameter. In general, if more than one mask code is defined for an object parameter, only one can be active.

Mask configurations

For each object parameter that supports masks, a format is used to generate parameter values, by defining a mask configuration for the mask code or codes associated with the parameter.

The mask configuration includes a mask that is composed of one or more mask template segments.


Each segment is either defined as Fixed Format, Generated Format, System Variable, or Reference Variable

Authorizations

The SSA ERP ODM authorization mechanism is a generic subsystem that provides user-defined authorizations. The authorization mechanism makes use of the SSA ERP People tables for Employees and Roles. The current scope of user authorizations is to enforce the authorization checks within the Data Management Package with respect to Change Management (CHM), Document Management (DOC), Folder Management (FMG) and Queries.

The authorizations facilitate the following actions:

Defining Object Specific Actions.

Defining Action Groups.

Linking Role(s) to an employee.

Assigning Actions to SSA ERP Roles.

Employees and roles by employees

In the authorizations, permissions to perform certain actions are associated with roles, rather than with individual users. An individual user who is assigned a role may perform all the actions that are permitted for that role.

Actions

The Authorizations enables to define actions for each object. Every object may have many actions associated with it. Similarly, actions can be common to several objects. Some actions are defined as system actions. These actions are fundamental to the operation of the ODM package and by default and all ODM actions are systems actions.

Action groups

An action group is a collection of one or more actions. An action group can contain many actions, and an action may be included in more than one action group. One action group may contain actions on more than one object.


Role assignments

User roles are assigned to actions using the Role Assignments. For each role, the actions or action groups are specified and then the role is authorized to perform on which objects.

Secondary status

Secondary status in the Data Management module is an additional property of an object. It is optional and depends on a basic status. Secondary statuses are part of the module system data and can be defined by a user.

Objects and related objects

Any ERP entity, which is defined in ODM with all its details, is an Object where in the documents can be linked to it directly. The related Object is the object, which is related to main object in a business flow. The documents linked to the related object can be referred from the main object if they are defined in related objects and set in Common ODM Parameters.

Common ODM parameters

Common ODM Parameters are available for some attributes, which are used in document management and change management modules. An authorized user according to the requirements and specifications can set these as defaults.

Business rules

A business rule can be defined for every action on source Object, which allows specifying the target Objects to perform the action.

Usually the event that takes place on the Object can trigger some events on the other linked Objects.

The Rules mechanism makes this process as automatic. The advantages of this approach are:

Simple maintenance

Time-saving mechanism in comparison with the manual approach

Code-saving mechanism


Flexibility in performing set of actions

Possibility of including query condition

Export and import of system data

The Data Management module includes an export and import feature, which can be used to transfer the ODM system data, selected from the System Table list, to and from a defined storage directory for further use.

Import Files

‘Import Files’ enables to import the files from any specified folder to SSA ERP ODM.

There are many cases where in user may import the files to ODM. Some of the cases are mentioned below.

Case 1:

If all the files are to be imported to ODM Work Area or Vault Area from legacy system and individual documents and files are to be created in ODM for every imported file.

Case 2:

If only some selected files are to be imported to ODM Vault Area and individual documents and files are to be created in ODM for every imported file.

Case 3:

If only some selected files are to be imported to ODM Work Area and individual documents and files are to be created in ODM for every imported file.

Case 4:

If only some selected files are to be imported to ODM Work Area or Vault Area and all these files are to be linked to the same document in ODM.


Case 5:

If all the files are to be imported to ODM Work Area or Vault Area and all these files are to be linked to the same document in ODM.

In all the above cases it is possible to import the files from a local host. If it is remote host then all the files in the specified folder of the remote host can be imported to ODM. The source and target location of files are to be specified in ODM.

New documents may be created for the imported files respectively in ODM. It is also possible to select the existing document in ODM in order to get linked to the imported files. ERP object (instance) that is defined in ODM can be linked to the document while importing the files.

Integration of SSA ERP ODM with Microsoft Office applications

Microsoft Office applications and SSA ERP ODM exchange the information in real time, and updates files attached to the document (via document revision) in ODM from the office applications. To make the access very simple to SSA ERP ODM from the MSO applications, the Office Integration will be of significant use. This integration constitutes Word files, Excel Files and PowerPoint files.

The SSA ERP ODM - Microsoft Office Integration menu is embedded in the native Microsoft application menus, from which you can directly access the essential features of ODM. SSA ERP ODM has functions such as Edit, View, Print, E Mail, Copy, and Move, and so on. The functions, such as Register in ODM, Update File, and Check in options can be performed from within Word, Excel, and PowerPoint. The integration enables an effective exchange of product information between the two systems.

Introduction

This chapter briefly describes the following main aspects of multi-company processing:

Multicompany structures.

Multicompany terms.

Enterprise structure modeling.

Enterprise units.

Multicurrency.

Intra-logistic company functions.

Data sharing

The term “multi-company” can be used to describe processes in more than one business unit within an organizational structure.

Processes

Actual business events, such as material handling, manufacturing, and administration, or the recording of these business events.

18Chapter 18 Multisite

18-2 | Multisite

Business Unit

Any entity in an organization that has some degree of independence, for example, a warehouse, a distribution center, a manufacturing plant, a sales office, and an administrative group. Independence implies that some degree of management is unique to the entity.

Multicompany in SSA ERP includes both functional and technical concepts. Examples of SSA ERP multi-company concepts include: group company structure, company types (financial, logistic, and both), data sharing, and internal Electronic Data interchange (EDI). For best results, you must have a clear understanding of both the organization’s structure and the SSA ERP multi-company functionality before you can start to develop a multi-company implementation plan.

Defining a company structure includes identifying physical locations, technical architecture, data management requirements, management structure, reporting requirements, centralized/decentralized planning, procurement, manufacturing and financial administration. Analyzing the organizational structure and processing requirements in conjunction with SSA ERP multi-company functional and technical capabilities provides a foundation for an implementation plan.

Multisite environments

A site is a set of company processes that is independent, to a certain degree, of the other company processes. For example, the production plants, an assembly plant, a distribution center, and the sales offices of an organization can form separate sites. A multisite environment is the integration of a number of sites in one organization structure.

A multisite environment consists of application logic and technology that refers to more than one enterprise unit, company, organization, or SSA ERP server. A multisite environment can provide optimization at enterprise level, with planning and control that encompass the entire enterprise, such as central inventory control, central purchasing, and central sales.

The same master data can be used enterprise-wide. The actual operations can be decentralized and carried out anywhere in the world.

Multisite | 18-3

An SSA ERP multisite environment usually consists of a structure of multiple logistic and financial companies. Therefore, multi-site is often synonymous with multi-company. If the various sites are located in different countries, you must set up a multicurrency system for the companies of the multi-company structure.

Some multi-company terms

This section introduces some of the terms that are used.

Multicompany (multisite)

An organization in which the SSA ERP configuration consists of more than one SSA ERP company, of the type Logistic, Financial, or Both. This implies the integration of a group of company processes into a structure, which is referred to as ‘multi-company’ in this manual.

Company

An SSA ERP company is a set of tables where logistic and/or financial master data and dynamic data is stored.

Table

A table definition is the grouping of various components including table fields, indices, and relations.

Table Linking

Two or more companies use the same data by accessing the same table in real time processing. All companies own the linked data; the linked table is physically located in one company.

Data Replication

Data is copied from one company into another company.

18-4 | Multisite

Logistic company

An SSA ERP company used for logistic transactions, such as the production and transportation of goods. All the logistic data concerning the transactions is stored in the company’s database.

A logistic company can consist of enterprise units that are linked to different financial companies.

Financial Company

A financial company is a company with at least one financial table. The main function of a financial company is to register all accounting transactions that result from the activities carried out in the enterprise units that are linked to the financial company (see the following figure). These activities consist of the operational and logistic transactions that result from a logistic goods flow and from production, service, warehousing, and support activities.

Enterprise Unit

An enterprise unit consists of logically grouped entities linked to the same financial company and to the same logistic company. Enterprise Units are considered independent financial units within a logistic context.

Multisite | 18-5

Entity

An entity is a separate and independent business unit. Examples include: assembly plants, manufacturing plants, distribution centers, sales offices, and purchase offices. Entities are linked to the appropriate financial company by using Enterprise Units.

Dynamic Enterprise Modeler

Dynamic Enterprise Modeling is the process of creating a template or framework to adapt an organization's software in real time, across changing organizational structures, business practices, and operational procedures, and thereby support implementation and continuous business process re-engineering.

Enterprise Structure Diagram

An Enterprise Structure diagram (model) graphically represents the structure of a company, which assists in the determination of the overall SSA ERP Company structures. For example, production sites in Canada and the U.S. and sales offices in both countries, as well as European countries, can be depicted (see the following figure).

18-6 | Multisite

Enterprise Modeling Management (EMM)

EMM contains all enterprise modeling related data for companies, enterprise units, clusters, key entities, and relationships between entities and enterprise units (see the following figure). Currency information is also an important element of EMM.

Enterprise structure modeling

The SSA ERP software is now used in more complex company structures than in the past. For example, the possibility to do enterprise planning across different sites enables you to use SSA ERP software for the production planning in large companies. Another example is the possibility to do the financial accounting of separate parts (sites) of one logistic company in separate financial companies.

The Dynamic Enterprise Modeler (DEM) is a tool that you can use to model the structure of your enterprise. For example, the production sites can be in Asia and America, and the sales offices in various European countries. The various sites of your enterprise are represented by enterprise units in the enterprise structure diagram. You also indicate the relationships between the enterprise units in the enterprise structure diagram (see the following figure).

Multisite | 18-7

In this way, you can model your enterprise independent of the organization of the SSA ERP databases.

You use enterprise units to model the multi-company structure.

You use logistic and financial companies to organize the database and the users’ authorizations to work with parts of the database.

Note: Obviously, you cannot completely ignore the organization of the databases and their distribution over the various servers when you design a multi-company structure.

Enterprise units

An enterprise unit is a financially independent part of the organization. An enterprise unit consists of entities such as departments, work centers, warehouses and projects, within one logistic company. An enterprise unit can represent a manufacturing plant, an assembly plant, a sales organization, and so on.

18-8 | Multisite

In the multi-company structure, an enterprise unit identifies a financial unit or a fiscal unit. All the transactions related to an enterprise unit are posted to one financial company. You can link the enterprise units of one logistic company to different financial companies for separate financial accounting, and perform the corporate accounting in the financial company that acts as the group company (see the following figure).

Group company

L1

FB

EU A

Warehouse A

Salesoffice A

FA

EU B

Workcenter B

Warehouse B

EU C

Service center C

Warehouse C

FC

Corporate accounting

If separate sites of your organization together form one legal and fiscal unit, you can link the enterprise units of one or more logistic companies to one financial company.

You can use the enterprise units for the modeling and configuration of a multi-company structure. Therefore, you do not need to create separate companies for the various business units and various locations of your enterprise.

Multisite | 18-9

Multicurrency

In SSA ERP, a logistic company can operate in multiple countries and, in this way, in multiple currency areas. The SSA ERP multicurrency systems enable a company to carry out accounting in more than one currency. Amounts can be computed and registered in up to three currencies.

Multicurrency enables organizations with operations in high inflation countries to report both in the local currency and in a stable currency.

Multicurrency also provided a solution to the European monetary integration period after 1999. During this period the participating countries could report to governments in both their local currency and in the currency of the EMU, the euro.

Intra-logistic-company transactions

Sales offices, purchase offices, work centers, service centers, and warehouses are entities of logistic companies. The entities are grouped into enterprise units. You can define the enterprise units in one logistic company as each other’s customers and suppliers, and model the goods flow and the corresponding financial relations, such as invoicing and pricing agreements between the enterprise units. To do this, you must define internal business partners and link these business partners to the enterprise units. A one-to-one relationship must exist between internal business partners and enterprise units.

Data sharing

The companies of a multi-company structure must use consistent data. For example, you can use the same calendars, item codes, business partners, and pricing information in the various sites.

Some data must be shared (and some data can be shared if this is required), and other data must not be shared. You can use several data sharing- and replication techniques to make the same data available to the different companies.

18-10 | Multisite

Multicompany processing

The multi-company structure enables enterprise-wide production planning and operations management. The following sections briefly describe the multi-company functions that the various SSA ERP packages support.

Multicompany Financials

In one logistic company, you can carry out logistic transactions between departments, work centers and warehouses of enterprise units that are linked to various financial companies. If the debit- and the credit sides of a logistic transaction are posted to different financial companies, SSA ERP can automatically generate inter-company transactions between the companies.

You can aggregate the data of a group of financial companies to the financial group company for corporate accounting.

Multicompany Enterprise Planning

You can use central multi-company planning to define a central plan that coordinates and triggers the local plans in the production companies. You can also aggregate and disaggregate the plans to different levels.

Multicompany Manufacturing

Product definition, engineering data management, and production scheduling and execution are controlled within each logistic company. Enterprise units do not have an effect on the activities that do not have financial consequences.

In a logistic company, routings can include work centers in different countries that belong to different enterprise units. SSA ERP posts the WIP transfers to the financial companies of the enterprise units.

Multisite | 18-11

Multicompany Order Management

During sales order entry, you can see the available inventory in warehouses of your own and other logistic companies using the bill of enterprise, or by using SSA ERP Enterprise Planning and SSA SCS Order Promising.

Via triangular invoicing, the sales office and the warehouse on the sales order or the purchase office in case of direct delivery, can be located in different countries and therefore also belong to different financial companies. The financial transactions will take place via internal invoices against commercial price or valuation price.

SSA ERP registers some financial business partner data separately for each sales office and for each purchase office. In this way, the various enterprise units can do business with the same customers and suppliers.

In a multi-company structure, you can centrally manage all or part of the purchase orders. For example, you can create a central purchase contract with your suppliers, including price- and discount agreements that apply to all the sites of your organization.

Multicompany Project

You must link a project to an enterprise unit and, in this way, to a financial company. If you use multiple financial companies, you can perform separate financial accounting for the projects of one logistic company.

You can aggregate the data of several subprojects to a main project for integrated project monitoring.

You can specify a project currency for each project and subproject. In this way, you can manage a project in any currency that is convenient; for example, the local currency of the country where you carry out the work.

18-12 | Multisite

Multicompany Service

Service centers and warehouses that contain spare parts are all parts of enterprise units. To perform separate financial accounting for the service centers and their warehouses, you can assign the services centers and warehouses to enterprise units that are linked to different financial companies.

You can only handle service contracts and service calls and perform tracking in one logistic company.

Multicompany Warehousing

You can define goods transfer relationships between warehouses of different enterprise units (linked to separate financial companies), but also between warehouses of various logistic companies, to transfer goods between warehouses and to generate invoices for the goods without using sales orders and purchase orders. For example, you can use multi-company warehousing to transfer standard goods between warehouses in different countries and implemented in different logistical companies.

You can define warehouse surcharges that are added to the valuation price of the goods, either when the goods are issued from a warehouse or when they are received.

Introduction

This chapter describes the main functions and features of the technology on which SSA ERP LN is based.

First, this chapter briefly describes the main components of this technology architecture. The subsequent sections further describe the functions and features of the various components. In addition, some other topics are described in separate chapters.

19Chapter 19 SSA ERP LN: The technology

19-2 | SSA ERP LN: The technology

Architecture

The following figure illustrates the SSA ERP LN Technology architecture:

Server

Platform

Dependent

Dependent

Server

Platform

Independent

Server

Platform Operating System

iBaan Virtual Machine (BSHELL) Database Drivers

DBMS (Database)

iBaan ERP Applications

4GL-Engine

Java Virtual Machine

External Application

Application Management

Tools Development

Tools

Web Server

XML/HTTP

XML/DS DS

Webtop

iBaan OpenWorldX

iBaan OpenWorldX

Adapter

Worktop

ConnectivityTools

Server

Platform

Dependent

Server

Platform

Independent

Server

Platform Operating System

Virtual Machine (BSHELL) Database Drivers

DBMS (Database)

SSA ERP Applications

4GL-Engine

Java Virtual Machine

External Application

Application Management

Tools Development

Tools

Web Server

XML/HTTP

XML/DS DS

Webtop

SSA Open

Architecure

SSA Open Architecture

Adapter

Worktop

ConnectivityTools

C l i e n t

P l a t f o r m

This architecture includes several layers. The following sections describe the contents of these layers in detail.

Server platform layer

This layer represents the operating system of the computer and the installed relational database (RDBMS). These items are prerequisites for an SSA ERP Server installation.

Server platform-dependent layer

This layer provides the runtime environment for platform-independent SSA applications. As such, these components are ported to and delivered for each specific operating system and database. For this reason, this layer is also known as the porting set.

The core of this runtime environment is the Virtual Machine, also known as the bshell.

SSA ERP LN: The technology | 19-3

This component implements the following main parts:

The execution environment for the application software

The interface with the user interfaces (Webtop and Worktop)

The interface with the databases

The database drivers provide database access to the relational databases, to enable all Baan database requests to be executed on the underlying relational database. For each relational database, a separate database driver is created.

To provide connectivity through SSA Open Architecture, a Java integration is created, which integrates the Java Virtual Machine with the Virtual Machine.

For more information on the Virtual Machine and the database drivers, refer to “ERP LN runtime environment,” in this section.

Server platform-independent layer

The SSA ERP LN applications in this layer are completely platform-independent.

The core of the SSA ERP LN applications is the 4GL engine, which handles all of the standard user interface and database behavior. The SSA ERP LN applications all make use of this standard behavior.

Using the development tools, developers can create new functionality or customize current functionality. For more information, refer to “SSA ERP LN development environment,” in this section.

To use the connectivity tools to create integrations with other applications and for data exchange, you can define and expose business objects. These Business Objects are exposed by means of SSA Open Architecture. For more information, refer to “Connectivity,” in this chapter.

The application administration tools enable you to configure and maintain the SSA ERP system. For more information on application administration, refer to “SSA ERP application management,” in this chapter.


Client platform-dependent layer

The user interface at the client side is implemented in the platform-dependent layer.

The primary interface for SSA ERP LN is SSA Webtop, which is a Web client. Webtop is installed on a Web server and enables users to start and run the SSA user interface in their Internet browser. Webtop itself interacts heavily with the 4GL Engine by means of the Virtual Machine.

As a secondary interface, Worktop is available, which is a user interface for the Windows platform only. For more information on Webtop and user interface concepts, refer to “User interface” in this chapter.

ERP LN runtime environment

This section describes the runtime environment, in particular the virtual machine, also known as bshell, as well as the database drivers.

Virtual Machine (bshell)

The bshell is a single-threaded process that is scheduled and executed by the native host platform. The bshell, also called the Virtual Machine, is the operating system abstraction layer for the ERP LN application code. The main task of the bshell is to run the application code. The application code is written in 4GL, which is the SSA ERP LN programming language.

The bshell is activated by an external request. Most often, this external request originates from the user interface driver when a user logs on to SSA ERP. For integration with third-party components, the bshell is activated by an intermediate launching component. For more information on how bshells are started in these cases, refer to “Application Services Manager (ASM),” in this chapter.

Each time a user logs on to the SSA ERP LN system, a separate bshell process is designated to the user. As a result, if multiple users log on to a particular platform, or if a user logs in multiple times, multiple bshell processes become active on the host platform.


The most important functions of the Bshell are:

Offer an execution environment to SSA ERP LN applications In this execution environment, SSA ERP LN applications are scheduled and executed as separate processes. This type of application is either a 3GL or 4GL program. The execution of the application programs by the bshell is carried out in close corporation with the 4GL Engine.

Implementation of a large number of standard functions that the SSA ERP application software uses. Among others, these functions are typical functions that require services from the underlying operating system, for example, stream file I/O and communication services.

Pass information from/to SSA ERP LN applications to and from the user interface and database driver Neither the SSA ERP LN applications nor the bshell contain user interface or database management system-specific functionality. This characteristic enables developers to write one set of code, which suites any customer situation with respect to user interface, operating system and database management systems.

Database driver

The database driver is the gateway for SSA ERP LN applications to the RDBMS of choice.

The database driver provides a logical model of one single database to the applications. The database type is abstracted, easily enabling support for various RDBMS versions. The number of databases present on the physical level, the types of databases, and where these databases reside is fully transparent to the client of the database driver. This characteristic of the database driver enables you to change the physical structure of the data management layer, without any application change.

The main functions of the database driver are the following:

Shield all database specific issues from the application software by providing a uniform and generic interface called BaanSQL. The BaanSQL syntax resembles the ANSI-92 SQL syntax.

Offer functionality to maintain (create/remove) tables in a (possibly distributed) database system.

Offer functionality to store and retrieve information in a (possibly distributed) database system.


Maintain the referential integrity between the data manipulated by means of the database driver.

Enforce domain constraints The domain describes the valid values that a table field can have. The database driver is responsible for protecting against invalid table field assignments.

Application Services Manager (ASM)

In SSA ERP, you sometimes need a 3GL or 4GL session that always runs on the system. An example is the job daemon, which is a 4GL application service that must always run on the system, independent of any user. In addition, other products, such as SSA Open Architecture, require functionality to start or stop a service on the ERP back-end system.

Application Services Manager (ASM) enables system administrators to define such application services, which are also called instances, in a generic framework. The ASM daemon can start and stop these instances.

ASM is a platform-dependent component. ASM builds are available for all actual hardware platforms of SSA ERP LN.

With an administrative tool, called ASM MMC snap-in, the system administrator can define, stop, and start instances. This tool is a snap-in for the Microsoft Management Console (MMC) and runs on Windows.

Platform and database support for SSA ERP LN 6.1

The platform and database combinations in the following table are currently available (as of December 2005).

Supported OS Oracle 9.2, 10

Informix 9.40, 10

DB2 8.1, 8.2

SQL Server 2000

HP PA_RISC HP-UX 11.00, 11.11 X X

HP IA64 HP-UX 11.23 X 10

IBM Power_PC AIX 5.1, 5.2, 5.3 X X X

SUN_SPARC\ SOLARIS 8, 9, 10 X X

Novell x86 Suse 8, 9 X X

Microsoft x86 Windows 2000, 2003 X X


Internationalization

Multibyte enabling

Introduction

An eight-bit-wide character space is not large enough to fit most Asian character sets. Asian countries, including Japan, China, and Korea, require at least 16 bits of character space to accommodate local characters. Therefore, a 32-bit wide character space is implemented in SSA Enterprise Server to support all possible character sets.

TSS

Multibyte enabling is implemented in SSA ERP by means of the TSS, which is a collection of character sets. TSS accommodates all multibyte character sets in a single package. TSS includes both ASCII character sets and multibyte character sets, such as Japanese, Chinese, and Hebrew. To distinguish between, for example, Japanese and Chinese, TSS consists of planes, each of which holds a 64 KB-size character set, or 256 pages of 256 characters.

Multi-language

Multiple languages within one ERP LN environment

Most ERP LN implementations use several languages simultaneously. ERP LN already provided limited support for combining multiple languages in a single environment.

With ERP LN FP2, this support is enhanced by enabling support for any combination of languages within one ERP LN environment, as long as the languages itself are supported with ERP LN.

This multi-language support is implemented by following the Unicode standards. For linguistic sorting, the International Components for Unicode (ICU) standards are followed as well.


Decoupled software and language packs

ERP LN uses LTS to both reduce the language-dependency of the SSA ERP applications and to lower the costs of media creation and distribution.

Basic concept

LTS provides a mechanism to really separate translatable software components, such as labels, questions, and messages from language-independent software components, such as form and report layouts. In LTS, the forms and report exist in the development language only. For example, a sales order entry form contains only an identifier to a referring label and is used by all system languages. The translated labels will be added only to display the form.

Storage of translatable software components

In ERP LN 6.1, labels are stored based on their context. This reduces redundancy and prevents labels from being changed while being used in another context.

Export/Import wizard

In ERP LN, you can export the labels, questions, and messages from a development or translation system and import them into other ERP LN environments. Export and import of labels is carried out by means of XML-formatted files. Every XML file contains a selection of translatable components based on the user’s settings.

The translated language files can be imported back into the SSA environment. The import process includes a conversion to runtime.

All descriptions are stored as labels that can be handled by the same import/export process.

English as fallback language

You can run the product under any language code. If a label does not exist in that language code, the English label appears.

Easy delivery

The translated XML language export files can be converted into a language packs, which in turn can be distributed and installed by the ERP installer.


Multicurrency

In SSA ERP LN 6.1, you can work with various currencies. For more information, refer to Chapter 6, “Financials.”

user interface

This section describes the function and features of the user interface of ERP LN and some other usability concepts.

ERP LN is delivered with two user interface products: SSA WebTop and SSA Worktop. SSA WebTop is the preferred user interface to use. Future investments will mainly be made in the SSA WebTop user interface.

SSA WebTop versus SSA Worktop

SSA WebTop is a Web-based, multiplatform user interface, whereas SSA Worktop is a Microsoft Windows based fat client.

Both user interfaces provide a navigation framework: Shortcut Bar and Navigation Tree, both Menu Browser and the DEM Process Browser.

The following figures provide an impression of both user interfaces.


SSA WebTop:

SSA Worktop:


Main differences between SSA WebTop and SSA Worktop

This section lists the main differences between SSA WebTop and SSA Worktop:

SSA WebTop is Web-based (no installation), and runs in a browser.

SSA WebTop supports multiple Operating Systems.

SSA WebTop requires less network bandwidth.

SSA WebTop integrates the ERP sessions in the work-area.

SSA Web Help is tightly integrated into SSA WebTop.

SSA WebTop is not suitable for developing DEM models.

SSA WebTop is not suitable for developing sessions with the Developers Kit.

For some features, for example, Charts, a different programming interface is used for SSA WebTop. The use of some “old” SSA Worktop-only programming interfaces has, therefore, been deprecated.

SSA WebTop-specific user interface features

Easy Filtering

To provide an easy way to perform filtering data in a grid, SSA WebTop has implemented the Easy Filter concept.

The grid header contains a filter row. To filter your data, you must enter your filter argument in a textbook, or you also use wildcards, and tab away from the field.

Click on the Filter icon in the grid header to save your filter easily for later use.

Smart Links

Using Smart Links, you can easily navigate to related information. Two types of Smart Links exist: Grid column Smart Links and Field level Smart Links. Grid column Smart Links are visualized in the header of the grid by underlining the column label. Field level Smart Links have the following indication: . Click this link to view detailed information.


Customize form

If the user has Customizable Fields authorizations, as described in “Customizable fields,” the user can click the Customize icon ( ) in an ERPLN session, or click Customize Form… on the View menu, to view the form in customize mode.

You can click the eye icon to hide fields, along with the corresponding label, or even hide complete groups. If you click the pencil icon, you can change the appearance of the label.

Customize toolbar

If the user has Customizable Fields authorizations, as described in “Customizable fields,” you can click Customize Toolbar... on the View menu to customize the secondary toolbar.

Customize menu

If the user has Customizable Fields authorizations, as described in “Customizable fields,” to customize the Specific, Print, and Text menus, click Customize Menu… on the View menu.

Auto-hide navigation areas

Optionally, you can hide the Shortcut and Tree Navigation areas in such a way that the areas become visible again if the user hovers the mouse over the left side of the screen.

Gantt charts support

Interactive Gantt charts are used for complex planning applications. Using the Gantt chart, the user views a clear visual overview of the planning. To change the planning, you use a simple drag-and-drop functionality. Navigation is also extremely user friendly. An example of a Gantt application can be found in SSA ERP Manufacturing: Shop Floor Control – Production Order Planning.


Company coloring

In the SSA WebTop Administration Console, the system administrator can enable Company Coloring. The administrator can give each different company a specific color to emphasize that the user works in various SSA companies. The company colors will be visualized in the task bar.

Customizable look-and-feel

The user can change the look and feel of the user interface. The default look and feel is the “SSA” look and feel. Other look and feels the user can switch to depend on the operating system. On Windows, the user can switch to the “Windows” look-and-feel.

System administration tools

SSA WebTop can be centrally managed. Users do not have to perform administration on their own. All settings are centrally stored. For example, the user does not have to know the Enterprise Server parameters. The administrator manages all Enterprise Server parameters.

For the system administrators to perform their tasks, a separate user interface has been developed, called the WebTop Administration Console. In this Administration Console, the system administrator can perform Webtop-specific administration tasks.

Generic user interface features

Navigation feature

Several methods are available to find the application sessions. The user can use one of the navigation trees: Menu Browser or Process Browser (DEM). The user can also drag and drop their favorite sessions to the Shortcut bar, and start these sessions from there.

You can also use the Run Program feature to start sessions by code. The most recently used session codes are remembered.


Multiple Window Interface

Each session has a unique window, which the user can resize or move around the screen. If you select the Remember the User’s Settings option in the user data, SSA ERP remembers the size and the position of the windows.

Grid customizations

You can customize the grid in the following ways:

Hide or add columns.

Change column widths.

Freeze columns.

Customizable Fields

Using the Customizable Fields feature, the user or administrator can make customizations to the forms without changing the form itself.

In the User Data template session, the user receives customizable fields authorization. Form customizations other than grid customizations can only be made through the SSA WebTop user interface.

In the Customization Maintenance (ttadv9100m000) session, an administrator can promote a user customization to apply to all users with a particular DEM role, or even all users who work in a particular company number.

Desktop integration

For Windows Operating Systems Desktop shortcuts can be made, which link to ERPLN sessions. You can also send shortcuts by e-mail.

Microsoft Office integration

For Windows Operating Systems with Microsoft Office installed, the user can easily use data from ERPLN, for example, Microsoft Word or Microsoft Excel.


Dashboards

SSA ERP LN 6.1 introduces the concept of dashboards. A dashboard is a session that fully supports a user who performs a particular role. A dashboard also gives the user an overview of relevant status information, and enables the user to access the session easily to perform tasks.

A dashboard typically contains a list of objects relevant for a particular role, for example, business partners or items. In this list, the user can select an object. The area above the list then shows relevant information about this object. Hyperlinks give the user easy access to other information and functionality of the selected object. A checkmark in front of the hyperlink shows whether the session the hyperlink jumps to contains relevant data.

SSA ERP LN 6.1 contains dashboards including the following:

Manufacturing:

Work Centers Dashboard

Items Dashboard

Order Management:

Buyer Dashboard

Account Manager Dashboard

Project:

Project Manager Dashboard

Service:

Customer Call Dashboard

People:

Employees Dashboard

Financials:

Accounts Receivable Dashboard

Accounts Payable Dashboard

Multi-main table sessions

SSA ERP LN introduces a new type of session: the multi-main table session. This session type enables you to combine various other sessions into a single session.


Multi-main table sessions are also specially designed to present data with a typical parent-child structure, for example, sales orders and related lines. Although this data is distributed among several main-tables in the system, the data can all be presented and edited from within a single parent-child session.

A typical parent-child session has two areas. The upper area contains information and functionality about the parent. The lower area contains one or more lists that show data about the various types of children. In this session, the user can edit both parent data and child data, which makes the sessions extremely powerful for data entry. In addition, a parent-child session also provides the user a complete overview of all important data related to the object.

The parent-child sessions available in ERP LN include:

Manufacturing:

Production Order

Generic Item – Structure

Order Management:

Sales Order – Lines

Sales Order Line – Deliveries

Service:

Service Order – Lines

Service Order Activity – Lines

Maintenance Sales Order

Work Order – Lines

Financials:

Mapping Scheme

Ledger Mapping

Dimension Mapping

Financial Business Partner Group (Accounts Receivable)

Financial Business Partner Group (Accounts Payable)

Invoice-Source Relation


Quality Management:

Inspection Orders – Easy Entry

Item – Storage Inspection

Object Data Management:

Document Revisions – Easy Entry

Change Proposal – Easy Entry

SSA Web Help

This section describes the most important functions and features of SSA Web Help. SSA Web Help is the new Help application for all SSA users and is installed together with the SSA WebTop, but can also be used as a standalone application.

MSDN look and feel

SSA Web Help has the same easy-to-use, recognizable user interface as the Microsoft MSDN Help. The window consists of three parts:

Shortcut bar

Navigation area

Content area

You can resize all these three parts to create the user interface you want. You can even change the look and feel.


Use of filters

You can install various types of Help content, for example, WebTop Help, SSA ERPLN Help, and SSA Enterprise Server Help. You can also configure Web Help to enable each user to hide the Help content they do not require.

Help texts stored in XML format

Help texts are stored in XML format and are, therefore, easy to maintain and deploy. Because the Help texts are stored in XML format, the customer can easily customize the Help texts. In addition, users can also store and search Microsoft Word, Microsoft Excel, PDF, and ASCII documents in SSA Web Help.

Full text search capabilities

User can now very easily search in Help. Simply enter your search criteria to search a part or all of the Help. Filtering is taken into account during the search. You can also perform a full-text search, or use combined search criteria using AND an OR. Matched items highlighted in the text.


On-the-fly installation of new Help content

When new Help content is delivered in a zip file, in the SSA WebTop Administration Console, you can easily install or update the Help content. The Help content file can be uploaded from the administrator’s client desktop or Web server. The Web server does not have to be restarted to make the new texts available.

To print booklets

You can easily print the content of SSA Web Help. Simply place the cursor in the tree, right-click on the mouse and, on the shortcut menu that appears, click Print. Everything under the current selected topic will be printed, according to the drill-down principle.

Customizable Web Help

By means of the admin console of the SSA WebTop, the administrator can assign users as Help writers by means of their user profiles. To customize the Help, these users can log on with a user profile where Help customization is enabled.

After logging in, this user will have additional options in the displayed Help, such as a Customize button on the Help page. If you click this button, you can customize the Help, for example, change or add Help texts or hide Help topics.

These customizations also remain if a new standard Help content is installed.

SSA Integration Pack 2.0 for ERP LN 5/6 – Microsoft Office 2000/XP

The Microsoft Office integration supplies SSA users with the best of both worlds: the ease-of-use and flexibility of Microsoft Word and Excel, and SSA ERP ’s capability to store and retrieve mass relational data. Users can select data from a SSA session and send this information to Microsoft Word or Excel:

Microsoft Word generates documents such as sales contracts, based on a predefined SSA ERP -related design template.


Microsoft Excel generates workbooks based on a predefined SSA ERP -related template. After the workbook is generated, users can use all the Excel functionality to manipulate and update the SSA ERP data.

Design templates are stored and published in SSA ERP on the application server, which enables other users to reuse these templates. Authorized SSA users can select the published templates from the Send To menu, as shown in the following figure:

Product Details

The Integration Pack consists of the following products:

User installer to enable related Menu Bar options and an extra toolbar in Microsoft Word and/or Excel.

Installer of designer tool for read-only templates. You can also, optionally, install SSA ERP upgrade facilities for Excel templates.

Additional tools provided to convert templates designed in earlier versions of the product to the latest template format of version.


SSA ERP Connectivity

Introduction

SSA ERP Connectivity is based on the Business Object concept.

A Business Object is an object understandable by the business, for example, a purchase order or organizational unit.

A Business Object contains information stored in the Business Object Attributes, for example, purchase order number and organizational unit name.

A Business Object contains a set of actions called Business Object Methods, which can manipulate the Business Object Attributes, for example, Create Purchase Order and List Organizational Units.

These Business Objects are the only entities that will expose information stored in the ERP database to the outside world.

The following integration paradigm is supported:

Business Object Services The Business Object is owned and handled by SSA ERP. A set of service methods enable the external party to manipulate the Business Object’s content.

Business Object Synchronization The Business Object sends changes as events to the external party.


The Business Object in SSA ERP has a layered architecture.

Public Layer

Protected Layer

DAL Layer

An external party can only enter the Public Layer, which can only enter the Protected Layer. The Protected Layer, in turn, can only enter the DAL Layer and the DAL Layer can only enter the table fields in the database.

All entries in each layer are considered interfaces. As a result, each layer’s definition is backwards compatible.

In this way, each layer is shielded against restructuring of the inner architecture of the lower layer.

The definition of the Public and the Protected Layer of the Business Object is modeled and stored in the Business Object Repository.


The following figure illustrates the overall architecture for SSA ERP Connectivity:

Business Object

Repository

Synchro-nization

Information

BaanERP Data

Synchro-nization Server

Store

Synchronization Object

Data Access layer

Protected Layer

Public Layer

Changes

Business Object

Data Access layer

Protected Layer

Public Layer

Repository Object

Data Access layer

Protected Layer

Public Layer

Dispatcher

http/SOAP connector

tcp-ip/SOAP

connector

invokes

invokes

invokes

uses

DMZ and internet

intranet

Public Interface

Protected Interface

pushes

Business Object Modeling

Introduction

Business Object definitions are modeled and stored in the Business Object Repository. Table and field definitions are stored in the data dictionary.

The DAL layer contains the data logic for all fields for one table. Based on the table definition, a DAL Template script can be generated. The logic must be programmed by filling in the template.

Two types of Business Objects exist: Simple and Complex Business Objects.

A Simple Business Object uses only one table, or more than one table with a zero-or-one-to-one relationship, to store information in. An example is the Business Object Currency.

A Complex Business Object uses at least two tables with a one-to-many relationship to store information in. An example is the Business Object PurchaseOrder.


If all protected and public information is defined the code of the protected and public layers is generated.

Protected attributes and methods

To model the protected layer of the Business Object, you can define the protected attributes and the protected methods.

The user can map a protected attribute to a table field, or the link can be the result of a calculation based on other protected attributes. The user must program the logic of these calculations inside a generated template.

Protected methods are Baan 3GL functions with arguments that are basic ERP data types.

To fulfill the interface constraints (backwards compatibility), a getters/setters concept is used rather than a regular argument list.

Two sets of protected methods exist: standard methods and specific methods.

The standard methods implement a predefined way to manipulate the protected Business Object Attributes for all Business Objects. Currently, six standard Business Object service methods exist:

Create

Change

Delete

Read

CreateRef

DeleteRef

CreateRef and DeleteRef are methods that enable external parties to notify SSA ERP that a reference is defined to this Business Object. If an external reference is defined, you cannot delete the Business Object.

The specific methods are methods for which logic is specific for this Business Object. This logic must be programmed in the generated template.

For each method, the protected attributes must be defined that are used as arguments.


Public attributes and methods

To model the public layer of the Business Object, you must define the public attributes and the public methods.

You can map a public attribute to a protected attribute, or the mapping can be the result of a calculation based on other protected attributes. The logic of these calculations must be programmed inside a generated template.

Public methods are Baan 3GL functions with three fixed arguments that are XML trees:

Request

Response

Result

The definition of these XML trees is stored as XML Schema files in the Business Object Repository.

Two sets of public methods exist: standard methods and specific methods.

The standard methods implement a predefined manner of manipulating the Public Business Object Attributes for all Business Objects. Currently, nine standard Business Object service methods exist:

Create

Change

Delete

Show

List

CreateRef

DeleteRef

PublishList

PublishChanges

The List, Show, PublishList, and PublishChanges method provides the requester the option to define a unique selection of the attributes and filter on the objects.


The specific methods are methods for which logic is specific for this Business Object. This logic must be programmed in the generated template.

SSA ERP Exchange

Introduction

In today’s businesses, customers have implemented various software packages from several vendors. The business data of these software packages is often managed locally and is not disclosed to other applications. Changes to data on one site are not reflected elsewhere, or only with inefficient data extraction tools.

SSA ERP Exchange is a piece of technology that enables customers to extract data from the SSA ERP system in a consistent, efficient, and flexible way.

You can also use SSA ERP Exchange in the following areas:

Multisite SSA ERP environments You can export and replay transactions processed on one or more sites onto one or more additional sites, and vice versa. With a configurable delay, you can partly synchronize databases of multiple sites.

Heterogeneous environments If you must integrate other applications with SSA ERP, you can achieve this integration without programming custom interfaces. While the transactions between both software environments are synchronized, data is available in both systems. You can perform the synchronization either one way from or to the SSA ERP environment, or both ways.

Conversions If an SSA ERP environment is upgraded to a release with a changed data model, conversion is required. With Exchange, the user can retrieve data from the old model and store the data in the new model. The user can perform this conversion in a highly configurable way.

Any one-time or repetitive export or import of data from or to an SSA ERP database.

SSA ERP Exchange positions itself uniquely in the area of offline bulk data exchange and data conversions, whereas the Business Object


Synchronization, as described in this section is more focused on online integrations and complete Business Objects rather than just data.

Architectural overview

The following illustration shows an architectural overview of SSA ERP Exchange:

TransactionLog

SSA ERP Exchange

OLTPApplication

Transport

OLTPApplication

SourceDatabase Export

Dataor

Trans-actions

TargetDatabaseImport

Configuration &Process Management

End usersEnd users

Data or transactions from the source database are exported can be manipulated and are then imported into the target database. This process is centrally managed.

Characteristics

From simple to flexible

In a simple integration business case, two sites have the same data model. As a result, the user can list the tables that must be synchronized, and generate the settings for the data exchange. With SSA ERP Exchange, a user can set up a simple integration such as this one in a few minutes.


For more complex cases, data selection and data transformation functionality is available. For fragmentation purposes, Exchange enables you to select the specific table columns that must be included, and to specify data ranges.

The user can implement data transformation by means of conversion tables or other methods, for example, to map codes from one environment to another. You can implement this functionality without programming. However, for complex validations and data transformations, Exchange offers the flexibility to embed scripts. These scripts offer complete functionality, including features such as embedded SQL.

In addition, the user can incorporate other programs or any operating system script

Not just data

SSA ERP Exchange offers not only database-level integration, but can also include existing business logic using functions from any SSA ERP application library.

The user can utilize the business logic of SSA ERP to add external data to SSA ERP Exchange in a controlled way. To add extra data, the Exchange can make use of the Data Access Layer (DAL), which handles the data constraints and business logic implemented in the SSA ERP applications. If you simply select a check box, the DAL functionality will be included when you import data. As a result, all validations and logic implemented in DALs are executed automatically, which avoids the requirement to program this functionality by hand in the exchange scripts.

Fast

Based on settings, code is generated and compiled into the runtime environment. This code is highly optimized.

In addition, you can compress the data that must be sent from one site to another to reduce network load.

The ability to exchange only the changes also improves performance. If two or more locations are synchronized, only the changes must be sent. The delta exchange is transaction-based; therefore the delta exchange processes transactions from the source database and replays the transactions at the target database as complete transactions.


Open

SSA ERP Exchange is a generic tool. You can configure SSA ERP Exchange to exchange any data from or into an SSA ERP database. The user can configure not only the data that must be included, but also in what sequence the data must be sent, and how the data must be formatted. Exchange supports formatting such as specifying date formats. In addition, Exchange can read and write both fixed length files, and delimited files using any delimiter.

Safe

In SSA ERP Exchange, the SSA ERP database definitions are used including domain constraints and integrity checks. In addition, the user can include validations in the Data Access Layer.

Transaction-based data exchange was designed to ensure that no transactions are missing or incomplete, and that the sequence is always correct. One transaction at the source will end up in one transaction at the target database. The sequence of the database transactions and the changes in a transaction at the target is forced to be the same as the sequence from the source. The sequences must also match if you use multiple database tables.

UTC times are used to assure time zone independence. In addition, application servers from various time zones can execute transactions on the same database. Also, if you exchange these transactions, the sequence is correct because the transaction sequence is time-zone independent.

All exceptions are logged and can be handled. The user can choose to:

Restart a previous run.

Continue a run, if the run was interrupted.

Reprocess rows that were rejected.

Multisite enabled

The Exchange architecture is based on a local autonomy model. Therefore, each site owns its data and processes and, in turn, each site decides when and how often to run exchange batches.


Conversely, you can link source and target sites. If you link sites, source and target sites are automatically synchronized. In addition, if one site is not available for some time, or if the batches at several sites do not run synchronously, Exchange ensures that no data will be missing.

Multisite Control enables users to not only use one-to-one topologies, but also one-to-many, many-to-one, or many-to-many. A target site can subscribe to data that is made available at a source site.

Manageable

SSA ERP Exchange enables the user to synchronize just once or regularly using a schedule. For example, you can synchronize every ten minutes, every hour, every day, or every week.

The processing status is logged and you can check the status at any time. The information presented includes statistics such as the number of rows processed and the number of exceptions.

When you configure the data exchange, if you incorporate specific checks, you can support process management. For example, you can carry out Exchange process steps conditionally, or you can stop an exchange process automatically under particular conditions.

Environment-friendly

Because Exchange is embedded in the SSA ERP environment, you can run Exchange in each environment where SSA ERP runs. As a result, Exchange is independent of any database or operating system.


SSA ERP Application Management

Job Management

SSA ERP Job Management provides functionality to schedule and monitor SSA sessions based on the following:

Business calendars

Periodical runs by minutes, hours, days, weeks, or months

External job schedulers

Device Management

SSA ERP Device Management provides functionality to:

Manage and monitor output devices attached to the SSA ERP infrastructure, such as network printers or file-oriented devices

Manage the SSA printer queues and device settings

User Management

SSA ERP User Management manages the SSA user’s profile for user- and developer-specific configurations, such as:

Device preferences

Application authorizations based on user roles and/or default user templates

Development related authorizations for e.g. specific sessions or ERP LN tables

Authorization Management System (AMS)

AMS provides functionality to:

Manage SSA user roles for role-based authorizations

Manage user templates for common used settings of end users and developers

Manage address book settings for the SSA ERP messaging facilities


Audit Management

Audit Management manages and monitors the audit files that contain transactional changes in the SSA ERP system. SSA ERP Data Access, which includes SSA ERP SyncServer and SSA ERP Exchange, primarily uses SSA ERP Audit Management to exchange the transactional changes across SSA ERP systems.

SSA ERP Development Environment

Introduction

This section describes the SSA ERP Development Environment. The Development Environment is a powerful set of tools to create scalable, robust, translatable, and platform-independent applications with high productivity.

3GL and 4GL sessions

The basic building blocks for SSA applications are sessions. A session is an entity that provides the user with an interface to an object to carry out a specific task. Technically, sessions can be divided in 3GL and 4GL sessions.

4GL sessions adhere to a particular template and are easy to develop. A 4GL session offers a great deal of standard functionality with respect to the user interface and database handling. A developer who creates a 4GL session selects a particular type of 4GL session and receives a default behavior for that session. Only the exceptions to that default behavior must be programmed. 4GL sessions have a form and combines associated software components, such as database tables and reports.

3GL sessions have nothing like what 4GL sessions offer. For 3GL sessions, programmers must program everything, including the complete user interface behavior.


The process to create 4GL application sessions typically involves the following steps:

Create table definitions.

Create a database interface script, which is also called the Data Access Layer (DAL).

Create dynamic forms.

Create a user-interface script.

Create labels, messages, and questions.

Create reports.

Create online Help.

Dynamic forms

Every 4GL session has a form developed with the Dynamic Form Editor (DFE). The DFE does not store the fixed positions of the window controls on the form, but only the dependency relation between fields. These relations can be identified with words such as:

Behind This field comes behind another field. If the other field is not displayed, this field will not be displayed either.

Below This field usually displays below the previous field, if the previous field is not displayed, this field will shift upwards, and other relation types.

Fields are combined into groups, which can have group boxes and can be nested. If the fields do not fit on one form, the fields will be spread over multiple forms. Fields in the lowest level group always appear on the same form.

This dynamic definition enables you to show the same form in several ways depending on the way you started the form (overview or details), the authorizations, and the category fields you chose (grouping of rows).

The biggest advantage of dynamic forms are visible at runtime, when fields are hidden on the fly and the form is restructured almost immediately.


Labels

Labels are used for every visible character string on the SSA ERP user interface. The use of labels enables SSA applications to be translated easily and in a cost-effective way. Deployment of software components is easy, because these components are truly language-independent. Deployment of new languages is also easy, because the language components can be delivered and installed by the ERP installer as a Language Pack.

Data Dictionary

In SSA ERP Tools, a central repository is present that contains all metadata and software components used by SSA ERP. This repository is called the data dictionary and is available in the same database system as the ERP data. The following software components are all stored in the data dictionary:

Table definitions

Domains

Menus

Sessions

Forms

Labels

Program scripts

Messages/Questions

Texts

Business Objects (BOR)

Icons

Versioning (VRC mechanism, see below)

Some of these software components are converted to flat ASCII files and stored on the file system for runtime performance reasons. This process is referred to as “convert to runtime.”


Source Configuration Management

All software components, which include sessions, source files, and reports, are under source control. As a result, for every software component, revision information is stored that can later be retrieved. This revision information is accompanied by a revision text, which describes the purpose of the change. Previous revisions can be retrieved for review, but later changes can also be rolled back.

All changes for a new application release or new piece of customization can be grouped in a Version Release Customization (VRC). The VRC is a code base that is either a full code base or that contains only the new/changed components as compared to a previous version. As a result, a VRC can be derived from an existing VRC.

To set up one or more application environments in an SSA system, you can define package combinations. A package combination consists of a set of application packages with a specific VRC. A SSA system can contain multiple package combinations. As a result, one SSA system can have multiple variants of the software active, for example, a package combination for the standard application and a package combination for customizations.

Product Maintenance and Control (PMC)

The Product Maintenance and Control (PMC) tool manages the implementation of service packs and individual patches, also called solutions, into a customer's SSA system.

The PMC tool enables you to check solutions for completeness and customization interference. Without this tool, solutions could be installed irrespective of other solutions that are already installed. Technically, you can install a solution that contains an earlier version of a function or DLL than already present in your system. In this case, you would lose the fixes in the original function or DLL. PMC keeps track of all installed solutions and their dependencies. The customer's SSA system contains a PMC repository, in which is registered which solutions the customer has installed and how these are related. New solutions will be checked against this PMC repository, in order to guarantee consistency of all solutions.

A Service Pack is created by bundling PMC solutions and offering these as one deliverable.


Installation and licensing

Introduction

A new installation concept is introduced with the SSA ERP LN release. The installation process is split up in two parts. The first step is to collect all the software components to be installed. During this process, the software components are staged into a so-called staging area.

Each delivery of software must be an Installable Unit (IU). The characteristics of an IU are that an IU can be delivered to customers as a software component with an installation program. After staging the installable units into the staging area, you must use the ERP installer to install the software components on the system, as illustrated in the following figure:

SSA ERP staging wizard

The SSA ERP staging wizard is an application for loading installable units into the staging area. During this staging process, the user can select the applications (installable units) from a medium that must be staged into the staging area. The staging wizard is available on the SSA Enterprise Engine and SSA ERP LN Application media.

After the installation wizard is started from the CD-ROM, the administrator must type a destination path of the staging area. Next, the staging wizard will show all the available installable units on the CD-ROM, and the administrator must make a selection on which installable units must be staged.


If the staging area already exists, the staging wizard displays the version from the software components available in the staging area, and the version from the CD-ROM. The administrator must make the decision on whether the installable units in the staging area must be updated (or downgraded) with the installable unit on the medium. The staging wizard will not perform any dependency checking, which means that the administrator must check which installable units and which versions must be staged into the staging area.

The installable units supported by the staging wizard are as follows:

SSA ERP porting set

SSA Enterprise Engine

SSA ERP LN 6.1 Application

SSA License Manager (client and server part)

SSA Application Service Manager (client and server part)

SSA OpenWorld ERP Adapter

SSA Webtop for SSA ERP

SSA ERP DEM Models

SSA ERP Demo and Base Companies

SSA ERP LN 6.1 Language Pack - 'language'

The software components that the Staging Wizard does not support are:

SSA Enterprise Webtop

SSA Documentation Portal

SSA Webtop content

PMC solutions and Service Packs

SSA Enterprise Engine Clients:

SSA Windows

SSA Worktop

SSA Enterprise Studio (DFE)

SSA ERP Application Clients:

SSA Integration Pack 2.0 for ERP LN 5/ERP 6 - Microsoft Office 97/2000/XP


SSA Integration Pack 1.0 for SSA ERP LN Project 6.1 - Microsoft Project 98/2000/2002

SSA Integration Pack for SSA ERP ODM MS Office 2000

SSA ERP LN 6.1 Freight Management Plan Board

SSA ERP LN 6.1 Sample Reports for FST

SSA Dynamic Enterprise Modeler

SSA ERP ODM Client

SSA ERP LN Project 6.1 Office Templates

SSA ERP Installer

The SSA ERP Installer is a generic installer you can use to install SSA ERP on the supported platforms. The SSA ERP Installer always runs on a Microsoft Windows platform, which means that installation on UNIX versions and IBM AS400 are carried out in client-server mode, while an installation on Microsoft Windows is performed locally.

To push the installable units to the remote server, the SSA ERP Installer uses a File Transfer Protocol (FTP) connection. The ERP Installer uses the Remote Executable Command (rexec) service to run programs on the remote computer. Finally, the ERP Installer uses the SSA Windows driver to start Enterprise Engine sessions on the remote computer.

The following figure provides an architectural overview of the SSA ERP Installer:


Because the SSA ERP Installer runs only on Microsoft Windows, you must deploy the staging area on a Microsoft Windows platform.

The administrator is responsible for installing the appropriate installable units together, which include components and versions. Depending on which installable units the administrator selects for installation, you must fill in several dialog boxes, after which the installation is carried out on the Enterprise Server.

SSA License Manager (SLM)

SSA License Manager introduction

SSA License Manager is the central license manager for all SSA products. SLM is a central application that checks whether users are licensed to start one of these products, and provides a common licensing solution for all SSA products, which ensures a consistent and reliable license validating mechanism.

An important advantage of having a single licensing mechanism is that this setup eliminates the need for multiple activation keys to start the various SSA products, minimizing administrative overhead. With the SLM, you need only a single activation key.

SLM license types

The license deals can vary, but the license types remain the same. Therefore, SLM does not license according to a license deal, but according to license types.

SSA ERP applications can be licensed in various ways, and to see how your application must be licensed, you can refer to the Software License and Support Agreement (SLSA). Depending on the pricing strategy of SSA, a restricted set of license types can be assigned to a specific application. For example, some applications can be licensed through any license type, while others can only be licensed through a server license only.

In general, the license types are distinguished in node locking and user locking. With node locking the adopting application can only work on a specific node in your network. A node can be a server, but also a desktop. With user locking, the adopting application can only work with a specified range of named user or with a predefined amount of concurrent users.


Currently, SSA supports only the following four license types:

License types Description

Concurrent User license

A user lock in which the adopting application can be used by a pool of concurrent users

Named User license A user lock in which the adopting application can be used by a pool of specific named users

Server license A node lock where the adopting application can be used on a pool of specific named server or desktop computers

Concurrent user license

With a concurrent user license, the SLM Server is not interested in the specific name of a user. The SLM Server only counts the amount of concurrent users at a specific time. If the amount exceeds the amount provided with the activation key, the SLM Server rejects new license requests from the adopting application.

Named user license

An adopting application can use named user licensing. In the SLSA is stated how many named users can use that application. The SLM Server keeps track of a list of all specific users that can use that application. The server rejects a license request from an adopting application if the specific user name is not known at the SLM Server.

Server license

An adopting application can use server licensing. In the SLSA is stated how many named servers can run that application. The SLM Server keeps track of a list of servers that can be used for an application.

SLM components

SLM contains the following components:

SLM Server handles all the license requests.


SLM Client decouples the product that adopted SLM and SLM Server and transfers the license requests from the SSA product to SLM Server.

SLM MMC snap-in is the configuration tool for SLM.

SLM validation procedure

The validation procedure consists of four main steps. The intention of the procedure is to activate the installed SSA products with an authorized activation key from SSA.

1 Specify at the SLM configuration all the products that have been installed and that must be licensed by means of SLM.

2 Upload this document to the Validation department of SSA.

3 SSA Validation checks the information in the license document against contract information. If the license document is correct, SSA Validation generates an activation key. This key is based on the data in the license document.

To overcome the period you must wait for the official validated key, SSA can send you almost immediately upon license request a temporary activation key that activates the applications for a limited period.

4 SSA Validation sends the validation key back to the customer, who submits this activation key to SLM server. By doing so, all specified SSA products in the license document become activated.

If other SSA components are installed, or if additional licenses are bought, the license document must be changed accordingly and a request for a new activation key must be carried out following the described process.

SLM deployment

SLM is a platform-dependent component. SLM builds are available for several hardware platforms and is kept in line with the platform support for the SSA Global products that depend on SLM for licensing.

A cluster of a maximum of four SLM servers can be set up to serve as a single logical license server to provide high availability.

Term Description

A/P Accounts Payable

A/R Accounts Receivable

ACP Accounts Payable, a module of SSA ERP Financials. Also used in business as a common term for monitoring and paying amounts owed to creditors.

ACR Accounts Receivable, a module of SSA ERP Financials. Also used in business as a common term for monitoring your debtors for payment.

Activity Activities are the project planning’s building blocks.

Actual costs of work performed (ACWP)

The actual costs incurred and recorded to accomplish the work performed within a given time period.

AMS Authorization Management System

API Application Programming Interface

ASCII American Standard Code for Information Interchange

ASM Application Services Manager

ASN Advance Shipment Notification

Assignment Information related to a job allocations for an employee

Baseline (planning) The base line can be seen as a snapshot of the start data and finish data of scheduled activities. It serves to compare the actual progress.

SLM SSA License Manager

A Appendix A Definitions, acronyms, and abbreviations

A-2 | Definitions, acronyms, and abbreviations

Bilateral Invoicing If there is goods transfer between entities belonging to two different financial companies but belonging to the same logistic company, the companies may decide to have invoicing relation between them. An internal invoice will be sent in this case from the company that delivered the goods to the company that received the goods.

BOCO Bill of Change Order

BOM Bill of Material

BOR Business Object Repository

BP Business Partner

Budgeted costs of work performed (BCWP)

The sum of the budgets for completed work packages and completed portions of open work packages. Also known as earned value.

Budgeted costs of work scheduled (BCWS)

The sum of the budgets for all the work packages and planning packages scheduled to be accomplished within a given time period.

BW Fat client for ERP LN, integrated with Worktop

CAD Computer Aided Design

CAT Cost Accounting, a module of SSA ERP Financials

CBM Condition Based Maintenance

CCB Change Control Board

CFG Configuration or Configuration Control

CH Change Header

Change Affected Objects

The Change Affected Objects session displays all the objects that can be affected and used in Change Management.

Change Committee A committee that is formed consisting of a chairperson and a few reviewers, to take part in the review process in Change Management. This committee is known as the Change Committee. Any authorized user can create a committee.

Change Management The Change Management is a module in ODM, which registers and controls the processes of product changes.

Change Orders The change order implements the change on the change order date. The change order child inherits the parent’s change order date.

Change Proposal A description of the planned change. This includes ownership details, recommended solution, task costs, and date execution, and the components linked to the change proposal.

Definitions, acronyms, and abbreviations | A-3

Change Request An entrance point to the change process. The information can be stored in each change request form to track different changes as requested by various sources.

Checked In Files present in the Vault Area are said to be in Checked In state.

Checked Out Files present in the Work Area are said to be in Checked Out state.

CHM Change Management

CLM Call management in Service package.

CMG Cash Management, a module of SSA ERP Financials. Also used in business as a common term for monitoring your cash.

CMS Commissions module in Distribution package that is responsible for raising commissions and rebates.

CO Change Order

COM Common module in Common package.

Company A working environment in which you can carry out logistic or financial transactions. All the data concerning the transactions are stored in the company’s database.

Depending on the type of data that the company controls, the company is:

A logistic company.

A financial company.

Both a logistic and a financial company.

In a multisite structure, the company database can partially exist uniquely for the company and partially consist of database tables that the company shares with other companies.

Consignment Consignment functionality is applicable when different parties handle inventory ownership and storage.

Control Account A control account is a general ledger account whose balance reflects the balance of Accounts Payable/ Accounts Receivable subledgers.

Control code This is a higher-level code above the special cost object and is used for control purposes.

Control data A translation of the actual budget into control data, which is used for cost control.

Cost Account/Project An identified level at the intersection of the work breakdown


cost account structure (WBS) and organizational breakdown structure (OBS). Functional responsibility for work is assigned at this point. For further management control you can compare the actual direct labor, material, and other direct costs with the earned value.

Cost component An extra dimension for the user to monitor the project.

Cost object The most detailed level of a budget. It is used to register the actual hours and the costs.

Cost type All the project costs can be categorized into five cost types: material, labor, equipment, subcontracting, and sundry costs.

CP Change Proposal

CTM Contract management module in Service package.

CTM Contract Management

CUMS Cumulatives

DAL Data Access Layer

DC Distribution Center

DEM Dynamic Enterprise Modelling

DFE Dynamic Form Editor

Direct Delivery If the required goods are not available in the company to execute a sales order, the purchase office sends an order to the supplier to directly deliver to the customer.

DLL Dynamic Load Library

DMZ De-Militarized Zone Part of a network which is located between two firewalls.

DOC Document Management

Document Libraries Document library is a library, which is used to catalog documents.

Document Lifecycle The life cycle of a document from concept to completion. The Document Lifecycle involves many phases.

Document Management

The Document Management is a module in ODM, which provides general document management facilities to the SSA ERP system. Document management ensures the efficient and secure use of consistent, reliable and revision controlled document information.

Document Management Committee

In Document Management, a committee can be formed consisting of a chairperson and few reviewers, to become a part of review process. This committee is known as a Document


Management Committee. Any authorized user can create such a committee.

Document type The type of document for a company (for example: safety regulations, wiring diagram, maintenance instructions, or standards). The user is authorized to perform various actions depending on the document type.

DRP Distribution Requirements Planning

Earned value Performance measurement; the budgeted costs of work performed.

EDI Electronic data interchange module in Electronic commerce package. This module is responsible for receiving and sending the various messages through EDI.

Element Elements are used to define the (structure of the) project.

EMM A module in SSA ERP Common that is used to model the organization and to make the enterprise modeling information available to the other SSA ERP packages. Modeling the organization consists of defining:

The entities.

The relationships between the entities.

The enterprise structure.

Employee Person employed by a company

Enterprise unit An enterprise unit consists of logically grouped entities (work centers, sales offices, purchase offices, accounting departments, warehouses, and projects) of one logistic company that report to the same financial company. From a business perspective, an enterprise unit can be considered as an independent fiscal unit in a logistic context.

For example, an enterprise unit can be a manufacturing plant, an assembly plant, a sales organization, a distribution center, or a service organization.

EOQ Economic Order Quantity

EP SSA ERP Enterprise Planning

Estimate to complete The value that represents a realistic appraisal of the cost of the work that is still required to complete a task.

Extensions Extensions cover the specific agreements within or in addition to the initial contract.

FAB Fabrication


Factor The factor is a bank or a commercial finance company that specializes in buying receivables.

FAM Fixed Asset Management, a module of SSA ERP Financials

FBM Failure Based Maintenance (also called Breakdown Maintenance)

FBS Financial Budget System, a module of SSA ERP Financials

FCO Field Change Order

File The object that points to a physical file.

Financial company A company used for posting financial data in SSA ERP Financials. You can link one or more enterprise units from multiple logistic companies to one financial company.

FM SSA ERP Freight Management

FOC Freight order control module in Freight package. This module is responsible for creating the various freight orders.

Folder Folder is a data item that contains a group of related objects.

Folder Management The Folder Management is a module in ODM, which is used to maintain folders. Folders simplify the management of product information.

FST Financial Statements, a module of SSA ERP Financials

GLD General Ledger, a module of SSA ERP Financials. All the ledger postings take place here.

Goods Synonym of Items

Group company

A financial group company is a financial company to which a number of other financial companies are linked. A financial group company is used to:

Process the corporate and administrative accounting

Accumulate the data from the group’s financial companies for consolidated financial reporting.

Perform central cash management processes such as payments and direct debit.

Hard Copies An object that points to the physical hard copy. The contents of a document may be stored using paper or other medium.

IBD Item Base Data

ID Identification

INH Inventory handling module in the Warehousing package.


INH Inventory Handling

INR Inventory Reporting

I/0 Input/Output

IPD Item Production Data

IPU Item Purchase Data

IRS Internal Revenue Service, branch of the federal US government in charge of collecting most types of taxes.

ISA Item Sales Data

ISO International Standard Organization

Labor Type Classification of labor to which surcharge is to be linked.

Logistic company

A SSA ERP company used for logistic transactions, such as the production and transportation of goods. All the logistic data concerning the transactions is stored in the company’s database.

A logistic company can consist of enterprise units that are linked to different financial companies.

LSP Logistic Service Provider

LTS Language Translation System

Mask A template that specifies the structure of an identification code.

Mateability Within FM this is done through so-called combination codes, which indicate whether items may be shipped together or whether a particular vehicle can be used for transporting an item (compatibility).

MAUC Moving Average Unit Cost

MCS System tables module in Common package.

MDM Master Data Management

MMC Microsoft Management Console

MSC Maintenance sales control module in Service package.

Multicompany (multisite)

An organization in which the SSA ERP configuration consists of more than one SSA ERP company, of the type Logistic, Financial, or Both. This implies the integration of a group of company processes into a structure, which is referred to as ‘multi-company’ in this manual.

Multicurrency systems Functionality that enables an SSA ERP company to do its accounting in more than one currency. Amounts are computed


and registered in up to three currencies.

Object An entity that is defined in ODM with all details to manage the Changes, Documents, Folders, and so on.

Object Browsing The object explorer enables the user to view the object’s links, in the form of a graphical horizontal tree browser.

Object Family Group of objects with an object as owner to maintain the links.

ODM Object Data Management (ODM) is an independent package within SSA ERP that provides effective data management and change management solutions in a project development scenario.

Part A material item that is used as a component, not as an (sub)assembly. Often used as a synonym for items.

PBOM Production Bill of Material

PCS Project Control Systems

PDF Portable Document Format

Performance measurement baseline

The time-phased budget plan against which project performance is measured. It is formed by the time-phased budgets assigned to scheduled activities.

PIN Project invoicing module in Projects package.

Planning package A logical aggregate of far-term work within a cost account that can be identified and budgeted, but that is not yet defined into work packages. Planning packages are identified during the planning to establish the time phasing of the major activities within a cost account and the quantity of the resources required for their performance.

PM Preventive Maintenance

Pooling Point Pooling points are (fixed) nodes in a route structure. Examples are regional DC’s, harbors, bonded warehouses and other sites where grouping of shipments, cross docking, centralized storage, and so on, take place, and from where goods are distributed again.

PPL People (module in Common)

PTC Product Testing and Control

PUR Purchase

QM Quality Management

Query Generic mechanism for registering a set of records based on conditions provided by the user.


Query Condition Condition provided by user based on attribute values used for setting up a query.

RAW Raw material

RDBMS Relational Database Management System

Related Objects This is an object that is defined in ODM and which is also related to the main object in a business flow.

Relative Change Orders (RCO)

Based on the Base Change Order date, the RCO will be effective based on the Change Order Date plus the duration given by the user and this date is made use in making an ERP entity effective or expired. The ERP entity must be logically dependent on the ERP entity linked to the Base Change Order Date.

Reviewers Mechanism This functionality is present in both Change Management and Document Management. It allows the user who is authorized, in this case the Chairperson to create a Committee and then define Reviewers by Document or Change Committee.

RMA Return Material Authorization

ROU Routing

Rule Rules can be used as a one-point provision to trigger dependent events/entities.

SBM Subcontract Management

Service Level

Service levels normally indicate a customers’ requirement with regard to delivery times. Examples are ‘Express Transport’, ’24 hours delivery’, and so on.

SFC Shop Floor Control

Shipper Commercial enterprise or manufacturer for which transport is an essential part of the supply chain but not regarded as core business.

SIC Strategic Inventory Control

SLI Sales invoicing module in Central invoicing package. The module is responsible for creation and sending invoices centrally.

SLS Sales module in Distribution package.

SLSA Software Licensed Support Agreement

SOC Service order control module in Service package.

SPC Service Planning and Concepts


SQL Structured Query Language

SRP Service Requirement Planning

TMG Transport Means Group

TMS Transport Management System

TPOP Time Phased Order Point

Transaction Type Differentiating hours spent by logistical package/module.

Triangular invoicing If the order is received by entity belonging to one financial company but the goods are delivered by an entity belonging to other financial company (entities belonging to the same logistic company), the companies may decide to have invoicing relation between them. In this case, an internal invoice will be sent from the company that delivered the goods to the company that received the order.

TSS Triton Super Set

UBM Use Based Maintenance

VIN Vehicle Identification Number

WCS Work Control System

WH Warehousing

WIP Work in Progress

WMD Warehouse Master Data

Work packages Detailed short-span jobs identified by the contractor for accomplishing work that is required to complete a contract.

Working Time Schedule

A way to divide the day in parts linked to a labor type.

XML Extensible Makup Language

Functions and Features ln 61 functions and features.pdf · Table of Contents Chapter 1...

Documents

Transcript of Functions and Features ln 61 functions and features.pdf · Table of Contents Chapter 1...