P3496H Us
P3496H Us
P3496H Us
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 ................................................................................................................................ 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
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
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
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
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 [email protected]. 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.
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
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
2-6
| Enterprise Modeler
Main Function
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
Enterprise Modeler
| 2-9
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.
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
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.
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
Static Conditions
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.
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.
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
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
Manufacturing Strategies
High
Flow lay-out
3
Process - Standardization Standard Production in Multi Model Flow Line Customer Spec Production in Mix Model Flow Line
1
Functional lay-out
2 Low
Low
High
Product - Standardization
| 3-3
3-4
| 3-5
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
Lean
Assembly based
Repetitive based
SFC order SFC For End Prod. SFC Lean Procurement KANBAN Lean For End Prod. Lean
SFC based
Lean based
| 3-7
SFC
Sales Order - Forecast MRP / Cap planning Production Orders Scheduler Seq. /Capacity SFC -> Execution
3-8
| 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
3-10
RPT
Sales Order - Forecast Mixing / Cap planning Repetitive Schedule Sequencing / Capacity RPT -> Execution
| 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
KANBAN
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.
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
80 GB Hard disk
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 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.
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.
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.
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).
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.
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
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.
Financials
| 6-3
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.
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.
Financials
| 6-5
partner. Sales invoices that recur over the periods can be generated automatically based on the original sales invoice.
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.
6-8
| Financials
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.
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
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.
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
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.
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.
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
5.
4.
Process Engineering
7.
Supplier
Customer
Project M anagement
3.
2.
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
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.
1.
17.
11.
Project Administration
14.
15.
Store Goods
Picking - Advanced
Store Goods
Picking - Advanced
Inspection
Shipping - Basic
Goods Flow
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
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.
Project
| 7-7
Standard Revenues. Standard Structures. User-defined Structures. Project Templates. Standard Surcharges.
7-8
| Project
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
| 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.
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.
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 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
| 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.
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.
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.
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.
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
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
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
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.
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.
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.
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
| 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.
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.
Project
| 7-31
displayed. The request for quotations and manually entered purchase requisitions are also captured and displayed here.
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.
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
| 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
7-40
| Project
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
| 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
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.
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 Horizon
Master Planning
Order Planning
Plan Analysis
Adjust Planning
Plan Transfer
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.
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.
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.
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.
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 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.
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.
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.
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
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.
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.
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.
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.
Order Management
| 9-19
delivered quantity. The planning organization determines which concept must be applied.
9-20
| Order Management
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
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.
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.
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
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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
Revision control
Engineering is performed per revision. In the ERP package, you can refer to the revisions defined in EDM.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
Manufacturing
| 12-21
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.
Manufacturing
| 12-23
For PCS projects, a dashboard is available from which users can start all relevant sessions for a specific PSC project.
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.
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.
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.
12-26
| Manufacturing
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.
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).
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.
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
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
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.
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.
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
| 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.
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:
Handle disposition (of items in reject location) through new disposition session
Put away
Destroy (Scrap)
Return
Inventory is adjusted
put away
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.
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.
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:
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
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.
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
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.
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.
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
End Customer
Component Supplier 2
VMI Comp.
Assembly
Final Assy.
End Customer
Manufacturer
Component Supplier 3
VMI Products
Store/End Customer
Store/End Customer
13-22
| Warehouse Management
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.
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
Service
Enterprise Planning
Freight Management
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
Warehouse
Carrier
The functions and features of the following modules will be described: Freight Master Data (FMD).
Payment
Customer
14-4
| Freight Management
Freight Order Control (FOC). Rough Planning (RPG). Load Building (LBD). Freight Rate Control (FRC). Freight Invoicing (FRI).
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.
14-6
| Freight Management
Freight Management
| 14-7
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
= 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.
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.
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 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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
| 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.
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.
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.
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.
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.
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.
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.
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.
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.
15-28
| Service
Service organization
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.
15-30
| Service
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 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.
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
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.
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
SOC
SPC
PM terms PM Schedule
CLM
CTM
Sub-assemblies Support
SBM
MSC
Repairs Plan time
P a r a m e t e r s
WCS
Service Items Service organization Reference Activities
MDM
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.
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
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
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.
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.
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
| 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
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.
| 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 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
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
| 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.
17-8
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:
| 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
| 17-11
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
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
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.
| 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:
17-14
Registering a change
Configuring a change
Accepting a change
Implementing a change
| 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.
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
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.
| 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.
17-18
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
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
| 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.
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
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.
| 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.
17-22
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.
The following business objects in Queries and Reports are described below: Query Query Conditions Reports
| 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
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.
| 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
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.
| 17-27
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.
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
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.
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.
Multisite
| 18-5
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
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.
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 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 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.
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
iBaan Infor OpenWorldX Bus Connectivity Tools iBaan Infor OpenWorldX SOA Adapter Jav a Virtual Machine Development T ools
Database Drivers
Dep Depen dent endP latS er ent for ver m Pl atfo rm S erver
Operating System
DBMS (Database)
This architecture includes several layers. The following sections describe the contents of these layers in detail.
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.
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.
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.
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
ERP LN Technology
| 19-7
Internationalization
Multilanguage software
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.
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
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.
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).
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.
ERP LN Technology
| 19-13
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.
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.
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.
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.
ERP LN Technology
| 19-15
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.
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.
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
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.
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.
Desktop integration
For Windows Operating Systems, Desktop shortcuts can be made which link to ERP LN sessions. Shortcuts can also be mailed.
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
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.
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.
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.
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.
ERP LN Technology
| 19-25
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:
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.
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).
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.
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
End users
OLTP Application
OLTP Application
Source Database
Export
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
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.
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.
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.
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.
19-36
| ERP LN Technology
A service pack is created by bundling PMC solutions and offering these as one deliverable.
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
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.
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.
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.
ERP LN Technology
| 19-41
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.
ERP LN Technology
| 19-43
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.
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
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
| 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,
CMS
CO COM Company
Control Account
A-4
DLL DMZ
Document Management
| 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
Element EMM
A-6
Extensions FAB Factor FAM FBM FBS FCO File Financial company
FM FOC
| 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.
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.
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
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.
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.
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.
| 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
SFC Shipper
SIC SLI
SLS SLSA SOC SPC SQL SRP TMG TMS TPOP Transaction Type Triangular invoicing
| A-11
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.
A-12