Infor FMS Enterprise Edition 6 - WordPress › Installationbaansupport.com/docs/baan/Functions and features.pdf · ... Entity Relationship Model (ERD) ... General Ledger ... “Infor

Infor FMS Enterprise Edition 6.1

Functions & Features

Copyright © 2009 Infor

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

Important Notices

The material contained in this publication (including any supplementary information) constitutes and contains confidential and proprietary information of Infor.

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

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

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

Publication Information

Document code: P3616A US

Release: Infor FMS Enterprise Edition 6.1

Publication date: October 10

Table of Contents

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

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

Introduction ................................................................................................................................ 2-1

Level 1: Enterprise Structure Model..................................................................................... 2-3

Level 2: Business Control Model.......................................................................................... 2-5

Level 3: Business Functions, Processes, and Organization diagram................................... 2-6

Business Data Model – Entity Relationship Model (ERD).................................................... 2-8

Functionality............................................................................................................................... 2-9

Enterprise Structure Modeling in FMS Enterprise Edition .................................................... 2-9

Business Control Model ..................................................................................................... 2-10

Business Function Model ................................................................................................... 2-11

Link to business function/process model ........................................................................... 2-12

Business Process Model.................................................................................................... 2-13

Business Organization Model ............................................................................................ 2-14

Business Data Model - Entity Relationship Models (ERM) ................................................ 2-15

Chapter 3 Common .................................................................................................................. 3-1

Introduction ................................................................................................................................ 3-1

Calendars................................................................................................................................... 3-1

Item base data ........................................................................................................................... 3-2

Business partners ...................................................................................................................... 3-3

Taxation ..................................................................................................................................... 3-3

Chapter 4 Financials ................................................................................................................4-1

Introduction ................................................................................................................................ 4-1

ii | Table of Contents

General Ledger (GLD) ............................................................................................................... 4-1

Currency system.................................................................................................................. 4-2

Company structure............................................................................................................... 4-2

General ledger structure ...................................................................................................... 4-2

Financial integration transaction mapping............................................................................ 4-2

General ledger transactions................................................................................................. 4-3

Reconciliation....................................................................................................................... 4-3

General ledger inquiries and reports.................................................................................... 4-3

Period and year end closure ................................................................................................ 4-4

Tax reporting........................................................................................................................ 4-4

Accounts Receivable (ACR)....................................................................................................... 4-4

Accounts Payable (ACP)............................................................................................................ 4-7

Cash Management (CMG) ......................................................................................................... 4-8

Financial Budget System (FBS) ............................................................................................... 4-10

Cost Accounting (CAT) ............................................................................................................ 4-11

Fixed Assets Management (FAM)............................................................................................ 4-13

Financial Statements (FST) ..................................................................................................... 4-14

Chapter 5 Order Management ................................................................................................. 5-1

Introduction ................................................................................................................................ 5-1

Important master data for Order Management........................................................................... 5-1

Sales office .......................................................................................................................... 5-2

Purchase office .................................................................................................................... 5-2

Dashboards.......................................................................................................................... 5-2

Pricing ........................................................................................................................................ 5-3

Sales Control ............................................................................................................................. 5-3

Sales master data ................................................................................................................ 5-4

Sales quotations .................................................................................................................. 5-4

Sales order entry.................................................................................................................. 5-5

Commission and rebate ....................................................................................................... 5-7

Purchase Control ....................................................................................................................... 5-8

Purchase master data.......................................................................................................... 5-8

Purchase requisitions........................................................................................................... 5-8

Table of Contents | iii

Purchase RFQs ................................................................................................................... 5-9

Purchase order entry ...........................................................................................................5-9

Vendor management ......................................................................................................... 5-10

Purchase contracts ............................................................................................................ 5-10

Delivery contract ...................................................................................................................... 5-12

Purchase schedule contract..................................................................................................... 5-12

Purchase contract line logistic data.......................................................................................... 5-12

Purchase contract price revisions ...................................................................................... 5-14

Sales contracts .................................................................................................................. 5-14

Purchase and Sales Schedule Management ........................................................................... 5-16

Introduction ........................................................................................................................ 5-16

Purchase schedule management....................................................................................... 5-17

Push and pull demand ....................................................................................................... 5-17

Purchase schedule header ................................................................................................ 5-18

Purchase schedule lines .................................................................................................... 5-19

Warehouse Management integration ................................................................................. 5-20

Process the purchase schedule ......................................................................................... 5-22

Purchase release header................................................................................................... 5-23

Purchase release lines....................................................................................................... 5-25

Purchase release lines details ........................................................................................... 5-26

CUM handling and FAB/RAW authorizations..................................................................... 5-26

Sales schedule management................................................................................................... 5-28

Introduction ........................................................................................................................ 5-28

Sales releases ................................................................................................................... 5-28

Sales release header ......................................................................................................... 5-28

Sales release lines............................................................................................................. 5-29

Sales schedule header ...................................................................................................... 5-29

Sales schedule lines .......................................................................................................... 5-31

Schedule shipment details/corrections............................................................................... 5-33

Sequence shipping information.......................................................................................... 5-33

Sales schedule reconciliation............................................................................................. 5-34

CUM handling and FAB/RAW authorizations..................................................................... 5-34

iv | Table of Contents

Purchase and Sales Statistics............................................................................................ 5-35

Chapter 6 Electronic Commerce ............................................................................................. 6-1

Introduction ................................................................................................................................ 6-1

Master data.......................................................................................................................... 6-2

Networks.............................................................................................................................. 6-2

Conversion........................................................................................................................... 6-2

Communication .................................................................................................................... 6-3

Message data ...................................................................................................................... 6-3

General ................................................................................................................................ 6-3

Chapter 7 Central Invoicing..................................................................................................... 7-1

Introduction ................................................................................................................................ 7-1

Sales Invoicing........................................................................................................................... 7-1

Chapter 8 Warehouse Management........................................................................................ 8-1

Introduction ................................................................................................................................ 8-1

Warehouse master data............................................................................................................. 8-2

Introduction .......................................................................................................................... 8-2

Warehouses......................................................................................................................... 8-2

Items .................................................................................................................................... 8-2

Warehouse order procedure ................................................................................................ 8-3

Miscellaneous ...................................................................................................................... 8-3

Inventory planning...................................................................................................................... 8-3

Introduction .......................................................................................................................... 8-3

Planned inventory transaction.............................................................................................. 8-4

Replenishment ..................................................................................................................... 8-4

Inventory commitment.......................................................................................................... 8-5

Inventory Handling ..................................................................................................................... 8-5

Introduction .......................................................................................................................... 8-5

Warehouse Management orders.......................................................................................... 8-5

Cross-docking ...................................................................................................................... 8-6

Direct Material Supply.......................................................................................................... 8-6

Inbound................................................................................................................................ 8-7

Table of Contents | v

Outbound ............................................................................................................................. 8-8

Value added services......................................................................................................... 8-10

Handling units .................................................................................................................... 8-10

Cycle counting ................................................................................................................... 8-11

Inventory adjustments........................................................................................................ 8-12

Blocking ............................................................................................................................. 8-12

Inventory Reporting.................................................................................................................. 8-13

Introduction ........................................................................................................................ 8-13

Inventory position............................................................................................................... 8-13

Inventory transactions........................................................................................................ 8-14

Inventory Analysis .................................................................................................................... 8-14

Lot Control and Serials............................................................................................................. 8-14

Introduction ........................................................................................................................ 8-14

Lot control .......................................................................................................................... 8-14

Serials................................................................................................................................ 8-15

Consignment stock................................................................................................................... 8-15

Consignment (not owned) .................................................................................................. 8-15

Consignment (owned)........................................................................................................ 8-16

Consignment replenishment and payment......................................................................... 8-16

Chapter 9 Cost Price Calculation............................................................................................ 9-1

Introduction ................................................................................................................................ 9-1

Cost price calculation ................................................................................................................. 9-1

Chapter 10 Multisite ................................................................................................................. 10-1

Introduction .............................................................................................................................. 10-1

Multisite environments ............................................................................................................. 10-2

Some multicompany terms....................................................................................................... 10-3

Enterprise structure modeling .................................................................................................. 10-6

Enterprise units ........................................................................................................................ 10-7

Multicurrency............................................................................................................................ 10-8

Intra-logistic-company transactions.......................................................................................... 10-8

Data sharing............................................................................................................................. 10-8

vi | Table of Contents

Multicompany processing......................................................................................................... 10-9

Multicompany Financials.......................................................................................................... 10-9

Multicompany Order Management ........................................................................................... 10-9

Multicompany Warehousing................................................................................................... 10-10

Chapter 11 FMS Enterprise: The technology......................................................................... 11-1

Introduction .............................................................................................................................. 11-1

Architecture.............................................................................................................................. 11-2

Server platform layer.......................................................................................................... 11-2

Server platform-dependent layer........................................................................................ 11-2

Server platform-independent layer..................................................................................... 11-3

Client platform dependent layer ......................................................................................... 11-4

FMS Enterprise Edition Runtime Environment......................................................................... 11-4

Virtual Machine (bshell) ..................................................................................................... 11-4

Database driver.................................................................................................................. 11-5

Application Services Manager (ASM) ................................................................................ 11-6

Platform and database support for Infor FMS Enterprise Edition 6.1 ................................. 11-7

Internationalization................................................................................................................... 11-7

Multibyte enabling .............................................................................................................. 11-7

Multi-language ................................................................................................................... 11-8

Multicurrency...................................................................................................................... 11-9

User Interface .......................................................................................................................... 11-9

Infor WebTop versus Infor Worktop ................................................................................... 11-9

Infor WebTop specific User Interface features ................................................................. 11-11

Generic User Interface features ....................................................................................... 11-13

Infor Web Help ................................................................................................................. 11-16

Infor Integration Pack 2.0 for FMS Enterprise Edition – Microsoft® Office 2000/XP .............. 11-18

Product Details................................................................................................................. 11-19

Infor FMS Connectivity........................................................................................................... 11-19

Introduction ...................................................................................................................... 11-19

Business Object Modeling ............................................................................................... 11-21

Integration Studio............................................................................................................. 11-22

Infor FMS third-party integrations........................................................................................... 11-24

Table of Contents | vii

Infor FMS Exchange .............................................................................................................. 11-24

Introduction ...................................................................................................................... 11-24

Architectural overview...................................................................................................... 11-25

Characteristics ................................................................................................................. 11-25

Not just data..................................................................................................................... 11-26

Fast.................................................................................................................................. 11-26

Open ................................................................................................................................ 11-26

Safe ................................................................................................................................. 11-27

Multisite enabled .............................................................................................................. 11-27

Manageable ..................................................................................................................... 11-28

Environment-friendly ........................................................................................................ 11-28

Infor FMS Application Management ....................................................................................... 11-28

Job Management ............................................................................................................. 11-28

Device Management ........................................................................................................ 11-28

User Management ........................................................................................................... 11-29

Authorization Management System (AMS) ...................................................................... 11-29

Audit Management........................................................................................................... 11-29

Infor FMS Development Environment .................................................................................... 11-29

Introduction ...................................................................................................................... 11-29

3GL and 4GL sessions .................................................................................................... 11-30

Dynamic forms ................................................................................................................. 11-30

Labels .............................................................................................................................. 11-31

Data Dictionary ................................................................................................................ 11-31

Source Configuration Management ................................................................................. 11-32

Product Maintenance and Control (PMC) ........................................................................ 11-32

Installation and licensing ........................................................................................................ 11-33

Introduction ...................................................................................................................... 11-33

Infor FMS staging wizard ................................................................................................. 11-33

Infor FMS Installer............................................................................................................ 11-34

Infor License Manager (SLM)........................................................................................... 11-35

Concurrent user license ................................................................................................... 11-36

Named user license ......................................................................................................... 11-36

viii | Table of Contents

Server license .................................................................................................................. 11-37

SLM components ............................................................................................................. 11-37

SLM validation procedure ................................................................................................ 11-37

SLM deployment .............................................................................................................. 11-38

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

About this Guide

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

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

This document contains the following chapters:

Chapter 1, “Infor FMS overview,” provides a general introduction to Infor FMS Enterprise Edition and to this document.

Chapter 2, “Enterprise Modeler,” discusses the Enterprise Modeler functionality in FMS Enterprise Edition.

Chapters 3 through 10 provide a detailed description of the modules and functionality of the various packages in Infor FMS Enterprise Edition.

Chapter 11, “Infor FMS Enterprise Edition Technology,” provides detailed information regarding the technology used in Infor FMS Enterprise Edition.

Appendix A provides a glossary of terms used in both Infor FMS Enterprise Edition and in this document, as well as a list of relevant abbreviations

Send us your comments

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

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

mailto:[email protected]?subject=Documentation�

x | Table of Contents

1 Chapter 1 Introduction

Infor FMS Enterprise Edition is a flexible, modular accounting and business system. Surrounding its core Financial modules are modules supporting sales, purchasing and inventory management.

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

Infor FMS Enterprise Edition complies with many national and international business practices and legal requirements and supports multiple currencies and languages, and helps to build successful international operations in today’s global environment.

2 Chapter 2 Enterprise Modeler

Introduction

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

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

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

In the framework of the Dynamic Enterprise Modeling (DEM) concept, the implementation and the initial setup of FMS Enterprise Edition is realized by means of 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 FMS Enterprise Edition solution, which effectively supports the business processes.

The key message concerning these models is that best-practice vision and experiences of both Infor consultants and partners are captured in the

2-2 | 1BEnterprise Modeler

predefined model, which serves as a catalyst in the creative and innovative process of BPR.

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

In short, the Enterprise Modeler provides the following:

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

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

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

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

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

1BEnterprise Modeler | 2-3

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

Enterprise Structure Model

Main Process FlowsBusiness Function Model

Business Control Models

Bus. Organization Model

Level 1: Enterprise Structure Model

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

Customers

Sales offices

Distribution centers

Assembly sites

Manufacturing sites

Suppliers

Central planning/purchasing sites


The Enterprise structure model:

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

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

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

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

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


Level 2: Business Control Model

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

The company’s primary industrial processes.

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

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

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

The Business Control Model:


Level 3: Business Functions, Processes, and Organization diagram

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

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

Business Function Variants

Optimization Relationship

Text linked to Bus. Process

Company

Mega/MajorFunction

MainFunction

Business Function options

ABC

Business Process Model (BP):

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


Business Organization Model:

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

OrganizationalUnit

StaffDepartment

Text byOrganizationalUnit Text linked

to Org. UnitUnit

Subdiagram

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

Roles by Organizational Unit

FunctionalRelationship


Business Data Model – Entity Relationship Model (ERD)

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

Document the logical and physical data structure of the FMS Enterprise Edition applications.

Disclose the data model part that is affected by the processes and FMS Enterprise Edition sessions.

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

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

The Data Model:


Functionality

Enterprise Structure Modeling in FMS Enterprise Edition

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

Order flow

Goods flow

Cash flow

Information flow

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

Name and description

Logistic company

Financial company

Reference model

Quantitative data, such as volumes and frequencies

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

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

Selection of processes

Configuration of these processes

Parameter settings

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


Business Control Model

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

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

Primary process (routing)

Customer order decoupling point

Management and control on production unit level

Management and control on logistic level (total goods flow)

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

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


FINAL ASSEMBLY

Assembly control

Sales Order

ReleasedFAS Order

Goods issueProcessControlCycle

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

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

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

Start event: Which events trigger this process?

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

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

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

Business Function Model

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

Best-practices business knowledge recorded by experienced consultants.

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

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


The Business Function Model includes the following characteristics:

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

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

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

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

Link to business function/process model

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

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

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


Link to business function / Process model:

Main Process Flow

Select Processes

Static Conditions

What How

Wizards:• Parameters• Master Data

Main Function

Mega/MajorFunction

Company

ProcessOptimization

ImplementationWizards

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

Business Process Model

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

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

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

The processes form the perfect vehicle for describing the FMS Enterprise Edition functionality and, even more importantly, what it can do for the customer’s business.

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

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


The business process model includes the following characteristics:

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

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

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

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

You can link roles and employees to business process activities.

Business Organization Model

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


Business Data Model - Entity Relationship Models (ERM)

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

1:1 A one-to-one relationship.

1:n A one-to-many relationship.

n:m A many-to-many relationship.

Optional Signifies that a relationship does not always exist.

The ERM Model can be defined at various abstraction levels:

Data cluster: Clusters a number of logical entities.

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

Physical entity: Database table definitions of the FMS Enterprise Edition application.

3 Chapter 3 Common

Introduction

Infor FMS Common provides quick access to data that is shared throughout the FMS Enterprise Edition applications.

Calendars

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

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

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

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

3-2 | 2BCommon

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

You can also split the calendar of a resource based on the activity for which the resource is used.

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.

Item base data

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

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

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

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

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

2BCommon | 3-3

Business partners

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

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

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

Taxation

Infor FMS Enterprise Edition 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, uses 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 means of the standard payment process.

In addition to tax reporting, European sales listings and European intrastat reporting are also available.

4 Chapter 4 Financials

Introduction

Infor FMS Financials can be used in a fully integrated environment or as a stand-alone financial system. Infor FMS Financials supports the needs of organizations consisting of multiple companies or business units operating in different environments. Infor FMS 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)

General Ledger (GLD)

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

4-2 | 3BFinancials

Currency system

Infor FMS offers a Euro compliant multicurrency system with up to three base currencies and an unlimited number of transaction currencies. For high inflation countries an ‘independent’ multicurrency system is available.

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

Company structure

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

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

General ledger structure

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

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

Infor FMS Financials offers user definable financial calendars for statutory, management and tax reporting.

Financial integration transaction mapping

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

The mapping scheme is version controlled, so if the mapping is changed, proper auditing is still possible as it is always known according which

3BFinancials | 4-3

mapping scheme version a transaction has been mapped. During activation of a new version the system checks the completeness and consistency (e.g. similar mapping on debit and credit side on interim account) of the setup.

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

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

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

General ledger transactions

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

Reconciliation

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

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

General ledger inquiries and reports

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

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

4-4 | 3BFinancials

Period and year end closure

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

Tax reporting

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

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

Accounts Receivable (ACR)

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

Financial business partner groups can be created for groups of invoice-to business partners. The classification in groups is generally based on certain common features such as area or product type. Various ledger accounts can be assigned to each financial business partner group, which allows automatic postings of transactions to be created. It is possible to maintain multiple control accounts for a business partner group depending on the kind of sale made.

Users can define a payment schedule to enable invoice payment in installments. Conditions such as payment dates, payment method, and payment discounts can vary by schedule line.

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

Fixed assets can be disposed through Accounts Receivable. Sales invoice belonging to the miscellaneous revenue originating from logistics can be

3BFinancials | 4-5

registered. It is possible to register intercompany and intergroup sales invoices (and credit notes).

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

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

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

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

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

Aging of the receivables into the various buckets can be done based on the days, months, or financial periods that the invoice has remained open. The user can determine whether doubtful invoices, anticipated receipts can be considered for aging. Aging can either be based on the invoice date or the due date.

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

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

4-6 | 3BFinancials

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

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

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

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

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

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

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

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

3BFinancials | 4-7

Accounts Payable (ACP)

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

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

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

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

Using the automatic three-way match functionality, users can match purchase invoices with purchase orders or freight orders. In addition, users can also manually match with the order or receipt.

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

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

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

Purchase invoices can also be received by means of EDI.

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

4-8 | 3BFinancials

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

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

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

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

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

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

Cash Management (CMG)

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

A company can be set up to either process its own receipts and payments or to have these handled by its financial group company. Transactions can be performed in any currency. Multicurrency support allows you to register

3BFinancials | 4-9

financial postings in up to three home currencies in addition to the document currency.

The Master Data business object sets up the basic data that will be used throughout the Cash Management module, such as bank relations, payment methods, data by bank/payment method, electronic bank statements, and so on. User authorizations can be defined for acceptance of payment differences, payment discounts, and bank costs. In addition, you can set up maximum payment amounts by user or by business partner.

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

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

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

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

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

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

A cash forecast is available for money requirement planning purposes. The forecast can be generated based on selected item ranges from purchase

4-10 | 3BFinancials

invoices, sales invoices, non order related sales invoices, purchase orders, sales orders, sales quotations, standing orders, and budgets.

The Electronic Bank Statements (EBS) module in Infor FMS 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.

Financial Budget System (FBS)

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

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

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

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

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

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

3BFinancials | 4-11

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

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

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

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

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

Cost Accounting (CAT)

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

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

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

4-12 | 3BFinancials

Hours Accounting module in order to calculate the allowed costs as a flexible budget.

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

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

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

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

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

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

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

The Cost Accounting module in Infor FMS Financials also contains the functionality to perform Activity Based Costing. In order to perform Activity

3BFinancials | 4-13

Based Costing, one of the dimension types must be selected for the activities. Activities can be combined with cost drivers. Allocations to cost objects may be based on the entered quantities or amounts of the cost drivers. After the collection of costs from other dimension types on activities, consumption rates for activities are calculated. There are even cost drivers defined for the cost objects, such as the number of sold items of a special kind. Actual quantities can be derived from logistics in the Cost Analysis business object. These cost drivers serve as surcharge base for the cost objects. After costs are allocated from activities to cost objects, actual surcharges can be determined and transferred into the Cost Price Calculation module master data.

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

Fixed Assets Management (FAM)

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

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

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

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

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

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

4-14 | 3BFinancials

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

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

The costs of an asset can be filled through the Accounts Payable module as you can link a purchase invoice to an asset.

Assets can be revaluated based on indices.

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

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

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

Financial Statements (FST)

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

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

Report layout (incl. graphs) is defined in Infor Enterprise Reporting for FMS Enterprise Edition. This application takes the prepared data from the data warehouse and prints the actual reports.

5 Chapter 5 Order Management

Introduction

Order Management supports the entire sales and purchase process from start to finish. For this purpose, abundant functionality is available including Pricing; Purchase Control, including requisitions, RFQs, contracts, schedules, orders, and vendor management; and Sales Control, including quotations, contracts, schedules, orders, and commissions and rebates.

Important master data for Order Management

When conducting business, users today are confronted with increasingly complex organizations, internally and externally, in buying and selling processes. To support this type of complexity, a new business partner structure has been introduced in Infor FMS.

Internal business partners

You can define purchase and sales offices. A purchase or sales office is a department clearly identified in the company business model in charge to manage business partners’ sales or purchase relationships.

Purchase and sales offices can be used for setting up defaults, authorizations, pricing, and so on. This entity will be handled as a cluster according to the multisite structure.

5-2 | 4BOrder Management

Sales office

Sales representatives can be assigned towards a sales office.

A sales office is a criterion for price agreements.

A sales office retrieves defaults concerning the applicable warehouse, order series, quotation series, and contract series.

A sales office can be used as selection criterion for printing reports.

Purchase office

Buyers and ranges of items/item groups can be assigned towards a purchase office.

A purchase office is a criterion for price agreements.

A purchase office retrieves defaults in regard to the applicable financial company, warehouse, output device, and order series.

A purchase office can be uses as a selection criterion for printing reports.

External business partners

Suppliers and customers can be defined as business partners and a business partner can perform various roles. A supplier can have the following roles: buy-from, ship-from, invoice-from, and pay-to. A customer can have the following rolls: sold-to, ship-to, invoice-to, and pay-by.

Dashboards

In Order Management, two dashboards are created: one for a buyer, known as the Buyer’s Dashboard, and one for an account manager, known as the Account Manager Dashboard. A dashboard is an overview session that provides a quick insight into the status of a particular object. The user is not required to go into the menus to open related sessions to see whether data is available. In the dashboard, all sessions related to the object are visible (buttons), and check boxes indicate whether data is available.

4BOrder Management | 5-3

Pricing

The new Pricing module can manage sales prices, including promotions and discounts and purchase prices & discounts. Main enhancement is the flexibility of defining prices & discounts and enables for complex pricing requirements of each business partner. A matrix can be set up, up to six levels, with a choice of a wide range of various attributes related to business partner, order data, and item data. You can set the line item discount, up to five levels. A line item discount can be an aggregation of several discount schedules. The module enables you to make prices & discounts based on quantity or value and to simulate the changes before you make decisions. Prices for configured items are handled in the PCF module. Prices for kits can be handled, as well as transfer prices in case of triangular invoicing, in which the sales office where goods are sold from does not belong to the same financial company as the warehouse from which goods are shipped.

Prices are stored in price books. Price books are broken down in order value or quantity.

Discounts are stored in discount schedules. Discount schedules are broken down in order value or quantity.

A flexible search engine will search for the right price or discount. Every price or discount is assigned to a combination of various attributes. The order data must match these attributes before a price or discount will be applied. Attributes can be a combination of business partner data, item data, and order data.

Both order and line item discounts are available.

The Pricing application enables you to apply several discounts at line-item level, however, discount strategies, such as accumulating ordered quantities for a particular item, are also supported.

Fixed amount and percentage discounts by multiple units of measure along with advanced tracking of conditions to evaluate margins and income.

The Pricing application handles multicurrency environments.

Tools to automatically increase or decrease prices or discounts.

Simulation capabilities to support “what if” scenarios are also available.

Sales Control

Sales Control can handle the entire sales order fulfillment process, including the control of quotations, contracts, schedules, orders, and commissions & rebates.


Sales master data

In Sales Control, the following items can be handled: standard items, generic items, customized items, service items, list items, costs items, and phantoms. In addition, you can maintain the alternative item codes by alternative code system, customer, or item. The company’s item code is used throughout the procedure, but the alternative code is available and can be used in customized reports.

In Sales Control, you can add additional sales-related item data. Item descriptions for each customer are also handled here.

You can maintain profiles with user-specific default data. You can define a print device for each external document such as, for example, the order acknowledgement. You can also specify values that are used when new sales orders are created, for example: order type, warehouse, or order series. You can define various order types. Each order type defines the steps that are mandatory in the order procedure and how the steps will be executed: automatic or not.

Sales quotations

You can type in sales quotations manually or generate the quotations from sales budgets. You can quote multiple alternative lines for every quotation line, and you can attach price and discount structures to quotations. You can copy quotations from other quotations, even if the source quotation belongs to another customer or if the quotation is in history. You can copy all lines, alternative lines, and missed quotation lines in the quotation copy process.

After the sales quotation has been registered in Infor FMS, you can print and send the quotation to the customer.

You can accept or reject each separate quotation line. You can maintain and link reasons for success/failure to the quotation lines. You can also maintain and link reasons for competitors. You can generate sales orders for the accepted sales quotation lines.

If insufficient inventory is available, a parameter determines if you can block copying to a sales order.

After the inventory is processed, the sales quotation is handled as a regular sales order.

You can maintain the expected success percentage for every quotation, and change the percentage for every line of the quotation. Enterprise Planning handles the planned inventory transactions for quotations.


However, Enterprise Planning only handles the inventory if the success percentage of a line at least equals the percentage determined by the corresponding parameter or the value entered while running the program.

You can view or print the history of sales quotations. You can call the history data for each customer and for each item. You can also print and delete the quotation history.

Sales order entry

You can create sales orders manually, or by means of E-Commerce (EDI and Internet). You can also copy a sales order from another sales order. The original sales order can belong to another customer, and you can even copy a sales order from history.

Every sales order is associated with an order type. The order type enables you to indicate the settings for the order; an order can be a collect order, a return order, a cost order, a combination of these, or a regular sales order only. A cost order can only contain cost and service items, while a return order contains negative quantities only. Items sold on a collect order are issued from inventory immediately on order entry.

The way a sales order is entered in a system can be carried out in an easy way: one screen for both the order header and the lines. To support fast order entry in cases where large ranges of product references exist, you can use item proposal lists, such as kits, options, accessories, menus, Order Templates and Catalog.

During order entry, many processes are initiated, such as credit checking, during three events: order entry, releasing to Warehouse Management, and confirm shipment; margin control; price & discount simulations and calculations; order promising by means of the Available To Promise (ATP) and/or Capable to Promise (CTP) functionality of the Extended Enterprise Planning application; check on available inventory in the (multisite) distribution network; inventory commitment; and so on. In addition, order-blocking capabilities are also important.

Infor FMS has been extended with multiple hold reasons, a separate release process, and a blocking history. After you maintain the sales order, you can print and send an order acknowledgment to the customer, which you can also send by means of EDI. Functionality for return management has been extended and you can now link a return order to the original document, such as an order number, shipment ID, or invoice number, which also enables you to copy relevant data from the original order to the return order. You can also print an RMA document.


Delivery constraints are a flexible way to handle deliveries based on customer requirements. Multiple delivery constraints that determine whether or not the customer will accept multiple shipment and/or backorders are managed.

The following constraints are supported: ship line complete, ship set complete, ship order complete, and ship line & cancel. Actual delivery takes place after sales orders are released in Warehousing.

You can specify the quantity for every item when the item is delivered directly from the supplier to the customer. If a sales order is booked and the quantity exceeds the predefined quantity, the Delivery Type field is automatically set to Direct Delivery and the Warehouse field is cleared. The other values of the Delivery Type field are: Warehouse and Cross-docking. Depending on a parameter, a purchase order is created directly or is created manually later on. This purchase order is delivered directly from the supplier to the customer. After processing, the purchase order the sales order that initialized the purchase delivery can be processed and invoiced

Sales orders can either be invoiced by installments or on delivery of goods. You can maintain up to nine default installment schedules. An installment schedule can be used to invoice the sales order. In addition, self-billing facilities are incorporated in the sales order procedure. The actual invoicing takes place, after sales orders are released, in the Central Invoicing module. The user can add additional costs, such as freight costs, to the sales invoice.

Change management of order is supported by the use of predefined change reason codes for display, reporting, and analyzing purposes.

To analyze the order entry process, periodically you can also view demand and lost sales information. This type of information is automatically updated during order entry.

In sales order history, you can view, print, or delete the history of sales orders. Historic data that is no longer relevant can be deleted.

The deleted data is printed out. Similar to printing or displaying data, you can select created orders, invoiced orders, or both.

The user can also generate freight orders directly from a sales order, depending on a parameter setting.

The sales order header also includes a status to support a better integration with CRM product. This sales order header status is a derived from status, and can have the following values: Free, Approved, In Process, Modified, Closed, Canceled, or Blocked.


The status is Free when the order is entered manually or generated automatically by CRM or EDI. The status is Approved at the moment the user clicks the icon to check the sales order so that the order header changes from Free to Approved. As soon the order status is Approved, the order is ready for execution. This means that, if the first activity on a line is set to Automatic, the activity will be executed immediately. The order header receives the status In Process when one of the activities is executed. The order header receives the status Modified when an existing line is changed or a new line is added. The order status changes to Closed when all requirements are delivered and invoiced. The status of the order becomes Cancelled when the user clicks Cancel on the order header. As a result, a canceled order is not available for execution. The order header status is Blocked if blocking checks are applicable and being set in the order type.

Commission and rebate

Commission and rebate functionality supports the calculation and control of commissions and rebates payable to trade relations. Trade relations can either be own employees (sales people), agents (suppliers), or customers. Commissions are paid to employees or agents (suppliers). Rebates are paid to customers. Because commissions and rebates are based on quantities or amounts sold, this module is closely integrated with the sales order entry.

Agreements can be recorded on which the calculation of commission and rebates is based. From global to detailed, you can record agreements on various levels, such as: customer, relation, agreement group, item, and commission/rebate group.

A calculation for the relations linked to a sales order (line) is based on the relevant sales order. A parameter determines whether you can carry out a calculation interactively or automatically while you create a sales order.

You can even postpone a calculation, for example, by executing a calculation as a periodic process. This can be useful if multiple agreements are based on cumulative sales.

If you require a reservation procedure and a link exists to Infor FMS Financials, reservations are transferred to Financials. Approval procedures are applicable.

Reservations for calculated commissions for employees are always transferred to Infor FMS Financials.

History of commissions and rebates is created immediately during the calculating procedure. This history can be displayed or reported.


Purchase Control

Purchase Control can handle the entire procurement process, including the control of purchase requisitions, RFQs, contracts, schedules, orders, and vendor management.

Purchase master data

In Purchase Control, the following items can be handled: standard items, generic items, project items, service items, subcontracting items, list items, costs items, and phantoms.

In Purchase Control, additional purchase-related item data can be added. For each item, you can name a preferred supplier and an alternative supplier. You can specify the percentage of requirements to be divided among the alternative suppliers. The user can also maintain various types of data for each supplier/item combination, for example, an approved supplier list. Purchase Control also enables you to define multiple manufacturers for each item/supplier combination.

In addition, you can register receipt tolerances for each item group, item, supplier/item, supplier, and supplier group. These tolerances are used in Warehouse Management to determine whether a receipt quantity unequal to the order quantity is acceptable.

You can also maintain profiles of user-specific default data. Users can type default values to specify the method of order entry they prefer. In addition, you can define some values that will probably be used when new RFQs or purchase orders are created as default values, for example, the warehouse, order series number, and order type.

Order types determine the steps that must be carried out and how these steps will be executed: automatic or manually.

Purchase requisitions

The purchase requisitions functionality will be to front end the purchasing process.

Purchase requisitions are used to enter non-system planned requirements for various types of items, including standard inventory, cost, service, and subcontract items.

The requester can also submit a requisition for an item that does not exist on the system by simply describing the item.


A requisition can result in a RFQ, a contract, or a purchase order.

Purchase RFQs

RFQs can be sent to various suppliers. You can enter the quotations sent by suppliers into Infor FMS. Together with the vendor rating data, the information presented enables you to select the most suitable supplier for the items on the inquiry.

Based on existing price information, additional information also appears which enables you to compare existing price lists and new quotations.

If suppliers do not return their quotations on time, you can print reminders.

After you make a decision, you can copy the inquiry to contract or order. You can select more than one supplier for each item. In that case, Infor FMS asks for a percentage of the total quantity to be ordered for each supplier.

After you make a decision, you can print and send a letter to thank the suppliers who were not selected.

Historical information is available related to created inquiries, copied inquiries (into an order or contract), and deleted inquiries.

Purchase order entry

You can create purchase orders manually or generate the purchase orders from various applications. Order (advices) generated by the various applications can be grouped into one Purchase Order (commingling). You can also copy a purchase order from another purchase order. The original purchase order might belong to another supplier, and you can even copy a purchase order from history.

Every purchase order is associated with an order type. The order type enables you to indicate the settings for the order. An order can be a collect order, a return order, a cost order, a subcontracting order, a combination of these various types, or simply a regular purchase order, which can be workflow-enabled. A cost order can only contain cost items, while a return order contains negative quantities only. Items bought on a collect order are added to inventory immediately on order entry.

During order entry, various processes are initiated, such as retrieving the right price and discount. After you maintain the purchase order, you can print an order acknowledgment after you receive a confirmation from the supplier, which can also be received by means of EDI.


Purchase orders are released to Warehouse Management, where a global receipt function is available. If the actual delivered goods do not match the packing slips in Warehouse Management, you can send a report (claim note) to the supplier and print reminders if deliveries are late.

The user can also add additional costs, for example, freight costs, to the purchase invoice. Pay-on-use and pay-on-receipt are supported. Extensive purchase matching capabilities triggered by Accounts Receivable are available.

Change management of order is supported by the use of predefined change reason codes for display, reporting, and analyzing purposes.

In purchase order history, you can view, print, or delete the history of purchase orders. Historic data that is no longer relevant can be deleted. The deleted data is printed out. Similar to printing or displaying data, you can select created orders, invoiced orders, or both.

Vendor management

Vendor management has been substantially extended by the introduction of sourcing rules, an Approved Supplier List (ASL) and vendor rating functionality.

With sourcing rules, you can predefine what percentage of products you want, such as to receive from which supplier. For more information, see also Purchase item and master data.

ASL enables to identify a supplier status for each item, such as approved, preferred, fixed, blocked, and a particular rating.

Vendor rating is based on objective and subjective criteria. The system can calculate the results of objective criteria related to receipts, quality approval, invoicing, and purchase order confirmation. The user can determine the subjective criteria by the user on a case-to-case basis. Every criterion can be rated by giving a weighting factor expressed in a percentage.

Purchase contracts

The purchase contract can be defined as a normal contract or as a specific contract. The specific contracts are used in specific circumstances, for example, to support special promotion actions, such as around Christmastime.


For this reason, you cannot define two normal contracts that are both valid at the same time for the same business partner, despite the fact that this is permitted for special contracts.

If desired, you can print a purchase acknowledgment. In the contract, all relevant information around business partners can be stored, including the following:

Buy-from business partner, ship-from business partner, invoice-from business partner, and pay-to business partner, including the related address data

Delivery warehouse

Terms of delivery

Carrier

Currency and tax information

Terms of payment and late payment surcharge.

In the purchase contract, the relevant item information is stored. This information can be based on own item-codes. However, using item code systems, you can also store external used item codes in the contract lines, to make communication between customer and supplier easier.

You can also fill the applicable effectivity unit for the purchase contract lines, together with the engineering revision information.

Each contract line must be valid, as indicated with dates, between the boundaries, set on the purchase contract header.

In the contract line, you can fill the agreed quantity with other relevant quantity information, such as the following:

Order quantities:

Minimum order quantity

Maximum order quantity

Economic order quantity

Order quantity multiple

Evaluation quantity data

Other relevant data that is present on the contract line includes the delivery warehouse and the flag to indicate whether self-billing is available.

The purchase contract can be used as a delivery contract or as a means to support the purchase schedules.


Delivery contract

You can use a delivery contract for situations in which multiple purchase/sales orders lines must be defined, all covered by the same purchase/sales contract, but each order line having a different delivery date.

After you mark the contract line as being a delivery contract, you can specify at which moment these items must be delivered with the purchase/sales order. The total quantity, as specified in the Delivery Contract session, cannot exceed the contract line quantity. Each line, as defined in the Delivery Contract session, results in a separate purchase/sales order line.

Purchase schedule contract

As soon as the item that is defined in the purchase contract line can be used in purchase schedules, as indicated by a flag on the General Item data, the Purchase Schedule in Use check box will be selected. This indicates that the relevant data, such as the pricing and logistic data, which is used as input for this type of schedule, must be entered. The pricing data is also relevant for contracts that are not linked to a schedule. After you enter that information, you can set the purchase contract line to Active and link the line to a purchase schedule.

Purchase contract line logistic data

As mentioned previously, if an item defined in the purchase contract line will be used in a purchase schedule, the related logistic data must be filled in. The default data for this session is retrieved from the item- purchase business partner data, but can be changed in the logistic data itself. If no item–purchase business partner data is defined, you cannot save the contract line.

The logistic data contains the following data:

Whether the buy-from business partner is the preferred supplier or the single-source supplier. This information is required for Enterprise Planning to determine whether multiple or only one purchase schedules can be generated for that item. The priority and the sourcing percentage specify that, if demand can be spread for multiple buy-from business partners, how that demand must be spread, for example, 30 percent to supplier A and 70 percent to supplier B.


The frozen period, which indicates if changes are permitted in the short-term demand of the purchase schedule.

Capacity-related information, for example, the supplier capacity.

Lead-time information, which is used as input for Warehousing, such as:

Carrier

Internal procurement time

Safety time and supply time

Lead-time horizon

Minimum and maximum tolerances for delivery and quantity

Schedule information: Indicates what information must be exchanged, which can be:

Only the material release: You can select this option if the item is marked as a Push in the general item data, because pull items, by definition, require the material release information.

Only the shipping schedule information.

Both material release and shipping schedule information

Only the sequence shipping schedule information.

How the information exchange is carried out: EDI or other methods: If you choose EDI, the user can choose to send the related EDI message directly, without manual interaction in the process of managing the schedules.

How the exchange of information is performed, EDI or another method: If you choose EDI, the user can choose to send the related EDI message directly, without manual interaction in the process of managing the schedules.

The segment sets and the issue patterns, which are required for that schedule.

The authorization information, such as FAB and RAW period, which indicates if the supplier can start to produce end-products or purchase raw material for a particular period, which is covered under the financial responsibility of the customer.

Delivery data: How is the delivery calculation carried out and what package definitions are used for this item?

You can only make the contract line active after you activate the purchase contract line logistic data. To change the data again, you can deactivate.


Purchase contract price revisions

During the contract’s lifetime, the agreements about the price can change, for example, due to inflation. For this reason, while other data remains exactly the same, only the price information must be updated. To update this information, you must enter all the price information.

Without at least one line, you cannot make the purchase contract active. The price is set for a particular period, which is set by the effective date. If you must the change the price, enter a new effective date, and the new price becomes valid from that moment onward.

In addition, you can also store discount information using a line discount session, in which the user can enter gross or net discount amounts.

You can process the purchase contract in several ways:

Check history information.

View turnover of the contract.

Terminate or delete purchase contract.

Evaluate the purchase contract by checking if the deliveries are on track, and compare an actual situation with the contract’s end date.

Copy lines of the purchase contract to a Request for Quotation (RFQ).

Check purchase contract overview information.

Sales contracts

Sales contracts are a type of mirror of the purchase contracts, although the functionality is a somewhat more straightforward and slightly less enhanced. No options are available to define price revisions, no separate logistic data is available and the way in which sales delivery contracts are set up--always using a sales schedule, and not directly generating a sales order--is rather confusing.

You can also define the sales contract as a normal contract or as a specific contract, as is applicable to the purchase contracts.

The effective date of the contract is, by default, set to the first day of the coming month. If, for example, the current date is March 3rd, the effective date of the contract will, by default, be set to April 1st. If the current date is March 28th, the default effective date is also set to April 1st, which is also applicable for the purchase contracts.


The sales contract also consists of a header and the header’s lines. The header mainly contains the business partner-related data, while the lines contain the item-specific-related data.

In the header, you can store all the relevant information in regard to business partners:

Sold-to business partner, ship-to business partner, invoice-to business partner, and pay-by business partner, including the related address data

Sales representative employees.

Terms of delivery

Carrier

Currency and tax information

Terms of payment, payment method, and late payment surcharge

The sales contract also stores the relevant item information. This information can be based on your own item codes, but also on external used item codes, using item code systems, can be stored in the contract lines, to enable easy communication between customer and supplier.

The applicable effectivity unit can also be filled in for the sales contract lines, together with the engineering revision information. Each contract line must be valid, as indicated with dates, between the boundaries set on the sales contract header.

In the contract line, the agreed quantity, together with other relevant quantity information, can be filled in, such as price, sales price unit, related price book, discount percentages, or discount amounts, discount schedule, quantity-related information, such as the minimum order quantity.

An option is also available that indicates if quantity binding is applicable. This option enables you to compare and check, during the evaluation of the sales contract, if the called quantities covered by that contract are within the limits set as maximum and minimum contract quantity. Other relevant data that is present on the contract line is the tax code, tax-exempt reason, and the tax exemption certificate.

In addition, you can use the sales contract as a delivery contract or as a means to support the sales schedule functionality. If the user wants to generate sales orders out of this type of delivery contract, the user must enter the applicable delivery dates in a sales schedule of type Shipping Schedule.

This type of delivery schedule must be generated out of the contract lines. If the sales schedule is defined manually, this sales schedule cannot serve as


a delivery contract, but then the sales schedule behaves as a normal sales schedule.

You can only generate this type of delivery schedule after you activate the line. You can activate the sales contract lines if at least the price is filled in. You can also terminate the sales contract lines.

Sales schedule contracts

No separate mark indicates that the item, as defined in the sales contract line, is dedicated for use in sales schedules, as present on the purchase side. As a result, the sales contract is valid for normal sales orders and for sales schedules, and all relevant logistic data must be filled in on the sales contract lines.

Sales contract processing

You can process the sales contract in several ways:

Check contract history information.

Check contract turnover history.

Evaluate the sales contract by checking whether the deliveries are on track, and compare the actual situation with the end date of the contract.

Terminate or delete the sales contract.

Purchase and Sales Schedule Management

Introduction

In some industries in which the goods flow between two business partners is intensive, demand tuning is essential, and a timely execution of the delivery is crucial. The exchange of information is carried out on a regular base and, in most cases, supported by means of the Electronic Data Interchange (EDI) medium. Standards in this industry can be used to enable both parties to determine how to interpret the content of this type of electronic message.

In the Infor FMS software, a standard messaging system is used, which is called the ERP Baan Electronic Message Interchange Standard (BEMIS), which enables communication with other standards.

In this document, the focus will be on the way in which communication is carried out. This document also describes the main characteristics.


The concept can be split into two main parts: 1) the focus is on the demanding organization that requires the items, which means a definition of the purchase schedules, and communicate that demand by means of the purchase release to the 2) sales organization, which receives that demand as a sales release and will execute delivery according to the related received sales schedule. The purchase release, which contains the schedule information of the demanding organization, is, therefore, transformed into a sales release, which also contains the related sales schedule information that is required at the delivering organization.

Purchase schedule management

The purchase schedule can be defined for these items, which require a timely delivery with high quantities. Therefore, the first step is to define in the general item data that this type of item will be used in the purchase schedules.

In addition, you must decide how this item will be triggered: using a push mechanism or using a pull mechanism.

Push and pull demand

The following two options are available:

Push demand The demand is push-driven, as defined in the purchase schedule, and is grouped from a central location, such as Enterprise planning, which has a top-down approach, which means that the delivery of the product will be performed to a central warehouse and, from there, these items will be transferred to the shop floor/assembly line. Working with push means that the delivered quantity is, in fact, more than the actual required quantity to prevent out-of-stock situations or that always the economical order quantity is delivered.

Pull demand If the demand is pull-driven, the opposite is the case: the actual demand is not determined from the top, but comes from the bottom. What is required in the warehouse, Kanban or TPOP, or at the shop floor on the assembly line, becomes the actual demand. Working with pull means that the actual demand is exactly equal to the to-be-delivered quantity. The planning organization determines which concept must be applied.


Purchase schedule header

The purchase schedule consists of a header with the related line. The purchase schedule header, with the header’s number, will be communicated between the two parties and that number will usually exist for a long period, for example, four years. Each purchase schedule is made specific for one item, which must be purchased and delivered in a regular interval. For example: every car needs seats. These seats must be delivered exactly on time somewhere in the production process of the car. The demand for such for such a chair is entered in the Purchase Schedule lines, while the Purchase Schedule Header contains the chair itself.

The Purchase Schedule Header can only be used after having defined a Purchase Contract for this item and having defined the Item – Buy-from Business Partner data. The data defined in these two other sessions is used as input for the Purchase Schedule.

The following information is stored in the Purchase Schedule Header:

Generation date

Purchase contract number + Contract office

Buy-from Business Partner + Address + Contact

Ship-from Business Partner + Address + Contact

Item for which Schedule is applicable

Purchase office and planner and buyer

Segment sets + Issue patters for Material Release and for Shipping Schedule

Invoice-from Business Partner + Pay-by Business Partner, together with tax information and self-billed invoice option and payment method

Purchase order type

Currency information: currency, exchange rate type, rate determiner, rate factor

How shipment is performed: shipment based or delivery based

Which warehouse receipt must be carried out + the Ship to Address

Flag to indicate if Consignment is applicable

The status of the schedule header can be active, Termination in Process, Terminated, Schedule Positions Full and Processed.


Purchase schedule lines

In the Purchase schedule line, for the item, as defined in the header, the required demand is entered or filled in by other methods, such as KANBAN, TPOP, or EP, for a particular date. The entered lines will be processed and result in related warehouse orders, to receive these purchased goods. For the push items, only one warehouse order is created, a blanket warehouse order, while for the pull items, each requirement results into a new warehouse order.

The following information is stored in the purchase schedule line:

Item, which is by definition the same as the item on the header.

Related project.

The scheduled quantity.

The planned delivery date + the planned shipment date.

The requirement type, which is determined and based on the segment and the issue date of the purchase schedule header. If the demand, as defined by the planned delivery date, lies already in the past, compared with the issue date of the header, because before the issue date, the supplier will not receive this purchase schedule, then the requirement type is set to Immediate. If the demand is for the short-term period, for example, the coming two weeks, the requirement type is set to Firm. Changes in this period may not always be fulfilled, because the period is on a very short term. The demand after the firm period, which can be defined by the user in the segments, will automatically become the planned period.

The reference ID, which is filled for call-off schedules and linked to the schedule as a reference.

The purchase release, which is communicated to the supplier. This release number is only filled in case the schedule is of type call-off, because then the demand is actually dedicated and known. For schedule lines that Enterprise Planning generates, you cannot fill this field because in a next run of EP, the old schedule lines are removed and new lines are inserted again. Therefore, it is not known if the related release has been sent or not. So, only for call off schedules the release number will be filled after that release has been sent.

Some flags, which indicate if transactions are logged – schedule text is present and – if line is Firm Planned. Firm planned means that Enterprise Planning cannot change the demand on that line.

The business partner data.


The warehouse and address, which is usually equal to the warehouse of the header, can be changed in case the purchase schedule is generated by EP and of type pull forecast. The planner can decide that, in that case, another warehouse is applicable. In addition, the Intrastat information can be filled in.

Pricing information is shown: the purchase price per unit, including the total schedule amount.

The quantities, which are shipped, received, approved, rejected.

The Advanced Shipment Notification (ASN) number, which triggered the receipt, including the receipt number + receipt date.

Some invoicing data, the purchase type, tax data and invoice related data, including invoiced quantity, invoiced amount, and invoice date.

The lines can be processed and receive the following statuses:

Created

Approved

Disapproved

Canceled

Order generated

ASN-received

Partial Received

Final receipt

Invoiced

Processed

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 in fact a system that requires new items in case the other bin has become empty. The bin usually contains a fixed quantity.

Therefore, in the Item – Warehouse data (whwmd2510m000) session, the supply system must be specified, together with the supply quantity.

In the Generate Orders (KANBAN) (whwmd2200m000) session, you can fill in the item and the warehouse where the actual demand comes from and where these items are required. The items must be supplied from another


warehouse or from a supplier. After you run the session, a purchase schedule line with purchase schedule type Call-off is added.

As mentioned previously, the condition is that first a pull schedule of type Pull-Forecast must be generated by EP.

Warehouse orders can also be of type Time Phased Order Point (TPOP), based on the reorder point of the item in a particular warehouse. You can run the Generate Orders (TPOP) session, which also results in the generation of purchase schedules of type Call-off.

In addition to the methods of generating purchase schedules by means of the Warehouse Management module, there are the standard integrations exist between the purchase schedules and the receipt of the items by means of warehouse orders.

Push schedules

One important distinction is related to the type of the purchase schedule. If the purchase schedule is of type Push, the warehouse order related to the schedule is a so-called blanket warehouse order.

The expected receipt is equal to the total agreed quantity, as specified in the contract. As time passes, the central demand will be consumed and each time, a part of that total agreed quantity will be received with that warehouse order. This means, in other words, that each line of such a push purchase schedule will not result in a specific warehouse order–inbound line, but result in only one warehouse order and one inbound line, which is kept open, so that multiple receipts can be booked on this inbound line.

The maximum quantity of these receipts can only be booked if the quantity does not exceed the quantities as totally specified on the purchase schedule lines.

Pull schedules

In case the purchase schedule is of type pull, then each line of the purchase schedule, with type Call-off, will result in a new warehouse order with a specific receipt line related to the order. After you confirm the receipt, the status of that purchase schedule line changes to Final Receipt (or Partial Receipt).

The purchase schedules of type Pull-Forecast will never result in a warehouse order, because these purchase schedules will always be consumed by the pull-call-off schedules.

If the exchange of information between customer and supplier is carried out with EDI, very often an advanced shipment notification will also be sent.


This means that the supplier sends an electronic signal that triggers the party who will receive these items that the items are being shipped from the supplier and will arrive soon.

At the moment this shipment arrives, to speed up the inbound process, you can read the data that was sent in that ASN and to confirm that. The ASN namely contains all items that are shipped with the quantities. This also will prevent typing errors during the inbound process.

At the moment this type of ASN is received in Warehouse Management, and these items are related to a purchase schedule, the status of that line will be set to ASN-received, which is not specific for pull-schedules, but also applicable for push schedules.

In case the items are received in the purchase schedule, the details of that receipt can be checked in the Purchase Schedule – Receipts (tdpur3115m200) session. The received quantity can be seen, or even modified, with the related delivered amount. In addition, the receipt number is visible, the ASN number, the packing slip, which is a document that shows in details the contents of a particular package, the packing slip quantity, the approved quantity and rejected quantity, the transaction date and a flag, which indicates whether or not the receipt was a final receipt. In addition, a flag Confirmed is present.

Process the purchase schedule

When all lines are present and defined in the purchase schedule, the total demand can be grouped into a purchase release. This release information will be sent to the supplier, so that the supplier can deliver according this demand.

To get the purchase schedule processed, you must perform the following steps:

1 Generate release lines: The release is composed and all lines are grouped together for that ship-from business partner/buy-from business partner.

2 Approve release lines: The release that is generated receives the status Scheduled. This step is not required for the purchase schedule call-off type, because they immediately result in an approved purchase release.

3 Process purchase schedules.

4 Delete purchase schedules.

5 Terminate purchase schedules: In the meantime, you can remove processed reference IDs.


Purchase release header

The purchase release is the result of the purchase schedule lines. The purchase release can be of several types:

Material Release

Shipping Schedule

Sequence Shipping Schedule

The type that is sent is determined by the relationship that is applicable between the customer and supplier. The material release contains the long-term information, for example, for the coming six months: one year, the shipping schedule contains the short-term information (0-14 days) and the sequence-shipping schedule contains the detailed information for delivery in the right sequence (1-24 hours information).

If both parties have a good relationship, exchanging all relevant information is easy, because the supplying partner can then make better forecasts.

The decision on which information will be exchanged is set as a default value in the Item – Buy-from Business Partner and the Item – Sold-to Business Partner information, while the final value is set in the purchase contract line logistic data, which is input for the purchase schedule.

You can only exchange the material release, or only the shipping schedule, or both material release and shipping schedule or only the sequence-shipping schedule.

The following table provides an overview of the type of information that will be sent and in which purchase release. For example: if only the material release is sent (number 1), the demand as present in the immediate period is sent, plus the demand of the planned period:


Demand of immediate period.

Demand of firm period

Demand of planned period

1 Only Material Release

In Material release In Material release

In Material release

2 Only Shipping Schedule

In Shipping Schedule

In Shipping Schedule

Not sent

3 Material Release and Shipping Schedule

In Material Release & in Shipping Schedule

Via Shipping Schedule

Via Material Release

4 Sequence Shipping Schedule

In Sequence Shipping Schedule

In Sequence Shipping Schedule

Not sent

If the user prints the Purchase Release (tdpur3422m000) session and selects Final Report, the user can also select Prepare EDI Messages. If these messages were not yet generated, the messages will now be generated so that the EDI messages can be sent in the EDI module.

This depends on the setting of Release EDI Message Directly in the Purchase Contract Line Logistic Data. If this check box is selected, the EDI message will be sent during the approval process of the purchase release. As soon as the EDI message is sent, the purchase release receives the Sent status.

For the purchase schedules of type Call-off, this means that, if that flag is set, immediately after the creation of the purchase schedule, the required purchase release is generated and approved, so that the EDI message is also sent immediately.

The following statuses are applicable for the purchase release header:

The purchase release can be of several types:

Preview

Scheduled

Sent

The following information is relevant information, which you can find in the purchase release header:

Release revision: if, for example, a new revision is sent each week containing the latest information, the old revisions automatically become


invalid and a new revision number is generated. The user can also view the previous sent release revision number.

The release planner.

The release type: if the release is a Material Release, Shipping schedule, or Sequence Shipping Schedule.

Release status.

Buy-from business partner and Ship-from business partner + Ship-to Address.

The related warehouse.

The issue date: indicates at which moment the release was sent.

The Message per Vehicle check box, which indicates if the sequence shipping information must be sent for each item or grouped for each vehicle.

Communication channel: in most cases, EDI will be used to exchange the data.

Some forecast information.

The delivery method: if the delivery method is shipment-based or delivery-based.

Purchase release lines

You can never change the lines: this information is all grouped from the schedule. If a change is required, a new generation cycle must be carried out. This means that little information is stored in the lines:

The item is specified.

Some CUM information, which is input to enable the supplier to perform the right calculations:

The CUM start date

The prior required CUM

The shipped CUM

The Received CUM

Receipt information:

Last Suppliers ASN

Last received quantity, with the receipt number and the packing slip

Last receipt date

Tax information:


Tax country, tax code, tax exempt reason, and a tax certificate number

Purchase release lines details

In the release line details, only information appears:

The quantity is mentioned with the price

Start date and end date are listed

The requirement type: indicating the priority of delivery: immediate, firm or planned

A reference ID

Some dimension information: length, width, and thickness

Some schedule information, so that the both parties can refer to their own schedule number.

CUM handling and FAB/RAW authorizations

CUM handling

Related to the purchase release is the CUM handling. The purchase and sales schedules will be used in industries where high volumes are applicable. As a result, thousands of items will be delivered. The required quantities are summed up in a total, the so-called cumulative (CUM).

Using the CUM model, the supplying organization can calculate in detail the needs of the demanding organization. If the supplier has shipped already 500 items, and this fulfills a demand of 300 for a particular week, the other 200 items might already fulfill part of the demand for the coming week. These calculations can be performed by comparing the required CUM, the received CUM, and the shipped CUM.

In Infor FMS Enterprise Edition 6.1, two systems are supported: the order-based CUM model and the receipt-based CUM model. The supplier often must accept the method, which is determined by the customer who requests the items.

Working with the order-based CUM means that the unfulfilled requirements of the past are not sent again. The supplier must calculate whether or not an under-delivery is applicable. Shipped CUM and required CUM are compared.

Working with the receipt-based CUM means that the unfulfilled requirements of the past are sent. In this case, the shipped CUM of the supplier is compared with the received CUM of the customer. Under-delivery cannot take place and over-delivery is easily calculated.


After a particular period, an evaluation of the delivery process is performed and the CUM-values, which have reached high values, can be reset. If a difference between the values exists, the supplier has registered in their system, compared with the CUM values of the customer, a negotiation process can start how to deal with that difference and with which the value can be agreed to continue. An update session is also available to modify the received CUM and a session is also available to reset the CUM values.

FAB/RAW handling

If the purchase organization will purchase the items from the supplier, this often implies that the supplier will produce these items. The end product of his production process will be delivered to the supplier.

Because fluctuations in demand can occur in each industry, the supplier will be careful to produce too many items, because the demand can suddenly decline. On the other side, the supplier also must be flexible to fulfill the demand if that increases, which signifies a risk.

To reduce the risk, the purchasing organization can promise to take financial responsibility for the final products the supplier will manufacture, up to a particular quantity and up to a particular date, which is called the FAB authorization. An indicator is also present for how long that procedure is valid.

The same is applicable to the RAW authorization: that is an indicator that the purchasing organization will enable the supplier can purchase raw materials up to a particular date. This is all made visible in the FAB/RAW Authorizations (tdpur3534m000) session.

In case a decline in the demand takes place, the FAB authorization value will decrease, but the HIGH FAB will retain the old value, because that was promised. At the moment, an evaluation of the schedules is carried out, the decision can be made to reset the High FAB value and make the value equal to the FAB authorization, which in fact means that the supplier still got the full responsibility, or that the difference between the High FAB and the FAB Authorization quantity will be carried forward into the new period.


Sales schedule management

Introduction

As described previously, the purchase schedules are defined on the demanding side. By means of the EDI, the release is sent. In this document, no attention is paid to the EDI part, because that is mainly related to have defined a good set-up of the data.

The only thing that can be useful to know, that such a purchase release cannot be sent except before the release’s issue date. If the issue date is passed, the purchase release will be sent and that will result in a sales release of the supplier. Based on this information, the supplier must fulfill the demand, which means that all changes that are made after the purchase release is sent, the supplier cannot be held responsible, until the supplier is informed of this new release.

Now, the sales release is assumed to be present at the supplier and the document will describe the process how the supplier must treat and process this type of sales release and the related schedule.

Sales releases

The sales release is received and will be equal to the type the customer sent. The following types can be present: Material Release, Shipping Schedule and Sequence Shipping Schedule, representing the long-term demand, the short-term demand, and the demand each day.

Sales release header

In the release header, the following information appears. Note that this information cannot be changed, because that is what the customer demands and has asked for:

Release number.

Release Revision number.

Release type.

Sold to Business Partner - Ship to Business Partner and the address.

Reference information from the customer, as:

Customer release.

Customer revision.


Quantity Qualifier, which means that the customer has sent the actual quantities.

Shipment / Delivery method.

Generation date, Forecast Horizon start date and Forecast Horizon end date.

The information of the sales release cannot be changed and remains fixed. The sales release does not have a status.

Sales release lines

Comparable to the header, the lines also only contain display information. The following data is present:

Release and revision number.

Release position and release type

Schedule number, revision, and position.

Customer release, revision, and position.

Together with the release and the release’s lines, the sales schedule has been received. Because this information is also fixed information, the release lines cannot be processed and, therefore, no status of the release lines is present.

Sales schedule header

The sales schedule represents the following information:

Schedule number and schedule type and revision number

A flag to indicate if the sales schedule must be treated as referenced. If the schedule is referenced, this signifies that the demand of the schedule is coming from an assembly line or from a dedicated warehouse and that a reference number is present to refer to that location.

The related release

Business partner information, such as Sold-to Business Partner + address + contact and the Ship-to Business Partner + address + contact and the Invoice-to Business Partner + address

The item that must be delivered to the customer

Some reference information: what is the delivery method, the sales office, the lot selection, the old schedule number,

The name of the planner and seller


Relevant contract information

CUM related info:

Generation start date

Start date

Prior required CUM

Received CUM

Shipped CUM and the applicable CUM model (order-based or receipt-based)

Invoiced CUM

FAB and RAW data:

FAB through date

RAW through date

FAB authorization

RAW authorization

High FAB quantity

High RAW quantity

Last shipment ID

Last receipt quantity with the last receipt date and the last ASN.

Currency information such as currency, exchange rate type, rate determiner, and the rate factor

Tax information: tax country flag for self billed invoicing and if consignment is applicable.

A reason for termination can be filled in.

As you can see, the sales schedule header contains quite a lot of the same information as is present in the purchase schedule header.

The sales schedule can be processed and have the following statuses:

Created

Adjusted: during the approve process a check is made if over-delivery or under delivery is applicable. If so, this can result in an adjustment of the quantity and, therefore, the status is set to Adjusted.

Approved: the schedule is approved including the adjusted quantities

Terminated: the schedule is no longer valid

Terminated in process: the schedule header is terminated, but not all lines of the schedule are canceled or processed


Schedule positions full: the available sales schedule line numbers are full and occupied.

Processed: the sales schedule is processed

Processing in progress: the sales schedule header is processed, but not all lines are invoiced yet.

Based on these statuses, clearly the sales schedule can be treated as processed during the schedule’s life cycle and pass by various statuses.

The following processes are available:

Approve: All lines of the schedule are approved

Release to order: The related warehouse order (or sales order) is created.

Release to invoicing: Invoices are sent to Central Invoicing module

Process delivered Sales Schedules: Sales Schedule receives the status Processed

Terminate: Sales Schedule receives the status terminated

Delete Sales Schedules: Sales schedule is deleted

Delete Sales Schedules revisions: all revisions are deleted

Restore schedule: the system attempts to undo the last approval step.

Sales schedule lines

In the sales schedule lines, the quantities to be delivered are listed, based on the delivery date. The demand is made visible for each release type: the demand that belongs to the material release is shown and the demand belonging to the shipping schedule is shown. An overlap, for example, of the immediate demand, can occur.

The following information is present in the sales schedule lines:

Schedule, schedule type, schedule revision with the position

Status of the line

A flag if the demand must be put on hold.

The planned receipt date with the start date

The time unit

The end date

The quantity and unit: this should be delivered to the customer

The requirement type of the customer: immediate, firm, or planned

The own requirement type


The warehouse from which delivery must be carried out

A lot number

Some contract information

Sold-to business partner and ship-to business partner information

Customer schedule number and customer schedule position

The reference number, for example, the VIN number

The dock location: this information is required for Warehouse Management

The ship-to address

More details about the item: length, width, and thickness

The price of the item with the total schedule line amount

Tax information: country, tax code, tax exempt reason, and tax certificate

Invoicing info: Intrastat 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:

Created

Adjusted

Approved

Canceled

Canceling in process

Order generated

Partially shipped

Goods delivered

Released to invoicing

Invoiced

Processed

By means of the lines, more detailed information about the shipments can be viewed in the Schedule Shipment Details/Corrections (tdsls3140m000) session. If the quantity that was shipped must be corrected, the user can make that correction.

Schedule shipment details/corrections

If something went wrong, you can correct the quantities. The following information is available:

Schedule information

The shipment ID number, with the delivery date, delivered quantity, and the delivered amount and the costs of goods sold amount

You can make a shipment correction: the correction quantity can be filled with the correction date. A confirmation flag is present.

In addition, some invoicing information is also displayed.

By means of this session, you can make and confirm several new corrections.

Sequence shipping information

This session will contain data in case the Assembly Control module triggers the actual demand that must be delivered. The following information is visible in the Sequence Shipping Information (tdsls3517m000) session:


Schedule ID

Schedule position

Schedule revision

Item

Sold-to business partner and Ship-to business partner

Quantity with delivery date and receipt date

Sequence info:

Vehicle

Job sequence

Dock location

Assembly kit

Reference

This detailed information is required to perform the delivery on exactly the specified location in the assembly line.

Sales schedule reconciliation

Finally, some remarks about the sales schedules in general. Suppose, during the evaluation process, a discrepancy arises between the CUMs so that customer and supplier do not have the same information available. After discussion, the shipped CUM can be modified in the Sales Schedule Reconciliation (tdsls3131m000) session. The user can choose to adjust the shipped CUM, or can reconcile the received CUM or can adjust and reconcile.

CUM handling and FAB/RAW authorizations

In addition, on the sales schedule side, sessions are available that contain specific CUM-related information.

The shipped CUM info can be viewed in the Shipped CUM (tdsls3532m000) session and contains the transaction date, the shipment ID, the shipped quantity, the shipped CUM, the received CUM, and the status.

The invoiced CUM info can be viewed in the Invoiced CUM (tdsls3533m000) session and contains the invoice date, the invoice number, the invoiced quantity, the cumulative invoiced quantity, and the status.


CUMs can be reset in another session, the Reset Cumulatives (tdsls3230m000) session, so that the reset date will be filled and CUM value is set back to zero.

In the FAB/RAW Authorization (tdsls3134m000) session, the user can see the following information:

Schedule with reset date

Item and the description

Release date

Sequence number + Schedule type + Revision

The FAB authorization

The RAW authorization

The High FAB and the high RAW

The received CUM

The prior required CUM

Last shipment ID

The Last Receipt date

Based on this information, the supplier knows the number of items on which the supplier can purchase raw materials and begin production without the risk that these items will not be sold.

Purchase and Sales Statistics

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

6 Chapter 6 Electronic Commerce

Introduction

Infor FMS Enterprise Edition 6.1 supports numerous business processes. An important step within this type of process is the sending of relevant data to other stakeholders. To do this, you can send hard copies through the mail, but a preferred way to exchange data is to use the Electronic Data Interchange possibilities.

The advantages of using EDI are the following:

No misinterpretation of data is possible

Fast medium to exchange data

Can be an automated part of an FMS business process.

In the following sections, the basic function and features of the EDI module are listed, although no significant changes have been made compared to previous releases.

An important note is that within the Infor FMS system, an own defined EDI message structure is developed, called ERP Baan Electronic Message Interchange Standard (BEMIS), which means that EDI messages must be converted to other EDI formats, such as EDIFACT or ASC X12, using a so-called EDI box. The BEMIS structure has a generic setup, so that whenever possible the mapping of the data with other EDI-systems can be made.

6-2 | 5BElectronic Commerce

Master data

Before you can use EDI, a great deal of setup must be made. As a result, codes for organizations, such as BEMIS, must be entered, the messages that must be exchanged, such as MRL001 for sending data related to material releases, the messages that are relevant for each business partner (not all business partners will need EDI messages) and the moment (the Infor FMS session) the EDI message must be generated. For example, during the Approve Release Lines (tdpur322m100) session an EDI Message for the Material Release (MRL001) must be generated.

Networks

All the EDI messages must be stored somewhere, because all the information is all electronic data. The user must define in the Network session, where the data must be stored. The business partner data is linked to this type of network.

Conversion

The conversion sessions are an important of the entire EDI module. You can enter the codes, for example, for addresses, currencies, countries, and schedule types in the system. This helps to interpret the meaning of the EDI message.

The user can see, in the conversion setups for each message, which table fields will become part of this type of message, what level the table field has in that message, and the length of the message.

When all codes are defined, the setup can be made for conversion-in data, so that incoming EDI messages can be transferred in the standard Infor FMS data, and for conversion-out data, so that messages are correctly transformed from the Infor FMS system. A good example where this functionality is required is the item code. In the Infor FMS system, an item can have code ABC, whereas at the other party, the same item has code 123. To make sure that the other party will get the right information, this type of conversion must be made.

In addition, you can define specific conversions for each business partner, and you can perform import and export of messages.

5BElectronic Commerce | 6-3

Communication

A separate module is present that handles the processing of the EDI messages. Messages can be generated for a particular network or being imported from a particular network.

If message-generation fails, and required changes are made (either in FMS or in the EDI module), you can try again to generate EDI messages.

Message data

You can view the messages that were received. If the conversion failed so that the message could not be processed, the old data remains there, and you can retry to perform the conversion. The user can always see the old data.

In the outgoing file, the EDI-messages are stored, which must be processed. If processing the message was successful, the data for being processed is removed from the Messages to Be Generated session. In the history sessions, all relevant data is still available for the user.

General

In EDI, the sessions that are triggering the BEMIS EDI message are defined. As a result, the functional session, for example, the Print Release session checks if the session is defined in EDI and, if so, a trigger is set in EDI that a BEMIS EDI message must be created for the printed release.

6-4 | 5BElectronic Commerce

The following table lists the messages that can be generated from the various Infor FMS entities:

Code Name of the message Related Business Object where message is used

DIS Dispatch Advise ASN

FML Load info to Carrier Freight Management

FMS Carrier Status info Freight Management

INV Trading Invoice Invoice

MRL Material Release Purchase Schedule

OCA Order Change Acknowledgement

Purchase Order & Sales Order

ORC Order Change Purchase Order & Sales Order

ORD Orders Purchase Order & Sales Order

ORS Order Response Order Management

RAD Remittance Advise Financials

SEQ Sequential Shipping Schedule Purchase Schedule

SHP Shipping Schedule Purchase Schedule

ERN Error Notification

RDN Receipt Discrepancy Notification

Receipt

You can group data from multiple Business Objects into one EDI message. The order information, for example, also contains address information, which is another Business Object.

To be able to compare data present in an EDI message, a print session called the Print Compare Conversion Setups (ecedi5400m000) session is available, which provides an overview of which data is present in the incoming messages and which data is present in the outgoing messages.

7 Chapter 7 Central Invoicing

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 Infor FMS. It is possible to centrally control the creation and sending the invoices to the business partners. Order data from the various logistic and financial modules belonging to the same business partner can be composed into a single invoice. Thus it is possible to send consolidated, few invoices to the business partner. These invoices can be printed or they can be sent to business partners via EDI.

Invoice data that can be received from logistics can be Sales orders, Warehouse orders, Rebate orders. Invoice data that can be received from Financials can be Interest invoice data, Debit/Credit note data. For the non-order related sales, manual sales orders can be raised within Sales Invoicing.

By using Billing Request Templates, the data from the various logistic and financial modules can be selected for invoicing. Billing request templates indicate on what criteria selections must be made, and whether one or several orders should be selected. The selections in the template will determine which ranges can be entered on the actual billing request. The order data from the various logistic and financial modules that is selected in the Billing request can be composed into invoices depending on the composing criteria. Once the invoices are printed (or sent via EDI), they can be posted to the Accounts Receivable open entries and to the General Ledger.

7-2 | 6BCentral Invoicing

Composing of the invoice data is done using some fixed composing criteria like Invoice-to Business Partner, Invoice-to address, Currency, Terms of payment. User-definable composing options will determine whether invoice data can be combined into one invoice. These user-definable composing options (such as tax code, shipment, department, sold-to business partner, sold-to address) can be defined by each Invoice-to Business partner. Using the user-definable composing options it is possible to collect invoice data from several business partners in the hierarchy to one invoice that can be sent to say the parent business partner.

While invoicing the sales order invoice data, the sales order has to be settled with the invoiced advance and normal installments. Also the not yet invoiced guarantee installments will be settled with the sales order invoice data.

The invoices can be printed or be sent to the business partner through EDI. Invoices can be automatically sorted automatically based on the delivery method and the postal code applicable. The invoices get printed in the language of the business partner and the language of the tax country. For the currencies selected, it is possible to do a grand total rounding on the invoice level for the required currencies.

A payment slip can be sent to the customer along with the invoice. Customer uses the payment slip to make a payment.

The invoice will be posted to accounts receivable, Cost of goods sold and Revenue will be posted to general ledger (through integrations).

Invoice interval given by business partner gives flexibility to define different interval between invoices for each business partner. For the Counter sales, it is possible to automatically process invoice without user interaction in between.

Sales Invoicing has integration with a tax provider. When the tax provider is on, the integrated tax provider software will be used to calculate taxes on the invoice.

Disposing of the fixed assets is possible through manual sales orders in Sales Invoicing. An invoice can be created for the disposed asset and can be sent to the business partner.

The Sales Invoice module supports triangular Invoicing and bilateral invoicing. In these processes, the external and internal sales invoice generation is handled by Sales Invoicing. The automatic creation of purchase invoice is handled in Accounts Payable.

Warehouse can send internal invoices to other warehouses in case of warehouse transfer). Work center can send internal invoice to other work center in case of WIP transfer. Warehouse can send internal invoice to sales

6BCentral Invoicing | 7-3

office in case a warehouse not belonging to the same financial company as the warehouse executes the order. Purchase office can send internal invoice to the sales office in case of direct delivery. Shipping office can send internal invoice to the sales office in case the shipping office not belonging to the same financial company as the sales office ships the goods.

Inter-company settlement: If there is transaction between two logistic companies, then such a transaction is treated as an Inter-company transaction. Such a relation is regarded as a normal buy-sell relation. But if the two entities belong to the same financial company then open entries for Accounts Receivable and Accounts Payable will be suppressed. All purchases and sales between logistic companies will be booked to a inter company billing and clearing account respectively. A report for such inter-company settlement transactions is available.

8 Chapter 8 Warehouse Management

Introduction

This chapter describes the modules of FMS Enterprise Edition Warehouse Management in more detail. This chapter describes the functions and features of the following modules:

Warehouse Master Data

Inventory Planning

Inventory Handling

Inventory Reporting

Inventory Analysis

Lot Control

FMS Enterprise Edition 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 executed. In fact, the warehousing orders are the communication layer between FMS Enterprise Edition Warehouse Management and the other FMS Enterprise Edition applications. As a result, tight integrations exist between Warehouse Management and the other FMS Enterprise Edition applications, but at the same time the package is essentially decoupled from the rest of the FMS Enterprise Edition applications. As a result, integrations towards external applications, such as WMS or ADC vendors, are possible.

8-2 | 7BWarehouse Management

Warehouse master data

Introduction

The master data to be entered for Warehouse Management consists of the following elements:

Warehouses

In this Business Object, warehousing master data is defined. Depending on the complexity of the activities that take place in these warehouses and the level of control, you can enter zones and locations.

Zone

A zone is any part of the warehouse where goods can be stored. Locations with similar storage characteristics or locations handled by the same vehicle or employee can be grouped through the use of zones.

Location

A location is a distinct place in a warehouse where goods are stored. A warehouse can be divided into locations to manage the available space, and to locate the stored goods. Storage conditions, capacity data, and blocks can be applied to individual locations. Locations can have the following types:

Receiving

Inspection

Bulk

Pick

Staging

Reject

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:

Valuation data

Storage data

7BWarehouse Management | 8-3

Dimensions

Besides the item warehousing data, you can also enter item data by warehouse. Here, you can enter specifics for each item and warehouse, such as:

Issue data

Lead times

Replenishment data

Other than items stored in warehouses, you can also define packaging items and package definitions here. Packaging definitions are used to specify how items must be packed. For this, you can use packaging items.

Warehouse order procedure

A warehouse order can initiate and control every inventory transaction in FMS Enterprise Edition Warehouse Management. From a simple transfer to a complicated receipt, one or more warehousing orders control and account the movement of inventory. Flexibility and automatic execution of activities is possible.

Miscellaneous

In addition to warehouses, items, and warehouse order procedures, you can also enter other types of warehousing master data, such as the following:

Label layouts

Location remarks to be printed on storage and packing lists

Inventory valuation methods

Storage conditions

Inventory planning

Introduction

The Inventory Planning module is all about planned inventory transactions and automated actions to replenish inventory. Inventory can also be reserved (committed) for a specific order.


Planned inventory transaction

Planned inventory transactions by item are expected changes in the inventory levels due to planned orders for items. Planned inventory transactions can be generated by several order systems, such as:

Purchase orders

Sales orders

Warehousing orders

At a particular moment, planned inventory transactions created by other packages and modules will cause warehousing orders to be generated. After an order is finished or canceled, the planned inventory transaction is removed.

Planned inventory transactions are used to do the following:

Calculate the economic stock

Statistical inventory control (SIC)

Time-phased order point (TPOP)

Replenishment

Replenishment can take place in a warehouse network in between warehouses and can take place in a warehouse itself between locations.

You can define replenishment between locations in a matrix that contains the supplying zone or supplying location and the destination zone or destination location for each item and the quantities to be replenished.

Several planning options are available in FMS Enterprise Edition to replenish warehouses. An inventory planning option that applies demand control is Time-Phased Order Point, which is mainly intended to replenish a warehouse by a supplying warehouse.

Besides demand control, FMS Enterprise Edition also offers two options for Inventory Control. One option is Statistical Inventory Control (SIC). SIC runs by item or by warehouse and creates advice that must be approved by a planner.

The other option is KANBAN, which uses a predefined setup for each item by warehouse, known by an identifier (ID) to replenish inventory.

In addition, some sessions are present to define (collectively) planning parameters for each item or for each item by warehouse, such as Economic Order Quantity or Safety Stock.


Inventory commitment

Several possibilities are available to reserve inventory. You can reserve only inventory without any allocation by an order, which is useful if the user can anticipate by having particular information in advance. Another possibility is manual commitment for each order.

The user can switch on automatic commitment functionality for sales orders and work orders of the Depot Repair module.

Inventory Handling

Introduction

In the Inventory Handling module, the actual inventory movements are executed with the use of warehousing orders. Warehouse activities, such as receiving, put away, picking, and shipping are handled in this module and controlled by means of the warehousing orders or handling units. In addition, activities such as cross-docking, assembly, packaging, cycle counting, inventory adjustments, and blocking are available in this module.

The Inventory Handling functionality can also be used in warehouse environments with a high volume, as well as environment with low volume throughput of goods.

Warehouse Management orders

A warehousing order is an order for handling goods in the warehouse. The warehousing orders are the communication layer between FMS Enterprise Edition Warehouse Management and other applications. These warehousing orders are required for a tight integration and a decoupled package at the same time.

Warehousing orders can be of type:

Receipt: Movement of goods from an entity other than warehouse to warehouse.

Issue: Movement of goods from warehouse to other entity than warehouse, such as a work center or a business partner.

Transfer: Movement of goods from one warehouse/location to another.


WIP transfer: Movement of goods from one costing work center to another.

Item transfer: A change of the item code, and perhaps of location as well, in fact an adjustment.

Warehousing orders can be entered manually, generated by other FMS Enterprise Edition packages, received from EDI or even from external applications.

The to-be-executed warehousing activities can be either communicated by the application that initiates the warehousing order, or entered manually for manual warehousing orders, or determined by means of the default order types by order origin. After the warehousing order is created, the user can deviate from these initial planned activities to align the process with the physical process of handling goods.

Depending on the Inventory Handling parameter, the warehousing orders are also kept as historic data.

Cross-docking

FMS Enterprise Edition 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 FMS Enterprise Edition, which corresponds with the physical flow of the goods, because these move directly from the receiving dock to the shipping dock. This prevents superfluous inbound and outbound handling.

Direct Material Supply

The DMS (Direct Material Supply) concept implies that goods received from suppliers or produced in manufacturing shops move directly to their point of consumption without storing it in a ‘storage’ warehouse. The DMS concept uses the Cross-docking concept to avoid storage of goods in the warehouse and the Warehouse Transfer Order concept to move the goods directly to the point of consumption, which is most likely another warehouse. By taking into account where the parts are required before storing the goods, it is possible to reduce stock sitting in a warehouse.

The end result will be a much more transparent logistical process, which will be more responsive to last minute changes in demand priorities while assigning inbound goods to outbound requirements.


Inbound

The Inventory Handling module includes inbound and outbound management. Inbound management takes care to get received goods stored in a warehouse.

During the process of storing the goods, several activities can be required. These activities can be set up and executed flexible. Even during the inbound process several activities can be switched off or on, or can be changed from execution mode. The following activities are supported by FMS Enterprise Edition and can be activated flexible:

Print goods received note

Receipts

Generate inbound advice

Put away inbound advice

Generate storage list

Storage list

Approvals

Generate inbound advice

Put away inbound advice

Generate storage list

Storage list

In addition to these activities, several supportive functions are available, such as reports and overview sessions.

In addition, Advance Shipment Notifications (ASNs) are supported. ASNs can be received and sent by means of EDI or manually. Validation of ASN data is available.

A receipt can be registered based on several filter criteria, such as:

Advance Shipment Notification

Expected shipment

Expected order

Load

Item

Business partner

Handling unit


References

In addition to these filter criteria, high-volume receipts are also possible.

To accept the receipt, several predefined tolerances in regard to receipt date and quantity are checked. This data can be used as input for vendor management of purchase control.

After you receive the goods, a quality inspection of the goods might be required. For straightforward inspections, inspections of FMS Enterprise Edition Warehouse Management can be used.

A goods receipt can also be linked to a purchase schedule. After you receive goods from a purchase schedule, an update message is sent to Purchase. Purchase Control can then conclude what goods receipts are linked to a purchase schedule. These receipts require a CUMS update. Checks on CUMS are performed manually, according to an interval. Warehousing does not check or validate CUMS itself.

After you receive and inspect the goods, you must store these goods in the warehouse. If the warehouse has locations, you must also assign a location. You can assign these locations during the inbound advice generation. Inbound advice generation is based on criteria, such as:

The location must not be blocked

The location must be an inbound location

The location must not contain other items (if wanted)

The location must not contain other lots of the same item (if wanted)

The location must have enough remaining capacity

Storage conditions must match.

If required, you can manually change inbound advices, if required. Therefore, the advice can be released and printed on storage lists.

Outbound

Outbound management handles activities to get stored goods out of the warehouse.

During the process of picking the goods, several activities can be required. These activities can be set up and executed flexible. Even during the outbound process, you can switch several activities off or on, or change activities from execution mode. FMS Enterprise Edition supports the following activities, which can be activated flexible:

Generate outbound advice


Release outbound advice

Generate pick list

Pick list

Approvals

Freeze/confirm shipments/loads

Print bill of lading

Print packing slip

Print packing list

In addition to these activities, numerous supportive functions are available, such as reports and overview sessions.

Based on demand, and if a warehouse has locations, goods must be picked from the warehouse locations. An outbound advice must be generated to determine the location to pick from. An outbound advice is a list generated by FMS Enterprise Edition that advises the user about the location and lot from which goods must be issued, taking into consideration factors such as block locations, outbound method, and package definition.

The following two types of picking can be distinguished:

Order picking: The picking is carried out by order and picking lists are printed by order.

Wave picking: A picking wave is a group of original orders that must be picked for one destination. Usually, a picking wave consists of multiple picking missions.

The picking mission covers the picking actions that are grouped logically. For example the actions are grouped by zone, order priority, production line sequence, and so on. Next, designated employees, forklifts, and so on can execute the actions in sequence. Picking lists are generated for each picking wave.

Picked goods are moved to staging locations. Staging locations represent the dock where loading of transport means takes place. Dock assignment is also supported. Staged inventory is still visible in the system.

After the goods are picked, a shipment is prepared, unless FMS Enterprise Edition Freight Management is used to generate the shipments. Shipments can be for one order (single shipment concept) or for multiple orders.

After the goods are made ‘transport ready’, the shipment can be frozen. Required documents, such as bill of lading, packing lists, and packing slips can now be printed.


After the shipment is final, you can confirm the shipments, based on shipment or load number. In addition, the shipping documents can now be printed or reprinted.

Based on Advanced Shipping Information (ASN and so on), an ASN data file can be defined. This file includes information about: item, customer, dates and times, truck, delivery address, and quantity.

Value added services

Value added services such as assembly and packaging is supported by means of warehousing assembly orders. These orders are used to collect goods to assemble the orders into one item. Warehousing assembly orders are created manually.

Warehousing assembly orders transform goods in the warehouse and can be performed at any location in the warehouse as long as the order is marked as assembly permitted.

A warehousing assembly order, orders you to pick and combine a number of items to produce an end item that remains in the warehouse. The bill of material for this operation is derived from the kit definition in the list components session.

When a warehousing assembly order is created, FMS Enterprise Edition generates:

Outbound-order lines for each component of the kit to be transferred to the assembly warehouse or location.

An inbound-order line to store the item to be assembled.

Performing a receipt on this warehouse order line registers that the operation has been completed and the item to be assembled can be put away as if the item were a received item.

Every manual modification of the warehousing assembly order or order line is registered in the warehousing assembly order history.

Handling units

A handling unit is a uniquely identifiable physical unit that consists of packaging and contents. A handling unit can contain items and other handling units.


Structure

A handling unit has a structure of packing materials and items. A handling-unit structure can vary from a simple box that contains a particular number of items, to a more complex structure such as a pallet with a number of boxes, which in turn contain smaller boxes that contain a number of items. A handling unit structure can consist of various handling units related in a parent-child fashion.

You can manually create a handling unit structure for a given number of items, or you can define a package definition in which you set up a template that determines the handling unit structure for particular types of items.

The use of handling units

A handling unit is a single entity that is used to process goods in the warehouse. Therefore, you can use a handling unit to receive, store, and issue goods.

To use a handling unit for warehouse processing, you must link the handling unit to a warehousing order line. By linking handling units to warehousing order lines, the warehousing-order lines will represent both administrative information, as well as physical information about the contents.

You can link a handling unit to an order line in various ways, for example, by generating handling units for an inbound order line, or, indirectly, by generating handling units for a receipt. A receipt is always linked to inbound order lines.

Because users must be able to control item movements with as few keystrokes as possible, automatic identification of handling units is possible. Therefore, you can attach a label to a handling unit. Defining handling unit structures and scanning labels enables you to have a highly automated execution of warehousing activities at receiving and shipping.

You can use both handling unit-based warehouse processing and item and order line-based warehouse processing.

Cycle counting

Cycle counts are intended to check the registered inventory against the actual inventory at a particular moment in time. Cycle-count orders are used to manually count the inventory by stock point and, subsequently, enter the counted quantities into the system. Cycle count orders are based on ABC parameters and counting frequencies.


Before cycle counts can be carried out, preconditions must be set. Some of these preconditions are:

Whether stock points must be blocked during cycle counts.

The cycle count intervals for the various classes.

The maximum allowed shortage or surplus of the counted inventory, measured against the item's system inventory, and expressed as a percentage of the system inventory.

The amount that indicates how much the total cost-price value of the counted inventory can deviate from the cost-price value of the system inventory.

To overrule the cycle count intervals you can force cycle counts for:

A new stock point

A stock point if its system inventory becomes zero

A specific stock point

A range of stock points during the generation of the cycle count orders

Employees can enter for each stock point the counted quantity on the printed cycle count list. Handling units can be marked as present.

If a variance occurs that falls outside the margins, a recount can be forced. If this type of variance does not occur, the cycle count order line can be approved and processed, which means an update of the quantities and related to this, an update of the financial value of inventory.

Inventory adjustments

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

Blocking

For whatever reason, you might be required to block part of a warehouse or particular items from moving around in a warehouse. Therefore, you can block inbound movement, outbound movement, transfer (receipt, issue), or assembly of items at various inventory levels:

Zone

Location

Lot


Stock point

Serialized item

Handling unit

At most of these levels, blocking can be more 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 an optimal view on this data.

Inventory position

The current inventory position is recorded at various inventory levels and for multiple entities. Data as inventory on hand, inventory on order, allocated inventory, and inventory on hold is stored.

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

Rejected inventory

Consignment inventory

Negative inventory

Committed inventory


Inventory transactions

All transactions that influence inventory positions or movements in a warehouse are recorded by FMS Enterprise Edition and logged in this module. This information is used for track and trace purposes. These transactions can be archived in time.

Inventory Analysis

This module provides functionality to analyze inventory from two perspectives, logistically and financially.

Logistically, an ABC and slow-moving analysis can be executed, which lists and, when selected, updates changes.

For the financial perspective, views illustrate the change of the inventory value due to normal transactions caused by orders, transactions caused by variances, or transactions caused by revaluation activities.

Two options are available to update the Inventory Value, even if inventory is present. One option is to update the Moving Average Unit Cost (MAUC) for MAUC items. The other option is to change the valuation method.

Lot Control and Serials

Introduction

This module consists of making inventory known by attaching labels. One type of label is Lot. Lots are intended to identify and classify items based on an identical production run or repair run. In FMS Enterprise Edition Warehouse Management, lots are also used by item revisions and unit effectivity.

Lot control

Lot numbers can be automatically generated based on a mask, which can differ for lots created by production, purchase, or Warehouse Management itself. Some information can be added, such as a business partner, to ease the identification of a lot.


Tracking and tracing display and report facilities are present to view transaction of lot-controlled items.

To know inventory per item by revision, this information is stored at item by lots. The same is applicable to unit effectivity. Therefore, lot is mandatory to support these two concepts with handling of goods.

The most detailed method is to track the lot in inventory, which means that you can perform a check for each lot if the lot is in stock. A method with less handling is that just lot numbers are registered for printing and tracking purposes, but no actual stock position is available.

Serials

A serial, or serialized item, is an item that is uniquely identifiable by the item’s serial number. This type of item can also be part of a lot. For each item, you can set the level of control. The most detailed method is to track the serial in inventory, which means that you can perform a check for each serial if the serial is in stock. 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 two 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.

Consignment (not owned)

This is a warehouse that is used for storing not-owned consignment inventory. Not-owned consignment inventory are goods owned by a supplier but managed by the own company and also stored in the warehouse of the own company without being paid for until after the goods are used or sold. These goods are registered as consignment inventory.


Consignment (owned)

A warehouse that is used for storing owned consignment inventory. Owned consignment inventory are goods owned by the own company and stored in a customers warehouse without receiving payment until after the goods are used or sold. The customer manages inventory. You do not register the goods as consignment inventory because the goods are still part of your inventory.

Consignment replenishment and payment

If you use consignment inventory, the sales or purchase order procedure is split into two parts:

Consignment replenishment

Consignment payment

Consignment replenishment

If you or your customer runs out of consignment stock, and replenishment is required, a sales or purchase order of type ‘consignment replenishment’ is required. With this order, the goods are delivered, but payment is postponed until the goods are actually used.

Consignment payment

If (part of the) consignment stock is used, at that moment the goods must be paid for. For owned consignment inventory, a sales order of a type ‘consignment invoicing’ must be used. For not owned consignment inventory, a purchase order of a type ‘consignment payment’ must be used. This triggers no goods movement, but only a payment flow.

9 Chapter 9 Cost Price Calculation

Introduction

Item related cost prices are set up in the Cost Price Calculation (CPR) module.

Cost price calculation

Cost Accounting calculates cost prices for standard and customized items based on data related to those items, such as: bills of material, (simulated) purchase prices, routings, and surcharges.

For standard items, suggested sales prices can be calculated based on the cost-plus method. If the item’s inventory is valued by Fixed Transfer Price (FTP), the CPR module will calculate the valuation price.

The application of surcharges is flexible regarding the realization moment and warehouse. Surcharges can be defined by item, item group, warehouse, a combination of item and warehouse, or by a combination of item group and warehouse. Surcharges have a realization moment that defines the moment the surcharge value is added to the inventory value or transfer value. Item receipt surcharges are added at purchase receipt, direct receipt in production WIP (purchased items), or the completion of the production order (manufactured items). Item issue surcharges are added at issue to production WIP, or at sales delivery to the customer. Warehouse receipt surcharges are added when the items are entered into inventory. Warehouse issue surcharges are added when the items leave the warehouse.

9-2 | 8BCost Price Calculation

Surcharges and operation rates attribute to the fixed or variable costs. A parameter setting enables you to exclude the fixed costs from the inventory value. This is only possible for items that are valued against the fixed transfer price. Item and warehouse surcharges are also possible for customized items.

In addition, two cost prices can be distinguished: full cost price and the variable cost price. Various simulation features enable the effects of changed prices, changed production rates, or order quantities to be assessed.

Standard cost prices are used for cost reporting and analysis. Cost prices are also used to determine planning, calculation, and financial analysis of standard items and customized items. Standard cost prices can be used for inventory valuation and contribution margin on sales prices. In the Cost Accounting module, the basis for the valuation price is only calculated if the valuation method for the item is FTP. For items that are valued against First In First Out, Last In First Out, Moving Average Unit Costs, or Lot Costing, the warehouse surcharges increases the inventory value per transfer.

10Chapter 10 Multisite

Introduction

This chapter briefly describes the following main aspects of multicompany processing:

Multicompany structures.

Multicompany terms.

Enterprise structure modeling.

Enterprise units.

Multicurrency.

Intra-logistic company functions.

Data sharing

The term “multicompany” can be used to describe processes in more than one business unit within an organizational structure.

Processes

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

Business Unit

Any entity in an organization that has some degree of independence, for example, a warehouse, a distribution center, a manufacturing plant, a sales office, and an administrative group. Independence implies that some degree of management is unique to the entity.

10-2 | 9BMultisite

Multicompany in Infor FMS includes both functional and technical concepts. Examples of Infor FMS 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 both the organization’s structure and the Infor FMS 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, manufacturing and financial administration. Analyzing the organizational structure and processing requirements in conjunction with Infor FMS multicompany functional and technical capabilities provides a foundation for an implementation plan.

Multisite environments

A site is a set of company processes that is independent, to a certain degree, of the other company processes. For example, the production plants, an assembly plant, a distribution center, and the sales offices of an organization can form separate sites. A multisite environment is the integration of a number of sites in one organization structure.

A multisite environment consists of application logic and technology that refers to more than one enterprise unit, company, organization, or Infor FMS 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 FMS Enterprise Edition 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.

9BMultisite | 10-3

Some multicompany terms

This section introduces some of the terms that are used.

Multicompany (multisite)

An organization in which the Infor FMS configuration consists of more than one Infor FMS company, of the type Logistic, Financial, or Both. This implies the integration of a group of company processes into a structure, which is referred to as ‘multicompany’ in this manual.

Company

An Infor FMS company is a set of tables where logistic and/or 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 Infor FMS company used for logistic transactions, such as the purchase and sales of goods. All the logistic data concerning the transactions is stored in the company’s database.

A logistic company can consist of enterprise units that are linked to different financial companies.

Financial Company

A financial company is a company with at least one financial table. The main function of a financial company is to register all accounting transactions that result from the activities carried out in the enterprise units that are linked to

10-4 | 9BMultisite

the financial company (see the following figure). These activities consist of the operational and logistic transactions that result from a logistic goods flow and warehousing activities.

Enterprise Unit

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

Entity

An entity is a separate and independent business unit. Examples include: assembly plants, manufacturing plants, distribution centers, sales offices, and purchase offices. Entities are linked to the appropriate financial company by using Enterprise Units.

Dynamic Enterprise Modeler

Dynamic Enterprise Modeling is the process of creating a template or framework to adapt an organization's software in real time, across changing organizational structures, business practices, and operational procedures, and thereby support implementation and continuous business process re-engineering.

Enterprise Structure Diagram

An Enterprise Structure diagram (model) graphically represents the structure of a company, which assists in the determination of the overall Infor FMS

9BMultisite | 10-5

Company structures. For example, production sites in Canada and the U.S. and sales offices in both countries, as well as European countries, can be depicted (see the following figure).

Enterprise Modeling Management (EMM)

EMM contains all enterprise modeling related data for companies, enterprise units, clusters, key entities, and relationships between entities and enterprise units (see the following figure). Currency information is also an important element of EMM.

10-6 | 9BMultisite

Enterprise structure modeling

The Infor FMS software is now used in more complex company structures than in the past. For example, the possibility to do enterprise planning across different sites enables you to use Infor FMS software for the production planning in large companies. Another example is the possibility to do the financial accounting of separate parts (sites) of one logistic company in separate financial companies.

The Enterprise Modeler (EM) is a tool that you can use to model the structure of your enterprise. For example, the production sites can be in Asia and America, and the sales offices in various European countries. The various sites of your enterprise are represented by enterprise units in the enterprise structure diagram. You also indicate the relationships between the enterprise units in the enterprise structure diagram (see the following figure).

In this way, you can model your enterprise independent of the organization of the Infor FMS 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

Obviously, you cannot completely ignore the organization of the databases and their distribution over the various servers when you design a multicompany structure.

9BMultisite | 10-7

Enterprise units

An enterprise unit is a financially independent part of the organization. An enterprise unit consists of entities such as departments, work centers, and warehouses, within one logistic company. An enterprise unit can represent a manufacturing plant, an assembly plant, a sales organization, and so on.

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

Group company

L1

FB

EU A

Warehouse A

Salesoffice A

FA

EU B

Workcenter B

Warehouse B

EU C

Service center C

Warehouse C

FC

Corporate accounting

If separate sites of your organization together form one legal and fiscal unit, you can link the enterprise units of one or more logistic companies to one financial company.

You can use the enterprise units for the modeling and configuration of a multicompany structure. Therefore, you do not need to create separate companies for the various business units and various locations of your enterprise.

10-8 | 9BMultisite

Multicurrency

In Infor FMS, a logistic company can operate in multiple countries and, in this way, in multiple currency areas. The Infor FMS multicurrency systems enable a company to carry out accounting in more than one currency. Amounts can be computed and registered in up to three currencies.

Multicurrency enables organizations with operations in high inflation countries to report both in the local currency and in a stable currency.

Multicurrency also provided a solution to the European monetary integration period after 1999. During this period the participating countries could report to governments in both their local currency and in the currency of the European Monetary Union (EMU), the Euro.

Intra-logistic-company transactions

Sales offices, purchase offices, work centers, service centers, and warehouses are entities of logistic companies. The entities are grouped into enterprise units. You can define the enterprise units in one logistic company as each other’s customers and suppliers, and model the goods flow and the corresponding financial relations, such as invoicing and pricing agreements between the enterprise units. To do this, you must define internal business partners and link these business partners to the enterprise units. A one-to-one relationship must exist between internal business partners and enterprise units.

Data sharing

The companies of a 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 (and other data can be shared if required), while 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 in

9BMultisite | 10-9

regard to which tables to share and when, as well as all information in regard to relations between tables.

Multicompany processing

The multicompany structure enables enterprise-wide production planning and operations management. The following sections briefly describe the multicompany functions that the various Infor FMS packages support.

Multicompany Financials

In one logistic company, you can carry out logistic transactions between departments, work centers, and warehouses of enterprise units that are linked to various financial companies. If the debit- and the credit sides of a logistic transaction are posted to different financial companies, Infor FMS can automatically generate inter-company transactions between the companies.

You can aggregate the data of a group of financial companies to the financial group company for corporate accounting.

Multicompany Order Management

During sales order entry, you can see the available inventory in warehouses of your own and other logistic companies using the bill of enterprise.

Via triangular invoicing, the sales office and the warehouse on the sales order or the purchase office in case of direct delivery, can be located in different countries and therefore also belong to different financial companies. The financial transactions will take place via internal invoices against commercial price or valuation price.

Infor FMS registers some financial business partner data separately for each sales office and for each purchase office. In this way, the various enterprise units can do business with the same customers and suppliers.

In a multicompany structure, you can centrally manage all or part of the purchase orders. For example, you can create a central purchase contract with your suppliers, including price- and discount agreements that apply to all the sites of your organization.

10-10 | 9BMultisite

Multicompany Warehousing

You can define goods transfer relationships between warehouses of different enterprise units (linked to separate financial companies), but also between warehouses of various logistic companies, to transfer goods between warehouses and to generate invoices for the goods without using sales orders and purchase orders. For example, you can use multicompany warehousing to transfer standard goods between warehouses in different countries and implemented in different logistical companies.

You can define warehouse surcharges that are added to the valuation price of the goods, either when the goods are issued from a warehouse or when they are received.

11Chapter 11 FMS Enterprise: The technology

Introduction

This chapter describes the main functions and features of the technology on which Infor FMS Enterprise Edition 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 further detailed. In addition, some other topics will be explained in separate chapters.

11-2 | 10BFMS Enterprise: The technology

Architecture

The following figure illustrates the FMS Enterprise Technology architecture:

Server

Platform

Dependent

Dependent

Server

Platform

Independent

Server

Platform Operating System

iBaan Virtual Machine (BSHELL) Database Drivers

DBMS (Database)

iBaan ERP Applications

4GL-Engine

Java Virtual Machine

External Application

Application Management

Tools Development

Tools

Web Server

XML/HTTP

XML/DS DS

Webtop

iBaan OpenWorldX

iBaan OpenWorldX

Adapter

Worktop

ConnectivityTools

Server

Platform

Dependent

Server

Platform

Independent

Server

Platform Operating System

Virtual Machine (BSHELL) Database Drivers

DBMS (Database)

SSA ERP Applications

4GL-Engine

Java Virtual Machine

External Application

Application Management

Tools Development

Tools

Web Server

XML/HTTP

XML/DS DS

Webtop

SSA Open

Architecure

SSA Open Architecture

Adapter

Worktop

ConnectivityTools

C l i e n t

P l a t f o r m

This architecture includes several layers. The following sections describe the contents of these layers in detail.

Server platform layer

This layer represents the operating system of the computer and the installed relational database (RDBMS). These items are pre-requisites for an Infor FMS Server installation.

Server platform-dependent layer

This layer provides the runtime environment for platform-independent Infor applications. As such, these components are ported to and delivered for each specific operating system and database. For this reason, this layer is also known as the porting set.

The core of this runtime environment is the Virtual Machine, also known as the bshell.

10BFMS Enterprise: The technology | 11-3

This component implements the following main parts:

The execution environment for the application software

The interface with the user interfaces (WebTop and Worktop)

The interface with the databases

The database drivers provide database access to the relational databases, to enable all FMS Enterprise Edition database requests to be executed on the underlying relational database. For each relational database, a separate database driver is created.

To provide connectivity through Infor Open Architecture, a Java integration is created, which integrates the Java Virtual Machine with the Virtual Machine.

For more information on the Virtual Machine and the database drivers, refer to, “FMS Enterprise Edition runtime environment” in this section.

Server platform-independent layer

The Infor FMS Enterprise Edition applications in this layer are completely platform-independent.

The core of the Infor FMS Enterprise Edition applications is the 4GL engine, which handles all of the standard user interface and database behavior. The Infor FMS Enterprise Edition applications all make use of this standard behavior.

By using the development tools, developers can create new functionality or customize current functionality. For more information, refer to, “Infor FMS Enterprise Edition Development Environment” in this section.

To use the connectivity tools to create integrations with other applications and for data exchange, you can define and expose business objects. These business objects are exposed via Infor Open Architecture. For more information, refer to, “Connectivity” in this chapter.

The application administration tools are used to configure and maintain the Infor FMS system. For more information on application administration, refer to, “Infor FMS Application Management” in this chapter.


Client platform dependent layer

The user interface at the client side is implemented in the platform-dependent layer.

The primary interface for Infor FMS Enterprise Edition is Infor WebTop, which is a Web client. WebTop is installed on a Web server and enables users to start and run the Infor user interface in their Internet browser. WebTop itself interacts heavily with the 4GL Engine by means of the Virtual Machine.

As a secondary interface, Worktop is available, which is a user interface for the Windows platform only. For more information on WebTop and user interface concepts, refer to, “User Interface” in this chapter.

FMS Enterprise Edition Runtime Environment

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

Virtual Machine (bshell)

The bshell is a single threaded process that is scheduled and executed by the native host platform. The bshell, also called the Virtual Machine, is the operating system abstraction layer for the FMS Enterprise Edition application code. The main task of the bshell is to run the application code. The application code is written in 4GL, which is the Infor FMS Enterprise Edition programming language.

The bshell is activated by an external request. Most of the time this external request originates from the user interface driver when someone logs on to the Infor FMS system. For integration with third-party components the bshell is activated by an intermediate launching component. For more information on how bshells are started in these cases, refer to, “Application Services Manager (ASM)” in this chapter.

Each time a user logs on to the Infor FMS Enterprise Edition system, a separate bshell process is designated to the user. As a result, when multiple users log in on a particular platform or a user logs in multiple times, multiple bshell processes become active on the host platform.


The most important functions of the Bshell are:

Offer an execution environment to Infor FMS Enterprise Edition applications: In this execution environment, Infor FMS Enterprise Edition applications are scheduled and executed as separate processes. Such an application is either a 3GL or 4GL program. The execution of the application programs by the bshell is carried out in close corporation with the 4GL Engine.

Implementation of a large number of standard functions that the Infor FMS application software uses. Among others, these functions are typical functions that require services from the underlying operating system, for example, stream file I/O and communication services.

Pass information from/to Infor FMS Enterprise Edition applications to/from the user interface and database driver. Neither the Infor FMS Enterprise Edition applications nor the bshell contain user interface or database management system-specific functionality. This characteristic enables developers to write one set of code, which suites any customer situation with respect to user interface, operating system and database management systems.

Database driver

The database driver is the gateway for Infor FMS Enterprise Edition applications to the RDBMS of choice. The database driver provides a logical model of one single database to the applications. The database type is abstracted, easily enabling support for various RDBMS versions. The number of databases present on the physical level, the types of databases, and where these databases reside is fully transparent to the client of the database driver. This characteristic of the database driver enables you to change the physical structure of the data management layer, without any application change.

The main functions of the database driver are the following:

Shield all database specific issues from the application software by providing a uniform and generic interface, called ERP BaanSQL. The ERP BaanSQL syntax resembles the ANSI-92 SQL syntax.

Offer functionality to maintain (create/remove) tables in a (possibly distributed) database system.

Offer functionality to store and retrieve information in a (possibly distributed) database system.

Maintain the referential integrity between the data manipulated by means of the database driver.


Enforce domain constraints. The domain describes the valid values that a table field can have. The database driver is responsible for protecting against invalid table field assignments.

Application Services Manager (ASM)

In Infor FMS, you sometimes need a 3GL or 4GL session that always runs on the system. An example is the job daemon, which is a 4GL application service that must always run on the system, independent of any user. In addition, other products, such as Infor Open Architecture, require functionality to start or stop a service on the FMS back-end system.

Application Services Manager (ASM) enables system administrators to define such application services, which are also called instances, in a generic framework. The ASM daemon can start and stop these instances.

ASM is a platform-dependent component. ASM builds are available for all actual hardware platforms of Infor FMS Enterprise Edition.

With an administrative tool, called ASM MMC snap-in, the system administrator can define, stop, and start instances. This tool is a snap-in for the Microsoft Management Console (MMC) and runs on Windows.


Platform and database support for Infor FMS Enterprise Edition 6.1

The following table lists the platform and database combinations that are currently available (as of September 2006).

Supported OS

Oracle 9.2, 10

Informix 9.40, 10

DB2 8.1, 8.2

SQL Server 2000, 2005

MySQl 5.0

HP PA_RISC HP-UX 11.00, 11.11 X X

HP IA64 HP-UX 11.23 X 10

IBM Power_PC AIX 5.2, 5.3 X X X

IBM iSeries i5/OS V5R3 X

SUN_SPARC\SOLARIS 8, 9, 10 X X

Novell x86 Suse 8, 9 X X X CA

Redhat x86 RedHat 4 X X X CA

Microsoft x86 Windows 2003 X X

CA = Controlled Available

Internationalization

Multibyte enabling

Introduction

An eight-bit-wide character space is not large enough to fit most Asian character sets. Asian countries, such as Japan, China, and Korea, require at least 16 bits of character space to accommodate local characters. Therefore, a 32-bit wide character space is implemented in Infor Enterprise Server to support all possible character sets.

TSS

The multibyte enabling has been implemented in Infor FMS by means of the TSS, which is a collection of character sets. TSS accommodates all multibyte character sets in a single package. TSS includes both ASCII character sets and multibyte character sets, such as Japanese, Chinese, and Hebrew. To distinguish between, for example, Japanese and Chinese, TSS consists of


planes, each of which holds a 64 KB-size character set, or 256 pages of 256 characters.

Multi-language

Multiple languages within one FMS Enterprise Edition environment

Most Infor FMS Enterprise Edition implementations use several languages simultaneously. Infor FMS Enterprise Edition supports any combination of languages within one FMS Enterprise Edition environment, as long as the languages itself are supported with FMS Enterprise Edition. The support is restricted to certain databases.

This multi-language support is implemented by following the Unicode standards. For linguistic sorting the ICU (International Components for Unicode) standards are followed as well.

Decoupled software and language packs

Infor FMS Enterprise Edition uses LTS to both reduce the language-dependency of the Infor FMS applications and to lower the costs of media creation and distribution.

Basic concept

LTS provides a mechanism to really separate translatable software components, such as labels, questions, and messages from language-independent software components, such as form and report layouts. In LTS, the forms and report exist in the development language only. For example, a sales order entry form contains only an identifier to a referring label and will be used by all system languages. The translated labels will be added only to display the form.

Storage of translatable software components

In Infor FMS Enterprise Edition 6.1, labels are stored based on their context. This reduces redundancy and prevents labels from being changed while being used in another context.

Export/Import wizard

In Infor FMS Enterprise Edition you can export the labels, questions, and messages from a development or translation system and import them into other Infor FMS Enterprise Edition environments. Export and import of labels is carried out by means of XML-formatted files. Every XML file contains a selection of translatable components based on the user’s settings.


The translated language files can be imported back into the Infor environment. The import process includes a conversion to runtime.

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 a language packs which can be distributed and installed by the FMS installer.

Multicurrency

In Infor FMS Enterprise Edition 6.1, you can work with various currencies. For more information on this, please refer to chapter 4 and 10 of this document.

User Interface

This section describes the function and features of the User Interface of Infor FMS Enterprise Edition and some other usability concepts.

Infor FMS Enterprise Edition is delivered with two User Interface products: Infor WebTop and Infor Worktop. Infor WebTop is the preferred User Interface to use. Future investments will mainly be made in the Infor WebTop User Interface.

Infor WebTop versus Infor Worktop

Infor WebTop is a web-based, multi-platform User Interface, whereas Infor Worktop is a Microsoft Windows based fat client.

Both User Interfaces provide a navigation framework: Shortcut bar and Navigation tree(s) (both Menu browser as the DEM process Browser).

The following screenshots give an impression of both User Interfaces.


Infor WebTop:

Infor Worktop:


Main differences between Infor WebTop and Infor Worktop

This paragraph lists the main differences between Infor WebTop and Infor Worktop:

Infor WebTop is web-based (no installation), and runs in a browser.

Infor WebTop supports multiple Operating Systems.

Infor WebTop requires less network bandwidth.

Infor WebTop integrates the FMS sessions in the work-area.

Infor Web Help is tightly integrated into Infor WebTop.

Infor WebTop is not suitable for developing DEM models.

Infor WebTop is not suitable for developing sessions with the Developers kit.

For some features (for example Charts), a different programming interface is used for Infor WebTop. The use of some “old” Infor Worktop-only programming interfaces has therefore been deprecated.

Infor WebTop specific User Interface features

Easy Filtering

To provide an easy way to perform filtering data in a grid, Infor WebTop has implemented the Easy Filter concept.

The grid header contains a filter row. By entering your filter argument—you can also use 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: . You can click this icon to view detailed information.

Customize Form

If the end-user has Customizable Fields authorizations (see paragraph on Customizable Fields), the end-user can click the Customize icon ( ) in an


FMS Enterprise Edition session (or choose View | Customize Form…), and the form will be displayed in customize-mode.

You can click the eye icon to hide fields, along with the corresponding label, or even hide complete groups. If you click the pencil icon, you can change the appearance of the label.

Customize Toolbar

If the 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 -, Print – and Text menu can be customized by choosing View | Customize Menu…

Auto-hide navigation area’s

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

Gantt charts support

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

Company coloring

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

Customizable look-and-feel

The end-user is able to 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.


System administration tools

Infor WebTop can be centrally managed. End-users do not have to do administration on their own. All settings are centrally stored. For example the end-user does not have to know the Enterprise Server parameters. The administrator manages that.

For the system administrators to perform their tasks, a separate user interface has been developed, called the WebTop Administration Console. In this Administration Console, the system administrator can perform WebTop-specific administration tasks.

Generic User Interface features

Navigation feature

There are several ways of finding your way to the application sessions. The end-user can use one of the navigation trees: Menu browser or Process Browser (DEM). Or the end-user can drag and drop his/her favorite sessions onto the Shortcut bar, and start them from there.

The run program feature can be used to start sessions by code. The most recently used session codes are remembered.

Multiple Window Interface

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

Grid customizations

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

Customizable Fields

With the Customizable Fields feature the end-user or administrator can make customizations to the forms, without changing the forms itself.

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 WebTop User Interface.

With the Customization Maintenance (ttadv9100m000) 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.

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 narrowed automatically as more characters are typed into the field.

Mandatory fields indication

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

Desktop integration

For Windows Operating Systems Desktop shortcuts can be made, which link to FMS Enterprise Edition sessions. Also Shortcuts can be mailed.

Microsoft Office integration

For Windows Operating Systems with Microsoft Office installed, data from Infor FMS Enterprise Edition can easily be used in for example MS Word or MS Excel.

Dashboards

Infor FMS Enterprise Edition 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 allows him to easily access the session he needs for performing his task.

A dashboard typically contains a list of objects relevant for a particular role (for instance 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 Infor FMS Enterprise Edition 6.1 the following dashboards are available:

Order Management:

Buyer Dashboard

Account Manager Dashboard

Financials:

Accounts Receivable Dashboard

Accounts Payable Dashboard

Multi Main Table Sessions

Infor FMS Enterprise Edition introduces a new type of session: the Multi Main Table session. This session type allows various other sessions to be combined into one. It is specially designed to present data with a typical parent-child structure, for instance Sales Orders and related Lines. Although this data is distributed among several main-tables in the system, it can all be presented and edited from within a single parent-child session.

A typical parent-child session has two areas: the upper part contains information and functionality about the parent. The lower part contains one or more lists that show data about the various types of children. Both parent data and child data may be edited inside the session, which makes the sessions extremely powerful for data entry. Apart from that, a parent-child session also gives the user a complete overview of all important data related to the object.

Among others, in FMS Enterprise Edition the following parent-child sessions are available

Order Management:

Sales Order – Lines

Sales Order Line – Deliveries

Financials:

Mapping Scheme

Ledger Mapping

Dimension Mapping

Financial Business Partner Group (Accounts Receivable)

Financial Business Partner Group (Accounts Payable)

Invoice-Source Relation


Infor Web Help

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

MSDN look and feel

Infor Web Help has the same easy-to-use and recognizable user interface as the Microsoft MSDN Help. The window consists of three parts:

The shortcut bar

The navigation area

The content area.

You can resize all these three parts to create the user interface you want. You can even change the look-and-feel.

Use of filters

You can install several Help contents, for example, WebTop Help, Infor FMS Enterprise Edition Help, and Infor Enterprise Server Help. You can also configure Web Help in such a way that each user can hide the Help contents they do not require.


Help texts stored in XML format

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

Full text search capabilities

Searching in Help was never this easy. Simply enter your search criteria to search a part or all of the Help. Filtering is taken into account during the search. You can also perform a Full text search, or use combined search criteria using AND an OR. The matched items are visualized by highlighting the text.

On-the-fly installation of new help content

When new Help content is delivered in a Zip file, in the Infor WebTop Administration Console, you can easily install or update the Help content. The help content file can be uploaded from the administrator’s client desktop or web server. The Web server does not have to be restarted to make the new texts available.

To print booklets

You can easily print the content of Infor Web Help. Simply place the cursor in the tree, right-click on the mouse and, on the shortcut menu that appears, click Print. Everything under the current selected topic will be printed, according to the drill-down principle.

Customizable Web Help

By means of the admin console of the Infor WebTop, the administrator can assign users as help writers by means of their user profiles. To customize the Help, these users can log on with a user profile where Help customization is enabled.

After logging in, this user will have additional options in the displayed Help, such as a Customize button on the Help page. After you click this button, you can customize the Help: change/add help texts or hide help topics.

These customizations remain also when a new standard Help content is installed.


Infor Integration Pack 2.0 for FMS Enterprise Edition – Microsoft® Office 2000/XP

The Microsoft Office integration supplies Infor users with the best of both worlds: the ease-of-use and flexibility of Microsoft Word and Excel, and Infor FMS’s 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 Infor FMS -related design template.

Microsoft Excel generates workbooks based on a predefined Infor FMS -related template. After the workbook is generated, users can use all the Excel functionality to manipulate and update the Infor FMS data.

Design templates are stored and published in Infor FMS on the application server, which enables 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:


Product Details

The Integration Pack consists of the following products:

End user installer to enable related menu bar options and an extra toolbar in Word and/or Excel.

Installer of designer tool for read-only templates. You can also, optionally, install Infor FMS upgrade facilities for Excel templates.

Additional tools provided to convert templates designed in earlier versions of the product to the latest template format of version.

Infor FMS Connectivity

Introduction

Infor FMS Connectivity is based on the Business Object concept.

A Business Object is an object understandable by the Business (i.e. Purchase Order, Organizational Unit)

It has information stored in the Business Object Attributes (i.e. Purchase Order Number, Organizational Unit Name)

It has a set of actions, Business Object Methods, which can manipulate the Business Object Attributes (i.e. Create Purchase Order, List Organizational Units)

These Business Objects are the only entities that will expose information stored in the FMS database to the outside world.

The following integration paradigms are supported:

Business Object Services The Business Object is owned and handled by Infor FMS. A set of service methods enable the external party to manipulate the contents of the Business Object.

Business Object Synchronization The Business Object sends changes as events to the external party.


The Business Object in Infor FMS has a layered architecture.

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 that 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 Infor FMS Connectivity is depicted in the following figure.

Business Object

Repository

Synchro-nization

Information

BaanERP Data

Synchro-nization Server

Store

Synchronization Object

Data Access layer

Protected Layer

Public Layer

Changes

Business Object

Data Access layer

Protected Layer

Public Layer

Repository Object

Data Access layer

Protected Layer

Public Layer

Dispatcher

http/SOAP connector

tcp-ip/SOAP

connector

invokes

invokes

invokes

uses

DMZ and internet

intranet

Public Interface

Protected Interface

pushes

Public Layer

Protected Layer

DAL Layer


Business Object Modeling

Introduction

Business Objects definitions and mappings to the FMS Enterprise Data Dictionary are modeled by using the Integration Studio, 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 needs to be programmed by filling in the template.

There are two types of Business Objects: Simple and Complex Business Objects.

A Simple Business Object uses only 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.

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

Protected Attributes and Methods

The Protected Layer of the Business Object is modeled by defining the Protected Attributes and the Protected Methods.

A Protected Attribute can be mapped to a table-field or it can be the result of a calculation based on other Protected Attributes. The logic of these calculations must be programmed inside a hook in Integration Studio.

Protected Methods are ERP Baan 3GL functions with arguments that are basic FMS data types.

In order to fulfill the interface constraints (backwards compatibility) a getters/setters concept is used instead of a regular argument list.

There are two sets of Protected Methods: standard methods and specific methods.

The Standard Methods implement a predefined way of manipulating the Protected Business Object Attributes for all Business Objects. Six standard Business Object service methods currently exist: Create, Change, Delete, Read, CreateRef, and DeleteRef.


The CreateRef and DeleteRef are methods that enable external parties to notify Infor FMS that a reference is defined to this Business Object. When an external reference is defined it is not possible to delete the Business Object.

The Specific Methods are methods which logic is specific for this Business Object. This logic needs to be programmed in the hooks of Integration Studio.

For each method the Protected Attributes must be defined that are used as arguments.

Public Attributes and Methods

The Public Layer of the Business Object is modeled by defining the Public Attributes and the Public Methods.

A Public Attribute is mapped to a Protected Attribute.

Public Methods are ERP Baan 3GL functions with 3 fixed arguments that are XML trees: the Request, Response, and Result argument.

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 9 standard Business Object Service methods: Create, Change, Delete, Show, List, CreateRef, DeleteRef, Subscribe and Unsubscribe, and 2 Business Object Event methods: PublishEvent and OnEvent.

The List, Show and Subscribe method gives the requester the possibility of defining its own selection of the attributes and filter on the objects

The Specific Methods are methods which logic is specific for this Business Object. This logic needs to be programmed in the Integration Studio hooks.

Integration Studio

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


Screenshot of Integration Studio

From the BID a client-side API can be generated in:

Java

.NET

WSDL

From the BID also PDF formatted documentation of the Public Interface can be generated.

Once the mapping to an application is done the server-side implementation can be generated from the BII and deployed for:

FMS Enterprise Edition (ERP BaanC, as described above)

But also for:

ERP LX (RPG)

WMS (Java)

Generic Java (POJO)


Infor FMS third-party integrations

Infor FMS Enterprise Edition 6.1 supports integrations with Infor CPM solutions such as Infor Business Intelligence and Infor Enterprise Analytics, both based on Cognos Cooperation technology. Infor Integration middleware is used to access the FMS Enterprise Edition 6.1 system.

Infor FMS Exchange

Introduction

In today’s businesses, customers have implemented various software packages from several vendors. The business data of these software packages is often managed locally and is not disclosed to other applications. Changes to data on one site are not reflected elsewhere, or only with inefficient data extraction tools.

Infor FMS Exchange is a piece of technology that enables customers to extract data from the Infor FMS system in a consistent, efficient, and flexible way.

You can also use Infor FMS Exchange to do the following:

Multisite Infor FMS 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 Infor FMS, you can achieve this integration without programming custom interfaces. While the transactions between both software environments are synchronized, data is available in both systems. You can perform the synchronization either one way from or to the Infor FMS environment, or both ways.

Conversions If an Infor FMS environment is upgraded to a release with a changed data model, conversion is required. With Exchange, the user can retrieve data from the old model and store the data in the new model. The user can perform this conversion in a highly configurable way.

Any one-time or repetitive export or import of data from or to an Infor FMS database.

Infor FMS Exchange positions itself uniquely in the area of offline bulk data exchange and data conversions, whereas the Business Object


Synchronization, as described in this section is more focused on online integrations and complete Business Objects rather than just data.

Architectural overview

The following illustration shows an architectural overview of Infor FMS Exchange:

TransactionLog

SSA ERP Exchange

OLTPApplication

Transport

OLTPApplication

SourceDatabase Export

Dataor

Trans-actions

TargetDatabaseImport

Configuration &Process Management

End usersEnd users

Data or transactions from the source database are exported can be manipulated and are then imported into the target database. This process is centrally managed.

Characteristics

From simple to flexible

In a simple integration business case, two sites have the same data model. As a result, the user can list the tables that must be synchronized, and generate the settings for the data exchange. With Infor FMS Exchange, a user can set up a simple integration such as this one in a few minutes.

For more complex cases, data selection and data transformation functionality is available. For fragmentation purposes, Exchange enables you to select the specific table columns that must be included, and to specify data ranges.


The user can implement data transformation by means of conversion tables or other methods, for example, to map codes from one environment to another. You can implement this functionality without programming. However, for complex validations and data transformations, Exchange offers the flexibility to embed scripts. These scripts offer complete functionality, including features such as embedded SQL.

In addition, the user can incorporate other programs or any operating system script

Not just data

Infor FMS Exchange offers not only database-level integration, but can also include existing business logic using functions from any Infor FMS application library.

The user can utilize the business logic of Infor FMS to add external data to Infor FMS Exchange in a controlled way. To add extra data, the Exchange can make use of the Data Access Layer (DAL), which handles the data constraints and business logic implemented in the Infor FMS applications. If you simply select a check box, the DAL functionality will be included when you import data. As a result, all validations and logic implemented in DALs are executed automatically, which avoids the requirement to program this functionality by hand in the exchange scripts.

Fast

Based on settings, code is generated and compiled into the runtime environment. This code is highly optimized.

In addition, you can compress the data that must be sent from one site to another to reduce network load.

The ability to exchange only the changes also improves performance. If two or more locations are synchronized, only the changes must be sent. The delta exchange is transaction-based; therefore the delta exchange processes transactions from the source database and replays the transactions at the target database as complete transactions.

Open

Infor FMS Exchange is a generic tool. You can configure Infor FMS Exchange to exchange any data from or into an Infor FMS database. The user can configure not only the data that must be included, but also in what sequence the data must be sent, and how the data must be formatted.


Exchange supports formatting such as specifying date formats. In addition, Exchange can read and write both fixed length files, and delimited files using any delimiter.

Safe

In Infor FMS Exchange, the Infor FMS database definitions are used including domain constraints and integrity checks. In addition, the user can include validations in the Data Access Layer.

Transaction-based data exchange was designed to ensure that no transactions are missing or incomplete, and that the sequence is always correct. One transaction at the source will end up in one transaction at the target database. The sequence of the database transactions and the changes in a transaction at the target is forced to be the same as the sequence from the source. The sequences must also match if you use multiple database tables.

UTC times are used to assure time zone independence. In addition, application servers from various time zones can execute transactions on the same database. Also, if you exchange these transactions, the sequence is correct because the transaction sequence is time-zone independent.

All exceptions are logged and can be handled. The user can choose to:

Restart a previous run.

Continue a run, if the run was interrupted.

Reprocess rows that were rejected.

Multisite enabled

The Exchange architecture is based on a local autonomy model. Therefore, each site owns its data and processes and, in turn, each site decides when and how often to run exchange batches.

On the other hand, you can link source and target sites. If you link sites, source and target sites are automatically synchronized. In addition, if one site is not available for some time, or if the batches at several sites do not run synchronously, Exchange ensures that no data will be missing.

Multisite Control enables users to not only use one-to-one topologies, but also one-to-many, many-to-one, or many-to-many. A target site can subscribe to data that is made available at a source site.


Manageable

Infor FMS Exchange enables the user to synchronize just once or regularly using a schedule. For example, you can synchronize every ten minutes, every hour, every day, or every week.

The processing status is logged and you can check the status at any time. The information presented includes statistics such as the number of rows processed and the number of exceptions.

When you configure the data exchange, if you incorporate specific checks, you can support process management. For example, you can carry out Exchange process steps conditionally, or you can stop an exchange process automatically under particular conditions.

Environment-friendly

Because Exchange is embedded in the Infor FMS environment, you can run Exchange in each environment where Infor FMS runs. As a result, Exchange is independent of any database or operating system.

Infor FMS Application Management

Job Management

Infor FMS Job Management provides functionality to schedule and monitor Infor sessions based on the following:

Business calendars

Periodical runs by minutes, hours, days, weeks, or months

External job schedulers

Device Management

Infor FMS Device Management provides functionality to:

Manage and monitor output devices attached to the Infor FMS infrastructure, such as network printers or file-oriented devices

Manage the Infor printer queues and device settings


User Management

Infor FMS User Management manages the Infor user’s profile for end user and developer specific configurations such as:

Device preferences

Application authorizations based on user roles and/or default user templates

Development related authorizations for e.g. specific sessions or FMS Enterprise Edition tables

Authorization Management System (AMS)

AMS provides functionality to:

Manage Infor user roles for role-based authorizations

Manage user templates for common used settings of end users and developers

Manage address book settings for the Infor FMS messaging facilities

Audit Management

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

Infor FMS Development Environment

Introduction

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


3GL and 4GL sessions

The basic building blocks for Infor applications are sessions. A session is an entity that provides the user with an interface to an object to carry out a particular task. Technically, sessions can be divided in 3GL and 4GL sessions.

4GL sessions adhere to a particular template and are easy to develop. A 4GL session offers a great deal of standard functionality with respect to the user interface and database handling. A developer who creates a 4GL session selects a particular type of 4GL session and receives a default behavior for that session. Only the exceptions to that default behavior must be programmed. 4GL sessions have a form and combines associated software components, such as database tables and reports.

3GL sessions have nothing like what 4GL sessions offer. For 3GL sessions, programmers must program everything, including the complete user interface behavior.

Creating 4GL application sessions typically involves the following:

Creation of table definitions

Creation of a database interface script, which is also called the Data Access Layer (DAL)

Creation of dynamic forms

Creation of user interface script

Creation of labels, messages, and questions

Creation of reports

Creation of online Help

Dynamic forms

Every 4GL session has a form that is developed with the Dynamic Form Editor (DFE). The DFE does not store the fixed positions of the window controls on the form, but only the dependency relation between fields. These relations can be identified with words such as:

Behind: This field comes behind another field. If the other field is not displayed, this field will not be displayed either.

Below: This field usually displays below the previous field, if the previous field is not displayed, this field will shift upwards, and other relation types.


Fields are combined into groups, which can have group boxes and can be nested. If the fields do not fit on one form, the fields will be spread over multiple forms. Fields in the lowest level group are always displayed on the same form.

This dynamic definition enables 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 Infor FMS user interface. The use of labels in combination with Error! Reference source not found. enables Infor applications to be translated easily and in a cost-effective way. Deployment of software components is easy, because these components are truly language-independent. Deployment of new languages is also easy, because the language components can be delivered and installed by the FMS installer as a LanguagePack.

Data Dictionary

In Infor FMS Tools, a central repository is present that contains all metadata and software components used by Infor FMS. This repository is called the data dictionary and is available in the same database system as the FMS data. The following software components are all stored in the data dictionary:

Table definitions

Domains

Menus

Sessions

Forms

Labels

Program scripts

Messages/Questions

Texts

Business Objects (BOR)

Icons

Versioning (VRC mechanism, see below)


Some of these software components are converted to flat ASCII files and stored on the file system for runtime performance reasons. This process is called “convert to runtime.”

Source Configuration Management

All software components, which include sessions, source files, and reports, are under source control. As a result, for every software component, revision information is stored that can later be retrieved. This revision information is accompanied by a revision text, which describes the purpose of the change. Older revisions can be retrieved for review, but later changes can also be rolled back.

All changes for a new application release or new piece of customization can be grouped in a VRC (Version Release Customization). The VRC is a code base which is either a full code base or which contains only the new/changed components compared to a previous version. As such, a VRC can be derived from an existing VRC.

In order 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, for example a package combination for the standard application and a package combination for customizations.

Product Maintenance and Control (PMC)

The Product Maintenance and Control (PMC) tool manages the implementation of service packs and individual patches, also called solutions, into a customer's Infor system.

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

A Service Pack is created by bundling PMC solutions and offering these as one deliverable.


Installation and licensing

Introduction

A new installation concept is introduced with the Infor FMS Enterprise Edition release. The installation process is split up in two parts. The first step is collecting all the software components to be installed. During this process the software components are “staged” into a so-called staging area.

Each delivery of software should be an Installable Unit (IU). The characteristics of an IU are that it can be delivered to customers as a software component with an installation program. After staging the installable units into the staging area the FMS-Installer should be used to install the software components on the system(s), see the following figure.

Infor FMS staging wizard

The Infor FMS staging wizard is an application for loading installable units into the staging area. During this staging process, the user can select the applications (installable units) from a medium that must be staged into the staging area. The staging wizard is available on the Infor Enterprise Engine and Infor FMS Enterprise Edition Application media.

After the installation wizard is started from the CD-ROM, the administrator must type a destination path of the staging area. Next, the staging wizard will show all the available installable units on the CD-ROM, and the administrator must make a selection on which installable units must be staged. If the staging area already exists, the staging wizard displays the version from the software components available in the staging area, and the version from the CD-ROM. The administrator must make the decision on whether the installable units in the staging area must be updated (or downgraded) with


the installable unit on the medium. The staging wizard will not perform any dependency checking, which means that the administrator must check which installable units and which versions must be staged into the staging area.

The installable units supported by the staging wizard are as follows:

Infor FMS porting set

Infor Enterprise Engine

Infor FMS Enterprise Edition 6.1 Application

Infor License Manager (client and server part)

Infor Application Service Manager (client and server part)

Infor OpenWorld FMS Adapter

Infor WebTop for Infor FMS

Infor FMS DEM Models

Infor FMS Demo and Base Companies

Infor FMS Enterprise Edition 6.1 Language Pack - 'language'

The software components that the Staging Wizard do not support are:

Infor Enterprise WebTop

Infor Documentation Portal

Infor WebTop content

PMC solutions and Service Packs

Infor Enterprise Engine Clients, which include:

Infor Windows

Infor Worktop

Infor Enterprise Studio (DFE)

Infor FMS Application Clients, which include:

Infor Integration Pack 2.0 for FMS Enterprise Edition 5/FMS 6 - Microsoft Office 97/2000/XP

Infor Dynamic Enterprise Modeler

Infor FMS Installer

The Infor FMS Installer is a generic installer for installing Infor FMS on the supported platforms. The Infor FMS Installer always runs on a Microsoft Windows platform, which means that installation on UNIX versions and IBM AS400 are carried out in client-server mode, while an installation on Microsoft Windows is performed locally.


To push the installable units to the remote server, the Infor FMS Installer uses a File Transfer Protocol (FTP) connection. The FMS Installer uses the Remote Executable Command (rexec) service to execute programs on the remote computer. Finally, the FMS Installer uses the Infor Windows driver to start Enterprise Engine sessions on the remote computer.

The following figure provides an architectural overview of the Infor FMS Installer:

Because the Infor FMS Installer runs only on Microsoft Windows, the staging area must also be deployed on a Microsoft Windows platform.

The administrator is responsible for installing the right installable units together, which include components and versions. Depending on which installable units the administrator selects for installation, dialog boxes must be filled in, and finally the installation on the Enterprise server is carried out.

Infor License Manager (SLM)

Infor License Manager introduction

Infor License Manager is the central license manager for all Infor products. SLM is a central application that checks whether users are licensed to start one of these products, and provides a common licensing solution for all Infor products, which ensures a consistent and reliable license validating mechanism.

An important advantage of having a single licensing mechanism is that this setup eliminates the need for multiple activation keys to start the various Infor products, minimizing administrative overhead. With the SLM, you need only a single activation key.


SLM license types

The license deals can vary, but the license types remain the same. Therefore, SLM does not license according to a license deal, but according to license types.

Infor FMS applications can be licensed in various ways, and to see how your application must be licensed, you can refer to the Software License and Support Agreement (SLSA). Depending on the pricing strategy of Infor, a restricted set of license types can be assigned to a specific application. For example, some applications can be licensed through any license type, while others can only be licensed through a server license only.

In general the license types are distinguished in node locking and user locking. With node locking the adopting application can only work on a specific node in your network. A node can be a server, but also a desktop. With user locking, the adopting application can only work with a specified range of named user or with a predefined amount of concurrent users.

Currently, Infor supports only the following four license types:

License types Description

Concurrent User license

A user lock in which the adopting application can be used by a pool of concurrent users

Named User license A user lock in which the adopting application can be used by a pool of specific named users

Server license A node lock where the adopting application can be used on a pool of specific named server or desktop computers

Concurrent user license

With a concurrent user license, the SLM Server is not interested in the specific name of a user. The SLM Server only counts the amount of concurrent users at a specific time. If the amount exceeds the amount provided with the activation key, the SLM Server rejects new license requests from the adopting application.

Named user license

An adopting application can use named user licensing. In the SLSA is stated how many named users can use that application. The SLM Server keeps track of a list of all specific users that can use that application. The server rejects a license request from an adopting application if the specific user name is not known at the SLM Server.


Server license

An adopting application can use server licensing. In the SLSA is stated how many named servers can run that application. The SLM Server keeps track of a list of servers that can be used for an application.

SLM components

SLM contains the following components:

SLM Server handles all the license requests.

SLM Client decouples the product that adopted SLM and SLM Server and transfers the license requests from the Infor product to SLM Server.

SLM MMC snap-in is the configuration tool for SLM.

SLM validation procedure

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

1 Specify at the SLM configuration all the products that have been installed and that must be licensed by means of SLM.

2 Upload this document to the Validation department of Infor.

3 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, Infor can send you almost immediately upon license request a temporary activation key that activates the applications for a limited period.

4 Infor Validation sends the validation key back to the customer, who 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 carried out following the described process.


SLM deployment

SLM is a platform-dependent component. SLM builds are available for several hardware platforms and is kept in line with the platform support for the Infor products that are depending on SLM for their licensing.

A cluster of max 4 SLM servers can be setup to serve as one logical license server providing high-availability.

A Appendix A Definitions, acronyms, and abbreviations

Term Description A/P Accounts Payable

A/R Accounts Receivable

ACP Accounts Payable, a module of Infor FMS Financials. Also used in business as a common term for monitoring and paying amounts owed to creditors.

ACR Accounts Receivable, a module of Infor FMS Financials. Also used in business as a common term for monitoring your debtors for payment.

AMS Authorization Management System

API Application Programming Interface

ASCII American Standard Code for Information Interchange

ASM Application Services Manager

ASN Advance Shipment Notification

Assignment Information related to a job allocations for an employee

Bilateral Invoicing If there is goods transfer between entities belonging to two different financial companies but belonging to the same logistic company, the companies may decide to have invoicing relation between them. An internal invoice will be sent in this case from the company that delivered the goods to the company that received the goods.

BOCO Bill of Change Order

A-2 | Definitions, acronyms, and abbreviations

Term Description BOM Bill of Material

BOR Business Object Repository

BP Business Partner

Budgeted costs of work performed (BCWP)

The sum of the budgets for completed work packages and completed portions of open work packages. Also known as earned value.

Budgeted costs of work scheduled (BCWS)

The sum of the budgets for all the work packages and planning packages scheduled to be accomplished within a given time period.

BW Fat client for FMS Enterprise Edition, integrated with Worktop

CAD Computer Aided Design

CAT Cost Accounting, a module of Infor FMS Financials

CBM Condition Based Maintenance

CCB Change Control Board

CFG Configuration or Configuration Control

CH Change Header

Change Affected Objects

The Change Affected Objects session displays all the objects that can be affected and used in Change Management.

Change Committee A committee that is formed consisting of a chairperson and a few reviewers, to take part in the review process in Change Management. This committee is known as the Change Committee. Any authorized user can create a committee.

Change Orders The change order implements the change on the change order date. The change order child inherits the parent’s change order date.

Change Proposal A description of the planned change. This includes ownership details, recommended solution, task costs, and date execution, and the components linked to the change proposal.

Change Request An entrance point to the change process. The information can be stored in each change request form to track different changes as requested by various sources.

Checked In Files present in the Vault Area are said to be in Checked In state.

Checked Out Files present in the Work Area are said to be in Checked Out state.

Definitions, acronyms, and abbreviations | A-3

Term Description CHM Change Management

CLM Call management in Service package.

CMG Cash Management, a module of Infor FMS Financials. Also used in business as a common term for monitoring your cash.

CMS Commissions module in Distribution package that is responsible for raising commissions and rebates.

CO Change Order

COM Common module in Common package.

Company A working environment in which you can carry out logistic or financial transactions. All the data concerning the transactions are stored in the company’s database. Depending on the type of data that the company controls, the company is:

A logistic company. A financial company. Both a logistic and a financial company.

In a multisite structure, the company database can partially exist uniquely for the company and partially consist of database tables that the company shares with other companies.

Consignment Consignment functionality is applicable when different parties handle inventory ownership and storage.

Control Account A control account is a general ledger account whose balance reflects the balance of Accounts Payable/ Accounts Receivable sub ledgers.

Control code This is a higher-level code above the special cost object and is used for control purposes.

Control data A translation of the actual budget into control data, which is used for cost control.

CP Change Proposal

CTM Contract management module in Service package.

CTM Contract Management

CUMS Cumulatives

DAL Data Access Layer

DC Distribution Center


Term Description DEM Dynamic Enterprise Modeling

DFE Dynamic Form Editor

Direct Delivery If the required goods are not available in the company to execute a sales order, the purchase office sends an order to the supplier to directly deliver to the customer.

DLL Dynamic Load Library

DMZ De-Militarized Zone Part of a network which is located between two firewalls.

DOC Document Management

Document Libraries Document library is a library, which is used to catalog documents.

Document Lifecycle The life cycle of a document from concept to completion. The Document Lifecycle involves many phases.

Earned value Performance measurement; the budgeted costs of work performed.

EDI Electronic data interchange module in Electronic commerce package. This module is responsible for receiving and sending the various messages through EDI.

EMM A module in Infor FMS Common that is used to model the organization and to make the enterprise modeling information available to the other Infor FMS packages. Modeling the organization consists of defining:

The entities. The relationships between the entities. The enterprise structure.

Employee Person employed by a company


Term Description Enterprise unit An enterprise unit consists of logically grouped

entities (work centers, sales offices, purchase offices, accounting departments, and warehouses) of one logistic company that report to the same financial company. From a business perspective, an enterprise unit can be considered as an independent fiscal unit in a logistic context. For example, an enterprise unit can be a manufacturing plant, an assembly plant, a sales organization, a distribution center, or a service organization.

EOQ Economic Order Quantity

Estimate to complete The value that represents a realistic appraisal of the cost of the work that is still required to complete a task.

Extensions Extensions cover the specific agreements within or in addition to the initial contract.

FAB Fabrication

Factor The factor is a bank or a commercial finance company that specializes in buying receivables.

FAM Fixed Asset Management, a module of Infor FMS Financials

FBS Financial Budget System, a module of Infor FMS Financials

File The object that points to a physical file.

Financial company A company used for posting financial data in Infor FMS Financials. You can link one or more enterprise units from multiple logistic companies to one financial company.

Folder Folder is a data item that contains a group of related objects.

FST Financial Statements, a module of Infor FMS Financials

GLD General Ledger, a module of Infor FMS Financials. All the ledger postings take place here.

Goods Synonym of Items


Term Description Group company

A financial group company is a financial company to which a number of other financial companies are linked. A financial group company is used to:

Process the corporate and administrative accounting

Accumulate the data from the group’s financial companies for consolidated financial reporting.

Perform central cash management processes such as payments and direct debit.

IBD Item Base Data

ID Identification

INH Inventory handling module in the Warehouse Management package.

INH Inventory Handling

INR Inventory Reporting

I/0 Input/Output

IPD Item Production Data

IPU Item Purchase Data

IRS Internal Revenue Service, branch of the federal US government in charge of collecting most types of taxes.

ISA Item Sales Data

ISO International Standard Organization

Labor Type Classification of labor to which surcharge is to be linked.

Logistic company

An Infor FMS company used for logistic transactions, such as the production and transportation of goods. All the logistic data concerning the transactions is stored in the company’s database. A logistic company can consist of enterprise units that are linked to different financial companies.

LSP Logistic Service Provider

LTS Language Translation System

Mask A template that specifies the structure of an identification code.

MAUC Moving Average Unit Cost

MCS System tables module in Common package.


Term Description MDM Master Data Management

MMC Microsoft Management Console

MSC Maintenance sales control module in Service package.

Multicompany (multisite)

An organization in which the Infor FMS configuration consists of more than one Infor FMS company, of the type Logistic, Financial, or Both. This implies the integration of a group of company processes into a structure, which is referred to as ‘multicompany’ in this manual.

Multicurrency systems Functionality that enables an Infor FMS company to do its accounting in more than one currency. Amounts are computed and registered in up to three currencies.

Object Browsing The object explorer enables the user to view the object’s links, in the form of a graphical horizontal tree browser.

Object Family Group of objects with an object as owner to maintain the links.

Part A material item that is used as a component, not as an (sub)assembly. Often used as a synonym for items.

PBOM Production Bill of Material

PDF Portable Document Format

PPL People (module in Common)

PTC Product Testing and Control

PUR Purchase

Query Generic mechanism for registering a set of records based on conditions provided by the user.

Query Condition Condition provided by user based on attribute values used for setting up a query.

RAW Raw material

RDBMS Relational Database Management System

Reviewers Mechanism This functionality is present in both Change Management and Document Management. It allows the user who is authorized, in this case the Chairperson to create a Committee and then define Reviewers by Document or Change Committee.

RMA Return Material Authorization


Term Description Rule Rules can be used as a one-point provision to

trigger dependent events/entities.

SBM Subcontract Management

Shipper Commercial enterprise or manufacturer for which transport is an essential part of the supply chain but not regarded as core business.

SIC Strategic Inventory Control

SLI Sales invoicing module in Central invoicing package. The module is responsible for creation and sending invoices centrally.

SLS Sales module in Distribution package.

SLSA Software Licensed Support Agreement

SQL Structured Query Language

TMG Transport Means Group

TMS Transport Management System

TPOP Time Phased Order Point

Transaction Type Differentiating hours spent by logistical package/module.

Triangular invoicing If the order is received by entity belonging to one financial company but the goods are delivered by an entity belonging to other financial company (entities belonging to the same logistic company), the companies may decide to have invoicing relation between them. In this case, an internal invoice will be sent from the company that delivered the goods to the company that received the order.

TSS Triton Super Set

UBM Use Based Maintenance

VIN Vehicle Identification Number

WCS Work Control System

WH Warehouse Management

WIP Work in Progress

WMD Warehouse Master Data

Work packages Detailed short-span jobs identified by the contractor for accomplishing work that is required to complete a contract.

Working Time A way to divide the day in parts linked to a labor


Term Description Schedule type.

XML Extensible Markup Language

Documents

Infor FMS Enterprise Edition 6 - WordPress › Installationbaansupport.com/docs/baan/Functions and features.pdf · ... Entity Relationship Model (ERD) ... General Ledger ... “Infor