ASPECT4 Logistics A Presentation of Release 9.1

ASPECT4 Logistics
A Presentation of
Release 9.1
The release 9.1 of ASPECT4 Logistics contains many functional
improvements to the commerce-related parts of the system.
Many development projects ensures a smooth change-over to
ASPECT4 Logistics for customers previously running the commerce
module of ASPECT4. The major part of the features relate
to outgoing logistics, e.g. price and discount addition, dynamic
rearrangement and transport management. For incoming
logistics the enhancements include a cockpit for receiving supplier
invoices. Some of the general improvements is the ability
to implement alternative cost prices – and the opportunity to
design your own screen display in eXposer.

2
Contents
About ASPECT4 Logistics Release 9.1 .......................... 3
Outgoing Logistics
Dynamic Rearrangement ............................................ 4
Set up Dynamic Rearrangement .............................. 4
Simulate Ability to Deliver ....................................... 5
Dynamic Rearrangement and Order Processing .......... 6
Log of Rearrangements ........................................... 7
Manual Reprioritising of Orders ................................ 7
Dynamic Rearrangement and Time ........................... 7
Sales Prices and Discounts ......................................... 8
Definitions ............................................................ 8
Master Records ...................................................... 8
Company Parameters ............................................. 9
Other .................................................................. 12
Master Data Maintenance ....................................... 12
Rules and Restrictions ........................................... 15
Functions ............................................................. 15
Transport Management ............................................. 17
How Do Transport Requirements Occur? .................. 18
Planning a Transportation ....................................... 19
Completing a Transportation ................................... 20
Blanket Orders ........................................................ 23
What is a Blanket Order Agreement ........................ 24
Relationship between Blanket Order Agreements
and Blanket Orders ........................................... 24
Customer-agreed Minimum Stocks .......................... 24
Distributing a Blanket Order Agreement Line
to Periods ......................................................... 24
Availability on Derived Orders ................................. 25
Availability on Internal Trade .................................. 26
Improved Call-off Management ............................... 26
Improved Folllow-up Options on Order Hierarchies .... 27
Integration to Sales Budget .................................... 27
e-Export ................................................................. 27
Receiving Delivery Proposal via Adaptor DELFOR ......... 28
Prerequisites and Delimitations ............................... 28
Minor enhancements – outgoing Logistics ................... 29
Copying order lines ............................................... 29
Entry of a numerical customer number .................... 29
EAN number as customer item number .................... 29
Selection by status ................................................ 29
Wholesaler Group ................................................. 29
Price Setting Customer .......................................... 29
Allocating pallets and packages ............................... 30
Extended control code scanning .............................. 30
Customs Tariff on Proforma Invoices ....................... 30
KID Number on Invoice ......................................... 30
Inward bound Logistics
Cockpit for Receiving Invoices ................................... 31
Cockpit for Capacity Overview ................................... 32
Check against Accumulated Capacity .......................... 33
Changed Control of Breakdown of Sales Plan ............... 33
Material Check in Fine Planning .................................. 34
Backward Dating in Fine Planning ............................... 34
Selection by Production Model Groups ........................ 34
Missing Data for POPX-TS .......................................... 34
Max size of Data Queues ........................................... 35
Function Groups in Connection with
Company Parameters A9145 and A9141 ................. 35
Workflow for Approval of Supplier Invoices ................. 35
Cross-Disciplinary Enhancements
New Standard Cost Methods ...................................... 37
Product Configuration during Sales Order Registration .. 37
Configuration of Item Set .......................................... 38
Item Number and Name ........................................... 38
Copying in Relation to Item Features .......................... 40
Print Options in 'Calculate Costs for
Purchase Items' (9231) ............................................ 40
Restructured Financial Interface ................................ 40
Technical Enhancements
STFE Processing under eXposer ................................. 41
Shortcut F4 ............................................................. 42
External Documents in DocManager ........................... 42
Call of PC Applications by using Shortcuts ................... 42
Implementation
Implementing Release 9.1 ......................................... 43
Preparation ............................................................. 43
Receiving and Installing Packages .............................. 43
Environment Setup .................................................. 44
Upgrading Test Environment ...................................... 44
Upgrading Operating Environment .............................. 45
Upgrading Test/Operating Environment ....................... 46
Comments .............................................................. 46
Triggers .................................................................. 46

About ASPECT4 Logistics
Release 9.1
This new release of ASPECT4 Logistics contains many functional
improvements to the commerce-related parts of the
system. Many development projects have been carried
out in order to ensure a smooth change-over to ASPECT4
Logistics for customers previously running the commerce
module of ASPECT4.
The major part of the innovative features relate to outgoing
logistics, e.g. price and discount addition, dynamic rearrangement,
and transport management. For incoming
logistics the enhancements include a cockpit for receiving
supplier invoices.
One of the general improvements is the ability to implement
alternative cost prices. Besides, you now have the
opportunity to design your own screen display in eXposer –
read about combo boxes, field groups and radio groups in
the chapter introducing technical improvements.
We are proud to announce that the first cockpits developed
are now included in the standard system. We hope that
you will all benefit from them.
This release description is distributed electronically, only. If
you need to have a paper edition, please print this file.
If you have not already upgraded to release 9.0, we recommend
that you upgrade directly to release 9.1.
For all of you who are already running release 9.0, we recommend
that you upgrade to release 9.1 to benefit from
the enhancements described in this document.
3

The purpose of dynamic rearrangement in ASPECT4 Logistics
is to ensure that customers are served with goods to
the best ability and in a prioritised order. Any change in the
business’ supply situation will also be reflected directly on
the sales orders by their delivery dates being changed automatically
according to defined parameters.
Dynamic rearrangement will allocate sales orders based on
the supply situation, i.e. based on stockholding and
planned receipts from purchase and production. Dynamic
rearrangement does not solve any tasks in connection with
improving the company’s supply situation.
Dynamic rearrangement n ASPECT4 Logistics is implemented
for normal sales orders, i.e. firm orders. It functions
within one warehouse area and not across warehouse areas.
The below new applications in ASPECT4 Logistics deal with
dynamic rearrangement:
6360 Display Arrangements
6260 Continuous Rearrangements
6263 Stop Continuous Rearrangements
6264 Rearrange All Items
6190 Work with Order Priorities
Set up Dynamic Rearrangement
Setting up dynamic rearrangement is a comprehensive
task. In order to apply dynamic rearrangement, you must
carry out settings within the following fields:
• Setup of system parameters
• Setup of triggers
• Application setup for order processing
• Start of applications required for using dynamic
rearrangement
System Parameters for Dynamic
Rearrangement
The system parameter REDISP is new in ASPECT4 Logistics
and is aimed at managing dynamic rearrangement.
As it appears from this system parameter, you can apply
three different elements for prioritising customer orders: A
customer grouping, a priority, or an order registration time
stamp. If you apply a customer grouping for the prioritising
of customers (e.g. A/B/C customers), you must also
specify the customer group for the classification.
4
Dynamic Rearrangement
OUTGOING LOGISTICS
If you prioritise the customers on a first-come basis, exclusively,
you only apply the time stamp as the priority.
As you will see from the parameters, you can also control
the maximum number of splits for an order line (corresponding
to the number of part deliveries). And you can
control that a particular minimum percentage of an order
line must be deliverable for the delivery to be of interest
altogether.
Besides, we recommend that you use a special setup to
control which orders to include in the arrangement. A typically
setup could be:
For purchase and production orders, you will normally include
confirmed purchase orders and production orders
(possibly controlled by status). For stocked items, all locations
and all consignments should be marked as included.
The below system parameters are new parameters resulting
from implementing dynamic rearrangement:
DISPBASE: Arrangement based on (system values)
REDIAARS: Cause of rearrangement (system values)
REDILBGR: Log limit for rearrangement (excludes causes
from the log).

Triggers
Dynamic rearrangement is based on triggers to the follow-
ing files:
• Stockholdings (LABEREG)
• Sales order lines (ORDLREGS)
• Purchase order lines (ORDLREGI)
• Production order lines (PROLREG)
You set up triggers via application 'Work with Event Descriptions'
(9188) and application 'Work with Onward Processing'
(9189). Below we describe a typical setup of these
applications.
Example of setup in 'Work with Onward Processing' (9189):
The specific setup of for example the file LABEREG may
look like this:
The general overview of which triggers are added to the
files is provided by the application 'Work with Event Descriptions'
(9188):
Activating Rearrangement in Order Processing
In order to apply dynamic rearrangement in order processing,
the following parameters must be set up in for example
'Work with Firm Order Lines' (6524):
Code value of 'Check available holding' must be 3.
So far, you have only had the code options 0 and 1. If you
select 3, the arrangement screen will appear if the order
either cannot be delivered directly from stock or the delivery
time of the order line is later than the delivery time of
the item.
Items with an arrangement code smaller than 7 will not be
included in the arrangement.
Active Applications for Dynamic Rearrangement
The application 'Implement Onward Processing' (9272)
must be active, and so must the application 'Continuous
Rearrangement' (6260). We recommend that you manage
this via application 'Work with Job Definitions' (9176).
Simulate Ability to Deliver
The ability to deliver can be viewed in application 'Display
Arrangement' (6360). Specify the item number, customer
number, and warehouse area. If you apply only the time of
registration as the priority in the arrangement, the customer
number is of no significance. If the customers have been
prioritised either by a customer group of by their priority,
the delivery situation depends on the customer’s priorities.
5

An arrangement screen may look like this:
It appears that the delivery time is 7 days and that the enquiry
is for 500 pieces. 50 pieces can be delivered from
stock. 200 pieces can be delivered when items purchased
have arrived on 17.10. The rest can be delivered according
to the item’s standard delivery time of 7 days, i.e. on
17.10.
Managing Planned Receipts
As always in ASPECT4 Logistics, a precise management of
the dates of expected receipts is significant to the credibility
of the arrangement overviews. The significance is even
greater when you apply the dynamic rearrangement facility.
A planned receipt is always at least one day ahead. Hereby
you have provided for time to handle the goods.
Managing Delivery Times
The procurement time of an item is stored in the purchase
information. If this information is not available, the system
will get the standard delivery time stored in the item’s
sales information. Based on experience it is difficult to keep
supplier delivery times updated even if they can easily be
maintained in ASPECT4 Logistics. If a purchase order has
been confirmed at a time later than the item’s delivery
time, the dynamic rearrangement facility will automatically
extend the delivery time for that item.
Dynamic Rearrangement and
Order Processing
If an order line cannot be completely delivered from stock,
and if it must not be delivered at a time later than the
standard delivery time, you apply the same arrangement
screen as displayed above under "Simulate ability to deliver".
In order to provide a true picture of an order line’s
delivery situation, we have introduced a new status code:
25 = Available. An order line can have status 25 if it is
available either against stock or against a stock receipt
(purchase or production).
You have a number of options for the order processing in
the screen display:
1. Best possible. If you select this option in our example,
the order line will be split into three order lines according
to the delivery situation. All order lines will have
02.10 as the requested delivery date. If the goods can
6
be delivered at an earlier date, the order lines will automatically
be moved in time correspondingly.
2. You agree with the customer that all 500 must be delivered
on 17.10. This is achieved by marking 'Delivery'
next to the date 17.10. An order line will be created
with 17.10 as the delivery date and 17.10 as requested
delivery date (an order line will never attempt to deliver
prior to requested delivery date).
3. You agree with the customer that 50 pieces must be delivered
now and the rest on 17.10. This is achieved by
entering 50 next to 02.10 and marking 17.10 for the
rest. The arrangement screen will then appear as shown
below. It will result in two order lines with the delivery
dates 02.10 and 17.10, respectively. Requested delivery
date is set to the same date as the delivery date.
4. Many other combinations may be agreed with the customer.
Only the maximum number of splits must not be
exceeded, and a delivery must fulfil at least the percentage
from the system parameter REDISP (except for the
last delivery).
What Happens to the Order if Something is Changed?
Let us assume that the above example has been created as
an order. Now, if there is a stock adjustment of -50, the
following events will occur:
1. The order line with delivery on 02.10 can no longer be
delivered. It will therefore be split into two order lines.
The original order line is reduced to 0, and a new order
line of 50 on 17.10 is created. This is caused by the fact
that it was agreed with the customer that 50 pieces
must be delivered on 02.10 and the first possible delivery
date is 17.10.
2. The order line for 17.10 is kept unchanged.
You may imagine many scenarios of events. We recommend
that you simulate any relevant scenario in order to
clarify how the arrangement will react in particular situations.
Basically, the following rules apply:
• An order will never attempt to deliver prior to requested
delivery date.
• An order line will never be split into a lager number than
that of the system parameter REDISP. If an order line
has been split manually in the arrangement screen, the
split lines can be split again, still considering the number
of splits allowed in the system parameter REDISP.
• An order line will never allow deliveries below the percentage
of the smallest delivery, cf. system parameter
REDISP (except for the last delivery).

Order Entry via EDI or BusinessConnector
If orders are received electronically, they will be processed
according to the 'Best possible' option.
Procured items and direct deliveries
Procured items and direct deliveries are not included in the
rearrangement processing in the usual way. For the order
policies IS, IO, PO, and IG, order lines are automatically
created in status 30, meaning 'prioritised'. This means that
they are actually not included in the rearrangement and
thereby they do not risk being split.
Log of Rearrangements
The changes made by dynamic rearrangement are of
course being logged. You can work with this log via application
'Work with Rearrangement Log' (6135). The log
shows what changes have been made to the order lines.
Based on the log you may choose to select, for example,
that you must send a new confirmation to the customer.
Manual Reprioritising of Orders
If you need to override the automatic allocation of items,
you can override via application 'Work with Order Priorities'
(6190). By selecting an order line in the application, its
status can be changed to 30, which is 'prioritised'.
Log of rearrangements
Dynamic rearrangement may be disturbed by the use of
reservations and allocations in the order processing. We
therefore recommend that these options are removed from
the order processing applications, i.e. do not allocate items
until they are picked from stock. We also recommend that
you restrict access to application 'Work with Order Priorities'
(6190).
Dynamic Rearrangement and Time
The fact that time passes cannot be perceived by the trigger
settings on the files. Therefore, once a day you must
reallocate all items. This is performed via application 'Reallocate
All Items' (6264).
7

To provide an overview of the sales price and discount addition
in ASPECT4 Logistics we have chosen to include in
this document a full description of the opportunities of
managing prices and discounts. Thus not only new features
are described below.
Managing sales prices and discounts implies:
• Management of price information and conditions.
• Communication of price information and conditions.
• Retrieval of current prices and prices conditions when
creating orders.
• Documentation of divergences, if any.
Facilities for the above-mentioned tasks include:
• An item may appear on various price lists.
• A price list my appear in various currencies.
• Price lists may be limited in time.
• Customers can be connected to a particular price list.
• A price list may be limited to one particular customer.
• Both prices and discounts can be processed.
• Quantity-dependent prices and discounts can be processed.
• Feature-dependent prices can be processed.
• Separate financial posting of the individual price elements.
Definitions
In ASPECT4 Logistics there are several concepts in the field
of 'Sales Prices and Discounts'.
Below you will find a definition of some of them.
Price - (basic price) is the basis on which the sales price is
determined.
The basis can be modified by addition/deduction (corrections)
and/or by granted discounts.
Discount - is the amount/percentage by which the sales
price is reduced when determining the net price.
A discount will always be specified and will appear as a
specified amount in quotations, order confirmations and invoices.
Price discounts in currency differ from price discounts in
percentage by being absolute variables as opposed to relative
percentages.
Correction - is an addition or deduction by which the basic
price is modified.
The correction will not appear as a specified amount in
quotations, order confirmations and invoices.
Price corrections in currency differ from price corrections in
percentage by being absolute variables added or deducted
as opposed to relative percentages.
8
Sales Prices and Discounts
Total discount - is a discount granted for the entire order.
It will be specified on the sales order header and will be
initiated with the value from the customer master records.
It will be calculated as a percentage of the order total,
however adjusted for the prices, discounts, corrections,
and order lines that have been deselected from total discount
calculation.
Chain discount - is a discount that can be granted in several
levels.
Discount agreements can exist in a random number of levels.
Thus it can be established when one agreement "replaces"
another agreement, and when the found agreement
is an "addition" to other agreements.
Discount calculation have many details, one of which is the
"level" of net amount on which to base the discount calculation;
for example: one discount agreement triggering 10
% discount and a second discount agreement triggering a
further 5 %. In this case the discount will be granted from
the net amount that was already subject to discount calculation.
Master Records
Customer File
Customer master records include the following fields on
which sales price fixing and discount are based:
Price Setting Customer No - provides the opportunity of
controlling price fixing and discount by the number specified
here. Thus the price addition control is flexible for each
customer (not tied to customer or debtor). The pricing customer
number may be applied in case of a wholesale society
determining the price.
Price List Number – is used for determining which price the
customer must pay when purchasing. If the field value is 0
(zero), the customer will buy at basic sales prices, and if it
is 1 (one), the customer will buy at price list prices. The
normal situation is 1.
Line Discount Code – determines whether the customer is
entitled to a price discount.
Quantity Discount Code - determines whether the customer
is entitled to a quantity discount.
Discount Group – is the price and discount group to which
the customer belongs. It provides the opportunity of connecting
customers to a common price list. It was applied
before the pricing customer concept was introduced.
Total Order Discount Percent – for customer.

Item File
Item master records include the following fields on which
sales price fixing and discount are based:
Discount Group for the item when selling.
The discount group specified in the sales item’s master
records is used when adding corrections and discounts.
Besides, it is possible to connect the item to a number of
supplementing item discount groups. These groups will
only be applied when calculating discount (not when calculating
corrections). The calculation sequence is specified in
the system parameter RABATVAR.
Line Discount Code – indicates whether a price discount is
granted on the item.
Quantity Discount Code - indicates whether a quantity discount
is granted on the item.
Company Parameters
Below you will find the company parameters influencing
sales prices and discounts.
Discount Agreement (RABATAFT)
Level: The level of the discount agreement. 0 is the highest
level, 9 is the lowest.
Discount Agreement Id: The entry basis. The discount
agreement Id is applied when posting chain discount.
Discount Basis: A discount that has been manually granted
to a particular order line will always override any other discount
calculation. This means that for example a collective
discount will not be added to the line as well. However, the
quantity on the line can be part of the total quantity basis
applied when determining the collective discount rates for
the entire agreement.
Collective Discount: When calculating discounts at a group
level, it must be specified whether the discount only applies
to the individual order line or whether it comprises all
order lines on the order belonging to the current item discount
group and discount agreement.
Unit Type: The type indicates whether the unit on the current
agreement is a unit of quantity or a unit of amount
(currency code).
If it is a unit of quantity, the order quantity will be converted
to the specified unit when calculating the discount.
If it is a currency code, the gross amount of the order line
will be used when searching for amount limits. If an agreement
in order currency has not been created, an agreement
in system currency may be applied. See the system
parameter SALGPRIS.
Unit: The unit (alternative unit) in which quantity limits are
specified in connection with discounts in the current agreement.
If the unit is a currency code, the limits specified are
amount limits in the current currency. Please note that if it
is a currency code, the gross amount of the order line will
be used when searching for amount limits.
Info on Next Quantity Limit: A percentage controlling notification
of a further discount potential. If a further discount
is possible and if the current quantity basis differs less than
the specified percentage from the next quantity limit, the
assistant dealing with the order will be notified. Notification
will occur when the line processing has been completed or
on request. If the value is 0, there will be no automatic information.
Manual Discount: A discount that has been granted manually
on a particular order line will always override any other
discount calculation. This means that for example a collective
discount will not be added to the line as well. However,
the quantity on the line can be part of the total quantity
basis applied when determining the collective discount
rates for the entire agreement.
Sequence Number: This is the calculation sequence number
for the discount agreement. When calculating sales discounts,
the individual discount agreements will be processed
in the sequence specified here.
Next Sequence Number: If a discount has been granted in
the current discount agreement, discount can be suppressed
in one or more succeeding discount agreements.
If the next sequence number is greater than zero (and
greater than the current calculation sequence number),
subsequent discount will continue from the sequence number
specified here.
9

Price and Discount Groups for Customers
(RABATKUN)
Possible Alternative Price Group: Alternative price group is
applied when searching in the price list after an unsuccessful
search via the primary customer price/discount group.
Hereby it is possible to use different groups when searching
prices and searching discounts, respectively. This is relevant
if you have rather many discount potentials, but only
few price lists.
If the field is blank, the alternative cost group is not included
in the search.
Discount Level Information (RABATNIV)
Processing Code: The processing code determines how the
discount must be granted.
The discount can be granted irrespective of other discount
potentials within the current discount level or, as an alternative,
it can replace other groups that would produce a
lower rate.
Besides, you can specify whether the discount should be
granted when a manual price has been entered on the order
line.
10
Discount Groups for Items (RABATVAR)
Total Disc on Items in Group: Must lines on items in this
group be included when calculating total discount (invoice
discount)?
EDI Discount Code: The associated discount code submitted
via EDI.
Sales Pricing (SALGPRIS)
Select by check mark the combinations to be applied in the
sales pricing:
Sales Price by CustNo-ItemNo
Sales Price by CustGrpN-ItemNo
Sales Price by Blank-ItemNo
Complete Feature/Option Spec: Sales pricing of feature
items with complete feature/option specification.
Addition/Deduction Features: Sales pricing of feature items
with addition/deduction for the feature determining the
price.

Sales Price Corr in Currency: The code determines if and
how sales price correction in currency is applied. Valid
codes are:
0: Sales price correction in currency is not applied
1: Sales price correction in currency is applied
2: Sales price correction in currency is applied if a sales
price correction in percent does not exist
Sales Price Correction %: The code determines if and how
sales price correction in percent is applied. Valid codes are:
0: Sales price correction in percent is not applied
1: Sales price correction in percent is applied
2: Sales price correction in percent is applied if a sales
price correction in currency does not exist
Sales Discount in Currency: The code determines if and
how sales discount in currency is applied. Valid codes are:
0: Sales discount in currency is not applied
1: Sales discount in currency is applied
2: Sales discount in currency is applied, if sales discount in
percent does not exist
Sales Discount %: The code determines if and how sales
discount in percent is applied. Valid codes are:
0: Sales discount in percent is not applied
1: Sales discount in percent is applied
2: Sales discount in percent is applied, if sales discount in
currency does not exist
Basic Correction Number: This number will be applied if
there is no sales price correction for the current sales order
header priority.
Select by check mark the combinations to be applied when
searching for sales price corrections and sales price discounts.
Discount Search in System Currency: When searching for
sales discounts where the discount is subject to specified
amount limits, the search will primarily be for discount limits
specified in order currency. If such limits do not exist,
by selecting this field you request to alternatively search
for limits in system currency.
Please note: In order to avoid that discounts are in this
case granted on the basis of both agreements in order currency
and agreements in system currency, the discount
rules should be defined to the effect that the agreement in
system currency is made subject to the non-existence of
an agreement in order currency. This can be achieved by
specifying a 'Next Sequence Number' in system parameter
RABATVAR.
You should also be aware that conversion between currencies
will always be at the current rate and therefore discount
limits converted into order currency may vary from
time to time.
11

Sales Management (MODUL-3)
Price List Used: Select to apply the price list system.
Customer Object Type: Whether the ordering customer or
the paying customer must determine the price setting. In
case you apply price setting customer, you must select ordering
customer.
Price Setting Date: Whether the order entry date or the delivery
date must function as the default price setting date.
Collective Discount Used: Whether collective discount is applied
at item discount group level.
Other
In the feature file you must specify whether the feature or
the option must determine the sales price (J/N).
Master Data Maintenance
Basic Prices - Sale
12
These items of information make up the basis on which the
sales price is determined. The basis can be modified by addition/deduction
and/or by granted discounts.
Price List Identification: This is the "pointer" onto the price
list that can be created from a customer/order. The price
list identification includes:
• Customer Identification Type
• Customer Identification
• Item Number
• Cost Variant Type
• Currency
Customer Identification Type is used in order to define
which kind of customer identification is applied:
O = Object (customer number)
G = Group (customer price/discount group)
I = No customer identification (blank)
Customer identification may be:
Customer Number
Customer Price/Discount Group
Blank
Item Identification: It is a basic condition that the sales
prices can always exist per item number. Additional specification
may even be required if the business is selling feature
items. Therefore the item identification includes:
• Item Number
• Cost Variant Type (1, 2, or 3)
• Variant (5 fields of 5 characters each)
In this structure there are three types of item identification:
- Pricing irrespective of feature
(fields for feature being blank).
- Pricing with comlete feature/option specification
( in the relevant fields for feature/options you must have
the option for the feature determining the price; the remaining
fields must be blank).
- Pricing with addition/deduction per feature
(for each feature determining the price you must specify
feature and option, respectively, in the first two fields;
the remaining fields must be blank).
From Date: The date from which the price list is effective.
This makes it possible to have several versions of the
"same" price list at the same time. When setting the price,
either delivery date or order entry date is decisive for the
choice of price list. This price setting date is stored and
maintained on the order line.
To Date: The date from which the price list is no longer effective.
A price list is effective until a new one takes effect
or until the price list expires. Expired price lists thus function
as if they do not exist, irrespective of their From Date.

Unit Price: Price per sales unit (per sales price specification).
May be corrected by addition or deduction. Likewise,
different kinds of discounts may influence the final net price.
Price Correction Possible: Whether the found sales price
may be corrected by addition/deduction.
Sales Price Discount Possible: Whether a sales price discount
may be granted on the found sales price. A sales
price discount is a discount with a quantity limit equalling
zero.
Quantity Discount Possible: Whether a quantity discount
may be granted on the found sales price. A quantity discount
is a discount with a quantity limit not equalling zero.
Total Discount Possible: Whether the order line may be included
when calculating the basis of a total discount.
Price Correction in Currency
The information in this file is about additions or deductions,
if any, by which the basic price can be corrected. Addition/
Deduction are common terms describing situations of deviation,
which are always relating to and applying to an entire
sales order voucher.
Additions or deductions may be commercially based or
may be the result of an achieved customer service, e.g.
addition for prompt delivery.
Price corrections in currency differ from price corrections in
percent by being additions or deductions of absolute
amounts as opposed to relative percentages.
Correction Number: Which addition or deduction to calculate
in the particular situation. The order priority on the
sales order header is applied when calculating.
Price List Identification: This is the "pointer" onto the price
list that can be created from a customer/order.
The price list identification includes:
• Customer Identification Type
• Customer Identification
• Item Number
• Cost Variant Type
• Currency
Customer Identification Type is used in order to define
which kind of customer identification is applied:
O = Object (customer number)
G = Group (customer price/discount group)
I = No customer identification (blank)
Customer identification may be:
Customer Number
Customer Price/Discount Group
Blank
Item Identification: This includes:
• Item Identification Type
• Item Identification
Item identification type is used in order to define which
kind of item identification is applied:
O = Object (item number)
G = Group (discount group for item when selling)
I = No item identification (blank)
Item identification may be:
Item number
Discount group for item when selling
Blank
Quantity Limit: The corrections apply to purchases from
and including this quantity limit (ordered sales units).
When buying a sales unit quantity below the lower quantity
limit, quantity correction is not applied.
Valid From Date: The date from which the price list is effective.
This makes it possible to have several versions of
the "same" price list at the same time. When setting the
price, either delivery date or order entry date is decisive
for the choice of price list. This price setting date is stored
and maintained on the order line.
Expiry Date: The date from which the price list is no longer
effective. A price list is effective until a new one takes effect
or until the price list expires. Expired price lists thus
function as if they do not exist, irrespective of their From
Date.
Price Correction: Addition (positive) or deduction (negative)
per sales unit. If the item identification type is item
number, the corrections are per sales price specification;
otherwise they apply to one sales unit. The corrections are
made for the found basic price.
Sales Price Discount Possible: Whether a sales price discount
may be granted on the found sales price. A sales
price discount is a discount with a quantity limit equalling
zero.
13

Quantity Discount Possible: Whether a quantity discount
may be granted on the found sales price. A quantity discount
is a discount with a quantity limit not equalling zero.
Total Discount Possible: Whether the order line may be included
when calculating the basis of a total discount.
Price Correction in Percent
The information in this file serves the same purpose as the
information in the file of price correction in currency. Here,
however, addition and deduction are expressed by a percentage.
The data structure is the structure described in the section
about price lists, except for:
Currency is not in the record.
Price Correction is replaced by Percentage Correction.
Price Discounts in Currency
The information in this file is about discounts deducted
from (added to) the sales price when determining the net
14
price. Discounts are always specified individually and appear
specified on quotations, order confirmations, and invoices.
Discounts in currency differ from discounts in percent by
being deductions of absolute amounts as opposed to relative
percentages.
The data structure is the structure described in the section
about price lists, except for:
Discount Agreement is added in the record.
Correction Number is not in the record.
Price Correction is replaced by Unit Discount.
Sales Price Discount Possible is not in the record.
Quantity Discount Possible is not in the record.
Price Discounts in Percent
The information in this file serves the same purpose as the
information in the file of sales price discounts in currency.
Here, however, the discount is expressed by a percentage.
The data structure is the structure described in the section
about price corrections, except for:
Currency is not in the record.
Unit Discount is replaced by Discount Percentage.

Rules and Restrictions
This chapter describes the precedence of the price/discount
elements that were introduced in the preceding sections.
Calculation Sequence
Calculations are made individually, i.e. not inter-dependent,
in the following steps:
1. Basic prices - sale
2. Price correction in currency / Price correction in percent
3. Price discounts in currency / Price discounts in percent
In the company file (SALGPRIS) you must specify whether
you apply price correction in currency, price correction in percent,
price discounts in currency, price discounts in percent.
If you apply price correction and/or discounts in both currency
and percent, please also specify the search sequence
for them. It is a rule that the 'first found' will be applied for
the price calculation.
Search Sequence
In each of the above-mentioned steps, information from only
one record will be applied. The general search sequence is:
1. Customer number - Item number
2. Customer number - Item discount group
3. Customer number - Blank
4. Customer price/discount group - Item number
5. Customer price/discount group - Item discount group
6. Customer price/discount group - Blank
7. Blank - Item number
8. Blank - Item discount group
9. Blank - Blank
In case of item features, a complete feature/option specification
is searched first and then addition/deduction per
feature is searched.
By editing the company parameter SALGPRIS, the search
sequence can be limited compared to the above.
Validity
Within the above-mentioned nine search steps, valid information
will be found in respect to a price setting date. The
valid record is characterized by being the latest 'Valid From
Date' that must not, however, be later than the price setting
date – and the 'To Date' must not be earlier than the
price setting date.
Restrictions in Sales Price Corrections and Discounts
In the individual calculation steps there may be a restriction
to the subsequent calculation of addition, deduction, or
discounts. The option No (N) in this connection will always
take precedence over a subsequent Yes (J) in later calculation
steps.
Please also note the following circumstances:
• If the option 'N' was selected for line discounts on the
price agreement, this will apply to all discount groups.
• If a discount has been specified at item number level,
discounts will not be retrieved at an item group level.
• If just one of several discount options at an item group
level has the option 'N' for 'Total Discount', this will override
any other discount groups’ total discount specification.
Functions
Work with Price Lists
You can work with basic prices, price corrections, and price
discounts. You can make queries for "complete" price lists
where gross price, gross price after price correction, and
net price will appear once you have entered a customer
number, item number, feature option, quantity, price setting
date, and correction number, if any.
Working with price lists includes a copy facility. You can
copy to another validity date or to another price list identification.
You can adjust prices by using a specified index. Besides,
you can adjust sales prices based on standard cost price,
simulation price, or basic sales price. When based on standard
cost price or basic sales price, you can even choose
between new or current prices. When adjusting prices, you
can apply the item’s profit percentage, index, or constant
addition. And you can define rules for rounding off.
Print Price Lists
By defining a number of parameters, you will have the opportunity
to print price lists with a user-defined layout. In
addition to printing the price list onto paper, you can print
it to a file that you can send to a CD ROM catalogue, to a
printing company, or to other reprocessing business.
Work with Sales Orders
The price lists are used for suggesting a unit price for the
individual item line when creating an order in case there is
no special agreement for the item-customer combination.
The pricing is made according to the following precedence
rules:
• Manually entered price and discount
• Special agreement price and discount
• Price list price, corrections, and discount
• Basic sales price
When processing an order, you are able to correct the customer
price/discount group and the price setting date for
an order line.
The order processing is able to find price list, sales price
correction, and sales price discount based on any corrected
order line information such as price setting date, ordered
quantity etc.
Furthermore, the order processing includes a facility for redetermining
price list price, sales correction, and sales
price discount. The functioning of this facility is analogous
to default order line, i.e. price setting date is changed to
entry/delivery date and customer price/discount group is
changed to the group according to the customer master information.
15

In addition, the order processing has a facility for restarting
pricing. The functioning of this facility is similar to that
of a new order line, i.e. the pricing is carried out according
to the precedence rules mentioned above.
On the individual order line you can work with discount
lines. Basically, the discount lines being documented here,
are the discount lines found in connection with pricing, but
they can be edited.
For each effected discount potential there will be a line
showing rate and discount basis. Discount lines can be edited,
and new discount lines can be created.
IMPORTANT: Calculation of net discount basis is made in
line number order.
If at least one line is edited, the price discount code on the
sales order line will be 'R' (manual editing at discount line
level). In this case, discount lines will not be updated automatically
even if the sales order line information is adjusted.
Display Customer Agreements
In 'Next Level' of customer master data (application 6128)
you will see a list of customer agreement elements.
Display customer agreements
16
The following record types are included in the list:
• Basic price
• Correction in percent
• Correction in currency
• Discounts in percent
• Discounts in currency
• Total discount
• Bonus
Via 'Fixed Selections' you can select for each type which
agreement types to display (O/G/I) or if no records should
be displayed for the type.
Furthermore, you can specify an 'At Date', which will enable
you to distinguish between historical, current, and future
agreements. This parameter is always set at current
date when starting the program.
Financial Reporting
The financial sales reporting comprises the following item
sale transactions:
• Sales at basic sales price
• Sales price correction
• Total discount
• Line discount (trade discounts)
• Sales price difference (difference between basic price
and basic sales price)

Transport Management
The purpose of the transport solution in ASPECT4
Logistics is to manage the internal task of planning
transportation, executing despatch, and following
up on the progress compared to the planning.
The transport solution in ASPECT4 Logistics is exclusively
aimed at the transportation of firm orders
(normal sales and stock movement orders).
It does not include the route management or dossier
accounting that is usually associated with a
transportation task. And it does not include any
new facilities controlling return goods. If you wish
to have these aspects covered by your IT solution,
you must integrate with ASPECT4 Transportation.
As a result of the above facts, this description
covers the following functions:
• How do transport requirements occur?
• Automatic creation
• Manual creation
• Planning a transportation
• Rebooking
• Booking list (Communication with carrier)
• Taking trip numbers
• Completing a transportation
• Feedback of what to transport
• Creation of freight dockets and package labels
• Print of freight dockets
• Print of package labels
• Creation of transport purchase orders
• Reversal of freight purchase
• Following up on transport
• Freight statistics
• Freight variances
The flow chart illustrates a typical transport process
of a business.
There may be deviations from this flow chart
without the basic functionality being changed. For
example, the elements "Preparation of documents"
and "Loading" may be parallel processes.
Picking of items does not appear in the flow
chart, but the picking process is expected to be
parallel to the first processes up till "Preparation
of documents".
Despatch
journals
Dialogue with
customer
Transport planning
Monitoring
transport
requirements
Redistribution
needs
yes
Move
requirements to
other route/date
Booking of
carrier
Recording of
special costs of
transport
Need to
rebook?
nej
Preparation of
documents
Loading
Report transport
complete
Invoice
registration
Match on
amount?
no
Approval of
invoice
End
yes
no
Booking list
Delivery note
Package labels
EDI freight docket
+ documents for
carrier
Freight docket
overview
Transport
purchase
order
17

How do Transport Requirements Occur?
In principle, transport requirements may occur in many
ways. Basically, there is a requirement when one or more
items of goods must be moved from our warehouse to a
consignee. The next question is: When do we know the
precise requirement, i.e. the quantity to be transported to
the customer and the time when is must be transported.
The answers may be many and they undoubtedly vary between
companies.
Fully aware that a precise transport requirement may occur
at many different times in different companies, we also
know that a number of ASPECT4 users will demand C-solutions
within this area.
Automatic Creation
In ASPECT4 Logistics we have chosen to establish that a
transport requirement may occur when a despatch journal
is created. The despatch journal is the job that controls the
picking of items from stock. If you only select stocks for
picking that are allocated, you can be quite sure that the
planned transport requirement will have to be fulfilled. It is
a condition that picking is made against order or against
customer (same customer number and delivery address).
The automatic transport requirement will arise when you
place the trigger program ZTRGTRAL on the file RUTHREG.
The trigger program will control that a transport requirement
is created corresponding to the despatch journal (the
picking job). The transport requirement is created on the
date of the despatch, and therefore we recommend that
you are very precise when you select the method for fixing
the date in the despatch journal. Furthermore, the transport
requirement is separated from the order by route
number, warehouse, and delivery method.
Many other variants of the occurrence of a transport
requirement can be imagined. Some variants can be subject
to a development cooperation, others will require Csolutions
to be developed.
Naturally, transport requirements will also start from sales
orders. Some new fields have been added to the sales orders
in order to support the transport management. The
new fields are:
• Transport requirements (e.g. crane, size of truck etc.)
• Time of delivery
• Trip number
Add to this that the despatch planning is already based on
the delivery models appearing from the route calendars in
application 'Work with Route Calendars' (9174). The arrival
time at the customer’s is calculated on the basis of partly
the number of days en route to the customer and partly
the route calendar of the delivery method. Selection of carrier
is controlled solely by the transport planning, i.e. a selection
of carrier, if any, on the fixed order is not considered.
18
An automatically created transport requirement may include
the following information:
• Customer number and delivery address
• Despatch journal number
• Number of pallets, packages, volume, gross weight and
net weight
• Transport requirements, customer requirements, and
time (hour) of delivery
• Length, width, and height (the greater ones from the
items)
• Status code (following the status code from the despatch
journal)
During the lifetime of a transport requirement, information
such as the below will be added:
• Number of despatch units picked
• Freight provision
• Booking list to carrier printed
The transport requirements are grouped in transport
headers that are created automatically when a new transport
requirement is created. The key to a collection of
transport requirements (a transport header) is: date,
route, warehouse, and delivery method.
The header contains information such as:
• Number of orders, order lines
• Summed-up despatch units
• Warehouse area (exit place) (defaulted by system parameter
Route)
• Departure time (hour) (defaulted by system parameter
Route)
• Carrier/Responsible (defaulted by system parameter
Route)
• Summed-up number of pallets, packages, volume, gross
weight and net weight
• Status
00 = Created
30 = Picking started
60 = Picking completed
80 = Delivery notes, freight dockets, and package labels
printed
Manual creation
From time to time, companies working with transport planning
will typically experience a need to create a transport
requirement manually. Most often the case will be about
items that are not to be picked from stock. In order to be
able to create manually, you simply open a number of
fields that are normally not enabled. This will allow you to
enter the precise transport information.

Planning a Transportation
The planning task partly consists of optimising transports,
partly of communicating with the carriers, and partly of
taking trip numbers (will not be applied in all companies).
Rebooking
As we have described, the creation of despatch journals
will trigger the creation of a transport requirement. If you
have additional requirements for your transport, e.g. an attempt
to drive full loads only, you will often have to rebook
your transport requirements.
Or you may wish to have only one car per transport. In
this case you will have to move some of the transport requirements
to other date/route combinations. It is not a
must that the routes must exist as master data. This allows
you to for example move a number of transport requirements
to a quite new and unknown route that will only occur
this one time due to a special transport requirement.
This method will also be the one to apply if you have several
transports to the same area that you need to divide
onto several cars.
It is a general rule that if you have moved a transport requirement
to for example another route, an additional
matching transport requirement (same order) will be
planned for the same route.
In the application 'Work with Transport Planning' (6191)
the rebooking function is named 'Move line'.
Booking List
The communication with the carriers is processed via a
booking list. The booking list is the document that covers
the carrier’s need for information, i.e. the details required
to get a suitable number of vehicles to solve the transport
task. The booking list can be printed via application 'Print
Booking List' (6293). Please note that the booking list cannot
be printed to paper unless you apply DocManager.
The booking list contains information about which transports
have been booked on a trip. For each transport requirement
you will see the delivery address and the expected
gross weight and the expected volume. These data
have been computed on the basis of the freight information
on the item’s sales information. Besides, the delivery time
(hour), special transport requirements, and customer requirements
appear.
Trip Numbers
Many companies wish to gather the trips on trip numbers.
You can take a common trip number for the transport requirements
gathered on a trip (combination of date/route/
warehouse/delivery method). The trip number is also updated
on the associated invoice order where it can be
used, among other things, for a combined print of the delivery
notes belonging to the trip. The trip number may
also be applied in connection with a follow-up on the actual
freight costs. A trip number is assigned by the voucher
number series TU.
Taking a trip number is not a must for applying the transport
planning in ASPECT4 Logistics. Only if you want to
have a combined print of delivery notes for the trip, you
have to take a trip number.
19

The booking list shows which transports have been booked for a trip.
Completing a Transportation
To complete a transportation, you record what has been
packed for the transport and you communicate to the interested
parties by submitting freight dockets, package labels,
freight docket summary, and delivery notes. Besides,
you must create the transport purchase order.
Feed-back on What to Transport
A transport requirement is directly connected with the picking
task – one transport requirement per despatch journal.
Therefore, it is natural to record the number of despatch
units per transport requirement. The purpose of this type
of registration is to have the correct number of despatch
units (pallets, packages, batch etc.) for the freight docket
and for generating packages and package labels.
To control the different despatch units, we have created a
new system parameter called 'Package types number
fields' (FRTPANT). The system parameter allows you to create
up to 10 different despatch units. Typical despatch
units are: pallet, package, batch or the like. When you
have completed picking for a despatch journal, the completion
of the journal will provide a field where you can enter
the number of despatch units, cf. those created under the
system parameter 'Package types number fields' (FRTPANT).
The alternative to recording the number of packages in
connection with completing a despatch journal is to record
20
the number of packed despatch units directly in the transport
planning, application 'Work with Transport Planning'
(6191). On the system parameter 'Package types number
fields' (FRTPANT) you can also specify an item number to
be invoiced when the despatch unit is recorded (e.g. invoicing
of EUR pallets when recording number of EUR pallets).
The above-mentioned recording of the number of despatch
units must not be confused with the "pick and pack" function
in ASPECT4 Logistics. The above-mentioned sort of
registration is general and does not control which items/
contents are in the individual packages. The registration
task in connection with this type of general feedback requires
far less resources than does the corresponding registration
of which contents are in the individual packages.
Creation of Freight Dockets and Package Labels
In connection with despatching the picked items, freight
dockets and package labels must usually be generated.
The principle of generating freight dockets requires one
freight docket per delivery address per customer. This ensures
that several orders for the same customer on the
same delivery address will be collected in one freight
docket. Hereby, the actual freight costs are kept at a minimum.
Via the reference structure you can trace the freight
docket by the order or vice versa.
Freight dockets are assigned a number from the system
parameter 'Freight docket numbers – building' (FRAGTMSK).
This parameter controls partly the length of the freight
docket number, partly the number assignment for the variable
part of the freight docket number. The building of
freight docket numbers may vary between carriers.
When freight dockets are generated, packages are generated,
as well. Basically, one package number is generated
per despatch unit reported back on the transport jobs collected
on the freight docket. If the carrier is able to trace
the individual packages, one package will be generated per

despatch unit reported back (example: 7 pallets on the
freight docket will result in 7 package numbers and thereby
7 unique package labels). The supplier field KULEARB4B
will control this process.
The freight docket contains information that can be added
manually if required, e.g. transport instruction, COD
amount, insurance amount and insurance category, policy
number, payer, transport code, delivery instruction. Manual
entry must be performed via application 'Work with Freight
Dockets' (6192).
Technical information about the freight docket:
• Freight docket number is taken according to the information
stored in system parameter 'Freight docket numbers
– building' (FRAGTMSK).
• Consignor address for the freight docket is defaulted
from the warehouse of the transport. The address of the
warehouse address number is applied. If it does not exist,
the address is taken from section 0010 in the Gen-
eral Files.
• Carrier is defaulted from the transport header.
• The below data are suggested from the system parameter
'Freight docket information default' (FRBRV):
• Consignor’s GAN number
• Transport instruction
• Freight payer code
• Transport code
• Delivery instruction
• Package type
• Quantity and package type are suggested from the
transport lines.
Communicating Freight Dockets and
Freight Docket Summary
Freight dockets can be communicated to the carrier either
electronically or on paper. To communicate the freight
docket on paper, you need to apply DocManager to design
the printout. The printing of freight dockets is made via application
'Print Freight Dockets' (6292).
The electronic communication to the carrier is based on the
EDIFACT standard IFTMIN. You can apply ASPECT4
BusinessConnector to set up the communication. For the
carriers receiving the freight docket electronically it will be
obvious to use the freight docket summary for checking
the quantities received.
In addition to the delivery address, the freight docket summary
contains transport comments, delivery time (hour),
and the number of despatch units reported back (pallets,
packages, batches, pieces etc.). The totals appear from the
bottom line of the list. The freight docket summary can be
printed via application 'Print Freight Docket Summary'
(6492). Please note that the freight docket summary cannot
be printed to paper unless you apply DocManager.
You will find an example on the next page.
Printing Package Labels
Package labels are printed only to those carriers who can
apply them for "track and trace". But this must not keep
others from printing package labels for all packages if they
should wish so, for example as an extra check by counting
the packages to be despatched. Package labels can be
21

The freight docket summary can only be printed via DocManager.
printed via application 'Print Package Labels' (6491). Please
note that the package labels cannot be printed unless you
apply DocManager.
Printing Delivery Notes
When a trip is ready to be made, the carrier must bring
along the delivery notes. Therefore, a new function has
been added to ASPECT4 Logistics that enables the printing
of delivery notes per trip number. To this end a trip number
has been added to the order header. The number is updated
in connection with updating the picked despatch
journal.
The delivery note has not been changed in contents or layout
in connection with implementing the transport module.
Creating Transport Purchase Orders
Provision and creation of freight purchase orders can now
be made according to three different models in ASPECT4
Logistics.
1. Freight provision is updated in the sales statistics.
Freight provision and outstanding freight is posted under
the pseudo account types FH and FS. Outstanding
freight is not controlled against the orders in this model.
2. Freight provision is updated in the sales statistics. Provision
is made and a freight purchase order is created in
connection with the invoicing. A freight purchase order
is created for each combination of order/delivery invoiced.
The freight purchase order will typically have the
same order number as the order invoiced. The delivery
number is either the same or with 5000 added. Freight
22
provision and outstanding freight is basically posted at
the time of invoicing (in practice in connection with the
automatic receiving of goods on the freight purchase order).
Posting is made to the pseudo account types FH
and IT (freight provision and outstanding purchase).
3. The third model is the one provided by the implemented
transport module. Here the freight purchase order is not
created on the basis of the sales order, but on the basis
of the freight docket. Hereby you have the same communication
with the carrier as you have on the freight
docket. Several deliveries can be collected on a freight
docket, which will save money on the freight purchase.
The freight provision is updated in the sales statistics at
the time of invoicing. The freight purchase order is created
by calling application 'Generate Freight Purchase'
(6295). The time may be prior to or after the time of invoicing.
Freight provision and outstanding freight is
posted in connection with the automatic receiving of
goods on the freight purchase order. Posting is made to
the pseudo account types FH and IT (freight provision
and outstanding purchase). As with model 2, the delivery
number will be added with 5000.
When freight purchase orders are generated on the basis
of a freight docket and not on the basis of the sales order,
the order number relation between sales order and freight
purchase order will vanish.
Manually created freight purchase orders are handled in
the same way as automatically created freight purchase orders.
Freight purchase orders can be created manually via
application 'Work with Purchase Orders' (7108).

When you choose to manually create freight purchase orders,
you will be able to have a complete set of freight statistics
even if freight dockets have not been created on all
despatches.
The value of the outstanding freight is charged on the
freight purchase order and is not found by reading the
freight docket or the sales order. However, the outstanding
freight will also appear from the freight docket header
(FRBHREG).
The freight provision will reflect the amount allocated on
the individual deliveries. Many deliveries can be collected
on one freight docket; therefore, the amount allocated to
cover the freight charges will supposedly be greater than
required. When the invoice is received, the outstanding
freight will be settled and the actual freight charge will be
posted. The resulting difference is partly caused by the
function of being able to collect several deliveries on one
freight docket.
The basis for linking freight purchase orders with freight
dockets is the numbers coinciding. This is achieved by applying
the sequence number from the freight docket as the
purchase order number.
The financial transactions for a freight purchase order basically
looks like this:
Blanket Orders
The facilities for applying blanket orders and quotations
were strongly improved with release 9.0 of ASPECT4 Logistics.
In release 9.1 we introduce a number of enhancements.
In order to have an aggregate description of the
functionality, we have chosen to submit the total description
of the blanket order management here. Many AS-
PECT4 users will choose to apply the facility for managing
and following up on sales promotions.
The basis for entering a blanket order agreement is the entering
of a customer agreement with a certain time frame.
The blanket order concept has existed through many versions
of ASPECT4 Logistics; however, with this release it
was decided to modify and expand the concept so that significant
changes are made to a number of key areas as described
below.
A freight provision of 500 DKK is created in connection
with the freight purchase order and the automatic receiving
of goods:
Outstanding Freight
purchase (IT) provision (FH)
| 500 500 |
An invoice is received from the carrier of 480 DKK
Outstanding Freight
purchase (IT) difference (FD) Creditor (IK)
500 | | 20 | 480
The actual freight will thus be the sum of freight provision
and the freight difference.
Freight Statistics
The freight statistics contain the sales order key as the primary
access if you apply method 2 to control the outstanding
freight. When applying method 1, no freight statistics
will be generated.
When you implement the transport planning feature, the
freight statistics will not be levelled at the sales order, but
at the freight docket and thereby the freight purchase order.
Basically, the freight statistics will contain the same information.
Actual freight as well as freight provision is already
included in the statistics.
Reversal of Freight Purchase
If by mistake a freight purchase order has been created for
a freight docket, it can be reversed. This functionality can
be activated via application 'Generate Freight Purchase'
(6295).
• What is a blanket order agreement
• The relationship between blanket order agreement and
blanket order
• Customer-agreed minimum stocks
• Periodizing a blanket order agreement line
• Availability on derived orders
• Improved call-off management
• Improved follow-up on order hierarchies
• Integration to sales budget
It is possible to maintain existing functionality through parameter
setup of system parameter Module 3 - Sales
management(MODUL-3). Similarly the new functionality
may be activated through system parameter Module 3 –
Sales management(MODUL-3).
23

What is a Blanket Order Agreement
In connection with the creation of a blanket order it is appropriate
to be able to manage a number of specifications
that do not usually belong to a specific blanket order. This
type of information is gathered under blanket order agreements
in application 'Work with Blanket Order Agreements’
(6137).
By means of this agreement it is possible to specify when
to notify (days before expiry or agreement utilization rate),
whether to print new order confirmation on adjustment,
planning calendar for allocation over time of the expected
call-off, term of the agreement, call-off quantities, price/
discount code, and transfer information. Transfer information
is rules governing to which extent information is to be
transferred from blanket order to the order type to which
transfer was decided.
A blanket order agreement is always created per project
number per customer. On the agreement you specify who
is allowed to call off against the associated blanket order
(you may for example create an agreement allowing all
customers with the same debtor to call off against a blanket
order). At item level it is possible to choose whether
the agreement applies per item, item group, or to all
items.
Relationship between Blanket Order
Agreements and Blanket Orders
It is possible to create a blanket order agreement directly
in 6137 and then create a blanket order in 6106 to be associated
with the blanket order agreement.
However, it is also possible to create the blanket order
agreement in connection with creating the blanket order
line if you have specified a project number. This facility is
controlled by a parameter in MODUL-3.
In practice this means that future creation of blanket orders
in application 'Work with Blanket Orders’ (6106) will
automatically lead you to 'Work with Blanket Order Agreements’
(6137) if no blanket order agreement exists for the
particular project number and customer number. This will
ease the blanket order agreement creation for the particular
project and customer, especially in the one-to-one situation
where a blanket order agreement matches a blanket
order.
When in future you create a blanket order line where the
entered quantity differs from the quantity information of
the blanket order agreement, the system will automatically
notify you about the discrepancy. And the system will allow
you to update the blanket order agreement with the new
quantity information, thus easing the updating of blanket
order agreements.
24
Customer-agreed Minimum Stocks
When you create a blanket order agreement, you can specify
minimum stocks. Hereby you can document any agreements
with the customer regarding a constant minimum
stock. Some companies want the customer-determined
minimum stocks to be added to the item’s minimum stock
when planning availability, whereas other companies want
the customer-determined minimum stocks to remain solely
informative and not to be considered when planning availability.
Whether or not to include customer-agreed minimum
stocks in availability planning is determined by system
parameter Production and warehouse management
parameters(STYKLIST).
Furthermore, the parameter MATPROF2 enables you to
control when the changes of the minimum stock should effect
availability. Minimum stocks appear in connection with
issues on the from-date and receipts on the to-date in the
material profile in order to ensure that they can be made
available. The status code on these issues and receipts follows
the status code on the record in 'Work with Blanket
Order Agreements’ (6137). Hereby it is possible to set up a
material profile that will for example not include the minimum
stock in the period until the status code value is 30
on the blanket order agreement.
Distributing a Blanket Order
Agreement Line to Periods
In application 'Work with Blanket Order Agreements'
(6137) you can describe per project number per customer
number a variety of basic conditions to apply when creating
blanket orders. The specifications, which may be stated
for item number, item group, or generally, include:
• Call-off quantity
(possible override of unit order size from item sales
information)
• Warning – days
(notice when a given maximum number of days
remain till expiry of the agreement)
• Warning – period/pct.
(notice when a given maximum percentage of the
validity period remains)
• Warning – remaining qty.
(notice when a given maximum quantity remains)
• Warning – rem. qty/pct
(notice when a given maximum percentage of the
agreed quantity remains)
• Planning calendar
(for availability planning: weekly/monthly allocation)
• Price/discount code
(are blanket order price/discount terms inherited in
call-off order)
0: call-off customer’s price/discount terms are
always applied (i.e. blanket order only
concerns quantity management)
1: terms are inherited if customer number or
debtor number corresponds to the customer
number of the blanket order
9: terms are always inherited

• Postadjustment of order prices
• New order confirmation on adjustment
When creating a blanket order line, you must specify delivery
term, end term, total quantity, etc. On creation of a
new line, end term is set to the agreement’s expiry date.
Delivery term is understood as the date of the first planned
delivery, while end term is understood as the final date of
the last delivery period. A date on the order header indicates
the expiry date of the entire blanket order (all lines).
On creation of lines it is validated that the end term does
not fall after this expiry date.
Delivery date and end date are applied for the periodizing
of availability. There is no automatic closing of agreements,
even if the end term is exceeded. Such closing may be
performed when printing a warning list.
During registration/editing, the line is broken down into a
number of periodized availability plans in accordance with
specifications in the agreement file.
Example: If a delivery term is 01.01.06, and the end term
is 31.12.06, and the planning calendar indicates breakdown
by month, then 1/12 of the order line quantity will be
made available for delivery at the beginning of each calendar
month over the year. In application 'Break Down Sales
Plan' (8211), the planning follows this periodized availability.
By selecting the option 'Work with availability’ on the blanket
order line, you can view and edit the periodized availability
plans. Here the order processor can arrange the
availability of quantities and times; however, the times
must be confined to the period stated on the order line.
When the level is exited it is checked whether the total
quantity matches the order line quantity. If not, the individual
period figures are adjusted relatively (i.e. at first it
is adequate just to state quantities as relative figures).
If the quantity at order line level is modified, the relative
distribution to periods is maintained. If the period is reduced,
the planned availability exceeding the period will be
moved to the start or end date of the period. If all availability
is deleted, a recalculation will be performed (like
when a new order line is created).
Availability on Derived Orders
It is possible to perform production and purchase planning
based on sales blanket orders. Even if end production (e.g.
fitting) is only performed in connection with the planning of
a firm order (on call-off from the blanket order), it is possible
already on creation of the blanket sales order to e.g.
purchase raw materials or complete initial production at
semi-manufactured item level.
This is illustrated in the example below. A partial arrangement
for a qty. of 100 of item A (RO01) on a blanket order
line (for a total qty. of 1200) will automatically create a
production order proposal (PF01) for a qty. of 100 of the
same item. This proposal further creates two derived production
order proposals (PF02 and PF03) for semi-manufactured
items B and C of qtys. of 100 and 200 respec-
tively. One production order proposal derives a purchase
order proposal (IF01) for item D of a qty. of 400. (Such a
set of orders is created for each partial arrangement on the
blanket order line.)
Creation
It is then possible to commence purchase and production
orders at semi-finished item level - PF02, PF03, and IF01
are all approved and completed.
Below the situation is illustrated after a call-off of a qty. of
25. The production order proposal PF01 is reduced to the
remaining qty. of 75. Derived production orders are not
changed as they have been completed in the meantime.
An actual production order (PO06) of a qty. of 25 is automatically
created in connection with the call-off order (firm
order - TO02). Here a setup is selected, which prevents
this production order from creating derived orders. In
other words, it is now expected that semi-finished items
are available (however, other order policies might result in
the creation of derived orders).
Call-off
When production of PO06 is completed, TO02 may be
transferred to invoicing. In this example there is an extraordinary
discarding of a qty. of 5, which means that only a
qty. of 20 may be invoiced (invoice order - FO03) while the
last 5 remain on the firm order. Note: If firm order is
changed to match the actually produced quantity the blanket
order may be ’adjusted back’ (parameter setup) to reflect
the actual remaining delivery (80 items).
Delivery
Optimisation of when to create derived orders is managed
through the individual item’s order policy code as well as
settings and processing of 'Implement Derived Order
Transactions’ (6241/6242).
Order policy code may e.g. be ’PO’, meaning that a derived
production order is always created, or ’PD’ meaning that a
derived order is only created if adequate stocks are not
available.
Through different calls and settings of 6241/6242 (and
possible employment of co-applications) you can ensure
that e.g. blanket orders will always result in derived production
orders being created as proposals and that they
will create new proposals. Different settings may e.g. en-
25

sure that firm orders will result in the creation of actual production
orders and that they will not derive further orders.
In the example above derived orders are created for the
exact quantity needed to cover the parent order (minimum
order size and unit order size of item master information =
1). If item master information dictates the creation of orders
for a larger quantity, this will happen. In other words,
an available stock is built for the quantity exceeding the
immediate requirement.
When orders are derived (directly or indirectly) from a
blanket order, it is possible to dictate that order quantities
of the derived order do not exceed the total requirements
from blanket order lines. This is in order to accomodate the
situation when it is desirable to build a minor stock of
semi-finished items for the covering of subsequent deliveries
under the relevant blanket order, but on the other hand
it is undesirable to over-produce, as the semi-finished
items are not suited for other purposes.
This situation is handled as follows:
• Applications 6241/6242 are run with settings ensuring
that for blanket orders derived orders are only created
for the current requirement (no stock build-up). In other
words, the order size indications from item information
are ignored.
• 'Join Production Orders' (8210) will join the production
orders. Orders of the same item number ordered are
joined here within delimited periods (regardless of
whether they are derived from the same blanket order).
You must specify whether to join per item number until
the minimum order size is met (multiple orders within
the delimited period) or whether to join into one order.
In the example above a qty. of 200 of item C (PF03) was
planned to be available to cover the requirements on production
of a qty. of 100 of item A (PF01). In other words,
2 of item C are required for the production of 1 item A. As
described, if minimum order size and unit order size for
item A = 1, a total of 12 production orders are planned for
item A (one order per calendar month). Thus the total requirement
for item C is a quantity of 2400.
When applications 6241/6242 are run as described above,
12 orders are created for item C, each of a quantity of 200
(presuming there is no available stock).
When 'Join Production Orders' (8210) has been executed,
these orders will be joined to an order of 2000 items on
01.01.05 and 400 items on 01.11.05 – provided the item’s
minimum order size is e.g. 2000 and more orders are to be
created.
Availability on Internal Trade
The availability planning described in the section above
may also be performed even if production takes place
through an affiliate. This is illustrated by the example below.
26
When the blanket sales order is created in Company1, a
blanket purchase order is automatically created in the
same company. This is "mirrored" in a blanket sales order
in Company2, where the initial production preparation may
be performed as described in the previous section.
Creation
A quantity of 25 is now called off as firm order TO02 is created.
This results in the automatic creation of purchase order
IO02 in Company1 and of firm order TO12 and production
order PO12 in Company2. At the same time the remaining
quantity on RO01 is reduced as well as the orders
derived from this in Company1 and Company2. Note that
these derived orders always only reflect changes in RO01 –
there is never any direct transfer from these to other order
types.
Call-off
As in the previous section only a quantity of 20 is reported
as finished from the production. This means that an invoice
order FO13 is created in Company2 (customer here is
Company1, while invoice address is that of the end customer).
In Company1 this invoice is registered automatically
(via application 7261), and an invoice order FO03 is
automatically created for the end customer.
Delivery
Improved Call-off Management
Call-off orders are created manually, by either:
• Transferring quantities called off to an order of a different
type (usually a firm order) on the basis of a blanket
order, or
• Automatically reducing the relevant blanket order in connection
with the creation of orders of a different order
type.
On transfer from blanket order (application 6106) the order
header information of the call-off order is basically
identical to that of the blanket order. For example, the customer
number may be different if the blanket order agreement
allows it (e.g. a blanket order agreement entered
with debtor).
The blanket order may be reduced automatically in connection
with the creation of a different type of order in the following
manner:

• Each order line is checked to see whether an existing
blanket order line meets the current conditions (item information,
customer information, project number, system
parameters, etc.) for joining.
• If so, the blanket order is reduced and an order reference
is created. Depending on the setting of application
dependent data it is possible to choose that the order
processor must first confirm the reduction of the selected
order. The order processor may then choose to accept
the reduction, to continue the search for any other order,
or to avoid reduction.
• The order processor is informed if the call-off exceeds
the remaining quantity of the blanket order.
• If prices/discounts are inherited, they are transferred. If
the blanket order price list code is ’1’ (conditions are in-
herited when customer number or debtor number corresponds
to the blanket order’s customer number) and if
the customer number deviates from the blanket order
customer number, this code is set at a special value ('T')
on the call-off order.
• Selected order header information may be transferred
from blanket order to call-off order (in accordance with
system parameter 'Blanket orders transfer parameters’
(SOOVFOPL)). If a given order is created as call-off from
several different blanket orders, the order header information
from the latest connected blanket order apply.
It is not possible to delete blanket order lines that are being
reduced, and it is not possible to change central information
(item number, feature/option specification, etc.)
Lines may always be closed even if order quantities are not
fully delivered.
When call-off on a blanket order line is performed, the
line’s part allocations are automatically reduced. This always
takes place through a reduction/deletion of the earliest
calendar allocations.
e-Export
On 31.12.2005 the old way of clearing export goods
through the customs ended. However, the old system was
prolonged for two preliminary months.
SKAT – the Danish Customs Authorities – have now introduced
the e-Export concept whereby you can specify your
clearance needs electronically. To meet this feature, EDB
Gruppen has developed a new module for ASPECT4. Thus
you can now communicate electronically with SKAT, deliver
your export documents automatically, and receive a reply.
In the e-Export module you can submit your export documents
to SKAT electronically. In ASPECT4 Logistics you can
work with export documents from proforma invoices (application
6230), invoices (application 6235), and collective invoices
(application 6236). These applications will continue
to have their usual function, but in addition they can now
via a business module submit your export documents to
the common e-Export module in ASPECT4. The e-Export
module will then automatically forward the export document
to SKAT, but if implications should occur, the e-Export
When calling off against a blanket order it is possible to retrieve
the sales price on the firm order based on the current
delivery date. This function is controlled by a parameter.
Retrieving the sales price at the time of call-off provides
greater freedom to perfom price adjustments on
agreements prior to the new prices taking effect. Thereby
it is still possible to call off at "the old price” even if the
price has been changed on the agreement prior to the date
of taking effect - and after the date of taking effect, a calloff
will automatically be at the new price even if by mistake
the price may not have been updated on the blanket order
agreement.
Improved Follow-Up Options on
Order Hierarchies
A new order overview, ’Print Arrangements List’ (6420)
was developed for the documentation of e.g. status of derived
orders ("semi-finished items"). This is based on sales
orders and displays information from sales orders as well
as derived orders.
All derived orders up to the desired level are displayed per
sales order line. If there is more than one derived order
per sales order line, information about them are displayed
in subsequent lines. The result of any materials check is
printed under the checked production order. You can
choose to print one line for all components or merely lines
with critical components.
Integration to Sales Budget
One of the new functionalities in blanket order management
is the possibility of transferring blanket orders to
budget. If there are long-term customer agreements and
they are documented as blanket orders in ASPECT4 Logistics,
it would be obvious to transfer them to budget. This
provides yet another option for follow-up on customer
blanket order agreements.
module allows you to edit/create/delete your export documents,
and transfer/retransfer them to SKAT.
The company parameter 'e-Export' (TOLDANV) is new and
determines whether transactions must be created for e-Export.
The parameter also contains information about the
customs office, clearance time, clearer’s SE number, declaration
category, declaration type inside/outside EFTA, EU
declaration type, procedure code, package label, and package
type.
There is another new company parameter 'EFTA Country'
(EFTALAND), which is used for determining which of the
declaration types to apply.
The solution requires the ASPECT4 BusinessConnector and
its flat file adaptor, and the ACS level must be 9.0.01 as a
minimum. Besides, you must have DocManager installed,
the iSeries operating system must be Version 5 Release 3,
and ASPECT4 Logistics must be release 8 or 9.
27

An EDI notification (DELFOR) contains orders/forecasts for
a number of items. At regular intervals, a new EDI notification
(DELFOR) is received, containing new/updated orders/
forecasts.
Receiving a DELFOR triggers the creation of sales orders
containing sales order lines equivalent to the items, quantities,
and delivery times specified in the EDI document. Receiving
a DELFOR will generate sales order transactions
(application 6101) that can be updated manually later on
(application 6201).
When creating sales order transactions you have several
options. You can optimize the system to first generate deletion
transactions (in 6101) for existing sales orders for
the customer. Or you can optimize the system to generate
completion transactions. Below, only deletion transactions
are described. When all creation transactions have been
generated (in 6101), you can now compress the created
sales order transactions whereby "equal" deletion/creation
transactions are removed again. This must be done before
submitting the sales order transactions for update (6201).
Hereby you achieve that the sales order transactions will
only comprise the changes required for the existing sales
orders. This will provide an overview of what to take
manual action on, viz. changes concerning delivery dates
within a short horizon. Changes concerning delivery dates
in the far future may well be left to the system to handle
automatically.
Based on the material profile that includes stockholding,
production order, and sales order, you can plan availability
– manually or automatically via application 8211. Availability
planning should cause creation/change in the production
plan.
Despatch can be made from the standard system’s normal
despatch planning, delivery summary etc.
Prerequisites and Delimitations
EDI notifications (DELFOR) are loaded via FTP to a local
server for processing in ASPECT4. The processing of EDI
notifications has the following prerequisites and delimitations:
• The transmission is always a "total" delivery plan per
item number for the customer. I.e. if the customer must
have the same item delivered to several delivery addresses,
the total plan for the item is always submitted,
and not only per delivery address.
Please note that the same item in the same transmission
(even per document) can be ordered for many delivery
addresses.
• Item number can be identified automatically, i.e. the
customer’s item number, trade item number, or EAN
number has been created.
28
Receiving Delivery Proposal via Adaptor DELFOR
• A particular code is always applied for "ordered" quantity.
This code must be controlled by parameter per customer.
Field EDIAK6063P in EDIAREG – maintain via application
6198.
• A particular code is always applied for "delivery date".
This code must be controlled by parameter per customer.
If the code is blank, the delivery date will not be filled in.
Field EDIAK2005L in EDIAREG – maintain via application
6198.
• A particular code is always applied for "expected arrival
date". This code must be controlled by parameter per
customer. If the code is blank, the expected arrival date
will not be filled in.
Field EDIAK2005M in EDIAREG – maintain via application
6198.
• A particular code is always applied for "customer order
number". This code must be controlled by parameter per
customer. If the code is blank, the customer order number
will not be filled in.
Field EDIAK1153K in EDIAREG – maintain via application
6198.
• The customer is identified by means of the NAD-BY segment.
• The delivery address is identified by means of the NAD-
CN segment.
Please note that there may be many NAD-CN in the
same document, i.e. one document may result in several
journals in TRSHREG.
If the delivery address cannot be identified by means of
NAD-CN, an attempt is made with NAD-DP. If still unsuccessful,
NAD-BY will be applied.

Minor Enhancements - Outgoing Logistics
Copying Order Lines
When copying order headers (sale and purchase) on a
5250 screen, you first copied the order header and then
the order lines. This proved inexpedient with eXposer, for
which reason we have added a functionality to both 5250
and eXposer: when copying an order, both order header
and order lines are copied. Whether or not to include order
lines in copying can be controlled by parameter via application-dependent
data (OPTIONAPPL).
During copying, a dialog box will appear with the new order
number and the number of order lines copied and not
copied. This dialog box only appears if you have chosen to
include order lines in the copying.
Entry of a Numerical Customer Number
When entering customer numbers, entry of numerical customer
numbers is now enabled. Example: If the customer
numbers are five-digit numbers, you can now enter for instance
26, instead of 00026.
EAN Number as Customer Item Number
It is now possible to insert an item EAN number as the customer
item number. This is set up via the system parameter
'Item Number Groups for Customers (Trade Item
Numbers)' (KUNVAGRP). Here it can be specified per customer
group whether the customer item number must be
the item EAN number or whether the item number must be
found the usual way.
This feature requires that EAN numbers are maintained via
application 'Work with EAN Numbers' (9109).
Selection by Status
The below price list applications now provide the opportunity
to select by item status. Hereby you can deselect
items that are not active.
Work with Basic Prices - Sales (6115)
Work with Price Correction in Currency (6116)
Work with Price Correction in Pct (6117)
Work with Price Discounts in Currency (6118)
Work with Price Discounts in Pct (6119)
Work with Basic Prices - Purchase (7115)
Work with Price Corr in Currency (7116)
Work with Price Corr in Percent (7117)
Work with Price Disc in Currency (7118)
Work with Price Disc in Percent (7119)
As a consequence of introducing selection by status, minor
changes have also been made to the below applications,
where status has now been entered as a fixed selection.
This will prevent resources from being used on correcting
items that are not active.
Work with Purchase Items (9103)
Work with Sales Items (9104)
Work with Item Features (9105)
Wholesaler Group
When managing debtors, you can now specify a wholesaler
group to be applied in connection with orders. In application
'Work with Customers' (6128) you now have an extra
field for the debtor: Wholesaler Group. The wholesaler
group is meant for controlling the customer constellation: a
parent company, a wholesaler network, the individual customer.
In this case you can now create the chain with an independent
customer number. You can subsequently specify the
customer number – as a wholesaler group – on the individual
shop’s customer number. If the wholesaler group is
applied, it will appear on the order, and thus it will be included
in the ASPECT4 Logistics sales statistics. The number
is not meant to appear on printouts, but if you apply
DocManager for your printouts, you may include the field in
sales documents.
Price Setting Customer
The price and discount management in release 9.1 now includes
the ability to apply price setting customers. A price
setting customer is created as an ordinary debtor. Subsequently
you can link other debtors to the price setting customer
via application 'Work with Customers' (6128) where
a new field has been added: Price Setting Customer No.
In this field you can specify the debtor number of the price
setting customer. The debtor will then follow the price and
discount structure of the price setting customer.
29

This provides great flexibility in the customers’ prices and
discounts because several customers can be linked to the
same price setting customer and thereby be managed centrally.
It also allows you to let the wholesaler group control
the price setting.
If you do not specify the price setting customer number,
the customer number will continue to be applied, unless
the system parameter 'Module 3 - Sales Management'
(MODUL-3) specifies that the debtor must prevail.
Allocating Pallets and Packages
The automatic allocation functionality has been extended:
It is now possible to only allocate whole pallets or whole
packages from a buffer location. This is achieved via the
system parameter 'Allocation – Optimizing Parameters'
(LOKAALK) where the field 'Picking Location' can now have
two additional values:
30
3: Allocate only whole packages from buffer locations
4: Allocate only whole pallets from buffer locations
If the parameter specifies that only whole packages or
whole pallets must be picked from buffer locations, any excess
quantity is ignored in the first place. Only in case of
missing material, opened lots will be allocated. The size of
package and pallet is determined from the item’s sales information.
Please note: Even though picking in whole pallets or whole
packages is primarily aimed at picking locations in order to
ensure that whole pallets/packages are picked from buffer
location, the parameter also works even if you do not apply
picking locations. Example: An item has a pallet size of 20
pieces. To allocate 105 pieces of the item, two allocations
will be generated: one of 100 pieces (5 pallets) and one of
5 pieces.
Extended Control Code Scanning
When you use handheld terminals in the warehouse, you
have the opportunity to validate that the correct item is being
picked. So far, this has been made by a control code on
the location. This control code has now been extended
from 8 to 16 characters in order to enable the use of item
number for the validation of whether the correct item is
being picked. If you want to use the item number for the
validation, you must specify 'VNR' or 'ITEM' in the location’s
control code field. Hereby you avoid having to update
the location file when moving items between locations.
If you want to apply the item number for the validation of
whether the scanned item is the correct item, the scanning
field must have the type 86, and the field’s LDA position
must be 585. This will ensure that for example EAN numbers,
pseudo item numbers or the like will be translated
into internal item numbers and thereby will be considered
valid.
Customs Tariff on Proforma Invoices
In connection with DocManager printouts, the proforma invoice
has been changed: The customs tariff number now
appears next to each order line. The DocManager band
printing the detail lines also includes the customs tariff
number.
KID Number on Invoice
Via a company parameter you can specify that a KID number
must be taken from section 1140 to be printed on the
original invoice via DocManager. The KID number will be
transferred to Finance along with the accounts receivable
transaction. This functionality requires ASPECT4 Financial
Management release 9 or newer.
The company parameter 'Invoice' (FAKTURA) has been extended
with a field controlling whether or not KID number
is applied.

Cockpit for Receiving Invoices
INWARD BOUND LOGISTICS
In cooperation with a customer, EG has developed a cockpit for receiving supplier invoices. The cockpit provides an excellent
overview partly of whether the voucher you are now recording, balances, and partly of which lines have previously
been recorded on the voucher.
A cockpit example:
In order to balance a voucher, you can edit the lines at the bottom right. Here you can also add lines of charges. If you
want to edit the voucher, e.g. about payment approval, date or the like, this can be done at the bottom left.
31

32
Cockpit for Capacity Overview
In order to provide a better view of the capacity situation, EG has developed a cockpit for this function. A typical cockpit
may look like this:

Check against Accumulated Capacity
The application 'Check Production' (8330) has been added
the function of checking against accumulated free capacity.
The purpose of adding the function is to allow for any later
overbooking; so far, there has been an implicit presumption
of a decreasing capacity utilization about the check.
The check is activated when the availability code is 9 on
the capacity resource and sum files have been generated
for the capacity resource. If there is no valid sum file, the
previous functionality prevails.
The function of checking against accumulated capacity is
meant not only for checking whether the required production
can be carried out at the required time, but also for
checking that it will not result in an overbooking later on.
In other words, the function allows for the fact that we
have not yet levelled out production. Thus, compared with
the previous check against the sum file, the check has
been extended to check against minimum free capacity at
all times.
The functionality is based on the existing functionality of
sum files. Therefore, sum files must be generated and updated
for the resource with application 'Rebuild Summary
Capacity Profiles' (8291) and 'Start Update of Capacity Profile'
(8292), respectively.
The sum files are updated by trigger and at any time they
describe the accumulated capacity and the accumulated requirements
up to any time of changed requirements. However,
you can define a period of indifference (system parameter
SUMKAP). If it is 0, all events will be reflected, but
it gives an improved performance to set it at minimum 1
day. This means, that overbooking may occur within a particular
day, but the error is not accumulated. Since a subsequent
fine planning is expected anyway, this will typically
be acceptable.
Changed Control of Breakdown
of Sales Plan
The way in which application 'Break Down Sales Plan'
(8211) has so far functioned, allowance has been made for
minimum/maximum order size and unit order size when
creating purchase order forecasts and production order
forecasts. This can now be optimized.
The application had the company parameter 'Net requirement
calculation – gross' (NEDBRYD) that defined a number
of breakdown preconditions. In order to enable the use
of copy applications, the optimizing information has now
been turned into application parameters for 'Break Down
Sales Plan' (8211).
Solution
'Break Down Sales Plan' (8211) has been modified to the
effect that optimizing parameters for breakdown must be
specified as application parameters.
Besides, the following fields have been added to the parameters:
Check Purch Quantities: A specification of whether allowance
must be made for minimum/unit/maximum order size
when calculating order size:
0: Do not consider order sizes.
1: Consider order sizes.
Quantity Check Purchase: A specification of which order
size to correct against:
0: Correct against minimum order size.
1: Correct against minimum and unit order size.
2: Correct against minimum, unit, and maximum order
size.
Check Prod Quantities: A specification of whether allowance
must be made for minimum/unit/maximum order size
when calculating order size:
0: Do not consider order sizes.
1: Consider order sizes.
Quantity Check Production: A specification of which order
size to correct against:
0: Correct against minimum order size.
1: Correct against minimum and unit order size.
2: Correct against minimum, unit, and maximum order
size.
Implementation
When implementing release 9.1, the application parameters
must be set up under file name NEDBRYD.
If allowance to order size must be made as previously, the
new optimizing parameters must be set up as shown below:
33

34
Material Check in Fine Planning
In the application 'Work with Fine Planning' (8121) the dating
has been extended with an extra parameter enabling
material check in connection with the fine planning. The
material check corresponds to the check performed via application
'Work with Production Orders' (8102), option
'Check Mat' and is performed on the same terms. In case
of missing materials, they will be displayed in a dialog box.
Backward Dating in Fine Planning
You now have the opportunity to date backwards in fine
planning, which means that the dating is made in proportion
to the 'To Date'. Thereby the dating is backwards in time.
Press Enter when the first screen has been filled in (cf
above).
Select Selection, and enter B in the field 'Direction code for
dating' (cf below).
Selection by Production Model
Groups
It is now possible to work with a fixed selection on production
model groups when you work with the different production
order types. The advantage is that you can more
determinedly work with a particular item grouping.
Missing Data for POPX-TS
Previously, the production feedback via the MARK time registration
system did not transfer a time stamp to the POP
files:
Production follow-up – flow items (POPFREG)
Production follow-up – journal headers (POPJREG)
Production follow-up – capacity (POPKREG)
Production follow-up – stock items (POPLREG)
Production follow-up – operations (POPOREG)
Feedback texts (POPTREG)
A time stamp has now been implemented, thus improving
the possibilities of examination.

Max Size of Data Queues
The use of data queues previously had an inexpediency:
When for example multi-changes of a file, such as the item
file, had been performed, the data queue created in connection
with a replication between intercompany companies
was created with a standard size of 16 MB. This would
cause problems if the number of changed records in the
file was great.
This has been corrected in release 9.1 where data queues
are now being created with a standard size of 2 GB.
Please note: This correction has been made for iSeries
V5R1M0 onwards.
Function Groups with Company
Parameters A9145 and A9141
In the applications 'Work with Stockholdings' (9145) and
'Work with Inventory Transactions' (9141) it is possible to
control which transactions the individual user is allowed to
make. The control is made via the company parameters
'Inventory transactions – optimizing parameters for Work
with' (A9145 and A9141). This function has now been extended
so that it is also possible to define per function
group which transactions are allowed. This will be helpful in
connection with managing the transaction authorities
where companies manage employees’ user authorities by
function groups.
Workflow for Approval of
Supplier Invoices
Some users have wanted the possibility of approving supplier
invoices via Espresso Workflow in ASPECT4 Logistics.
This will be available in the future if you buy an additional
module.
Workflow Prerequisites
In order to implement the workflow module, ASPECT4 Logistics
must be release 8.1.6 or later, and your ASPECT4
ACS and Financial Management must be release 8.3 or
later. Furthermore, you must have the proper licences for
Espresso, and your mail program must be Lotus Notes. The
sales promotion material that will be prepared for the solution,
will include an overview of the required licences.
The solution will be implemented in 'Work With Supplier Invoice
Receipts' (7166); therefore, you must apply this access
to receiving supplier invoices. It is a further prerequisite
that the voucher number for the invoice is unique. A
setup by which a voucher number is taken automatically,
will ensure the uniqueness.
Workflow Description
The flow chart on the next page illustrates the business
procedure supported by Espresso Workflow.
When you enter an invoice in 7166, a label will be printed
to be put on the invoice for the subsequent scanning (after
the posting). The label will have the id under which the invoice
will be saved in MultiArchive, and the id to be applied
for initiating the workflow on the correct invoice.
A voucher will be posted whether or not it has been approved.
The difference is told by the transaction id by
which the voucher is posted to the general ledger. When
there is a mismatch between order and invoice, the
workflow will be initiated during the scanning. In the
workflow, the invoice can be approved for payment. This
will result in the transaction id being changed. The invoice
can also be rejected. The way this should be handled, is
determined by the individual installation – it can be made
by modifications in 7166 or by a modification of the ledger
transaction.
It is a prior assumption to approving invoices via Espresso
Workflow that a workflow has been set up and rules have
been specified in MultiArchive. Please note the following:
• ASPECT4 Logistics standard functionality for defining tolerances
to acceptable deviations is applied. Thus a
workflow is only initiated when the deviation exceeds a
specified percentage or amount and the invoice is
thereby not approved.
• A voucher cannot be approved in the workflow until the
transaction has been transferred to ASPECT4 Financial
Management. It may therefore be necessary to update
the general ledger more frequently than hitherto.
35

Espresso Workflow will support the below business procedure with an ASPECT4 customer:
36
Registration of .
supplier invoice
(7166)
Does invoice
match order?
Yes
Approved
for payment
Posting
with code 31
No
Print label
(7461)
Posting
with code 38
Scanning and
registration in
MultiArchive
Scanning initiates the workflow
Await
credit note and
new invoice
Approval via
Espresso
Workflow
Reject
payment
Handling
Fx Fx
Change
ledger
trans
Approve
invoice
Change of code
38 to 31 on
ledger trans

New Standard Cost Methods
It is now possible to work with different standard cost
methods in ASPECT4 Logistics. The alternative methods
are:
• Standard Cost Price (Std Cost)
• Actual cost by weighted average (Avg Cost)
• Actual cost by theoretical FIFO (Fifo Cost)
Implementing either average cost price or FIFO cost price
requires that all stock transactions from sale, production,
and purchase are updated (semi) online.
It is also a prerequisite that manual registration is disabled
on the following transaction types:
• TP – receipts from production
• TI – receipts from purchase
If average cost price or FIFO cost price is applied for feature
items, a complete feature/option cost price specification
must be applied.
You can select cost price method per item number. The
cost price methods are applied for example for reporting of
stock values.
A working paper will be prepared about the cost price concept
in ASPECT4 Logistics. Therefore you will not find a
complete description here.
Product Configuration during Sales
Order Registration
The use of the product configurator is often closely related
to selling a new item. So far, selling a new item has required
the creation of a number of master data, such as
basic item information and sales item information, the
building/configuration of a production model, the calculation
and registration of cost price and sales price.
These tasks are now integrated in one operating cycle so
that they can be performed in connection with the order
registration in the "Work with …" applications 6102-6106.
During the recording of the sales order line, the system will
check whether a configuration model is associated with the
item as a production model. In the affirmative, the product
configurator is called when you try to record a sales order
line on the item.
Master data creation is performed partly by copying from
the configuration item, which is our basis, and partly by
calculations based on the configured production model.
CROSS-DISCIPLINARY ENHANCEMENTS
This is illustrated in the example below:
The configuration item is created in application 'Work with
Basic Items' (9102) and application 'Work with Sales
Items' (1904). Its default production model must be the
configurator model from which you want to configure.
When entering the configuration item on a sales order line,
the following must be performed:
1. In a dialog box you specify the name of the new production
model. It will also be the name of the basic item
and the sales item being created.
2. Now information about the basic item and the sales item
is copied on the basis of the configuration item. After
copying, you have the opportunity to edit the information.
Which fields are included in the edit screen is controlled
by the screen setup. This means that you can set
up that only those fields must be displayed that have to
be changed compared with the configuration item.
If no fields have been selected, the edit screen will be
skipped.
3. Then the configuration window will appear for configuring
the production model.
4. When the configuration has been completed, you can
have all lines of the configured production model displayed.
Thus it is possible to perform manual corrections
37

38
on the model after the configuration has been completed.
Whether or not you want to have the lines displayed
can be controlled by the company parameter
'Sales Configuration' (KONFIGS).
5. Then the cost and sales price will be calculated, and the
prices will be created in their respective files. Before
creating the sales price, however, it can be corrected in
this screen:
The sales price is calculated as cost + mark-up percentage
from the sales item information.
6. When this screen is confirmed, the sales order line will
be updated with the new configured item number and
sales price.
A firm order line created in this way can be reconfigured if
the customer requires some changes later on. However, it
is a precondition that the item is not in stock and that production
has not be initiated. When you reconfigure, the
production model, cost price, sales price, and sales item
line will be updated.
In the company parameter 'Sales Configuration' (KONFIGS)
you must specify whether the sales price must be created
in application 'Work with Basic Prices' (6115), and you
must specify parameters for the creation of sales price and
for the formats in edit screens for basic and sales item.
Besides, you must specify whether you want the lines of
the configured model to be displayed after configuration.
Configuration of Item Set
When you sell an article, you often need or want to sell accessories
for it.
For example, a door sold might require a casing. Depending
on the type of casing, particular hinges could be required,
and a door knob might have to be chosen as well.
This scenario has previously been met by applying item
sets, but as it will appear from the above example, the
number of combinations will soon grow high. Alternatively,
the shop assistant’s product knowledge has to be great in
order to be able to guide the customer in available combinations.
In order to make this situation more flexible, the product
configurator can now also be applied for configuring item
sets. Hereby the item set can be configured at the time of
selling, and the sales assistant can be guided through the
possible combinations.
The functionality is similar to the one known from configuring
production models, and as described previously, you
can now perform the configuring when you enter the sales
order lines.
The below applications are used in connection with building
configurator models:
Work with Configuration Variable (9115)
Work with Prod Model Process Stages (9119) - New
Work with Configuration Models (9120)
In connection with configuration from sales order lines, you
can set up in the company parameter 'Sales configuration
(KONFIGS) whether you want to create item information
on the item set header. This is required to enable
reconfiguration. Computation of sales price on the item set
header is performed as a summation of the sales prices on
the item set. If you want to create the sales price in application
'Work with Basic Prices' (6115), this will always be a
customer-individual price.
Item Number and Name
Retrieval of item number + item name + features + option
for external papers has been coded in many different
ways.
In this release we have uniformed the way in which this information
is retrieved, irrespective of its purpose, and we
have simplified the way it is being retrieved.
It is now possible both via eXposer and on a "green"
screen to maintain feature numbers by language, feature
name by language, supplementary texts for the features
by language, option number by language, and option
names by language.
Description of the old solution
Retrieval of item number + item name + features + option
for external papers has been coded in many different
ways. For example for the printing of invoice, the information
is retrieved in one way for printing on paper (spool).
For the same item line the information is retrieved again
when it is stored in EDCLREG (for EDI and DocManager).
The charge lines will retrieve the same information in a
third way. When data (EDCLREG) are submitted to
DocManager, part of the above information is retrieved
once again.
As it appears from the above example, the same information
is retrieved several times in the same program and

even coded in different ways. And the same information is
retrieved in other programs (print order, print delivery
note, print packing list etc.), but coded in a slightly different
way.
Maintenance of supplementary texts for sales items is
made via application 9104 by language. If maintained on a
"green" screen, the texts will be stored in TEXTREG with
TEXT-TYPE =’U’. If maintained via eXposer, they will be
stored in TEXTREG with TEXT-TYPE=’J’. Likewise for texts
for purchase items.
In connection with printing external papers via
DocManager, data to be printed will be stored in fx
EDCLREG (EDFLREG and EDPLREG). This file should contain
everything needed at line level. However, the file does
not contain sufficient information about features and options.
Therefore, when transferring to DocManager, the information
will be retrieved once again.
Today, features and options are maintained via 'Work with
Features' (9111). Via this application you can:
• Maintain a feature in language 00, i.e. number, name,
etc.
• Maintain feature name in other languages
• Maintain supplementary texts for the feature in language
00
• Maintain supplementary texts for the feature in other
languages (this applies to eXposer, only)
• Maintain options in language 00 for a feature, i.e. number,
name, etc.
• Maintain option name in other languages
The issues of this solution are:
• You cannot maintain feature numbers by language.
• You cannot maintain option numbers by language.
• There are "old" feature numbers by language in
TEXTREG. The retrieval programs expect to find them in
SPOTREG.
• There are "old" option numbers by language in TEXTREG.
The retrieval programs expect to find them in SPOTREG.
• Maintenance of supplementary texts for features are
stored in TEXTREG.
According to the description of TEXT-TYPE, the TYPE must
be 'D' for supplementary texts in language 00 and 'Y' for
other. The principle of having a different TEXT-TYPE depending
on the supplementary texts being by language
or note, is outdated. The retrieval programs have not
been made according to it.
Description of Enhancement
Functionality and user interface
For this release 9.1 we have developed a new sub-program
ZVAREINFO that can retrieve information about item number,
item name, features, and options. Programs printing
external documents relating to sale or purchase have been
adjusted to apply the sub-program.
After we have started to maintain supplementary texts in
several languages in eXposer in the "same screen", these
supplementary texts are stored in TEXTREG with the same
TEXT-TYPE. Supplementary texts for sales items by language
have therefore been moved from text type 'U' to
text type 'J', and supplementary texts for purchase items
by language have consequently been moved from text type
'W' to text type 'I'. A conversion language has been made
for this. The field description for TEXTTYPE has been updated
in accordance with the above.
The files EDCLREG, EDFLREG, and EDPLREG have been extended
with sufficient information about features and options
so that it is no longer necessary to get the same information
once again in connection with printing via
DocManager. The programs writing in these files have been
adjusted so that the new fields are filled in correctly.
DocManager layout has been adjusted accordingly.
The problems about maintaining features and options have
been solved:
• Feature numbers can be maintained by language via application
9111.
They are stored in SPOTREG (field name DIMHNR).
• "Old" feature numbers by language were stored in
TEXTREG. They must be moved to SPOTREG. A conversion
program has been developed for this purpose.
Retrieval programs for feature numbers by language expect
to find them in SPOTREG.
• Option numbers can be maintained by language via application
9111.
They are stored in SPOTREG (field name DIMLUDF).
• "Old" option numbers by language were stored in
TEXTREG. They must be moved to SPOTREG. A conversion
program has been developed for this purpose.
Retrieval programs for option numbers by language expect
to find them in SPOTREG.
• After we have started maintaining multi-language
supplementary texts in eXposer in the "same screen",
the supplementary texts are stored in TEXTREG with the
same TEXT-TYPE. Therefore, supplementary feature texts
by language must be moved from text type 'Y' to text
type 'D'. A conversion program has been made for this
purpose.
• The field description for TEXTTYPE has been updated accordingly.
• Printing programs retrieve information about features
and options according to the above.
39

Databases
The below fields have been added to EDCLREG:
EDCLUDFNE1 – 5 30A Option names – external
EDCLDIMNE1 – 5 30A Feature names – external
EDCLANEUD1 – 5 5A Facility – Option names
– external
EDCLANEDN1 – 5 30A Facility – Feature names
– external
The below fields have been added to EDFLREG:
EDFLUDFNE1 – 5 30A Option names – external
EDFLDIMNE1 – 5 30A Feature names – external
EDFLANEUD1 – 5 5A Facility – Option names
– external
EDFLANEDN1 – 5 30A Facility – Feature names
– external
The below fields have been added to EDPLREG:
EDPLUDFNE1 – 5 30A Option names – external
EDPLDIMNE1 – 5 30A Feature names – external
Conversion
Conversion of TEXTREG is made by the conversion programs
KONTEXT91A and KONTEXT91B.
40
Copying in Relation to Item Features
In application 'Work with Features' (9111), copying in
eXposer differed from copying on a 5250 screen. Copying
in eXposer has been considered a new creation compared
to the sub-elements (options and text elements). This has
now been corrected so that when a transaction is copied in
'Work with Features' (9111), the sub-elements are copied,
too.
Print Options in 'Calculate Costs for
Purchase Items' (9231)
In the application you can select whether or not to print a
list when you have modified cost or simulation prices. Previously,
you had two options: print a list with all purchase
items or do not print. Your options are now:
0=No print
1=Print Created/Modified Prices
2=Print
Restructured Financial Interface
The interface to ASPECT4 Financial Management has been
restructured from applying a fixed file layout to applying a
command style. This makes the interface more flexible,
e.g. you can modify field sizes in one system without necessarily
having to modify them in another system at the
same time.

STFE Processing under eXposer
The STFE processing on a 5250 screen is based on cursor
locations when moving and copying fields. This cannot be
applied under eXposer.
Moving and copying under eXposer has now been enabled
by selecting the location. The right-click options – they can
also be reached by shortcut keys – are:
Move - Select lines to move.
Copy - Select lines to copy.
Insert selected - Select the location where your selected
lines must be moved or copied to.
Skip - Skip the line
Move up - Move the line 1 line up.
Move down - Move the line 1 line down.
In the window below, three lines have been selected for
moving.
TECHNICAL ENHANCEMENTS
The three lines selected are grey. The user has then rightclicked
on line 17. If you select 'Insert selected', the three
lines will be moved and inserted before the line 'Number of
decimals'. If you select 'Move', also line 17 will be selected
for moving in which case you must select 'Insert selected'
somewhere else in the list.
By right-clicking on for example three lines (they will turn
blue) and selecting 'Move up' or 'Move down' (or Alt+Gr U/
D), the lines will be moved up or down, and you will keep
the blue selection. Thereby you can move the lines up/
down several times by pressing Alt+Gr U or Alt+Gr D several
times.
Besides, in some screens editing has been enabled in the
list panel; hereby the STFE settings are now easier to
make under eXposer than under the 5250 emulation.
41

Field Display Method
In release 9 the field 'Field Display Method' was added. In
release 9.1 even more display methods have been introduced:
Default
No overriding.
Text only
Field contents are displayed without label text or trail text
and cannot be edited.
Combo box
The field is displayed as a combo box. Example:
The general layout of the combo box is controlled by the
system parameter eXposer.
Field group
A group of fields, e.g.:
The heading 'Text' is of type 0; i.e. it would be a tab if this
was not defined as a field group. The field group ends with
a blank field of type 0, specified as a field group.
Radio group
A group of options of which only one can be selected.
Example:
The values for the radio group are found via a company
parameter. Therefore, the text type must be F, and the text
entry must be the name of the company parameter.
F4 Liste
F4 ability (often default).
42
Shortcut F4
You may have experienced some inexpediency about shortcuts
in an F4 application, e.g. during creation of a sales order
line where you select the item number via F4. Now all
shortcuts are enabled in F4 applications as well.
External Documents in DocManager
Previously, the below three documents could not be printed
via DocManager:
• Proforma Invoice
• Reminder Purchase
• Quotation
The documents can now be printed via DocManager like all
other external documents.
Call PC Applications via Shorcuts
There are three applications: PC01, PC02, PC03, where you
can define different parameters in the 0128 record. According
to the below example, the functionality may be
used for getting product images by pressing a shortcut.
By means of the LDA positions 440 for language and 585
for item number and the path type P1 (defined as a path in
application 'Work with PC Paths' (9187)) you can now call
the application and view your product images.
The path P1 may look like this:
J:"/company/docs/images/&&/V&&&&&&&&&&&&&&&&.jpg"
It is a prerequisite for using this type of applications that
you have saved your data in a structured way.

Implementing Release 9.1
This implementation guide covers the upgrading from
ASPECT4 Logistics Release 9 to ASPECT4 Logistics Release
9.1.
The guide deals with implementation in test environment
as well as in operating environment.
Preparation
You should read this document before upgrading.
Before upgrading, your release level of ASPECT4 Logistics
must be 9.0.5 at a minimum. Whether the environment
has been upgraded to the required level can be checked
via application Conversion (0690) by entering 5 next to
system 416. If you have not upgraded to level 9.0.5,
please contact EG.
Before upgrading, your ACS release level must be 9, and
we recommend that ASPECT4 Financial Management is also
upgraded to release 9.
The upgrade method implies an upgrade of the test environment
first. Testing must be made in this environment
during a test period. On upgrading of the operating environment,
certain test environment components are put into
operation. This regards individual programs and images.
Usually it will be advantageous to have a test environment
based on relatively new data from the operating environment,
and it might also be of an advantage that the test
environment contains a true replica of the operating
environment’s program library, including updated userindividual
images, as these are restored to operation on
launch.
Therefore, we recommend that you set up a new test environment
before upgrading.
The description refers to XX and YY, which is the environment
installation prefix. (This may be found via application
Work with Packets (9165): Select file group ADRS by
means of option 7 and read file library name against one of
the files. Installation prefix may then be viewed as the
first two characters of this library name). Below, XX and YY
may be the prefix of an operating as well as a test environment.
The ASPECT4 Logistics environment to be upgraded must
not have any active jobs. If there are active batch jobs,
stop them. If there are active users in the environment,
ask them to log off.
Apply the command WRKOBJLCK VIRKREG *FILE to see if
there are jobs. If the list is empty, press F6 to view member
locks, if any. As an alternative method, use iSeries
Navigator to see any locks on the file VIRKREG.
IMPLEMENTATION
Batch jobs requested to run automatically via the application
'Work with Job Definitions' (9176) must be held as
long as the upgrading takes place
Before starting the upgrading in the operating environment,
we recommend that transaction data are updated to
maximum practicable extent.
To achieve a maximum update of data, run the following
applications:
Print Receipts Journal (7260)
Print Production Feedback Trans (8260)
Print Inventory Journal (9201)
Update Finance (9283)
Before upgrading the operating environment, make a tape
backup and/or disk backup of the following libraries:
XXKOMFIL
XXKOMPGM
XXKOMSRC
XXKOMBATCH
EGSPCDTA
EGDTA
Receiving and Installing Packages
In order to carry out the upgrading, you must receive and
install various packages and updates. Receiving must be
performed only once. Installation of packages with the two
program libraries R91ALPGM and R91ALSRC also needs
performed only once.
Sign on to the ASPECT4 operating environment as the user
EDBGRP.
Receive the following shipments in the operating environment’s
application 'Installation in Prod. Environment'
(0590):
• Basic package 416-9100
• Conversion package 416-9180
• Update, if any, of individual programs and sources
• Update, if any, of individual data elements
Receive and install the following shipments in the usual op-
erating environment:
• Dispatch containing package 416-9101 (R91ALPGM)
• Dispatch containing package 416-9191 (R91ALPGM)
• Dispatch containing package 416-9192 (R91ALPGM)
• Dispatch containing package 416-9102 (R91ALSRC)
When these four packages are installed, they must be deleted
in application 'Installation in prod. environment'
(0590) in order to release disk space.
43

Environment Setup
Maintain 'Environment Setup in ASPECT4' via application
0108.
If a setup for test environment already exists, replace
R9KOM* with R91AL*.
If no setup for test environment exists, a setup must be
made with the same library list as exists in the test environment
application 'Maintain general files' (0050), section
0154; however, stating R91AL * instead of R9KOM*. And if
there is exactly one company in the test environment, the
record is deleted in application 'Maintain general registers'
(0050), section 0154. Otherwise, library lists are adjusted
for the individual companies in the test environment so
that R9KOM* is again replaced by R91AL *.
Make the same modifications for the operating environment.
Only, do not change R9KOM * to R91AL * until during
upgrading.
You may have to modify user profiles in application 'Maintain
user authorizations' (0110). If the users do not already
have attached operating/test environments defined
in application 0108, you must attach environments now.
Individual OS/400 user profiles must also be adjusted in
application 'Maintain user authorizations' (0110) via option
8, stating 'ASPECT4’ as 'Initial program to call’ and
'EGAKS400’ as 'Library’.
Adjust job description in XXKOMBATCH, replacing R9KOM*
with R91AL *.
In case of integration from ASPECT4 Logistics to other systems
it may be necessary to make changes in the connection,
e.g. modifying library names from R9KOM* to
R91AL*, deleting and rebuilding logical files, changing layout
programs and archive programs.
Relevant systems might be e.g.:
• Interform
• MultiArchive
• VIS
• Targit
44
Upgrading Test Environment
The files MESSREG and OVERREG must be copied from
R9KOMPGM to R91ALPGM in order to maintain existing individual
systems texts and report headings.
Do not forget to close the file MESSREG (CLOF MESSREG)
before copying.
If the command CPYF is used from a command entry line,
the two commands will be executed as follows:
CPYF FROMFILE(R9KOMPGM/MESSREG)
TOFILE(R91ALPGM/MESSREG) + MBROPT(*REPLACE)
FMTOPT(*MAP)
CPYF FROMFILE(R9KOMPGM/OVERREG)
TOFILE(R91ALPGM/OVERREG) + MBROPT(*REPLACE)
FMTOPT(*MAP)
You may choose to copy the files via iSeries Navigator instead.
Since this is a release update, old individual objects and
sources will typically have to be deleted and replaced by
updated ones, received from EDB Gruppen. This deletion
takes place on further agreement with the usual ASPECT4
Logistics consultant.
Call application 0696. Choose to work with objects and
specify XXKOMPGM as the object library.
In the test environment program library, XXKOMPGM, the
relevant of the following is removed:
Object Object type Attribute
*ALL *PGM
*ALL *FILE DSPF
*ALL *FILE PRTF
*ALL *CMD
Call application 0696. Choose to work with objects and
specify XXKOMSRC as the object library. Specify the following:
In the list, select with option 12 the individual Q* files.
Then remove the relevant sources with option 4.

In application 'Maintain application parameters' (0128), adjust
application 059x as regards setup of library lists for
receipt and entering of dispatches. Normally, application
0591 is used for the test environment.
Maintain application 059x via application Maintain application
parameters (0128), select 10 = Maintain parameters
and 1 against EGKOMA:
In application 'Maintain application parameters' (0128) set
the additional parameters for application 059x by using option
10=Maintain parm. Select EGKOMB by option 1:
The operating environment’s prefix is denoted by XX. The
test environment’s prefix is denoted by YY.
If you have a shipment containing an update of individual
programs and sources, you must now receive and install it.
Now proceed with the steps mentioned below under "Upgrading
Test/Operating Environment".
Upgrading Operating Environment
In application 'Maintain application parameters' (0128) set
the parameters for application 059x regarding the setup of
library lists for receiving and loading shipments. Normally,
application 0590 is used for the operating environment.
In application 'Maintain application parameters' (0128) set
the additional parameters for application 059x by using option
10=Maintain param. Select EGKOMA by option 1:
In application 'Maintain application parameters' (0128) set
the additional parameters for application 059x by using option
10=Maintain param. Select EGKOMB by option 1:
Sign on as user QSECOFR and delete the old operating
environment’s program and source library by using the below
commands:
DLTLIB LIB(XXKOMPGM)
DLTLIB LIB(XXKOMSRC)
The test environment’s programs and screen displays have
been upgraded and maintained during the test period.
Therefore, these libraries must be used in the future operating
environment.
Copy the test environment’s program library and source library
by entering the below commands - the test
environment’s prefix is denoted by XX. The operating
environment’s prefix is denoted by YY.
CPYLIB FROMLIB(XXKOMPGM) TOLIB(YYKOMPGM)
CPYLIB FROMLIB(XXKOMSRC) TOLIB(YYKOMSRC)
45

Upgrading Test/Operating Environment
Sign on to the relevant ASPECT4 Logistics environment as
user EDBGRP.
Run program R9TILR91 and fill in as illustrated below:
Group and company number must be filled in with the specific
values. Values may be found by pressing the Home
key in the menu.
When the parameters for the upgrading command have
been filled in, press Enter. Now a list will appear of temporary
conversion files in XXKOMFIL, characterised by their
names containing *CO*, and then a list of files in
XXKOMPGM. These files must be deleted or renamed before
upgrade can continue. Now the upgrading proceeds,
converting modified files, building new files, and running
various conversion programs.
Load the shipment containing the basic package (416-
9100) and the conversion package (416-9180).
If you have received a shipment containing update of individual
data elements, you must load it now. When upgrading
the operating environment, omit the field definitions by
leaving the relevant field blank during loading via 059x.
Now look through application depending data via application
'Maintain Application Parameters' (0128). Look through
the company file via the applications 'Work with System
Parameters' (9001 and 9002), or alternatively 'Work with
System Parameters' (9006 and 9007).
In application 'Work with Report Headings' (9168) report
headings with a specified installation id must be reviewed
and modified if required. You must also review headings in
foreign languages concerning external documents (applications
'Print xxxx' (623x/723x)).
After various test routines the environment is operating.
When everything has been found OK, clean up so that all
temporary conversion files will be removed. Use the command:
WRKOBJPDM LIB(XXKOMFIL) OBJ('*CO*’) OBJTYPE(*FILE)
- and similarly on XXKOMPGM
Comments
46
Field Definitions
During upgrading, new/changed field definitions will be
loaded for the below batch applications:
Update Sales Prices (6213)
Transfer Blanket Order to Budget (6225)
Print Quotations (6231)
Print Order Confirmations (6232)
Print Delivery Notes (6233)
Print Invoices/Credit Notes (6235)
Print Collective Invoices/CredNotes (6236)
Print Packing Lists (6254)
Print Allocation List (6420)
Print Sales Budgets (6421)
Print Budget Comparisons (6424)
Print Sales Order Receipts (6434)
Print Sales Order List (6437)
Print Sales Statistics (6475)
Print Purchase Orders (7232)
Join Production Orders (8210)
If you have made your own special versions of these applications,
you must test them in connection with the upgrading.
Possibly you will have to rebuild them. Individual users
may be identified via application 'Work with fixed batch
definitions per application' (9177). Modifications may also
be required in connection with setting job definitions for
these batch applications via application Work with Job Definitions’
(9176):
Company Parameters
We refer to the separate documentation regarding these
release items for an overview of concerned company parameters.
Creation of IC Type
Create in 'Work with PC Paths' (9187).
Path type: IC
Path: com/edbgruppen/aspect4/dataengine/icons/
Triggers
When the upgrade has been completed, any triggers must
be readded to files in application 0172.
The library name (e.g. R9KOMPGM) is stored in user space
with object name = file name.

We create value for you,
your business and your customers
At EG we always think in solutions as a whole rather than just technology. In
this way we create value for you, your business and your customers. When
you cooperate with EG, you get a strong and solid partner, who knows the
value of long and close relationships. We listen to your knowledge, talk your
language and share our experience with you – in order for us together – to
develop the right solution to your company.
We help you to develop your business through consultancy and implementation
of IT solutions – always focusing on ensuring a good return on investment
– and a calm and secure working day. Our goals are clearly defined for
the work processes, optimisation and technology support when we develop
solutions in cooperation with our customers.
We call it ”Adding value to business”.
Learn more about ASPECT4 Logistics
Call Bo Eriksen and hear more about
how we can create value for your business
with our knowledge and ASPECT4.
Tel.: +45 79 38 38 08
E-mail boe@edbgruppen.dk
Read more of our comprehensive
competencies on www.eg.dk/logistik