chapter 6 transaction file processing

INSIGHT

Chapter 6

Transaction File Processing

6.1 Introduction

Purpose The purpose of this chapter is to introduce one of the most unusual andpowerful features of SAILS—its ability to process transaction historyfiles. Perhaps nowhere else does SAILS come closer to the real worldexperienced by the logistics professional, a world often dominated bycustomer order processing and shipping and receiving.

Transaction history files allow you to explore in great detail how alogistics system truly operates. They can significantly improve theaccuracy of the SAILS database, can ease difficult data preparationchores, and can provide great flexibility to modelers. But these benefitsare not gained without cost. One notable cost is the effort required tobridge the gulf between detail (individual transactions) and summary(the strategic network design model). Another cost is the considerableeffort required for data processing. Transaction history files also thrustyou squarely into the world of serious data processing. Efficientprocedures are required to build, store, examine, process, andsummarize files that can easily contain several million data records.

The objectives of this chapter are to:

• define the concept of the transaction history file

• list the types of transaction files recognized by SAILS

• explore the advantages of transaction files

• describe the content of each transaction file

• introduce the concepts of data recoding and data aggregation

• describe the nature of transaction file processing

• summarize the results obtained from transaction file processing

• develop an action plan by discussing the steps required to prepare atransaction file and its associated “bridge” data

6-2 CHAPTER 6: TRANSACTION FILE PROCESSING

INSIGHT

6.1 Introduction, continued

In thisChapter

The Transaction File Processing chapter is organized as follows:

Section Page6.1 Introduction 6-1

Purpose 6-1In this Chapter 6-2Before You Begin 6-3

6.2 Understanding Transaction File Types 6-56.3 Understanding the Purpose of Transaction

Files6-6

6.3.1 Overview 6-66.3.2 Written Reports 6-66.3.3 Cost/Flow Baseline Analysis 6-66.3.4 Aggregation Flexibility 6-76.3.5 Customer Demands 6-76.3.6 SHIPCONS 6-8

6.4 Understanding Transaction File Content 6-96.4.1 Overview 6-9

Five Measures of Volume in Records 6-96.4.2 Inbound, Replenishment, and DC

Transfer SAILS Transaction Files6-10

6.4.3 The Outbound Transaction File 6-146.4.4 Miniature Transaction Files 6-18

6.5 Recoding and Aggregating Data 6-196.5.1 Bridging the Gap between Transaction

Files and the Model6-19

6.5.2 Using Cross-Reference Tables to Recode Data

6-19

6.5.3 Using Cross-Reference Tables to Aggregate Data

6-21

6.5.4 Applying Recoding/Aggregation to Transaction File Processing

6-21

How SAILS Recodes/Aggregates Files 6-226.6 Understanding File Processing 6-23

Overview 6-236.6.1 Inbound, Replenishment, and DC

Transfer Files6-24

Processing Logic for Inbound, Replenishment, and DC Transfer Files

6-24

6.6.2 Outbound Transaction File 6-26 Processing Logic for Outbound Transaction Files

6-26

Additional Facts about Outbound Transaction File Processing

6-28

continued on the next page

SAILS OPTIMIZATION SOFTWARE 6-3

INSIGHT


In thisChapter,continued

Section Page6.7 Understanding Transaction File Processing

Results6-31

6.7.1 Written Reports 6-316.7.2 Historical Flow Percentages 6-336.7.3 Customer Demand Table 6-366.7.4 SHIPCONS Input 6-37

6.8 Preparing Transaction File Data 6-38Prepare an Action Plan 6-386.8.1 Preparing the Actual Transaction File 6-38

Overview 6-38 How to Prepare Transaction Files 6-39

6.8.2 Preparing Recoding/Aggregation Data 6-39 Overview 6-39 Commodity Recoding/Aggregation Data

6-40

Facility Recoding/Aggregation Data 6-42 Customer Region Recoding/ Aggregation Data

6-43

State/County Code-Based Customer Aggregation Tables

6-46

How to Customize Aggregation Codes 6-46 Customer Class Code Recoding/ Aggregation Data

6-48

About Customer Class Strategy 6-486.9 A Final Perspective 6-53

Before YouBegin

Before you proceed with this chapter, you may wish to review theseterms:

• ECUs European Currency Units

• FIPS Federal Information Processing Standards

• transaction history this file is extracted from a company'sfile invoice or shipment history data, where each

data record corresponds to a single item on anactual invoice or shipment from an origin to adestination. As illustrated by the outboundtransaction file in Figure 6-1, a transaction fileconveys to SAILS the


INSIGHT


Before YouBegin, continued

historical pattern of commodity movements inthe logistics network throughout the chosenbase time period. Other information typicallyfound on the original company's transactionfile, such as detailed street addresses, billingaddresses and codes, credit authorizationcodes, etc., are not relevant to SAILS models;therefore, they are not included in a SAILStransaction history file.

Transaction History File Records

document number customer account ship-to-address shipment origin item code quantity date

InvoiceInvoice

Invoice

Figure 6-1. General contents of an outbound transaction history file. Each data recordcontains the listed information and corresponds to a single line item on a single invoice orshipment.


INSIGHT

6.2 Understanding Transaction File Types

In earlier chapters, we defined the five major kinds of transportationlinks that SAILS recognizes: inbound, interplant, replenishment, DCtransfer, and outbound. Of these, SAILS recognizes four correspondingtransaction file types, as follows:

Inbound shipments of raw materials from rawmaterial suppliers to plant locations

Replenishment shipments of finished products fromplant locations to DC locations

DC transfer shipments of finished products fromDC locations to DC locations

Outbound shipments of finished products fromDC locations to customer regions

Figure 6-2 shows the position of each link type using our standardOPTIMA model illustration.

S1

S2

P1

P2

P3

PW1

PW2

PW3

FW1

FW2

FW3

FW4

FW5

CR1

CR2

CR3

CR4

CR5

CR6

Raw Materials

Intermediate Products

Finished Products

ReplenishmentInbound Interplant DC Transfer Outbound

*

*

*

*

*

*

Legend: S= Supplier, P = Plant, PW = Plant Warehouse, FW= Field Warehouse, and CR= Customer Region

Figure 6-2. The OPTIMA model schematic, showing all link types that you use to buildany OPTIMA model. Inbound, interplant, and DC transfer links are optional.


INSIGHT


INSIGHT

6.3 Understanding the Purpose of Transaction Files

6.3.1 Overview

There are five major reasons for preparing transaction file inputs toSAILS:

1 to analyze historical commodity flow patterns via written reports

2 to facilitate preparation of a historical cost/flow baseline

3 to provide a flexible method to change the underlying SAILS model,especially for commodity groups, customer regions, and customerclasses

4 to provide a reliable source of customer demand data

5 to drive the SHIPCONS traffic management simulation model

Reasons 4 and 5 apply only to outbound transaction files. You can learnmore about all these reasons in the next five sections.

6.3.2 Written Reports

SAILS can generate a wealth of statistical analyses of the contents of atransaction file. These analyses may include aggregate volume totals;order/shipment size analysis; monthly, weekly, and daily seasonalanalyses; and market penetration analyses of outbound transactionfiles. You may find these reports useful in their own right; they providebetter understanding of the logistics system under study. Or, you mayfind that they confirm information that is already available. In eithercase, they are important validation tools for a transaction file, enablingyou to compare its contents with known historical values.

6.3.3 Cost/Flow Baseline Analysis

You can generate a model cost/flow baseline:(validation) analysis byreplicating base period network flows, and computing correspondingfacility and transportation costs. You can then compare the results withknown historical values to assess the accuracy of the


INSIGHT

6.3 Understanding the Purpose of Transaction Files, continued

model design and its database. This exercise requires link-specific flowsfor each commodity, a task that can be quite difficult when donemanually. Transaction files simplify the process, because SAILSsummarizes the required historical flow patterns automatically duringfile processing and retains them to use later in the baseline exercise.Cost/flow baseline analysis is explained in Chapter 11 .

6.3.4 Aggregation Flexibility

You learned in earlier chapters that typically, you must aggregate stockcodes into commodity groups, and customer accounts into customerregions to build a SAILS model. If you prepare transaction files, SAILSaccomplishes these tasks on-the-fly during transaction file processing.The aggregation process is guided by a series of recoding/aggregationcross-reference tables that associate individual stock codes withproduct groups, and customer georeference codes or account numberswith customer regions. Therefore, you can alter the definition of anaffected model component by simply changing the correspondingrecoding/aggregation cross reference table and reprocessing theaffected transaction file(s).

6.3.5 Customer Demands

In Chapter 5, you learned about the SAILS customer demandrequirement and the four methods by which it can be satisfied:geographic spread, manual, full transaction file, and the miniaturetransaction file. You also learned that the transaction file-basedapproaches provide the greatest flexibility and ease of datapreparation. In short, an outbound transaction file can serve as theprimary (usually exclusive) source of customer demand data. In mostorganizations, there is no better source of demand information.


INSIGHT

6.3 Understanding the Purpose of Transaction Files, continued

6.3.6 SHIPCONS

You must provide a full outbound transaction history file to activateSHIPCONS, a sophisticated traffic management simulation model builtinto SAILS. Use SHIPCONS to estimate lane-by-lane outbound freightcosts associated with alternative point-to-point rate structures andoperating policies. See Chapter 9 for a detailed presentation of theSHIPCONS input requirements, processing logic, and output files.


INSIGHT

6.4 Understanding Transaction File Content

6.4.1 Overview

To better understand SAILS transaction files, you will next want toexamine their respective layouts, or content. You will find detaileddiscussions and instructions for preparation in the SAILS User Guide,but we offer here a brief explanation of the content of each file, anecessary prelude to discussions about transaction file processing andrecoding/aggregation data.transaction file:content

FiveMeasures ofVolume inRecords

A transaction file record has five distinct measures of volume:

• units

• weight

• cube

• inventory value and

• sales value

These measures form the core of information extracted by SAILS fromany transaction file. Thus, how you use these measures is criticallyimportant if you are to gain the greatest benefits from a transaction file.

To help you understand how best to use these measures we offer somedefinitions and descriptions in the next section.

NOTE: In the descriptions that follow, the word internal refers tothe actual codes used in your business systems to identifyvarious data such as stock codes and facility locations. Forthe moment, we assume that you will prepare a fulltransaction file. Therefore, each data record representsexactly one item on one shipment (that is, each record is a“line item”). We will consider miniature transaction fileslater in this chapter.


INSIGHT

6.4 Understanding Transaction File Content

6.4.2 Inbound, Replenishment, and DC Transfer SAILS Transaction Files

The inbound, replenishment, and DC transfer SAILS transaction filelayouts are shown in Figures 6-3 through 6-5, respectively. Specificformats differ only within fields 2, 3, and 4—the shipment origin,shipment destination, and stock code entries, respectively. Individualdata field descriptions follow:Document # internal shipping document number

(bill of lading #, for example) orequivalent. Use this field exclusively toidentify all records that comprise agiven shipment.

Origin Code internal location code of the actualshipment origin.

Destination Code internal location code of the actualshipment destination.

Stock Code internal item code for a given line item.

Quantity number of units of a given item that areactually shipped. This must be a positivevalue—SAILS drops records with zeroor negative quantities.

Julian Date actual shipment date in Julian formatYYDDD (for example, February 24, 1995is 95055).

Extended Weight total weight of the line item shipped.This can be expressed in any desiredunit of measure, such as pounds orkilograms. It is required only If…

• flows in the corresponding network (raw material or finished product) are measured in terms of weight,

and…

• you do not want SAILS to compute


INSIGHT

the extended weight for you.


INSIGHT

6.4 Understanding Transaction File Content, continued

Extended Cube total cube of line item shipped. It can beexpressed in any desired unit ofmeasure, such as cubic feet or cubicmeters. It is required only If…

• flows in the corresponding network (raw material or finished product) are measured in terms of cube, and

• you do not want SAILS to compute the extended cube for you.

Extended Inventory Value total inventory value (manufacturingvalue) of a line item shipped. It can beexpressed in any desired unit ofmeasure, such as dollars, ECUs, or yen.This field is never required for anySAILS application. Its purpose is to feedcertain transaction file aggregatevolume reports by total inventory value.This has no relevance to the solver. Usethis field only IF…

• you wish to see aggregate volume totals by inventory value, and…

• you do not want SAILS to compute the extended inventory value for you.

Extended Sales Value total sales value (revenue value) of aline item shipped. It can be expressed inany desired unit of measure, such asdollars, ECUs, or yen. This field is neverrequired for any SAILS application. Itspurpose is to feed certain transactionfile aggregate volume reports by totalsales value. This has no relevance to thesolver. This field is required only If…

• you wish to see aggregate volume totals by sales value, and…

• you do not want SAILS to compute the extended sales value for you. It


INSIGHT

is not relevant to the inbound transaction file.


INSIGHT


Mode Code internal code for transportation mode/carrier used for this shipment. This isnot currently used by SAILS, but youcan fill it in for independent analysis.

INBOUND TRANSACTION FILE

ElementNumber

Data ElementDescription

Location (inbytes)

Data TypeDescription

FORTRANData Type

COBOLData Type

1 Document # 1-16 Alpha C16 X (16)

2 Origin Supplier Code 17-20 Alpha C4 X (4)

3 Destination Plant Code 21-24 Alpha C4 X (4)

4 Raw Material Stock Code 25-40 Alpha C16 X (16)

5 Quantity 41-50 Numeric I10 9 (10)

6 Julian Date (YYDDD) 51-55 Numeric I5 9 (5)

7 Extended Weight 56-65 Numeric I10 9 (10)

8 Extended Cube 66-75 Numeric I10 9 (10)

9 Extended Value 76-85 Numeric I10 9 (10)

10 Extended Sales 86-95 Numeric I10 9 (10)

11 Mode Code 96-100 Alpha C5 X (5)

Figure 6-3. Layout of the SAILS inbound transaction history file.


INSIGHT


REPLENISHMENT TRANSACTION FILE

ElementNumber


Location (inbytes)


FORTRANData Type

COBOLData Type


2 Origin Plant Code 17-20 Alpha C4 X (4)

3 Destination DC Code 21-24 Alpha C4 X (4)

4 Finished Product Stock Code 25-40 Alpha C16 X (16)








Figure 6-4. Layout of the SAILS replenishment transaction history file.

TRANSFER TRANSACTION FILE

ElementNumber


Location (inbytes)


FORTRANData Type

COBOLData Type


2 Origin DC Code 17-20 Alpha C4 X (4)

3 Destination DC Code 21-24 Alpha C4 X (4)










INSIGHT

Figure 6-5. Layout of the SAILS DC transfer transaction history file.


INSIGHT


6.4.3 The Outbound Transaction File

The outbound transaction file layout is shown in Figure 6-6. Individualdata field descriptions follow:

Document # internal shipping document number(bill of lading #, for example) orequivalent. You can use an invoicenumber if a shipping document numberis unavailable. Use this field exclusivelyto identify the records that comprise agiven shipment.

Customer Account # internal designation of the actual ship-to (never bill-to) customer location. Thisis used only by SHIPCONS.

Customer Class code used to identify the customer classfor this shipment.

ZIP Code five-digit zip code of the actual ship-tolocation (U.S. only).

State Code numeric FIPS; state code of actual ship-to location (U.S. only).

County Code numeric FIPS; county code of the actualship-to location (U.S. only).

Customer Aggregation Code numeric code used to aggregate actualship-to (never bill-to) customer locationsinto customer regions.

Stock Code internal item code for a given line item.


INSIGHT


Quantity number of units of given item that areactually shipped. This must be a positivevalue—SAILS drops records with zeroor negative quantities.

Origin DC Code internal DC location code of the actualshipment origin. Plant-direct shipmentsare assumed to originate from a plantDC.

Julian Date the actual shipment date in Julianformat YYDDD (for example, February24, 1995 is 95055)

Extended Weight total weight of the line item shipped.This can be expressed in any desiredunit of measure, such as pounds orkilograms. It is required only If…

• finished product network flows and customer demands are measured in terms of weight, and…

• you do not want SAILS to compute the extended weight for you.

Extended Cube total cube of line item shipped. It can beexpressed in any desired unit ofmeasure, such as cubic feet or cubicmeters. It is required only If…

• finished product network flows and customer demands are measured in terms of cube, and…

• you do not want SAILS to compute the extended cube for you.

Extended Inventory Value total inventory value (manufacturingvalue) of a line item shipped. It can beexpressed in any desired unit ofmeasure, such as dollars, ECUs, or yen.This field is never required for anySAILS application. Its purpose is to


INSIGHT


Extended Inventory Value, feed certain transaction file analysiscontinued aggregate volume reports by total

inventory value and/or facilitate certainpost solver inventory analysis reports.This field is required only IF…

• you wish to see aggregate volumetotals by inventory value,

• you wish to obtain certain post-optimization inventory level analysis reports (see Ch 13), and…

• you do not want SAILS to compute the extended inventory value for you.

Extended Sales Value total sales value (revenue value) of aline item shipped. It can be expressed inany desired unit of measure, such asdollars, ECUs, or yen. This field is neverrequired for any SAILS application. Itspurpose is to feed certain transactionfile aggregate volume reports by totalsales value. This has no relevance to thesolver. This field is required only If…

• you wish to see aggregate volume totals by sales value, and…

• you do not want SAILS to computethe extended sales value for you.

Mode Code internal code for transportationmode/carrier used for this shipment.This is not currently used by SAILS, butyou can fill it in for independentanalysis.

Consult the SAILS User Guide for additional data preparationinstructions and for a complete discussion of the output reports anddata files available from transaction file processing. You will then be inan excellent position to finalize your transaction file strategy.


INSIGHT


Data FieldDescriptions,concluded

You do not have to fill in the extended weight, cube, inventory value,and sales value fields on a transaction file, even if you plan to use thisinformation. Rather, you can let SAILS compute the extensions for you,IF you supply the corresponding unit values for each stock code, asdiscussed later in this chapter.

OUTBOUND TRANSACTION FILE

ElementNumber


Location (inbytes)


FORTRANData Type

COBOLData Type


2 Customer Account # 17-32 Alpha C16 X (16)

3 Customer Class 33-36 Alpha C4 X (4)

4 ZIP Code 37-45 Numeric I9 9 (9)

5 FIPS State Code 46-47 Numeric I2 9 (2)

6 FIPS County Code 48-50 Numeric I3 9 (3)

7 Customer Aggregation Code 51-60 Numeric I10 9 (10)



10 Origin DC Code 87-90 Alpha C4 X (4)






16 Shipment Mode 136-140 Alpha C5 X (5)

Figure 6-6. Layout of the SAILS outbound transaction history file.


INSIGHT


6.4.4 Miniature Transaction Files

MiniatureTransactionFiles vs. FullTransactionFiles

The SAILS miniature transaction files are identical in format to the fulltransaction files. However, there is one critical difference—all flows fora given stock code/origin/destination are preaggregated across theentire base time period to a single day.

Follow these steps for various kinds of miniature transaction files:

For these filetypes…

do this…

inbound,replenishment, or DCtransfer transactionfiles

create a single data record for each unique stockcode/origin code/destination code combinationthat had positive flow during the base period.

outbound transactionfile

create a single data record for each unique stockcode/origin DC code/customer aggregationcode/customer class code combination that hadpositive flow during the base period.

In all instances, you should total all active volume measures for theentire base time period: quantity, extended weight, extended cube,extended inventory value, and extended sales value. Select a singledate and enter it on every record.


INSIGHT

6.5 Recoding and Aggregating Data

6.5.1 Bridging the Gap between Transaction Files and the Model

How to Getfrom Here toThere

If you carefully reexamine the preceding transaction file data fielddescriptions, you will notice an apparent omission—there is no directreference to the fundamental model components defined in Chapter 4 ,such as commodity groups and customer regions. Even the fields thatrefer to raw material suppliers, plant locations, DC locations, andcustomer classes are specified in terms of internal company dataprocessing codes—not by SAILS model component ID numbers. Butyou already know that SAILS models are built in part from commoditygroups and customer regions, not individual stock codes and customeraccounts. You also know that SAILS understands the various modelcomponents only in terms of corresponding ID numbers. How can youdeal with these apparent inconsistencies?

To leap the gulf between detail (transaction files) and summary (theSAILS model) you must construct a “data bridge” from a series ofcross-reference tables. SAILS uses this bridge to guide the substitution ofSAILS ID numbers for certain internal codes used in your businessinformation system files, a process known as data recoding. Aspecialized form of data recoding, known as data aggregation, occurswhenever multiple internal codes are associated with a single SAILS IDnumber.

6.5.2 Using Cross-Reference Tables to Recode Data

DataRecodingProvidesBuildingBlocks forthe Bridge

Data recoding is the consistent substitution of one character string foranother, on either a one-to-one or many-to-one basis. In this caserecoding is a simple substitution of SAILS ID numbers for certaininternal data processing codes found on your company transactionhistory files. You can simply set up a cross-reference table:descriptionto designate these substitutions.


INSIGHT

6.5 Recoding and Aggregating Data, continued

This substitution is evident in Figure 6-7, where we illustrate datarecoding with the cross-reference table of cities, internal DC locationcodes, and corresponding SAILS ID numbers. Location codes such as“4A”, “B23”, and “G10” do not follow a universally understood datacoding scheme, such as zip codes, postal codes, state/county codes, ortelephone area codes.

Therefore, SAILS cannot interpret such internal codes correctly withoutadditional guidance. However, by associating a SAILS DC location IDnumber with every internal DC location code that may appear on atransaction file, you effectively tell SAILS about the meaning of eachcode. (We assume here that the middle column in Figure 6-7 is anexhaustive list of such codes). SAILS is now able to substitute an IDnumber for each location code that it encounters when processing atransaction file, and can extract all required data in a formunderstandable to the underlying database manager and solver.

DATA RECODING CROSS-REFERENCE TABLE EXAMPLE

DC Location Name Original DC LocationCodes

(found in transactionfiles; assigned by the

SAILS user)

SAILS DC ID Numbers

New York 4A 10Boston 6CDE 20Charlotte 99 30Atlanta B23 40Jacksonville E11 50Chicago 2244 60Dallas 8709 70Seattle DDZZ 80San Francisco J4 90Los Angeles G10 100Los Angeles G11 100Los Angeles G12 100

Figure 6-7. SAILS uses a series of cross-reference tables to guide the transition frominternal codes found on a transaction history file to the model components used to build aSAILS model. A one-to-one substitution of a SAILS ID number for an internal code isknown as data recoding, while a many-to-one association is known as data aggregation. Inthis example we associate internal DC location codes with corresponding SAILS DClocation ID numbers (the names are not formally part of the real table). Three codes, G10,G11, and G12 are all interpreted to mean Los Angeles—an example of data aggregation.


INSIGHT


6.5.3 Using Cross-Reference Tables to Aggregate Data

Data aggregation is a specialized form of data recoding, where youassociate multiple internal codes with a single SAILS model componentelement. Figure 6-8 illustrates this concept, using a cross-reference tablefor commodity aggregation; here, multiple stock codes are associatedwith each finished product group. You may have noticed that Figure 6-7 also contains an example of data aggregation; in the last three rows,location codes G10, G11, and G12 designate a DC location in LosAngeles. Such a case may occur when there are several publicwarehouse facilities in the same city, or might represent a regionalclustering of facilities (see Chapter 4).

6.5.4 Applying Recoding/Aggregation to Transaction FileProcessing

How SAILSRecodes/AggregatesFiles

The actual process of recoding/aggregation within SAILS is quitesimple. SAILS follows these general steps:


INSIGHT


How SAILSRecodes/AggregatesFiles, continued

Step Action1 Read a data record from the given transaction file.2 Extract the relevant internal code from the data record. (For example, stock

code, location code, customer class code, and so on).3 Search a separate cross-reference table of all such codes and attempt to find

a matching entry. Depending on the data’s nature, SAILS may generate thetable automatically, or the user can supply it, or both.

4 IF… THEN…a match is found • determine the corresponding

model component element• substitute the SAILS ID number• store relevant volume and sta-

tistical data from the data record under the given element.

no match is found • record the unknown code and quantity from the transaction file record and

• discard the record.

For product aggregation, SAILS would apply this process as follows:

Step Action1 Read a data record from the transaction file.2 Extract the product stock code from the data record.3 Search the finished product stock code cross-reference table supplied by the

user and attempt to find a match with the stock code from the transaction file.4 IF… THEN…

a match is found • determine the product group to whichthe user has assigned the stock code

• record demand volume, historical DC throughput, and so on, under the given product group, using the product group ID number.

no match is found • record the unknown stock code andquantity from the transaction file record and

• discard the record.


INSIGHT

6.6 Understanding Transaction File Processing Logic

Overview You can enjoy all of the benefits associated with transaction files withlittle or no technical understanding of SAILS. However, an intuitivegrasp of the underlying file processing logic will enhance your abilityto prepare the required input files, set the appropriate controls, andinterpret the results correctly. To help you, we next describe the step-by-step program operation during transaction file processing. Refer tothe processing logic flowchart in Figure 6-9 as you read the next twosections.

Read Record Any Errors?

Do VolumeExtensions

Standard UnitsConverted?

Record Data

Last Record?

Print Reports

Stop

Record Error

Throw Out Record

Convert Quantity

No

No

Yes

Yes

Yes

No

Figure 6-9. Transaction file processing logic used by SAILS.


INSIGHT

6.6 Understanding Transaction File Processing Logic

6.6.1 Inbound, Replenishment, and DC Transfer Files

ProcessingLogic forInbound,Replenish-ment, andDC TransferFiles

The SAILS processing logic for the inbound, replenishment, and DCtransfer transaction files follows:

Step Action1 Read a record from the transaction file.2 Verify the accuracy of the internal origin location code by searching a

separate origin location code cross-reference table for a corresponding entry.

IF… THEN…a match is found obtain the corresponding SAILS

ID number.

no match is found record the unknown code and shipment quantity.

3 Verify the accuracy of the internal destination location code by searching aseparate destination location code cross-reference table for a correspondingentry.


ID number.


4 Verify the accuracy of the internal stock code by searching a separate stockcode cross-reference table for a matching entry.

IF… THEN…a match is found obtain the corresponding product

group and unit descriptors—weight, cube, inventory value, sales value, and standard units conversion factor.


table continued on the next page


INSIGHT

6.6 Understanding Transaction File Processing Logic, continued

6.6.1 Inbound, Replenishment, and DC Transfer Files

Step Action5 Verify the shipment quantity. Records with a negative, zero, or excessive

(run-time limit specified by the user) quantity are dropped.6 Verify the Julian date. Records with a date outside a user-specified range are

eliminated.7

IF… THEN…errors have been detected eliminate the record and return to Step 1.

no errors have been detected proceed to Step 7.

8 Compute weight, cube, inventory value, and sales value extensions asrequired (that is, only if the given extended field is blank or set to 0). Use theitem descriptors from Step 4, the quantity from Step 5, and the followingformulas:

EXTENDED WEIGHT = UNIT WEIGHT × QUANTITY

EXTENDED CUBE = UNIT CUBE × QUANTITY

EXTENDED INVENTORY VALUE = UNIT INVENTORY VALUE × QUANTITY

EXTENDED SALES VALUE = UNIT SALES VALUE × QUANTITY

9 Convert the quantity shipped to standard units, if requested. Use the standardunit conversion factor from Step 4, the quantity from Step 5, and thefollowing formula:

STANDARD UNITS = STANDARD UNITS CONVERSION FACTOR ×QUANTITY

10 Record volume data for later reports.11 Repeat Steps 1-10 until the entire file is processed.12 Store all results and print reports.


INSIGHT


6.6.2 Outbound Transaction File

ProcessingLogic forOutboundTransactionFile

The SAILS processing logic for the outbound transaction file follows:

Step Action1 Read a record from the transaction file.2 Verify the accuracy of the internal origin DC location code field by searching

a separate origin DC location code cross-reference table for a correspondingentry.


ID number.


3 Verify the accuracy of the internal customer aggregation code by searching aseparate customer aggregation code cross-reference table for acorresponding entry.


ID number.


4 Verify the accuracy of the internal stock code by searching a separate stockcode cross-reference table for a matching entry.

IF… THEN…a match is found obtain the corresponding product

group and unit descriptors—weight, cube, inventory value, sales value, and standard units conversion factor.


5 Verify the shipment quantity. Records with a negative, zero, or excessive(run-time limit specified by the user) quantity are dropped.

6 Verify the Julian date. Records with a date outside of a user-specified rangeare eliminated.



INSIGHT


6.6.2 Outbound Transaction File, continued

Step Action7 Verify accuracy of the internal customer class code by searching a separate

customer class code cross-reference table for a corresponding entry.IF… THEN…a match is found obtain the corresponding SAILS

ID number.


8 IF… THEN…errors are detected eliminate the record and return to Step 1.

no errors are detected proceed to Step 9.

9 Compute weight, cube, inventory value, and sales value extensions asrequired (that is, only if the given extended field is blank or set to 0). Use theitem descriptors from Step 4, the quantity from Step 5, and these formulas:

EXTENDED WEIGHT = UNIT WEIGHT × QUANTITY

EXTENDED CUBE = UNIT CUBE × QUANTITY

EXTENDED INVENTORY VALUE = UNIT INVENTORY VALUE × QUANTITY

EXTENDED SALES VALUE = UNIT SALES VALUE × QUANTITY

10 Convert the quantity shipped to standard units, if requested. Use the standardunit conversion factor from Step 4, the quantity from Step 5, and thefollowing formula:

STANDARD UNITS = STANDARD UNITS CONVERSION FACTOR × QUANTITY

11 Verify the accuracy of the 5-digit ZIP code (U.S. destinations only) IF theuser has activated the appropriate processing option.

IF… THEN…a valid ZIP code is present save it for later data recording by three-

digit ZIP code to support geographic analysis reports.

the ZIP code is not present or is bypass the data recording by three-digitinvalid ZIP code, but do not eliminate the record.

NOTE: SAILS automatically truncates the 5-digit ZIP code to thecorresponding 3-digit ZIP code.



INSIGHT


6.6.2 Outbound Transaction File, continued

Step Action12 Verify the accuracy of the state and county codes (U.S. destinations only) IF

the user has activated the appropriate processing option.

IF… THEN…valid state/county codes are present save them for later data recording by

state/county to support geographic analysis reports.

state/county codes are missing or bypass the data recording by state/invalid county codes, but do not eliminate the

record.

13 Record volume data for later reports.14 Repeat Steps 1-13 until the entire file is processed.15 Store all results and print reports.

AdditionalFacts aboutTransactionFileProcessing

Keep in mind these additional facts about SAILS transaction fileprocessing:

1 The document number and customer account number fields are notchecked for accuracy. There are no objective standards for verifyingthese fields; hence, SAILS assumes that you are supplying accurateentries.

2 You must supply a positive value in the quantity field; otherwise,SAILS drops the record. Under no circumstances will SAILS subtractnegative values from remaining transactions.

3 All other measures of volume, such as weight, cube, inventoryvalue, and sales value, are optional, both individually and incombination. Of course, if you elect to measure network flow interms of weight or cube, then you must supply appropriate valuesper one or both of the following procedures:

• You can compute the extension and fill in the appropriateextended field when you prepare the transaction file.


INSIGHT


AdditionalFacts aboutTransactionFileProcessing,continued

• You can leave the extended field blank and allow SAILS tocompute the extension for you during transaction file processing.If you use this option, you must supply the corresponding unitmeasure for each stock code in the stock item code cross-referencetable (see below). SAILS will automatically compute the requiredextension, per the formulas given in the step-by-step procedureabove, whenever it detects a blank or zero in an extended field.

Example:

Suppose that you wish to see aggregate volume reports by weight.You can

EITHER1 compute the extended weight of each line item and place this value in

the extended weight field of the transaction file,OR2 supply a unit weight for each stock code in the stock code cross-

reference table. SAILS will then compute the extended weight bymultiplying the quantity shipped by the unit weight.

These two procedures are not mutually exclusive. SAILS willautomatically accept all extended field values supplied by you. However, ifa given field is left blank or set to 0, SAILS will attempt to compute therequired extension. Therefore, you may freely intermix records with andwithout computed extensions. Just remember to supply unit measures inthe stock code cross-reference table if you want SAILS to compute anyextensions for you.

4 SAILS will show aggregate volume in terms of units in a number ofreports. Frequently, however, the natural units of demand differacross stock codes. For example, shipment quantities in units of“each”, case, dozen, gallon, and pallet may all be present in atransaction file—perhaps even on the same shipment. In suchinstances, aggregate volume totals in terms of units are generallymeaningless. What does a total of 300 units mean if it consists of 100cases, 100 gallons, and 100 dozen? However, in certain instances itis possible to convert differing measures of quantity into a single,consistent unit. For example, suppose that you manufacture paintand offer it for sale in five different containers: pint can, quart can,gallon can, five gallon pail, and 50 gallon drum. Suppose furtherthat you wish to see aggregate volume reported in units of“standard gallons”.


INSIGHT


AdditionalFacts aboutTransactionFileProcessing,continued

It is a simple matter to convert each of the above package sizes toequivalent gallons by means of a suitable conversion factor. Forexample, demand for quart cans may be converted to standardgallons by multiplying it by 0.25 (gallons per quart).

IF… THEN…you elect to convertdiffering units ofquantity measurementto a standard unit

you must supply an appropriateconversion factor for each stock code inthe stock code cross-reference table(see below).

IMPORTANT: The conversion to standard units occurs after anyextensions have been computed. Therefore, youshould express any unit weight, unit cube, unitinventory value, and unit sales value entries in thenatural units of demand for a given stock code, not instandard units.


INSIGHT

6.7 Understanding Transaction File Processing Results

Overview There are two major outputs from any transaction file analysis, writtenreports and a table of historical flow percentages. Outbound transactionfile processing yields two additional outputs: a table of aggregatedcustomer demands and a modified outbound transaction file suitablefor input to SHIPCONS. We discuss each of these outputs, next.

6.7.1 Written Reports

The written reports available from inbound, replenishment, and DCtransfer transaction file processing are identical and are summarized inFigure 6-10. The written reports from outbound transaction fileprocessing, while similar in appearance and content, differ in twoimportant respects: (1) many reports display data by customer class;and (2) an elaborate geographic analysis of customer demand patternsmay be requested. The available reports are summarized in Figure 6-11. We discuss all transaction file analysis reports in much greaterdetail in the SAILS User Guide and in selected appendices.

.i.reports available in SAILS:transaction file processing 6-;INBOUND, REPLENISHMENT, DC FILES

REPORT SUMMARY

1 PROCESSING/ERROR REPORTS

A Processing/error summary

B Detailed error listings

2 AGGREGATE VOLUME REPORTS

A Shipment Volume

B Shipment Processing

C Shipment Size

3 SEASONAL ANALYSIS REPORTS

A Monthly Volume

B Weekly Volume

C Daily Volume

Figure 6-10. Summary of principal reports generated by SAILS after processing an


INSIGHT

inbound, replenishment, or DC transfer transaction history file. The SAILS User Guidecontains a complete list of all reports and shows how to request them.


INSIGHT

6.7 Understanding Transaction File Processing Results, continued

OUTBOUND TRANSACTION FILEREPORT SUMMARY

1 PROCESSING/ERROR REPORTS

A Processing/error summary

B Detailed error listings

2 AGGREGATE VOLUME REPORTS

A Order Volume

B Order Processing

C Order Size Histograms

3 SEASONAL ANALYSIS REPORTS

A Monthly Volume

B Weekly Volume

C Daily Volume

4 GEOGRAPHIC ANALYSIS REPORTS

A Aggregate Volume

B Market Penetration

C Correlation Analysis

Figure 6-11. Summary of principal reports generated by SAILS after it processes anoutbound transaction file. The SAILS User Guide contains a complete list of all reports andshows how to request them.


INSIGHT


6.7.2 Historical Flow Percentages

AboutHistoricalFlowPercentageTables

SAILS creates a historical flow percentage table with each SAILStransaction file analysis. The content of the table is as follows: for eachdestination location-commodity group combination, SAILS computesthe percentage of the total volume of the given commodity received atthe given destination that was shipped by each origin. More specifically:

inbound for each plant location/raw materialcombination, the percentage of the totalvolume received that was shipped byeach raw material supplier

replenishment for each DC location/finished productcombination, the percentage of the totalvolume received that was shipped byeach plant

DC transfer for each destination DC location/finished product combination, thepercentage of the total volume receivedthat was shipped by each origin DC

outbound for each destination customer-region/customer class-finished productcombination, the percentage of the totalvolume received that was shipped byeach origin DC

Use these tables in the cost/flow baseline analysis module and thebaseline-optimization comparison module. See Chapters 11 and 12 fordetails. Refer to Figures 6-12 through 6-15 for examples of each table.


INSIGHT


AboutHistoricalFlowPercentageTables,continued

INBOUND HISTORICAL FLOW TABLE

(each destination plant location)

Origin Raw Material Suppliers

1 2 3 4 5Raw

Materials1 0.15 0.25 0.05 0.45 0.102 0.00 0.00 1.00 0.00 0.003 0.10 0.30 0.20 0.05 0.35

Figure 6-12. An example of an inbound historical flow allocation table. SAILS generates aseparate table for each destination plant location whenever an inbound transaction file isprocessed. Notice that the decimal fractions in each row total 1.0. The table is usedexclusively by the cost/flow baseline module to control the flow of raw materials from rawmaterial suppliers to plant locations.

REPLENISHMENT HISTORICAL FLOW TABLE(each destination DC location)

Origin Plant Locations

1 2 3 4 5FinishedProducts

1 0.15 0.25 0.05 0.45 0.102 0.00 0.00 1.00 0.00 0.003 0.10 0.30 0.20 0.05 0.35

Figure 6-13. An example of a replenishment historical flow allocation table. SAILSgenerates a separate table for each destination DC location whenever a replenishmenttransaction file is processed. Notice that the decimal fractions in each row total 1.0. Thetable is used exclusively by the cost/flow baseline module to control the flow of finishedproducts from plant locations to DC locations.


INSIGHT


AboutHistoricalFlowPercentageTables,continued

DC TRANSFER HISTORICAL FLOW TABLE(each destination DC location)

Origin DC Locations


1 0.15 0.25 0.05 0.45 0.102 0.00 0.00 1.00 0.00 0.003 0.10 0.30 0.20 0.05 0.35

Figure 6-14. An example of a DC transfer historical flow allocation table. SAILS generatesa separate table for each destination DC location whenever a DC transfer transaction file isprocessed. Notice that the decimal fractions in each row total 1.0. The table is usedexclusively by the cost/flow baseline module to control the flow of finished productsbetween DC locations.

OUTBOUND HISTORICAL FLOW TABLE(each destination customer region/customer class)

Origin DC Locations


1 0.15 0.25 0.05 0.45 0.102 0.00 0.00 1.00 0.00 0.003 0.10 0.30 0.20 0.05 0.35

Figure 6-15. An example of an outbound historical flow allocation table. SAILS generates aseparate table for each destination customer region-customer class combination wheneveran outbound transaction file is processed. Notice that the decimal fractions in each rowtotal 1.0. The table is used exclusively by the cost/flow baseline module to control the flowof finished products from DC locations to customer regions.


INSIGHT


6.7.3 Customer Demand Table

As you learned in Chapter 5, you must present SAILS solvers with atable of demands summarized across the base time period. SAILSautomatically fills the appropriate table with demands summarizedfrom the outbound transaction file. See Figure 6-16, next.

Customer Region 4

Customer Region 3

Customer Region 2

Customer Region 1Finished Products

Cu

sto

me

r C

lass

es

Finished Product 4

Finished Product 3

Finished Product 2

Finished Product 1Customer Classes

Cu

sto

me

r R

eg

ion

s

Customer Class 4

Customer Class 3

Customer Class 2

Customer Class 1Finished Products

Cu

sto

me

r R

eg

ion

s

1 Table for Each Customer Region

1 Table for Each Finished Product

1 Table for Each Customer Class

Figure 6-16. The SAILS customer demand data requirement. You must supply demandtotals for each customer region/customer class-finished product group combination. Arelational database allows us to visualize the data as (a) a succession of region-specifictables, where each table is dimensioned as classes × × products; (b) a succession of product-specific tables, where each table is dimensioned as regions × × classes: and (c) a succession ofclass-specific tables, where each table is dimensioned as regions × × products. All threeviews of the data are equivalent.


INSIGHT


INSIGHT


6.7.4 SHIPCONS Input

The SHIPCONS traffic management simulation model requires input ofa full SAILS outbound transaction file. During outbound transaction fileprocessing, SAILS prepares this file for you. You do not need to befamiliar with the layout of this file to use SHIPCONS effectively.However, keep in mind that records deleted during outboundtransaction file processing are not included in this file.


INSIGHT

6.8 Preparing Transaction File Data

First, Preparean ActionPlan

You must plan and complete the preparation of these two significantsources associated with transaction file data preparation:

• the actual transaction file, and• associated recoding/aggregation data

6.8.1 Preparing the Actual Transaction File

Overview Transaction file preparation is not an inherently difficult task.Conceptually it involves nothing more than the following:

Step Action1 Locate a suitable master transaction history file.2 Write and execute a simple computer program which extracts selected data

elements from each master file record in accordance with SAILS transactionfile specifications.

In practice, however, problems may arise because of the followingfactors:

1 Access to the master transaction file is restricted.

2 Entire sections of the master transaction file are missing orincomplete.

3 Individual data elements within the file are missing or inaccurate.

4 Certain data elements required by SAILS must be obtained fromother related files (e.g., a customer master file).

5 Programming support is difficult to obtain.

Given sufficient time and effort, all of the above difficulties can usuallybe overcome. The operative term here is “sufficient”. Given at least thepotential for significant delay, prudence dictates that you beginpreparing transaction files at the earliest appropriate time in a study.We discuss the sequencing of data preparation tasks in Chapter 14 andin the SAILS User Guide.


INSIGHT

6.8 Preparing Transaction File Data, continued

How toPrepareTransactionFiles

We recommend that you adopt the following general procedure todevelop any transaction file:

Step Action1 Decide which SAILS transaction file(s) you wish to prepare.2 Verify the existence of master transaction history files in your organization.3 Determine the period of time for which transaction files are retained by your

organization.4 Secure any necessary programming resources.5 Analyze your master transaction file(s) in light of SAILS file specifications.6 Formulate a strategy for each data field you propose to use in each SAILS

transaction file.7 Write and test the file extraction program(s).8 Obtain a small sample of the extracted transaction file and process it using

SAILS.9 Obtain the full transaction file extract.

10 Process the full transaction file extract using SAILS.

See the SAILS User Guide for information on detailed transaction filepreparation, testing, and processing procedures.

6.8.2 Preparing Recoding/Aggregation Data

Overview Seven different types of recoding/aggregation data are recognized bySAILS: raw material, finished product, raw material supplier, plantlocation, DC location, customer region, and customer class. Therequirement to supply a given category is a function of the transactionfile being processed. Figure 6-17 shows all possible combinations ofrecoding/aggregation data categories and transaction files.

In the next several sections, we briefly consider each of therecoding/aggregation categories, together with certain built-in SAILSprocessing options which you may find useful when preparing thedata. For discussion purposes, the seven data categories may bereduced to four generic types: commodity, facility, customer region,and customer class. We emphasize that recoding/aggregation data arerequired only if you elect to prepare transaction files; they are usednowhere else in SAILS.


INSIGHT


RawMaterial

FinishedProduct

RawMaterialSupplier

PlantLocation

DCLocation

CustomerRegion

CustomerClass

TransactionFiles

Inbound X X X

Replenish-ment

X X X

DC Transfer X X

Outbound X X X X

Fig. 6-17. Certain recoding/aggregation data is required to process each transaction historyfile. These cross-reference tables bridge the data gap between the detailed internal codesfound on the transaction file and the corresponding SAILS model components. Bydeferring recoding/aggregation until the last possible moment, you preserve databaseflexibility. A change to a given model component requires only a change to thecorresponding recoding/aggregation table—the transaction file(s) remain the same.

CommodityRecoding/AggregationData

There are two possible categories of commodity aggregation data: rawmaterial and finished product. In both instances, you must prepare amaster list of stock codes and assign each item in the list to exactly onecommodity group (SAILS will block any attempt to do otherwise). Theresult is the stock code-to-SAILS commodity group cross reference tablethat we described earlier.

As we saw earlier, when SAILS processes a transaction file, it mustassign a SAILS commodity group to each line item of each shipment. Tosatisfy this requirement, it extracts the stock code from each data recordand attempts to match it in the stock code cross-reference table that yousupply. If a match is detected, the commodity group is assigned; if not,the record is discarded.


INSIGHT


CommodityRecoding/AggregationData, continued

Assembling a complete list of stock codes is rarely a problem, sincemost organizations maintain and store a master catalogueelectronically. On the other hand, assigning each item in the list to acommodity group can be rather tedious. SAILS can reduce your effortconsiderably if (and this is a very big if!) your stock codes exhibit certainstructure or patterns. For example, suppose that your stock codes areten characters long and that the first four characters designate a certainmajor product family or classification (the remaining charactersindicate details such as size, color, labeling, etc.). Suppose further thatthere is some relationship between these internal product families andthe product groups you have defined in your SAILS model. In this caseyou can supply SAILS with a list of stock code “prefixes”, together withthe corresponding product group assignment for each such “pattern”.SAILS will search the master stock code list and automatically assign anitem to a product group whenever a pattern match is detected.

Unfortunately, many stock code numbering schemes exhibit nostructure whatsoever. However, all hope of avoiding manualassignment drudgery is still not lost. Your firm may have alreadyassigned each item to a major product line or family, using a specialinternal coding scheme carried in the master catalogue but nototherwise reflected in the stock code itself. If such a system exists, makecertain that you include this information when you obtain an extract ofthe catalogue. Although SAILS cannot make use of these codes directly,you may be able to exploit them via a custom program, databasemanager, or spreadsheet routine. Alternatively, you could physicallyincorporate them into the stock codes used in the SAILS database (bothin the transaction files and master stock code list), thereby enablingSAILS to perform the pattern matching described above.

In extreme cases involving tens or even hundreds of thousands of stockcodes, you should seriously consider doing some sort of preaggregationwhile preparing the transaction file. For example, if your stock codenumbering scheme includes some sort of hierarchical “family” or“class” designation (per the discussion of pattern matching above), youcould include only those characters in the stock code field, collapsing allrecords on a given shipment within the same family or class into asingle record. If you do so,


INSIGHT


CommodityRecoding/AggregationData, continued

make certain that you add all the volume fields together for the recordswhich are being collapsed. This procedure will obviously reduce thesize of both the transaction file and the corresponding master stockcode list. However, you should carefully weigh the tradeoff betweenfile size reduction and aggregation flexibility. Detail removed a prioricannot be reconstructed by SAILS.

FacilityRecoding/AggregationData

There are three possible categories of facility recoding/aggregationdata: supplier, plant, and DC locations. In each instance you mustprepare a master list of actual internal location codes (i.e., the codesthat appear on your transaction files) and assign each code in the list toexactly one location in your model. The result is the internal locationcode-to-SAILS location ID cross-reference table that we describedearlier.

When SAILS processes a transaction file, it must determine the originand destination locations of each shipment. To satisfy this requirement,it extracts the internal origin/destination location codes from each datarecord and attempts to identify them by searching the correspondingcross-reference tables that you supply. IF a match is detected, THENthe location is determined; if not, the record is discarded.

Preparing a cross-reference table of location codes used by your firm israrely a problem, if for no other reason than the list is typically quitesmall. Moreover, in many instances you need not prepare the cross-reference table at all! By default, SAILS assumes that the supplier, plant,and DC location ID numbers from the Network Description Data areidentical to the location codes found in the transaction history file(s). Ifyou make the SAILS ID numbers the same as those actually used byyour firm, then the location code cross-reference table is automaticallyavailable for transaction file processing with no further input on yourpart.

Unfortunately, the convention of using SAILS ID numbers which matchyour internal location codes is not always sufficient or even possible.You must formally prepare a master location code cross-reference tableunder the following conditions:


INSIGHT


Prepare a master location codecross-reference table IF…

Description

the SAILS ID numbers do not matchthe actual location codes found onyour transaction file(s)your internal location codes containalphanumeric or special characters ordo not fall within the range 1<x<9999you wish to “cluster” two or morefacilities into a single location formodeling purposes.

This is especially common in studies involvingthe merging of previously independentnetworks. It can also occur when you haveemployed two or more public warehouseoperations in the same location. In suchcases, you will assign multiple internal locationcodes to a single model location.

you must prepare a formal geographicaggregation scheme.

For example, vendor-intensive distributionsystems may involve thousands of shippinglocations—far too many to be modeleddiscretely. In such cases, you would model“vendor regions”, where each such region iscomprised of a nodal point city and a list ofeither actual location codes or georeferencecodes. The nodal point city is entered as partof Network Description data (see Chapter 4),but the corresponding list of location codes orgeoreference codes is prepared as a cross-reference table.

CustomerRegionRecoding/AggregationData

In Chapter 4 we showed that a customer region is composed of twoparts: a nodal point city and a surrounding boundary. The nodal pointcities are entered as part of the Network Description Data (see Chapter4), but the corresponding boundary is defined via data aggregationtables. When SAILS processes an outbound transaction file record, itextracts information from the “customer aggregation code” field andattempts to identify it by searching a corresponding cross-referencetable of such codes. If a match is detected, the customer region isdetermined; if not, the record is discarded.

Specification of customer region nodal point cities is straightforward:the center of a major urban area, the demand centroid of the area, etc.However, the surrounding boundary is another matter. While inprinciple you could list all discrete ship-to customers which comprisethe region, in practice you might well be overwhelmed by


INSIGHT


CustomerRegionRecoding/AggregationData, continued

the effort. In general, you will find it much simpler to use ageoreference coding system, wherein a given code represents allcustomers within its boundaries. For U.S. customers, 3-digit zip codes(approximately 900 active codes), or state/county codes (3247including Puerto Rico, Guam and the Virgin Islands) are the systems ofchoice, while postal codes specific to each country are typically usedelsewhere. Regardless of the system chosen, each georeference code isassigned to exactly one nodal point. The area represented by all codesassigned to a given nodal point is the true customer region (see Chapter4 for an introduction to customer aggregation).

If you elect to base customer aggregation on three-digit zip codes orstate/county codes (applicable to U.S. customer regions only), thenSAILS will optionally generate the required aggregation table for you,either in its entirety or in part. It does so by attaching each georeferencecode to the closest customer region, where distance is computed fromthe approximate population centroid of the area represented by thecode to each customer region nodal point. Georeference codespreassigned by you are excluded from this auto generation process, asare international customer regions. In addition, you may optionallyexclude certain “nonstandard” customer regions, such as those used torepresent export volume.

SAILS generates the three-digit ZIP code-based customer aggregationtable as described in the following table:


INSIGHT


Step Action1 Obtain a three-digit ZIP code from the SAILS master georeference database.2

IF… THEN…the 3-digit ZIP code corresponds to forcibly assign it to the indicateda customer region nodal point customer region.ZIP code Do this even if the user has assigned

the three-digit ZIP code to another customer region. Proceed to Step 5.

the 3-digit ZIP code is part of a ZIP forcibly assign it to the indicatedcode sectional center, and… customer region.another 3-digit ZIP code within the Do this even if the user has assignedsectional center has already been the three-digit ZIP code to anotherassigned to a customer region customer region. This step preserves

the integrity of sectional centers. Proceed to Step 5.

the 3-digit ZIP code has been accept the assignment and proceedpreassigned by the user to a to Step 5.customer region

NOTE: Each U.S. nodal point from Network Description Data must beassigned a 5-digit ZIP code—see the SAILS User Guide fordetails.

3 Compute the distance from the approximate population centroid of the 3-digitzip area to every customer region nodal point.

4 Assign the 3-digit zip code to the closest customer region, using thedistances computed in Step 3.

NOTE: Exclude from this step all customer regions marked as“nonstandard” by the user and all with nodal points outside ofthe United States and its territories.

5 Repeat Steps 1 through 4 for every three-digit ZIP code in the SAILSgeoreference database.

NOTE: You must define no more than one customer regionalnodal point in any ZIP code sectional center IF you usethis procedure. (nonstandard regions are excluded fromthis recommendation). Otherwise, you will confuse theautomatic aggregation table generation logic, whichattempts to maintain sectional center integrity. You canavoid this problem if you use SAILS standard customerregion nodal point lists. See Chapter 4 for additionaldetails.


INSIGHT


State/CountyCode-BasedCustomerAggregationTables

SAILS generates the complete state/county code-based customeraggregation table as described in the following table:

Step Action1 Obtain a FIPS state/county code from the SAILS master georeference

database.2

IF… THEN…the state/county code has been accept the assignmentpreassigned by the user to a and proceed to Step 5.customer regionthe state/county code has not execute steps 3, 4, and 5.been preassigned

3 Compute the distance from the approximate population centroid of thecounty to every customer region nodal point.

4 Assign the state/county code to the closest customer region, using thedistances computed in Step 3.Exclude from this step all customer regions marked as “nonstandard” by theuser and all with nodal points outside of the United States and its territories.

5 Repeat Steps 1 through 4 for every FIPS state/county code in the SAILSgeoreference database.

How toCustomizeAggregationCodes

NOTE: You must develop customized aggregation codes that willappear both in the SAILS outbound transaction historyfile and the corresponding cross-reference table IF youhave included customer regions in your model torepresent export volume or other special conditions. Use anumbering scheme that cannot possibly clash with thestandard aggregation codes you have selected.

Example

If your customer aggregation strategy is based on three-digit zip codes,then choose values greater than 999 to represent nonstandard customerregion nodal points. Make certain that you coordinate such matterswith the programmer responsible for transaction file preparation. An


INSIGHT

example of a numbering scheme for an assumed set of special exportcustomer regions (one for each significant port of embarkation) isshown in Figure 6-18.

EXPORT ZONE EXAMPLE

NAME ZIP CODE SAILS ID #

New York/New Jersey 07101 8001

Baltimore 21233 8002

Tidewater 23501 8003

Jacksonville 32203 8004

Miami 33101 8005

New Orleans 70140 8006

Houston 77052 8007

Los Angeles 90055 8008

San Francisco 94101 8009

Seattle 98101 8010

Fig. 6-18. Example of a numbering scheme for an assumed set of special export customerregions for each significant port of embarkation.


INSIGHT


CustomerClass CodeRecoding/AggregationData

Customer class recoding data is required whenever you choose todefine multiple customer classes on the outbound transaction file. Inthis instance you must prepare a master list of internal customer classcodes—the codes that appear on your outbound transaction file—andassign each code in the list to exactly one customer class in your model.The result is the internal customer class code-to-SAILS customer classID cross-reference table that we described earlier.

As we explained earlier, when SAILS processes an outboundtransaction file, it must determine the customer class to which eachshipment is assigned. To satisfy this requirement, it extracts the internalcustomer class code from each data record and attempts to identify itby searching the corresponding cross-reference table that you supply. Ifa match is detected, the customer class is determined; if not, the recordis discarded.

Many beginning SAILS users have difficulty with the idea of acustomer class code, because there is typically no internal (“realworld”) coding scheme which they can associate with their modelcustomer classes. Notice that this is not the case for the other types ofrecoding/aggregation data: stock codes and location codes constitutewell-understood, standard coding schemes. The solution is actuallyquite simple and affords you a great deal of flexibility: invent yourown coding scheme!

Prior to worrying about specific customer class codes, you mustconceptually define the customer classes which will be included in yourmodel (see Chapter 4). For each such class you must then determinewhether or not it is possible to actually identify the transactions whichcorrespond to the business segment represented by the class. If it is notpossible to do so, you must rework your customer class strategy.

AboutCustomerClassStrategy

To illustrate the potential difficulty here, let us consider a very commoncustomer class: customer pickups. If a special code designating acustomer pickup already exists on your transaction history file, then theproblem is already solved. If not, you may be able to design processinglogic such that you can make an educated guess as to which shipmentswere actually picked up by customers. For example, you could assumethat all shipments within a given service radius were, in fact, customerpickups. If you are unable to


INSIGHT


AboutCustomerClassStrategy,continued

devise such a scheme, you have no choice but to abandon modelingcustomer pickups as a separate customer class. In any event, it is veryimportant for you to discuss your proposed file preparation strategywith the programmer(s) assigned to the task. This is especially importantif special processing logic must be built into the data extractionprogram. It is not uncommon for apparently straightforward decisionrules to translate into very complex programming specifications.

Many SAILS users have developed rather elaborate customer class codeschemes which, in turn, provide them with considerable analysisflexibility. The basic idea is to build as much detail as possible into thetransaction file itself and then exploit it via the use of cross-referencetables. While the details vary from application to application, we canillustrate all of the essential ideas with a simple example.

Suppose that you wish to build into the outbound transaction file thefollowing distinctions:

1 institutional versus retail

2 large shipment versus small shipment

3 pickup versus delivered

4 stock order versus emergency order

You will notice from the outbound transaction file layout that thecustomer class code field is four characters wide. Since you arepermitted to write the field specification in any way that you wish,define each character position and assign corresponding codes asfollows:

Character Position 1 institutional versus retail“I” = institutional“R” = retail

Character Position 2 large shipment versus small shipment“L” = large shipment“S” = small shipment


INSIGHT


AboutCustomerClassStrategy,continued

Character Position 3 delivered versus pickup“D” = delivered“P” = pickup

Character Position 4 stock order versus emergency order“S” = stock order“E” = emergency order

If we assume that all 16 possible combinations of the above codes couldactually appear on the transaction file, then we must prepare the masterlist of customer class codes shown in Figure 6-19. Of course, this doesnot imply that we must actually define 16 customer classes in our model.Rather, it simply means that we must account for all 16 combinations inour cross-reference table. We may choose to aggregate these codes in anymanner whatsoever. For example, suppose that we initially elect todefine four customer classes in our model:

1 institutional stock order

2 institutional emergency orders

3 retail stock orders

4 retail emergency orders

The resulting cross-reference table is shown in Figure 6-20.

Finally, as with location codes, IF you choose customer class IDnumbers such that they match customer class codes found on theoutbound transaction file, THEN you need not prepare a customer classcode cross-reference table at all. Of course, this approach precludes thesort of flexible coding strategy illustrated above, but is satisfactory ifyou anticipate no changes to your customer class definitions.


INSIGHT


CUSTOMER CLASS CODE TABLE(Internal Codes on the Outbound Transaction File)

ILDS

ILDE

ILPS

ILPE

ISDS

ISDE

ISPS

ISPE

RLDS

RLDE

RLPS

RLPE

RSDS

RSDE

RSPS

RSPE

Figure 6-19 . An example of a master customer class code list. In this instance eachcharacter position corresponds to a potentially important partition of demand:

Position 1: institutional (I) vs. retail (R)

Position 2: large shipment (L) vs. small shipment (S)

Position 3: delivered (D) vs. pickup (P)

Position 4: stock order (S) vs. emergency order (E)

The list shown accounts for all possible combinations of these characters. However, youneed to include only those that actually appear in the outbound transaction file.


INSIGHT


CUSTOMER CLASS CODE AGGREGATION EXAMPLE

CUSTOMER CLASS 1: INSTITUTIONAL STOCK ORDERSILDSILPSISDSISPS

CUSTOMER CLASS 2: INSTITUTIONAL EMERGENCY ORDERSILDEILPEISDEISPE

CUSTOMER CLASS 3: RETAIL STOCK ORDERSRLDSRLPSRSDSRSPS

CUSTOMER CLASS 4: RETAIL EMERGENCY ORDERSRLDERLPERSDERSPE

Figure 6-20. A customer class code aggregation example. The 16 class code possibilitieslisted in Figure 6-19 have been grouped into four customer classes for modeling purposes.


INSIGHT

6.9 A Final Perspective

ChapterSummary

You are now in a much better position to appreciate the rationale forthe SAILS transaction file specifications, especially the use of stockcodes, internal location codes, and georeference codes. For one thing, itmakes preparation of the file much easier: you need only extract—notmodify—the relevant data fields from your corporate shipment historyfiles. In particular, no recoding or aggregation is required at this step inthe overall process. But of much greater importance is the flexibilityinherent in the design. If you change your mind about the number and(or) composition of commodity groups, customer classes, or customerregions, if you decide to cluster supplier, plant, or DC locations, or ifyou wish to modify the base time period, you need not regenerate theSAILS transaction history file(s). Rather, you simply modify theappropriate network description and corresponding cross-referencetables and rerun the applicable transaction file processor(s) in SAILS.Since all recoding/aggregation is accomplished on-the-fly, informationextracted from the transaction file(s) will be regenerated and a new setof reports will be prepared—all without further action on your part.Experience has shown that this is far superior to preparing a newtransaction file in response to every model design change.

The discussion of transaction files brings to a close our consideration ofthe demand data associated with customer regions, as well as upstreamhistorical flow data. We turn now to a detailed examination of theremaining nodes in the network: suppliers, plants, and distributioncenters. We do so in terms of their operating costs and capacities,otherwise known as facility data.


INSIGHT

NOTES

chapter 6 transaction file processing

Documents