Design Advanced Planning-Infor

Detailed Design Advanced Planning
Infor Supply Chain Planning
YPOD Detailed Design Advanced

Planning
Infor Supply Chain Planning for Yara
AP for blending hub & global planning
Name: Design AP YARA v1.1.doc Version: 1.1 Created: 10 April 2007 Updated: 8-Jun-2007
Change 1.0: draft version Document owner: M Ham
history: 1.1: published version
Document Approval
This document should be approved by:
Name Function Signature Date
Linda Bergoens Yara Project Manager
Jo de Vliegher Business Consultant
Jos Winters Yara Integration Specialist
Tony Player Infor Project Manager
Stephen Hainie Infor Integration Specialist
Geoff Locket Infor Solution Architect
Maurice Ham Infor Solution Architect
Table 1: Document approval
Copyright 1996-2007, Infor IP Holdings C.V. and/or its affiliates or licensors. Page 2 of 62
Executive Summary
This document contains the structure to describe the usage of AP within Yara.
In chapter 2 the link to the detailed definition document is made. The key
requirements in this document function as a starting point for the AP design
In chapter 3 the AP model itself is explained. First of all in model structure

(calculations) and also in all related area such as integration and way of
working (procedures)
Chapter 4 describes brief the roles and responsibilities in the rest of the
project. Of course, most of them are already addresses and known. A number
of them with a higher level of detail are described here.
Chapter 5 gives the starting point of the tests of this design. It also shows the
important point that changes (and errors) on this design should be
documented and approved.
Table of Contents
DOCUMENT APPROVAL...............................................................................................2
EXECUTIVE SUMMARY.................................................................................................3
TABLE OF CONTENTS..................................................................................................4
1 INTRODUCTION .................................................................................................6
2 YARA SUPPLY CHAIN CHALLENGES / KEY SUCCESS FACTORS ...............7
3 DETAILED SCOPE ........................................................................................... 13

3.1 CLASS DIAGRAM ...................................................................................... 15
3.1.1 Products ..................................................................................... 17
3.1.2 Locations .................................................................................... 19
3.1.3 Products@Locations................................................................... 23
3.1.4 Suppliers .................................................................................... 25
3.1.5 Supplier Allocations .................................................................... 26
3.1.6 Customers .................................................................................. 27
3.1.7 Customer Allocations.................................................................. 28
3.1.8 Routes ........................................................................................ 28
3.1.9 Transfers .................................................................................... 29
3.1.10 Resources .................................................................................. 30
3.1.11 Resource Allocations .................................................................. 31
3.1.12 Processes................................................................................... 31
3.1.13 Formulas.................................................................................... 33
3.1.14 Parameters................................................................................. 34
3.1.15 Specifications ............................................................................. 35
3.1.16 Recipes ...................................................................................... 35
3.1.17 Recipe Allocations ...................................................................... 36
3.2 CALENDAR BUCKETS & HORIZON .............................................................. 36
3.3 OPTIMIZATIONS ........................................................................................ 39
3.4 MODEL SIZE CALCULATION ........................................................................ 41
3.5 TECHNICAL SETUP OF THE MODELS ........................................................... 42
3.6 INTEGRATION MASTER DATA ..................................................................... 43
3.6.1 Products ..................................................................................... 46
3.6.2 Locations .................................................................................... 46
3.6.3 Products@Locations................................................................... 47
3.6.4 Suppliers .................................................................................... 47
3.6.5 Supplier Allocations .................................................................... 48
3.6.6 Customers .................................................................................. 48
3.6.7 Customer Allocations.................................................................. 48
3.6.8 Routes ........................................................................................ 48
3.6.9 Transfers .................................................................................... 49
3.6.10 Resources .................................................................................. 49
3.6.11 Processes................................................................................... 49
3.6.12 Resource Allocations .................................................................. 50
3.6.13 Formulas.................................................................................... 50
3.6.14 Parameters................................................................................. 52
3.6.15 Specifications ............................................................................. 52
3.6.16 Recipes ...................................................................................... 52

3.6.17 Recipe Allocations ...................................................................... 53
3.7 INTEGRATION TRANSACTIONAL DATA ......................................................... 53
3.7.1 Forecast ..................................................................................... 53
3.7.2 Orders ........................................................................................ 54
3.7.3 Budget ........................................................................................ 54
3.7.4 History figures............................................................................. 54
3.7.5 Stocks......................................................................................... 55
3.8 INTEGRATION REPORT DATA ..................................................................... 56
3.9 PLANNING W ORKFLOWS ........................................................................... 56
3.10 PLAN SHEETS .......................................................................................... 57
4 ROLES & RESPONSIBILITIES CLARIFICATION ............................................ 58
4.1 DATA COLLECTION ................................................................................... 58
4.2 INTEGRATION ........................................................................................... 58
4.3 OBJECTIVE FUNCTIONS FINE-TUNING ......................................................... 58
4.4 PLANNING PROCESSES ............................................................................. 59
4.5 PLAN SHEETS AND QUERIES ...................................................................... 59
4.6 REPORTS ................................................................................................ 59
4.7 SIMULATION SCENARIOS ........................................................................... 60
4.8 TRAINING, TESTING AND USER MANUALS .................................................... 60
5 PLANNED TESTING STEPS ............................................................................ 61
5.1 PILOT TESTING......................................................................................... 61
5.2 UAT TESTING .......................................................................................... 61
DOCUMENT CONTROL ............................................................................................... 62
ACRONYMS AND ABBREVIATIONS .......................................................................... 62
LIST OF TABLES AND FIGURES................................................................................ 62
1 Introduction
This document describes the design of Advanced Planning within Yara.

Advanced Planning (AP) is used on 3 major parts in the supply chain:
as optimizer in 3 blending regions: Brazil, United Kingdom and South

Africa.
as tool on the Global department for distributing the capacity in Global
factories to the markets
as tool on the France and Italy market for distributing the capacity in
their local OPP plants (similar to the global model)
Whenever in this document the global model is described, it is applicable for

both global, Italy and France
The document will describe in detail the setup of the model with all related
elements. Important in here is the integration with the (Oracle based)
integration hub, but also the plan sheets and workflows are mentioned.
Furthermore is there already as structure on the cooperation of the various

departments in the company which should lead to an S&OP structure.
The model is created in AP version 5.0.5 and has already 3 pilot models
available (from BR, SA and UK). The pilot models for global, FR and IT will be
released shortly.
2 Yara Supply Chain Challenges / Key Success Factors
This section is copied from the Detailed Project Definition. This chapter will
contain both RP and AP related topics.
Requirements Planning initially involves the process of netting requirements

against warehouse and production site stocks. Secondly, Requirements
Planning involves the review of consolidated netted requirements and making
a decision as to from which production site, warehouse or third party supplier
the netted requirements will be sourced, including information as to whether
the sourcing is global OPP/TPP, local OPP/TPP, blending OPP/TPP or joint
venture. Once a given supply quantity of product has been secured, the
regional planning teams are responsible for negotiating with the sales teams
to balance any differences between what has been requested by the sales
organization and what can be provided.
In some countries (for example the US) all warehouses are managed
individually, more commonly however (Italy & France) warehouses are
grouped together for planning with the sales forecast netted off against a total
Legal Company (in the case of Italy) or a number of grouped warehouses (in
the case of France). This netted requirement is then typically aggregated by
region and ultimately by Legal Company to provide a total view of
requirements for a specific Legal Company.
As the plan evolves the regional planning teams are responsible for providing
updated demand data and reacting to communications from the global
planning teams in situations where there are supply shortages. The regional
planning teams are also responsible for bidding on any excess volumes
(arbitration) that become available from the global production sites.
Key requirements for Requirements Planning are:

Ability to define different warehouse aggregation hierarchies by Legal
Company to manage differences in the way stock is considered within
a Legal Company. i.e. for some legal companies all the stock is
considered as if it were one big pool regardless of the actual physical
layout of the warehouses, In others each warehouse is considered to
be either on its own or part of a group. It must be possible to handle
both situations and also to move from one situation to the other as
required.
Ability to view total stocks (total of all products, regardless of individual
product) per location. i.e. it must be possible to report aggregated
stock positions across any group of products and locations.
Ability to view stock for each product and/or product group within a
warehouse on the same screen (as a list of products for that
warehouse), and to drill down product by product. In order to provide
this functionality it is proposed to enhance the standard MLE screens.
Ability to view requirements for each product and/or product group
within a production site at the same time on the same screen (as a list
of products for that warehouse), and to drill down channel by channel

until the original request.
Ability to see the impact of the Requirements Plan on the total stock
holding at a warehouse. In order to provide this functionality it is
proposed to enhance the standard MLE screens.
The application has to support a rolling time horizon, where short-term
figures are derived from more precise information (sales orders,
precise forecasts) than long-term figures (rough forecasts).
Within the rolling time horizon, the system should flexibly show
subtotals (quarter, year). In order to provide this functionality it is
proposed to provide flexible reporting options to provide quarterly
subtotaling.
Ability to define different source locations for product within a month
and potentially multiple sources for the same product within a month.
This process should take into account the fact that different sources
can have a different lead time.
Ability to drill down from Legal Company to region, to warehouse and
ultimately to Sales Persons to find the source of the requirements
Ability to see the production capacity requirements for local production
sites and manage capacity between a number of local production sites
Ability to see the total stock, production and demand for a warehouse
or production site and to manage these capacity requirements (for
stock and/or production) by manually delaying or expediting
production, changing the source of the requirements, or changing the
required and/or production quantity. Through a process of drilling
down, these changes to production and/or requirements must be able
to be performed at all levels in the hierarchy. For example, 2 countries
requiring the same product from the same source: if the source is
unable to meet the requirements, the supply planner must be able to
drill down on the requirement quantity to see the requesting locations.
The planner must also be able to change the requirement quantities of
each of the requesting locations in a process currently referred to as
allocation. Such a change should be flagged to each of the
requesting locations.
Ability to track actual and planned production against the budget as
the year progresses
Ability to manage local bagging operations via BOM conversion of
sales forecasts for bagged products into a Requirements Plan for bulk
product
Ability to handle changes of product code that can be imposed by a
change in production site. In order to provide this functionality it is
proposed to create customized system logic to facilitate the change in
product code.
Ability to visibly track the difference between the total requirements by
source and what has currently been committed to by global sourcing.
Ability for storage capacity excesses at warehouse level (i.e. stock of
all products totaled per warehouse and compared to a known
maximum storage capacity) to be flagged. In order to provide this
functionality it is proposed to enhance the standard MLE screens.
Ability to have phantom aggregated levels per Business Unit and per
Legal Company showing aggregated stock and requirements. In order
to provide this functionality it is proposed to provide flexible reporting
options to allow for the provision of aggregated requirements and

stock positions.
Ability to see historical and future months on the same screen (this is
required for the managing of arbitration volumes). The ability to see
historical values in the requirements planning screens will depend on
the module in use. Planners using RP will only be able to access
historical values through reports. Users of AP will have the ability to
see the history and future on the same screen.
Basic system rules in support of automatic allocation. i.e. The system
should do basic validation along the lines that it should not be possible
to allocate products against a production site where they are not
produced.
For blending units, the process of Requirements Planning is fundamentally

different from the other regions in that sales forecasts are mostly received at
blended product level while requirements are posted at raw material level
(definition see further). This means that the Requirements Planning uses a
Bill of Material to translate finished (blended) product requirements into raw
material (dependant) requirements.
The Bill of Material (BOM) can be seen as a formula to achieve the required
end product. There are many ways of blending raw materials into the required
blended products. These BOMs can be seen / managed in different ways:
The BOM can be fixed in that the raw materials (RM) are defined
included the relative quantities. Possibly, several alternative fixed
BOMs are known and available for selection.
The BOM can also be variable so that all possible RMs are defined,
while the exact draw quantities are calculated based on the target
chemical composition. The resulting formula is relative over time, so
that the same end product (=blend) can have several formulas over
the time horizon to achieve the best possible mix.
RMs for blending are in fact main fertilizer products produced in OPP/TPP/JV
plants. Next to blended products, hubs also sell these main products directly
(not blended) which generates in the end both independent and dependent
requirements for main products. The capacity planning of a hub consists of
three groups:
Production capacity, which covers both blending and bagging

capacities, OPP production for fertilizer (if available in the region) and
TPP blending operations.
Transport capacity:
o A minimum and/or maximum capacity: A minimum level in
general or a fixed ship size for UK
o The triangle between lead times, costs and capacities.
Storage capacity. The stocks capabilities will mostly be used to
accommodate raw material stocks. Three types of storage have to be
integrated
o Own warehouses and production stocks
o Consignment and/or TPP stocks: if the stocks are element for
planning they will be included. (The financial ownership is
important but who has control over the stocks is more
important in a planning sense)
o In transit stocks. E.g. the stocks to arrive in the near future

from the global plants in Europe. The stocks are owned by the
blending regions as soon as the ship is loaded.
Key requirements for blending planning are:
Internal (OPP) or external (TPP) blending. JV blending exists also (in

South Africa) but this will not be planned by YPOD. Raw material
requirements are received from the JV as a sales forecast of main
products. This will result in additional independent demand for raw
materials.
Import Raw Materials (OPP/TPP) or use local (TPP) sourced
materials. The imported materials have a longer lead time.
Blending/bagging capacity is limited and might be bottle neck in the
peak season. In the solution this will be solved by adding capacity,
reallocation of production and/or upfront production. In case of upfront
production, blends are usually stored in consignment stocks.
Transport is limited within the geographical area and might be
regulated/restricted with costs (e.g. taxes) between the
states/countries. As a hub, South Africa covers different African
countries, each with a different tax regime. In that sense, South
Africas tax structure can be compared to Brazils. Different regional
divisions within the UK market are subject to specific restrictions,
requiring planning to take regional divisions into account in the UK.
o Internal transports (= all transports of raw materials): part of
product cost
o Customer transport (= transport of blend to customer): each
transport has a different cost associated to it. The cost will be
attached to the customer group which will be the region / sales
supervisor
Bill-of-Materials can be variable or fixed (with a choice of versions).
Blends have a predefined quantity of N, P , K and other components
(e.g. micronutrients)
o Related to these BOM structures the product management is
important: relationship raw material to product family
aggregate product is needed to display BOMs on all levels
o At this moment Brazil has a flexible BOM. SA and UK have a
fixed BOM with versions. A mixture of flexible and fixed is not
possible
90% of UK market is in main fertilizer products, 10% is blends
UK needs ship size calculation in the optimisation model for two
reasons.
o Transports to UK are almost entirely done within shipping
contracts, which define the ship sizes upfront
o The relatively low consumption of some RMs in UK makes it
important to have a stock management which is linked to the
real ship sizes
For the UK, it is possible for the global facility to send the material
directly to the customer.
The bucket structure: a telescopic implementation is foreseen to cover
both short term precision (weekly buckets) and mid long term
precision (monthly buckets).
o Weekly buckets up to one quarter. Two methods are available:
The first quarter split in 3 months of 4-4-5 weeks

respectively. This solution requires the whole planning
calendar to be aligned with the 4-4-5 philosophy,
including the sales forecast.
First quarter split in months and a further split in
calendar weeks plus a split in the week at the monthly
shift.
o Further quarters are in monthly time buckets (or aggregations
of 4-4-5 weeks if selected above)
Safety stock calculation/management is done at raw material level
instead of finished products.
o for this projects scope: number of weeks in cover stock at raw
material level, possibly with a minimum level.
o possible later improvement (out of scope in this project): safety
stock based on forecast error
Possible existence of negative opening balance. A solution is
necessary how to handle them. Source of negative actual stock:
o technical source: the current SAP implementation allows
negative stocks. E.g. if not everybody is fully up to date with
transactions
o market source: cannibalization: product A is planned, product
B is shipped
Yara has a process flow to operate the various model-levels and
template models:
o The sales forecast is received. (In Brazil: by aggregator)
o First optimization run: all local constraints (capacities, stocks,
) are active, but sourcing is unconstrained from a certain
lead time (e.g. first 8 weeks locked, rest open)
o Planned deliveries from global are received optimization is
run again, now also sourcing is constrained
o A Feasibility check (initially for Brazil only). Only the first 4
weeks in week buckets, all constraints are active including
constraint of max 5 raw materials in blend BOM. The demand
data is not the sales forecast anymore but planned deliveries
of individual blended products.
Key requirements for Global Planning are:
Ability to drill down from global production site to Legal Company /

Sales Region to find the source of the requirements
Ability to see the production capacity requirements for global
production sites and manage capacity between all production sites in
one go
Ability to update the realized production capacities on screen
(corrections to the automatic uploads)
Ability to see the total stock production for a global production site and
to ensure that the least stock is held at any point in time by managing
distribution recommendations to the Legal Companies
the year progresses
Ability to track (i.e. on the screen) the difference between the netted
requirements by Legal Company and what the budgeted/committed
requirements are, taking into account historical months where

necessary.
Ability to change delivery quantity by Legal Company to correspond to
realistically achievable production quantities in situations where there
are capacity shortages. The reductions or increases of the
requirements should be shown as a different line to show the
difference between requested and allocated volumes.
In the event that Requirements Planning functionalities are delivered
through different modules of the Infor planning suite, ability for Global
Planners to view total requirements, regardless of the source system.
Legal Companies
Ability to create one virtual Legal Company to accommodate excess
OPP supply quantities for the arbitration process. Today, this is
managed through the Legal Company Antarctica.
Ability to see the production capacity requirements for local production
sites and manage capacity between a number of local production sites
Ability to see the total stock, production and demand for a warehouse
or production site and to manage these capacity requirements (for
stock and/or production) by manually delaying or expediting
production, changing the source of the requirements, or changing the
required and/or production quantity. Through a process of drilling
down, these changes to production and/or requirements must be able
to be performed at all levels in the hierarchy. For example, 2 countries
requiring the same product from the same source: if the source is
unable to meet the requirements, the supply planner must be able to
drill down on the requirement quantity to see the requesting locations.
The planner must also be able to change the requirement quantities of
each of the requesting locations in a process currently referred to as
allocation. Such a change should be flagged to each of the
requesting locations.
the year progresses
Ability to manage local bagging operations via BOM conversion of
sales forecasts for bagged products into a requirements plan for bulk
product
Ability to handle changes of product code that can be imposed by a
change in production site
Not previously in document. Ability to see historical and future months
on the same screen (this is required for the managing of arbitration
volumes).
Basic system rules in support of automatic allocation.
3 Detailed Scope
This chapter gives an overview of the AP model, including a class diagram,

model constraints and a basic overview of the plan sheets. The chapter on
horizon and bucket structure explains the concept of the Mid Long Term
(MLT) and Short Term model (ST).
The table below shows an overview of (AP) models and links in the various
parts of Yara. The MLT models are built in 2 phases in the time between now
and January. In the budget phase (until September 2007) the budget plan for
2008 is prepared. In the phase between September and January 2008 the
plan is extended and made ready for monthly planning cycles. After January
2008 the planning cycle is extended with a ST feasibility study with increased
complexity over a shorter horizon.
Market Focus Description

Blending Brazil MLT A monthly planning on aggregated level to determine
production and purchases based on (customer) forecast.
The aim is to determine optimal netted requirements
based on a netting process in the supply chain. The
BOMs are variable and there is G-OPP, L-OPP, G-TPP
and L-TPP. Communication with global about the needs
and availabilities of raw materials. The purchases are
against a stock policy level (incl. safety stocks at raw
material level
ST A short-term weekly feasibility study to see if the
aggregated level is doable. The aggregates are
ungrouped to blends, the forecast is replaced with
actual orders and the purchase orders (in transit stock)
are frozen. The number of ingredients in a variable BOM
is set to a maximum
South Africa MLT A monthly planning on aggregated level (product level =
aggregated level) to determine production and
purchases based on (customer) forecast. The aim is to
determine optimal netted requirement in the supply
chain. The BOMs are fixed (with alternatives) and there
is G-OPP, L-OPP, G-TPP and L-TPP. Communication
with global about the needs and availabilities of raw
materials. The purchases are against a stock policy level
(incl. safety stock at raw material level). The surplus
capacity is indicated as Capable to Promise.
United MLT A monthly planning on aggregated level (product level =
aggregated level) to determine production and
Kingdom
purchases based on (customer) forecast for both solids
and liquids. The aim is to determine optimal netted
requirement in the supply chain. The BOMs are fixed
(with alternatives), contain subsequent steps and there is
G-OPP, L-OPP, G-TPP and L-TPP. Communication with
global about the needs and availabilities of raw
materials. The purchases are against a boat size and
stock policy level (incl. safety stock at raw material level).
Production France MLT A monthly planning on product level to determine
production and purchases based on netted
hub
requirements. The aim is to use the available OPP
production process maximal. The BOMs are fixed and
contain subsequent steps. There is L-OPP to be leveled
with G-OPP, G-TPP and L-TPP
Italy MLT A monthly planning on product level to determine
production and purchases based on netted
requirements. The aim is to use the available OPP
production process maximal. The BOMs are fixed and
contain subsequent steps. There is L-OPP to be leveled
with G-OPP, G-TPP and L-TPP

Global Nitrates/UAN MLT A monthly planning on product level to determine
production in the G-OPP plants and to fulfill demand
from the markets (netted requirements). The aim is to
use the available G-OPP production as efficient as
possible and to distribute the available
products/production as efficient as possible. The BOMs
are fixed and contain subsequent steps. The G-TPP is
monitored
Urea MLT A monthly planning on product level to determine
monitored
NPKs MLT A monthly planning on product level to determine
monitored
CN MLT A monthly planning on product level to determine
monitored. The CNmelt (the raw material in this model)
is end product of the NPK global model
Overall MLT An overview model on all global models to see
production capacities used in all factories. This model is
for reference only.
There are two types of AP models
Model type Description

Brazil An optimization model to calculate all stocks, purchases, productions
and sales in a region. This model uses solvers to optimize on a fixed or
South Africa variable bill of material, ship sizes, capacities, lead times, stock
United Kingdom quantities etc.. This optimized plan is derived at the point where the plan
is feasible and the costs are lowest.
France A calculation model to match production with sales. These models are
maintained manually (with the option to use solvers in a later stage).
Italy These models need input from either RP (France, Italy and a number of
Global Nitrates/UAN markets) or AP (blending hubs). These models do not receive a forecast
Global Urea from the market(s) but operate on an existing requirements plan (AP or
Global NPKs RP)
Global CN
Global overall
3.1 Class Diagram

The figure below shows the AP class diagram as envisaged based on the
scoping and design discussions. The cores of the solutions are based on the
BOM/Routings structure of the standard Infor SNO (Strategic Network
Optimization) template model. This model allows an infinite number of
process steps within one generic structure, which makes it possible to fit
different sites with a different number of process steps in one model.
There are 2 model templates available:
The first template is the model to be used by the blending hubs. This model
has both a structure for the formula with predefined ingredients (with a
predefined draw quantity per ingredient) and a structure with variable draw
quantities for a set of ingredients where usage is done based on
specifications (the variable BOM)
The second template is used for Global planning and other (sales) regions
where the end results of the model above combined with information of the
other solutions in the supply chain is used as input of this model. This model
has only a fixed BOM structure, but can have a multilevel BOM where this is
not used (often) in the blending model.
Market Focus Model to be used

Blending Brazil MLT Model 1 with variable BOM
ST Model 1 with variable BOM
South Africa MLT Model 1 with fixed BOM
United MLT Model 1 with fixed BOM
Kingdom
Production France MLT Model 2 with fixed BOM
hub Italy MLT Model 2 with fixed BOM
Global Nitrates/UAN MLT Model 2 with fixed BOM
Urea MLT Model 2 with fixed BOM
NPKs MLT Model 2 with fixed BOM
CN MLT Model 2 with fixed BOM
Overall MLT Model 2 with fixed BOM
The models for South Africa and United Kingdom have the possibility to add a
variable BOM. Once a model uses the variable BOM the fixed BOM will no
longer be interfaced from the ERP system(s). The BOM information needs to
be entered manually in integration layer when a variable BOM is used in the

model.
This manual editing of variable BOMs will be supported by a hierarchical

setup of the master data. Manual work is limited to indicating which raw
materials will be used for which product family. The database will generate for
each blend / aggregator the necessary variable BOM info for AP. This manual
editing will be supported by an external tool (to be decided in which format).
See Formulas for an explanation.
The second model is a model with a similar setup on supply, transfer, sales
and (fixed formula) production. The transfer is still in but is not foreseen to be
used. The model is adapted for manual maintenance.
3.1.1 Products
Products can be classified into
end products
intermediate products
raw materials (ingredients, raw materials and packaging materials).
This classification differs from market to market and therefore from model to
model.
End products are sold to customers and are produced out of several other
intermediate products and / or raw materials. A number of products act both
as an end product and as an intermediate product dependant on the time and

place in the supply chain. These products are sold to customers as well as
used for the production of other end / intermediate products. Example: an
NPK produced in Porsgrunn is sold to the blending hub in UK as finished
material. This NPK can be sold directly to a customer and could function as a
raw material in a blending operation to produce a blend.
The products being planned within AP are the so called planning products.
These are not the actual products as they can for example be found in the
ERP systems. Similar products existing in reality are grouped into planning
products that are planned as single items.
Market Focus Number of products / aggregates

Blending Brazil MLT 180-200 aggregates (approx 800 nowadays. Project
ongoing to limit this to 200)
ST 6000 (planning)products
South Africa MLT 300 planning products (in 20 aggregate groups)
United MLT 40 planning products
Kingdom
Production France MLT Approx 100 planning products
hub Italy MLT Approx 25 planning products
Global Nitrates/UAN MLT Approx 25 planning products
Urea MLT Approx 10 planning products
NPKs MLT Approx 50 planning products
CN MLT Approx 10 planning products
Overall MLT 100 - 150 planning products
Note: An aggregate is a model blend representative for a group of blends.

The aggregated level is introduced to keep the AP model size under control.
In a later chapter of this document the variable BOM is introduced. If this
variable BOM is applied on all products, the model will become unhandleable.
See Model size calculation
Note: The aggregated level in Brazil does not contain packaging information.
This packaging information is replaced by a common packaging type in the
aggregator group.
MLT model: Monthly buckets; 6-18 months in advance.

ST model: Weekly buckets with split at month split (2 buckets for same week
at the beginning and end of the month); 4-13 weeks in advance
See Calendar Buckets & Horizon for a further explanation of the time
structure
On product level the total cover stock is given. This number of weeks worth
of stock is valid for the whole supply chain. E.g. 10 weeks worth of stock for
the whole of Brazil.
The service level per product is calculated in the product class and in the
customer class.
Budget project phase In the budget phase of the project only the planning
products or aggregates are used. The planning is on all levels a one off-plan
(a budget for 2008) not supported by workflows. All models (blending, sales,
global) are used to calculate this budget plan.
Balancing project phase In the balancing phase the models for global and
production hubs (IT and FR) are finalized. These models are expanded with
workflows to make a month to month planning possible. The models will
operate manual where needed/possible/agreed. The communication between
global and markets is firmed.
Optimizing project phase In the optimizing phase planning products (for

all blending model instances) are taken into account and the models are
expanded with solvers and workflows to make a month to month planning
possible. The communication between global and (blending) markets is
firmed.
Post Optimizing project phase In the phase after the 1st of January 2008
the model usage in Brazil will be expanded by using a set of workflows to
increase complexity in the model. The model will be used to see if the
aggregated model is still feasible on a short term taking all products and
discrete constraints into account. And to determine in which weeks vessels
are preferred to arrive.
3.1.2 Locations
All relevant locations physically available in a supply chain are translated in
the AP model. Both MLT and ST model have the same locations. Locations
can be stock keeping or non-stock keeping.
In the budget phase location do not have links with locations. Production is
grouped in a number of locations to represent the budget per location. All
warehouses, ports and other locations are left out.
In the optimizing phase the network on the blending hub locations is

extended. This network has connections from one location to the other (called
routes and transfers)
Market Focus Phase Locations

Blending Brazil MLT Budget One location per production facility with
one combined function for production,
blending, bagging (if applicable), port
and warehouse. No links between
facilities. Global sites modeled as
supplier relation
Optimizing Every location (production, blending,
bagging, diluting, warehouse, port)
modeled. Based on routes the transfer
network is created. The port from global
sites is used as transition point between
blending and global
ST Feasibility Location identical to the optimizing
study structure. Only active transfers
(transfers used by the MLT model in the
first 3 months) are used
South Africa MLT Budget One location per production facility with
blending, bagging (if applicable), port
supplier relation
blending and global
United MLT Budget One location per production facility with
Kingdom blending, bagging (if applicable), port
supplier relation
blending and global
Production France MLT Budget One location per site
hub Balancing One location per site
Italy MLT Budget One location per site
Balancing One location per site

Global Nitrates/UAN MLT Budget One location per site
Urea MLT Budget One location per site
NPKs MLT Budget One location per site
CN MLT Budget One location per site
Overall MLT Budget One location per site
Types of locations:
Port
Production
Stock
Port + Stock
Port + Stock + Production
Stock + Production
Production could be bagging, blending, diluting, main production or local

production. This indication of the type of location is only for referential
(reporting) purposes. Capacity on a location is expressed as one general
capacity. Similar production lines in one location should preferable be
combined.
It is a choice to model the customer relation with optional locations. These

locations will gather all demand with the possibility to store transport costs
between production location and customer location. Downside of the
modeling customers as locations is the rise of location and therefore the
number of transfers (see Transfers and Routes). Positive effect is the
possibility to store route specific costs in case of multiple routes towards the
customer.
Market Focus Customer Location structure

Blending Brazil MLT Use method 3
ST Use method 3
South Africa MLT Use method 3
United MLT Use method 1
Kingdom
Production France MLT not applicable
hub Italy MLT not applicable
Global Nitrates/UAN MLT not applicable
Urea MLT not applicable
NPKs MLT not applicable
CN MLT not applicable
Overall MLT not applicable
See 4.1.6 for the explanation of customers.
The supplier relationship functions with an intermediate location for OPP

deliveries. In case of FOB deliveries the goods are owned by the hub when
loaded on the ship. For Local and Global suppliers for TPP the ownership
changes at unloading at the production facility or port.
On the location for the global location the port of destination is handled as a
sub-location. This enables the global sites to see the destination on the
supplier relationship. The sub locations are also available in the global model
to see the shipments to the individual ports.
See 4.1.4 for an explanation on suppliers.
Since the global models will have blending models as customer and the
blending models will have the global model as supplier we can make a joined
example:
Blending Global
Main Location Sub Location Vendor Customer Sub Location Main Location
Porsgrunn Port Porto Porsgrunn Yara Brazil Not in use Porsgrunn
Alegro Porto Alegro
Porsgrunn Port Capetown Porsgrunn Yara South Not in use Porsgrunn
Africa
Capetown
Sluiskil Port Capetown Sluiskil Yara South Not in use Sluiskil
Africa
Capetown
If drill down information is needed, this will be generated with the use of
queries in AP. These queries select e.g. in the global model all the ports for
Yara South Africa. By applying different queries, different drill down structures
can be used.
3.1.3 Products@Locations
In the product at location class the products (and aggregates) are made
specific per location. When a product has been processed / used / produced
at a certain location a production@location record will be generated.
The Max Inventory property in the P@L class is product driven. E.g. if for
raw materials it is allowed to store materials and for finished products it is not,
the max inventory on finished products needs to be set to 0. If there is a
physical constraint on space, the constraint needs to be added to the location.
The default max inventory is 999.999.999
The Minimum Service Level is a hard constraint to force certain products to

stay above a minimum level. If this constraint is applied to too many products
it can result into an infeasible solution. The default minimum service level is 0.
The service level is calculated anyhow and maximized in the solver.
The Monthly Holding Cost can either be a penalty or actual costs. In most
cases this is a fixed amount per month.
The Budget is property to compare the budget quantity with the forecast
quantity. There is no relationship between the two properties. The budget is
visible and can be used in determining the order-quantity in the customer
allocations. This functionality will be used at global. There is both a production
and a sales budget.
The Hist Production is a property (in the global model only) to show the
production of global sites in a number of months of history.
Market Focus
Blending Brazil MLT Forecast customer forecast on aggregate
Orders not in use
Budget not in use / reference only
Delivery purchasing receipts + transports
receipts
Shipments transport shipments
ST Forecast customer forecast on aggregate
Orders customer orders on blend
Note: only one active per bucket
Budget not in use

receipts
South Africa MLT Forecast customer forecast
Orders not in use
Budget not in use / reference only
receipts
United MLT Forecast customer forecast
Orders not in use
Kingdom Budget not in use / reference only
receipts
Production France MLT Forecast netted requirement from markets
Sales promised requirements to markets
hub Budget reference only
Arbitration reference only
Delivery not in use
Shipments not in use
Hist purchase reference only
Hist production reference only
Hist sales reference only
Italy MLT Forecast netted requirement from markets
Budget reference only
Delivery not in use
Global Nitrates/UAN MLT Forecast netted requirement from markets
Delivery not in use
Urea MLT Forecast netted requirement from markets
Delivery not in use
NPKs MLT Forecast netted requirement from markets
Delivery not in use
CN MLT Forecast netted requirement from markets
Delivery not in use
Overall MLT Forecast netted requirement from markets

Delivery not in use
If products@locations are not available and a sell cannot be fulfilled, this will
lead to either:
Lost sales there is not enough material and its not possible to
resupply stock by producing or purchasing (upfront) or
Backlog the point of satisfying the sell is postponed until the
material is available. If it is not possible to get material at all, this will
still lead to lost sales.
Lost sales and Backlog are the objectives in the solver with the highest
objective. It is an indication per customer allocation if it is allowed to generate
backlog (per default is yes)
Unused capacity (production capacity with raw materials available) is

expressed as CTP. This capable to promise is the quantity that can be
promised to (new) customers without jeopardizing existing forecasts (or
orders)
Stock (with possibly Safety Stock) is also monitored at P@L level. Each
product is monitored at P@L level and both product and location level in total.
Safety stock is either a cover stock (used in hubs because forecasted
products are different from the storage items) or based on a forecast
inaccuracy calculation (maybe to be used in a later stage).
The build-up of this network per model is done in integration. See

Products@Locations for an explanation. Only existing combinations are
visible in the model.
3.1.4 Suppliers
All parties delivering goods to the supply chain are suppliers. This is of course
the case for TPP products which are purchased products. Also the OPP
products are handled via a supplier relationship. In the global model, the
purchase requirements on the various OPP suppliers will be handled as
demand.
In the Blending and Complex region models there is a location at the sending
facility (e.g. Porsgrunn). This location is linked (in supplier allocations) to the
supplier.
Market Focus Suppliers

Blending Brazil MLT G-OPP / G-TPP (both via port)
L-OPP / L-TPP (via warehouse / production site)
ST G-OPP / G-TPP (everything is arranged and locked,
manual intervention possible)
L-OPP / L-TPP (limited possibilities)
South Africa MLT G-OPP / G-TPP (both via port)
L-OPP / L-TPP (via warehouse / production site / port)
United MLT G-OPP / G-TPP (both via port)
L-OPP / L-TPP (via warehouse / production site / port)
Kingdom
Production France MLT deliveries for RM and INT produced in the global French
hub site; suppliers of critical raw materials; possible

connections to other global sites in terms or raw
material and intermediates (global OPP via RP)
Italy MLT suppliers of critical raw materials; possible connections
to other global sites in terms or raw material and
intermediates (global OPP via RP)
Global Nitrates/UAN MLT deliveries from other global models and deliveries of
critical raw materials
Urea MLT deliveries from other global models and deliveries of
NPKs MLT deliveries from other global models and deliveries of
CN MLT deliveries from other global models and deliveries of
Overall MLT deliveries from other global models and deliveries of
In the budget phase the connection with suppliers is directly on the producing
locations. In the optimizing phase the relation is moved to the initial receiving
point. E.g. if the receiving point is the habor in Capetown the supplier relation
is raised on the Capetown location.
3.1.5 Supplier Allocations

The supplier allocations are the links between products@locations and
suppliers. Note that this is the location where the supplied goods enter the
supply chain. In case of a port delivery the supplier relationship is raised on
the port. Many warehouses from that port will receive materials from the same
supplier delivery.
The Min and Max purchase qty show boundaries per product/supplier how
much is allowed to buy. A contract obligation should be entered here
The Purchase Lead Time is the time between ordering and receiving of the
goods. Since there is a location in the port of the sending OPP facility, this is
the time between ordering and the boat leaving the port.
The Purchase Unit Cost is the total purchase cost price per 1 UoM. If there
is no price available a penalty can function too. The higher the penalty, the
more difficult it is to buy at this supplier
The Hist Purchase is a property (in the global model only) to show the
purchases for global sites in a number of months of history.
In Supplier Allocations is described that only existing combinations are added

to the various models.
Market Focus Supplier Allocation

Blending Brazil MLT Supplier allocations for global suppliers with main
products, local suppliers for TPP product and local
suppliers for raw materials.
ST Supplier allocations for global suppliers with main
South Africa MLT Supplier allocations for global suppliers with main
United MLT Supplier allocations for global suppliers with main
Kingdom

Production France MLT Supplier allocations for local suppliers for raw materials
per factory. In some case an allocation to deliver raw
hub materials from other (global) locations. TPP is handled in
RP.
Italy MLT Supplier allocations for local suppliers for raw materials
materials from other (global) locations. TPP is handled in
RP.
Global Nitrates/UAN MLT Supplier allocations for local suppliers for raw materials
materials from other (global) locations
Urea MLT Supplier allocations for local suppliers for raw materials
NPKs MLT Supplier allocations for local suppliers for raw materials
CN MLT Supplier allocations for local suppliers for raw materials
Overall MLT Supplier allocations for local suppliers for raw materials
Since the global purchases are handled via a port of origin, the supplier
relationship is managed on port of origin (e.g. the supplier allocation for
Porsgrunn is related to the location Porsgrunn and not to the blending unit to
process the materials in).
On TPP the general rule is to buy OPP first before entering a TPP value.
Since this calculation is based on costs, the lowest costs will have preference
(if TPP is cheaper, it will use TPP first). The maximum purchase is used to
build in a maximum from a specific supplier/product
3.1.6 Customers
Customers determine the (external) demand from the market. The amount of
detail is identical to the sales forecast. At this moment the sales forecast has
the level of sales manager or (below that) sales supervisor as lowest level.
Market Focus Customer

Blending Brazil MLT Sales supervisors
ST Sales supervisors / not important
South Africa MLT Sales supervisors
United MLT Sales manager / regional split
Kingdom
Production France MLT The regional market(s), if information is available (such
as warehouse, port or production site it is included
hub
Italy MLT The regional market(s), if information is available (such
Global Nitrates/UAN MLT The regional market(s), if information is available (such
Urea MLT The regional market(s), if information is available (such
NPKs MLT The regional market(s), if information is available (such
CN MLT The regional market(s), if information is available (such
Overall MLT The regional market(s), if information is available (such
In case of a blending hub model, the demand comes from sales planning.
This forecast with external demand shows the quantity that is prognosed to
be sent to customers. Derived from the requirements plan(s) the global, Italy
and France model can derive dependant demand. The customers in such a
model are the regional market. A change in sales planning could lead to a
change in requirements plan and could lead to a change in global planning.
Blending models receive forecast group as customer in their model. The

global, Italy and France models receive the net requirements from AP and RP
as input (= sales region / port as input).
3.1.7 Customer Allocations

Service Level A minimum service level of 100% means that the demand of
the forecast group should be fulfilled whenever possible (i.e. it does not lead
to violation of any other hard constraint). Profitability is completely discarded
in this situation. A minimum service level of 0% means that AP will fulfil
demand based on overall profitability. Therefore in general products with a
high profitability will be prioritized above products with low profitability.
Unprofitable products (where costs involved are higher than the obtained
revenue) will never be fulfilled.
Unsatisfied Demand AP will indicate demand that will not be delivered to

the customers of the forecast group as unfulfilled demand.
Forecast group demand and sales prices for end products are imported from
the DP demand forecast. Demand for intermediates and raw material is
derived requirement which is calculated from preceding processes, required
for the production of the end product.
In the ST model in stead of the demand forecast the Open Sales Orders of a
forecast group will be imported. These open sales orders will be considered
as committed demand, and therefore AP will always try to fulfill this demand
(like it does for demand of forecast groups with a 100% service level).
The price property is used for relative importance in case there is a choice
which product will be added to lost sales. The product with the highest margin
will have the preference to be delivered over the product with a lower margin.
The Hist Sales is a property (in the global model only) to show the deliveries
from global sites in a number of months of history.
The Arbitration Sales is a property (in the global model only) to show the
arbitration sales from global sites in a number of months of history.
3.1.8 Routes
The route class is used to identify the ship sizes, route costs and route
durations.
Ship size: the ship size is a batch size. It calculates the needs for full ships. It
indicates the number of ships with the tonnage per ship to the global
planning. When a full ship is confirmed, the actual tonnage of the transport
can be different. Therefore the ship size is ignored when looking into the in
transit stocks. Note: the linear solver does not create full loads, the discrete
solver, takes boat sizes into account. It will show a number of boats as
number, not rounded to full figures.
Market Focus Routes

Blending Brazil MLT Minimum on transfers
ST None
South Africa MLT Minimum on transfers
United MLT Ship sizes in the calculation. Every route has a quantity
and the combination of transfer sizes should be equal to
Kingdom the ship size
Production France MLT No routes foreseen in this model
hub Italy MLT No routes foreseen in this model
Global Nitrates/UAN MLT No routes foreseen in this model
Urea MLT No routes foreseen in this model
NPKs MLT No routes foreseen in this model
CN MLT No routes foreseen in this model
Overall MLT No routes foreseen in this model
Because there are various ships on a route, the resource route should be
made unique for each boat size. The route is used to build up the (product
and route specific) transport network
If (in the UK case) the quantity varies per ship, an extra route for small
quantities is needed. This special route (against a high penalty with e.g. a
quantity of 100 TNE) enables it to make smaller ships
Route cost: a boat size will determine the discharge costs and transport
costs. If there is a fixed price per ton, the costs can be used at transport level.
If there is a charge per vessel, the routes class needs to be used.
Duration: the duration could be boat specific. If there is no difference in

duration, both transfer and route have the same function. Since the duration
is in days and the AP model is in weeks / months, there will be a rounding to
the nearest full bucket.
3.1.9 Transfers
The transfers are the connections between locations. The transfers are
product and route specific.
Market Focus
Blending Brazil MLT Show the in transit stock
ST In transit stock is used to determine the arrival week
South Africa MLT Show the floating stock
United MLT Show the floating stock
Kingdom
Production France MLT No transfers foreseen in this model
hub Italy MLT No transfers foreseen in this model

Global Nitrates/UAN MLT No transfers foreseen in this model
Urea MLT No transfers foreseen in this model
NPKs MLT No transfers foreseen in this model
CN MLT No transfers foreseen in this model
Overall MLT No transfers foreseen in this model
The Lead Time is in days. Since the bucket size is months (except for the ST
Brazil model), the lead-time will be displayed in months: < 15 days: no lead-
time showed; > 15 days: lead-time is showed as 1 month difference
The minimum transfer quantity is a minimum per bucket per product. Note:
this property makes the model discrete. An increase in calculation time is
expected. Example: to use a transfer you need at least 10000 ton. Quantities
below 10000 ton will either be raised to 10000 (which created stock) or
moved to another period to be more effective with other deliveries
3.1.10 Resources
Resources are the machines on the various (production) locations. In general
at blending sites similar production lines are modeled as one resource per
location. On global sites, production lines are modeled as one unit (if
possible). Only if the capacity is non-transferable and critical, each resource
is modeled. E.g. 2 blenders which perform the same task can be modeled as
one resource with a common capacity. In case of a blender and a packaging
line, this could be modeled as 2 resources if the capacity is constrained.
The capacity is maintained in hours.

A capacity in hours to indicate the regular hours
An extra capacity to show more expensive capacity (such as
overtime). It shows an extra boundary. If the problem can be solved
by adding capacity this will be indicated by usage of these hours
A min load is a percentage to load minimal. Be aware this is a hard
constraint. If there are no orders/forecast, stock will be added.
Market Focus Resources

Blending Brazil MLT Blenders, Dilutors, Packaging lines (t.b.d.), Equipment
from OPP fertilizer production (Rio Grande)
ST Blenders, Dilutors, Packaging lines (t.b.d.), Equipment
from OPP fertilizer production (Rio Grande)
South Africa MLT Blenders, Dilutors, Packaging lines (t.b.d.)
United MLT Blenders, Dilutors, Packaging lines (t.b.d.)
Kingdom
Production France MLT Equipment from OPP fertilizer production
hub Italy MLT Equipment from OPP fertilizer production
Global Nitrates/UAN MLT Equipment from OPP fertilizer production
Urea MLT Equipment from OPP fertilizer production
NPKs MLT Equipment from OPP fertilizer production
CN MLT Equipment from OPP fertilizer production
Overall MLT Equipment from OPP fertilizer production
The extra capacity is an important property since it makes the constraint a

soft constraint. Problems that can be solved with adding capacity are
indicated by usage of the extra capacity.
3.1.11 Resource Allocations

The resource allocations are also called Routings. They show the capacity
utilization of a process on a resource. The rate is number of units (ton) per
hour. By comparing the rate per product with the total number of hours
available the utilization is calculated.
By using Scheduled Production the production is frozen. This is a manual

entry field to freeze a certain quantity on a certain production line.
The Min batch size is a level to start production. This will only be used in the
Global model
The Resource Allocation Cost are preference costs in case there is a

choice of lines. It shows a cost per ton. In general a system with 10 to indicate
the preferred line and 20, 30 etc. for the optional line is sufficient. If more
detailed production costs are available they could be applied. They should
however be generalized over all locations. Otherwise they would interfere with
the transfer/route costs to influence the choice of location.
The Min Load is a hard constraint to produce at a minimum level. On

blending level there are not many applications for this. This would be useful
for e.g. the Ammonia factory. This ammonia factory should be planned at
maximum level (taking into account certain resource availability). This factory
could e.g. be planned at a minimum level of 95%. If there is not enough
dependant demand it will build up stock on a possible level.
3.1.12 Processes
The processes are grouping structures for producing products. Each process
will have a product and a version attached to it. The version indicated to
enable more than one version on one location. With version it is possible to
have more than one BOM or Routing on a location to produce the same
product.
The process is the high level holding place for a formula (Bill of Material) and
a resource allocation (Routing). Product with an alternative resource
allocation and/or formula within the same location are handled with a version
within the process.
An example of an alternative resource allocation would be a second plant with

a possibility to produce the same product like on the default resource (with
possible different costs and a different speed
An example of an alternative formula would be an alternative ingredient
The alternative process holds the combination of the alternative process and
the alternative routing.
Market Focus Processes

Blending Brazil MLT In most cases one variable formula. Certain raw
materials are declared as fixed inflow. In some cases
there is an optional variable formula. Single resource
allocations. Therefore in most cases a process with one
version
ST See MLT
South Africa MLT Multi version formula and single version resource
allocation: a process with multiple versions is applicable
United MLT Single version formula and multi version resource
allocation: a process with multiple versions is applicable
Kingdom
Production France MLT Single version formula and single version resource
allocation: single version process (expansion still
hub possible)
Italy MLT Single version formula and single version resource
possible)
Global Nitrates/UAN MLT Single version formula and single version resource
possible)
Urea MLT Single version formula and single version resource
possible)
NPKs MLT Single version formula and single version resource
possible)
CN MLT Single version formula and single version resource
possible)
Overall MLT Single version formula and single version resource
possible)
3.1.13 Formulas
Formulas are the representation of the Bill of Material (BOM). There will be 2
types of records:
Outflow records, to produce a certain material

Inflow records, to consume a certain material
For each BOM is applicable: the SUM of outflow = the SUM of inflow. If there
are BOMs where this rule does not apply, an extra ingredient or a by-product
should be added. In the blending model this represented as (all) Outflow =
(all) Variable Inflow + (all) Fixed Inflow. The outflow is shown as Production
(or Yield). A counter counts all inflow products. This counter could be set to a
maximum but this is not foreseen (it makes the calculation discrete).
In general the outflow is always 1. When a formula delivers a secondary

product (or byproduct) this is applied here. The sum of main product and
byproduct should be 1. Therefore a filler should be used to make up the total
quantity. Example: if a NPK is diluted the water is a filler. In a 50% solution
the NPK drops from 16-16-16 to 8-8-8 and the other 50% is water.
The condition that the quantity of inflow should equal the quantity of outflow is
only applicable in the blending optimization model. In the global models this
could differ.
A variable BOM has version v00

A fixed BOM has version v01 - v99
Whenever a hub wants to use variable BOMs, all data entry will be manual.
Even the available (fixed) BOMs in SAP will not be used to prevent double
counts.
Market Focus Formula

Blending Brazil MLT Variable formula with certain fixed ingredients, inflow =
outflow
ST Variable formula with certain fixed ingredients, inflow =
outflow
South Africa MLT Fixed formula with alternatives, inflow = outflow
United MLT Fixed formula without alternatives (at the start), inflow =
outflow
Kingdom
Production France MLT Fixed formula, inflow independent from outflow
hub Italy MLT Fixed formula, inflow independent from outflow
Global Nitrates/UAN MLT Fixed formula, inflow independent from outflow
Urea MLT Fixed formula, inflow independent from outflow
NPKs MLT Fixed formula, inflow independent from outflow
CN MLT Fixed formula, inflow independent from outflow
Overall MLT Fixed formula, inflow independent from outflow
In general only critical raw materials are added. Critical means they are
important in the planning process 1,5 year upfront. Example: in a packaging
operation the product itself is a critical material. The empty bigbags are not.
In the case of a variable BOM certain items can be declared as fixed

ingredients. Example: micronutrients such as Zinc should be added in small
quantities. These raw materials influence the NPK specifications and are
critical raw materials. Also S (sulfur) can be seen as fixed ingredient.
3.1.14 Parameters
Market Focus Parameters

Blending Brazil MLT Parameters for aggregated products
ST Parameters for planning products
South Africa MLT Future use
United MLT Future use
Kingdom
Production France MLT Not available
hub Italy MLT Not available
Global Nitrates/UAN MLT Not available
Urea MLT Not available
NPKs MLT Not available
CN MLT Not available
Overall MLT Not available
The parameters show the 3 basic parameters the variable BOM uses. All
ingredients have a portion of these parameters. By adding ingredients the
blended product should also be in specification according to these
parameters.
The parameters are:
N Nitrogen
P Phosphorous
K Potassium
Note: There is the possibility to add an extra parameters At this moment the
S component is not going to be added as variable BOM. This would have a
large effect on the number of records and the calculation time (see Model size
calculation for the implications). The S component is going to be added as a
fixed ingredient in the BOM (see formula).
Per outflow product and per inflow product the specifications are known.
These specifications of the outflow and the sum of ingredients should match.
Example:
In the example the produced aggregate has NPK values of 10-23-10. There
are 3 ingredients possible 16-16-16, 02-40-00 and 14-03-18. By adding
quantities of these ingredients, the specification of the blend should match the
given NPK values.
3.1.15 Specifications
Specifications are the values for the parameters on produced products.
Market Focus Specifications

Blending Brazil MLT Parameter specs per blend for aggregated products
ST Parameter specs per blend for planning products
Kingdom
The specifications are contents of the parameters in the blended product.

There is a Min Inflow Factor and a Max Inflow Factor. These properties
show the minimum and maximum specification in the blended product to use
without penalties. E.g. in a 16-16-16 the N will have a specification of MIN 16
and MAX 16 + 1% = 16,16. The Over Max Penalty and Under Min Penalty
indicate a penalty if the raw materials cannot reach the specification. These
penalties are important since they make the constraint a soft constraint. If a
product is unmake-able because the correct raw materials are not available it
will propose the best formula and will indicate which specification is not
reached or over-used.
3.1.16 Recipes
Specifications are the values for the parameters on consumed products
Market Focus Recipes

Blending Brazil MLT Parameter specs per possible ingredient for aggregated
products
ST Parameter specs per possible ingredient for planning
products
Kingdom
In each formula a filler is used. This filler is a substance (without N, P or K) to

make products from raw materials with a high potency (= e.g. a high N factor).
An example of a filler is lime stone or water.
The recipes are formula specific specification of the ingredient parameters.

Per ingredient in a BOM there is a declaration of the content of e.g. N
3.1.17 Recipe Allocations
The recipe allocation is the link from parameters at inflow level to the
parameters at outflow level.
Market Focus Recipe Allocations

Blending Brazil MLT Parameters for aggregated products
ST Parameters for planning products
Kingdom
This gives the following overall picture of relationships between formula,

specification and recipe (allocation):
This setup will be generated via product families in the integration hub. See
for an explanation.
3.2 Calendar Buckets & Horizon
The whole supply chain (see the solution map for the details) the bucket size
is set to months. The Brazilian region has the preference to work in weekly
buckets in the first quarter. Doing so, the region will be enabled to store data
(on purchasing) on weekly buckets which will give a clearer picture on stocks.
MLT model - There are maximum 18 months in the mid long term plan. On
blending hub the level is planning product (or aggregator level in case of
Brazil). On global level this is planning product level too. In general conditions
the MLT in the hubs is 6 months of plan on screen. This is a rolling horizon
Once a year the plan is extended with a full new (budget) year. The global
plan is stable on one year. Months in the past are frozen and once a year the
plan is expanded with a new budget year.
In the global model there is a fiscal and a fertilizer year (July June). Before
expanding the year with a new budget year the plan is expanded with a
fertilizer year. The expansion works according to the described system with
budget
ST model the first month is a split-up in weeks of the first bucket. Since the
opening balance should be synchronized with the opening balance of the
MLT model. In this model the purchases are frozen and the model is
recalculated using orders in stead of forecast.
Market Focus Input Buckets

Blending Brazil MLT Forecast Monthly
ST Orders + Forecast Weekly (with extra split at
month split)
South Africa MLT Forecast Monthly
United MLT Forecast Monthly
Kingdom
Production France MLT Forecast / RP plan Monthly

hub Italy MLT Forecast / RP plan Monthly
Global Nitrates/UAN MLT RP plan / AP plan Monthly
Urea MLT RP plan / AP plan Monthly
NPKs MLT RP plan / AP plan Monthly
CN MLT RP plan / AP plan Monthly
Overall MLT RP plan / AP plan Monthly
The switch from MLT model to ST model will be done in the same model.
With a workflow (see Planning Workflows) the calendar is split into week
buckets. This will automatically divide the month quantities into smaller
weekly quantities. When this plan is edited the quantities are stored in weekly
quantities. This makes it possible to redo this exercise multiple times. See the
example screenshots
This ST calculation is done in a model which is used for the MLT calculation.
The model is saved separately and can be consulted separately. There is not
an aggregation step foreseen from ST level back to MLT level.
3.3 Optimizations
In the blending model there are two types of solvers:
Linear solver
Discrete solver
In general a discrete solver is (much) more time consuming than a linear

solver. But when discrete calculations are part of the model (e.g. to use a ship
size when the transfer is calculated) a discrete solver is needed.
Market Focus Recipe Allocations

Blending Brazil MLT No discrete constraints foreseen. In a later stage a ship
size can be introduced. The number of ingredients is
information data calculated afterwards and not
constrained. Linear
ST Ship sizes are introduced, although maintained
manually. Linear
South Africa MLT A minimum transfer quantity is included. The number of
ingredients is determined by the fixed BOM and not
constrained. Discrete
United MLT Ship sizes on routes are used. Minimum quantities on
purchase and transfers are applied. Discrete
Kingdom
Production France MLT No solving at AP introduction
hub Italy MLT No solving at AP introduction
Global Nitrates/UAN MLT No solving at AP introduction
Urea MLT No solving at AP introduction
NPKs MLT No solving at AP introduction
CN MLT No solving at AP introduction
Overall MLT No solving at AP introduction
Since the linear solving is a much faster way of solving, a 2 layer solve is
proposed. An initial solve with a linear solver is performed to see if the
problem is feasible. If the problem is feasible the second solve run is started
to give an exact answer. This is performed in a workflow.
Objectives of a solver
(with a weight per
objective).
Posted properties: the

properties the solver
can change
Locked properties: the

properties are not
allowed to change
(e.g. the forecast)
The solver needs fine tuning on the objectives. By changing the weights the
result of the solver is changed. In the picture above, generating lost sales is
10000 times more important than generating transport cost. Both solvers are
available in the blending model. But if the problem is not discrete, the discrete
one will not be used.
The solvers are also available in the global model but will not be used initially.
If a model is too large to solve in one run (see Model size calculation) the
problem can also be solved in phases. This could be a time phasing:
But could also be a solve based on functionality. First solve the production
problem and then the transport (and purchasing problem). The place where
this could be applicable is on the Brazilian ST model. A detailed roll out plan
will be made after 1/1/2008. All workflows, solvers and integrations will be in
before 1/1/2008
3.4 Model size calculation
This calculation is just an estimation of the number of variables in the model.

The maximum size of a windows based install is approx 4 to 4,5 million
variables. Beyond this point the maximum available memory in a windows
machine is not sufficient. This is a physical limit of windows. In such a
condition a limit of the model is one of the solutions. By solving in phases or

decomposing the problem into smaller problems can help. Another solution
(which has not been evaluated in this design) is the use of Linux which can
cope with more memory.
Another solution to limit the size of the model can be by adding a split in the
model:
One model that solves in one bucket of a month all products to see if
the agreed purchases can still cope with the blending plans for orders
A second model to determine on a weekly basis the delivery plan in
order to assign an appropriate week for a (global) delivery.
One important statement is the use of discrete constraints. This will have a
significant impact on solving times. At this stage it is not possible to estimate
a solving time. Discrete will slow down the (solving) process seriously.
3.5 Technical setup of the models

AP functions outside of the database environment compared to the RP
(requirements planning) or SP (sales planning) module. There is a connection
to the database (Integration Hub) located on one central server. This server
holds data, both master and transactional and is located on one central
location.
In cases where the data load is substantial (e.g. the Brazil ST model) the
connection to the database should be optimized and be as short and with the
highest bandwidth possible.
In case of models with a lot of variables (e.g. the Brazil ST model) the
memory usage should be optimized and as high available for calculation as
possible. A server environment would be the preference.
Models with a limited number of resources (data load) and therefore a limited
number of variables for solving the model, can also be applied on local
machines. However, a Citrix environment could be seen as preference to
generate a uniform and controlled solution with standardized structures and
backups.
See the technical document for further information about this subject.
3.6 Integration master data

In all integrations only the fields in use are interfaced. Fields not in use are
available in the database but set to 0 or left empty.
Each model triggers a set of records in the master data and the transactional
data. The views contain all records for a specific profile. If records are visible
under two profiles, the records are visible twice.
Market Focus Profile

Blending Brazil MLT YBBR
ST YBBR (with different set of
interfaces to import more detail)
South Africa MLT YBSA
United MLT YBUK
Kingdom
Production France MLT YPFR
hub Italy MLT YPIT
Global Nitrates/UAN MLT YGNI
Urea MLT YGUR
NPKs MLT YGNPK
CN MLT YGCN
Overall YGALL (no integration from or to
the hub, only integration from
global models)
Interface name YBBR YBBR YBSA YBUK YPFR YPIT YGNI YGUR YG YGCN YG
(ST) NPK ALL
IH_AP_Product_AG X - X X X X X X X X -
IH_AP_Product_BL - X - - - - - - - - -
IH_AP_Locations X X X X X X X X X X -
IH_AP_Product_ X - X X X X X X X X -
Locations_AG
IH_AP_Product_ - X - - - - - - - - -
Locations_BL
IH_AP_Suppliers X X X X X X X X X X -
IH_AP_Supplier_Allocations X X X X X X X X X X -
IH_AP_Customers X X X X X X X X X X -
IH_AP_Customer_ X X X X X X X X X X -
Allocations_AG
IH_AP_Customer_ - X - - - - - - - - -
Allocations_BL
IH_AP_Routes X X X X - - - - - - -
IH_AP_Transfers X X X X - - - - - - -
IH_AP_Resources X X X X X X X X X X -
IH_AP_Resource_ X X X X X X X X X X -
Allocations_AG
IH_AP_Processes_AG X X X X X X X X X X -
IH_AP_Processes_BL - X - - - - - - - - -
IH_AP_Formulas_AG X X X X X X X X X X -
IH_AP_Formulas_BL - X - - - - - - - - -
IH_AP_Parameters X X Future Future - - - - - - -
IH_AP_Specifications_AG X X Future Future - - - - - - -
IH_AP_Specifications_BL - X - - - - - - - - -
IH_AP_Recipes_AG X X Future Future - - - - - - -
IH_AP_Recipes_AG - X - - - - - - - - -
IH_AP_Recipe_ X X Future Future - - - - - - -
Allocations_AG
IH_AP_Recipe_ - X - - - - - - - - -
Allocations_BL
IH_AP_Forecast X X X X X X X X X X -
IH_AP_Orders - X - - - - - - - - -
IH_AP_Budget - - - - X X X X X X -
IH_AP_hist_Sales - - - - X X X X X X -
IH_AP_hist_Purchase - - - - X X X X X X -
IH_AP_hist_Production - - - - X X X X X X -
IH_AP_Stock_AG X X X X X X X X X X -
IH_AP_Stock_BL - X - - - - - - - - -
IH_AP_Stock_InTransit_AG X X X X X X X X X X -
IH_AP_Stock_InTransit_BL - - - - - - - - - - -
The YGALL model will be filled by exporting all resources and plans from the
YPFR, YPIT, YGNI, YGUR, YGNPK and YGCN models and import them into
one model. This model is used for viewing only. The stock could be imported
(and with that the product, location and product@location interface) if stock all
around the world should be visible. This is done with a report from the
database. Rosstock and other possible sites are initially not interfaced in the
all model. Information can be obtained from the database on a report.
All data comes from one database. With the profiles it is ensured that each
product is planned in only one AP model (no overlaps and no gaps). The
profiles select a part of the dataset.
The only way of importing (master) data will be via the Integration Hub. If data
does not exist in the ERP system (SAP, SUN) the data is imported or entered
in the Integration Hub via another method (so called Homeless Data).
The default method of reporting is again via the database via separated
tables in the database. There is no duplication of data. Information that is
imported is not updated and reported, but other data is reported. Example:
the forecast is the ingoing component and the purchasing is the outgoing
data element. If the report should contain master data or ingoing transaction
data, the link is made in the database.
The ST model for Brazil is a more detailed level in the MLT model. With the
use of workflows and a different
set of interfaces more complexity
is introduced. In the first 4 weeks
(exact number to be established)
the orders replace the forecast. In
the rest of the ST model the
orders are visible but the forecast
is still leading.
The blends imported in the ST

interfaces are filtered with the
blends that have orders in the first
4 weeks. Forecast can only exist
on aggregates.
The data in all described interfaces comes from the integration hub unless
described different.
3.6.1 Products
Master data Field / size Description

Name Text The product name. This is the product code + packaging
code + short description
Description Text Description of the product / aggregate
Unit Text Unit of measurement. In Yara this is always TNE.
Liquids are expressed in real tonnes taking the water
content into account
Item type Text RM / IM / FG. Overruled by product@location
Item class Text Yara product group
Max cover Number The maximum cover stock (in weeks coverage) on a
product over the whole supply chain
Aggregate Text The aggregate the blend belongs to. If there are no
aggregates or the blend is an aggregate this is the same
field as in NAME
Profile Text An identifier per record to receive the correct records per
model
The product table can contain both products and aggregated products. Based
on an identifier in AP (a variable) the correct level is chosen. If the identifier is
BL all products will be imported. If the identifier is AG all aggregated products
will be included (where aggregate = name).
The product comes from the core_product table. If it is an aggregator, it is

retrieved from the product aggregation field. Products with similar codes in
the product code field and aggregation field are aggregators themselves.
Products can have various aggregations and therefore it is possible to have a
different aggregation in Brazil than in South Africa.
3.6.2 Locations

Name Text The name of the location
Description Text Description of the location
Country Text The country
Region Text A lower level region identifier (such as the tax code)
Type Text A type of location (production, port, etc.)
Unit Text Unit of measurement. In Yara this is always TNE
Max inventory Number The maximum qty of inventory at this location (in TNE)
Max production Number The maximum qty of production at this location (in TNE)
Min production Number The minimum qty of production at this location (in TNE)
model
The locations are used in a different perspective as in the ERP solutions.

Therefore the locations are part of the homeless dataset (at least in the
Budget Phase). They will be uploaded via an Excel spreadsheet per AP
model.
In case of direct shipments a virtual location needs to be created. In case of

UK this is 2 locations. These locations trigger a transfer from one of the
(global) main production sites.
The connection to the global sites in the blending models is done with
locations and sublocations.
3.6.3 Products@Locations
The initial setup of the P@L class is done in the integration hub. Whenever
there is a new product, the possible locations where this item is used or
produced should be indicated.

Products.Name Text The link to the product
Locations.Name Text The link to the location
Description Text Description of the product at location level
Distribution Number 0
Item class Text See product-class
Item type Text See product-class
Unit Text See product-class
Forecast multiplier Number 1
Max inventory Number 999999999 or max level
Min service level Number 0 or actual level (max 99)
Monthly holding Number $ per TNE per month
cost
Units per pallet Number 1
model
The generation of this class is done with transactional history. Generation of

new products at location is done in the homeless section.
There is one unit of measurement of cost in the model. Since costs are only
used to find a minimum cost point, the costs are given in one currency.
Usually this is $ but this could be any currency chosen. As long as all costs
are in the same currency for one given model.
3.6.4 Suppliers
Name Text Name of a supplier
Description Text Description
model
Only active suppliers are imported into AP. Active supplier are supplier
attached to materials that can be bought in the AP model. This selecting is
either done in the integration from SAP where only certain groups of suppliers
are imported and also in the integration to AP where only suppliers are
imported where products exist in the supplier allocation.
3.6.5 Supplier Allocations

Locations.Name Text Name of the location
Suppliers.Name Text Name of the supplier
Products.Name Text Name of the product
Max purchase qty Number If there is a maximum purchase qty per monthly bucket
Min purchase qty Number If there is a minimum purchase qty per monthly bucket
Purchase lead time Number The lead time between ordering and shipping (receiving)
Purchase unit cost Number The purchase cost (incl. transport if applicable) which
includes product costs
model
Only relevant supplier allocations should be imported into AP.
3.6.6 Customers
Name Text Name of a customer(group)
model
A customer for the blending models is a forecast group and a customer for a
global model is an internal customer (market, warehouse, port etc.)
3.6.7 Customer Allocations

Customers.Name Text Name of the customer
Forecast multiplier Number 1
Minimum service Number 0 (could be a figure between 0 and 100. At start this will
be 0)
level
Price Number (estimated) sales price to end customer
Use Forecast Number 1
Use Order Number 1
model
Only relevant customer allocations should be imported into AP.
3.6.8 Routes
In the Integration hub routes are the high level representation of the transfers.
Different modalities of transport (e.g. by plane or by boat) are added here

Name Text Name of a transport
Type Text A type of transport
Max transport qty Number The maximum quantity to transport via this route per
bucket (default = 999999999)
Transport time Number The lead-time
Unit cost Number The quantity per transport
Dir (receiving loc) Number The ship size
model
3.6.9 Transfers
Transfers are product specific routes

Transfers.name Text Name of the transport (format is product: route)
Transfers out.name Text Identical name to the transfers name
Transfers in.name Text Identical name to the transfers name
Routes.name Text The link to the routes (format is warehouse out ->
warehouse in modality)
Transfers unit costs Number Price per transfer per product per TNE
To warehouse Text Location in
Product Text The product involved
From Warehouse Text Location out
Description Text Description of the transport
Type Text Type of transport (e.g. boat 30000 TNE)
Transfers transport Number Number of days in shipment time (can be overruled by
routes)
time
Min transport qty Number Minimum quantity of a product on a transport.
model
Only relevant transfers should be imported into the model
3.6.10 Resources
Resources.name Text Name of the resources (joined resources / production
lines)
Locations.name Text Name of the location
Capacity Number Number of hours per week. If 2 lines are handled in one
line, the capacity is multiplied
Extra capacity Number Number of hours per week (overtime)
Capacity multiplier Number 1
Min load Number Between 0 and 100. Gives a minimum load quantity (%)
model
3.6.11 Processes
Processes.Name Text Name of the process (=header of the BOM)

Unit Text TNE
Effective from Date The introduction date of the product
Effective to Date The end date of the product
Version Text Version identifier. V0 = variable BOM, V1-V## is fixed
BOM
model
3.6.12 Resource Allocations

Processes.name Text Name of the processes (with the version included)
Resources.name Text Name of the resource
Min Batch size Number 0
Rate Number Speed per hour (units per hour)
Rate multiplier Number 1
Unit Text TNE/HR
Unit cost Number Cost per hour
Extra cost Number Cost for extra hours
model
Only relevant resource allocations should be imported into AP.
3.6.13 Formulas
The formula is used in both variable-BOM setup and the fixed-BOM setup.
With a fixed BOM setup (version V01 V99) the outflow quantities and fixed
inflow quantities are used.
This BOM only has the ingredients which should be used in the correct
quantities on there
There is no possibility the BOM can be variable and fixed at the same time
The variable BOM (version V00) (the combination of the ingredients is

calculated based on parameters / specifications) also has formula records:
The variable BOM has all possible ingredients without mentioning a fixed
inflow Q. The used inflow quantity is calculated with the use of parameters,
specifications, recipes and recipe allocations.

Processes.Name Text Name of the process (=header of the BOM)
Fixed Inflow Factor Number If inflow records: draw quantity related to 1, in case of a
variable inflow quantity = 0
Outflow Factor Number If outflow record: 1
Unit Text Unit of measurement
model
The formula can be multilevel. This means the outflow of one formula
structure is the fixed inflow of the other. Intermediate product can be used in
various Formulas and outflow products can have inflow from more that one
other intermediates.
Once a hub starts to use variable BOMs, all BOMs (also the fixed ones) are
entered and maintained manually. If not there is a link to SAP. The place to
store the manual fixed and variable BOM will be is described in the integration
design
The formulas should only contain active, critical materials. Only relevant
formulas should be imported into AP.
3.6.14 Parameters
Name Text Name of the parameter
model
This is manual data in the database. It is not able to extend it after go live.
The interface will only run one time. The data will be used to generate records
for both specifications and recipes
3.6.15 Specifications
Processes.name Text Name of the process (with version)
Parameters.name Text Name of the parameter
Max inflow factor Number Between 0 and 999. E.g. if the product is 20/20/20 the N
is 20. The maximum usually is min + 2%
Min inflow factor Number Between 0 and 999. E.g. if the product is 20/20/20 the N
is 20. Usually this is a minimum
Over max penalty Number 9999
Under min penalty Number 9999
model
Only variable BOMs are in this table and contains the specifications (of N, P
and K) of the produced products (blends and aggregates)
3.6.16 Recipes
Products.name Text Name of the product
Parameters.name Text Name of the parameter (N, P, K etc)
Factor Number The factor of the parameter in the inflow. This should be
aligned with specification
model
In the database a matrix is setup to indicate raw material possibilities against

planning products and aggregates:
By indicating a possible usage of Raw Materials against an aggregate

(without possible draw quantities), the match is also applicable for the
underlying planning products and products. The grouping structure is stored
in the product group table.
Note: in MLT the aggregated product is used. Brazil has more than one
planning product per aggregator. Also packaging could be handled in an
aggregated way (where all packaging sizes are aggregated into one code). All
others have a one to one relationship where every planning product is its own
aggregated level. In the ST model (only Brazil) the planning product is
included on all levels.
Only variable BOMs are in this table.
3.6.17 Recipe Allocations

Parameters.name Text Name of the parameter (N, P, K etc)
model
Only variable BOMs are in this table.
3.7 Integration transactional data
3.7.1 Forecast
Customers.name Text Name of the customer
Forecast Q Number The forecast quantity
Bucket Date The first date in the bucket
model
In blending models this interface contains the customer forecast for Sales
Forecasting.
In global (and Italy and France) this contains the netted requirements from the
RP and AP models.
3.7.2 Orders
Transactional data Field / size Description

Order Q Number The order quantity
model
For the ST model only. This interface cooperates with the forecast interface.
The forecast interface is at aggregator level and the order interface at blend
level. This has as a result the problem that the forecast cannot be
consumed by the orders. Therefore in week 1-4 the orders are leading and in
week 5-13 the forecast is leading. Only orders/forecast with demand will be
imported in the master data
3.7.3 Budget
The budget is firmed on 2 locations:
A production budget in product@location

A sales budget in customer allocation
With a workflow this data is updated after the budget has been agreed. The
workflow copies the planning data from the budget round into the budget
property which can be used in operational plan as reference.
3.7.4 History figures
Hist Sales
Hist sales Q Number The realised order quantity
model
Hist Purchase
Suppliers.name Text Name of the supplier
Hist purchase Q Number The realised purchase quantity
model
Hist Production
Hist production Q Number The realised production quantity
model
3.7.5 Stocks
Stocks
Bucket Date The first date in the first bucket
Inventory Q Number Quantity inventory
model
Negative stocks should be corrected before the solver runs. Negative stocks
are imported but indicated in an exception plansheet. The users responsibility
is to solve the stock issues before running the solver. This could be done by
either setting the negative stock to 0 or correcting the other value (which
should be too high).
In the models other than blending, negative stocks are common and allowed.
The fact that the solver is not used makes this possible.
In Transit Stocks
Transfer.name Text Name of the Transfer (=route + product)
In transit inventory Number Quantity inventory
Q
Bucket Date The first date in the first bucket
model

Transfer in.name Text Name of the Transfer (=route + product)
Receipt Q Number Quantity inventory
Bucket Date Receiving date
model
Negative stocks should be corrected before the solver runs. Negative stocks
are imported but indicated in an exception plansheet. The users responsibility
is to solve the stock issues before running the solver. This could be done by
either setting the negative stock to 0 or correcting the other value (which
should be too high).
In the models other than blending, negative stocks are common and allowed.
The fact that the solver is not used makes this possible.
3.8 Integration report data
This chapter will be included in a later stage of the project when the reporting
requirements are known.
3.9 Planning Workflows
In the budget phase the workflows are not established. There will be one-off
workflows to generate a certain behavior or to change mass data.
In the MLT blending model there will be a series of workflows to support the
frequent planning run.
a workflow to set the calendar correct. There will be a budget workflow

(to expand the calendar with one full year). And a workflow to move
the calendar forward
a workflow to import all master data. These interfaces contain all
records. There is an option to empty the model first or to update
records and introduce new records
a workflow to import all transactional data. The workflow should be in
balance with the availability of data. If the ERP interface runs once a
month, there is no possibility to see daily updated information.
Furthermore the whole set should run. If there is only a new openings
balance, but the forecast is unchanged it has a out of sync situation.
a workflow to solve a plan
a workflow to publish al plan
In the ST blending model there will be a series of workflows to support the

analysis of the MLT plan on a more refines way.
a workflow to update the MLT calendar with ST information

a workflow to import extra data en set certain data (e.g. the
aggregated stocks) to 0. Also the use forecast and use order
properties are set correct. For both transactional and master data
a workflow to solve the plan (possibly in parts)
In the MLT global (+FR + IT) model there will be a series of workflows to
support the frequent planning run.
a workflow to update the calendar. This will have a different setup

compared to the blending models. The number of locked history
months increases
a workflow to import master data.
a workflow to import transactional data (stocks + demands from the
AP and RP models)
a workflow to publish internally (to overall model and e.g. from NPK to
CN model)
a workflow to publish the data to the database
When testing the model more workflows will be created to enable smooth and
easy operation of the AP model.
The global model can easily be expanded with solver workflows. It is a

recommendation to have at least one person in the organization with modeler
skills. This person should follow AP modeling course and is in the end
capable of defining workflows, solvers and can make (minor) changes to the
modeler. He/She is also capable of advanced error follow up and analyzing
problems when operating in a live environment.
A workflow is used to update the budget figures after the budget has been
agreed. This workflow copies the planning data from the budget round into
the budget property which can be used in operational plan as reference.
3.10 Plan Sheets

In the current models we have a number of predefined plan sheets:
01. demand view

02. inventory view
03. capacity view
04. distribution view
05. cost view
06. supplier view
07. initialize view
08. process view
09. transport view
10. recipe view
11. global view
12. specification view
In the global model all the variable BOM plan sheets are not available (10,
12). The plan sheets are stored in the model. And can therefore be specific
per model. Users should be able to change and create plan sheets. But since
there will be a template model stored which can be used in case of
emergency, the changes need to be applied in 2 models (in the running
model and the template model)
4 Roles & Responsibilities Clarification
This section offers clarifications about the planned input of the Infor team in
relation to specific project deliverables.
4.1 Data collection

In order that AP takes planning decisions based on correct data, Yara will
ensure the timely collection of high-quality data. Infor will assist Yara in this
task by defining data requirements. These data requirements are visible in
this document and have been translated into integration requirements, stored
in the integration design.
The data collection in the Budget process will be a manual one. With the use
of spreadsheets we can upload information directly into AP.
In the second phase of the project, the spreadsheets will be replaced by

interfaced information where the original spreadsheets will serve as a
reference to see if the data is interfaced and possibly translated correctly from
the ERP systems.
Data collection also contains a data cleaning step. The manual data gathering
in spreadsheets will identify certain steps where data appears incorrect.
Correctional actions should take place to improve the data quality.
When doing the testing of the (AP) system, not all data has to be available,
dependant of the type of test
Unit test test with a limited test set the separated functions of each
system
Integration test test with a limited test set all flows from start to finish
Mass data test / User acceptance test test with a full data set all
functions of the system
4.2 Integration
Initially (at the Budget phase) the integration will have a lower priority. Data
that is available will be used via the integration hub. But it is foreseen that
other data will be interfaced through spreadsheets.
The integration that is described in the integration design document describes

the integration to be in place for the optimization and balancing phase of the
project.
4.3 Objective functions fine-tuning

The solver contains a number of objectives. These objectives will have a
default value and need to be set to company specific values to give the
correct result. This fine-tuning is done in the test phase of the project. If a
result with a number of resources gives a non expected result the height of a
penalty or the weight of the objective can be changed to change the solving
behaviour. This should not be a task in a live environment. If a situation asks
for different behaviours (e.g. in the summer a different behaviour than in
winter), it is better to create two predefined solvers than changing the
objective weights.
4.4 Planning processes

The planning process will be worked out in a later stage of the project
(between September and January 2008). The initial budget process will have
a similar type of process:
1. create a sales plan in Sales Planning

2. export the sales planning into AP for the blending hubs and RP for the
rest of the markets
3. run the AP blending model (solve) (and the RP calculation)
4. export the netted requirements (from AP and RP) into the database
5. read all requirements in the global models and the Italy and France
model.
6. match production with sales, push material into the market or shortfall
on some requirements. Add / indicate global TPP capacity. Handle
internal capacity consumption.
7. export the results internally to the all model
8. export the results to the database
9. import the scheduled deliveries in the AP blending models and RP
10. resolve to replan the purchase problems
11. for Brazil: do the feasibility check in the ST model and plan weekly
vessel schedules
12. export the foreseen order promising back to Sales Planning
After exporting everything to the database also the report section is updated.
4.5 Plan sheets and queries

The users should be able to change and update plansheet & queries. Plan
sheets is described in 4.10. The plan sheet can contain queries which create
a sub selection of all available records (e.g. show all records with lost sales).
The queries are the starting point for an analysis on exception.
Although the queries are in essence simple, an experience AP user who has
received a modeling course is very well capable of expanding the set queries
or developing new applications
4.6 Reports
Reports in AP are all handled via the database. In a later stage of the project
a number of tables will be defined for various areas of reporting:
Stock
Production
Purchasing
Resource utilization
Sales results
Transport
All sets of data will be stored in the database with a number of identifiers:
Profile
Publish date (or date of first bucket)
Model type (ST/MLT)
Scenario identifier
As long as the new set of exported data is not available in the set of tables,
the records will be inserted as new records. If the set is already available the
database the old publish will be wiped and replaced with a new set of records.
These tables make it possible to create reports in BiW or (via ODBC) in Excel
or Access.
4.7 Simulation scenarios

As mentioned in the previous chapter, each export will have a scenario
identifier. When starting a new scenario this identifier is asked and stored in
the model. Each record in the model will have this identifier. Furthermore is
the model saved as a separate model.
When exporting the data, everything is marked with the scenario identifier.
Only the BASE scenario is handled in the rest of the supply chain.
With the use of tools outside AP a comparison between scenarios (both

stored in the same table) can be made.
There is no physical maximum on the number of scenarios. Although more

than 10 scenarios is not recommended since this is just too much to compare.
4.8 Training, testing and user manuals

The testing in the different test runs is performed by Yara key users and
supported by Infor consultants. For these tests scripts are created by Yara
key users to test their challenges from the business. In the testing it is the
goal to streamline the calculations and setups of the various AP models in the
landscape and to streamline the communications with other elements in the
solution map.
The result of all the testing done in the various rounds is to:
To get a correct calculation

To find out the correct way of handling the model supporting the Yara
S&OP process and described in user manuals
The main input for the user manual will come from key users supported by
Infor and the main input for the technical manual will come from Infor
supported by the key users. This user manual will serve as input for the
knowledge transfer from key users to users.
5 Planned Testing Steps
There are 2 (and in Brazil 3) testing cycles.
1. the budget MLT phase

2. the optimizing and balancing MLT phase
3. the ST phase in Brazil
Each testing schedule will have 3 testing periods. The pilot testing, which
contain of a unit test and a integration test. And a User Acceptance Test
5.1 Pilot testing

In the unit test a small dataset is used to test the individual components. This
could be an integration or a part of the AP model. Each test is described what
is tested and what should be the foreseen output, and documented. Minor
changes to the model are usually handled after this set of tests. Followed by a
retest after the change
The integration test runs with the same small dataset and is run from start to
end. Each model / application / dataset is linked to other components and
especially the cooperation of all individual components is important. Again
test scripts and documenting the results is vital in this test set
5.2 UAT testing

The UAT test runs with (preferably) a full dataset and covers all elements of
all systems. All systems work in the correct sequence. The result of the UAT
test is usually a GO / NO GO decision. In that decision the users match the
design with the actual result in the model(s). Therefore it is vital to signal and
document errors in this document or changes to the design.
Document control
Version Changes Date Author

0.1 Draft version 10 April 2007 Maurice Ham
0.3 Updated draft version 23 April 2007 Maurice Ham
0.5 Updated draft version 23 May 2007 Maurice Ham
1.0 Initial released version 25 May 2007 Maurice Ham
1.1 Updated version released to key 8 June 2007 Maurice Ham
users
Table 2: Document control
Acronyms and abbreviations
Explanation
AP Advanced Planning
DP Demand Planning
DF Demand Forecasting
RP Requirements Planning
SP Sales Planning
Table 3: Acronyms and abbreviations
List of Tables and Figures
Table 1: Document approval ..................................................................................... 2

Table 2: Document control ...................................................................................... 62
Table 3: Acronyms and abbreviations ..................................................................... 62

Design Advanced Planning-Infor

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Design Advanced Planning-Infor

Caricato da

Copyright:

Formati disponibili

Detailed Design Advanced Planning

Infor Supply Chain Planning

YPOD Detailed Design Advanced

This document should be approved by:

Name Function Signature Date

Linda Bergoens Yara Project Manager

Jo de Vliegher Business Consultant

Jos Winters Yara Integration Specialist

Tony Player Infor Project Manager

Stephen Hainie Infor Integration Specialist

Geoff Locket Infor Solution Architect

Maurice Ham Infor Solution Architect

Table 1: Document approval

In chapter 3 the AP model itself is explained. First of all in model structure

2 YARA SUPPLY CHAIN CHALLENGES / KEY SUCCESS FACTORS ...............7

3 DETAILED SCOPE ........................................................................................... 13

3.6.16 Recipes ...................................................................................... 52

ACRONYMS AND ABBREVIATIONS .......................................................................... 62

LIST OF TABLES AND FIGURES................................................................................ 62

This document describes the design of Advanced Planning within Yara.

as optimizer in 3 blending regions: Brazil, United Kingdom and South

Whenever in this document the global model is described, it is applicable for

Furthermore is there already as structure on the cooperation of the various

2 Yara Supply Chain Challenges / Key Success Factors

Requirements Planning initially involves the process of netting requirements

Key requirements for Requirements Planning are:

of products for that warehouse), and to drill down channel by channel

options to allow for the provision of aggregated requirements and

For blending units, the process of Requirements Planning is fundamentally

Production capacity, which covers both blending and bagging

o In transit stocks. E.g. the stocks to arrive in the near future

Key requirements for blending planning are:

Internal (OPP) or external (TPP) blending. JV blending exists also (in

The first quarter split in 3 months of 4-4-5 weeks

Key requirements for Global Planning are:

Ability to drill down from global production site to Legal Company /

requirements are, taking into account historical months where

This chapter gives an overview of the AP model, including a class diagram,

Market Focus Description

with G-OPP, G-TPP and L-TPP

There are two types of AP models

Model type Description

3.1 Class Diagram

There are 2 model templates available:

Market Focus Model to be used

be entered manually in integration layer when a variable BOM is used in the

This manual editing of variable BOMs will be supported by a hierarchical

as an end product and as an intermediate product dependant on the time and

Market Focus Number of products / aggregates

Note: An aggregate is a model blend representative for a group of blends.

MLT model: Monthly buckets; 6-18 months in advance.

Optimizing project phase In the optimizing phase planning products (for

In the optimizing phase the network on the blending hub locations is

Market Focus Phase Locations

Balancing One location per site

Production could be bagging, blending, diluting, main production or local

It is a choice to model the customer relation with optional locations. These

Market Focus Customer Location structure

See 4.1.6 for the explanation of customers.

The supplier relationship functions with an intermediate location for OPP

See 4.1.4 for an explanation on suppliers.

The Minimum Service Level is a hard constraint to force certain products to

Budget not in use

Arbitration reference only