Infor ERP LN 6.

Functions and Features

Copyright 2010 Infor

All rights reserved. The word and design marks set forth herein are trademarks and/or registered trademarks of Infor and/or related affiliates and subsidiaries. All rights reserved. All other trademarks listed herein are the property of their respective owners.

Important Notices
The material contained in this publication (including any supplementary information) constitutes and contains confidential and proprietary information of Infor. 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 Infor 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 Infor 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 Infor has taken due care to ensure that the material included in this publication is accurate and complete, Infor 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, Infor 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.

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

Publication Information
Document code: P3496H US Release: Functions and Features Publication date: December 6, 2010

Table of Contents

Chapter 1 Chapter 2

Introduction ............................................................................................................. 1-1 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 ERP LN............................................................................ 2-9 Business Control Model ..................................................................................................... 2-10 Business Function Model ................................................................................................... 2-12 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 Chapter 4 Production Typologies and ERP LN Scenarios.................................................... 3-1 Common .................................................................................................................. 4-1

Introduction ................................................................................................................................ 4-1 Calendars................................................................................................................................... 4-1 Unit effectivity............................................................................................................................. 4-2 Unit effective data ................................................................................................................ 4-2 Requirements....................................................................................................................... 4-3 Units and sales order entry .................................................................................................. 4-4

ii

| Table of Contents
Units in inventory ................................................................................................................. 4-4 Pegging................................................................................................................................ 4-4 Cost price calculation........................................................................................................... 4-4 Allocations and Hard Pegging.................................................................................................... 4-4 Item base data ........................................................................................................................... 4-5 Business partners ...................................................................................................................... 4-5 Taxation ..................................................................................................................................... 4-6 Terms and Conditions ................................................................................................................ 4-6

Chapter 5

People ...................................................................................................................... 5-1

Introduction ................................................................................................................................ 5-1 Master Data Management (MDM).............................................................................................. 5-1 Time Management (TMM).......................................................................................................... 5-2 Budgeting............................................................................................................................. 5-2 Hours registration................................................................................................................. 5-3 History.................................................................................................................................. 5-5 Chapter 6 Financials ................................................................................................................ 6-1

Introduction ................................................................................................................................ 6-1 General Ledger (GLD) ............................................................................................................... 6-2 Multi currency....................................................................................................................... 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 Accounts Receivable (ACR)....................................................................................................... 6-4 Multiple control accounts ..................................................................................................... 6-5 Payment schedules.............................................................................................................. 6-5 Credit control........................................................................................................................ 6-5

Table of Contents

| iii

Factoring .............................................................................................................................. 6-5 Accounts Payable (ACP)............................................................................................................ 6-7 Multiple control accounts ..................................................................................................... 6-8 Automatic invoice creation ................................................................................................... 6-8 Easy entry ............................................................................................................................ 6-8 Matching .............................................................................................................................. 6-8 Payment schedules.............................................................................................................. 6-8 Payment authorizations ....................................................................................................... 6-9 Pay from receipt................................................................................................................... 6-9 Withholding taxes................................................................................................................. 6-9 Procurement cards............................................................................................................... 6-9 Dashboard ........................................................................................................................... 6-9 Aging analysis...................................................................................................................... 6-9 Cash Management (CMG) ....................................................................................................... 6-10 Financial Budget System (FBS) ............................................................................................... 6-11 Cost Accounting (CAT) ............................................................................................................ 6-13 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-6 General Project Data ........................................................................................................... 7-7 Standard Cost Objects......................................................................................................... 7-8 Buy from business partner files............................................................................................ 7-8 Standard Revenues ............................................................................................................. 7-9 Standard structures.............................................................................................................. 7-9 User-defined structures........................................................................................................ 7-9 Project templates ............................................................................................................... 7-10 Standard Surcharges ......................................................................................................... 7-10 Project Definition (PDM)........................................................................................................... 7-10 Scope definition Dynamic menu...................................................................................... 7-11

iv

| Table of Contents
Project Data ....................................................................................................................... 7-11 Project structures ............................................................................................................... 7-13 Project general data........................................................................................................... 7-14 Project Cost Objects .......................................................................................................... 7-14 Project Revenues............................................................................................................... 7-15 Project surcharges ............................................................................................................. 7-15 Project Currency Conversion ............................................................................................. 7-15 Project Estimating (EST).......................................................................................................... 7-15 Project Budget (PTC) ............................................................................................................... 7-21 Project Planning (PSS-2) ......................................................................................................... 7-25 Plans.................................................................................................................................. 7-26 Activities and Activity Structure .......................................................................................... 7-26 Activity Relationships ......................................................................................................... 7-27 Milestones.......................................................................................................................... 7-27 Integration with Microsoft Project ....................................................................................... 7-27 External scheduling links ................................................................................................... 7-28 Baseline ............................................................................................................................. 7-28 Project Requirement Planning (PSS-6).................................................................................... 7-28 Generate planned orders ................................................................................................... 7-29 Order line balance.............................................................................................................. 7-30 Planned purchase orders ................................................................................................... 7-31 Planned warehouse orders ................................................................................................ 7-31 History of PRP order .......................................................................................................... 7-31 Generate service orders .................................................................................................... 7-31 List of service order links by project ................................................................................... 7-32 Project Progress (PPC)............................................................................................................ 7-32 Progress ............................................................................................................................ 7-33 Costs.................................................................................................................................. 7-34 Cost Forecast..................................................................................................................... 7-35 Registering revenues ......................................................................................................... 7-36 Financial results ................................................................................................................. 7-36 Extension Transactions...................................................................................................... 7-37

Table of Contents

|v

Processing ......................................................................................................................... 7-38 Project Monitoring (PPC) ......................................................................................................... 7-38 Build Actual Cost Control ................................................................................................... 7-39 Control Inquiries and Reports ............................................................................................ 7-40 Financial analysis (charts) ................................................................................................. 7-40 Performance Measurement ............................................................................................... 7-41 Project Invoicing (PIN) ............................................................................................................. 7-42 Installment invoicing........................................................................................................... 7-43 Progress invoice ................................................................................................................ 7-44 Unit Rate ............................................................................................................................ 7-45 Cost plus ............................................................................................................................ 7-45 Integration with Sales Invoicing.......................................................................................... 7-46 Chapter 8 Enterprise Planning ................................................................................................ 8-1

Introduction ................................................................................................................................ 8-1 Enterprise Planning Master Data ............................................................................................... 8-2 Scenarios ............................................................................................................................. 8-2 Item data .............................................................................................................................. 8-3 Resources............................................................................................................................ 8-3 Plan units ............................................................................................................................. 8-4 Sourcing............................................................................................................................... 8-4 Master planning ......................................................................................................................... 8-4 Item planning ....................................................................................................................... 8-5 Resource planning ............................................................................................................... 8-6 Channel planning ................................................................................................................. 8-6 Order planning ........................................................................................................................... 8-6 Plan analysis.............................................................................................................................. 8-8 Plan transfer............................................................................................................................... 8-8 Order grouping..................................................................................................................... 8-9 Release planning ................................................................................................................. 8-9 Enterprise Planning parameters................................................................................................. 8-9 EP parameters ..................................................................................................................... 8-9 Performance parameters ................................................................................................... 8-10

vi

| Table of Contents
Work load control parameters ............................................................................................ 8-10 Order Management ................................................................................................. 9-1

Chapter 9

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 Subcontracting ................................................................................................................... 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-13 Purchase contract price revisions ...................................................................................... 9-15 Sales contracts .................................................................................................................. 9-15 Purchase and Sales Schedule Management ........................................................................... 9-17 Introduction ........................................................................................................................ 9-17 Purchase schedule management....................................................................................... 9-18 Push and pull demand ....................................................................................................... 9-18 Purchase schedule header ................................................................................................ 9-19

Table of Contents

| vii

Purchase schedule lines .................................................................................................... 9-20 Integrations around the purchase schedules ..................................................................... 9-21 Process the purchase schedule ......................................................................................... 9-24 Purchase release header ................................................................................................... 9-24 Purchase release lines....................................................................................................... 9-26 Purchase release lines details ........................................................................................... 9-27 CUM handling and FAB/RAW authorizations..................................................................... 9-27 Sales schedule management................................................................................................... 9-29 Introduction ........................................................................................................................ 9-29 Sales releases ................................................................................................................... 9-29 Sales release header ......................................................................................................... 9-29 Sales release lines............................................................................................................. 9-30 Sales schedule header ...................................................................................................... 9-30 Sales schedule lines .......................................................................................................... 9-32 Schedule shipment details/corrections............................................................................... 9-34 Sequence shipping information.......................................................................................... 9-34 Sales schedule reconciliation............................................................................................. 9-35 CUM handling and FAB/RAW authorizations..................................................................... 9-35 Purchase and Sales Statistics............................................................................................ 9-36 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

Introduction .............................................................................................................................. 11-1 Sales Invoicing ......................................................................................................................... 11-1 Chapter 12 Manufacturing ....................................................................................................... 12-1

viii

| Table of Contents
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 Infor PDM........................................................................................................ 12-2 Item Production Data (IPD) ...................................................................................................... 12-3 Bill of Material (BOM) ............................................................................................................... 12-4 Routing (ROU) ......................................................................................................................... 12-5 Configurator (PCF)................................................................................................................... 12-7 Generic product modeling .................................................................................................. 12-8 Configuration and structure generation.............................................................................. 12-8 Advanced Configurator Integration .................................................................................... 12-9 Cost Price Calculation (CPR)................................................................................................... 12-9 Shop Floor Control (SFC) ...................................................................................................... 12-10 Positioning of production typologies................................................................................. 12-10 Production order control................................................................................................... 12-13 Production order processing ............................................................................................ 12-14 Production order completion ............................................................................................ 12-15 Scrap and yield ................................................................................................................ 12-15 Production order planning ................................................................................................ 12-16 Production order subcontracting ...................................................................................... 12-16 Execution of subcontracting activities .............................................................................. 12-18 Production order costing .................................................................................................. 12-20 Production order history ................................................................................................... 12-20 Input output monitoring .................................................................................................... 12-21 Order grouping................................................................................................................. 12-21 Order sequencing based on setup and states.................................................................. 12-22 Project Control (PCS)............................................................................................................. 12-22 Repetitive Manufacturing (RPT) ............................................................................................. 12-23 Assembly Planning................................................................................................................. 12-23

Table of Contents

| ix

Sales order entry.............................................................................................................. 12-24 Engineering & product configuration ................................................................................ 12-24 Product variants ............................................................................................................... 12-24 Master data: Line/operation setup.................................................................................... 12-24 Flattened parts ................................................................................................................. 12-25 Assembly parts requirements calculation......................................................................... 12-25 Assembly order generation .............................................................................................. 12-25 Refresh/freeze assembly orders ...................................................................................... 12-25 Unit and date effectivity.................................................................................................... 12-25 Assembly Control (ASC) ........................................................................................................ 12-25 Line Station Variants (LSV).............................................................................................. 12-26 Clustered Line Station Orders (CLSO)............................................................................. 12-26 Partial freeze.................................................................................................................... 12-26 Multisite assembly............................................................................................................ 12-27 Line Sequencing .............................................................................................................. 12-27 Manual change of the sequence ...................................................................................... 12-27 Inventory check................................................................................................................ 12-27 Work instructions ............................................................................................................. 12-27 Material supply................................................................................................................. 12-27 Time-horizon-driven material supply ................................................................................ 12-28 Closed loop ...................................................................................................................... 12-28 Progress overview per line segment ...................................................................................... 12-29 Progress overview per buffer ........................................................................................... 12-29 Progress overview per line station ................................................................................... 12-29 Process triggering ............................................................................................................ 12-29 Hours backflush ............................................................................................................... 12-30 Line surcharges ............................................................................................................... 12-30 WIP transfers ................................................................................................................... 12-30 As-built structure .............................................................................................................. 12-30 Lean system..................................................................................................................... 12-31 Bar coding........................................................................................................................ 12-31 Manufacturing control ...................................................................................................... 12-31

| Table of Contents
Tool Requirements Planning (TRP) ....................................................................................... 12-33 Product Classification (GRT).................................................................................................. 12-33

Chapter 13

Warehouse Management...................................................................................... 13-1

Introduction .............................................................................................................................. 13-1 Warehouse master data........................................................................................................... 13-2 Introduction ........................................................................................................................ 13-2 Warehouses....................................................................................................................... 13-2 Items .................................................................................................................................. 13-3 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-5 Introduction ........................................................................................................................ 13-5 Warehouse Management orders........................................................................................ 13-6 Cross-docking .................................................................................................................... 13-7 Direct Material Supply........................................................................................................ 13-7 Inbound .............................................................................................................................. 13-7 Inventory Disposition.......................................................................................................... 13-9 Outbound ......................................................................................................................... 13-11 Value added services....................................................................................................... 13-12 Kitting and Shipping ......................................................................................................... 13-13 Handling units .................................................................................................................. 13-14 Cycle counting ................................................................................................................. 13-15 Inventory adjustments...................................................................................................... 13-16 Blocking ........................................................................................................................... 13-16 Inventory Reporting................................................................................................................ 13-17 Introduction ...................................................................................................................... 13-17 Inventory position............................................................................................................. 13-17

Table of Contents

| xi

Inventory transactions...................................................................................................... 13-18 Inventory Analysis .................................................................................................................. 13-18 Lot Control and Serials........................................................................................................... 13-18 Introduction ...................................................................................................................... 13-18 Lot control ........................................................................................................................ 13-18 Serials .............................................................................................................................. 13-19 Consignment stock................................................................................................................. 13-19 Consignment (not owned) ................................................................................................ 13-19 Consignment (owned) ...................................................................................................... 13-20 Service customer owned.................................................................................................. 13-20 Consignment replenishment and payment....................................................................... 13-20 Vendor Managed Inventory.................................................................................................... 13-21 VMI Procedures & Scenarios ........................................................................................... 13-21 Roles and Terms/Conditions............................................................................................ 13-22 Communication ................................................................................................................ 13-23 Connectivity to AutoConnect Components............................................................................. 13-23 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-4 Addresses and items ......................................................................................................... 14-4 Transportation master data ................................................................................................ 14-5 Freight order master data .................................................................................................. 14-5 Load building (freight planning) master data ...................................................................... 14-6 Freight Order Control (FOC) .................................................................................................... 14-6 Create/maintain freight orders............................................................................................ 14-6 Subcontracting freight orders ............................................................................................. 14-7 Inventory commitments for freight orders........................................................................... 14-7 Freight order history........................................................................................................... 14-7 Rough Planning (RPG) ............................................................................................................ 14-7 Load Building (Planning) (LBD)................................................................................................ 14-7

xii

| Table of Contents
Plans, loads, and shipments .............................................................................................. 14-8 Graphical planning board ................................................................................................... 14-9 History.............................................................................................................................. 14-10 Freight Rate Control (FRC) .................................................................................................... 14-10 To calculate freight costs and revenues........................................................................... 14-10 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-4 Grouping, usage, and history ............................................................................................. 15-5 Call Management (CLM) .......................................................................................................... 15-6 Contract Management (CTM) .................................................................................................. 15-8 Contract master data ......................................................................................................... 15-9 Warranties.......................................................................................................................... 15-9 Contract templates........................................................................................................... 15-10 Contract quotations.......................................................................................................... 15-10 Contract control................................................................................................................ 15-11 Subcontract Management (SBM) ........................................................................................... 15-14 Field service........................................................................................................................... 15-14 Planning and Concepts (SPC) ......................................................................................... 15-14 Service Order Control (SOC) ........................................................................................... 15-16 RMA and Depot Repair .......................................................................................................... 15-23 Maintenance Sales Quotations (EPP).............................................................................. 15-23 Maintenance Sales Control (MSC)................................................................................... 15-24 Work Order Control (WCS) .............................................................................................. 15-25 Master Data Management (MDM).......................................................................................... 15-27 Service organization ........................................................................................................ 15-28 Service item data ............................................................................................................. 15-30 Reference activities and inspection templates ................................................................. 15-30

Table of Contents

| xiii

Cost and the coverage types ........................................................................................... 15-31 Sundry service related definitions .................................................................................... 15-32 Related Orders................................................................................................................. 15-33 Service Analytics.............................................................................................................. 15-33 Module relationships in ERP LN Service................................................................................ 15-34 Chapter 16 Quality Management............................................................................................. 16-1

Introduction .............................................................................................................................. 16-1 Product Testing and Control .................................................................................................... 16-1 Introduction ........................................................................................................................ 16-1 Master data ........................................................................................................................ 16-5 Algorithm............................................................................................................................ 16-6 Quality IDs ......................................................................................................................... 16-7 Order-specific inspections.................................................................................................. 16-8 Standard inspections ......................................................................................................... 16-9 Storage inspection ........................................................................................................... 16-12 Inspection history ............................................................................................................. 16-13 Quality Management parameters..................................................................................... 16-13 Origin ............................................................................................................................... 16-13 Series............................................................................................................................... 16-14 Blocking reasons.............................................................................................................. 16-15 Test data .......................................................................................................................... 16-15 Chapter 17 Object Data Management ..................................................................................... 17-1

Introduction .............................................................................................................................. 17-1 Overview features of ODM....................................................................................................... 17-2 Document Management........................................................................................................... 17-3 Introduction ........................................................................................................................ 17-3 Libraries ............................................................................................................................. 17-4 Document type................................................................................................................... 17-5 Documents......................................................................................................................... 17-5 Document revision ............................................................................................................. 17-6 Files ................................................................................................................................... 17-8

xiv

| Table of Contents
Hard copies........................................................................................................................ 17-9 Document Management integrations ............................................................................... 17-10 Document Management integrations to external applications.......................................... 17-10 Architecture of Document Management in ERP LN ODM................................................ 17-11 Change Management............................................................................................................. 17-12 Introduction ...................................................................................................................... 17-12 Change Management Objectives ........................................................................................... 17-14 Business objectives ......................................................................................................... 17-14 Functional objectives ....................................................................................................... 17-15 Change Request .............................................................................................................. 17-15 Changes .......................................................................................................................... 17-16 Change proposal.............................................................................................................. 17-17 Change proposal status ................................................................................................... 17-17 Change approval.............................................................................................................. 17-18 Linking an ERP LN object to the change proposal........................................................... 17-18 Change orders ................................................................................................................. 17-18 Task group ....................................................................................................................... 17-19 Tasks ............................................................................................................................... 17-19 Folder Management ............................................................................................................... 17-20 Introduction ...................................................................................................................... 17-20 Folders ............................................................................................................................. 17-20 Queries and Reports .............................................................................................................. 17-21 Introduction ...................................................................................................................... 17-21 Query ............................................................................................................................... 17-23 Query Conditions ............................................................................................................. 17-23 Reports ............................................................................................................................ 17-24 Configuration.......................................................................................................................... 17-24 Introduction ...................................................................................................................... 17-24 Masks .............................................................................................................................. 17-25 Authorizations .................................................................................................................. 17-25 Secondary status ............................................................................................................. 17-26 Objects and related objects.............................................................................................. 17-26

Table of Contents

| xv

Common ODM parameters .............................................................................................. 17-27 Business rules.................................................................................................................. 17-27 Export and import of system data .................................................................................... 17-27 Import Files ...................................................................................................................... 17-27 Chapter 18 Multisite ................................................................................................................. 18-1

Introduction .............................................................................................................................. 18-1 Multisite environments ............................................................................................................. 18-2 Some multicompany terms....................................................................................................... 18-2 Enterprise structure modeling .................................................................................................. 18-5 Enterprise units ........................................................................................................................ 18-6 Multicurrency............................................................................................................................ 18-7 Intra-logistic company transactions .......................................................................................... 18-8 Data sharing............................................................................................................................. 18-8 Multicompany processing......................................................................................................... 18-9 Multicompany Financials.......................................................................................................... 18-9 Multicompany Enterprise Planning........................................................................................... 18-9 Multicompany Manufacturing ................................................................................................... 18-9 Multicompany Order Management ......................................................................................... 18-10 Multicompany Project............................................................................................................. 18-10 Multicompany Service ............................................................................................................ 18-10 Multicompany Warehousing................................................................................................... 18-11 Chapter 19 ERP LN 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-3 Enterprise Server ............................................................................................................... 19-4 Enterprise Server Extension .............................................................................................. 19-4 ERP LN Runtime Environment................................................................................................. 19-4

xvi

| Table of Contents
Virtual Machine (bshell) ..................................................................................................... 19-4 Database driver.................................................................................................................. 19-5 Platform and database support for ERP LN 6.1 ................................................................. 19-6 Infor ES Reporting Service ................................................................................................ 19-6 Internationalization ................................................................................................................... 19-7 Multilanguage software ...................................................................................................... 19-7 Multilanguage Data ............................................................................................................ 19-8 Multicurrency...................................................................................................................... 19-8 User Interface .......................................................................................................................... 19-8 Customer Defined Fields ................................................................................................... 19-9 Sensitivity Labels ............................................................................................................... 19-9 Infor Web UI versus Infor Worktop..................................................................................... 19-9 Infor Web UI specific User Interface features................................................................... 19-11 Generic User Interface features ....................................................................................... 19-18 Infor Web Help ................................................................................................................. 19-21 Infor Integration Pack 2.0 for ERP LN 5/6 Microsoft Office XP/Vista................................ 19-23 Product Details................................................................................................................. 19-24 ERP LN Connectivity.............................................................................................................. 19-24 Infor ION Integration ........................................................................................................ 19-24 Infor ION Event Management .......................................................................................... 19-24 Infor ION Workflow........................................................................................................... 19-25 Business Object concept ................................................................................................. 19-25 Business Object Modeling ............................................................................................... 19-26 Business Studio ............................................................................................................... 19-28 ERP LN third-party integrations ............................................................................................. 19-29 ERP LN Exchange ................................................................................................................. 19-30 Introduction ...................................................................................................................... 19-30 Architectural overview ...................................................................................................... 19-31 Characteristics ................................................................................................................. 19-31 Not just data..................................................................................................................... 19-32 Fast.................................................................................................................................. 19-32 Open ................................................................................................................................ 19-33

Table of Contents

| xvii

Safe ................................................................................................................................. 19-33 Multisite enabled .............................................................................................................. 19-33 Manageable ..................................................................................................................... 19-34 ERP LN Application Management.......................................................................................... 19-34 Job Management ............................................................................................................. 19-34 Device Management ........................................................................................................ 19-34 User Management ........................................................................................................... 19-35 Authorization Management System (AMS) ...................................................................... 19-35 Audit Management........................................................................................................... 19-35 Product Maintenance and Control (PMC) ........................................................................ 19-35 Data Upgrade Engine ...................................................................................................... 19-36 ERP LN Development Environment ....................................................................................... 19-36 Introduction ...................................................................................................................... 19-36 Application Studio ............................................................................................................ 19-36 Microsoft Reporting for ERP LN Extension ...................................................................... 19-37 3GL and 4GL sessions .................................................................................................... 19-37 Dynamic forms ................................................................................................................. 19-38 Labels .............................................................................................................................. 19-38 Programmatic business triggers....................................................................................... 19-38 Data Dictionary ................................................................................................................ 19-39 Source Configuration Management ................................................................................. 19-39 Business Studio ............................................................................................................... 19-40 .Installation and licensing ....................................................................................................... 19-40 Introduction ...................................................................................................................... 19-40 ERP LN staging wizard .................................................................................................... 19-41 ERP LN Installer .............................................................................................................. 19-42 Infor License Manager (SLM)........................................................................................... 19-42 SLM validation procedure ................................................................................................ 19-43 SLM deployment .............................................................................................................. 19-43 Appendix A Definitions, Acronyms, and Abbreviations.......................................................... A-1

xviii

| Table of Contents

About this Guide

This document describes the functionality in ERP LN, and is a technical document that provides detailed information 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 ERP LN. This document contains the following chapters: Chapter 1, ERP LN Overview, provides a general introduction to ERP LN and this document. Chapter 2, Enterprise Modeler, discusses the Enterprise Modeler functionality in ERP LN. Chapter 3, Production Typologies and ERP LN Scenarios, describes the broad range of production typologies in discrete manufacturing environments that ERP LN supports. Chapters 418 provide a detailed description of the modules and functionality of the various packages in ERP LN. Chapter 19, ERP LN Technology, provides detailed information about the technology used in ERP LN. Appendix A provides a glossary of terms used in ERP LN and in this document, and a list of relevant abbreviations.

xx

| Table of Contents
Send us your comments We continually review and improve our documentation. Any remarks/requests for information concerning this document or topic are appreciated. Please email your comments to documentation@infor.com. In your e-mail, refer to the document code and title. More specific information will enable us to process feedback efficiently.

Table of Contents

| xxi

Chapter 1 Introduction

Infor ERP LN is a flexible, modular solution for the industrial enterprise with a primary focus on discrete manufacturers. The advantage of ERP LN is 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 ERP solutions are proven in many industries. This latest release, ERP LN, extends flexibility. Many enhancements have been introduced to simplify steps in carrying out business processes, reduce the cost of ownership, simplify implementation, and enable ERP LN to inter-operate with other systems across enterprises. ERP LN complies with many national and international business practices and legal requirements, supports multiple currencies and languages, and helps to build successful international operations in todays global environment.

Chapter 2 Enterprise Modeler

Introduction
Infor is unique in offering an integrated product suite that fully supports the typical stages in a business re-engineering cycle. Usually, companies reassess their goals and strategies so they can stay ahead of the competition. Therefore, companies must often redesign their organization, including processes and organization charts, and information technology infrastructure. The Enterprise Modeler provides what is needed to compete in the market place: the ability to redirect the processes and IT infrastructure towards the companies objectives and strategies to stay ahead of the competition. Although the Enterprise Modeling architecture describes extensive company processes, this does not mean a customer must go through this time consuming and process from scratch. Infor offers an Enterprise model designed and geared for almost every business process available in ERP LN. In the framework of the Dynamic Enterprise Modeling (DEM) concept, the implementation and initial setup of ERP LN is realized by the subsequent evaluation of the predefined model. 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 ERP LN solution, which effectively supports the business processes.

2-2

| Enterprise Modeler
The important message regarding these models is that best-practice vision and experiences of Infor consultants and partners are captured in the predefined model, which serves as a catalyst in the creative and innovative process of BPR. Using ERP LN Enterprise Modeler and dedicated model, the effort and time required for this evaluation process is significantly reduced. Therefore, when required, companies will not hesitate to reassess their ERP implementation without the necessity for a costly and time-consuming reimplementation. This provides the flexibility and speed companies require to follow the business dynamics with the IT infrastructure. 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, and 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 ERP LN application; 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 a training tool.

Enterprise Modeler

| 2-3

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

Business Control Models

Business Function Model

Main Process Flows

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 the following: Customers Sales offices Distribution centers Assembly sites Manufacturing sites Suppliers Central planning/purchasing sites

2-4

| Enterprise Modeler
The Enterprise Structure Model is as follows:

Between Enterprise Units, various types of relationships exist in terms of order flows, goods flows, 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 multisite managerial model from a financial perspective and a logistic perspective. Typical questions are as follows: What does the company consider to be one financial unit with bottom-line responsibilities, such as a business unit? What does the company consider to be one logistic unit that will be managed and controlled by Manufacturing Resource Planning (MRPII) concepts? In ERP LN, multi-site concepts provide the flexibility to define financial and logistic unit independently. The important part in the definition of this managerial model is the Enterprise Unit. By definition, an Enterprise Unit belongs to one logistic company and 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 rather than a physical view.

Enterprise Modeler

| 2-5

Level 2: Business Control Model

At an Enterprise Unit level, order and goods flows are planned, managed, and carried out. A Business Control Model (BCM) defines, on a high conceptual level, how the enterprise unit manages processes to realize the objectives of the company. A BCM shows the following: The primary industrial processes of the company. 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 objectives regarding throughput times, quality, and costs. The Business Control Model is as follows:

2-6

| Enterprise Modeler

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 ERP LN application. On this level, the following three submodels 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 regarding alternative methods to configure the workflow processes and ERP configuration, such as desktop and parameters.
Company ABC Mega/Major Function Text linked to Bus. Process

Main Function

Business Function options

Business Function Variants Optimization Relationship

Business Process Model (BP) This model defines the exact definition of the processes and where and when the appropriate ERP LN functionality must be invoked (mapping of ERP functionality to process definition). This model defines the work instructions on the process and process-step level, and roles required for authorization.

Enterprise Modeler

| 2-7

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, and then assigned to users/user groups and processes/process steps; this way, the processes are mapped to the companys organization chart.

2-8

| Enterprise Modeler
Organizational Unit Staff Department
Text by Organizational Unit Text linked to Org. Unit Unit

Subdiagram

Functional Relationship

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

Roles by Organizational Unit

Business Data Model Entity Relationship Model (ERD)

So far, the emphasis of the Enterprise Modeler was on process modeling rather than data modeling. This makes sense because companies objectives and strategies are realized by people and processes, not by data. However, data is an important source for processes. Therefore, in ERP LN, the Enterprise Modeler is extended with entity relationship models. These models serve the following purposes: Document the logical and physical data structure of the ERP LN applications. Reveal the data model part affected by the processes and ERP LN sessions. Support the IT/EDP staff in activities, such as data conversion and customizations. These models also support process teams during reengineering by opening the application box for a better understanding of the application strengths (IT as enabler).

Enterprise Modeler

| 2-9

The Data Model is as follows:

Functionality
Enterprise Structure Modeling in ERP LN
In ERP LN, 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 the following: Name and description. Logistic company.

2-10

| Enterprise Modeler
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 ERP LN 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 the following: Selection of processes. Configuration of these processes. Parameter settings. After you define the Enterprise Structure Model, the mapping on the ERP LN 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 ERP LN, 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, and therefore the 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).

Enterprise Modeler

| 2-11

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

Assembly control

Released FAS Order

Process Control Cycle

Goods issue

FINAL ASSEMBLY

For each process control cycle, one or more main-process flows (flow definitions in Petri-net, mapped on the ERP LN Applications) are designed. You must consider the Business Control Model, and the models process control cycles, as a context diagram that shows the business context of processes; 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:

2-12

| Enterprise Modeler
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 in Petri-net and mapped on the ERP LN 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 mainprocess) 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 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 design the process steps, best practices, options, and variants built into the process definitions, various alternative methods are available to use the ERP LN functionality in the processes, which are built-in as alternative routings through the main-processes. A customer must decide which alternative is appropriate for their situation.

Enterprise Modeler

| 2-13

The main-process is shown 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 is as follows:

One main-process per workflow case Represented by one main-function in function model What
Company Main Process Flow Mega/Major Function Select Processes Main Function

How

Wizards: Parameters Master Data Implementation Process Wizards Optimization

Static Conditions

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 ERP LN functionality. Therefore, on the lowest level of the process definition, ERP LN sessions are modeled. This can be seen as a real paradigm shift. Rather than presenting the ERP package module by module, the richness of the provided functionality can be shown by using the business process; this way, the business is leading. Discussing the process definition with the keyusers, the appropriate functionality is showed at the right time and 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, and therefore the process control cycle, are realized. The processes form the perfect vehicle for describing the ERP LN functionality and what it can do for the customers business. The processes form a starting point for generating the end-user environment.

2-14

| Enterprise Modeler
To document administrative procedures (ISO9000), which result 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 such as states, activities, and controls. Each activity is preceded and followed by a state. An activity can be an ERP LN session, a non-ERP LN application, a manual activity, or a (nested) business process. You can model business processes according to the Petri-net formalism. The components, and a number of constructions that can be used for Petri-net modeling, are described in the Dynamic Enterprise Modeling Manual. You can link job instructions, AO documents, and support applications 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 created in that activity. Support applications allow you to model clusters of sessions that can be used as auxiliary sessions, such as display sessions and print sessions, when an activity is being carried out. You can use a graphical display of a business process as a user interface rather than a menu structure. Therefore, you can choose by user for a menubrowser, a processbrowser, or both. 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. An important idea in this is the identification of roles in the company. A role defines which activities/tasks are usually assigned to one person or group when a process is being carried out. Also, the hierarchical and functional relationships can be described between the departments.

Business Data Model - Entity Relationship Models (ERM)

The graphical data model editor allows 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, which is as follows: 1:1 A one-to-one relationship.

Enterprise Modeler

| 2-15

1:n A one-to-many relationship. n:m A many-to-many relationship. Optional Signifies 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 that are comprised of several physical entities. Physical entity: Database table definitions of the ERP LN application.

Chapter 3 Production Typologies and ERP LN Scenarios

ERP LN 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 and the layout of the factory and material flow, as shown in the following figure:
Products & Volume
Many Products Few of Each Many Products Medium Volume Several Products High Volume One Product Very High Volume

Lay-out & Material Flow

Functional Lay-out Cellular Lay-out Repetitive Flow

Job-shop Production Cell Paced Line Flow Continuous Flow

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.

3-2

| Production Typologies and ERP LN Scenarios

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

Manufacturing Strategies
High
Flow lay-out

3
Process - Standardization Standard Production in Multi Model Flow Line Customer Spec Production in Mix Model Flow Line

Standard Production in Job Shop

1
Functional lay-out

Customer Spec Production in Job Shop

2 Low

Low

High
Product - Standardization

Manufacturing Strategy 1: Standard production in job shop

Manufacturing Strategy 1 has 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 quite independently. During production, each product can follow a different route through the factory. Production planning must create a balance between workload planning on work centers, order lead times, and inventory levels.

Production Typologies and ERP LN Scenarios

| 3-3

Manufacturing Strategy 2: Customer-specific production in job shop

Manufacturing Strategy 2 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 more favorable results 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 quite 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 components 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 usually shorter and materials comprise a higher percentage of the total cost.

Manufacturing Strategy 3: Standard production in multimodel flow line

Manufacturing Strategy 3 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.

3-4

| Production Typologies and ERP LN Scenarios

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 requirement. 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 mixedmodel flow line

Manufacturing Strategy 4 has the following characteristics: High-volume production of customer-specific products. High level of product and process conformity allows production in line. Line assembly control with sequencing and line station variants. Products are produced to customer order. No stock of end items exist, 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 requirement. 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, with 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 mainly consists of material costs. A strong incentive is present to shorten delivery times.

Production Typologies and ERP LN Scenarios

| 3-5

Mapping the Manufacturing Strategies to ERP LN 6.1

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

ERP LN 6.1 Manufacturing Solutions

High
Process Standardization

RPT

ASC

LES

SFC

SFC/PCS

Project

Low

High
Product - Standardization

Low

RPT is the Repetitive Manufacturing module in ERP LN 6.1 Manufacturing, which supports multimodel flow line environments. ASC is the Assembly Control module in the ERP LN 6.1 Manufacturing, which supports supporting mixed-model flow line environments. LES is the ERP LN 6.1 Lean Execution System, which supports production cell environments with lean manufacturing concepts. SFC is the Shop Floor Control module in ERP LN 6.1 Manufacturing, which supports standard and customer-specific production in job shop environments. PCS is the Project Control System in ERP LN 6.1 Manufacturing, which supports tracking and costing for customer-specific production in job shop environments. Project is the ERP LN 6.1 Project, which supports one-time, customerspecific projects.

3-6

| Production Typologies and ERP LN Scenarios

Hybrid Manufacturing
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. Therefore, different manufacturing strategies can be used for different items. The following figure shows various scenarios to set up the production environment in ERP LN 6.1:

Lean

Assembly Order ASC For End Prod. SFC Lean

Assembly based

RPT schedule SFC For End Prod. SFC Lean

Repetitive based

SFC order SFC For End Prod. SFC Lean Procurement KANBAN Lean For End Prod. Lean

SFC based

Lean based

ERP LN 6.1 Scenarios

The packages and modules mentioned previously are the key manufacturing software components that can best be utilized for each manufacturing strategy. 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 ERP LN 6.1 for each manufacturing strategy.

Production Typologies and ERP LN Scenarios

| 3-7

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, serves as input for the material and capacity requirements planning, performed by 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 carried out and reported complete in SFC, after which the end product is put on stock. Additionally, 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 shows this scenario:

Scenario for Standard Production in Job Shop

SFC
Sales Order - Forecast MRP / Cap planning Production Orders Scheduler Seq. /Capacity SFC -> Execution

3-8

| Production Typologies and ERP LN Scenarios

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 the Product Configurator (PCF). Based on the sales order product template or product variant, the PCS project is generated, which allows cost control and tracking for customerspecific 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-toorder 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 carried out in SFC, but the orders for the customer-specific items are directly related to the PCS project. Therefore, the progress and costs of the production orders can 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, 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.

Production Typologies and ERP LN Scenarios

| 3-9

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. Additionally, standard components might also be required. Both are planned by the order planning in Enterprise Planning. The advices from EP are transferred to Shop Floor Control, where the production orders for the PCS project and the standard components are carried out. 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 shows the two previously mentioned scenarios:
Scenarios for customer specific production in job shop

PCS Sales Order - (Forecast) PCS project Project planning -MRP Production Orders Scheduler Seq./Capacity SFC -> Execution

Project Project Budget Project planning -MRP Production Orders Scheduler Seq /Capacity SFC -> Execution

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, such as daily or weekly schedules.

3-10

| Production Typologies and ERP LN Scenarios

The production line produces rate based; the production advices in EP are adapted to this rate. The rate is determined by 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 implementation 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 allows minimal interaction for the operator with ERP LN 6.1. The following figure shows this scenario.
Scenario for standard production in multi-model flow line

RPT

Sales Order - Forecast Mixing / Cap planning Repetitive Schedule Sequencing / Capacity RPT -> Execution

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

The Lean Execution System (LES) is suited for both multimodel and mixedmodel 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 graphical boards, where the loads on the production cells can be leveled.

Production Typologies and ERP LN Scenarios

| 3-11

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, such as on an 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. Here, 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, implementation and progress monitoring is performed in ASC. The material supply is based on triggers coming from the assembly line. Costs for materials and hours are accounted for by 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

LES

ASC

Sales Order - Forecast

Sales Order Parts req. planning

KANBAN

Assembly Orders Mixing / Sequencing

LES -> Execution

ASC -> Execution

The scenarios described in this chapter for all manufacturing strategies are not fixed. These scenarios represent a common way of working according to best practices. However, various scenarios are supported for each strategy to create the best fit to customer-specific processes.

Chapter 4 Common

Introduction
ERP LN Common provides quick access to data that is shared throughout the ERP LN 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 to determine lead times and start and end dates for activities 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, such as on the resource itself, the calendar on a higher level will be used, such as 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.

4-2

| Common
This only allows you to define the exceptions on the lower levels, such as the holiday of an employee. The other working hours are inherited from the work center the employee works in. Additionally, you can define an exception as a recurrence. For example, because of maintenance, the work center is not available every third Monday morning. You can also split the calendar of a resource based on the activity for which the resource is used. If an employee is deployed 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
With unit effectivity functionality, you can define multiple occurrences, called units, for one item without having 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 exceptions. A unit is a system-generated number and consists of a user-defined series and sequence number.

Unit effective data

Exceptions can be linked to the data described in the following list. Therefore, 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.

Common

| 4-3

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 link this requirement to unit-effective data, such as BOM line and routing; this way, you can simultaneously assign multiple units. 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. The following figure shows the requirements to BOM lines:
Requirement 120 GB (units 1,2) Not Valid PC001 Valid Requirement 2.6 GHz (units 2,3) Units 1,2,3

120 GB Hard disk

80 GB Hard disk

Not Valid Valid

2.4 GHz Processor

2.6 GHz Processor

For example, this figure shows that Unit 2 consists of the BOM lines 120GB hard disk and 2.6 GHz processor.

4-4

| Common

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 selected for a specific unit can keep the unit information during storage in inventory. This unit code is linked to a lot number that 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.

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 also be calculated per unit.

Allocations and Hard Pegging

Allocations and Hard Pegging extends existing allocation and pegging concepts to allow the allocation of inventory/the hard pegging of supply order(s) to specific demand orders based on specific characteristics. The specification object contains the characteristics which extend the demand and supply objects for selecting and matching valid characteristics during the processes of characteristic based demand and supply matching. Character based demand and supply matching can be extended through the bill of material by the bill of material allocation and hard pegging flag. During the planning and demand supply matching processes, you can use inventory which has been preallocated, or select and allocate unallocated inventory by using the specification.

Common

| 4-5

Currently, there are four defined allocation and hard pegging types. Order Based Business Partner : Based on Business Partner and Order Number. : Based on Business Partner.

Customer Reference : Based on Business Partner and Reference Number. Internal Reference : Based on Reference Number.

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, such as temporary external purchasing. In addition to the item type, you can indicate if the item is lot controlled, serialized, unit effective/revision controlled. Additionally, you can also set ordering and costing-specific item parameters. For example, item ordering data indicates the order policy (to order or anonymous), the order system (supply mechanism, such as 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 default, you can also predefine the characteristics; 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/suppliers.

Business partners
Suppliers and customers are defined in ERP LN as business partners, because todays business extends beyond straightforward supplier customer relationships. Therefore, you can define supplier and customer roles for a business partner. Common practice is that a supplier uses, for example, an external party to ship the goods to your company, and the

4-6

| Common
invoice can be sent from a central office. Therefore, you can distinguish various roles for each business partner. These features let you define a network of business partners that you deal with to purchase or sell products. You can define affiliated business partners 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, for the logistic and financial flow between two logistical ERP LN companies. When you define supplier-customer relationships between sites in one logistical company with enterprise units, you can use internal business partners to support the logistic and financial flow between the sites.

Taxation
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, users can model every possible tax situation. 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 by the standard payment process. Besides tax reporting, European sales listings and European intrastat reporting are also available.

Terms and Conditions

The new Terms and Conditions module lets you set up terms and condition agreements in which all terms and conditions that are applicable in a particular situation between business partners can be stored. For example, in a Terms and Conditions agreement you can register the terms and conditions about the financial ownership of goods for a specific functionality. This functionality can be Vendor Managed Inventory (VMI)/Subcontracting. A Terms and Conditions agreement is linked to a Purchase Contract or Sales Contract.

Chapter 5 People

Introduction
You can use ERP LN People in a fully integrated ERP LN environment or as a stand-alone time registration system. ERP LN People supports the needs of organizations to capture time and expenses as spent by employees from business units operating in different environments. ERP LN 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).

Master Data Management (MDM)

The Master Data Management (MDM) module forms the basis of the ERP LN People application. The MDM module lets you register relevant employee information and codes to be used for general hours and expenses. You can also register information on roles, skills, rates, and surcharges that are part of the People (PPL) module as part of Common.

5-2

| People
The information on the employee to be captured by 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 separated into two types: absence and indirect. The MDM module also lets you capture assignments. These assignments are planned allocations of time you can use to speed up the hours registration process by loading the assignments on your timesheet. For example, this way you could define a recurrent meeting to show on your timesheet. User profiles cater to the need to preset several settings, such as what time period to default while starting the hours-entry screen. The Employees Dashboard allows 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.

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, team/employee.

People

| 5-3

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

Hours registration
The hours-registration function 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 as follows: General Tasks Project PCS Project Production Assembly (Field) Service Depot Repair The following are specific aspects of Manufacturing: Machine Time: For Manufacturing-related types and employee time, machine time can also be captured. Backflushing: The automatic accounting of hours spent based on the theoretical usage and 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. All entry sessions let you 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 copied to all employees in the team. Other features available as part of the registration options include the following: Use of Assignments: You can use planned allocation of time-recorded assignments as input for the hours-registration process and still make changes. Copy Hours and Expenses: Extensive copy options let you copy transactions for one employee to several others, or to other time periods.

5-4

| People
Global Registration: Global registration is best suited to deal with time spent as relevant for a wider range of employees, such as public holidays. The following figure shows a brief recap:

The purpose of hours-registration is probably the calculation of labor costs by employee. Processing the transactions results in the calculation of the following: Rates Surcharges The labor costs by employee will be posted to the following: Respective logistical packages Financials 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

People

| 5-5

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 origins, and lets you view the following: Hours Labor costs Various surcharges An Archive and Delete option is provided.

Chapter 6 Financials

Introduction
ERP LN Financials can be used in a fully integrated ERP environment and in a stand-alone financial setup. ERP LN Financials support the needs of organizations consisting of multiple companies or business units operating in different environments. ERP LN 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).

6-2

| Financials

General Ledger (GLD)

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

Multi currency
ERP LN supports accounting with multiple currencies. Up to three home currencies can be configured (one local and two additional reporting), and an unlimited number of transaction currencies. One currency system supports all general accounting principles such as IFRS/IAS and US GAAP.

Company structure
Financial companies can be consolidated in a group company. Companies within the same group can have different local currencies and reporting currencies. Multiple financial companies can be linked to entities of one or more logistic companies, which allows cross border multinational logistic operations. Intercompany transactions, including internal purchase and sales invoices, are automatically created.

General ledger structure

ERP LN Financials offers a flexible structure, with user definable ledger accounts and dimensions. Out of the ten dimensions stored in each GL transaction, five are fully flexible and user-definable. Parent child structures can be built for both ledger accounts (100 levels) and for the dimensions (10 levels). Dual GAAP features are provided through the option to define a second ledger account structure and the use of multiple home currencies. Usage of ledger accounts and dimensions 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 be defined. ERP LN Financials offers user definable financial calendars for statutory, management, and tax reporting.

Financials

| 6-3

Financial integration transaction mapping

ERP LN Financials offers extensive options to map logistic and financial transactions to ledger accounts and dimensions. For each logistic and/or financial transaction, the user can decide which elements, such as project, warehouse, item group, business partner group, and so on must be logged and mapped to ledger accounts and dimensions.. The mapping scheme is version controlled. Therefore, if the mapping is changed, correct auditing is still possible because it is always known to which mapping scheme version a transaction has been mapped to. During activation of a new version, the system checks the completeness and consistency of the setup, such as similar mapping on debit and credit side on interim accounts. 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 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, using default ledger accounts and dimensions. The architecture of the mapping scheme allows newly created transactions, either by ERP LN or an external application, to be mapped and posted without software changes to ERP LN Financials.

General ledger transactions

Journal entries can be automatically created or manually created. Automatic entries are created through integration transactions from the logistic modules or other financial modules; intercompany transactions and periodically generated transactions according to predefined setups, such as recurring and reversal transactions.

Reconciliation
ERP LN Financials offers a generic tool for auditing, analyzing, and reconciling the General Ledger back to the operations management source transactions. For each reconciliation area such as invoice accrual, work in progress, and inventory, the user can decide which elements must be logged to facilitate reconciliation such as project, warehouse, and item group.

6-4

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

General ledger inquiries and reports

Many inquiry options are available to offer different views on the general ledger history. The inquiries include actual balances, budgeted balances, and budget variances. Analysis is assisted through drill-down functionality from the top to the lowest (transacation detail) level and vice-versa. ERP LN offers many standard reports such as journal reports and trial balances. 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. ERP LN Financials enforces the correct 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 years opening balances.

Tax reporting
Tax records are logged in the Tax Analysis. Through inquiries and reports, the user gains understanding of 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 and tax code and country. Tax declarations can be generated and paid to the appropriate collection offices through the regular payment process; this process facilitates xmlreporting.

Accounts Receivable (ACR)

The Accounts Receivable (ACR) module handles and monitors sales invoices and credit notes. Additionally, the Accounts Receivable module handles credit checking, credit management, customer balance management, and generates interest invoices. Invoice corrections can be done and the credit notes can be linked to the invoices. It is possible to link credit notes to invoices of the child business

Financials

| 6-5

partner. Sales invoices that recur over the periods can be generated automatically based on the original sales invoice.

Multiple control accounts

Financial business partner groups can be created for groups of invoice-to business partners. The classification in groups is usually 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. It is possible to maintain multiple control accounts for a business partner group depending on the kind of sale made.

Payment schedules
Users can define a payment schedule to allow invoice payments on installments. Conditions such as payment dates, payment method, and payment discounts can vary by schedule line. Fixed assets can be disposed and/or sold through Accounts Receivable. Sales invoices belonging to the miscellaneous revenue originating from logistics, such as Service, PCS, and Projects can be registered. You can also register intercompany and intergroup sales invoices and credit notes.

Credit control
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 specific problem.

Factoring
You can factor the receivables to a Factor. If factoring is done without recourse, the receivables of the business partner will be closed and new receivables will be opened for the Factor. The factor will support the liability of the receivable. If factoring is done with recourse, and in case factor is not able to collect the receivable from the business partner, we are responsible to the factor and the amount they have paid for those invoices. Three-phase credit checking during order acceptance, release to warehousing, and shipment can be done. During the credit checking process, the business partners status, credit limit, and overdue invoices will be checked.

6-6

| Financials
Effective credit management can be done by maintaining the customer credit profile and allowing Credit analyst driven credit control. The business partners credit rating, credit limit, credit availability, and various document balances can be provided. The Credit Analyst functionality allows the credit analyst to monitor the amount of credit given to an invoice-to business partner. Credit analyst maintains credit diary. Using this, the credit analyst can 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 analyze and take action for the various business partners for whom they are responsible. Aging of the receivables into the various buckets can be done based on the days, months, or financial periods the invoice has remained open. The user can determine whether doubtful invoices and anticipated receipts can be considered for aging. Aging can be based on the invoice date or the due date. Reminder letters, known as dunning letters, urge business partners to pay their open invoices and can be prepared. These reminder letters are userdefinable. Different letters of severity can be used. If the business partner does not respond to the reminder letters sent, the system could automatically select more severe letters to remind the business partner 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/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. Depending on the number of days the payment has been delayed, different interest percentages can be defined per financial business partner group, Accounts Receivables Management is assisted 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 drilldown feature allows the user to zoom from the invoice to payment documents, sales order data, and the entries made in the General Ledger.

Financials

| 6-7

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, and 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. Doubtful sales invoices can be marked as doubtful and posted to a special ledger account for Doubtful invoices. Fully closed Invoices, 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 concerning a range of business partners, or the business partner credit profile that allows the user to compare a business partners outstanding orders and invoice amounts with their credit limits can be reported. Additionally, an analysis can be printed to show 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 including registration, invoice matching and supplier balance management. The Accounts Payable module allows writing off 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. When the payment has taken place, this currency loss/profit is posted as a realized currency loss/profit. Fully closed Invoices, 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.

6-8

| Financials

Multiple control accounts

Financial business partner groups can be created for groups of invoice-from suppliers. The classification into groups is usually based on certain common features such as the product or the type of business partner such as 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. Depending on the kind of purchase made, it is possible to maintain multiple control accounts for a business partner group.

Automatic invoice creation

The Accounts Payable module supports manual and automatic creation of invoices. Automatic invoices are created for internal trade (internal invoices) and self billing for supplier invoices. Purchase invoices can also be created by electronic data interchange (EDI).

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

Matching
Using the automatic three-way match functionality, users can match purchase invoices with purchase orders or freight orders. Additionally, users can manually match with the order, receipt.or consumption. Multicompany invoice matching is also possible, whereby one company processes purchase invoices for the group company.

Payment schedules
You can define a payment schedule to allow invoice payment in installments. Conditions such as payment dates, payment method, and payment discounts can vary by schedule line.

Financials

| 6-9

Payment authorizations
User authorizations can be set for price variances, additional costs, and payment approval. Full authorization history is maintained for purchase invoices.

Pay from receipt

ERP LN Financials also supports pay from receipt. A warehouse receipt triggers the automatic creation of a purchase invoice. Because this invoice is automatically matched and approved, the invoice is ready for payment.

Withholding taxes
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 the appropriate tax collection office. Purchase invoices can also be marked for 1099 MISC reporting to the IRS.

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

Dashboard
Accounts Payables Management is assisted 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 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 analysis
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 be based on the invoice date or the due date.

6-10

| Financials

Cash Management (CMG)

The Cash Management (CMG) module manages all cash related transactions, which 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 automatic payments, direct debits, and electronic bank statements. Different methods for processing the payments and receipts are supported such as 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 used throughout the Cash Management module such as bank relations, payment methods, data by bank/payment method, electronic bank statements, and so on. User authorizations can be defined for acceptance of payment differences, payment discounts, and bank costs. Additionally, you can set up maximum payment amounts by user or by 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. Additionally, 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. Different check formats can also be printed from system. The payment procedure section in the Cash Management module supports 1099 MISC-Income Payments. This provides 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, correction runs, and original filings can be performed. 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

Financials

| 6-11

payments, including remittance letters to specify the payment to the business partner. The receipt procedure in the Cash Management module allows automatic and manual direct debits from business partners. Open items 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, which provides commonly required information on a business partners payment behavior, is also available. 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 ERP LN 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. Cash Management in Infor ERP LN Financials supports Trade Notes functionality; it handles Trade Notes Receivable and Trade Notes payable. Endorsing and Discounting of Trade Notes Receivable is possible. It is also possible to use Trade Notes Receivable as Collateral. Bank credit can be used to make payment by borrowing money from the bank. To pay an amount more than the balance amount available in the bank, the organization can utilize the credit payment facility provided by the bank to the organization.

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

6-12

| Financials
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; these are used 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, using a multiplier, this data can be calculated into a new budget. Budgets can be linked through a distribution code so 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 must be calculated. The source accounts can be from the same budget or a different budget. Cost drivers are available to perform performance dependent budgeting; the cost driver is the base for calculating rates and surcharges. Budget amounts can be split into fixed and variable cost portions. 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 performed with the ledger account as the leading key, in which case the dimensions are specified; alternatively, it can be performed 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 using percentages and factors. Additionally, budgets can be defined as a percentage of a previously defined budget for a specific ledger account or dimension. Budgets can be combined so that some budgets are dependent on other budgets. Tree structures are allowed for budget dependencies.

Financials

| 6-13

Cost Accounting (CAT)

The Cost Accounting (CAT) module provides cost analysis and cost allocation functionality on a detailed and 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. Therefore 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 concerning the activity ratio (output) of a company. A 100% fixed or 100% variable is required, and any variance can be entered by the user for any dimension/general ledger account combination. These decisions are a base requirement for the results of the Cost Analysis. The Cost Analysis business object handles the actual amounts and performance quantities necessary to generate the deviations and 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. If the relevant dimensions have performance dependent budgets, actual performance quantities can be taken from the Hours Accounting module 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. 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 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. This cost analysis functionality offers the facility to copy the results to the cost price calculation

6-14

| Financials
master data of the Cost Price Calculation and Project Control System modules in a rule driven way. As for Inventory valuation analysis, Standard and Actual Costing methods are available to report the value of a companys inventory. Apart from the Fixed Transfer Price, the methods that can be used to value inventory based on actual purchase or production costs that 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 can 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. If a waterfall model is not sufficient for cyclic allocation relation nets, a repetitive method is used to determine the exact solution for allocation amounts: the so-called price iteration. The Cost Accounting module in ERP LN Financials also contains the functionality to perform Activity Based Costing. 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 can 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 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 modules 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, such as 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 companys fixed assets can be registered and managed. Financial transactions such as investment,

Financials

| 6-15

depreciation, revaluation, transfer, and disposal are posted to the general ledger. The Fixed Assets Management module supports different asset books for different purposes such as commercial, statutory, tax, calculator, and so on. 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. Location tracking can be done through a segmented location code. The location code can contain up to eight user definable segments such as country/city/site/building/floor. Location-wise cost and depreciations of an asset can also be obtained. Fixed Asset Management supports numerous depreciation methods such as straight line, declining balance, sum of the years digits, fixed amount, units of production, net book value oriented, annuity, and so on. Next to these predefined methods, customized depreciation methods can be defined. Depreciation methods specific to certain countries legislations are also addressed. 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, you can 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 ERP LN Project Assets can be revaluated based on indices. To assist efficient asset management, one central asset screen is available through which all relevant actions, including inquiries and transactions, on the asset can be taken. Reports are available to document entered master data and report all asset transactions. Also specific reports for registration, reconciliation, analysis, and tax are available. Invested Capital Overview and Depreciation Expense projection reports are available to print data on a periodic or yearly basis.

6-16

| Financials
Assets can be transferred or disposed by quantity or percentage. Disposed assets can be invoiced through the Sales Invoicing module. An additional depreciation called accelerated depreciation can be applied on assets for every year. The depreciation amount will be a percentage of the depreciation for that year, and can have a maximum value equal to the depreciation for that year. Depreciation can be posted to Non-GL asset books. Any such depreciation posted will be reversed when the asset is disposed. The cost of an asset can be reduced through the Cash Management module when there is a discount on payments for purchase invoices used to create the asset.

Financial Statements (FST)

In the Financial Statements (FST) module, user definable reports such as balance sheets, profit and loss statements, and dimension reporting can be generated for internal and external reporting purposes. Statement structures for ledger accounts and dimensions are defined in the Financial Statements module. Ledger Accounts, or groups of ledger accounts, can be translated to legal or statutory statement accounts. The FST module extracts data from the General Ledger and Financial Budget System, calculates the statement values such as periodical balances and year-to-date balances, and stores them. The Financial Statement can be generated in any currency and in combination with any currency rate; this allows the user to remeasure balance sheet amounts, using historical rates or, for example, closing rates. Also available is a consolidation functionality, linking individual statements and rolling them up, which allows the entry of statement adjustments transactions. The report layout, including Graphs, is defined in reporting for ERP LN. This application takes the prepared data from the financial statement values and prints the reports, optionally with specifications of the statement accounts.

Chapter 7 Project

Introduction
ERP LN Project provides Project Management solutions that allow general contractors, equipment suppliers, engineering firms, and other projectoriented companies to effectively manage and improve their business processes. ERP LN Project supports the project supply chain consisting of customers, prime contractor, subcontractor, suppliers, and other parts of project supply chain. The solution caters to the total lifecycle management of projects including 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. ERP LN Project is a highly integrated offering as part of ERP LN. It is integrated with Order Management, Warehouse Management, Manufacturing, Service, People, Financials, and Central Invoicing. Integration with Microsoft Word and Microsoft Excel is present for various calculations and reports. A seamless integration with Microsoft Project is provided to leverage the powerful and easy functionality of scheduling within Microsoft Project.

7-2

| Project
This includes the integration to Microsofts Client-Server based Enterprise Project Management offering of Microsoft Project ; this includes functionality such as centralized resource management through resource pools and centralized calendars. ERP LN Project supports all the business processes of Project Management, such as project-definition, estimation, budgeting, planning, baseline establishment, implementation, control, and closure. ERP LN 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). Additionally, a Project Dashboard is provided for a complete overview of each project. The following integrations show the integration between ERP LN Project and other packages of ERP LN, along with the integration in the various modules of ERP LN Project: Request for Quotation Order to payment

Project

| 7-3

Purchase

Engineering Product Engineering - w ith EDM (MRT, 6. MJS)

5.

Purchase Inquiry Management

4.

Process Engineering

7.

Account M anagement Customer Data Management

Supplier

Customer

Project M anagement

3.

2.

8. Project Estimating Process Oriented

Project Definition Process Oriented 1.

10.

Financial Planning & Budgeting 9. CHL11a: Request for Quotation (Process-driven Project) -----------------------------------------------1. Request for Quotation to be M anaged 2. Customer Data to be M anaged 3. Project to be Engineered 4. Purchase Inquiry to be M anaged 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 M anaged 10. Quotation to be Accepted

Financial Planning and Budgeting

7-4

| Project
Purchase 9. Purchase Order Entry Process Engineering Engineering 3. Product Engineering - Change Orders w ith EDM (MJS, MRT)

Project M anagement

4.

2.

Project Budgeting Process Oriented 6. Project Planning Process Oriented 12. 7. 8. Supplier Execution Control 13. 16.

5.

Project Definition Process Oriented

1.

Project Control Process Oriented

17.

Project Evaluation & Closing - Process Oriented 18.

11.

Project Administration

Customer Service Service Execution Control

14.

Warehousing Receiving Advanced 10.

15.

Store Goods

Picking - Advanced

Store Goods

Picking - Advanced

Inspection

Shipping - Basic

Goods Flow

Account Receivable Invoices

Credit Control

20.

Invoice Creation

19.

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

Cash M anagement Electronic Bank Statement Processing 21. Bank

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

Project

| 7-5

Project Dashboard
In project-driven companies, regardless of the role, all the users access Projects to complete 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 thing is common to all the users: to view the various phases of the project in one single overview. Project Dashboard is created to present a complete overview, from estimating, invoicing, to Project information in one session. Project Dashboard presents the following details (field values) in one window: Status. Contract Amount. Contract Type. Invoice Type. Holdback Percentage. Organization Breakdown Structure (OBS). 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. Forecast Revenues. Total Revenues. Cost Variance.

7-6

| Project
Cost Variance at Completion. Received amounts from customer. Paid amounts supplier. Customer overdue amounts. Overdue amounts to Supplier. Additionally, Project Dashboard provides access to all the relevant project information in one place. The Dashboard contains links to the most important sessions present in ERP LN 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.

General Project Tables (PDM)

This module provides the functionality to maintain project master data. The master data is the standard data used across all projects within the company. Besides the logistics tables and financial tables of ERP LN Common, this module contains the general data used in ERP LN Project. The features in this module are as follows: General Project Data. Standard Cost Objects. Buy From Business Partners Diskettes.

Project

| 7-7

Standard Revenues. Standard Structures. User-defined Structures. Project Templates. Standard Surcharges.

General Project Data

In General Project Data, the master data used in ERP LN Project is centralized for use across projects. Most of these tables are used for grouping, sorting, and reporting projects, and also as various dimensions for financial postings. Employees and trade groups involved in projects are defined here. You can also define an organizations responsibility matrix. In this matrix, you can assign the responsibility for certain parts of a project to the correct employees. The general project data consists of following tables: Acquiring Methods. Appointment types. Business sectors. Categories. Competitors. Document types. Financing methods. Groups. Phases. Employees Project. Responsibilities. Sufferance tax. Third party types/third parties. Trade Groups.

7-8

| Project

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 together. Five cost types of cost objects are available: Item: This cost object cannot be maintained in this business object, but can be maintained 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 using percentages and fixed amounts. For the labor cost objects linked to reference activities of ERP LN Service, you can directly update the prices from the reference activity.

Buy from business partner files

If a supplier can provide a file or diskette with item prices and discounts, this information can be imported; this allows you to define the relationship between supplier codes and your own codes, and also 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.

Project

| 7-9

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 ERP LN 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 template projects.

User-defined structures
Various additional structures 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. User-defined; Hierarchical. Organization Breakdown Structure (OBS). Currently, the first two types of User defined structures are only limited to estimating module, and are used for reporting purposes. Using OBS, you can define the various organization levels of your own organization, or of subcontractors, such as in a treelike structure. You can define various organization levels in an OBS, such as 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

7-10

| Project
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 administration costs of the project setup with the template functionality. A standard template is a project flagged as such. A standard template can contain all the relevant project setup such as project, structure, budget, and so on. While you create a new project, one of the templates can be used as a starting point. This is similar to copying a normal project, but, unlike normal projects, no costs or revenues can be posted on a template.

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 the following: 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/amounts. The user can also define an effective date and 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)

Project Definition provides the functionality to define a project contract with all the terms and conditions, and the definition of all the internal processes which will be used for each specific project. Any changes to the scope of the project are handled with the use of extension contracts, which contain practically the same information as a project.

Project

| 7-11

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 as follows: Scope Definition: Dynamic Menu. Project Data. Project Structure. Project General Data. 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 ERP LN Project. A dynamic menu is navigation to one project in a specific area, such as 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). This way, you can easier 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, and some can be performed independently.

Project Data
Master data for each specific project is stored in the Project Data business object. One central project table only contains the basic project data. Therefore, the user can use and access this table from ERP LN Project and ERP LN 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.

7-12

| Project
A project can be defined as a main project, a subproject, or a single project. With 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 only define two levels. You can choose whether 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, an internal project, or a template project. An internal project has no contract obligations to a business partner, and no revenue can be related to an internal project. Next to the internal project it is possible 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 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 ERP LN 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, and multiple contract sub-amounts with different currencies by customer by project are also possible. Advances on the customer can be split into 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 the following: Project/by cost type/cost object/cost component.

Project

| 7-13

Activity/by cost type/cost object/cost component. Element/by cost type/cost object/cost component. Extension/by cost type/cost object/cost component. 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/accounts. The relationship between projects in ERP LN Project and projects in ERP LN Manufacturing (PCS projects) can be defined. Project data can be archived or retrieved from the archives. You can choose whether to copy or move the project data to a separate archive company number, and which data groups must be archived.

Project structures
Use the Project structures business object to define the scope of the project concerning 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 a purely deliverable oriented structure 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 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 present in the

7-14

| Project
element structure. Here, it is recommended that you use activity structure wherever possible. Every activity structure is part of a project plan. Activity session is made a grid session. 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 the Project general data business object, such as third parties, employees responsible, appointments, documents, and locations.

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

Extensions
Extensions are used to handle uncertainties such 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 the Project Cost Objects 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.

Project

| 7-15

If cost components are used, each project cost object has a reference to a cost component. Global updates of prices and rates of project cost objects are possible using percentages, fixed amounts, and from standard cost objects. For the labor cost objects linked to reference activities of ERP LN Service, you can directly update the prices from the standard labor or the reference activity. Purchase contracts for the procurement of standard items used in projects can be defined here.

Project Revenues
Maintain the unique revenue codes for a specific project, project activities, or project elements in Project Revenues. These revenue codes can be used to combine revenues, such as cost-plus. Revenues can be posted to a revenue code (installments and advances). The revenue code can be used for the integration with ERP LN 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 in Project surcharges. If project specific surcharges are present, only the project surcharges are used and the standard surcharges are ignored.

Project Currency Conversion

Using the Project Currency Conversion 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 correct estimating and bidding will result in obtaining the project contract. The EST module provides the following functionality: Cost price estimation.

7-16

| Project
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, such as 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 a 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 ERP LN Object Data Management, you can link the documents. The new module is a base solution that fulfills the basic customer requirements and is a user-friendly and integrated piece of software. The features of estimating solution are as follows: Estimate versions. Estimate structures. Estimate lines, such as the following: Microsoft Project integration. Microsoft Excel integration. Aggregate amounts by PSE. Verify top-down estimate consistency. Bid. Launch estimate to budget. Message log.

Project

| 7-17

Estimate versions
An estimate goes through multiple changes and repetitions before resulting in a final bid. Many factors lead to the changes, which are either due to changes in scope by the customer or changes in the estimating process within the company. Usually, the changes could be due to progressive elaboration of the project scope. The best way to keep track of these changes is to use version control. Therefore, every estimate will be captured under a version and 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 supported by ERP LN 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 schedule estimations. Typically, a project life cycle 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 implementation, followed by service and maintenance. This is similar to asdesigned, as-planned, as-built, and as-maintained BOM. One of the structures can be used as a primary structure. Although only one primary structure exists, the project can have many other structures used for various purposes. An estimate undergoes multiple repetitions as described in the previous feature, Estimate versions. In each new version, the scope and 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.

Estimate lines
The estimate lines feature is the most important feature of the module, in which you can perform almost the entire estimating on one screen. In one estimate version, you can use 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 at total level or detailed level.

7-18

| Project
The user can define the estimate with or without cost objects, control codes, cost types, descriptions, and structures. You can also calculate the cost and sales estimates in the same version. Estimate lines at all levels only signify the amounts (cost & sales) for the primary structural element. Other structures linked to the lines are used for various views of the cost and sales information, which belong to the primary structure. Because bottom-up and top-down estimates can exist simultaneously, for each element of the primary structure you can choose which type of estimate must be used for the bid. Leading estimate type assists 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 on the estimate line or in a separate table. Include in scope option is used to specify whether the work represented by the estimate line is included in the estimate. This will affect the cost and sales price of the estimate. The main purpose of this field is to arrive at a final quotation based on customer choice to exclude parts from estimate. The flag will also serve as a workaround for alternatives. You can use adjustments, escalations, and contingencies to fine-tune 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 and provide estimating functionality.

Integration with Microsoft Project

The current integration between ERP LN 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 the estimate lines cost and sales dates. For cost, the activity start date releases the costs for an estimate line; for sales, the finish date sets the expected sales date.

Integration with Microsoft Excel

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

Project

| 7-19

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 use all the mentioned features and provide the possibility for the customers to reuse existing data. ERP LN 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 ERP LN Projects 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 ERP LN Projects estimate lines. You can create a range of records in ERP LN Projects estimate lines after calculation in Microsoft Excel of, for example, new estimate lines from Microsoft Excel. You can draw charts/graphs to provide a visual representation of the data imported from ERP LN Projects estimate lines, such as cash flow in the project. An additional feature of the Microsoft Excel integration is it offers integration with other industry-specific estimating packages. Many packages use the Microsoft Excel format.

Aggregate amounts by PSE (primary structural element)

When you conduct estimation at various levels you must get a summery view of 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 only for primary structure. Use this process session to calculate the amounts.

Verify top-down estimate consistency

You must ensure the amounts of parent and children are consistent, so the combined total of the children amounts do not exceed the total parent 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. Additionally, these warnings are given in a separate window, so that the estimating process flows on uninterrupted.

7-20

| Project
Therefore, a separate session is provided to verify top-down estimates, which provides an error report on all 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 for a part of the project structure, which means multiple bids can be created for one project. Additionally, 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 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. These Documents are the CAD drawings, project plan from ESP, scope documents, contingency documents, and so on, that are related to the bid in ERP LN Object Data Management. All the estimate lines of a version, which are included in a certain bid, are captured in the bid lines table.

Launch estimate to budget

The main feature of the launch estimate to budget function is to reuse all the data created during the estimating process for implementation. Another feature is the possibility of relaunching 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 of a structure, or a 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. Additionally, 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

| 7-21

Project Budget (PTC)

The purpose of the PTC 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: element-based and 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 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) modules features are as follows: Bottom-up Budget Element Budget 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 useful to analyze the cost patterns in a project. A budget line can have the following cost types: Material Labor Equipment

7-22

| Project
Subcontracting Sundry costs You can use cost components, such as 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 the Element Budget business object. However, the following differences exist: You cannot define a frequency between parent and child. Relationships cannot be multiparent. 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 the Activity Budget business object. Similar to 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 the budget adjustments feature to implement change control on budgets. After a budget is finalized, you can no longer modify the budget information; the only way is to use adjustments or extensions. The main difference is that adjustments cannot be invoiced to customers, but the extensions can be invoiced to customers. All the adjustments can be captured under various adjustment codes for better tracking and control under different heads.

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

Project

| 7-23

Budget Cost Analysis

At various stages in constructing the actual budget for your project, you will want answers to such questions as the following: 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? What amounts are budgeted for extensions or surcharges? ERP LN 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; 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. Additionally, 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 obtain these types of cost objects before project implementation starts. You can create a purchase budget by entering cost objects directly, or 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 and is used to bypass the step-by-step process of project budgeting and implementation.

7-24

| Project
General Budget Sessions
General Budget session functionality is used in the element budgets and the activity budgets. You can update the changed prices and rates in the actual budget with their latest values, and you can also update the budget dates and budget line currencies. 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 ERP LN People for project tasks The user can customize an item based on customer specifications using the integration with the PCS module of ERP LN Manufacturing.

Top-Down Budget
The user can budget in a top-down method instead of a bottom-up method. In the top-down method, the user can first assign a budget to a parent activity and distribute the budget to all the activitys 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 parents 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 let you 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 Planned Value or 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-25

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. ERP LN Project does not have the scheduling functionality, so the functionality in External Scheduling Packages (ESP) is used for project schedule development. ERP LN Project is integrated 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 in ERP LN Project or Microsoft Project and send it to the other system for the next process steps. You can only perform activity sequencing using relationships and constraints in Microsoft Project and import into ERP LN Project. The activity duration estimating using the resource allocations with resource calendars, leveling, and capacity analysis must be performed in Microsoft Project. The resultant activity start and end dates are transferred to ERP LN Project through the integration. The Project Planning module serves as the main interface between ERP LN Project and Microsoft Project 2002 to exchange the scheduling data. Various views of the actual project schedule will be available in Microsoft Project. The activities contain a lot of other information required for requirements planning, implementation, 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 the PSS-2 module. Features of PSS-2 are as follows: Plans. Activities (Scope Definition). Activity Relationships. Milestones. Integration with Microsoft Project. External Scheduling Links. Baselines.

7-26

| Project

Plans
Plan session is used to register plans. A plan is used to identify an activity structure and 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 projects scope into smaller manageable work packages; for more details, refer to the PDM section. The scheduling information of activities consists of 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 perform 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: Level 1 describes the components of the project to be implemented, 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 level 2, 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 implementation takes place at work packages. Planning packages are high-level budget and schedule planning and will eventually result into one or more work packages. Activities are arranged in 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. Additionally, an activity cannot have more than one direct parent.

Project

| 7-27

Activity Relationships
An activity relationship means a relationship between two activities or a relationship between activities and budget lines. Activities are sequenced regarding 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 on the completion of the task of the predecessor. Finish-to-finish: The completion of the task of the successor depends on the completion of the task of the predecessor. Start-to-start: The initiation of the task of the successor depends on the initiation of the task of the predecessor. Start-to-finish: The completion of the task of the successor depends on 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.

Integration with Microsoft Project

The main function of using Microsoft Project is to determine scheduling information for work packages and budget lines. The main function is also used to determine the expected cost date and expected sales date fields of estimate lines. All the resources, including cost objects, employees, trade groups, and calendars present in ERP LN, can be transferred to Microsoft Project for use in scheduling. The activity structure and activity relationships are transferred to Microsoft Project, and form the basis for scheduling. The activities in Project can be divided within Microsoft Project into several subprojects. Therefore, for each cost account, you can set up a different schedule in Microsoft Project. Additionally, a user can schedule a range of cost accounts, such as all cost accounts related to an organizational unit, in one project in Microsoft Project. Microsoft Project offers the following functions: Use of activities, precedence relationships, resource lines (budget lines in Project terms), and calendars. Maintaining WBS.

7-28

| Project
Network planning. Resource Leveling. Capacity analysis. Multiproject planning with distributed projects. Recording and displaying the baselines. Modern windows functionality, including user defined-columns, filters, and so on. In Microsoft Project, you can detail the lowest level activities from ERP LN Project for the benefit of scheduling. One or more Microsoft Project activities can be linked to a work package of ERP LN Project.

External scheduling links

In external scheduling links, the various Microsoft Projects projects linked to ERP LN Project, and the top linked activity, are stored. The user can manually delete the link; however, Infor does not recommend this. The correct way to disconnect the integration is from the disconnect process from Microsoft Project.

Baseline
The baseline can be seen as a snapshot of the project schedule, and 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 baselines. Whenever a new base line is planned for the project, this signifies the scope of the project has deviated considerably from the original plan and that the previous baseline is no longer relevant. You can also save baselines in ERP LN Project from Microsoft Project. For performance measurement, you must store one or more base lines.

Project Requirement Planning (PSS-6)

The Project Requirement Planning (PSS-6) module offers the functionality to generate/maintain recommendations for material, equipment, and subcontracting during the project. The recommendations are divided into purchase orders and warehouse orders and, after you confirm and transfer these recommendations, this recommendation will be transferred to the Purchase Control module and ERP LN Warehouse Management. Another

Project

| 7-29

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. The PSS-6 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. Additionally, 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 also generate service orders for free budget. Therefore, generating control data is unnecessary. This provides the advantage of advance notification to Service for planning purposes. The actual implementation 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 ERP LN Project from the purchase, warehouse, and service orders. The features of the PSS-6 module are as follows: 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.

Generate planned orders

With the generated planned orders feature, you can generate or regenerate planned orders from the Project Technical Calculation (PTC) and 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

7-30

| Project
Rent equipment Mobilize subcontractors The orders are generated based on the start date of the activity budget lines. If these are not present, then it uses the activity or element start date; if this is also empty, it uses the project start date. You can divide all orders generated into the following three types of orders: Material recommendations Equipment recommendations Subcontracting recommendations Material recommendations are subdivided into the following: Purchase Orders: Orders for items that must be purchased by ERP LN Order Management. Warehouse Orders: Orders for items handled by ERP LN Warehouse Management, which are further divided into the following: Orders for standard items that have inventory in any of the warehouses; this depends on the way the warehouse clusters are setup. For standard items, Infor makes a warehouse reservation when you enter a planned warehouse order or confirm a planned warehouse order. When this reservation will be made depends on a parameter. Orders for customized items produced by ERP LN Manufacturing that will be stored in a warehouse. Equipment and subcontracting recommendations always result in purchase orders. 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, ERP LN creates planned orders with a reference to that contract. If budget/ 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

Project

| 7-31

displayed. The request for quotations and manually entered purchase requisitions are also captured and displayed here.

Planned purchase orders

Use the planned purchase orders feature to plan purchase orders and transfer the orders to ERP LN Order Management. You can create these orders from the Generate Planned PRP Orders process and also manually enter the orders. All the planned PRP purchase orders must be approved before transferring the orders to ERP LN 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 combine multiple PRP purchase order advices with other purchase advices to create one purchase order, using the commingling feature present in ERP LN Order Management.

Planned warehouse orders

Use the planned warehouse orders feature to plan warehouse orders and transfer them to ERP LN Warehouse Management. You can create these orders from the Generate Planned Orders process and also manually enter the orders. All the planned PRP warehouse orders must be approved before transferring them to ERP LN Warehouse Management. You can combine multiple PRP warehouse orders into one warehouse order to save a lot of administrative work involved for processing each warehouse order.

History of PRP order

You can see the history of all purchase and warehouse orders delivered at a project warehouse or a project site. All 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:

7-32

| Project
Handle the contract lifecycle, including warranty and maintenance. Perform project-driven organizations, including installations. Unlike PRP purchase and warehouse orders, no planned service orders are generated; therefore, no approval step is required. Here, you will directly create a service order in ERP LN 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 ERP Service.

List of service order links by project

Use the list of service order links by project 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. You can view the status, activities, and start and end dates of service orders.

Project Progress (PPC)

The Project Progress (PPC) module contains functionality to measure, register, and monitor the progress, cost, and revenues during the implementation 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 ERP LN 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 recorded in Project Progress (PPC) with regards to the project budget. The Project Monitoring part is described in the following section. The features that belong to PPC Progress are as follows: Progress: Progress offers the possibility to maintain the project progress for all cost types, at various levels, including activities, elements and extensions.

Project

| 7-33

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 manually perform this procedure. Financial Results: This feature is intended to take profits, losses/financial reservations during the implementation of projects, such as at the closing of the financial year. The final result is taken when the project is closed. Extension Transactions: Project contract quantities, prices/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. Processing: This feature lets you send the costs, revenue, extension transactions, and financial results to project history and ERP LN Financials. The costs and revenues from ERP LN Financials and the revenues generated by ERP LN Central Invoicing are also processed.

Progress
The progress of a project can be registered for the following: Elements: element, element/cost type, and element/cost object. Activities: activity, activity/cost type, and activity/cost object. Extensions: extension/cost type and 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 also register progress on element budgets, while your generated control data is based on activities. However, if your generated control data is based on elements, you cannot register the progress of activities.

7-34

| Project
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, such as 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. For an ERP LN 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 ERP LN Project project. After the progress is recorded, it can be processed to Project Monitoring. Additionally, invoicing can be carried out based on the progress of the project.

Costs
Use Cost and commitment session 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/commitments can be entered manually, or are a result of the following: Registering hours in ERP LN People. Purchase orders in the Purchase Control (PUR) module of ERP LN Order Management. Transferring project inventory or anonymous inventory from a project. Warehouse to a project. You can perform this procedure in ERP LN Warehouse Management. Costing the lines of service order or service order activities linked to projects in ERP LN Service. All the costs of service order and its activities will flow into labor cost object. The Accounts Payable (ACP) module in ERP LN Financials. You can register costs for all cost types. Each cost line 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 manually entered 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.

Project

| 7-35

Every placed order or registered receipt can be a commitment, and is recorded in the commitment accounting system until the corresponding invoice is entered. 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 ERP Financials or ERP Order Management, ERP Warehouse Management, or ERP Service, then these transactions will be automatically created. The template of surcharges (percentages) applied to registered costs can be defined by project, cost type, cost object, and cost component. Depending on the extension definition, extensions are included or excluded. Project costs can also be booked from the Accounts Payable module in ERP Financials to ERP Project. For example, an invoice with project-related costs is directly entered in ERP Financials without intervention from ERP Purchase. You can maintain forecast for final results and store information by date. Hours entered in the ERP People package are 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 a provisional amount, the invoicing depends on the actual costs registered.

Cost Forecast
You can forecast the costs that would be incurred on the project 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 manually entered, this parameter determines whether the changes to the budget or the ETC are calculated.

7-36

| Project

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 ERP Central Invoicing, the project revenues will be automatically available. Surcharges can also be applied to revenues. Additionally, you can maintain the forecast deviations of the revenues by element and activities against the contract; 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 lets you 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 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. It is often used for projects without hardware deliverables, such as engineering or development projects. The percentage of completion is manually entered or is the result of the costs divided by the estimate at completion. The revenue recognition Milestone method is based on the completion of milestones. It is often used for projects without hardware deliverable, such as engineering and development projects.

Project

| 7-37

The revenue recognition method Reimbursement Contract is based on actual costs transactions and their sales value, and is 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 manually enter the ERF, 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; these are invoiced revenues, expected revenue, and forecasted revenues. To calculate the cost of goods sold, you can use the following methods: Profit Percentage: This total cost of goods sold is based on the recognized revenues and a profit percentage. This method is often used for projects without hardware deliverables, such as engineering and development projects. COGS = Total Revenue Recognized to date * (1 profit %) In other words, the revenue is calculated and then the costs of goods are calculated based on the recognized revenue and profit percentage. Reimbursement Contract Calculate the total accrued costs, including the unbillable costs and unpaid transactions, which are the costs that originate from unpaid purchase order invoices. Apply the overhead using the surcharges on the incurred costs. 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 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.

7-38

| Project
If quantities, prices/the time spent varies, PPC can signal any deviations and generate the basis for invoicing the fluctuations. The project forecasts and registration of relevant project information will be handled. The expected forecast deviation of costs can be recorded. In the extension settlement, various types can be distinguished, such as index fluctuations, price fluctuation settlement, quantities to be settled, and provisional amounts. Index fluctuations means a percentage of the contract price can be settled according to price indices. The billable amount is based on invoiced installments or the progress. In the price fluctuation settlement procedure, the data for the price variations, such as wage fluctuations, can be registered and maintained. The results of the procedure are generated invoices with the billing of price variations. These invoices are processed by the 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 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.

Processing
Costs, commitments, and revenues must be confirmed before processing. After you confirm these factors, they are processed to Project History, Project Monitoring, and ERP LN Financials, and allow 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 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.

Project

| 7-39

A wide range of selection criteria ensures the correct data is presented to the correct people. For example, including or excluding expected costs (commitment accounting) for the current or cumulative period, and with or without final result forecasts. Additionally, you can see the estimated cost for the end of a project while the project runs. Features of PPC Monitoring are as follows: 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 are the main feature here. You can make reports for the current period and also for periods in the past. Financial Analysis (Graphs) This feature provides the functionality to display costs and revenue graphs, and performance indicators. Performance Measurement Provides data and reports required for effective analysis of variances. Performance measurement results from comparing the following: Planned Value, also known as Budgeted Costs of Work Scheduled (BCWS) Earned Value, also known as Budgeted Costs of Work Performed (BCWP) Actual Cost, also known as Actual Costs of Work Performed (ACWP) Estimate To Completion Estimate At Completion

Build Actual Cost Control

The permitted and actual cost calculation 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.

7-40

| Project

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 the following: Project, project/cost type, project/control code, and 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 follows: 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. A large number of reports are available to meet the organizations requirements, such as project control with references to purchase, and warehouse orders and the status of these orders. ERP LN allows the user to easily drill down to the desired level of cost control.

Financial analysis (charts)

Use the financial analysis session to create a chart of the progression of costs and revenues during the project implementation 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 chart shows a cost line and a revenue line; both lines consist partly of actual amounts and planned amounts. Before the reference date the actual costs and actual revenues are shown. After the reference date, the planned costs, revenues, and forecast are shown. The purpose of the financial analysis is the following:

Project

| 7-41

Liquidity forecasting. Performance measurement. Two types of charts are available on Worktop and Web UI, depending on the method of monitoring used: Financial Analysis. Performance Measurement using EVM. The following table lists the fields, and their interrelationships, that appear in each chart: S.No 1 2 3 4 Control Inquiries concept Planned costs (budget) Actual costs Permitted costs (progress) Forecasted costs Earned value concept Planned Value or BCWS Actual Cost or ACWP Earned Value (EV) or BCWP ETC

S.No 1: These costs are the budgeted costs and 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). S.No 2: The actual costs posted to the project history. S.No 3: Determined on the 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 compare how much work has actually been completed against the amount of work planned for completion.

7-42

| Project
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 Planned value. The budgeted costs of work performed (BCWP), the Earned value. Actual costs of work performed (ACWP), the Actual cost. Budgeted costs at completion (BAC). Estimated costs at completion (EAC). Schedule Variance (SV), and the permitted costs minus planned costs (BCWP-BCWS). Cost Variance (CV), and the allowed costs minus planned costs (BCWPACWP). These performance measurement values are generated on four levels: Activity. Activity/cost type. OBS element. OBS element/cost type.

Project Invoicing (PIN)

The Project Invoicing (PIN) module collects, prepares, and provides invoice data, with the purpose to transfer this data to the Sales Invoicing (SLI) module of ERP Central Invoicing package. Several invoicing methods are supported. The 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. Additionally, the generic features such as discounts, VAT, and late payment surcharge are processed in Sales Invoicing. The PIN modules features are as follows: Advance Payment Requests Allows you to define advance payment requests.

Project

| 7-43

Installments Allows 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 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 Project Project - Fixed price contract - Cost plus Methods Installment, progress invoice, unit rate Unit rate, cost plus Contract amount, budgeted costs, actual costs Actual costs

Extension - Variations Extension - Provisional amount Fluctuation settlement Quantities to be settled

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 and installment amounts. To register the amounts, you can use a ratio of distribution based on points or percentages. With points, a total number of points is assigned to the project; these points are distributed over several installments and each point represents a proportional part of the contract amount. The use of percentages is based on the same principle.

7-44

| Project
You can make the moment of invoicing for the remaining installment amount dependent on completing an activity or a milestone. Normally, each installment will result in a new invoice. However, you can combine installments into one invoice because installments are linked to Milestones, which are reached at the same time.

Progress invoice
The progress invoice concerns a special way of installment invoicing, in which the installment amounts are based on the actual progress, and the sales rates are based 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 that can be directly charged to a product or service are budgeted; 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 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 the basis of the progress (quantity) of the element or activity, or on the 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 E12 E21 TOP Quantity 110 5 50.000 Sales Rate 16 200 60 Total 1760 1000 3000 Settlement Price 20 Progress 40 2

Project

| 7-45

The billable amounts are as follows: E12: 16*40 = 640 E21: 200*2 = 400 TOP: 3000*(640/1760) = 1091 Example settlement of variations: Suppose 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 sales rates of the elements or activities.

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) are defined by cost type in Project Definition (see PDM). When the margin percentages are empty, 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
Extension-contract amount concerns a single invoice with the total amount recorded for the extension.

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

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

7-46

| Project
Advance payments
An advance payment is an agreement between the customer and contractor, and is 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. Additionally, 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.

Holdback
Holdback or retainage means a part or percentage of the invoice is paid when the job is completed. The amount is, for example, held back as assurance for the quality of the work. This amount is determined by taking the percentage, which is recorded in the Project Definition (PDM) module, and applying this percentage to the invoiceable lines. Holdback can be applied to all invoicing methods.

Integration with Sales Invoicing

The Sales Invoicing module of 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, discount settlement, and processing late payment surcharge and terms of payments are centralized in Sales Invoicing.

Chapter 8 Enterprise Planning

Introduction
Enterprise Planning performs and controls the planning process in 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 ERP LN Enterprise Planning in more detail; it also 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).

8-2

| Enterprise Planning
The following figure shows the relationship between these modules:

Planning Parameters

Planning Master Data

Define Demand Plan

Planning Horizon
Master Planning

Order Planning

Plan Analysis

Adjust Planning

Plan Transfer

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. Additionally, 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. This allows you to forecast and plan in small periods on the shortterm, and in larger periods in the longer-term. You can define the scenario as rolling, which will periodically redivide the scenario-planning horizon in plan periods starting at the current date. This offers a consistent period division for the planner as time passes.

Enterprise Planning

| 8-3

You can copy 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 allows 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 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 by production, purchase, or distribution. When you select the default source production/purchase, the actual source is determined by the Date-Effective Item Data session. You can also define the horizons to generate planned orders and plans for each plan item. Additionally, you can define whether the plan item has an item master plan, and also 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/ disaggregated between a family plan item and its child plan items, 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 manually insert the critical materials and capacities, 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 you define in ERP LN 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 resources directly in Enterprise Planning.

8-4

| Enterprise Planning

Plan units
You must set up plan units 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 allows 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 Sourcing Strategy: This determines if the item is produced, purchased/ distributed. You are not required to define a sourcing strategy; if the sourcing strategy is not defined, the default source from the ItemPlanning data is taken. The Supply Strategy: This determines the rules that specify which suppliers and warehouses must be selected for purchasing and distribution. 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; if no supplying strategy is applicable, they are 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.

Enterprise Planning

| 8-5

Item planning
You can generate the master planning for an item; based on the demand, this will create a production plan, purchase plan/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. Additionally, 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 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 calculate plans in the short-term, which can be required when you run the master planning in finite mode using workload control. An item master plan is mandatory if you want to generate the master planning for a plan item. The resulting production, purchase/distribution plan can be viewed in the item master plan. Also, 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 automatically generated. 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 to aggregate or disaggregate data between family plan items and child (family) plan items. Forecast, inventory plans, and production and purchase plans can be aggregated or disaggregated, and also planned orders, actual orders, and inventory on

8-6

| Enterprise Planning
hand. You can define aggregation or desegregation percentages for each data type. The item master plan contains available-to-promise figures 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 are calculated by 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. Also, 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, such as all customers in a region. You can maintain forecast and compare the forecast with actual sales in the channel master plan. Also, you can maintain allowed demand per channel. The allowed demand represents the part of the central production plan assigned to a certain channel. Based on the allowed demand, the channel available to promise is automatically calculated to support order promising. Forecast and allowed demand can also be automatically calculated using 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

Enterprise Planning

| 8-7

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 using order planning. Based on the source of the plan item, the order planning run creates detailed planned production, purchase/distribution orders for the short and middle term, depending on the order horizon 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 purchase schedules rather than (planned) purchase orders. Purchase schedules support high-volume, repetitive purchase supply based on contracts. When an item is ordered through 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 suppliers delivery patterns. The planned production orders results in capacity use of resources. For each resource, you can view the detailed capacity utilization based on the order planning in the resource order plan and compare it with the available capacity. Also, 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 order planning. You are not required to control a plan item with master planning to create an item master plan. This feature allows 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 use another type of forecast called special demand. Consumption of special demand by actual sales demand is supported. To define special demand, an item master plan is not mandatory; 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. Therefore, an item master plan is 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 techniques to support order promising. The components and capacities to be checked for CTP are part of the bill of material and

8-8

| Enterprise Planning
routing. You can 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 masterplanning run using the plan analysis. The analysis consists of signals and performance indicators. A signal represents a warning for the planner that a particular element, such as 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, and 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; 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 master planning; also, signals can also apply to a plan item or a resource. Signals created for planned orders in Enterprise Planning can be automatically processed after evaluation by the planner. For example, a reschedule-in signal that is automatically processed, 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, purchase department, and warehouse. Often, the orders from this point onwards are handled by individuals other than the planner, such as shop floor planner, buyer, and warehouse manager. However, the planner still controls the total plan through the planning views, including the actual order information, and the signals still generated for the actual orders, if required.

Enterprise Planning

| 8-9

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. From that point onwards, the business procedure for these planned orders will 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/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. In this view, you can still decide not to transfer particular orders before you actually transfer to production, purchase, and warehousing. Planned production orders and production plans 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 using 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.

8-10

| Enterprise Planning
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 used during the order planning and master-planning run. You can set up the way that parallel processing is carried out. Parallel processing means 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.

Chapter 9 Order Management

Introduction
Order Management supports the entire sales and purchase process from start to finish. A lot of functionality is available, including the following: Pricing: purchase control, requisitions, RFQs, contracts, schedules, orders, and vendor management. Sales Control: quotations, contracts, schedules, orders, commissions, and rebates. Relation Management.

Important master data for Order Management

When conducting business, users are faced with 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 ERP LN.

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

9-2

| Order Management

Sales office
The following are characteristics of sales offices: Sales representatives can be assigned towards a sales office. A sales office is a criterion for price agreements. A sales office retrieves defaults about the applicable warehouse, order series, quotation series, and contract series. A sales office can be used as a selection criterion for printing reports.

Purchase office
The following are characteristics of purchase offices: 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 used 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 Buyers Dashboard, and one for an account manager, known as the Relation 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, promotions and discounts, and purchase prices and discounts. The main enhancement is the flexibility of defining prices & discounts that allows 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 allows you to make prices & discounts based on quantity or value, and simulate the changes before you make decisions. Prices for configured items are handled in the PCF module. Prices for kits can be handled, plus 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 of value or quantity. Discounts are stored in discount schedules. Discount schedules are broken down in order of 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 is applied. Attributes can be a combination of business partner data, item data, and order data. Order and line item discounts are available. The Pricing application allows 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 are available to automatically increase or decrease prices or discounts. Simulation capabilities to support what if scenarios are available.

9-4

| Order Management

Sales Control
Sales Control can handle the entire sales order fulfillment process, including the control of quotations, contracts, schedules, orders, and commissions and 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. You can also maintain the alternative item codes by alternative code system, customer, or item. The companys 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 the order acknowledgement. You can also specify values used when new sales orders are created, such as order type, warehouse, or order series. You can define various order types; each order type defines the mandatory steps in the order procedure and if the steps will be performed automatically or not.

Sales quotations
You can manually type in sales quotations 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 ERP LN, you can print it and send it 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 and 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.

Order Management

| 9-5

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 equals at least 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 item, and also print and delete the quotation history.

Sales order entry

You can manually create sales orders or create them through E-Commerce (EDI and Internet). Sales orders can be copied from another sales order and also from history; copying is performed using copy templates. In a copy template, you can define which attributes of the new sales order should be either (1) copied from source order, (2) defaulted by ERP LN, or (3) specified by you during copy implementation. Every sales order is associated with an order type. The order type allows 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, and a return order only contains negative quantities. Items sold on a collect order are issued from inventory immediately on order entry. A sales order is entered in a system in an easy way, with 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 Infor Configurator is available for assemble-to-order environments. Product substitution and replacement is also supported, particularly for industries with short product life cycles. During order entry, many processes are initiated, such as: Credit checking Margin control Price and Discount calculations Available to Promise and Capable to Promise checks

9-6

| Order Management
Inventory Commitment Order-blocking checks

ERP LN supports the postponement of inventory checks and shortage handling until after the sales order is created. Specifically, you can save sales order lines with plan items that have insufficient ATP/CTP. These lines can be handled for shortages at a later point in time. This process can be manually carried out or carried out in a batch. ERP LN 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 EDI. Functionality for return management has been extended; you can now link a return order to the original document, such as an order number, shipment ID, or invoice number, which also allows 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 the customer will accept multiple shipment/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. Depending on a parameter, a purchase order is directly created or manually created later. This purchase order is delivered directly from the supplier to the customer. After processing, the purchase order sales order that initialized the purchase delivery can be processed and invoiced. Sales orders can 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. Self-billing facilities are also 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 to the sales invoice such as freight costs. Change management of order is supported by the use of predefined change reason codes for display, reporting, and analyzing purposes.

Order Management

| 9-7

To analyze the order entry process, 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. 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. 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 manually entered or automatically generated by CRM or EDI. When the user clicks the icon to check the sales order, the status is Approved; therefore, the order header changes from Free to Approved. When the order status is Approved, it is ready for implementation. This means that if the first activity on a line is set to Automatic, the activity will be performed immediately. The order header receives the status In Process when one of the activities is performed. 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. Therefore, a cancelled order is not available for implementation. The order header status is Blocked if blocking checks are applicable and 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 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 are based. From global to detailed, you can record agreements on various levels such as customer, relation, agreement group, project, item, and commission/rebate group.

9-8

| Order Management
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 postpone a calculation, such as by performing a calculation as a periodic process; this can be useful if multiple agreements are based on cumulative sales. If you need a reservation procedure, and a link exists to ERP LN Financials, reservations are transferred to Financials. Approval procedures are applicable. Reservations for calculated commissions for employees are always transferred to ERP LN Financials. History of commissions and rebates is immediately created during the calculating procedure, and 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, such as an approved supplier list. Purchase Control also allows you to define multiple manufacturers for each item/supplier combination. Manufacturing part numbers can be defined and used in purchase orders, requisitions, RFQs, and purchase contracts. You can also register receipt tolerances for each item group, item, supplier/item, supplier, and supplier group. These tolerances are used in Warehouse Management to determine whether a receipt quantity unequal to the order quantity is acceptable.

Order Management

| 9-9

You can also maintain profiles of user-specific default data. Users can type default values to specify the method of order entry they prefer. Additionally, you can define some values that will probably be used when new RFQs or purchase orders are created as default values, such as the warehouse, order series number, and order type. Order types determine the steps that must be carried out and whether they will be carried out automatic or manually.

Purchase requisitions
The purchase requisitions functionality will be the front end of 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 describing the item. A requisition can result in an RFQ, a contract, or a purchase order.

Purchase RFQs
RFQs can be sent to various suppliers. You can enter the quotations sent by suppliers into ERP LN. Together with the vendor rating data, the information presented allows you to select the most suitable supplier for the items on the inquiry. Based on existing price information, additional information appears; this allows 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, ERP LN 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 related to created inquiries, copied inquiries (into an order or contract), and deleted inquiries is available.

9-10

| Order Management

Purchase order entry

You can manually create purchase orders or generate them 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 history; copying is performed using copy templates. In a copy template, you can define which attributes of the new purchase order should be either (1) copied from source order, (2) defaulted by ERP LN, or (3) specified by you during copy implementation. Every purchase order is associated with an order type. The order type allows 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 a regular purchase order which can be workflow-enabled. A cost order only contains cost and service items, but a return order only contains negative quantities. Items bought on a collect order are added to the 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 or send it by EDI to the supplier. Purchase orders are released to Warehouse Management, where a global receipt function is available. If the actual delivered goods do not match the packing slips in Warehouse Management, you can send a report (claim note) to the supplier and print reminders if deliveries are late. The user can also add additional costs to the purchase order, such as freight costs. 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.

Subcontracting
The entire production process of an item can be subcontracted. It is also possible to subcontract some operations of an existing production order. To subcontract the entire production process of an item, it can be indicated as a subcontracted item. For this item, enterprise planning generates a

Order Management

| 9-11

subcontracting purchase order. The components that must be sent to the subcontractor are stored as material supply lines on the subcontracted purchase order. It is also possible to subcontract operations of production orders. In that case, a subcontracting purchase order with material supply lines is generated from a production order.

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 receiving from a specific supplier. For more information, see Purchase item and master data. ASL allows you 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 criterion can be rated by giving a weighting factor expressed in a percentage.

Relation Management
The Relation Management module is designed to place the focus on managing customer interactions of your company. The module supports next to relation management in general, the complete opportunity management process with easy access to the required information for the sales representative and a direct integration to quotations. It is possible to create activities which help in managing the interaction with the customer(s). Activities are created helping to manage opportunities, business partner or activity lists for an employee or a contact. Contacts and activities (appointments, calls) are synchronized with MS Outlook. To manage on characteristics of business partners, contacts, activities and opportunities which are not part of standard LN, you can define additional information fields through the use of attributes or attribute sets.

9-12

| Order Management

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, such as to support special promotion actions. Therefore, you cannot define two normal contracts that are both valid simultaneously for the same business partner, even though it is permitted for special contracts. If preferred, 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 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

Order Management

| 9-13

Other relevant data 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 way 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 when 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 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 used as input for this type of schedule, must be entered. The pricing data is also relevant for contracts 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

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. If no itempurchase 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

9-14

| Order Management
to determine whether multiple or 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 that indicates if changes are permitted in the short-term demand of the purchase schedule. Capacity-related information, such as the supplier capacity. Lead-time information, which is used as input for Warehousing, such as the following: 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 the following: Only the material release: You can select this option if the item is marked as a Push in the general item data, because by definition, pull items require the material release information. Only the shipping schedule information. 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 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.

Order Management

| 9-15

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 contracts lifetime, the agreements about the price can change, due to inflation, for example. Therefore, 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 forward. 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 contracts 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 more straightforward and slightly less enhanced. No options are available to define price revisions, and no separate logistic data is available. Also, the set up of sales delivery contracts is complicated, because they always involve using a sales schedule and do not directly generate a sales order. You can also define the sales contract as a normal contract or a specific contract, as is applicable to the purchase contracts.

9-16

| Order Management
By default, the effective date of the contract is set to the first day of the coming month. For example, if the current date is March 3rd, the effective date of the contract will be set to April 1st. If the current date is March 28th, the effective date is also set to April 1st; this is also applicable for the purchase contracts. The sales contract also consists of a header and the headers 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 about business partners, such as the following: 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 externally used item codes, using item code systems, and can be stored in the contract lines to allow easy communication between customer and supplier. The applicable effectivity unit can also be filled in for the sales contract lines 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 information can be filled in, such as price, sales price unit, related price book, discount percentages, discount amounts, discount schedule, and the quantity-related information such as the minimum order quantity. An option is also available that indicates if quantity binding is applicable. This option allows you to compare and check, during the evaluation of the sales contract, if the called quantities covered by that contract are within the maximum and minimum limits set as contract quantity. Other relevant data present on the contract line is the tax code, tax-exempt reason, and the tax exemption certificate. You can also use the sales contract as a delivery contract or as a way to support the sales schedule functionality. If the user wants to generate sales

Order Management

| 9-17

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 manually defined, it cannot serve as a delivery contract, but 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 the item, as defined in the sales contract line, is dedicated for use in sales schedules, as present on the purchase side. Therefore, 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 the following 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 the automotive, aerospace, and defense industries, goods flow between two business partners is intensive, demand tuning is essential, and timely implementation of the delivery is crucial. The exchange of information is carried out on a regular basis and usually supported by the Electronic Data Interchange (EDI) medium. Standards in this industry can be used to allow the manufacturer and supplier to determine how to interpret the content of this type of electronic message.

9-18

| Order Management
In the ERP LN software, a standard messaging system called the Baan Electronic Message Interchange Standard (BEMIS) is used, which allows communication with other standards. In this document, the focus is on the way communication is carried out. However, the main characteristics are also described. The concept can be split into two main parts: 1) The focus is on the demanding organization that requires the items; this means a definition of the purchase schedules, and also communicates that demand by the purchase release to the second part: 2) Sales organization, which receives that demand as a sales release and performs delivery according to the related received sales schedule. Therefore the purchase release, which contains the schedule information of the demanding organization, is transformed into a sales release, which contains the related sales schedule information required at the delivering organization.

Purchase schedule management

The purchase schedule can be defined for items that 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. Also, you must decide whether this item will be triggered using a push mechanism or 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. This means the delivery of the product will be performed to a central warehouse and transferred to the shop floor/assembly line. Working with push means the delivered quantity is more than the actual required quantity; this is to prevent out-of-stock situations or ensure the economical order quantity is always delivered. Pull demand If the demand is pull-driven, the actual demand is not determined from the top, but comes from the bottom. What is required in the warehouse, Kanban, TPOP, or at the shop floor on the assembly line becomes the actual demand. Working with pull means the actual demand is exactly equal to the to-be-

Order Management

| 9-19

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 headers number, will be communicated between the two parties; the number will usually exist for a long period. 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 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 it has defined a Purchase Contract for this item and 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, and 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.

9-20

| Order Management

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. 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 issue date of the purchase schedule header 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 incase 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. Therefore, it is not known if the related release has been sent or not. So, the release number will only be filled for call-off schedules after the release has been sent. The business partner data. The warehouse and address, which is usually equal to the warehouse of the header, can be changed incase the purchase schedule is generated by EP and of type pull forecast. In that case, the planner can decide that another warehouse is applicable. Also, the Intrastat information 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, and 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.

Order Management

| 9-21

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

You can generate the purchase schedule in several ways. A short overview of the available integrations and how they work will be given.

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 session. Therefore, 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 create a purchase order as a type of fallback mechanism,. If a decentralized planning is made, this implies the actual demand comes from the assembly lines, the KANBAN-warehouse orders, or TPOPwarehouse orders. These items are marked as pull in the general item data; if demand is entered and known in Enterprise Planning for these items, after running the Generate Order Planning session, this results in purchase schedules of type Pull Forecast. These Pull Forecast schedules can then be exchanged to the supplier, so the supplier knows what to expect and wait for the pull call-off schedules, which will consume the forecast. The pull call-off schedule receives the same identification number as the pull forecast. The EP planning can be run incase the item is also defined in the ItemPlanning session and the order horizon is filled for that item.

9-22

| Order Management
Warehouse Management 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 a system that requires new items incase the other bin has become empty. The bin usually contains a fixed quantity. Therefore, in the Item Warehouse data session, the supply system must be specified, together with the supply quantity. In the Generate Orders (KANBAN) session, you can fill in the item and 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. The condition is that a pull schedule of type Pull-Forecast must first 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 using the Warehouse Management module, there are the standard integrations that exist between the purchase schedules and the receipt of the items using 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 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. Therefore, each line of such a push purchase schedule will not result in a specific warehouse orderinbound 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 total specified on the purchase schedule lines.

Order Management

| 9-23

Pull schedules Incase the purchase schedule is of type pull, 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, an advanced shipment notification will usually be sent. This means 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. When the shipment arrives, to speed up the inbound process you can read and confirm the data sent in the ASN. The ASN contains all items shipped with the quantities. This will also prevent typing errors during the inbound process. When this type of ASN is received in Warehouse Management, and the items are related to a purchase schedule, the status of that line will be set to ASNreceived; this is not specific for pull-schedules, but is 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 modified with the related delivered amount. Additionally, the receipt number, the ASN number, the packing slip (a detailed document that shows 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 the receipt was a final receipt, are all visible; a flag Confirmed is also present.

Line Assembly Control integration

The actual demand might come from the Assembly line, an example being the automotive industry: at a particular moment in the production process, the engine of the car must be delivered and installed. That means the engines of the cars must be delivered in the right sequence, because each car can have a different type of engine. To support this, an integration is available with the purchase schedules, which enables these items to be called; this results in actual quantities in the purchase schedule.

9-24

| Order Management
The session that will result in the generation of the shipping schedule is the Transfer Part Supply Messages session. In the Sequence Shipping Data session, the user can see 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 they can deliver according to this demand. To get the purchase schedule processed, complete 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. Approve release lines: The generated release 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. Process purchase schedules. Delete purchase schedules. Terminate purchase schedules: Meantime, you can remove processed reference IDs.

3 4 5

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 between the customer and supplier. The material release contains the long-term information, such as for the next 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).

Order Management

| 9-25

If the customer and supplier have a good relationship, exchanging all relevant information is easy, because the supplying partner can make better forecasts. The decision concerning 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. 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 sequenceshipping 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 present in the immediate period is sent, plus the demand of the planned period: Demand of immediate period 1 2 3 Only Material Release Only Shipping Schedule Material Release and Shipping Schedule Sequence Shipping Schedule In Material release In Shipping Schedule Demand of firm period In Material release In Shipping Schedule Demand of planned period In Material release Not sent By Material Release

In Material Release By Shipping and in Shipping Schedule Schedule In Sequence Shipping Schedule In Sequence Shipping Schedule

Not sent

If the user prints the Purchase Release session and selects Final Report, they can also select Prepare EDI Messages. If these messages were not yet generated, the messages will now be generated so the EDI messages can be sent in the EDI module. However, this depends on the setting of the Release EDI Message Directly in the Purchase Contract Line Logistic Data check box. If this 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

9-26

| Order Management
purchase release is generated and approved; therefore, the EDI message is sent immediately. The purchase release can be of several types: Preview Scheduled Sent The following is important information which you can find in the purchase release header: Release revision: For example, if a new revision containing the latest information is sent each week, 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, which indicates when 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: Usually, EDI will be used to exchange the data. Some forecast information. The delivery method: If the delivery method is shipment-based or deliverybased.

Purchase release lines

You can never change the lines because this information is all grouped from the schedule. If a change is required, a new generation cycle must be completed; 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:

Order Management

| 9-27

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 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 indicates the priority of delivery: immediate, firm, or planned. A reference ID. Some dimension information: length and width. Some schedule information, so customer and supplier can refer to their own schedule number.

CUM handling and FAB/RAW authorizations

CUM handling
The CUM handling is related to the purchase release. The purchase and sales schedules will be used in industries where high volumes are applicable; therefore, thousands of items will be delivered. The required quantities are calculated in a total, called the cumulative (CUM). Using the CUM model, the supplying organization can accurately calculate the needs of the demanding organization. If the supplier has already shipped 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

9-28

| Order Management
calculations can be performed by comparing the required CUM, the received CUM, and the shipped CUM. In ERP LN, two systems are supported: the order-based CUM model and the receipt-based CUM model. Often, the supplier must accept the method, which is determined by the customer who requests the items. Working with the order-based CUM means the unfulfilled requirements of the past are not sent again. The supplier must calculate whether an underdelivery is applicable. Shipped CUM and required CUM are compared. Working with the receipt-based CUM means 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 discrepancy exists between the CUM values that are registered by the customer and the supplier, a negotiation process can start on how to deal with that difference. An update session is available to modify the received CUM, and a session is 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 not to produce too many items, because the demand can suddenly decline. However, the supplier must also be flexible to fulfill the demand if it 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 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, which is an indicator that the purchasing organization will allow the supplier to purchase raw materials up to a particular date. This is all made visible in the FAB/RAW Authorizations session. Incase 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. When an evaluation of the schedules is carried out, the decision

Order Management

| 9-29

can be made to reset the High FAB value and make the value equal to the FAB authorization; this 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
The purchase schedules are defined on the demanding side, often the OEM or Tier1 Manufacturer. The release is sent by the EDI. In this document, no attention is paid to the EDI part, because that is mainly related to having defined a good set-up of the data. Note that such a purchase release cannot be sent except before the releases 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 all changes made after the purchase release is sent. The supplier cannot be held responsible until they are informed of this new release. Now, the sales release is assumed to be present at the supplier, and the document will describe the process about 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, which represents the long-term demand, 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 has requested: Release number. Release Revision number. Release type.

9-30

| Order Management
Sold to Business Partner - Ship to Business Partner, and the address. Reference information from the customer, such as the following: Customer release. Customer revision. Quantity Qualifier, which means 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

The lines only contain the following display information: 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 releases lines, the sales schedule has been received. Because this information is also fixed information, the release lines cannot be processed; 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 the demand of the schedule is coming from an assembly line or a dedicated warehouse and that a reference number is present for 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.

Order Management

| 9-31

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 receiptbased). 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 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. The sales schedule header contains quite a lot of the same information 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 to see if overdelivery or under-delivery is applicable. If so, this can result in an adjustment of the quantity; therefore, the status is set to Adjusted.

9-32

| Order Management
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. Based on these statuses, the sales schedule can be treated as processed during the schedules 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 the 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. For example, an overlap of the immediate demand can occur. The following information is present in the sales schedule lines: Schedule, schedule type, and 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.

Order Management

| 9-33

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, such as the VIN number. The dock location: This information is required for Warehouse Management. The ship-to address. More details about the item: Length and width. 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 information, 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:

9-34

| Order Management
Created Adjusted Approved Canceled Canceling in process Order generated Partially shipped Goods delivered Released to invoicing Invoiced Processed Using the lines, more detailed information about the shipments can be viewed in the Schedule Shipment Details/Corrections session. If the shipped quantity must be corrected, the user can make corrections.

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 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. Some invoicing information is also displayed. Through this session, you can make and confirm several new corrections.

Sequence shipping information

The Sequence Shipping Information session contains data incase the Assembly Control module triggers the actual demand that must be delivered. The following information is visible in the session: Schedule ID. Schedule position. Schedule revision.

Order Management

| 9-35

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 the specified location in the assembly line.

Sales schedule reconciliation

Presume that during the evaluation process, a difference arises between the CUMs so that the customer and supplier do not have the same information available. After discussion, the shipped CUM can be modified in the Sales Schedule Reconciliation session. The user can choose to adjust the shipped CUM, reconcile the received CUM, or adjust and reconcile.

CUM handling and FAB/RAW authorizations

On the sales schedule side, sessions that contain specific CUM-related information are available. The shipped CUM information can be viewed in the Shipped CUM session; it contains the transaction date, shipment ID, shipped quantity, shipped CUM, received CUM, and the status. The invoiced CUM information can be viewed in the Invoiced CUM session; it contains the invoice date, invoice number, invoiced quantity, cumulative invoiced quantity, and the status. CUMs can also be reset in the Reset Cumulatives session, so that the reset date will be filled and the CUM value is set back to zero. In the FAB/RAW Authorization session, the user can see the following information: Schedule with reset date. Item and the description.

9-36

| Order Management
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 the number of items on which the supplier can purchase raw materials; therefore, the supplier can begin production without the risk that these items will not be sold.

Purchase and Sales Statistics

You can upload your annual sales/purchases from order history to a new Statistics module. In this module, you can define your own layouts or displays to display or print statistical information. In this new module, you can also analyze historical data from multiple logistical companies.

Chapter 10 Electronic Commerce

10

Introduction
ERP LN 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 as follows: 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 functions and features of the EDI module are listed, although no significant changes have been made compared to previous releases. Note that within the ERP LN system, an own defined EDI message structure is developed, called Baan Electronic Message Interchange Standard (BEMIS); this means that EDI messages must be converted to other EDI formats, such as EDIFACT or ASC X12, using an 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.

10-2

| Electronic Commerce

Master data
Before you can use EDI, a lot of setup must be made; therefore, codes for organizations, such as BEMIS, must be entered. Messages that must be exchanged for sending data related to material releases, such as MRL001, must also be entered, and the relevant messages for each business partner (not all business partners will need EDI messages) and the moment (the ERP LN session) the EDI message must be generated. For example, during the Approve Release Lines 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 electronic data. In the Network session, the user must define where the data must be stored. The business partner data is linked to this type of network.

Conversion
The conversion sessions are an important part of the entire EDI module. You can enter the codes in the system, such as for addresses, currencies, countries, and schedule types; this helps to interpret the meaning of the EDI message. In the conversion setups for each message, the user can see which table fields will become part of this type of message, what level the table field has in that message, and the message length. When all codes are defined, the setup can be made for conversion-in data. Therefore, incoming EDI messages can be transferred in the standard ERP LN data and, for conversion-out data, messages are correctly transformed from the ERP LN system. An example of where this functionality is required is the item code. In the ERP LN system, an item can have code ABC, but at the other party, the same item has code 123. To ensure the other party will get the correct information, this type of conversion must be made. You can also define specific conversions for each business partner, and perform import and export of messages.

Electronic Commerce

| 10-3

Communication
A separate module that handles the processing of the EDI messages is present. Messages can be generated for a particular network or imported from a particular network. If message-generation fails, and required changes are made in ERP or the EDI module, you can try to generate EDI messages again.

Message data
You can view the received messages. If the conversion failed and the message could not be processed, the old data remains there, and you can try to perform the conversion again. 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 triggering the BEMIS EDI message are defined. Therefore, the functional session, such as the Print Release session, checks if the session is defined in EDI; 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 ERP LN entities: Code Name of the message DIS FML FMS INV MRL OCA ORC ORD ORS RAD SEQ SHP ERN RDN Dispatch Advise Load info to Carrier Carrier Status info Trading Invoice Material Release Order Change Acknowledgement Order Change Orders Order Response Remittance Advise Related Business Object where message is used ASN Freight Management Freight Management Invoice Purchase Schedule Purchase Order and Sales Order Purchase Order and Sales Order Purchase Order and Sales Order Order Management Financials

Sequential Shipping Schedule Purchase Schedule Shipping Schedule Error Notification Receipt Discrepancy Notification Receipt Purchase Schedule

You can group data from multiple Business Objects into one EDI message. For example, the order information also contains address information, which is another Business Object. To compare data present in an EDI message, a print session called the Print Compare Conversion Setups session is available. This provides an overview of which data is present in the incoming messages and outgoing messages.

Chapter 11 Central Invoicing

11

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 ERP LN. It is possible to centrally control the creation and send 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. Therefore, it is possible to send consolidated, few invoices to the business partner. These invoices can be printed or sent to business partners using EDI. The links to the various modules are shown in the following figure:

11-2

| Central Invoicing
SLS INH SOC CTM COM MSC CLM PIN CMS FOC ACR CMG SLI MCS EDI ACR 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, or Freight orders. Invoice data that can be received from Financials can be Interest invoice data, or 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 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 selected in the Billing request can be composed into invoices, depending on the composing criteria. When the invoices are printed, or sent by EDI, they can be posted to the Accounts Receivable open entries and the General Ledger.

Central Invoicing

| 11-3

Composing of the invoice data is done using some fixed composing criteria such as Invoice-to Business Partner, Invoice-to address, Currency, and 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, and sold-to address, can be defined by each Invoice-to Business partner. Using the user-definable composing options, you can collect invoice data from several business partners in the hierarchy into one invoice that can be sent to the parent business partner. While invoicing the sales order invoice data, the sales order must 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 sent to the business partner through EDI. Invoices can be automatically sorted based on the delivery method and postal code applicable. The invoices are 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 with the invoice; the customer uses the payment slip to make a payment. The invoice will be posted to accounts receivable, and the 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 intervals between invoices for each business partner. For the Counter sales, it is possible to automatically process invoices 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 sent to the business partner. The Sales Invoice module supports triangular Invoicing and bilateral invoicing. In the following processes, the external and internal sales invoice generation is handled by Sales Invoicing. The automatic creation of purchase invoice is handled in Accounts Payable.

11-4

| Central Invoicing
Sales Invoicing module supports Self billed invoices. Self billed invoices can be received from customers and can be matched with sales orders. After matching, an accounts receivable is created in Financials. Warehouse can send internal invoices to other warehouses incase of warehouse transfer. Work center can send internal invoices to other work centers incase of WIP transfer. Warehouse can send internal invoices to sales offices incase a warehouse not belonging to the same financial company as the warehouse implements the order. Purchase office can send internal invoices to the sales office incase of direct delivery. Shipping office can send internal invoices to the sales office incase 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 it is treated as an Inter-company transaction; such a relation is regarded as a normal buy-sell relation. However, if the two entities belong to the same financial company, then the open entries for Accounts Receivable and Accounts Payable will be suppressed. All purchases and sales between logistic companies will be booked to an inter company billing and clearing account; a report for inter-company settlement transactions is available.

Chapter 12 Manufacturing

12

Introduction
This chapter describes the following ERP LN 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)

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 allows you to maintain revisions linked to items. The EDM 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 ERP LN Manufacturing (Shop Floor Control and Assembly Control).

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 allow you to update multiple BOMs in Manufacturing simultaneously. Actions are defined for MBCs, and these actions inform you which changes must be performed on the items 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, such as 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, Bill of Material, and Assembly Parts and Operations module, 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.

Interface to Infor PDM

EDM can be connected to Infor PLM. The following is a short summary of the main Infor PDM features:

Manufacturing

| 12-3

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 Infor PLM module to linked documents and CAD drawings.

Item Production Data (IPD)

The item data in ERP LN is completely restructured. In ERP LN, there is now one central module called Item Base Data (IBD); here, general item data is maintained, such as the item description, item type, item grouping, and so on. The IBD module is used to control item data that is not applicationspecific and used in most of the other ERP LN modules. Each ERP LN application uses its own specific item data module and has access to the IBD module. Several new submodules exist to maintain item data concerning specific functional areas such as manufacturing, purchasing, costing, and sales. Item data related to ERP LN Manufacturing is located in the Item Production Data (IPD) module. The Item Production Data (IPD) module is the central module in ERP LN Manufacturing that provides support to other components in Manufacturing. The IPD module contains manufacturing-related item data such as the following: 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.

12-4

| Manufacturing
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; more manufacturing-related attributes are maintained in the IPD module. The new item base data and item production data allows the following: A more modular and decoupled setup of the ERP LN applications. A more user-friendly and flexible approach to the item data. ERP LN to be more open to other packages. ERP LN 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 parent/child relationship between the end item and the components related to the end item. This data is important for material planning and material requirements processes. A production bill of material can contain 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 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 an operation number to a

Manufacturing

| 12-5

component; this way the materials are connected to the operation in which they are consumed. You can also 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 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, and 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 perhaps on a certain machine. Routings can be as follows: Standard, which means it can be attached to multiple items. Item specific. Routings can also be quantity-dependent and 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. Additionally, required tools can be defined on this detailed level. The routing procedure consists of defining the elements () used in the operations, such as work centers, machines, and tasks; this 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/required tools can be defined per operation.

12-6

| Manufacturing
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 needs of the customer. Tools, or kits containing multiple tools, can be linked to machines, tasks, and operations. This is important for meeting the ever-increasing demand for quality, and to comply with ISO or QS 9000 quality standards. For more information on this subject, refer to Chapter 12 and the section on Tools Requirement Planning (TRP). The Routing module contains the following objects:

Work Centers
This business object allows you to maintain data concerning the companys work centers. Resources, such as 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, which is 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 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, which can only be part of an assembly line, are supported as special kinds of work centers and only used in Assembly Planning and Control (APL and ASC).

Machines
This business object allows you to maintain data corning the machines 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.

Manufacturing

| 12-7

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 allows you to maintain the operation data for standard and customized manufactured items. Operation data is stored and maintained for standard-items 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, such as length and width, 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 using a norm table.

Configurator (PCF)
The Product Configurator, which is part of Manufacturing, allows 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: To enforce constraints at sales time to guarantee that only buildable products are stated by the selected features and options. Structure generation for product variants: To generate the BOM/routings for the product based on the selected features and options. In support of these, PCF provides the following: Generic product modeling: To define the generic product, its features, and options.

12-8

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

Generic product modeling is the steps 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 shows 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 a 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 the user 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 quick ordering lookalikes. The sales order line, with its features and options, is used to generate the specific BOM and routing for the order. Depending on the order policy of the

Manufacturing

| 12-9

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.

Advanced Configurator Integration

In addition to the options provided by the Product Configurator (PCF), you can use an external, more advanced configurator, BuyDesign, from TDCI. By item or item group, you might be notified that, rather than PCF, BuyDesign should be used to configure items. As part of the configuration, the BuyDesign configurator will make the relevant chosen features and options available to ERP LN. This information can be used to drive the remaining processes in PCF. Therefore, relevant manufacturing constraints that affect the generic BOM and routing should be defined in PCF. For more details, check with your sales contact.

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 items 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 the 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 allows you to exclude the fixed costs from the inventory value. However, this is only possible for items valued against the fixed

12-10

| Manufacturing
transfer price. Item and warehouse surcharges are also possible for customized items. Two cost prices can also be distinguished: full cost price and the variable cost price. Various simulation features allow 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 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, such as low volumes and 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 to the execution of these orders. At macro level, the procedure consists of availability of materials and capacity, determining the order sequence, providing the necessary information through the help of various documents to the operators on the shop floor (including Kanban labels), 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 required for an item and the order policy of that item (anonymous or to order).

Manufacturing

| 12-11

The following classifications are possible: Level of customization Derived from Standard item Fully customized Using a Lean Project A B Derived from Generic Item D E F G Standard item Customiz ed item

Not using a project at all C Anonymous production

Note that empty cells in this table indicate situations that are not applicable. Additionally, ERP LN does not support situations C and E; however, the following sections provide comments on these situations. 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 difficult to use all the available PCS functionality because 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-toOrder. 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.

12-12

| Manufacturing
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, nonproject-specific planned orders are generated that also supply other PCS projects that require the same anonymous parts. If the items relate to the lean project, the cost price can be calculated. C: Not using a project, derived from standard item This situation is not supported by dedicated functionality. Standard ERP LN functionality can be used to produce these types of items. D: Fully customized, derived from generic item A sales order is available for a standard generic item, but 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 process a high volume of transactions, but full PCF configuration is supported. The product variant number allows 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 allow 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, such as Automotive, generic items with order system FAS (Final Assembly Schedule) are used, which are 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,

Manufacturing

| 12-13

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-toorder 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 until 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 manually or automatically entered through Enterprise Planning, Statistical Inventory Control, or several warehousing supply systems such as Kanban. If necessary, the production process can roughly be divided in changing estimates, 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 allows you to determine what materials can be issued at a specific stage in the production, what hours can be booked, and what subcontracting orders can be generated at a specific stage in the production. The status of the production order is automatically updated 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 allows you to record rejects for individual operations and 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 at the end of an operation, such as according to an inspection. These items can then be rejected. Rework orders can be issued to rework finished production orders. Reporting completed of operations can be followed by a financial transfer of WIP to the next work center.

12-14

| Manufacturing
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; at 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 also be adjusted. Production-related status information is stored for every serialized end item. The following statuses are examples: Created, Rejected, Assigned, and 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, sent to warehousing, or returned 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 warehousing, or returned from warehousing. Based on this information, the quantities in the production order are determined.

Production order processing

In ERP LN, during order processing, routings defined on phantom items will be included. 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 be estimated. The Tools requirement is estimated. Production order planning is set. Capacity utilization is determined. The materials are estimated, which means the materials estimate is filled with components from the standard or customized BOM; this is also performed for phantom components. Allocation of materials is performed using planned warehouse orders because you can have negative stock on hand. Depending on the feedback from Warehouse Management while executing a warehouse

Manufacturing

| 12-15

order, issued materials will be recorded in SFC. Therefore, 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, such as 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. Currently, posting to inventory will be performed at standard cost price or actual cost price depending on the valuation method.

Scrap and yield

Because there can be loss in production during or after processes, within the discrete manufacturing environment it is often necessary to specify scrap/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 semi-finished products. Yield is always operation-related and defined as a process output (end product quantities). Additionally, scrap may be specified as a percentage and a fixed quantity, while yield is always 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 defined as a fixed quantity or 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

12-16

| Manufacturing
operation is finished. Scrap quantity and yield percentage on operation level influence planned materials and hours. Subcontracting operations can also have scrap/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 replan the production order. The planning of a production order is a process of determining the start and end dates of the individual operations and 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 different factors such as the operation times (cycle time and set-up time), normal work time of resource units, queue-time, waiting-time, 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. Also, if a service order is present for service activities to run on a machine, the machine might not be available to perform 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 cost estimate; these changes can be reflected in the planning and are based on parameters. You can connect a single task to multiple work centers; this 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. 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

Manufacturing

| 12-17

large 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 perform the subcontracting of an operation. Subcontracting is based on the concept of outsourcing an operation. A subtracting purchase order is sent to the subcontractor. It is possible to control the material flow to and from the subcontractor. The work in process (called subassembly) produced in the operations prior to the subcontracted operation can be sent to the subcontractor. Also, components required for the subcontracted operation can be sent to subcontractor. The materials can be supplied in bulk or specifically for the production order concerned. The components and subassembly sent to the subcontractor are stored as material supply lines on the subcontracted purchase order. When the item produced by the subcontractor is received in a warehouse of the manufacturer, the related subcontracted operations are automatically reported complete. The inventory levels of the components and subassemblies sent to the subcontractor can be monitored in the system of the manufacturer. Two types of subcontracting are possible: Planned subcontracting: Defined as an operation in Routing or 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. Several views are available. Subcontracting operations can be listed per production order and per subcontractor. You can also view the subcontracted purchase orders per finished end product. It is also possible that the entire production process of an item can be subcontracted; for this purpose, items can be indicated as subcontracted

12-18

| Manufacturing
items. For those items, enterprise planning generates subcontracting purchase orders with material supply lines for the components that must be sent to the subcontractor. It is also possible to generate a subcontracting purchase order for an entire production order that has the status planned. Consequently, the production order is cancelled and a subcontracting purchase order is generated.

Execution of subcontracting activities

Functionality is available for subcontractors. Production orders executed for the manufacturer are indicated as subcontracting production orders. It is possible to receive materials owned by the manufacturer. Those items are stored against a certain value using current valuation logic. The items can be issued to a subcontracting production order. However, the actual costs of those items are zero when they are consumed in a production order. The WIP of a subcontracting production order is partially owned by the manufacturer; this value is visible to the user.

Production order material issue

This business object consists of the entry of issues and issuing of inventory as a part of the order procedure for production orders. The entering of issues is required to issue the necessary 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 automatically carried out.

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. Additionally, 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 directly issued (current date/time) or issued at the allocation date/time of the material for a specific operation. This process useful when using floor stock.

Manufacturing

| 12-19

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 automatically posted based on estimates when the operation/production orders are reported completed. The quantity of backflushing is based on the quantities reported back on operations/orders. You can manually backflush or allow 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 order quantity. The book date of backflushing hours is a date entered by the user, or 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 the following: Schedule (RPT) SFC order Operation Backflushing is possible even if there are shortages for the material. Negative backflushing is also possible under every condition. With negative backflushing, receipt booking is performed in Warehouse Management.

Shop floor warehouses

SFC warehouses are a special kind of warehouse 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. Supply is controlled through the supply system Time Phased

12-20

| Manufacturing
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 nonphysical work center that collects the production results 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/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, the production, and 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 about 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.

Manufacturing

| 12-21

Input output monitoring

Input/Output Control is the Capacity Control tool practiced 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 basic 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: Increased 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 the inability to efficiently report I/O on queue level. Risk of CRP tools not being used due to feedback from I/O Control reporting on the performance to the CRP plan.

Order grouping
ERP LN allows you to group production orders, which improves the efficiency of the user by reducing the number of individual transactions 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

12-22

| Manufacturing
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 efficiently, such as a sheet of metal.

Order sequencing based on setup and states

To optimize the use of the various machines available for the production process in a factory, and minimize changeover due to other product characteristics, functionality is available to sort production orders based on set-up classes; for example, color, and states, such as red. A class is an item operation characteristic, such as color; a state is a specific value of that characteristic, such as red. The user can define a sequence in which the blocks of SFC orders with the same set-up state, such as block 1: red, block 2: blue, are planned over time. The grouping algorithm uses sequence numbers statistically defined for each set-up state to group the SFC orders. The regular start and end dates of the orders replanned by the Block Planning module are also updated. Therefore, you can use all regular SFC functionality with this sequencing functionality.

Project Control (PCS)

The PCS module is used for customer-order-driven production. Various project types and item types can be distinguished, which results 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, the 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. Budgets can also 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 subproject dates. A main project can be used to collect budgeted costs, estimated costs, and actual costs.

Manufacturing

| 12-23

For PCS projects, a dashboard is available from which users can start all relevant sessions for a specific PSC project.

Repetitive Manufacturing (RPT)

The Repetitive Manufacturing (RPT) module facilitates production control in a repetitive-type manufacturing environment. The RPT module is used for highvolume production in a multimodel-flow environment. An RPT scheduling area can be used as a multimodel flow line. The RPT module allows you to control orders 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 required in a repetitive production process can be JIT items that can also be called off through shipment schedules. ERP LN 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, such as car manufacturers, require a system that allows 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.

12-24

| Manufacturing
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. By using the Product Configurator (PCF), the product variant can be configured.

Engineering & product configuration

Product structures can be defined in APL, an external system, or when using the Product Configurator, in PCF. The generic end item, such as 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. Instead of, or next to, the Product Configurator, the unit effectivity functionality can be used to define variety in the generic product structures. An external PDM system can also be used to create customer-specific product structures based on the selections performed in an external configurator.

Product variants
The configuration is stored as a product variant in APL. The product variant is the central entity for storing logistic-related information of the product concerned, such as product structure, 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 generic item. Together, the generic item and product variant identify the unique product. A product variant is created on sales order entry. You can reuse an existing product variant on a different sales order.

Master data: Line/operation setup

The assembly layout is maintained in ASC. Operations are defined in APL and are assigned to the line stations.

Manufacturing

| 12-25

Flattened parts
The content of every module is stored in the flattened parts. This is a onelevel BOM consisting of all the assembly parts. The flattened assembly parts can be defined in APL, retrieved from Engineering Data Management (EDM), or Imported 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. The Product variant Structure and related flattened assembly parts are input for the assembly part requirements calculation.

Assembly order generation

Assembly orders are generated and sent to the Assembly Control module. During the generation process, Product Variant Demand, Product Variant Structures, and related flattened assembly parts and operations are retrieved. Next to this, assembly orders in process and available on-hand inventory for Product Variants are considered, to determine if new assembly orders must be generated..

Refresh/freeze assembly orders

Assembly orders are frozen within a certain time fence; 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

Unit and date effectivity can be used. For unit effectivity, the data will be effective for a range of unit numbers.

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:

12-26

| Manufacturing

Line Station Variants (LSV)

Line station variants are used to reduce the data storage and 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 only have a link to Line Station Variants.

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 allows 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 and the combined material requirements per bucket. Some companies 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. Such companies can also use the assembly functionality. A parameter available allows you to indicate whether transaction processing is line-station based or order-based. When the transaction processing is line-station based, costing is performed per line, not per order. 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 partially freeze assembly orders; this 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 by linking a time fence to a line segment. Suppose this time fence is called F. At a specific moment, such as now (planned start date on segment F) <= Now, then everything of the order related to segment with freeze time fence = F is refreshed and frozen. This order part is now within the freeze horizon. The frozen parts of the order can still be manually changed. You can manually change operation data, including assembly parts, if required.

Manufacturing

| 12-27

Multisite assembly
In many mixed-model-flow companies, the assembly process is performed over multiple companies that have their own logistical data set. These companies can have several assembly lines in different logistical companies. A generic subitem is assembled on a supplying line and supplied to the main line on which the final end item is assembled.

Line Sequencing
Assembly orders generated by APL can be sequenced by using the sequencing engine, resulting in a line mix and line sequence. During this sequencing process, line rules are taken into account; for example, clustering assembly orders based on item characteristics, or blocking assembly orders based on capacity rules.

Manual change of the sequence

The sequence is recorded in an easy to use control panel which can be used to manually change the generated sequence. You can move orders to another position or 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 reporting completions, for example. 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 deals with 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.

12-28

| Manufacturing
For pulling materials from supplier of warehouse to the correct destination, triggers can be used. For some supplying methods, these triggers can be based on events in production. Different supplying methods can be used and 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 involved. 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 simultaneously, 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 separately for every assembly order based on triggers in the production process, even though 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 sales releases. These releases (shipping and sequenced shipping schedules) are communicated to the supplier through EDI. Additionally, a unique reference per KIT, station, and part is included in that information. At the suppliers (Infor) system, this

Manufacturing

| 12-29

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

Usually, a planner is responsible for a segment, and 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. You can also 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 allows you to select different overviews.

Progress overview per line station

Similar to the progress overview per buffer, the progress can also be monitored per line station. This control panel allows you to perform many activities. The control panel can be used to report line station orders that contain the work on that order. Also, different views are available by a toggle function; for the line station involved, you can display all orders or only the orders not yet completed. Instead of using this line station for reporting line station orders completed, you can also use barcode functionality to do this.

Process triggering
In mixed model flow production environments, many activities are based on the progress information of individual orders. Therefore, 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:

12-30

| Manufacturing
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, such as the following: 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-volume 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 operation and the number of employees required per operation.

Line surcharges
During the assembly process, line surcharges can be booked. Surcharges booked on an assembly line are defined per the following: 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, and 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. This number is generated when the

Manufacturing

| 12-31

sequence of the order is confirmed. The serial format can be any, which means that the standard legal formats can be supported, such as ISO norm for VIN numbers for road vehicles. As-built structure information can be collected during the assembly process; this can be 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 ERP LN Service.

Lean system
ASC has been designed to minimize system tasks to be performed by the users. For example, 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 reading bar codes.

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 used to perform certain tasks of an end user. The dashboard is based on one object, such as item, business partner, order, and so on, which the user needs to start to carry out their task. Relevant details of this object, and the possibility to open the sessions in which the relevant information for the task(s) is stored, are presented on the dashboard. The following dashboards are available: Items dashboard: From this session, the following sessions can be accessed for an item selected on the screen: Bill of material. The items wherein the item are used. The routings of the item. The alternative items.

12-32

| Manufacturing
The related engineering revisions. The business partners that supply the item. Production orders. Purchase orders. Purchase schedules. Other relevant data is available in the dashboard for a selected item, such as the following: Item signal. Inventory on hand. The time phased inventory presented in graphical mode. Work center dashboard: From this session, the following sessions can be accessed for a work center selected on the screen: Utilization by week. Utilization by day. Input/output control. Resource order plan. Tool requests. The following process can be started from this dashboard: Build utilization. Generate input/output control. Delete input/output control. Request/return tools. Other relevant data is available in the dashboard for a selected work center, such as the following: Basic week capacity Number of operators Number of machines

Manufacturing

| 12-33

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 ERP LN 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 Warehouse Management. 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 ERP LN system automatically displays an alternative tool when the required tool is not available. When a tool kit is released, all of the relevant tool kits are released simultaneously. By using ERP LN, you can compose a tool that consists of multiple detachable components. To perform an operation, you must have the complete set of tool components. Based on the comparison between the planned lifein times used or hours usedand the actual use of the tools, ERP LN 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. New/existing items can also be classified according to the defined product classification. Searching is performed through a combination of search arguments.

Chapter 13 Warehouse Management

13

Introduction
This chapter describes the modules of ERP LN Warehouse Management in more detail. It also describes the functions and features of the following modules: Warehouse Master Data Inventory Planning Inventory Handling Inventory Reporting Inventory Analysis Lot Control ERP LN Warehouse Management 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 implemented. The warehousing orders are the communication layer between ERP LN Warehouse Management and the other ERP LN applications; therefore, tight integrations exist between Warehouse Management and the other ERP LN applications, but at the same time the package is essentially decoupled from the rest of the ERP LN applications. Therefore, integrations towards external applications, such as WMS or ADC vendors, are possible.

13-2

| Warehouse Management

Warehouse master data

Introduction
The master data to be entered for Warehouse Management 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

Docks
Receipt locations and staging locations can be defined as load docks and unload docks. The system can automatically select and propose a dock when goods are received or picked; this can be based on user-defined criteria such as item, storage zone, business partner, carrier, route, transport means.

Warehouse Management

| 13-3

Items
Here, you must define the items used or handled by Warehouse Management. In item warehousing data, you can enter specific warehousing data, such as the following: Valuation data 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 the following: Issue data Lead times Replenishment data 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 ERP LN Warehouse Management. From a simple transfer to a complicated receipt, one or more warehousing orders control and account the movement of inventory. Flexibility and automatic implementation of activities is possible.

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

| Warehouse Management

Inventory planning
Introduction
The Inventory Planning module is 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 the following: 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 will 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

Warehouse Management

| 13-5

Replenishment
Replenishment can take place in a warehouse network in between warehouses, or in a warehouse between locations. You can define replenishment between locations in a matrix that contains the supplying zone or supplying location, the destination zone or destination location for each item, and the quantities to be replenished. Several planning options are available in ERP LN to replenish warehouses. The most advanced option is to use Distribution Requirements Planning (DRP) or ERP Enterprise Planning (EP). DRP applies demand control. Another inventory planning option that applies Demand Control is TimePhased Order Point; this is a simpler option mainly intended to replenish a warehouse by a supplying warehouse. Besides demand control, ERP LN offers two options for Inventory Control. One option is Statistical Inventory Control (SIC); this runs by item or 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. Some sessions are also present to collectively define planning parameters for each item or each item by warehouse, such as Economic Order Quantity or Safety Stock.

Inventory commitment
Several possibilities are available to reserve inventory. You can only reserve 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.

Inventory Handling
Introduction
In the Inventory Handling module, the actual inventory movements are implemented with the use of warehousing orders. Warehouse activities, such

13-6

| Warehouse Management
as receiving, put away, picking, and shipping are handled in this module and controlled by the warehousing orders or handling units. Additionally, 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, and environments with low volume throughput of goods.

Warehouse Management orders

A warehousing order is an order for handling goods in the warehouse. The warehousing orders are the communication layer between ERP LN Warehouse Management and other applications. These warehousing orders are required for a tight integration and a decoupled package simultaneously. Warehousing orders can be the following types: Receipt: Movement of goods from an entity other than warehouse to warehouse. Issue: Movement of goods from warehouse to another entity than warehouse, such as a work center or 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 maybe of location, (an adjustment). Warehousing orders can be manually entered, generated by other ERP LN packages, or received from EDI or external applications. The to-be-implemented warehousing activities can be communicated by the application that initiates the warehousing order, or manually entered for manual warehousing orders, or determined by 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.

Warehouse Management

| 13-7

Cross-docking
ERP LN 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 ERP LN, 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 Direct Material Supply (DMS) 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 probably 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 ensures received goods are stored in a warehouse. During the process of storing the goods, several activities can be required, which can be set up and implemented flexibly. Even during the inbound process, several activities can be switched off or on, or can be changed from implementation mode. The following activities are supported by ERP LN and can be activated flexibly: Print goods received note. Receipts. Generate inbound advice. Put away inbound advice. Generate storage list.

13-8

| Warehouse Management
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. Advance Shipment Notifications (ASNs) are also supported. ASNs can be received and sent by EDI or sent manually. Validation of ASN data is available. A receipt can be registered based on several filter criteria, such as the following: Advance Shipment Notification Expected shipment Expected order Load Item Business partner Handling unit References Besides these filter criteria, high-volume receipts are also possible. To accept the receipt, several predefined tolerances regarding 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 ERP LN Warehouse Management can be used. ERP LN Quality Management, to which an integration exists, supports more advanced inspection functionality. 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.

Warehouse Management

| 13-9

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, which is based on criteria such as the following: 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; therefore, the advice can be released and printed on storage lists.

Inventory Disposition
Items/materials that arrive at a warehouse often require inspection. Inspection can happen in many ways: superficial, that is, whether packaging is damaged, or very extensive, that is, including laboratory tests. In many cases, goods must go through an extensive inspection, possibly including multiple rounds, before they are allowed to be used. Goods might be initially rejected at first check and segregated to be subjected to further inspection, based on which a final decision is made. This final decision determines what will actually take place: rework, scrapping, return, or use as is. This is reflected in the ERP LN system. New functionality is offered with regard to the inspection of received goods and the procedure that follows. This functionality is called inventory disposition and deviates in some respects from the existing Rejection functionality. Inventory disposition caters for follow-up activities/decisions such as use as is, scrap, rework and return, necessary after an initial rejection of the received items.

13-10

| Warehouse Management
The following shows the procedure:

Receive and inspect items

Approve received items

Disposition received items by entering a rejected quantity in WH inspection session

Generate inbound advice

Handle disposition (of items in reject location) through new disposition session

Put away

Accept (Use as is)

Destroy (Scrap)

Return

Inbound advice from reject loc. to storage bin.

Inventory is adjusted

Return order is recorded and items returned

put away

Settlement with supplier

Settlement with supplier

The inventory disposition procedure is applied to owned goods and consigned goods. The new disposition functionality differs from the existing rejection functionality in the following areas: Goods received from suppliers and recorded as such in the system will immediately become ownership of the receiving party if no consignment applies, irrespective of what happens afterwards during inspection. If these items are inspected, they might initially be dispositioned, that is, rejected and placed in a different location. This procedure is followed by a reexamination of the goods in order to come to a final decision. Meanwhile, all received goods still remain the ownership of the receiving party. This implies that dispositioning goods and initially placing them in a specific (reject/disposition) location, does not trigger (potential) backorders or generate any financial integration transactions. Nor does it affect inventory valuation or automatically debit the supplier and generate debit memos. In other words, after a receipt is recorded in the system, the goods are paid for, so the supplier does not have to wait until the disposition procedure has been completed. In short, the disposition procedure is not intertwined with the receipt procedure, which implies that a final receipt remains a final receipt, irrespective of what happens at disposition.

Warehouse Management

| 13-11

From a logistical perspective, consigned receipts must get the same treatment; however, the ownership issue does not apply because consigned goods generally change ownership when used/consumed by the receiving party.

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 implemented flexibly. Even during the outbound process, you can switch several activities off or on, or change activities from implementation mode. ERP LN supports the following activities, which can be activated flexibly: Generate outbound advice Release outbound advice Generate pick list Pick list Approvals Freeze/confirm shipments/loads Print bill of goods Print packing slip Print packing list Numerous supportive functions are also 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 ERP LN that advises the user about the location and lot from which goods must be issued; this takes into consideration such factors 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.

13-12

| Warehouse Management
The picking mission covers the picking actions 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 perform 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 takes place. Dock assignment is also supported, and staged inventory is still visible in the system. After the goods are picked, a shipment is prepared, unless ERP LN Freight Management is used to generate the shipments. Shipments can be for one order (single shipment concept) or multiple orders in case the delivery address is the same. If Delivery Points are defined, which is a further detailing of the delivery address, shipments can be built by delivery point. How shipments are generated by the system can be manipulated by userdefined criteria such as date/time (periods), picking missions, locations, references, routes, and carriers. If ERP LN Freight Management is implemented but not used for load planning and shipment building/planning, you can run a carrier selection and costing process straight from the loads and shipments created in ERP LN Warehouse Management. After the goods are made transport ready, the shipment can be frozen. Required documents, such as bill of goods, 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. Additionally, the shipping documents can be printed or reprinted. Based on Advanced Shipping Information, such as ASN and so on, an ASN data file can be defined. This file includes information about item, customer, dates and times, truck, delivery address, and quantity.

Value added services

Value added services, such as assembly and packaging, are supported by warehousing assembly orders; these orders are used to collect goods to assemble the orders into one item. Warehousing assembly orders are manually created. Warehousing assembly orders transform goods in the warehouse, and can be performed at any location in the warehouse if the order is marked as assembly permitted.

Warehouse Management

| 13-13

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, ERP LN generates the following: 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 was a received item. Every manual modification of the warehousing assembly order or order line is registered in the warehousing assembly order history.

Kitting and Shipping

Multiple customers have specific order, pick, kit, pack, and ship procedures in place when they issue goods from a warehouse. Kitting in this sense is a method of shipping components in a structured way, according to how they are applied at the destination (modification site). It is essential that kit structure and components that are required for an order are visible throughout the entire outbound process. A topkitsubkit structure can be defined in the sales order, where the order header represents the topkit and every line contains a subkit. This structure is copied to the warehouse orders, where every subkit will be represented by a warehouse order set. Usually the composition of a (ship)kit is determined by the components and the corresponding activities/operations necessary to produce/assemble the required end product/kit. In principle, a kit is not delivered partially (short shipping of components); nevertheless, you can do this, that is, after explicit instructions from the customer. Components that have not been shipped from the warehouse can be shipped later or can be delivered straight from the supplier (direct shipping). Modifying the (BOM) structure of a topkit or a subkit is still possible in later stages in the order-picking-kitting-shipping procedure. These changes must be automatically processed in existing (kit) orders. After a kit order has been passed to the warehouse, changes can only be carried through manually. Therefore, steps must be reversed, sometimes even after (confirm) picking. Optionally, the procedure ends with the packaging of kits into containers for shipment to the customer. The topkit/subkit structure remains recognizable in the container contents. This containerizing process is a manual process.

13-14

| Warehouse Management
Before containers are shipped, they can be accompanied by a new document or a set of documents called Shipping Manifest, in addition to other available shipping documents. This manifest describes the contents of the entire shipment ID (topkit) and the contents per container. Furthermore, it contains information about the missing components, which are needed to complete subkits. This refers to components that are shipped directly or will be shipped later because of a shortage. The basic procedure is as follows:

Mai ntai n BO M (by eng ineerin g de pt).

Compo se/pack subkits (no n-system action .)

Recor d sales order and retrieve BOM (=kit) structu re for th e delivery of compone nts.

Release inve ntor y (re lease o utbo und advice / confirm pick)

Trigger supply / procurement of co mpo nents from intern al/e xternal supplie rs

Rece ive, insp ect and put away comp onents in th e wareh ouse

Continuous Change to BO M/Kit structure

P ack goods for shipment purposes (Containe rs)

Freeze ship me nt (optional)

Pr int warehouse (outboun d) instructions and pick componen t kits.

Final stage for BOM change

Produce the necessary documents (like the shippin g manifests)

Mana ge shortage s and (possi bly) dire ct shipmen ts

Shi p go ods

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

Warehouse Management

| 13-15

parent-child fashion. You can manually create a mix of different items on a single handling unit. You can manually create a handling unit structure for a given number of items; alternatively, you can define a package definition in which you set up a template that determines the handling unit structure for particular types of items. Later on in the process, you can update/change the packaging structure of existing handling units. This can be done by replacing an entire packaging definition or a single packaging level. For tracking and tracing purposes, packaging material balances and Shipping Material Accounts can be maintained per address for specific, that is, reusable, packaging material.

The use of handling units

A handling unit is a single entity 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 administrative information and physical information about the contents. You can link a handling unit to an order line in various ways. For example, you can generate handling units for an inbound order line, or, indirectly, you can generate 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 allows you to have a highly automated implementation of warehousing activities at receiving and shipping. With regard to handling unit labels, you can define different layouts per packaging (HU) structure or even packaging (HU) level. You can use 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 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.

13-16

| Warehouse Management
Before cycle counts can be carried out, preconditions must be set. Some of these preconditions are as follows: 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 the following: 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. For each stock point, employees can enter the counted quantity on the printed cycle count list. Handling units can be marked as present. If a variance that falls outside the margins occurs, a recount can be forced. If this type of variance does not occur, the cycle count order line can be approved and processed; this means an update of the quantities and, related to this, an update of the financial value of inventory.

Inventory adjustments
Inventory adjustments are used to manually change the inventory registered by ERP LN at a specific stock point. Inventory adjustment orders are used to perform the inventory adjustment.

Blocking
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 the various inventory levels: Zone Location

Warehouse Management

| 13-17

Lot Stock point Serialized item Handling unit At most of these levels, blocking can be more specific 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 important for a company, several reports are offered to provide the best 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. 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

13-18

| Warehouse Management
Committed inventory

Inventory transactions
All transactions that influence inventory positions or movements in a warehouse are recorded by ERP LN and logged in this module. This information is used for track and trace purposes. Eventually, these transactions can be archived.

Inventory Analysis
This module provides functionality to analyze inventory from two perspectives: logistically and financially. Logistically, an ABC and slow-moving analysis can be performed, 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. Two options are available to update the Inventory Value, even if inventory is present. One is to update the Moving Average Unit Cost (MAUC) for MAUC items; the other 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 ERP LN Warehouse Management, 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, or Warehouse Management. Some information can be added to ease the identification of a lot, such as a business partner.

Warehouse Management

| 13-19

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 for 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 uniquely identifiable by its 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 you can perform a check for each serial if the serial is in stock. 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 owned by the customer and exist in the warehouse for repair.

Consignment (not owned)

This is a warehouse used for storing not-owned consignment inventory. Notowned consignment inventory are goods owned by a supplier but managed by the own company and 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.

13-20

| Warehouse Management

Consignment (owned)
A warehouse 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 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.

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

Warehouse Management

| 13-21

Vendor Managed Inventory

ERPLN supports multiple forms of VMI (Vendor-Managed Inventory). VMI is a popular formula for managing inventory and the cost/ownership. Many enterprises keep their inventory levels and cost low by leaving the management/handling and ownership of component stock in the hands of their suppliers. Only when items/components are actually issued and consumed (consignment principle), are they paid for; this is called Pay-onUse. In some cases, inventory planning is left up to the component supplier. An alternative scenario is when inventory management, and sometimes inventory planning, is subcontracted to a third party, usually a Logistic Service Provider (LSP). All scenarios are supported by ERPLN regardless of which party owns the inventory or who is responsible for inventory management and supply planning.

VMI Procedures & Scenarios

To properly assist the concept of VMI, the complete process flow of component procurement, (consignment) inventory, (subcontracted) warehouse management, inventory planning, production planning, manufacturing, and the necessary communication between parties involved is covered by ERPLN. In other words, both the sales side (vendor role) and the purchase side (customer role) within a VMI scenario is covered by ERP LN. Within a VMI context, a basic supply chain can be shown as follows:

VMI Products Component Supplier 1 VMI Products

End Customer

Component Supplier 2

VMI Comp.

Assembly

Final Assy.

End Customer

Manufacturer
Component Supplier 3

VMI Products

Store/End Customer

Warehouses possibly managed by an LSP

Store/End Customer

13-22

| Warehouse Management

Roles and Terms/Conditions

The supply chain and VMI solution described in the above diagram can only function well if the role and responsibilities of each party involved are clear. The relationship between the different parties (suppliers, manufacturers, and customers) must be strong and reliable. Within ERPLN, agreements made within the supply chain, such as inventory/replenishment levels, delivery dates, and so on, are registered in Terms & Conditions, which are linked to purchase/sales contracts. Such agreements are made with business partners, but can apply to specific items or item-warehouse combinations. Multiple VMI scenarios exist, and are distinguished by the roles played by the parties involved: who owns the inventory, who is responsible for supply planning, and who is in charge of warehouse management/inventory handling. The following range of VMI-related business processes/scenarios are supported by ERP LN: Scenario Traditional (non-VMI)* Consignment* Full VMI Planning by customer WH management by LSP WH management by supplier Planning by supplier WH management by customer 1 2 3 4 5 6 Number Financial Ownership Customer Supplier Supplier Supplier Supplier Customer Customer Supplier Supply Planning Customer Customer Supplier Customer Customer Customer Supplier Supplier Warehouse Management Customer Customer Supplier Supplier LSP Supplier Customer Customer

* Already supported by previous ERPLN versions.

In case a party is the owner of the inventory, or responsible for the supply planning, but is not in charge of warehouse operations (inventory handling), it is necessary to record inventory levels and keep track of transactions regarding inventory which is physically not present on site; this is supported through a kind of virtual/administrative warehouse, which is a normal warehouse but with procedural limitations. Inventory levels in such warehouses are always a reflection of the inventory in a real warehouse, defined in the system of the party actually managing the warehouse and handling the stock.

Warehouse Management

| 13-23

Communication
To make a VMI formula work, exchange of all kinds of information between the parties involved is crucial. This mainly concerns information on forecast, demand, inventory replenishment, receipt transactions, consumptions, inventory levels, invoicing, payment, and so on.

Connectivity to AutoConnect Components

As part of the Automotive solution, ERP LN must work seamlessly together with components of the AutoConnect Suite. For this purpose, enhancements have been made mainly in the shipping and handling unit/packaging area to enable a smooth process through ERP LN Warehouse Management and the AutoConnect components.

Chapter 14 Freight Management

14

Introduction
This chapter provides an overview of the functions and features offered by ERP LN Freight Management. Freight Management is a Transport Management System (TMS) that allows customers to properly manage their transport orders, load consolidation, planning, and to calculate delivery lead times. This can be done across different logistic companies. The main target group of ERP LN Freight Management is shippers rather than carriers or logistic service providers. The product is a fully integrated part of the ERP LN suite and has strong links with Warehouse Management, Financials, Order Management (Purchase and Sales), and Enterprise Planning. However, the product can also be used as a stand-alone freight order and planning system. ERP LN Freight Management uses general master data, such as countries, business partners, addresses, items, departments, distances, and so on. Additionally, 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. Functionality is available for estimating freight-related costs and revenues, and a link to ERP LN Central Invoicing for handling invoices from carriers or to charge transport services to customers:

14-2

| Freight Management

Freight Management within ERP LN

Project Manufacturing Order Management Warehouse Management

Service

Enterprise Planning

Invoicing & Finance

Freight Management

Main integration scenarios

Warehouse Management
Warehouse Management is almost always active when you use Freight Management. The close connection between ERP LN Freight Management and Warehouse Management allows you to copy warehouse orders; these can be inbound, outbound, and transfer orders or 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.

Enterprise Planning
Activating the link between ERP LN Enterprise Planning and Freight Management produces freight orders on the basis of planned item transfers between warehouses (planned distribution orders).

Freight Management

| 14-3

This allows 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 companys suppliers to the companys warehouses, a link between ERP LN Order Management (Purchase) is available. This link triggers freight orders on the basis of purchase orders, which allows you to perform load consolidation, planning, and shipping items to the appropriate warehouses.

Sales Control
Sales Control is a frequently used connection that allows a shipper to create freight orders on the basis of sales orders. For example, companies that manufacture goods are usually 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 possible cost. 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 shows the business process with the integration between ERP LN Sales Control and Freight Management, including the link to Warehouse Management:
Business Process Sales Control Freight Management Integration
Shipping office Set up: Route Plans, Freight Rating, Carriers / Fleets, Transport modes / methods Order Receipt Planning Load Building & Costing Execution Finance Invoicing

Sales

Release to warehouse Carrier Selection

Warehouse

Carrier

The functions and features of the following modules will be described: Freight Master Data (FMD).

Payment

Customer

Create Freight Order & Order grouping

14-4

| Freight Management
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 ERP LN 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; planning groups can be a subdivision into specialized teams, such as for hazardous material or tanker transport. A shipping office can be assigned to specific warehouses, to ensure this shipping office manages all external movements of goods stored in these warehouses. Alternatively, a matrix can be defined to assign freight orders to the correct shipping offices, based on criteria such as 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. Additionally, login codes (users) can be linked to each combination of shipping office and planning group, and profiles can be defined for every user.

Addresses and items

Besides the common address and item data, some freight management specific details may have to be added. With 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.

Freight Management

| 14-5

Concerning the transportation of items, defining details about dimensions, special transport means and methods, mateability, and carriers might be essential. Often, Freight Management-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 concerning the actual transportation of goods is specified. Depending on the complexity of the shipping activities, various transport types can be defined, such as Refrigerated, Hazmat, Express, and so on. You can also specify combination codes to be used for mateability/compatibility rules. Also, the structure and nature of the transport fleet used is entered here by Transport Means Groups (TMGs) and Transport Means Combinations (TMCs); this determines the character and composition of transport means such as vans, tankers, ships, palletized, tractors, trailers, the mode/category, capacity, speed, and so on. In case a fleet is owned or dedicated, you may be required to fill the TMGs/TMCs with individual means of transport, for which you can monitor availability through calendars. Finally, you can define and link external carriers/LSPs to specific shipping office planning group combinations. For every carrier, the capacity and TMGs/TMCs 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. Also, information such as freight and weight/volume classes can be specified, which can be used to calculate transport costs/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 ensure an order is assigned to the appropriate team.

14-6

| Freight Management

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. The route structure also determines which freight orders can be consolidated and planned on the same trip to reduce costs. In ERP LN Freight Management, you can maintain standard routes to which ranges of ZIP codes or areas can be attached, and 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 incase 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 allow local round trips. 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; this includes 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

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 batchwise. You can also manually create freight orders.

Freight Management

| 14-7

Subcontracting freight orders

Depending on a shippers policy, you can include freight orders in the load planning. Alternatively, you can decide that all planning activities or the planning of particular transport, such as 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.

Inventory commitments for freight orders

Inventory allocation/commitment functionality is available to commit inventory for items on freight order lines. This option enables a procedure where only those freight orders for which all or part of the required inventory is available are included in the transport planning, that is, load building, process.

Freight order history

You can clear 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 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)

Incase a shipper goes further than freight order control, but also wants to be involved in the planning and perhaps implementation of his transport activities, the planning/load building engine of ERP LN Freight Management must be applied. For example, running the planning engine in Freight

14-8

| Freight Management
Management 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 different logistic companies and can be managed and planned centrally by 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 shown in the following figure:
Planning Algorithms within ERP LN 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 combined into one load/round trip with shipments on the same route Single mode

C) Pooling (Route Plans)

Intermediate pooling points (e.g. DCs) 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 implemented. 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

Freight Management

| 14-9

algorithm), Incoterms (points of title passage), transport means groups, capacity, and so on. Incase no TMG or route has yet been defined, 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 yet been allocated, 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. To improve the efficiency of the transport planning procedure, the system supports inventory monitoring and commitment straight from the loads and shipments; it can also generate a list of available goods and shortages per load or shipment. The purpose is to avoid situations where a planner works out a detailed transport planning while many of the goods are not on stock and cannot be shipped. Based on the parameter setting, the transport planning procedure can be extremely flexible, allowing updates such as the adding of new orders to existing loads even up to status Shipped. The settings can also determine that the procedure must be more rigid and that no load/shipment updates can take place after a plan has been actualized or the warehouse outbound procedure has been initiated. Manual time/date changes, re-sequencing/reshuffling of shipments/addresses within loads, moving shipments between different routes, automatic recalculation of times/dates, lead times, distances, and costs are supported in a flexible and user-friendly way. 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 the actual transport is not subcontracted. Incase a shipper is not in possession of a fleet, all transport will be performed by one dedicated or more external carriers. Alternatively, a shipper may decide to subcontract particular loads that require conditioned means of transport. For this purpose, FM offers functionality for subcontracting loads to external carriers.

Graphical planning board

To assist the use of the core modules of 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 planning operations can be performed from here.

14-10

| Freight Management

History
You can clear the 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 possible 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. Also, the desire to charge customers and other business partners for transport services (revenues) is increasing. In FM, costs are based on carrier freight rates; revenues are calculated by either the client freight rates or carrier rates with markups.

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 rate basis numbers. Many other aspects can have an affect 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 ERP LN Order Management. Freight costs can be calculated on different levels, of which loads and shipments are the most important. Initial cost calculation takes place during the planning run, when the load plan, loads, and shipments are generated. You can freeze the costs after the first calculation or to let the system recalculate costs that are based on more actual information during the execution process, even up to the final status Completed.

Freight Management

| 14-11

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 whom the carrier arranges transportation, you must set up the required rate scales and release freight orders for invoicing. The latter action allows the ERP LN 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, amounts, currencies, terms of payment, invoice address, open balance, and so on. ERP Central Invoicing also handles processing invoices received from carriers for services rendered.

Chapter 15 Service

15

Introduction
ERP LN 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. 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. ERP Service assists these through processes such as field service, depot repair, subcontracting, and help desk support. ERP LN 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). ERP LN Service consists of the following modules to cater to the various service processes: Configuration Management. Call Management. Contract Management. Subcontract Management. Field Service. RMA and Depot Repair. Master Data Management.

15-2

| Service

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 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 allows 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. Serialized items are customer-specific or owner-specific configurations that consist of items such as photocopiers, computers, air conditioners, forklifts, lathe machines, or aircraft. You can manually create a serialized item, or modify existing items. Serialized items are the building blocks of physical breakdown structures. These serialized items are uniquely numbered and 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 ERP LN Service. Based on this, a serialized item can exist in various locations, such as in configuration, in depot repair, in transit, or in a warehouse. Additionally, each serialized item

Service

| 15-3

can have a status of Start-Up, Active, Defective, Working Condition, to be Recycled, Removed, or Revision. The status defective can be set while receiving the item in To Warehouse lines of service/work order materials or maintenance sales order receipts. After the repair is performed on a work order, the status of the serialized item can be set to Working Condition. This status will differentiate these serials from the new ones. When a serial is scrapped in the service department, the status will be set to Removed, which is useful incase of replacements. When a serial is to be scrapped using WEEE type procedures, before being disposed of, they must be stored in a warehouse; they will be set the status To Be Recycled. Limited changes are possible on serialized items that have the Active status. When adding service orders or covering the item under contract, it is checked whether the status of the item is active. 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, can be covered by a service contract and a warranty. Repair warranty duration can be defined on the details. 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; 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 effective or outdated. The view tree option allows 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 functional importance. 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

15-4

| Service
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; by linking the cluster to a work center or department, you can designate the cluster as internal.

Item breakdown
Usually, an item breakdown is an origin of physical breakdown structures. An item breakdown consists of relationships between various items to form a hierarchical structure of assemblies and subassemblies. An item breakdown makes up a generic bill of material 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 allow this, the top item must be defined as serialized for the configuration control in the service item data. This is to ensure 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.

Methods adopted in creating configuration structures

Three main methods are available to create a physical breakdown structure using a process; each method is based on relevance: Copied as an As-Maintained structure from an As-Built structure from ERP LN Manufacturing. Alternatively, you can also copy an As-Built structure from a Manufacturing or PCS project as a physical breakdown structure. Copied as an As-Maintained structure from a production bill of material from ERP LN Manufacturing. You can copy standard items and customized item structures. In this case, consistency checks applicable on production bill of material are applicable. Copied from a Project structure with the structures underlying Element or Activity structure with the structures material lines. In this process, you

Service

| 15-5

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 only be derived from 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.

Grouping, usage, and history

You can classify an item breakdown by functional element, which is a term 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 useful in categorizing skills to be used while planning. This also forms a logical grouping for querying and reporting purposes. A Graphic Browser Framework is available to visualize the configuration breakdown structures throughout ERP LN 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 improved ease of use in selecting the features.

15-6

| Service
Currently, a history of the physical breakdown is available to keep track of all events that happened within a structure. This log is updated regardless of the origin of the change. A difference report can also be obtained to know the changes that have occurred to a structure between two different dates. 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 customers primary link into the service environment. In Call Management, you can register and 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 individuals queue; subsequently, the call can be taken up for processing. Calls can also be assigned to a business partner (subcontractor), for which e-mail is used 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 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. Incase of product recalls, calls can be linked to a Field change order. The work done by dealers of the OEM can be registered and transferred to field service orders. 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 controlled response time. Calls can escalate if they are not solved within the agreed timeframe. Additionally, logging what is done, and by whom, is automatically carried out. This feature allows 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

Service

| 15-7

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 centers 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/employee. The employee can be the service manager. Diagnose tree. Calls can also 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, ERP LN Service suggests a predefined solution through a solution control structure. Probability analysis tools can help you find out more effective solutions in various situations. Call Resolution: Calls can be resolved by providing assistance to customers over a network such as e-mail, telephone, or other media. Calls can be transferred to Field Service for resolution incase a visit by Field Service engineers becomes necessary. Calls can also be transferred to Maintenance sales orders incase 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. Also, 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 allow 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. Additionally, these views also provide an insight into the sales orders under process for this customer and keep better track of possible new installations.

15-8

| Service
Repair history & bad fixes
Some details calls and service activities carried out must be available for the call taker if the customer calls. 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 ERP LN Service.

Escalation management
Calls that run out of time must be controlled, and 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 made, about when these changes are made, and who makes them.

Contract Management (CTM)

Service contracts are important because 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.

Service

| 15-9

Reference activities can also be included in a contract, along with various configurations such as clusters or serialized items. If a sales representative agrees 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.

Contract master data

The following information can be maintained in the master data and is important 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. Also, 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 occur. 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 ERP LN Service.

15-10

| Service

Contract templates
These templates are 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 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 types can be posted to contract history. Typical features include the following: 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 and 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 made to the quotations under selection and then sent to the customers again; otherwise, you can simply cancel the quotations.

Service

| 15-11

Contract control
An active contract can be derived from a processed quotation or defined from a directly defined contract. A contract consists of a set of financial and logistic terms, and also configuration lines that provide a list of equipment/assets covered by that contract. It also 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 regards to a service contract are similar to a contract quotation: financial information such as currencies, exchange rates, taxes, revenue recognition methods, installment methods, and 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 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, and 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 the header. 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.

15-12

| Service
The costs mentioned here are forecasted costs and you must periodically compare these 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 and controlled with the customer: 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. To quickly use all 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. Coverage methods supported by ERP LN Service are as follows: Fixed Price: All the work implemented on the orders is covered without charging the customer. Coverage percentage: The contract covers only a part (the percentage) of the implemented 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.

Service

| 15-13

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 carrying out changes to an existing contract agreement, such as adding more configuration lines, changes to prices and discounts, and so on. Indexation is to apply price increments/decrements based on changes occurring to the consumer price index. You can define and activate changes 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 manually link a service contract to a subcontracting agreement.

Contract Financials
You can define and invoice the installments. You can transfer these installments to ERP LN Central Invoicing. The accounts receivable and so on are automatically updated in ERP LN Financials. The invoiced amounts can be booked to ERP LN Financials according to the defined ledger accounts.

Contract revenue recognition

The processes related to revenue recognition available within this module are used to delink 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 contract conditions are met. You can also 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.

15-14

| Service
The revenues recognized by these processes are reported to ERP LN Financials into the appropriate ledger accounts and in the appropriate periods.

Contract history
When active contracts are not renewable and exceed their expiry dates, they can be set to expired. 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 expired or canceled contracts that are settled in every respect can be closed.

Subcontract Management (SBM)

Often, a company does not deliver the entire offering of Service, such as in the case of Products. Sometimes, the entire service of a product is subcontracted to a Supplier. The customer still has the advantage of one main contractor as contact. For the main contractor, proper registration is required to align the contractors 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. 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 allows you to use preventive maintenance for assets in an effective way; these assets can belong to your customers or could be your own internal assets. The planned activities can be covered by service contracts and could be agreed with the customers and, therefore, must be automatically controlled by the service order system.

Service

| 15-15

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 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, 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 perform 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, and maintenance planning can then be generated. 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, service activities, 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 customers 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 service planning can be generated for items linked to clusters and items which are not part of any cluster (Independent Serialized Items). The planning can be modified. Each time you generate a planned activity for a work center or machine, the downtime can be reflected in Enterprise Planning.

15-16

| Service
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 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 implementation of the order, then process the order, book costs, and trigger invoicing. To perform on-site repair, replace, or upgrade the serialized items or the clusters containing them, service orders are used to plan and carry out this effectively. Various types of orders can be defined, such as internal and external orders, Orders related to the work performed by dealers, scheduled and notscheduled 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, and the costs can be charged to the production or sales department using separate ledger accounts. Service orders can integrate with external applications, such as ERP LN Service Scheduler or ERP LN 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, Planning and Concepts module, and ERP LN Project; however, service orders can also be manually created. If required, the service order can be created from a quotation. Another way to create a service order is to generate orders out of

Service

| 15-17

the FCO functionality. Service orders can be defined and processed on active PCS projects, or on delivered PCS projects. The service order can have several statuses throughout the order life cycle, ranging from Free to Closed. These statuses allow you to control the service order. Interruption is a substatus you can use for parts non-availability, or because the customers asset is not available for 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 allow Global SRP to plan the order, which means the parts required be allocated to the warehouse or purchased. The activities are soft allocated to the preferred service engineers for a configuration. The ATP values of the spare parts required can be checked during the planning; based on the ATP dates, the activities can be rescheduled. 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 implemented. If intelligent scheduling is required, this can be achieved by service scheduler or 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; this step would release warehouse material (if stock is available), and allows you to start implementation of the orders. Emergency calls can be directly transferred to service orders in Released status. Interrupted: For some reason, the order cannot be carried out, such as hold for parts or asset not available. This is a substatus within the status Released. Ready (or Completed). The job is finished, material used, hours used, and so on, and can be entered in ERP LN. Costed: All costs and expenses are booked to the service order and 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. A batch process can also be run to cost range of service orders, service order activities, or service order cost lines. The invoice line can be sent to ERP LN invoicing in On Hold or Confirmed status. Closed: The invoice process is also carried out, which means 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.

15-18

| Service
The steps to complete also depend on the service procedures selected. For example, if 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 on a selection by you through a Service type; repair warranty offers 100 percent coverage.

Dealer Warranty Claims

Dealer claims can be registered as service orders. A call can also be created and transferred as a dealer claim service order; the registered claim can be approved or rejected. The approved claims can be costed, which results in a credit note. Dealers are reimbursed with the cost using the credit notes.

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. Additionally, the preferred engineers are soft allocated for the orders that must be carried out. In the second stage, at 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 ERP LN Service Scheduler or ERP LN Service Scheduler Assistant. These tools feature various planning constraints to use the engineers more efficiently and have high visibility of field service activities. In Call Management, Contract Management, and Planning and Concepts, the service activities are defined in this module. From the service quotation, you can also create a service order. The following planning constraints and resource checks can be valid for the whole planning cycle; remember 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/location can be combined to work more efficiently, particularly with calls. Response time: The response time agreed in the contract, warranty, service order, or call to fix the problem.

Service

| 15-19

Skills engineer: Without the correct 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. Overtime: Overtime allowed for an engineer is another check that can be performed. Available parts: Without available parts for the service order to be carried out, you cannot reach a high first-time fix rate. If the correct part is not available, an alternative part can be delivered. The alternative items can be selected based on the main item under repair. Service kit allocation: To perform a service order, sometimes a service kit is required; therefore, it must be planned and allocated. Asset calendar: A calendar in which the availability of an asset can be checked, such as 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 performing service activities. When recording the measurements while performing service order activities or based on a customer or 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 added as a new service order.

ERP LN Service Scheduler and ERP LN Service Scheduler Assistant

The planning constraints can be effectively visualized or utilized to plan service orders by using ERP LN Service Scheduler or ERP LN Service Scheduler Assistant. ERP LN Service Scheduler is a visual, graphical, and interactive tool that provides the dispatcher control over planning and scheduling of service

15-20

| Service
orders. Scheduler helps visualize orders in various statuses with various resources and allows user-friendly features to be used to achieve efficient scheduling, such as drag-and-drop. ERP LN 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. 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, and keeping in view constraints and certain other field service dynamics. However, tools such as these and Infor E-Service Remote are outside the scope of ERP LN 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 (ERP LN 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 doctors visit, and so on can also be reported. The costs can also be entered in the remote service application such as Infor Mobile Service (formerly called E-Service Remote). For possible invoicing, which depends on the contract or warranty agreed, you can transfer the costs by remote access to ERP LN Service directly from the field. Order costs/amounts can be covered by any applicable/valid agreements such as service contracts, warranty, repair warranty, service order quotations, or FCO based on the applicable discounts in each case. Incase of dealer claims, the order can only be costed when claims are approved. 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 allows you to get a quick overview of the costs on the Service orders.

Service

| 15-21

Invoicing
The invoice process is triggered when you set the order or activity status to Costed. The cost lines that underlie the order or activity are sent to ERP LN Invoicing, from where further processing is carried out to send the invoices to the customer sites. Depending on the situation, 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 a maintenance sales order can be combined with a service order into a collect invoice to prevent bureaucratic trouble in the financial department. In the background, the ledger accounts in ERP LN 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 ERP LN Warehouse Management. 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, it can be delivered by the overnight service; if the part is not available, a purchase order is created. The items that must be purchased can be received in a warehouse and can then be issued to the service order, or the supplier can be directed to issue the material directly at the customer site. Incase of supplier direct delivery, the non-consumed items can be returned directly to the supplier or can be received in a company warehouse. Optionally, users can generate freight orders for the goods transport from the supplier to the customer, or vice versa. The freight cost can be invoiced to the customer by the service department or the freight office. The freight costs, when invoiced by service department, qualify to be covered against a service contract or a warranty. Sometimes, the freight cost can also be ignored. Defective parts may need to be received mandatory from the customer for verification. Such lines can only be costed when the parts are received in the warehouse. 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 customers location.

Component replacements
A replacement or change in the customer's configuration means the configuration is updated with the correct serial number and other information.

15-22

| Service
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 the replaced component must be returned. When the parts must be returned, a warehouse order of the type Receipt is created in the warehouse. You can send these parts back to designated warehouses to be taken up by work orders to complete repair of parts. Alternatively, the service engineer has probably drawn excess parts from warehouses to perform 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 begin 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 implement 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 service activities free of cost, due to FCO.

Audit trail
For audit trail requirements, you can track and trace components and parts. Therefore, 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, such as 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

Service

| 15-23

basis. The integration with Object Data Management applicable to document controls can also help the purpose of audit trail.

RMA and Depot Repair

This section consists of the ways 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. Depot repair is achieved through work order handling. Work orders also allow 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 own serial numbers. Unless items are consumables or of generic interests, the parts are serialized and configuration controlled.

Maintenance Sales Quotations (EPP)

When a customer who is seeking repair of an item approaches a service provider, the customer will probably ask for a quote for the repair. A Maintenance Sales Quote gives an indication of the costs involved in the repair. Quote gives the ability to give discounts and considers all applicable obligations such as warranty and the contract for coming up with the final quote amount. Quotation can have following statuses Free when a quotation is created. Printed when the quotation is printed and sent to the customer. Accepted when the customer accepts the proposal. Processed when the quotation is processed to a maintenance sales order. If the customer does not agree to the proposal, the Quotation status will be set to Canceled. Maintenance Sales Quotation functionality offers the following features: Agreement with the customer for repair price. Processing a quote to Maintenance Sales Order. Invoice the Maintenance Sales Order according to the quote.

15-24

| Service
You can also interrupt maintenance sales order line (part maintenance) or work order and raise a quote. Acceptance of the quote can be triggered from part maintenance line or work order or quotation, which will remove the interruption and work can proceed.

Maintenance Sales Control (MSC)

Maintenance Sales Control offers features related to RMA and also more. The maintenance sales order is the heart of Maintenance Sales Control. Maintenance sales orders can be registered by entering them directly or transferring the orders from a call. Each maintenance sales order can handle a number of part lines. 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 service customer owned warehouse to successfully carry out repair activities as a part of depot repair. A linked up work order is necessary when the repairs are implemented 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 service customer owned, from where the item can be returned to the customer. Due to some reasons, if the part cannot be returned to the customer, the part maintenance line can be converted to a part receipt. Part delivery: If parts must be delivered to a customer, this delivery is done through a parts delivery line. Customers may require new or upgrade type subassemblies or additional parts. The parts delivery lines allow 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. Sometimes, return of parts might occur instead of parts delivered, or it might be parts returned as a part of rejection, or sometimes it might be outdated parts sold back at reduced prices. All of these issues are handled as parts return lines. By combining parts receipt and parts delivery lines, parts exchange is performed; 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. Part loan: During the absence of the part due to repair or the temporary nature of part use, the customer would require a loaner for a short-time which the customer can use for a limited time and then return the part. Incase the

Service

| 15-25

service office decides the loaned part does not need to be returned to the service organization, the part loan line can be converted to a part delivery. The user can mention if the freight orders must be generated for the material receipts from the customer and material issues to the customer for all the above mentioned maintenance sales order line procedures. If the option to generate the freight orders is chosen, freight orders are generated in the ERP LN Freight management module. The freight cost can be invoiced to the customer by the service department or freight office. It is also an option to ignore the freight costs. In all the previous cases, you can invoice the customers for the services and parts rendered. You can offer service contract, warranty coverage, or repair warranty coverage for part lines already involving 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. If required, after the parts are delivered against the replacements and loaner items received back after use, the maintenance sales orders can be invoiced by sending the coverage lines to ERP LN Invoicing. By looking into the gross or net margins on the coverage lines of an order, you can perceive the profitability of the order and modify before sending to Invoicing. The costs and revenues are posted to appropriate ledger accounts in the ERP LN 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. The 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. Another functionality of the routing is having routing options. Using 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 one item.

15-26

| Service
Work order structure
The carrier for work to be implemented in ERP LN Service is the work order. Work order can be created in the following ways: The work order will be created on receipt of the to-be-repaired Item, which is triggered by the maintenance sales order. The user can also manually create work orders. The work order can also be generated in a batch for similar items owned by the organization (Internal Items) which are defective. This feature is applicable only when the item is serialized in inventory. Such Work orders are termed as Batch Repair Work Orders. The batch process will generate a work order for each item and work order resource lines will be created with the defective serialized items with delivery type Batch Repair. A work order can have activities linked. These activities can be freely entered or can be created using the templates as described previously. Incase of separate flows of repair of subassemblies and components, you can use follow-up work orders, which can result in an entire structure of diverging and converging work orders.

Work order implementation

A work order can be planned, released, completed, signed off, and closed. Additionally, the work orders activities have unique statuses quite similar to the work order statuses. By parameter setting, you can decrease the number of statuses, such as 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; additionally, tools and general costs can be estimated. Incase of Batch Repair work order, a transfer warehouse order will be generated from the warehouse in which the defective item is present to a central warehouse. An issue warehouse order will be generated to issue the item from the central warehouse to the service depot. 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 allow this, linked purchase orders are generated with the planning process. Delivery of these types of purchase orders also indicates the completion of work orders.

Service

| 15-27

If required, you can create follow-up work orders to provide repaired parts or subassemblies. 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. Customized items can be produced in depot scenarios. If the order is carried out according to the engineer, the work order status can be set to Completed. However, the user can still register hours, and so on. Subsequently, an authorized engineer can sign off on the order and close it. 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. Incase of a Batch Repair Work Order, the repaired part should be returned to the original warehouse. Therefore, a receipt warehouse order will be created from the service depot to the central warehouse, and a transfer order will be created from the central warehouse to the original warehouse of the item. A provision is provided to view the repair costs of a work order in terms of Material, Labor, and other costs. After this step and reconciliation, the work order can be posted to history or deleted.

Master Data Management (MDM)

The data used throughout ERP LN 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.

15-28

| Service

Service organization

Service Department/Service area

The service organization consists of resources and relationships; specifically, these are 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 Subservice Department This division of two entities is to model your organization in a way that provides information about capacity and implementation abilities. For planning reasons, these entities must be treated as one large group without any department borders.

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. The following four types of warehouses are allowed and used in the Service package: Normal Warehouse: A Warehouse used for Production, Sales, Purchase, and Project can also be used in Service. This indicates a Warehouse in a fixed location. Transactions are like any normal Warehouse. Service Warehouse: A Warehouse similar to a normal warehouse but can only be used in the Service domain. Transactions are also similar to a normal Warehouse, but confined to Service domain. Service Reject Warehouse: This is a Warehouse like a normal warehouse, except it is used especially while returning parts that may 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 used to store parts belonging to Customers. While receiving parts into this Warehouse, the companys inventory does not go up or 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 linked with a warehouse (of the type normal or service). A Service Kit is defined and

Service

| 15-29

used in Service domain, but the inventory transactions are done as in any Normal or Service warehouse, including the replenishments. Service cars: A Service car is a mobile Warehouse, and has a 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 by Service, 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. A service kit can be related to a service warehouse or model. You can use the service kit to store spare parts and tools required for the repair activities of a specific asset. To perform service on an asset, ERP LN Service can allocate service kits. A service car can have the function of a warehouse. The spare parts required for the service orders to be performed 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 used mostly for service-related activities, such as carrying out orders, registering or handling calls, sales representatives for service sales, foreman, dispatchers, or handlers. Each service employee must be defined with General and People (HR) related details for correct functioning. Each service employee can have a linked service car and must be defined with user profile details 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, 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. 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 and labor types can be defined and used from ERP LN People. Skills and certifications can also be added as ODM attachments.

15-30

| Service

Service item data

Materials often form one of the important resources while implementing service on products. Service item data deals with details used when 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. Similar to defining defaults to be used with an item group, you can easily define a new service item. You can define details concerning 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; items of the type Service or Cost account for subcontracting purposes. You can also define customized items, which is 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 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 ERP LN Order Management Pricing can be used while using items as spare parts. Each item also inherently carries a unique generic price.

Reference activities and inspection templates

The reference activities and inspection templates repository of activities is based on a service organizations experience. These activities are service activities that can be implemented 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 may apply. A reference activity can also contain details about recommended ways to perform, such as duration or suggested frequency of implementation. This can also suggest whether the activity is recommended for subcontracting.

Service

| 15-31

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. Additionally, 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 implementing service activities. Inspection templates are particularly useful while carrying out field service or 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 implementing 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 wholly or partially performs 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: Any variant that cannot be accounted for in any of the earlier categories can be accounted for under this cost type.

15-32

| Service
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, by changing the coverage type you can deny agreement coverage.

Sundry service related definitions

Service type or Service order type

Service 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 logistic and financial analysis; it can also be used to differentiate repair warranty application. Optionally, the warehouse order procedures of type Issue and Receipt can be linked to a service type, which will provide the flexibility to have different warehouse procedures for different service types. During Service order release, these warehouse order types will be used while creating the warehouse orders for the material line(s) under the service order activity. If no warehouse order types are linked to the service type, the warehouse order types defined in Default warehouse order types by origin will be used.

Tasks A task is a specification of short-term work performed 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 conditionbased maintenance can be assessed. This generic definition is used elsewhere based on the context.

Service

| 15-33

Maintenance concept
A Maintenance concept is a list of Reference activities with a schedule proposal, either attached to an Item or not. Using the Maintenance concept, it is easier to generate Maintenance planning for similar Items.

Routing
A Routing is a Repository of a set of activities categorized by options, which is defined together and might be selected while carrying out Depot repair.

Related Orders
A possibility to view the related orders of service orders, maintenance sales orders, and work orders is provided. The related orders could be the generated warehouse orders, purchase orders, or freight orders. This view is possible from the following: Service Orders. Service Order Activities. Service Order Estimated Material lines. Service Order Actual Material lines. Maintenance sales orders. Maintenance sales order lines. Maintenance sales order Coverage lines. Work Orders. Work Order Material Resources.

Service Analytics

Calculate Service Performance Indicators

The following can be calculated on Service installations (Serialized item/Cluster): Availability of the serialized item. Mean Time to Repair (MTTR). Mean Time Between Failure (MTBF).

15-34

| Service
Calculate Uptime analysis
The comparison between the uptime promised as part of service contract for a serialized item and the actual uptime of a serialized item can be made.

Calculate Repair Costs

The repair costs on calls, service orders, and maintenance sales order for a serialized item/cluster can be calculated and printed.

Module relationships in ERP LN Service

This section describes the relationships between various modules in the ERP LN Service. This section describes the following relationships between the modules: Master Data Management (MDM) Provides definitions and links with every other module within ERP LN Service if service engineers, the service center, service area, skills, or any other service-specific table is used. This module allows the definition of service related details of items and 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 performed. 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, such as 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. Calls are transferred to

Service

| 15-35

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 and PM schedules are defined in the SPC module. To complete 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, and 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 performed through work orders. Work orders can be carried out on anonymous items by retrieving them directly from the warehouses, or on customer-specific items originating from the MSC module. Parameters Here, you can set the operating conditions of the ERP LN Service modules. This module affects the operation of every other module The following figure shows the coherence of the ERP LN Service components:

15-36

| Service
CFG
Serialized Item History Clusters & Physical Breakdowns
Plan time Appointment Activity

Item Breakdowns

Response Times Problem track Asset ID

SOC

SPC
PM terms PM Schedule

CLM

Response Time Helpdesk terms

CTM
Sub-assemblies Support

SBM

Product support Part Services

MSC
Repairs Plan time

Repair terms Cost coverage

P a r a m e t e r s

WCS
Service Items Service organization Reference Activities

MDM

Chapter 16 Quality Management

16

Introduction
This chapter provides an overview of the functions and features offered by the ERP LN Quality Management application. ERP LN 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 reach the required quality. Quality Management uses a logistical flow of products to schedule inspections. In every company, products, raw materials, end products, and products inbetween manufacturing steps are regularly inspected to ensure the procedure runs smoothly. This is to review what went wrong, or determine what could go wrong during production, distribution, or during the time products are in inventory.

Product Testing and Control

Introduction
Product Testing and Control (PTC) is the only module in ERP LN Quality Management (QM) that governs the activities required to control the flow of products selected for inspection. The basic product data structured by the characteristics will be inspected in QM, and the PTC module performs the entire inspection procedure. The basic data on which the products are inspected must be setup. The inspections can be carried out on the following:

16-2

| Quality Management
Purchased products. Sales Products. Manufactured Products. Products stored in Inventory. Products during Warehouse Transfer. The following figure shows the PTC module in ERP LN QM:

Warehousing

Sales

Quality Management
PTC

Production

Purchase

Quality Management

| 16-3

The following figure shows the Modules related to PTC:

Item Data WMD IPU IPD ISA IBD SFC INH Orders and Schedules PUR SLS

BOM

PTC

COM

ROU MCS

INR

QM inspection orders can be generated for the following origin orders: Purchase orders in the Purchase (PUR) module: ERP LN Order Management. Sales orders in the Sales (SLS) module: ERP LN Order Management. Production orders in the Shop Floor Control (SFC) module: ERP LN Manufacturing. Storage inspection orders in the Inventory Reporting (INR) module: ERP LN Warehouse Management. Warehouse transfer orders in the Inventory Handling (INH) module: ERP LN Warehouse Management. The item data 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:

16-4

| Quality Management
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 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 in this chapter: Master Data Algorithms Quality IDs Order-Specific Inspections Standard Inspections Storage Inspections Inspection History QM Parameters

Quality Management

| 16-5

The following figure shows the Main flow between the business objects in PTC:

MCS COM WMD WMD ISA Master Data Origins SLS Calibrations Quality IDs PUR SFC INH ROU BOM Item Data IPD IPU IBD

Order-Specific Inspection Data

INR MCS

Standard Inspections

Storage Inspections

Inspection History

Master data
The Master Data business object is used to specify the products and procedure that must be inspected. The inspection of the selected products is performed based on characteristics. The characteristics specify the part of the item that must be inspected. The Master Data business object receives data about units, departments, skills, locations, employees, warehouses, and so on from the following: System Tables (MCS). General Data (COM). Warehousing Master Data (WMD).

16-6

| Quality Management
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 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 specified test is to be linked to a characteristic, or to an aspect/characteristic combination. For each test, the characteristics value can be qualitative, which means the characteristics value is determined as good or bad, or quantitative. In other words, the characteristics 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 the quality of the product falls in the established quality level. You can enter the calibration data for every instrument. Some of the instruments 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 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 a matter of taking measurements on characteristics; based on measurements, complex calculations are

Quality Management

| 16-7

sometimes 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 a characteristic method. Each algorithm is an expression containing the variables and standard mathematical expressions you can use in the algorithm, such as logarithms, sine, cosine, and so on. 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 considerably reduces time. QM uses test groups during the generation of inspection orders. For each test group, the test type and sample size data must be provided. The test groups must be linked to a quality ID. For each test group 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 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 related to the characteristic or the characteristic/aspect combination can be modified. The norm value 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, a bill of material, or a business partner the items have in common.

16-8

| Quality Management
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 Purchase Production BOM Routing Inventory Handling - Sales Order Lines - Purchase Order Lines - Production Orders - Estimated Materials and Materials to issue for Production Orders - Production Planning - Warehouse Transfer

Inspection orders are used to structure the inspection of products that are purchased, produced, or sold. Inspection orders are automatically generated 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 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.

Quality Management

| 16-9

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 by the company. Order-specific inspections are used when the inspections are deviated from how the inspections are defined in the quality combination, such as when a specific characteristic is to be inspected on a product 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 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, orderspecific inspection data is generated. The order-Specific Inspection data includes the test data and 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. Orderspecific inspection data is linked to the orders and schedules in the Sales (SLS) module, Purchase (PUR) module, and the Shop Floor Control (SFC) module. However, the actual inspection order is generated based on the warehouse order related to Sales, Purchase, or Shop Floor Control. An exception to this is the origin Routing. Routings inspection orders are related to the operations of the Shop Floor Control order.

Standard inspections
The overview of the standard inspection orders for which inspection orders are created can be seen 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, the inspection-order status, and the blocking method, and the result of inspections can be displayed. The

16-10

| Quality Management
link between the origin and quality ID is established through the quality combinations. QM uses the data in the Master Data business object and 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 defined in the QM parameters. After a standard inspection order is created, but before the inspection can be performed, 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 specified for that inspection order. Each sample can be subdivided into test quantities; a test quantity is the smallest portion of items 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 only enter this test data for the order lines that were maintained in the standard inspections and 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 and inspections for each inspection order line is sufficient. After an order line has been completed, you cannot add, modify, or delete any inspection data; however, you can change the status of the order line from Free to Active. The inspection orders must be processed, and can be used to evaluate the test results 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 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

Quality Management

| 16-11

been reported in the purchase procedure, sales procedure, or production procedure, and compares the quantities with those entered in PTC. A report is generated that displays the compared quantities of the origin and PTC. To keep track of an inspection order, 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 Free Active Completed Processed To status Free Active Enter Test Data by Serial Number. Completed Processed Closed Complete and Process Inspection Orders. Complete and Process Inspection Orders. Check and Close Standard Inspection Orders. Session Inspection Orders. Enter Test Data by Characteristic.

By default, the order status is 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. After the inspection order line has been completed, the order status changes to Completed. When all inspection order lines have the order status Completed, the entire order is set to Completed. After you complete an order line, you can no 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 the existing inspection data will be deleted, and new inspection data from the master data will be generated.

16-12

| Quality Management

Storage inspection
Storage inspections are used to maintain the inspection orders and results of storage inspections for items in the inventory. The items for which a storageinspection 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; later on, the storage inspection can be closed. Incase of destructive inspections, you must manually adjust the inventory. The storage-inspections procedure begins with storage inspection generation and the selected items inventory gets blocked. You can manually add the new inspections and 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 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 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 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 complete the following two steps to finalize the storage inspection order:
1 2

Enter the test data by characteristic or serial number. Complete and process the inspection orders. After the storage inspection is processed, you can close the storage inspection where the accepted and rejected quantities will then be unblocked. Calculate whether the accepted and rejected quantities match the recommended quantities; if these quantities match, the storage inspection order is closed. The status of the inspection order is then set to Closed.

Quality Management

| 16-13

If rejected quantities exist, they must be subtracted to adjust inventory. Because inventory actions cannot be performed automatically, you must manually correct this.

Inspection history
You can archive inspection orders for future purposes using 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 split into inspection order, position, and sample can also be printed depending 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

16-14

| Quality Management
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 the following: Sales Inspection Orders. Purchase Inspection Orders. Production Inspection Orders. Material Inspection Orders. Routing Inspection Orders. Warehouse Transfer Inspection Orders. Storage Inspection Orders.

Quality Management

| 16-15

Blocking reasons
You can provide the reasons for various inspection statuses for Block on Operation and 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 ERP LN Quality Management when the order is defined in the Quality Management parameters.

Chapter 17 Object Data Management

17

Introduction
ERP LN Object Data Management (ODM) ensures product data is handled correctly and the most stringent product life-cycle management processes are applied. ERP LN Object Data Management extends the power of ERP LN while creating an integrated product warehouse, which results in a complete life-cycle management solution. The ODM solution exposes important product information to any number of business entities in the enterprise, including sales, marketing, financials, customer support, and so on. ODM allows you to access, view, and change product metadata and physical files, given the appropriate level of access. ODM also helps you manage data in a way that allows you to increase productivity and reduce time to market, because businesses need enterprisewide solutions to maintain the competitive edge. ERP LN ODM offers ERP LN users easy access to documents in a globally distributed setup. With its revision and status control capabilities, ODM becomes an important component towards providing a complete product lifecycle management solution. ODM provides fully integrated Document Management, Change Management, and Folder Management facilities for ERP LN users. You can use a query to retrieve data based on user-defined conditions of any ERP LN entity. An advanced query allows you to view ODM entities in a report format. ERP LN ODM improves the power of ERP LN through the ability to link external files to the ERP LN entities, and manage these files linked to document revisions. The life-cycle management system is available for documents attached to ERP LN entities such as Items, Routing, Employees,

17-2

| Object Data Management

Purchase Orders, Sales Orders, and so on. A predefined set of entities is available but can be extended at will. 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 the most recent, correct version is always available. The associated files can easily be viewed 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 and consistent change management practices due to delivery time constraints, quality improvements, and cost reductions, which are all driven by the need to maintain customer satisfaction. Change management offers tools to control product change processes and can be used with multiple ERP LN entities for ensuring 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 ERP LN ODM to quickly search the ERP LN data. The ODM browser is a graphical tool that provides a user-friendly display of the data and data links. The Graphical Object Browser allows navigation through complex hierarchies, while presenting multiple entities and their related items as a tree structure.

Overview features of ODM

The following are overview features of ODM: Establishes a coherent product information warehouse across the extended enterprise. Allows revision-controlled document and file links to any ERP LN entity. Provides secure online access to a globally dispersed product information repository. Allows 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.

Object Data Management

| 17-3

Facilitates ISO/QS 9000 certification by ensuring tight control and traceability of product and process information. The following diagram shows the integration of ODM with other packages of ERP LN:

ERP LN 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 ERP LN. Document Management ensures the efficient use of secure, consistent, and reliable document information through of the following 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 ERP LN database. Document templates.

17-4

| Object Data Management

The standard ERP LN ODM authorization mechanism is used to determine the actions to be performed by individual users on various Document Management entities. The set of actions a user can perform on a document, file, or any other object, depends on the users role. User roles are assigned permissions to perform different operations on different objects, using the ERP LN 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, and 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; 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 also be kept in the related vault areas.

Object Data Management

| 17-5

Document type
Document types are assigned to documents. The document type is used to define the document revision mode; it can also be used to define the document identifier mask and 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 consisting 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. The user can also attach more than one template file for a particular document type, only if 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, only if 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 ERP LN 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, usually 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 through the document revisions. Document revisions are assigned a status, which indicates their position in

17-6

| Object Data Management

the life cycle, such as In Design, Submitted, Approved, Released, Expired, Withdrawn, and so on. The file operations that can be performed on a document revision depend on the revisions status.

Document reviewers
The reviewers are imported to the document based on the document type and associated committee to the document. The default committee can be changed at the time the document is created, and the reviewers can be individually assigned to the document.

Document revision
The key functionality of a document life cycle is as follows: 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 so 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, such as some types of reports and 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 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, attach files or hard copies, and can proceed with the life-cycle operations of document revision.
Submitted The document revision has been submitted for review. When the

Object Data Management

| 17-7

document has this status, any user with the necessary authorization can view the document files and redline the linked files. The files are moved from the work area to the vault area 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 and the development of the document has been successfully completed. The files are moved from the work area to the vault area defined for the document library incase of light documents. Rejected The document revision has been rejected at some stage of the review process. No new links can 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. All the files can be copied to the default work area of the user depending on the necessity of the files. Withdrawn The document revision has been withdrawn and the content is obsolete. No links can be made to this document revision. A document revision can be withdrawn even if it has links to any ERP LN 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, but can be used to define inbetween statuses.

Document Revision Reviewers

The review process can be of two types: normal-reviewers mechanism or fixed-reviewers mechanism.

17-8

| Object Data Management

For the fixed-reviewers mechanism, the review is carried out in sequential order and reviewers must provide the recommendations to do the final review by the 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 a set of documents 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. Additionally, 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 ERP LN entities

The standard main overview session for ERP entities has a toolbar icon which resembles 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 easily linked directly to any ERP entity defined in ODM 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, the file is moved to a vault area. Files must be checked out before they can be modified. Files are checked out by the system as part of the life cycle. ERP LN ODM manages the files attached to document revisions; it maintains information about them, controls access to them, and assists in working with them. The document type of the document revision determines whether the files are assigned with revisions. The following cases show how a group of files can be attached to the same document:

Object Data Management

| 17-9

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, such as a CAD drawing of an item; one file is for viewing, such as an image of the same item; and another file is for printing, such as 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; depending on the requirement, it can also be detached with the document revision.

File operations
The following file operations can be done for a file 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 can 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 ERP LN ODM by attaching them to a document revision, and cannot be registered independently.

17-10

| Object Data Management

The document type of the document revision determines whether 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 objects can be seen with the documents of main object. The Entities involved in the integration process are as follows: ERP LN Services. ERP LN Order Management. ERP LN Manufacturing. ERP LN Project. ERP LN People. ERP LN Freight management. ERP LN Warehouse Management. ERP LN Financials. ERP LN 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. Example: Mobile Service (ESR).

Object Data Management

| 17-11

Architecture of Document Management in ERP LN ODM

Worktop scenario
BW Client Baan server ERP LN A java function, which invokes OD MCs V Client on ERP ault S erver. This J ava function is invoked by Baan4GL using JV M. Vault Area

Baan Windows

Work Area

V ault JVM Integration J ava Code (jar file) placed in ERP Server Vault server Vault client

File S erver Work Area Vault Server V Area ault

Web UI scenario
MS Client Signed Webtop Baan Server Baan ERP A java function, which invokes ODMCs Vault Client on ERP Server. This Java function is invoked by Baan4GL using JVM Vault Area

Work Area

HTTP/XML Firewall JVM integration Java Code (jar file) placed in ERP Server Vault Vault server Vault client

Webserver

DS

File Server Webtop DS Connector Webserver Vault Area Work Area Vault Server

17-12

| Object Data Management

Change Management
Introduction
The Change Management module provides tools for registering and controlling changes. Change control is a complex and 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 changes. Because of this flexibility, the Change Control module can be leveraged for use with a variety of entities in ERP LN. The Change Management module interfaces to other modules in the ERP LN ODM package and elsewhere by using a sophisticated interface mechanism. This mechanism also allows links of objects from other packages and modules to the Change Management module.

Others BOM Change Management IPD

UNIT ROU EDM PUR

Change Management relationships with other packages of ERP LN

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, which allows linking to a specific object and interfacing to the objects application.

Object Data Management

| 17-13

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 organizations most important and complex process. ODMs Change Management module provides the flexibility of creating and maintaining a change process to optimize an organizations Enterprise Resource Planning (ERP) system. The following figure shows 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 the following four principle components of the change process: Registration: The authorizations and rules for changing an object, such as items, operations, effectivity, and so on. Identification: An identifier assigned for every managed object. Configuration: The method of defining the products configuration, and maintaining the configuration throughout the products life. Implementation: The method of implementing the change and completing the change process.

17-14

| Object Data Management

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. The Change is a permanent identifier which will group all the similar CRs together and allows the user to track the managed object through the Change Management life cycle. The Change Proposal allows the user to link affected ERP objects, set effectivity dates, attach task groups with tasks, and connect to reference items. 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 with the Chairperson of the Committee. The Chairperson, after studying all the recommendations, can approve or reject the proposal of a Change. The Change Order implementation function allows the user to update the task status and revise the task implementation dates; finally, the change is completed.

Registering a change

Configuring a change

Review by Change Committee

Accepting a change

Implementing a change

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 implementation 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, such as ISO 9000, MIL-SPEC, and so on. Speed: Speed up time to implement the changes.

Object Data Management

| 17-15

Functional objectives
Full Change Management: The data, such as 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 entire 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 use the design for the implementation phase after the change approval.

Change Management Life Cycle

The following diagram shows the change management life cycle:

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. It also allows the reduction of the number of changes being processed by

17-16

| Object Data Management

eliminating trivial requests, or by combining similar requests. The use of the change request is optional. The following steps are carried out using the Change Requests:
1 2 3 4

Registration Change Requests. Check existing requests for similar Changes, and combining them if any exist. Attach relevant objects. Assign responsibility for the Change.

Changes
The Changes is the second stage in the life cycle of Change Management. It is a database entity that represents the Change and 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, process, documentation, work instructions, and so on. Sometimes there will be a fixed group of reviewers where they can adopt fixed-reviewer mechanism or normal-reviewer mechanism. For fixed-reviewer mechanism, every member of the group will give their decision in a decided fixed sequence. The member cannot give their recommendation until the member prior to them gives their recommendation in the reviewer sequence. There is also a situation where 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 to approve or reject the proposal is final, regardless of the recommendations provided by the members.

Object Data Management

| 17-17

In the fixed-reviewer procedure, it is compulsory that reviewers give their recommendations sequentially. For example, when the user selects 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 must provide their recommendation; only after this operation can the second reviewer exercise their own recommendation. In this way, all the reviewers must give their recommendations one after the other. The final authority lies with the Chairman of Change Control Board (CCB), who can exercise their own recommendations without depending on those of other reviewers. The reviewers can play an indirect role in approving/rejecting any change. Whenever the reviewer gives the recommendation, all the reviewers and 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, because creating a new Change automatically establishes the default Proposal of the Change. The Change Proposal is a version-controlled entity and 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

Change proposal 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 or rejected. Tasks are Done: All the tasks attached to a proposal are done.

17-18

| Object Data Management

Change approval
When the Change Proposal is submitted for review (Approved in Direct Approval mechanism) the Change Control Board assembles 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 ERP LN 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 ERP LN objects that can be linked to a Change Proposal are as follows: Products or Assemblies E-Item Revisions Bill of Material lines Production Item Routing Operation Labor Types Surcharges Task Groups Tasks Any object used to link Change Management should be registered with the ODM package.

Change orders
Change Order provides a generic mechanism for changing any changecontrolled 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

Object Data Management

| 17-19

update a Change Orders effective date or expiry date from the Change Order. A Change Order can exist independently from a Change Proposal. A 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 implementation of the change order or change orders associated with it. This step includes the following operations: Perform 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 linked to the proposal having relative change order is logically dependent on the ERP entity 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, role, 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 with 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:

17-20

| Object Data Management

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 these relationships are strong or mandatory; others are weak or optional. Not all links can be hard-coded at design phase, as these are rarely used. Additionally, 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 an ERP LN 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 be linked 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: Provides fast retrieval of any kind of related information. Folders can be freely created for various subjects and then be divided into 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 ERP LN system. Folders are of two types: Shared or Personal.

Object Data Management

| 17-21

Any ERP LN object 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 who created it. The owner or the creator of the Personal Folder can mail the contents of the Folder; 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: The folder has only just been created, or is still under initial design process; therefore, it 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 ERP LN 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 ERP LN 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 ERP LN 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 ERP LN object.

17-22

| Object Data Management

Store the Query Result sets and rerun 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 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 allows 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 The queries and reports feature is consistent with compatible accepted industry quality standards, such as ISO 9000, MIL-SPEC, and so on.

Functional Objectives
Query management Report repository Print functionality Create complex Query Conditions, track of Queries, and storing Query runs. Implement reports that are grouped by object. Provide a standard interface for printing reports from the Document Management, Change Management, and Folder Management modules of the ERP LN ODM package. Establish a set of predefined reports for Object Data Management. Facilitate options to implement reports on query results.

Standard reports Query/Report Integration

The following business objects in Queries and Reports are described below: Query Query Conditions Reports

Object Data Management

| 17-23

Query

Introduction
There are three different types of Queries in the query subsystem. Queries can be defined based on a single object type or a set up of combined queries. The combined query is specified in the complex conditions of the Query. Base Query Previous Run Conditions are based on attribute values from the object definition table. Allows the user to use the results of a previous run of a different Query but of the same object type as the input for the current implementation. 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.

Linked query

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 defined for 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 as follows: 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 is as follows: =, <, >, <=, >=, <>, IN, BETWEEN, LIKE, NOT IN, NOT BETWEEN, NOT LIKE.

17-24

| Object Data Management

System Parameters are a set of predefined ERP LN 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; 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 obtained will be the data filtered from the data already stored 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
ERP LN Object Data Management provides numerous common infrastructure services available to all the modules in the package. The following business objects in Configuration are described below: Masks. Authorizations.

Object Data Management

| 17-25

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 on the mask defined by the user. A unique identifier represents almost all entities in ERP LN 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. Usually, 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; this is done by defining a mask configuration for the mask code or codes associated with the parameter. The mask configuration includes a mask composed of one or more mask template segments. Each segment is defined as Fixed Format, Generated Format, System Variable, or Reference Variable.

Authorizations
The ERP LN ODM authorization mechanism is a generic subsystem that provides user-defined authorizations. The authorization mechanism makes use of the ERP LN People tables for Employees and Roles. The scope of user authorizations is to enforce the authorization checks within the Data Management Package regarding Change Management (CHM), Document Management (DOC), Folder Management (FMG), and Queries. The authorizations facilitate the following actions: Defining Object Specific Actions. Defining Action Groups.

17-26

| Object Data Management

Linking Role(s) to an employee. Assigning Actions to ERP LN 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 can perform all the actions permitted for that role.

Actions
The Authorizations allows you to define actions for each object; every object may have many actions associated with it. Similarly, actions can be common to several objects, and some actions are defined as system actions. These actions are fundamental to the operation of the ODM package and, by default, 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 can 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, then the role is authorized to perform on the specified 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 an authorized user.

Objects and related objects

Any ERP entity which is defined in ODM with all its details is an Object where documents can be linked directly to it. The related Object is the object, which is related to the 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.

Object Data Management

| 17-27

Common ODM parameters

Common ODM Parameters are available for some attributes used in document management and change management modules. According to the requirements and specifications, an authorized user 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 automatic. The advantages of this approach are as follows: Simple maintenance. Time-saving mechanism in comparison with the manual approach. Code-saving mechanism. Flexibility in performing a set of actions. Possibility of including query condition.

Export and import of system data

The Data Management module includes an export and import feature; this 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 allows you to import files from any specified folder to ERP LN ODM. There are many cases where a user may import the files to ODM; some of these 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.

17-28

| Object Data Management

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 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 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 a 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 can be created for the imported files in ODM. You can also select the existing document in ODM to get linked to the imported files. ERP object (instance) defined in ODM can be linked to the document while importing the files.

Chapter 18 Multisite

18

Introduction
This chapter briefly describes the following main aspects of multicompany processing: Multicompany structures Multicompany terms Enterprise structure modeling Enterprise units Multicurrency Intralogistic company functions Data sharing The term multicompany can be used to describe processes in more than one business unit within an organizational structure.

Processes
Processes are actual business events, such as material handling, manufacturing, and administration, or the recording of these business events.

Business Unit
A business unit is any entity in an organization with some degree of independence, such as a warehouse, distribution center, manufacturing plant, sales office, or administrative group. Independence implies that some degree of management is unique to the entity.

18-2

| Multisite
Multicompany in ERP LN includes functional and technical concepts. Examples of ERP LN multicompany 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 the organizations structure and the ERP LN multicompany functionality before you can start to develop a multicompany implementation plan. Defining a company structure includes identifying physical locations, technical architecture, data management requirements, management structure, reporting requirements, centralized/decentralized planning, procurement, and manufacturing and financial administration. Analyzing the organizational structure and processing requirements in conjunction with ERP LN multicompany functional and technical capabilities provides a foundation for an implementation plan.

Multisite environments
A site is a set of company processes 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 ERP LN 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. An ERP LN multisite environment usually consists of a structure of multiple logistic and financial companies; therefore, multisite is often synonymous with multicompany. If the various sites are located in different countries, you must set up a multicurrency system for the companies of the multicompany structure.

Some multicompany terms

This section introduces some of the terms used.

Multisite

| 18-3

Multicompany (multisite)
An organization in which the ERP LN configuration consists of more than one ERP LN 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 multicompany in this document.

Company
An ERP LN company is a set of tables where logistic/financial master data and dynamic data are 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.

Logistic company
An ERP LN company used for logistic transactions, such as the production and transportation of goods. All the logistic data concerning the transactions is stored in the companys database. A logistic company can consist of enterprise units 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 performed in the enterprise units 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.

18-4

| Multisite

Enterprise Unit
An enterprise unit consists of logically grouped entities linked to the same financial company and logistic company. Enterprise Units are considered independent financial units within a logistic context.

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

Enterprise Structure Diagram

An Enterprise Structure diagram (model) graphically represents the structure of a company, which assists in the determination of the overall ERP LN 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).

Multisite

| 18-5

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 ERP LN software is now used in more complex company structures than in the past. For example, the possibility to do enterprise planning across different sites allows you to use ERP LN 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.

18-6

| Multisite
The Enterprise Modeler (EM) is a tool 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).

In this way, you can model your enterprise independent of the organization of the ERP LN databases. You use enterprise units to model the multicompany structure. You use logistic and financial companies to organize the database and the users authorizations to work with parts of the database. Note You cannot completely ignore the organization of the databases and their distribution over the various servers when you design a multicompany 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.

Multisite

| 18-7

In the multicompany 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).

L1
EU A
Warehouse A Sales office A

EU B
Warehouse B Work center B

EU C
Warehouse C Service center C

FA

FB

FC

Group company Corporate accounting

If separate sites of your organization collectively 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 multicompany structure. Therefore, you do not need to create separate companies for the various business units and locations of your enterprise.

Multicurrency
In ERP LN, a logistic company can operate in multiple countries and, in this way, in multiple currency areas. The ERP LN multicurrency systems allow a

18-8

| Multisite
company to perform accounting in more than one currency. Amounts can be computed and registered in up to three currencies. Multicurrency allows organizations with operations in high inflation countries to report 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 European Monetary Union (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 others 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-toone relationship must exist between internal business partners and enterprise units.

Data sharing
The companies of a multicompany 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, other data can be shared if 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. Table sharing is one of the data sharing techniques. To set up table sharing, the Table Sharing Modeler is available, which guides the user through the table sharing process. The Table Sharing Modeler stores all information regarding which tables to share and when, and all information regarding relations between tables.

Multisite

| 18-9

Multicompany processing
The multicompany structure allows enterprise-wide production planning and operations management. The following sections briefly describe the multicompany functions the various ERP LN packages support.

Multicompany Financials
In one logistic company, you can carry out logistic transactions between departments, work centers, and warehouses of enterprise units linked to various financial companies. If the debit and credit sides of a logistic transaction are posted to different financial companies, ERP LN can automatically generate intercompany 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 multicompany 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 implementation are controlled within each logistic company. Enterprise units do not have an effect on the activities that have no financial consequences. In a logistic company, routings can include work centers in different countries that belong to different enterprise units. ERP LN posts the WIP transfers to the financial companies of the enterprise units.

18-10

| Multisite

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 using ERP LN Enterprise Planning and Infor SCS Order Promising. Through triangular invoicing, the sales office and warehouse on the sales order, or the purchase office incase of direct delivery, can be located in different countries; therefore, they also belong to different financial companies. The financial transactions will take place using internal invoices against commercial price or valuation price. ERP LN registers some financial business partner data separately for each sales office and purchase office. In this way, the various enterprise units can do business with the same customers and suppliers. In a multicompany 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 convenient currency; for example, the local currency of the country where you perform the work.

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 service centers and warehouses to enterprise units linked to different financial companies. When items are used on a service order, triangular invoicing is possible between the service office and warehouse.

Multisite

| 18-11

You can only handle service contracts, 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, and also between warehouses of various logistic companies to transfer goods between warehouses and generate invoices for the goods without using sales orders and purchase orders. For example, you can use multicompany warehousing to transfer standard goods between warehouses in different countries and implemented in different logistical companies. You can define warehouse surcharges added to the valuation price of the goods, either when the goods are issued from a warehouse or when they are received.

Chapter 19 ERP LN Technology

19

Introduction
This chapter describes the main functions and features of the technology on which ERP LN is based. First, this chapter briefly describes the main components of this technology architecture. In the sections following this overview, the functions and features of the various components will be detailed. Additionally, other topics will be explained in separate chapters.

19-2

| ERP LN Technology

Architecture
The following figure illustrates the ERP LN Technology architecture:
Studio Webtop I nf or SOA External Application WebUI Webtop
D e p e n d e n t P l a t f o r m C l i e n t

I nf or ERP Applications iBaan ERP Applications

XML/HTTP Web Server

In depe nden t Pl atform S erver In d epe P lat nde for S er ver nt m

iBaan Infor OpenWorldX Bus Connectivity Tools iBaan Infor OpenWorldX SOA Adapter Jav a Virtual Machine Development T ools

XML/DS Applic ation Management Tools 4GL-Engine

iBaan Virtual Mac hine (BSHELL) Virtual Machine (BSHELL)

Database Drivers

Dep Depen dent endP latS er ent for ver m Pl atfo rm S erver

Operating System

DBMS (Database)

P lat S er for P latform m ver Ser ver

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 ERP LN Server installation.

Server platform-dependent layer

This layer provides the runtime environment for platform-independent Infor applications. As such, these components are ported to and delivered for each specific operating system and database; therefore, this layer is also known as the porting set. The core of this runtime environment is the Virtual Machine, also known as the bshell. This component implements the following main parts: The implementation environment for the application software. The interface with the user interfaces (Web UI and Studios).

ERP LN Technology

| 19-3

The interface with the databases. The database drivers provide database access to the relational databases, to allow all ERP LN database requests to be performed on the underlying relational database. For each relational database, a separate database driver is created. The interface with other applications via Infor SOA To provide connectivity through Infor Open Architecture, 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 ERP LN applications in this layer are completely platform-independent. The core of the ERP LN applications is the 4GL engine, which handles all of the standard user interface and database behavior. The ERP LN applications all make use of this standard behavior. By using the development studio, developers can create new functionality or customize current functionality. For more information, refer to, ERP LN Development Environment in this section. Various tools are available for connectivity. Integration through SOA is based on BODs (Business Object Documents), which comply to the OAGIS standard. Other connectivity tools are Infor Integration and data exchange. For more information, refer to, Connectivity in this chapter. The application administration tools are used to configure and maintain the ERP LN system. For more information on application administration, refer to ERP LN 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 ERP LN is Infor Web UI, which is a Web client. Web UI is installed on a Web server and allows users to start and run the Infor user interface in their Internet browser. Web UI interacts heavily with the 4GL Engine using the Virtual Machine.

19-4

| ERP LN Technology
As a secondary interface, Worktop is available; this is a user interface for the Windows platform only. For more information on Web UI and user interface concepts, refer to User Interface in this chapter.

Enterprise Server
The technology to allow the application code to run is called the Enterprise Server and consists of the porting set, the 4GL Engine, and the connectivity tools.

Enterprise Server Extension

The web-based products that complement the capabilities of the Enterprise Server. Examples are the Web UI and the BIRT-based report service.

ERP LN Runtime Environment

This section describes the runtime environment, particularly the virtual machine, also known as bshell, and the database drivers.

Virtual Machine (bshell)

The bshell is a single threaded process scheduled and implemented 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 ERP LN programming language. The bshell is activated by an external request. Usually this external request originates from the user interface driver when someone logs on to the ERP LN system. Each time a user logs on to the ERP LN system, a separate bshell process is designated to the user. Therefore, when multiple users log in on a particular platform or a user logs in multiple times, multiple bshell processes become active on the host platform. The most important functions of the Bshell are as follows: Offers an implementation environment to ERP LN applications: In this implementation environment, ERP LN applications are scheduled and performed as separate processes. Such an application is either a 3GL

ERP LN Technology

| 19-5

or 4GL program. The implementation of the application programs by the bshell is carried out in close corporation with the 4GL Engine. Implements a large number of standard functions the ERP LN application software uses. Among others, these functions are typical functions that require services from the underlying operating system, such as stream file I/O and communication services. Passes information from/to ERP LN applications to/from the user interface and database driver. The ERP LN applications or the bshell contain user interface or database management system-specific functionality. This characteristic allows developers to write one set of code, which suites any customer situation with respect to user interface, operating system, and database management systems. When the bshell is used in combo mode, which means that the bshell and the corresponding database driver are running in the same process space, the communication between the bshell and the database is optimized, which leads to less cpu usage and memory conception.

Database driver
The database driver is the gateway for 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 allowing 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 allows 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: Shields 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. Offers functionality to maintain (create/remove) tables in a possibly distributed database system. Offers functionality to store and retrieve information in a possibly distributed database system. Maintains the referential integrity between the data manipulated by the database driver. Enforces domain constraints. The domain describes the valid values a table field can have. The

19-6

| ERP LN Technology
database driver is responsible for protecting against invalid table field assignments.

Platform and database support for ERP LN 6.1

The following table lists the platform and database combinations currently available since December 2010. For an updated platform, check the technical notes of the latest available porting set, solution 148218.
SQL Server 2005, 2008 Oracle 10, 11 X X X X X X X Informix DB2 9.1, 2008 R2 11 9.5, 9.7 X X X X X X X X X X

Supported OS HP PA_RISC HP-UX HP IA64 HP-UX IBM Power_PC AIX SUN_SPARC\SOLARIS Novell x86 Suse Redhat x86 RedHat Microsoft x86 Windows v1, v2, v3 v2, v3 5.3, 6.1, 7.1 10 10, 11 5 2008, 2008 R2

Infor ES Reporting Service

The Reporting Service is a print service that runs on a Windows platform, which enables printing of ERP LN reports using Windows printer drivers. This is useful for customers who want to use certain printers for batch job reports for which no printer driver is available on the platform for which ERP LN is deployed.

ERP LN Technology

| 19-7

Internationalization
Multilanguage software

Multiple languages within one ERP LN environment

Most ERP LN implementations use several languages simultaneously. ERP LN supports any combination of languages within one ERP LN environment, as long as the languages are supported with ERP LN. The support is restricted to certain databases. This multilanguage support is implemented by following the Unicode standards. For linguistic sorting, the ICU (International Components for Unicode) standards are also followed.

Decoupled software and language packs

ERP LN uses LTS to reduce the language-dependency of the ERP LN applications and lower the costs of media creation and distribution. Basic concept LTS provides a mechanism to separate translatable software components such as labels, questions, and also messages from language-independent software components such as form and report layouts. In LTS, the forms and reports only exist in the development language. For example, a sales order entry form only contains an identifier to a referring label and will be used by all system languages. The translated labels will only be added 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 XML-formatted files. Every XML file contains a selection of translatable components based on the users settings. The translated language files can be imported back into the Infor environment. The import process includes a conversion to runtime.

19-8

| ERP LN Technology
All descriptions are stored as labels which 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 will be shown. Easy delivery The translated XML language export files can be converted into language packs which can be distributed and installed by the ERP installer.

Multilanguage Data
It is possible to show data, such as descriptions, in the data language of the end user. A customer must define data languages and define for which multi byte fields these data languages are applicable. One of the data languages will be the base language. In case a description is not available, such as if it was translated to another data language, the base language will be shown.

Assigning data languages to users

Each data language must be linked to a software language. Therefore, by default, the data language of a user is determined based on the software language of the user. This link can be overruled and you can assign a data language directly to a user.

Multicurrency
ERP LN supports multiple currencies. For more information on this, refer to Chapter 6 and 19 in this document.

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: Infor Web UI and Infor Worktop. Infor Web UI is the preferred User Interface to use. Future investments are mainly made in the Infor Web UI User Interface.

ERP LN Technology

| 19-9

Customer Defined Fields

Customer Defined Fields (CDF) allow customers to add application fields to the ERP LN applications. It is a matter of configuring additional fields and not doing any application development. This means that no business logic is changed, and no development license is needed to add customer definable fields to the ERPLN Application. The following restrictions have been defined: Tools tables (package tt and tl) can not contain CDFs. Web UI conditional formatting is not supported for CDFs. Easy SQL is not supported for CDFs. EDI is not supported for CDFs. Except for reporting through the Reporting Studio and the Reporting Viewer, reporting is not supported for CDFs. External integrations, such as Infor Integration, EDI, Exchange, Office integration, and SOA-based integration, do not support CDFs. CDFs are not supported in program scripts.

Sensitivity Labels
Some data of the ERP LN environment may be sensitive. Sensitivity labeling provides the ability to define sensitivity levels and assign these levels to tables, table fields, sessions, or reports. Involved forms and reports will mark the output with related sensitivity label.

Infor Web UI versus Infor Worktop

Infor Web UI is a web-based, multiplatform User Interface, whereas Infor Worktop is a Microsoft Windows-based fat client. Both User Interfaces provide a navigation framework: Shortcut bar and Navigation tree(s), and Menu browser as the DEM process Browser. The following screenshots give an idea of both User Interfaces.

19-10

| ERP LN Technology
Infor Web UI:

Infor Worktop:

For detailed information on Web UI, refer to: Infor ERP LN Web UI Online Help Infor ERP LN Web UI - Installation and Configuration Guide (U8715 US)

ERP LN Technology

| 19-11

Note: Web UI can run in Infor Companion. For details, refer to the Infor Companion-LN Plug-in User Guide (U9647 US).

Main differences between Infor Web UI and Infor Worktop

The following are the main differences between Infor Web UI and Infor Worktop: Infor Web UI is the strategic UI forward, not all new features are available in Worktop. Infor Web UI is web-based (no installation), and runs in a browser. Infor Web UI supports multiple Operating Systems. Infor Web UI requires less network bandwidth. Infor Web UI integrates the ERP sessions in the work-area. Infor Web Help is tightly integrated into Infor Web UI. Infor Web UI is not suitable for developing DEM models. Infor Web UI is not suitable for developing sessions with the Developers kit. For some features, such as Charts, a different programming interface is used for Infor Web UI. Therefore, the use of some old Infor Worktop-only programming interfaces has been disapproved of.

Infor Web UI specific User Interface features

Easy Filtering
To provide an easy way to perform filtering data in a grid, Infor Web UI has implemented the Easy Filter concept. The grid header contains a filter row. By entering your filter argument, or using wildcards, in a textbox and tabbing away from the field, your data will be filtered. By clicking on the filter icon in the grid header, you can easily save your filter for later use.

Smart Links
With Smart Links you can easily navigate to related information. There are two types of Smart Links: 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: . To view detailed information, click this icon.

19-12

| ERP LN Technology
Customize Form
If the end-user has Customizable Fields authorizations (see paragraph on Customizable Fields), they can click the Customize icon ( ) in an ERP LN session or choose View | Customize Form..., and the form will be displayed in customize-mode. To hide fields or complete groups, click the eye icon along with the corresponding label. To change the appearance of the label, click the pencil icon. Note: The following functionality is supported for ERP LN back-ends with Enterprise Server 8.7 or later: Users can personalize the forms in the Personalize Grid (ttadv9210m100) session. This session is started automatically when a user clicks the Customize icon. In overview sessions with multiple tabs, users can move grid fields to other tabs.

Customize Toolbar
If the end-user has Customizable Fields authorizations (see paragraph on Customizable Fields), the secondary Toolbar can be customized by choosing View | Customize Toolbar...

Customize Menu
If the end-user has Customizable Fields authorizations (see paragraph on Customizable Fields), the Specific menu, Print menu, and Text menu can be customized by choosing View | Customize Menu

Dockable panels
The Web UI panels, such as the Infor ERP panel, Infor Web Help panel, and the Home Pages panel are dockable. You can drag each panel to another location in the Web UI window and dock it.

Auto-hide navigation areas

Optionally, the Shortcut Navigation and Tree Navigation areas can be made hidden in such a way that they become visible again when the mouse hovers over the left side of the screen.

ERP LN Technology

| 19-13

Gantt charts support

Interactive Gantt charts are used for complex planning applications. With the Gantt chart, the end-user gets a clear visual overview of the planning. It is easy to change the planning by drag and drop functionality. Navigation is also very user friendly. An example of a Gantt application can be found in the Manufacturing package: Shop Floor Control Production Order Planning.

Company coloring
In the Infor Web UI Administration Console, the system administrator can allow Company Coloring. The administrator can give each different company a specific color to emphasize that the user is working in various Infor companies. The company colors will be visualized in the task bar.

Conditional formatting
Web UI supports conditional formatting of data. You can define conditions to apply special formatting effects to the data that is displayed in ERP LN sessions. For example, you can apply a foreground color, a background color, or a warning symbol. You can define multiple conditions per session.

Mandatory Field Indication

You can choose whether Web UI should display an asterisk behind the labels of the mandatory fields in ERP sessions.

Customizable look-and-feel
The end-user can change the look-and-feel of the User Interface. The default look-and-feel is the Infor look-and-feel. Other look-and-feels the user can switch to depend on the Operating System. On Windows, the end-user can switch to the Windows look-and-feel.

Copy data to MS Excel

ERP LN multi-occurrence sessions contain a toolbar button to copy the data that is currently displayed to MS Excel.

Cancel button on user profile dialog

The user profile dialog contains a Cancel button.

19-14

| ERP LN Technology
About dialog
The Help menu in the Web UI title bar contains an About dialog that displays the following information: Web UI version Web UI Server User Profile Infor ERP environment Host name And so on

Session properties
From a sessions help menu, you can display properties, such as session information, session data, authorizations, and form information.

Link support in text editor

Web UI supports "http://www." and "mailto:" links in the ERP LN Text Editor.

Column highlighting
You can click a column header in a session to highlight the column. In this way you can draw attention to the column. This can be useful, for example: When you give a presentation. When you create screenshots.

Show company number

The Options menu in the Web UI title bar contains a Show company in title option. If this option is selected, the current company number is displayed in the title bar of the following components: Work Area. Infor ERP navigation panel. Shortcuts panel.

ERP LN Technology

| 19-15

Change company number via shortcut menu

You can switch to another company number through the shortcut menu in the Infor ERP navigation panel.

Java Web Start

You can start Web UI through Java Web Start. Web UI is started through Java Web Start, for example, when you perform a drill-back action in Infor PM Dashboard.

Start a second Web UI from your current Web UI

The File menu in the Web UI title bar contains an Open Profile option, which you can use to start a second Web UI. This option is only available if the current Web UI was started through Java Web Start.

Tooltip on conditions
When you hover the mouse pointer over a conditionally formatted row or field, the description of the corresponding condition is displayed as a tooltip.

Dynamic Find dialog

If multiple indices are available, you can select the desired index in the Find dialog. The dialog shows the corresponding input fields.

Last login date

During the log on process, the last login date and time are displayed. This is useful, for example, to check if somebody used your user account during your absence. Once you are logged on, the last login date and time are displayed in the status bar below the Work Area.

Project Activity Testing

The Options menu in the Web UI title bar contains a Select Activity option. Use this option if you want to test software components that are checked out to an Infor ERP LN Application Studio activity.

Automatic scroll in Graphical Browser Framework (GBF)

You can drag to an item below the lower border of the GBF window. The window scrolls automatically.

19-16

| ERP LN Technology
Displaying icons in enumerated fields
Depending on configuration settings, icons can be displayed in enumerated fields in overview sessions. The icons are linked to enumerated constants and are displayed instead of the corresponding enumerated descriptions, which saves space in the grid.

Dropping Pictures
Depending on authorization settings, users can drop pictures in sessions that have a picture box. A user can drop a picture only if the session supports this action.

Federation Services login

Users can log in through a Federation Services login URL. By logging in once, users gain access to multiple applications. Depending on ADFS configuration settings, users can be logged in automatically based on their Windows credentials. Note: Single Sign-On using ADFS is Limited Available (LA).

System administration tools

Infor Web UI can be centrally managed. End-users do not have to do administration on their own. All settings are centrally stored; for example, the end-user does not have to know the Enterprise Server parameters because the administrator manages that. For the system administrators to perform their tasks, a separate user interface has been developed, called the Web UI Administration Console. In this Administration Console, the system administrator can perform Web UIspecific administration tasks. For details on the Web UI Administration, refer to: Infor ERP LN Web UI - Installation and Configuration Guide (U8715 US) Web UI Administration Console Online Help

Login using Infor Single Sign On

Web UI supports user login using Infor Single Sign On (Infor SSO) authentication through Infor Security. By logging on, users can access multiple applications. To log on through Infor SSO, a different URL is used. In the Manage Infor ERP Environments page in the Web UI Administration Console, you can select the Infor SSO protocol for your ERP environment.

ERP LN Technology

| 19-17

Homepages
Homepages are designed to support a user working within a specific role within the company. A homepage is focused on presenting only relevant data to the user which helps them achieve their objective, which is to perform their tasks quickly with no non-value added steps. A Homepage consists of different working panes. The different panes provide users with alerts, workload, quick navigations to most used sessions, and easy access to relevant reports. Also, Key performance Indicators (KPIs) for monitoring process, providing status information, and evaluating performance are visualized on the homepage. Although homepages are delivered with pre-defined content, users have the ability to configure the different panes. Within ERP LN 6.1, the following roles are supported through homepages:

Production Planner. Shop Supervisor. Buyer. Sales Administrator. Warehouse Manager. Shipping/Receiving Manager. Warehouse Administrator. Accounts Payable Administrator. Accounts Receivable Administrator. Accounting Manager. Credit and Collection Representative. Project Manager.

360 screens
ERP LN introduces the concept of 360 screens. A 360 screen is a screen that provides the user with a compressive overview of a specific business object, such as customer or supplier. A 360 screen incorporates an overview of linked business objects, a status synopsis, relevant graphs, and KPI statistics for monitoring progress and evaluating performance, and includes a section with quick links to most used sessions. The 360 screens are customizable to meet the specific needs of different end-users.

19-18

| ERP LN Technology
In ERP LN 6.1, the following 360 screens are available: Order Management: Customer 360 Supplier 360

Generic User Interface features

Navigation feature
There are several ways to find your way to the application sessions. The enduser can use one of the navigation trees: Menu browser or Process Browser (DEM). Alternatively, the end-user can drag and drop their favorite sessions onto the Shortcut bar, and start them from there. The run program feature can be used to start sessions by code. The most recently used session codes are remembered.

Multiple Window Interface

Each session has its own window, which can be resized or moved around the screen. When the Remember the users settings option is turned on in the users user-data, the size and position of the windows are remembered.

Grid customizations
The grid can be customized by hiding/adding columns, changing column widths, and freezing columns.

Customizable Fields
With the Customizable Fields feature, the end-user or administrator can make customizations to the forms without actually changing the forms. In the User Data template session, a user is given Customizable Fields authorization. Form customizations other than grid customizations can only be made through the Infor Web UI User Interface. With the Customization Maintenance session, an administrator can promote an end-user customization to apply to all users with a certain DEM-role, or even all users working in a particular company number.

ERP LN Technology

| 19-19

Auto complete
For fields with lookup functionality (also known as zoom fields), the user interface assists the end-user by automatically providing a list of lookup entries that match the fields content. The list of entries is automatically narrowed as more characters are typed into the field.

Mandatory fields indication

Required fields are marked with a red asterisk. Also, fields that are only mandatory when a certain condition is true are marked as mandatory when the condition is met.

Desktop integration
For Windows Operating Systems, Desktop shortcuts can be made which link to ERP LN sessions. Shortcuts can also be mailed.

Microsoft Office integration

For Windows Operating Systems with Microsoft Office installed, data from ERP LN can easily be used in MS Word or MS Excel, for example.

Dashboards
ERP LN 6.1 introduces the concept of dashboards. A dashboard is a session that fully supports a user who performs a particular role. It gives the user an overview of relevant status information and easy access to the session needed to perform their task. Usually, a dashboard contains a list of objects relevant for a particular role, such as Business Partners or Items; in this list the user can select an object. The area above the list will then show 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 tells the user if there is relevant data in the session the hyperlink jumps to. Among others, in ERP LN 6.1 the following dashboards are available: Manufacturing: Work Centers Dashboard Items Dashboard Order Management: Buyer Dashboard Account Manager Dashboard

19-20

| ERP LN Technology
Project: Project Manager Dashboard Service: Customer Call Dashboard People: Employees Dashboard Financials: Accounts Receivable Dashboard Accounts Payable Dashboard

Multi Main Table Sessions

ERP LN introduces a new type of session: the Multi Main Table session. This session type allows various other sessions to be combined into one, and is designed to present data with a typical parent-child structure, such as Sales Orders and related Lines. Although this data is distributed among several main tables in the system, it can be presented and edited from within a single parent-child session. A typical parent-child session has two areas. The upper part contains information and functionality about the parent; the lower part contains one or more lists that show data about the various types of children. Both parent data and child data may be edited inside the session, which makes the sessions extremely powerful for data entry. A parent-child session also gives the user a complete overview of all important data related to the object. Among others, in ERP LN the following parent-child sessions are available: 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.

ERP LN Technology

| 19-21

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 Revision. Change Proposal.

Infor Web Help

This section describes the most important functions and features of Infor Web Help. Infor Web Help is the new Help application for all Infor users and is installed together with the Infor Web UI; however, it can also be used as a standalone application.

MSDN look and feel

Infor Web Help has the same easy-to-use and recognizable user interface as the Microsoft MSDN Help. The window consists of three parts: The shortcut bar The navigation area The content area You can resize all three parts to create the user interface you want; you can even change the look-and-feel.

19-22

| ERP LN Technology

Use of filters
You can install several Help contents, such as Web UI Help, ERP LN Help, and Infor Enterprise Server Help. You can also configure Web Help in such a way that each user can hide the Help contents they do not require.

Help texts stored in XML format

The Help texts are stored in XML format and are easy to maintain and deploy. Because the Help texts are stored in XML format, the customer can easily customize the Help texts. Additionally, the users can also store and search Microsoft Word, Microsoft Excel, PDF, and ASCII documents in Infor Web Help.

Full text search capabilities

To search in Help, 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 and OR. The matched items are visualized by highlighting the text.

On-the-fly installation of new help content

When new Help content is delivered in a Zip file, in the Infor Web UI Administration Console you can easily install or update the Help content. The help content file can be uploaded from the administrators client desktop or

ERP LN Technology

| 19-23

web server. The Web server does not have to be restarted to make the new texts available.

To print booklets
To print the content of Infor Web Help, 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

Using the admin console of the Infor Web UI, the administrator can assign users as help writers through 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. After you click this button, you can customize the Help by changing/adding help texts and hiding help topics. These customizations also remain when a new standard Help content is installed.

Infor Integration Pack 2.0 for ERP LN 5/6 Microsoft Office XP/Vista
The Microsoft Office integration supplies Infor users with the ease-of-use and flexibility of Microsoft Word and Excel, and ERP LNs capability to store and retrieve mass relational data. Users can select data from an Infor session and send this information to Microsoft Word or Excel: Microsoft Word generates documents such as sales contracts, based on a predefined ERP LN related design template. Microsoft Excel generates workbooks based on a predefined ERP LN related template. After the workbook is generated, users can use all the Excel functionality to manipulate and update the ERP LN data. Design templates are stored and published in ERP LN on the application server, which allows other users to reuse these templates. Authorized Infor users can select the published templates from the Send To menu, as shown in the following figure:

19-24

| ERP LN Technology

Product Details
The Integration Pack consists of the following products: End-user installer to allow related menu bar options and an extra toolbar in Word/Excel. Installer of designer tool for read-only templates. Optionally, you can also , install ERP LN upgrade facilities for Excel templates. Additional tools provided to convert templates designed in earlier versions of the product to the latest template format or version.

ERP LN Connectivity
Infor ION Integration
Enterprise Server plays a role in connecting ERP LN to the Infor ION domain. Enterprise Server contains components for the connectivity with Infor Service Bus. The ERP LN Connector is delivered with the Infor ION product installer. There is no stand-alone installation for ION connectivity in Enterprise Server. To use the ION connectivity on the Infor service bus, you must use the Infor ION Desk to model the properties for the ESB LN Connector. When a routing model is deployment in ION Desk, the LN Connector is started in the service bus and the ERP LN instance is ready to publish BOD messages, according to this business routing model. To develop Business Object Document implementations for ERP LN, you must use Business Studio. To enable integrations with other Infor solutions, a set of BODs is being delivered with ERP LN FP5 and later.

Infor ION Event Management

ION Event Management is one of the business services of ION that can be used to create Alerts based on documents published by the ERP LN application. In Event Management, business rules can be defined in the form of Monitors. Each time a business rule is triggered, an Alert is created and displayed in the Tasklist for end users.

ERP LN Technology

| 19-25

Infor ION Workflow

ION Workflow is one of the business services of ION that can be used to define user-oriented workflows that are triggered by a document published by the ERP LN application. Workflow steps of type User Task will result in Task entries being displayed in the users Tasklist. Tasklist is the application in which end users see the Alerts and Tasks that apply to their role. Tasklist can be used as a desktop application or can be embedded in Infor User Experience. Infor Ion Event Management and Workflow are delivered with the Infor ION product installer. There is no stand-alone installation required for this in Enterprise Server.

Business Object concept

ERP LN Connectivity is based on the Business Object concept. A Business Object is an object understandable by the Business, such as Purchase Order or Organizational Unit. It has information stored in the Business Object Attributes, such as Purchase Order Number or Organizational Unit Name. It has a set of actions, Business Object Methods, which can manipulate the Business Object Attributes such as Create Purchase Order or 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 paradigms are supported: Business Object Services The Business Object is owned and handled by ERP LN. A set of service methods allow the external party to manipulate the contents of the Business Object. Business Object Synchronization The Business Object sends changes as events to the external party. The Business Object in ERP LN has a layered architecture.

19-26

| ERP LN Technology

Public Layer

Protected Layer

DAL Layer

An external party can only enter the Public Layer. The Public Layer can only enter the Protected Layer. The Protected Layer 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 as an interface. This means its 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 overall architecture for ERP LN Connectivity is shown in the following figure:

Business Object Modeling

Introduction
Business Objects definitions and mappings to the LN Data Dictionary are modeled using the Business Studio, which is an Eclipse based IDE. The Public and Protected Layer code is generated and deployed 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. There are two types of Business Objects: Simple and Complex Business Objects. A Simple Business Object only uses one table, or more than one table having a zero-or-one-to-one relationship, to store its information in. An example is the Business Object Currency.

ERP LN Technology

| 19-27

A Complex Business Object uses at least two tables with a one-to-many relationship to store its information in. An example is the Business Object Purchase Order.

Protected Attributes and Methods

The Protected Layer of the Business Object is modeled by defining the Protected Attributes and Protected Methods. A Protected Attribute can be mapped to a table-field, or it can be the result of a calculation based on other Protected Attributes. The logic of these calculations must be programmed inside a hook in Integration Studio. 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 instead of a regular argument list. There are two sets of Protected Methods: Standard Methods and Specific Methods. The Standard Methods implement a predefined way of manipulating the Protected Business Object Attributes for all Business Objects. Six standard Business Object service methods currently exist: Create, Change, Delete, Read, CreateRef, and DeleteRef. The CreateRef and DeleteRef allow external parties to notify ERP LN that a reference is defined to this Business Object. When an external reference is defined, it is not possible to delete the Business Object. For the Specific Methods, logic is specific for this Business Object. This logic must be programmed in the hooks of Integration Studio. For each method, the Protected Attributes used as arguments must be defined.

Public Attributes and Methods

The Public Layer of the Business Object is modeled by defining the Public Attributes and Public Methods. A Public Attribute is mapped to a Protected Attribute. Public Methods are Baan 3GL functions with 3 fixed arguments that are XML trees, such as the Request, Response, and Result argument.

19-28

| ERP LN Technology
There are two sets of Public Methods: Standard methods and Specific Methods. The Standard Methods implement a predefined way of manipulating the Public Business Object Attributes for all Business Objects. Currently there are nine standard Business Object Service methods: Create, Change, Delete, Show, List, CreateRef, DeleteRef, Subscribe and Unsubscribe. The two Business Object Event methods are PublishEvent and OnEvent. The List, Show, and Subscribe method gives the requester the possibility of defining their own selection of the attributes and filter on the objects For the Specific Methods, logic is specific for this Business Object. This logic must be programmed in the Business Studio hooks.

Business Studio
Business Studio is an Eclipse-based IDE that supports the modeling of Business Object Interfaces (Business Interface Definitions BID) and its mapping to the Data Dictionary of an Application (Business Interface Implementations, BII).

Screenshot of Integration Studio

ERP LN Technology

| 19-29

From the BID, a client-side API can be generated in the following: Java .NET WSDL From the BID, PDF formatted documentation of the Public Interface can also be generated. Once the mapping to an application is complete, the server-side implementation can be generated from the BII and deployed for the following: ERP LN (BaanC, as described above). ERP LX (RPG). WMS (Java). Generic Java (POJO). It provides the following functionality: Import, model, and generate BDEs. Generates WSDL for BDE services on the ERP LN backend. Generates java and .Net proxies for BDE definitions.

Enterprise Server Extensions Connector for WebServices

The Connector for WebServices exposes BDE-based Web Services and is an alternative for Infor Integration Adapters for synchronous BDE invocation This Connector should be used together with BDEs for which the WSDL has been generated from Business Studio to the ERP LN backend.

ERP LN third-party integrations

ERP LN 6 supports integrations with Infor CPM solutions such as Infor Business Intelligence and Infor Enterprise Analytics, which are both based on Cognos Cooperation technology. Infor Integration middleware is used to access the ERP LN 6 system. ERP LN is also integrated with Microsoft SQL Server 2008 R2 Reporting Services. ERP LN provides a document management solution, which is based on Microsoft SharePoint. Through this solution, Web UI and WorkTop users can

19-30

| ERP LN Technology
attach documents to records in various ERP LN sessions. The attached documents are stored in Microsoft SharePoint. You can access SharePoint directly. Note: With Enterprise Server 8.7 it is also possible to store documents in the ECM Vault, and attach them to ERP LN objects. ECM (Enterprise Content Management) is part of the Infor PLM suite and includes a robust Document Management System. By using ERP LN, you can configure Single Sign-On using Microsofts Active Directory Federation Services (ADFS). Note: Single Sign-On using ADFS is Limited Available (LA).

ERP LN Exchange
Introduction
For application integration with applications not having todays integration tooling Exchange is available. The business data of these legacy applications is often managed locally and not disclosed to other applications. Changes to data on one site are not reflected elsewhere, or only with inefficient data extraction tools. ERP LN Exchange allows customers to extract data from the ERP LN system in a consistent, efficient, and flexible way. You can also use ERP LN Exchange to do the following: Multisite ERP LN 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 ERP LN, you can do this without programming custom interfaces. While the transactions between both software environments are synchronized, data is available in both systems. You can perform the synchronization one way from or to the ERP LN environment, or both ways. Conversions If an ERP LN 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.

ERP LN Technology

| 19-31

Any one-time or repetitive export or import of data from or to an ERP LN database. ERP LN Exchange positions itself uniquely in the area of offline bulk data exchange and data conversions; 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 figure shows an architectural overview of ERP LN Exchange:

End users

Infor ERP Exchange

End users

Configuration & Process Management

OLTP Application

OLTP Application

Source Database

Export

Data or Transactions Transport

Import

Target Database

Transaction Log

Data or transactions from the source database are exported and can be manipulated; they 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. Therefore, the user can list the tables that must be synchronized, and generate the settings for the data exchange. With ERP LN Exchange, a user can set up a simple integration in a few minutes.

19-32

| ERP LN Technology
For more complex cases, data selection and data transformation functionality is available. For fragmentation purposes, Exchange allows you to select the specific table columns that must be included, and to specify data ranges. The user can implement data transformation using conversion tables or other methods, such as 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. Additionally, the user can incorporate other programs or any operating system script.

Not just data

ERP LN Exchange offers not only database-level integration, but can also include existing business logic using functions from any ERP LN application library. The user can utilize the business logic of ERP LN to add external data to ERP LN 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 ERP LN applications. If you select a check box, the DAL functionality will be included when you import data. Therefore, all validations and logic implemented in DALs are automatically performed, 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. To reduce network load, you can also compress the data that must be sent from one site to another. The ability to only exchange 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.

ERP LN Technology

| 19-33

Open
ERP LN Exchange is a generic tool. You can configure ERP LN Exchange to exchange any data from or into an ERP LN database. The user can not only configure 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. Additionally, Exchange can read and write fixed length files and delimited files using any delimiter.

Safe
In ERP LN Exchange, the ERP LN database definitions are used including domain constraints and integrity checks. The user can also include validations in the Data Access Layer. Transaction-based data exchange was designed to ensure 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. If you use multiple database tables, the sequences must also match. UTC times are used to guarantee time zone independence. Application servers from various time zones can implement 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 do the following: 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. On the other hand, you can link source and target sites. If you link sites, source and target sites are automatically synchronized. Additionally, if one site is not available for a time, or if the batches at several sites do not run synchronously, Exchange ensures no data will be missing.

19-34

| ERP LN Technology
Multisite Control not only allows users to use one-to-one topologies, but also one-to-many, many-to-one, or many-to-many. A target site can subscribe to data made available at a source site.

Manageable
ERP LN Exchange allows 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 perform Exchange process steps conditionally, or you can stop an exchange process automatically under particular conditions.

ERP LN Application Management

Job Management
ERP LN Job Management provides functionality to schedule and monitor Infor sessions based on the following: Business calendars. Periodical runs by minutes, hours, days, weeks, or months. External job schedulers.

Device Management
ERP LN Device Management provides functionality to do the following: Manage and monitor output devices attached to the ERP LN infrastructure, such as network printers or file-oriented devices. Manage the Infor printer queues and device settings.

ERP LN Technology

| 19-35

User Management
ERP LN User Management manages the Infor users profile for end user and developer specific configurations, such as the following: Device preferences. Application authorizations based on user roles/default user templates. Development related authorizations such as specific sessions or ERP LN tables.

Authorization Management System (AMS)

AMS provides functionality to do the following: Manage Infor user roles for role-based authorizations. Manage user templates for common used settings of end users and developers. Manage address book settings for the ERP LN messaging facilities.

Audit Management
Audit Management manages and monitors the audit files that contain transactional changes in the ERP LN system. ERP LN Audit Management is primarily used by ERP LN Data Access (ERP LN SyncServer and ERP LN Exchange) to exchange the transactional changes across ERP LN systems.

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 Infor system. The PMC tool is used to check solutions for completeness and customization interference. Without this tool, solutions could be installed regardless of other solutions that were already installed. Technically, you could install a solution that contains an older version of a function or DLL than that present in your system. In such a case, the fixes that were in the original function or DLL would be lost. PMC keeps track of all installed solutions and their dependencies. The customer's Infor system contains a PMC repository, in which is registered which solutions the customer has installed and how these are related. To guarantee consistency of all solutions, new solutions will be checked against this PMC repository.

19-36

| ERP LN Technology
A service pack is created by bundling PMC solutions and offering these as one deliverable.

Data Upgrade Engine

The Data Upgrade Engine is a tool that upgrades the ERP LN database after the installation of a feature pack. Upgrades that can be performed are, for example, for the initialization of new table fields and moving data to other tables. The number of upgrades to perform depends on the starting point of the upgrade. The bigger the gap between the previous feature pack that was installed on the customers system and the new feature pack, the more upgrades will be performed.

ERP LN Development Environment

Introduction
This section describes the ERP LN Development Environment. The Development Environment is a powerful set of tools to create scalable, robust, translatable, and platform-independent applications with a high productivity.

Application Studio
Infor ERP LN Application Studio is an Eclipse-based integrated development environment for ERP LN 4GL components. Key features of this product are as follows: Activity-based development. Editors for component properties and source code. Powerful debugger. Integrated with PMC. For more information, refer to these documents: Infor ERP LN Application Studio User Guide (U8921 US) Infor ERP LN Application Studio Administrator Guide (U9420 US)

ERP LN Technology

| 19-37

Microsoft Reporting for ERP LN Extension

The Microsoft Reporting for ERP LN Extension is a platform for development of ERP LN reports, which is based on Microsoft SQL Server 2008 R2 Reporting Services (SSRS). SSRS provides a complete, server-based platform designed to support a wide variety of reporting needs enabling organizations to deliver relevant information where needed across the entire enterprise. In the Microsoft Reporting for ERP LN Extension, ERP LN session reports can be redesigned as SSRS report designs. This gives the reports a modern layout with all kinds of features such as images, indicators, and graphs. For details on the Microsoft Reporting for ERP LN Extension, refer to: Microsoft Reporting for ERP LN - Administrator's Guide (U9656 US) Microsoft Reporting for ERP LN - Developer's Guide (U9657 US)

3GL and 4GL sessions

The basic building blocks for Infor applications are sessions. A session is an entity that provides the user with an interface to an object to perform a particular 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 regarding 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 resembling what 4GL sessions offer. For 3GL sessions, programmers must program everything, including the complete user interface behavior. Creating 4GL application sessions usually involves the following: Creation of table definitions. Creation of a database interface script, which is also called the Data Access Layer (DAL). Creation of dynamic forms. Creation of user interface script.

19-38

| ERP LN Technology
Creation of labels, messages, and questions. Creation of reports. Creation of 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 the following: Behind: This field comes behind another field. If the other field is not displayed, this field will also not be displayed. 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 are always displayed on the same form. This dynamic definition allows you to show the same form in several ways depending on the way the form was started (overview or details), authorizations, and the chosen category fields (grouping of rows). The biggest advantage of dynamic forms can be seen 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 ERP LN user interface. The use of labels in combination with LTS allows Infor applications to be easily translated in a cost-effective way. Deployment of software components is easy, because these components are truly languageindependent. Deployment of new languages is also easy, because the language components can be delivered and installed by the ERP installer as a Language Pack.

Programmatic business triggers

To be able to extend the standard functionality with triggering external communication, the concept of User Exits is supported.

ERP LN Technology

| 19-39

A User Exits DLL (UEDLL) can be created in a non-standard VRC, which provides 8 new hooks that are executed just before and after the defined standard sections/hooks of the UI script and/or DAL script.

Data Dictionary
In ERP LN Tools, a central repository is present that contains all metadata and software components used by ERP LN. 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 called convert to runtime.

Source Configuration Management

All software components, which include sessions, source files, and reports, are under source control. Therefore, 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. Older 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 VRC (Version Release Customization). The VRC is a code base which is a full code base or which contains only the new/changed

19-40

| ERP LN Technology
components compared to a previous version. As such, a VRC can be derived from an existing VRC. To setup one or more application environments in an Infor system, package combinations can be defined. A package combination consists of a set of application packages with a specific VRC. An Infor system can contain multiple package combinations. As a result, one Infor system can have multiple variants of the software active, such as a package combination for the standard application and a package combination for customizations.

Business Studio
The Eclipse-based Business Studio is the follower of Integration Studio 6.1 and provides the following functionality: Import, model and generate BDEs. Generates WSDL for BDE services on the ERP LN backend. Generates java and .Net proxies for BDE definitions.

.Installation and licensing

Introduction
A new installation concept is introduced with the ERP LN release. The installation process is split up in two parts; the first step is collecting all the software components to be installed. During this process the software components are staged into a staging area. Each delivery of software should be an Installable Unit (IU). The characteristics of an IU are that it can be delivered to customers as a software component with an installation program. After staging the installable units into the staging area, the ERP-Installer should be used to install the software components on the system(s) (see the following figure).

ERP LN Technology

| 19-41

ERP LN staging wizard

The ERP LN 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 Infor Enterprise Engine and ERP LN Application media. After the installation wizard is started from the media, the administrator must type a destination path of the staging area. Next, the staging wizard will show all the available installable units, 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 media. The administrator must decide whether the installable units in the staging area must be updated 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 versions must be staged into the staging area. The installable units supported by the staging wizard are as follows: ERP LN porting set. Infor Enterprise Server. ERP LN 6.1 Application. Infor License Manager (client and server part). Infor Application Service Manager (client and server part). Infor Enterprise Server AddOn.

19-42

| ERP LN Technology
ERP LN DEM Models. ERP LN Demo and Base Companies. ERP LN 6.1 Language Pack - 'language'. PMC solutions and Service Packs.

ERP LN Installer
The ERP LN Installer is a generic installer for installing ERP LN on the supported platforms. The ERP LN Installer always runs on a Microsoft Windows platform, which means installation on UNIX versions are carried out in client-server mode, whereas an installation on Microsoft Windows is locally performed. To push the installable units to the remote server, the ERP LN Installer uses a File Transfer Protocol (FTP) connection. The ERP Installer uses the Remote Executable Command (rexec) service to implement programs on the remote computer. Finally, the ERP Installer uses the Infor Windows driver to start Enterprise Engine sessions on the remote computer. Because the ERP LN Installer only runs on Microsoft Windows, the staging area must also be deployed on a Microsoft Windows platform. The administrator is responsible for installing the correct installable units together, which include components and versions. Depending on which installable units the administrator selects for installation, dialog boxes must be filled in; finally, the installation on the Enterprise server is carried out.

Infor License Manager (SLM)

Infor License Manager introduction

Infor License Manager is the central license manager for various Infor 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 Infor products; this ensures a consistent and reliable license validating mechanism. An important advantage of having a single licensing mechanism is that it eliminates the need for multiple activation keys to start the various Infor products, which minimizes administrative overhead. With the SLM, you only need a single activation key.

ERP LN Technology

| 19-43

SLM validation procedure

The validation procedure consists of the following four main steps. The intention of the procedure is to activate the installed Infor products with an authorized activation key from Infor.
1 2 3

Specify at the SLM configuration all the products that have been installed and that must be licensed by SLM. Upload this document to the Validation department of Infor. Infor Validation checks the information in the license document against contract information. If the license document is correct, Infor 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; upon license request, Infor can send you almost immediately a temporary activation key that activates the applications for a limited period.

Infor Validation sends the validation key back to the customer, who then submits this activation key to SLM server. By doing so, all specified Infor products in the license document become activated. If other Infor 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 performed 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 Infor Global products that are depending on SLM for their licensing. A maximum cluster of 4 SLM servers can be setup to serve as one logical license server providing high-availability.

Appendix A Definitions, Acronyms, and Abbreviations

Term A/P A/R ACP

Description Accounts Payable. Accounts Receivable. Accounts Payable, a module of ERP LN Financials. Also used in business as a common term for monitoring and paying amounts owed to creditors. Accounts Receivable, a module of ERP LN Financials. Also used in business as a common term for monitoring your debtors for payment. Activities are the project plannings building blocks. The actual costs incurred and recorded to accomplish the work performed within a given time period. Authorization Management System. Application Programming Interface. American Standard Code for Information Interchange. Application Services Manager. Advance Shipment Notification. Information related to a job allocation for an employee. The baseline can be seen as a snapshot of the start data and finish data of scheduled activities. It serves to compare the actual progress. Infor License Manager.

ACR

Activity Actual costs of work performed (ACWP) AMS API ASCII ASM ASN Assignment Baseline (planning)

SLM

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. In this case, an internal invoice will be sent from the company that delivered the goods to the company that received the goods. Bill of Change Order. Bill of Material. Business Object Repository. Business Partner. The sum of the budgets for completed work packages and completed portions of open work packages. Also known as earned value. The sum of the budgets for all the work packages and planning packages scheduled to be accomplished within a given time period. Fat client for ERP LN, integrated with Worktop. Computer Aided Design. Cost Accounting, a module of ERP LN Financials. Condition Based Maintenance. Change Control Board. Configuration or Configuration Control. Change Header. The Change Affected Objects session displays all the objects that can be affected and used in Change Management. 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. The Change Management is a module in ODM, which registers and controls the processes of product changes. The change order implements the change on the change order date. The change order child inherits the parents change order date. A description of the planned change. This includes ownership details, recommended solution, task costs, date implementation, and the components

BOCO BOM BOR BP Budgeted costs of work performed (BCWP) Budgeted costs of work scheduled (BCWS) BW CAD CAT CBM CCB CFG CH Change Affected Objects Change Committee

Change Management

Change Orders

Change Proposal

Definitions, Acronyms, and Abbreviations

| A-3

linked to the change proposal. 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. Files present in the Vault Area are said to be in Checked In state. Files present in the Work Area are said to be in Checked Out state. Change Management. Call management in Service package. Cash Management, a module of ERP LN Financials. Also used in business as a common term for monitoring your cash. Commissions module in Order Management package that is responsible for raising commissions and rebates. Change Order. Common module in Common package. A working environment in which you can perform logistic or financial transactions. All the data concerning the transactions are stored in the companys database. Depending on the type of data the company controls, the company is one of the following: 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 the company shares with other companies. Consignment Consignment functionality is applicable when different parties handle inventory ownership and storage. A control account is a general ledger account whose balance reflects the balance of Accounts Payable/Accounts Receivable subledgers. This is a higher-level code above the special cost object and is used for control purposes. A translation of the actual budget into control data,

Checked In Checked Out CHM CLM CMG

CMS

CO COM Company

Control Account

Control code Control data

A-4

| Definitions, Acronyms, and Abbreviations

which is used for cost control. Cost Account/Project cost account An identified level at the intersection of the work breakdown 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. An extra dimension for the user to monitor the project. The most detailed level of a budget. It is used to register the actual hours and costs. All the project costs can be categorized into five cost types: material, labor, equipment, subcontracting, and sundry costs. Change Proposal. Contract management module in Service package. Contract Management. Cumulatives. Data Access Layer. Distribution Center. Dynamic Enterprise Modeling. Dynamic Form Editor. If the required goods are not available in the company to perform a sales order, the purchase office sends an order to the supplier to directly deliver to the customer. Dynamic Load Library. De-Militarized Zone: Part of a network which is located between two firewalls. Document Management. Document library is a library used to catalog documents. The lifecycle of a document from concept to completion. The Document Lifecycle involves many phases. The Document Management is a module in ODM, which provides general document management facilities to the ERP LN system. Document management ensures the efficient and secure use

Cost component Cost object Cost type

CP CTM CTM CUMS DAL DC DEM DFE Direct Delivery

DLL DMZ

DOC Document Libraries Document Lifecycle

Document Management

Definitions, Acronyms, and Abbreviations

| A-5

of consistent, reliable, and revision controlled document information. Document Management Committee In Document Management, a committee can be formed consisting of a chairperson and a few reviewers to become a part of the review process. This committee is known as a Document Management Committee. Any authorized user can create such a committee. The type of document for a company, such as safety regulations, wiring diagram, maintenance instructions, or standards. The user is authorized to perform various actions depending on the document type. Distribution Requirements Planning. Performance measurement; the budgeted costs of work performed. Electronic Data Interchange module in Electronic Commerce package. This module is responsible for receiving and sending the various messages through EDI. Elements are used to define the structure of the project. A module in ERP Common that is used to model the organization and make the enterprise modeling information available to the other ERP LN packages. Modeling the organization consists of defining the following: The entities. The relationships between the entities. The enterprise structure. Employee Enterprise unit A person employed by a company. An enterprise unit consists of logically grouped entities such as 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.

Document type

DRP Earned value EDI

Element EMM

A-6

| Definitions, Acronyms, and Abbreviations

EOQ EP Estimate to complete Economic Order Quantity. ERP LN Enterprise Planning. The value that represents a realistic appraisal of the cost of the work still required to complete a task. Extensions cover the specific agreements within or in addition to the initial contract. Fabrication. The factor is a bank or commercial finance company that specializes in buying receivables. Fixed Asset Management, a module of ERP LN Financials. Failure Based Maintenance, also called Breakdown Maintenance. Financial Budget System, a module of ERP LN Financials. Field Change Order. The object that points to a physical file. A company used for posting financial data in ERP LN Financials. You can link one or more enterprise units from multiple logistic companies to one financial company. ERP LN Freight Management. Freight order control module in Freight package. This module is responsible for creating the various freight orders. Folder is a data item that contains a group of related objects. The Folder Management is a module in ODM used to maintain folders. Folders simplify the management of product information. Financial Statements, a module of ERP LN Financials. General Ledger, a module of ERP LN Financials. All the ledger postings take place here. Synonym of Items. 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 do the following:

Extensions FAB Factor FAM FBM FBS FCO File Financial company

FM FOC

Folder Folder Management

FST GLD Goods Group company

Definitions, Acronyms, and Abbreviations

| A-7

Process the corporate and administrative accounting. Accumulate the data from the groups 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 can be stored using paper or other means. Item Base Data. Identification. Inventory Handling module in the Warehouse Management package. Inventory Handling. Inventory Reporting. Input/Output. Item Production Data. Item Purchase Data. Internal Revenue Service, which is a branch of the federal US government in charge of collecting most types of taxes. Item Sales Data. International Standard Organization. Classification of labor to which surcharge is to be linked.

IBD ID INH INH INR I/0 IPD IPU IRS

ISA ISO Labor Type

Logistic company

An ERP LN company used for logistic transactions, such as the production and transportation of goods. All the logistic data concerning the transactions is stored in the companys database. A logistic company can consist of enterprise units linked to different financial companies.

LSP LTS Mask Mateability

Logistic Service Provider. Language Translation System. A template that specifies the structure of an identification code. Within Freight Management, this is done through combination codes; this indicates whether items can be shipped together or whether a particular

A-8

| Definitions, Acronyms, and Abbreviations

vehicle can be used for transporting an item (compatibility). MAUC MCS MDM MMC MSC Multicompany (multisite) Moving Average Unit Cost. System tables module in Common package. Master Data Management. Microsoft Management Console. Maintenance sales control module in Service package. An organization in which the ERP LN configuration consists of more than one ERP LN 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 multicompany in this manual.

Multicurrency systems Functionality that allows an ERP LN company to do its accounting in more than one currency. Amounts are computed and registered in up to three currencies. Object Object Browsing An entity defined in ODM with all details to manage the Changes, Documents, Folders, and so on. The object explorer allows the user to view the objects links in the form of a graphical horizontal tree browser.

Object Family ODM

Group of objects with an object as owner to maintain the links. Object Data Management (ODM) is an independent package within ERP LN that provides effective data management and change management solutions in a project development scenario. A material item used as a component, not as a subassembly. Often used as a synonym for items. Production Bill of Material. Project Control Systems. Portable Document Format.

Part PBOM PCS PDF

Performance The time-phased budget plan against which project measurement baseline performance is measured. It is formed by the timephased budgets assigned to scheduled activities. PIN Project Invoicing module in the Project package.

Definitions, Acronyms, and Abbreviations

| A-9

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. Preventive Maintenance. Pooling points are fixed nodes in a route structure. Examples are regional DCs, harbors, bonded warehouses and sites where grouping of shipments, cross docking, centralized storage, and so on, take place, and from where goods are distributed again. People (module in Common). Product Testing and Control. Purchase. Quality Management. Generic mechanism for registering a set of records based on conditions provided by the user. Condition provided by the user based on attribute values used for setting up a query. Raw material. Relational Database Management System. This is an object defined in ODM and also related to the main object in a business flow. 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; this date is used 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.

PM Pooling Point

PPL PTC PUR QM Query Query Condition RAW RDBMS Related Objects Relative Change Orders (RCO)

Reviewers Mechanism This functionality is present in Change Management and Document Management. It allows the authorized user, in this case the Chairperson, to create a Committee and then define Reviewers by Document or Change Committee. RMA ROU Rule Return Material Authorization. Routing. Rules can be used as a one-point provision to trigger dependent events/entities.

A-10

| Definitions, Acronyms, and Abbreviations

SBM Service Level Subcontract Management. Service levels usually indicate a customers requirement regarding delivery times. Examples are Express Transport, 24 hours delivery, and so on. Shop Floor Control. Commercial enterprise or manufacturer for which transport is an essential part of the supply chain but not regarded as core business. Statistical Inventory Control. Sales invoicing module in Central invoicing package. The module is responsible for creation and sending invoices centrally. Sales module in Order Management package. Software Licensed Support Agreement. Service order control module in Service package. Service Planning and Concepts. Structured Query Language. Service Requirement Planning. Transport Means Group. Transport Management System. Time Phased Order Point. Differentiating hours spent by logistical package/module. If the order is received by an entity belonging to one financial company, but the goods are delivered by an entity belonging to another financial company (entities belonging to the same logistic company), the companies can 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. Triton Super Set. Use-Based Maintenance. Vehicle Identification Number. Work Control System. Warehouse Management. Work in Progress.

SFC Shipper

SIC SLI

SLS SLSA SOC SPC SQL SRP TMG TMS TPOP Transaction Type Triangular invoicing

TSS UBM VIN WCS WH WIP

Definitions, Acronyms, and Abbreviations

| A-11

WMD Work packages

Warehouse Master Data. Detailed short-span jobs identified by the contractor for accomplishing work required to complete a contract. A way to divide the day in parts linked to a labor type. Extensible Markup Language.

Working Time Schedule XML

A-12

| Definitions, Acronyms, and Abbreviations