Sterling Selling and Fulfillment Foundation



Distributed Order Management

Configuration Guide
Release 9.2
Sterling Selling and Fulfillment Foundation



Distributed Order Management

Configuration Guide
Release 9.2
 Note
Before using this information and the product it supports, read the information in “Notices” on page 495.

Copyright
This edition applies to the 9.2 Version of IBM Sterling Selling and Fulfillment Foundation and to all subsequent
releases and modifications until otherwise indicated in new editions.
© Copyright IBM Corporation 1999, 2012.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Chapter 1. Introduction . . . . . . . . 1 Creating a Level of Service . . . . . . . . 33
Introducing Distributed Order Management . . . . 1 Modifying a Level of Service . . . . . . . 34
Business Models . . . . . . . . . . . . . 1 Deleting a Level of Service . . . . . . . . 34
Multidivisional Corporation . . . . . . . . 1 Defining Node Level Controls . . . . . . . . 34
Third-Party Logistics . . . . . . . . . . 2 Defining a Node's Primary Order Promising
Marketplace . . . . . . . . . . . . . 2 Information . . . . . . . . . . . . . 35
Sterling Distributed Order Management Defining a Node’s Relationships . . . . . . 37
Configuration . . . . . . . . . . . . . . 2 Defining Notification Periods . . . . . . . 40
Sourcing Setup . . . . . . . . . . . . 3 Defining Sourcing and Scheduling Rules . . . 43
Logistics . . . . . . . . . . . . . . . 3 Defining Fulfillment Types . . . . . . . . 43
Financials . . . . . . . . . . . . . . 3 Defining Basic Sourcing Configuration . . . . 44
Customer . . . . . . . . . . . . . . 3 Defining Order Sourcing Classifications . . . . 45
Order Attributes . . . . . . . . . . . . 3 Sourcing Region Selection . . . . . . . . 46
Order Validation . . . . . . . . . . . . 3 Defining Sourcing Region Selection . . . . . 47
Instruction Types . . . . . . . . . . . . 4 Defining Scheduling Rules . . . . . . . . 47
Modification Reasons . . . . . . . . . . 4 Configuring Landed Cost Optimization . . . . 53
Backorder Reasons . . . . . . . . . . . 4 Forwarding/Transfer Rules . . . . . . . . 57
Process Type Configuration . . . . . . . . 4 Defining Distribution Groups for Product Items 58
Purge Criteria . . . . . . . . . . . . . 4 Defining Sourcing Rules for Product Items . . . 61
Icons Used in This Guide . . . . . . . . . . 5 Defining Sourcing Rules for Delivery Service
Items . . . . . . . . . . . . . . . 64
Chapter 2. Navigating the Applications Defining Distribution Groups for Delivery
Service Items . . . . . . . . . . . . . 66
Manager . . . . . . . . . . . . . . 7 Defining Distribution Groups for Provided
Starting the Applications Manager . . . . . . . 7 Service Items . . . . . . . . . . . . . 67
The Applications Manager Layout . . . . . . . 7 Defining Sourcing Rules for Provided Service
Application Rules Side Panel . . . . . . . . 8 Items . . . . . . . . . . . . . . . 69
Work Area. . . . . . . . . . . . . . 14 Defining Procurement Rules . . . . . . . . 71
Actions Available in the Applications Manager . . 18 Defining Sourcing Template Details . . . . . 74
Using the Applications Manager's Lookup
Functionality . . . . . . . . . . . . . 19
Viewing the Document Types Associated with an
Chapter 4. Configuring
Application . . . . . . . . . . . . . 19 Cross-Application Service Execution
Viewing the User Logged into the Applications Components . . . . . . . . . . . . 77
Manager . . . . . . . . . . . . . . 20 Configuring Service Supervisors . . . . . . . 77
Using Lists and List Filtering . . . . . . . 21 Defining a Service Supervisor for a Node . . . 77
Date and Time Entry . . . . . . . . . . 21 Modifying a Service Supervisor for a Node . . . 78
Troubleshooting Errors . . . . . . . . . 22 Deleting a Service Supervisor for a Node . . . 78
Using Special Characters . . . . . . . . . 22 Configuring Questions. . . . . . . . . . . 78
Defining Address Question Groups . . . . . 78
Chapter 3. Configuring Modifying Address Question Groups . . . . . 79
Cross-Application Order Promising Deleting Address Question Groups . . . . . 79
Defining Address Questions . . . . . . . . 79
Components . . . . . . . . . . . . 23 Modifying Address Questions . . . . . . . 80
Configuring Cross-Application Order Promising Deleting Address Questions . . . . . . . . 80
Components . . . . . . . . . . . . . . 23 Defining Capacity Impact. . . . . . . . . 81
What Is the Fulfillment Network Model? . . . . 23 Modifying Capacity Impact . . . . . . . . 82
The Fulfillment Network Model Work Area and Deleting Capacity Impact . . . . . . . . . 82
Its Components . . . . . . . . . . . . 23 Rearranging Address Question Entities . . . . 82
Defining Distribution Groups . . . . . . . 26 Defining Permit Question Groups . . . . . . 83
Defining Node Types . . . . . . . . . . 27 Modifying Permit Question Groups . . . . . 83
Defining Nodes . . . . . . . . . . . . 28 Deleting Permit Question Groups . . . . . . 83
Defining Relationship Types . . . . . . . . 30 Defining Permit Questions . . . . . . . . 84
Defining Relationships. . . . . . . . . . 31 Modifying Permit Questions . . . . . . . . 85
Defining Item Level Controls . . . . . . . . 33 Deleting Permit Questions . . . . . . . . 85
Defining Levels of Service . . . . . . . . . 33 Rearranging Permit Questionnaire Entities . . . 85

© Copyright IBM Corp. 1999, 2012 iii

Chapter 5. Configuring Defining Customer Classifications . . . . . 128
Cross-Application Logistics Defining Additional Customer Rules . . . . 129
Defining Customer Definitions . . . . . . . 130
Components . . . . . . . . . . . . 87
Creating a Customer Definition . . . . . . 130
Configuring Cross-Application Logistics
Modifying a Customer Definition. . . . . . 131
Components . . . . . . . . . . . . . . 87
Deleting a Customer Definition . . . . . . 137
Defining Logistics Attributes . . . . . . . . 87
Defining Contact Types . . . . . . . . . . 137
Defining Freight Terms . . . . . . . . . 87
Creating a Customer Contact Type . . . . . 137
Defining Carrier Modification Reasons . . . . 89
Modifying a Customer Contact Type . . . . 138
Defining Additional Logistic Rules . . . . . 90
Deleting a Customer Contact Type . . . . . 138
Defining Delivery Codes . . . . . . . . . . 91
Defining Customer Entitlements . . . . . . . 138
Creating a Delivery Code. . . . . . . . . 91
Defining Customer Grades . . . . . . . . . 139
Modifying a Delivery Code . . . . . . . . 92
Deleting a Delivery Code . . . . . . . . . 92
Defining Shipment Modes . . . . . . . . . 92 Chapter 9. Configuring a Document's
Creating a Shipment Mode . . . . . . . . 93 Attributes . . . . . . . . . . . . . 141
Modifying a Shipment Mode . . . . . . . 93 Configuring a Document's Attributes . . . . . 141
Deleting a Shipment Mode . . . . . . . . 93 Defining Order Types . . . . . . . . . . 141
Defining Outbound Constraints . . . . . . . 93 Creating an Order Type . . . . . . . . . 141
Creating a Routing Guide . . . . . . . . 95 Modifying an Order Type . . . . . . . . 141
Modifying a Routing Guide . . . . . . . . 96 Deleting an Order Type . . . . . . . . . 142
Deleting a Routing Guide . . . . . . . . 100 Defining Order Sources . . . . . . . . . . 142
Creating an Order Source . . . . . . . . 142
Chapter 6. Configuring Modifying an Order Source. . . . . . . . 143
Deleting an Order Source . . . . . . . . 143
Cross-Application Payment
Defining External References for the Order Level 143
Components . . . . . . . . . . . . 103 Creating an External Reference for the Order
Configuring Cross-Application Payment Header Level . . . . . . . . . . . . 143
Components. . . . . . . . . . . . . . 103 Modifying an External Reference for the Order
System Payment Processing Rules . . . . . . 103 Header Level . . . . . . . . . . . . 144
Defining Payment Rules . . . . . . . . . . 104 Deleting an External Reference for the Order
Creating a Payment Rule . . . . . . . . 104 Header Level . . . . . . . . . . . . 144
Modifying a Payment Rule . . . . . . . . 106 Defining External References for the Order Line
Deleting a Payment Rule . . . . . . . . 107 Level . . . . . . . . . . . . . . . . 144
Defining Payment Types. . . . . . . . . . 107 Creating an External Reference for the Order
Creating a Payment Type . . . . . . . . 107 Line Level . . . . . . . . . . . . . 144
Modifying a Payment Type . . . . . . . . 111 Modifying an External Reference for the Order
Deleting a Payment Type . . . . . . . . 111 Line Level . . . . . . . . . . . . . 145
Defining Payment Card Types . . . . . . . . 111 Deleting an External Reference for the Order
Creating a Payment Card Type . . . . . . 112 Line Level . . . . . . . . . . . . . 145
Modifying a Payment Card Type . . . . . . 115 Defining Order Address Types . . . . . . . 145
Deleting a Payment Card Type . . . . . . 115 Creating an Order Address Type . . . . . . 146
Modifying an Order Address Type . . . . . 146
Chapter 7. Configuring Deleting an Order Address Type . . . . . . 146
Cross-Application Pricing Defining Line Types . . . . . . . . . . . 147
Components . . . . . . . . . . . . 117 Creating a Line Type . . . . . . . . . . 147
Configuring Cross-Application Pricing Components 117 Modifying a Line Type . . . . . . . . . 147
Legacy Pricing Service . . . . . . . . . . 117 Deleting a Line Type . . . . . . . . . . 147
Defining Pricing by Region . . . . . . . . 117 Defining Other Attributes . . . . . . . . . 147
Defining Price Programs and Price Lists . . . 118 Generating a Prime Line Number for a New
Pricing Service . . . . . . . . . . . . . 122 Line from a Pre-Configured Number . . . . 148
Defining Region Schema for Selling . . . . . 122
Defining Pricing Organization Rules. . . . . 122 Chapter 10. Configuring a Document's
Defining Pricing Enterprise Rules . . . . . 125 Order Validation . . . . . . . . . . 149
Configuring a Document's Order Validation . . . 149
Chapter 8. Configuring
Cross-Application Customer Chapter 11. Configuring a Document's
Components . . . . . . . . . . . . 127 Instruction Types. . . . . . . . . . 151
Configuring Cross-Application Customer Configuring a Document's Instruction Types . . . 151
Components. . . . . . . . . . . . . . 127 Creating an Instruction Type . . . . . . . . 151
Defining Region Usage for Selling . . . . . . 127 Modifying an Instruction Type . . . . . . . 151

iv Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Deleting an Instruction Type . . . . . . . . 152 Configuring an Opportunity Document's Lost
Reason . . . . . . . . . . . . . . . 165
Chapter 12. Configuring a Document's Creating a Lost Reason . . . . . . . . . . 165
Modification Reasons . . . . . . . . 153 Modifying a Lost Reason . . . . . . . . . 165
Creating a New Lost Reason Based on an Existing
Configuring a Document’s Modification Reasons 153
One . . . . . . . . . . . . . . . . 166
Creating a Modification Reason . . . . . . . 153
Deleting a Lost Reason . . . . . . . . . . 166
Modifying a Modification Reason . . . . . . 153
Deleting a Modification Reason . . . . . . . 154
Chapter 19. Configuring a Document's
Chapter 13. Configuring a Document's Modification Components . . . . . . 167
Backorder Reasons. . . . . . . . . 155 Configuring a Document's Modification
Components. . . . . . . . . . . . . . 167
Configuring a Document's Backorder Reasons . . 155
Defining Custom Modification Types . . . . . 167
Creating a Backorder Reason . . . . . . . . 155
Creating a Custom Modification Type . . . . 168
Modifying a Backorder Reason . . . . . . . 155
Modifying a Custom Modification Type . . . 168
Deleting a Backorder Reason . . . . . . . . 156
Deleting a Custom Modification Type . . . . 169
Defining Status Modification Groups . . . . . 169
Chapter 14. Configuring a Document's Defining Modification Rules . . . . . . . 169
Note Reasons . . . . . . . . . . . 157 Specifying a Condition for a Status Modification
Configuring a Document's Note Reasons . . . . 157 Group . . . . . . . . . . . . . . . 171
Creating a Note Reason . . . . . . . . . . 157 Overriding Status Modification Groups. . . . 172
Modifying a Note Reason . . . . . . . . . 157 Inheriting Modification Rules from a Status
Creating a New Note Reason Based on an Existing Modification Group . . . . . . . . . . 172
One . . . . . . . . . . . . . . . . 157 Resolving Conflicts Between Status Modification
Deleting a Note Reason . . . . . . . . . . 158 Groups . . . . . . . . . . . . . . 173
Creating a Status Modification Group . . . . 174
Chapter 15. Configuring a Quote Modifying a Status Modification Group . . . 177
Document's Approval Rule Violation Deleting a Status Modification Group . . . . 177
Defining Modifications Impacting Pricing . . . . 177
Reason . . . . . . . . . . . . . . 159
Adding/Removing a Modification Type for
Configuring a Quote Document’s Approval Rule
Modifications Impacting Pricing . . . . . . 177
Violation Reason . . . . . . . . . . . . 159
Defining Modifications Requiring Auditing . . . 178
Creating an Approval Rule Violation Reason . . . 159
Modifying an Approval Rule Violation Reason . . 159
Creating a New Approval Rule Violation Reason Chapter 20. Configuring an Order
Based on an Existing One . . . . . . . . . 160 Document's Fulfillment-Specific
Deleting an Approval Rule Violation Reason . . . 160 Components . . . . . . . . . . . . 179
Configuring an Order Document's
Chapter 16. Configuring a Document's Fulfillment-Specific Components . . . . . . . 179
Line Relationship Type . . . . . . . 161 Defining Hold Types . . . . . . . . . . . 179
Configuring a Document’s Line Relationship Type 161 Creating a Hold Type . . . . . . . . . 179
Defining a Line Relationship Type . . . . . . 161 Modifying a Hold Type . . . . . . . . . 187
Modifying a Line Relationship Type . . . . . . 161 Deleting a Hold Type. . . . . . . . . . 188
Creating a New Line Relationship Type Based on Defining Order Tags . . . . . . . . . . . 188
an Existing One . . . . . . . . . . . . 161 Modifying an Order Tag. . . . . . . . . 189
Deleting a Line Relationship Type . . . . . 162 Deleting an Order Tag . . . . . . . . . 190
Defining Fulfillment Rules . . . . . . . . . 190
Defining Process Type Details . . . . . . . . 192
Chapter 17. Configuring an Order Fulfillment: Process Type Pipeline
Opportunity Document's Lead Origin . 163 Configuration . . . . . . . . . . . . . 192
Configuring an Opportunity Document's Lead Order Fulfillment: Defining Pipeline
Origin . . . . . . . . . . . . . . . . 163 Determination . . . . . . . . . . . . 193
Creating a Lead Origin . . . . . . . . . 163 Order Fulfillment: Pipelines . . . . . . . 193
Modifying a Lead Origin . . . . . . . . 163 Order Fulfillment: Transactions . . . . . . 194
Creating a New Lead Origin Based on an Order Fulfillment: Statuses . . . . . . . . 196
Existing One . . . . . . . . . . . . 163 Order Fulfillment: Conditions . . . . . . . 198
Deleting a Lead Origin . . . . . . . . . 164 Order Fulfillment: Actions . . . . . . . . 199
Defining Transaction Rules . . . . . . . . . 199
Chapter 18. Configuring an Defining Transaction Rules for Quotes . . . . 202
Opportunity Document's Lost Reason . 165 Defining Status Inventory Types . . . . . . . 203
Creating a Status Inventory Type . . . . . . 204

Contents v
 Modifying a Status Inventory Type . . . . . 205 Modifying a Payment Term. . . . . . . . 239
Deleting a Status Inventory Type . . . . . . 205 Deleting a Payment Term . . . . . . . . 239
Defining Quote Rules . . . . . . . . . . 206 Defining Charge Definitions . . . . . . . . 240
Defining Monitoring Components . . . . . . 206 Creating a Charge Category . . . . . . . 240
Order Fulfillment: Defining Date Types. . . . 206 Modifying a Charge Category . . . . . . . 241
Order Fulfillment: Defining Milestones . . . . 208 Deleting a Charge Category . . . . . . . 241
Order Fulfillment: Defining Monitoring Events . . 209 Defining Tax Names . . . . . . . . . . . 242
Order Fulfillment: Creating an Event Rule. . . 210 Creating a Tax Name . . . . . . . . . . 242
Order Fulfillment: Modifying an Event . . . . 211 Modifying a Tax Name . . . . . . . . . 242
Order Fulfillment: Deleting an Event . . . . 211 Deleting a Tax Name . . . . . . . . . . 243
Defining Transaction Dependencies . . . . . . 212 Defining Additional Payment Rules . . . . . . 243
Defining a Default Dependency Group . . . . 213 Defining Additional Payment Rules for Quotes 246
Creating a Transaction Dependency Group . . 213 Defining Receiving Discrepancy Reasons . . . . 246
Modifying a Transaction Dependency Group 216 Creating a Receiving Discrepancy Reason . . . 246
Deleting a Transaction Dependency Group . . 216 Modifying a Receiving Discrepancy Reason . . 247
Deleting a Receiving Discrepancy Reason . . . 248
Chapter 21. Configuring an
Opportunity Document's Chapter 24. Configuring a Document's
Fulfillment-Specific Components . . . 217 Purge Criteria . . . . . . . . . . . 249
Configuring an Opportunity Document’s Configuring a Document's Purge Criteria . . . . 249
Fulfillment-Specific Components . . . . . . . 217 Modifying an Order Document Type's Purge
Opportunity Fulfillment: Configuring Process Type Criteria Rule . . . . . . . . . . . . 250
Pipelines . . . . . . . . . . . . . . . 217
Opportunity Fulfillment: Pipelines . . . . . 217 Chapter 25. Configuring Value-Added
Opportunity Fulfillment: Transactions . . . . 218 Services . . . . . . . . . . . . . 253
Opportunity Fulfillment: Statuses. . . . . . 219 Configuring Value-Added Services . . . . . . 253
Opportunity Fulfillment: Conditions. . . . . 220 Defining Value-Added Services Modification
Opportunity Fulfillment: Actions . . . . . . 220 Reasons . . . . . . . . . . . . . . . 253
Configuring Purge Criteria . . . . . . . . . 221 Value-Added Services: Creating a Modification
Reason . . . . . . . . . . . . . . 253
Chapter 22. Configuring an Order Value-Added Services: Modifying a
Document's Shipment-Specific Modification Reason . . . . . . . . . . 253
Components . . . . . . . . . . . . 223 Value-Added Services: Creating a New
Configuring an Order Document's Modification Reason Based on an Existing One . 254
Shipment-Specific Components . . . . . . . 223 Value-Added Services: Deleting a Modification
Shipments: Defining Hold Types . . . . . . . 223 Reason . . . . . . . . . . . . . . 254
Shipments: Defining Process Type Details . . . . 223 Defining Value-Added Services Cancellation
Shipments: Process Type Pipeline Configuration 224 Reasons . . . . . . . . . . . . . . . 254
Shipments: Defining Pipeline Determination . . 224 Creating a Cancellation Reason . . . . . . 254
Shipments: Pipelines . . . . . . . . . . 225 Modifying a Cancellation Reason . . . . . . 255
Shipments: Transactions . . . . . . . . . 226 Creating a New Cancellation Reason Based on
Shipments: Statuses . . . . . . . . . . 228 an Existing One . . . . . . . . . . . 255
Shipments: Conditions . . . . . . . . . 229 Deleting a Cancellation Reason . . . . . . 255
Shipments: Actions . . . . . . . . . . 230 Defining Value-Added Services Appointment
Shipments: Defining Monitoring Components . . 230 Failure Reasons. . . . . . . . . . . . . 256
Shipments: Defining Date Types . . . . . . 231 Creating a Appointment Failure Reason . . . 256
Shipments: Defining Milestones . . . . . . 232 Modifying an Appointment Failure Reason . . 256
Shipments: Defining Monitoring Events . . . . 233 Creating a New Appointment Failure Reason
Shipments: Creating an Event Rule . . . . . 234 Based on an Existing One . . . . . . . . 257
Shipments: Modifying an Event . . . . . . 234 Deleting an Appointment Failure Reason . . . 257
Shipments: Deleting an Event . . . . . . . 235 Defining Value-Added Services Note Reasons . . 257
Defining Shipment Preferences . . . . . . . 235 Creating a Note Reason . . . . . . . . . 257
Over Shipping Preferences . . . . . . . . 235 Modifying a Note Reason . . . . . . . . 258
Transaction Rules . . . . . . . . . . . 237 Creating a New Note Reason Based on an
Existing One . . . . . . . . . . . . 258
Deleting a Note Reason . . . . . . . . . 258
Chapter 23. Configuring a Document's Defining Value-Added Services Instruction Types 258
Financial Components . . . . . . . 239 Value-Added Services: Creating an Instruction
Defining Payment Terms . . . . . . . . . 239 Type . . . . . . . . . . . . . . . 259
Creating a Payment Term . . . . . . . . 239

vi Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Value-Added Services: Modifying an Instruction Create Chained Order . . . . . . . . . 304
Type . . . . . . . . . . . . . . . 259 Create Derived Order . . . . . . . . . 305
Value-Added Services: Deleting an Instruction Create Order Invoice . . . . . . . . . . 307
Type . . . . . . . . . . . . . . . 259 Create Shipment Invoice. . . . . . . . . 308
Defining Value-Added Services Rules . . . . . 259 ESP Evaluator . . . . . . . . . . . . 309
Setting Up Value-Added Services Pre-Call Rules 260 Item Based Allocation . . . . . . . . . 311
Setting Up Value-Added Services Other Rules 260 Mark Load as Trailer Loaded . . . . . . . 315
Defining Value-Added Services Modification Match Inventory . . . . . . . . . . . 316
Groups . . . . . . . . . . . . . . . 261 Payment Collection . . . . . . . . . . 317
Setting Up Value-Added Services Modification Payment Execution . . . . . . . . . . 319
Groups . . . . . . . . . . . . . . 261 Post Inventory Match. . . . . . . . . . 321
Value-Added Services: Modifying a Process Order Hold Type . . . . . . . . 322
Modification Group . . . . . . . . . . 262 Process Work Order Hold Type . . . . . . 324
Value-Added Services: Deleting a Modification Publish Negotiation Results . . . . . . . 325
Group . . . . . . . . . . . . . . . 263 Release . . . . . . . . . . . . . . 327
Defining Value-Added Services Hold Types . . . 263 Route Shipment . . . . . . . . . . . 329
Value-Added Services: Creating a Hold Type 263 Schedule . . . . . . . . . . . . . . 330
Value-Added Services: Modifying a Hold Type 266 Send Invoice . . . . . . . . . . . . 333
Value-Added Services: Deleting a Hold Type 266 Send Item Changes . . . . . . . . . . 335
Defining Value-Added Services Process Types . . 266 Send Customer Changes. . . . . . . . . 336
Viewing Value-Added Services Process Type Send Order . . . . . . . . . . . . . 338
Details . . . . . . . . . . . . . . 267 Send Release . . . . . . . . . . . . 339
Defining Value-Added Services Process Model . . 267 Start Order Negotiation . . . . . . . . . 340
Value-Added Services: Pipeline Determination 267 Synchronize Colony Map . . . . . . . . 341
Value-Added Services: Pipelines . . . . . . 268 Update Best Match Region . . . . . . . . 343
Value-Added Services: Transactions . . . . . 269 PopulateOwnershipTransferSummary . . . . 345
Value-Added Services: Statuses . . . . . . 270 YSCRecycleEntityAttributeAgent . . . . . . 346
Value-Added Services: Conditions . . . . . 271 Time-Triggered Purge Transactions . . . . . . 346
Value-Added Services: Actions . . . . . . 272 Purge Strategy . . . . . . . . . . . . 347
Value-Added Services: Service Definitions . . . 272 Configuring Purge Transaction Log Files . . . 347
Viewing Value-Added Services Date Types . . 273 Available Purges . . . . . . . . . . . 348
Defining Value-Added Services Event Task Queue Syncher Time-Triggered Transactions 425
Monitoring . . . . . . . . . . . . . 273 Load Execution Task Queue Syncher . . . . 425
Viewing Value-Added Services Purge Criteria . . 275 Order Delivery Task Queue Syncher. . . . . 426
Order Fulfillment Task Queue Syncher . . . . 427
Chapter 26. Time-Triggered Order Negotiation Task Queue Syncher . . . 428
Transaction Reference . . . . . . . 277 Quote Fulfillment Task Queue Syncher . . . . 429
Monitors . . . . . . . . . . . . . . . 430
Time-Triggered Transaction Reference . . . . . 277
Availability Monitor . . . . . . . . . . 431
Running Time-Triggered Transactions . . . . . 278
Exception Monitor. . . . . . . . . . . 432
Steps to Complete Before Scheduling
Inventory Monitor. . . . . . . . . . . 434
Time-Triggered Transactions . . . . . . . 278
Negotiation Monitor . . . . . . . . . . 435
Configuring Communication Between an Agent
Enhanced Order Monitor . . . . . . . . 436
and a JMS Server . . . . . . . . . . . . 278
Enhanced Quote Monitor . . . . . . . . 439
Prerequisites. . . . . . . . . . . . . 279
Enhanced Return Monitor . . . . . . . . 441
Create an Initial Context Factory Code . . . . 279
Real-time Availability Monitor . . . . . . . 444
Define the Transaction Information . . . . . 280
Shipment Monitor . . . . . . . . . . . 451
Business Process Time-Triggered Transactions . . 281
Work Order Monitor . . . . . . . . . . 453
Asynchronous Request Processor . . . . . . 281
Case Insensitive Data Loader . . . . . . . 282
Change Load Status . . . . . . . . . . 284 Chapter 27. Order Modification Types 455
Change Shipment Status. . . . . . . . . 285 Order Modification Types . . . . . . . . . 455
Close Delivery Plan . . . . . . . . . . 286
Close Load . . . . . . . . . . . . . 288 Chapter 28. Condition Builder
Close Manifest . . . . . . . . . . . . 289 Attributes . . . . . . . . . . . . . 467
Close Order . . . . . . . . . . . . . 291 Condition Builder Attributes . . . . . . . . 467
Close Receipts . . . . . . . . . . . . 292 Sales Order . . . . . . . . . . . . . . 468
Close Shipment. . . . . . . . . . . . 294 Order Fulfillment . . . . . . . . . . . 468
Collect Shipment Statistics . . . . . . . . 295 Order Negotiation . . . . . . . . . . . 470
Consolidate Additional Inventory . . . . . 297 Outbound Shipment . . . . . . . . . . 471
Consolidate To Shipment . . . . . . . . 298 Receipt . . . . . . . . . . . . . . 472
Create Catalog Index . . . . . . . . . . 300

Contents vii
Planned Order . . . . . . . . . . . . . 472 WMS Putaway . . . . . . . . . . . . . 481
Planned Order Execution . . . . . . . . 472 WMS Layout Definition . . . . . . . . . . 481
Planned Order Negotiation . . . . . . . . 472 WMS Inventory . . . . . . . . . . . . 481
Return Order . . . . . . . . . . . . . 472 Trailer Loading . . . . . . . . . . . . . 481
Reverse Logistics . . . . . . . . . . . 472 Task Execution . . . . . . . . . . . . . 481
Return Shipment . . . . . . . . . . . 474 Move Request Execution . . . . . . . . . 481
Return Receipt . . . . . . . . . . . . 474 Manifesting . . . . . . . . . . . . . . 482
Template Order. . . . . . . . . . . . . 475 Over Pack Build . . . . . . . . . . . . 482
Purchase Order. . . . . . . . . . . . . 475 Count Execution . . . . . . . . . . . . 482
Purchase Order Execution . . . . . . . . 475 Pack Process. . . . . . . . . . . . . . 483
Purchase Order Negotiation . . . . . . . 477 Outbound Picking . . . . . . . . . . . . 485
Inbound Shipment. . . . . . . . . . . 477 VAS Process . . . . . . . . . . . . . . 485
Purchase Order Receipt . . . . . . . . . 477 Opportunity . . . . . . . . . . . . . . 486
Transfer Order . . . . . . . . . . . . . 477 Opportunity Fulfillment . . . . . . . . . 486
Transfer Order Execution . . . . . . . . 477 Item Based Allocation . . . . . . . . . . 487
Transfer Order Delivery . . . . . . . . . 477
Transfer Order Receipt . . . . . . . . . 478 Index . . . . . . . . . . . . . . . 491
Master Order Fulfillment . . . . . . . . . 478
Quote Fulfillment . . . . . . . . . . . . 479
Notices . . . . . . . . . . . . . . 495
Load Execution. . . . . . . . . . . . . 479
General . . . . . . . . . . . . . . . 480

viii Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 1. Introduction
Introducing Distributed Order Management
This book concentrates on the rules and setup configurations that make up the
Sterling Distributed Order Management business application in the Applications
Manager. This book is intended for both Hub and Enterprise administrators using
the Applications Manager to set up the IBM® Sterling Selling and Fulfillment
Foundation environment. Business analysts should also use this book to plan
appropriate business practices as they pertain to Sterling Selling and Fulfillment
Foundation. Programmers and System Integrators should refer to the Sterling
Selling and Fulfillment Foundation: Extending Transactions and the Sterling Selling and
Fulfillment Foundation: Integration Guide for information about extending or
integrating external applications with Sterling Selling and Fulfillment Foundation.

Note: This book assumes that you have read and are familiar with the concepts
and business functionality detailed in the Sterling Selling and Fulfillment Foundation:
Product Concepts Guide.

Applications Manager

The Applications Manager is a collection of all the rules and setup configurations
necessary to implement Sterling Selling and Fulfillment Foundation organized so
that configuration can be done for each business application separately. The
following business applications can be configured within the Applications
Manager:
v Sterling Distributed Order Management
v IBM Sterling Global Inventory Visibility
v Catalog Management
v IBM Sterling Logistics Management
v IBM Sterling Supply Collaboration
v IBM Sterling Reverse Logistics
v IBM Sterling Application Platform

Business Models
There is no single business model that encompasses the environment in which all
the Sterling Selling and Fulfillment Foundation applications can be used. Therefore,
there is no single way to configure your Sterling Selling and Fulfillment
Foundation environment.

For example, your company might be considered a multidivisional corporation, a

third-party logistics company, or a marketplace business. Each of these business
models require a different conceptual approach to the Sterling Selling and
Fulfillment Foundation configuration.

Multidivisional Corporation
The multidivisional corporation model is a business corporation whose primary
focus is managing purchase and sales activities. A typical multidivisional
corporation can be a buyer, a seller, or both. It could also be a retailer, a
manufacturer, or both. Whatever form the multidivisional corporation takes, it

© Copyright IBM Corp. 1999, 2012 1

 normally has multiple channels with different types of customers, such as,
consumers, retailers, dealers, and original equipment manufacturers.

In the multidivisional corporation model, each division might be set up as an

Enterprise in Sterling Selling and Fulfillment Foundation. This setup allows both
segregation of transactions by division and global visibility at the corporate level.
Each Enterprise configures their own business rules, workflow, and transaction
processing.

Third-Party Logistics
Traditional third-party logistics companies provide a range of outsourced services
such as warehousing, transportation, and contract manufacturing.

Large companies can gain the competitive advantage through the real-time
management of their supply chains. These advantages include lower costs and
improved customer service. Additionally, new sales channels such as web stores,
hand-held devices, and in-store kiosks provide companies new methods of
reaching their customers. All of these issues have increased the complexity of the
fulfillment process.

In the third-party logistics model, each client might be set up as an Enterprise. This
setup allows the third-party logistics Hub to have visibility of all transactions in
the Hub environment, while the clients that are set up as Enterprises only have
visibility to their own transactions. This allows the third-party logistics business to
provide unique transaction processing to its clients.

Marketplace
A marketplace is an online intermediary that connects Buyers and Sellers.
Marketplaces eliminate inefficiencies by aggregating offerings from many Sellers or
by matching Buyers and Sellers in an exchange or auction. For Buyers, they lower
purchasing costs and help them reach new Sellers. For Sellers, they lower sales
costs and give them access to new customers. It is a central location, or Hub,
where a trusted intermediary integrates both procedures and technology to lower
the costs and enhance the effectiveness of Buyer and Seller transactions.

In the marketplace model, each market might be set up as an Enterprise. This

setup allows each market to be unique with their own product or service handling.

Sterling Distributed Order Management Configuration

Sterling Distributed Order Management provides configurable business rules and
workflow used to automate the manual processes associated with managing
fulfillment in an extended supply chain. Sterling Distributed Order Management
addresses the entire order process from order creation to settlement. Each order
line can easily follow a unique process based upon any order-related attribute or
business rule. It automatically creates and tracks any processes that result from, or
depend upon, the original customer order.

In the Applications Manager, you can use Sterling Distributed Order Management
configuration grouping to establish both cross-application and order document
specific rules and attributes. Cross-application rules and attributes can impact other
applications, such as Supply Collaboration or Reverse Logistics. Order document
specific rules and attributes pertain only to the order document type you are

2 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 configuring, such as Sales Order or Transfer Order. You can define different
configurations for individual order document types without impacting other
applications or order document types.

You can use the Distributed Order Management configuration grouping to

configure various aspects of Sterling Selling and Fulfillment Foundation for your
business application modules.

Sourcing Setup
Sourcing is the process of determining what node should be used to ship or
provide product, delivery service, and provided service items.

You can define the rules and components necessary to determine the appropriate
node and suppliers used to source items. These rules and components are used
when there are multiple nodes and suppliers from which you can source items and
services.

For more information about Sourcing Setup, see “Configuring Cross-Application

Order Promising Components” on page 23.

Logistics
You can configure the components used by different logistics related functionality
throughout the Distributed Order Management business application module.

For more information about Logistics, see Chapter 5, Configuring

Cross-Application Logistics Components.

Financials
You can configure the components used by the Sterling Selling and Fulfillment
Foundation financial engine throughout the Distributed Order Management
business application module.

For more information about Financials, see "Configuring Cross-Application Pricing

Components" and "Configuring a Document's Financial Components".

Customer
You can define the customers that buy from an organization in the Distributed
Order Management module.

For more information about Customer, see “Configuring Cross-Application

Customer Components” on page 127.

Order Attributes
You can define common codes as they pertain to order documents viewed in the
Application Consoles.

For more information about Order Attributes, see Chapter 9, Configuring a

Document’s Attributes.

Order Validation
You can define configuration for validating certain aspects of an order during
order document creation.

Chapter 1. Introduction 3
 For more information about Order Validation, see Chapter 10, Configuring a
Document’s Order Validation.

Instruction Types
You can define the common codes used when adding special instructions to an
order document.

For more information about instruction types, see Chapter 11, Configuring a
Document’s Instruction Types.

Modification Reasons
You can define common codes for modification reasons. These codes define why a
modification was made by a user.

For more information about Modification Reasons, see Chapter 12, Configuring a
Document’s Modification Reasons.

Backorder Reasons
You can define common codes for backorder reasons. These codes describe why an
order document was backordered.

For more information about Backorder Reasons, see Chapter 13, Configuring a
Document’s Backorder Reasons.

Process Type Configuration

To complete an order document's lifecycle, each document has a set of different
processes that it can go through. These processes are called process types. Every
order document has a defined set of process types in Sterling Selling and
Fulfillment Foundation.

The following process types are defined in Sterling Selling and Fulfillment
Foundation for the order document types:
v Fulfillment
v Negotiation
v Shipment
v Receipt

You can configure the rules and components that define an order document's
process types.

For more about Process Type Configuration, see "Configuring an Order Document's
Fulfillment-Specific Components" and "Configuring an Order Document's
Shipment-Specific Components" .

Purge Criteria
You can define the parameters used when purging order document related records
from the system.

For more information about Purge Criteria, see Chapter 24, Configuring a
Document’s Purge Criteria.

4 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Icons Used in This Guide
The following table describes the icons used in this guide.
Table 1. Icons Used in This Guide
Icon Name Description
Create New Click this icon to create
new configuration
information or details for
order promising, pricing,
logistics, and so forth. As
shown, you may see this
icon with different
backgrounds, depending
on the context within
which you are working.
Details Click this icon to view or
change configuration
details for order promising,
pricing, logistics, and so
forth. As shown, you may
see this icon with different
backgrounds, depending
on the context within
which you are working.
Delete Click this icon to delete
configuration details for
order promising, pricing,
logistics, and so forth. As
shown, you may see this
icon with different
backgrounds, depending
on the context within
which you are working.
Save Click this icon to save
entries you have made.
The Save icon may be
displayed in blue or gold.
Save As Click this icon to create
new notes and rules that
are based on the existing
ones.
Search Click this icon to search for
configuration information
about order promising,
pricing, logistics, and so
forth. and so forth.
Check Additional Click this icon to check
Questions additional questions about
capacity impact.
Load Rules for Click to display the Load
Organization Organization for
Configuration pop-up
window, from which you
can display a specified
organization's rules.

Chapter 1. Introduction 5
 Table 1. Icons Used in This Guide (continued)
Icon Name Description
Refresh Click to refresh the screen
with your criteria.
Move Up Arrow Click to move questions up
in the question group.
Move Down Arrow Click to move questions
down in the question
group.
Move Right Arrow Click to move the item to
the list on the right.
Move Left Arrow Click to move the item to
the list on the left.
Transactions Click to display the
Transactions list.
Statuses Click to display the
Statuses list.
Conditions Click to display the
Conditions list.
Actions Click to display the Actions
list.
Service Definitions Click to display the Service
Definitions.
Zoom In Click this to zoom in on
your screen.

6 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 2. Navigating the Applications Manager
Starting the Applications Manager
About this task

To access the Applications Manager:

Procedure
1. Point your browser to http://<hostname>:<portname>/smcfs/console/
start.jsp
where,
v hostname is the computer name or IP address of the computer where Sterling
Selling and Fulfillment Foundation is installed.
v portnumber is the listening port of the computer where Sterling Selling and
Fulfillment Foundation is installed.
The browser displays the Sign In window.
2. Enter your login ID and password and choose the Sign In button. The Console
Home Page is displayed.
3. From the menu bar, choose Configuration > Launch Applications Manager. The
Applications Manager opens in a new window.
Additionally, enterprise users who maintain an enterprise can access the
Applications Manager by means of http://<Sterling Selling and Fulfillment
Foundation installation server>/smcfs/console/login.jsp.
If both the Applications Manager and the monitor in the System Management
Console are opened at the same time, and if a dialogue window is opened in
either application, the other stops responding to user input until that dialogue
window is closed. This is due to a bug in the Java platform.

The Applications Manager Layout

The Applications Manager is a graphical user interface that can be used to
configure different aspects of Sterling Selling and Fulfillment Foundation. The
different configurations are defined by logical groupings called applications that
can be accessed from the Applications Manager menu bar.

Figure 1. Applications Menu

© Copyright IBM Corp. 1999, 2012 7

 Each application focuses on a particular aspect of Sterling Selling and Fulfillment
Foundation and contains all of the rules, common codes, and settings necessary for
Sterling Selling and Fulfillment Foundation to work in a real-world business
setting.

The following applications can be configured in this version of Sterling Selling and
Fulfillment Foundation:
v Distributed Order Management
v Global Inventory Visibility
v Catalog Management
v Logistics Management
v Supply Collaboration
v Reverse Logistics
v Application Platform

When you select the application that you want to configure, the Applications
Manager displays a side panel containing all of the available configuration rules
for the selected application and a work area in which these rules can be
configured.

Figure 2. The Standard Applications Manager Interface

Application Rules Side Panel

The application rules side panel displays a hierarchical tree of elements specific to
processes used within the application.

8 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Figure 3. Example of Application Rules Side Panel

The application rules side panel also identifies the organization you are
configuring rules for and what, if any, rules are inherited from another
organization.

You can use the application rules side panel for accessing configuration screens,
determining inheritance, and loading another organization's rules.

Accessing Configuration Screens

The main purpose of the application rules side panel is to provide an interface to
access the application’s individual configuration screens. To access a configuration
screen, browse through the application tree and double-click on the applicable
configuration element, the element’s configuration screen displays in the work
area.

Determining Inheritance
In Sterling Selling and Fulfillment Foundation, when an Enterprise is created it can
inherit all or part of an existing Enterprise's configuration rules. This inheritance is
done at the configuration group level. A configuration group is a classification of
similar configuration elements. For example, all of the rules and configurations
dealing with items are grouped together into one configuration group and all of
the rules and configurations dealing with organizations are grouped into another.

An administrator organization is set for every organization defined within the

system. Only the administrator organization can modify the rules defined for a
particular organization. If a particular organization administers multiple
organizations, then they can load the rules of organization that it administers
within the application tree. For more information about loading another
organization's rules, see “Loading Another Organization's Rules” on page 14.

Configuration groups are associated with organization levels. Organization levels

determine how configuration groups are inherited and which organizations can
maintain them. The organization levels defined in Sterling Selling and Fulfillment
Foundation are:
v Hub Level - Configuration groups that are associated with the Hub organization

Chapter 2. Navigating the Applications Manager 9

 v Enterprise Level - Configuration groups that are associated with the individual
Enterprise organizations within the Hub environment
v Catalog Organization - Configuration groups that are associated with the
organization(s) that maintains the catalog(s) within the Hub environment
v Inventory Organization - Configuration groups that are associated with the
organization(s) that maintains the inventory within the Hub environment
v Pricing Organization - Configuration groups that are associated with the
organization(s) that maintains the pricing within the Hub environment
v Organization - Configuration groups that are associated with any organization
within the Hub environment

The Applications Manager does not load configuration data and permissions based
on Data Access Policies that are described in the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

Enhanced Inheritance for Process Models

An Enterprise can inherit the configurations of the following entities from other
Enterprises:
v Pipelines
v User Exits
v Services
v Actions
v Conditions
v Statuses
v Transactions
v Events

When an Enterprise inherits these entities from some other Enterprise, the current
Enterprise can view the configurations that are inherited from all other Enterprises
(including the Hub) in the inheritance hierarchy. In addition, the current Enterprise
can view the configurations that are defined for the Hub.

For example, consider the following inheritance hierarchy:

In this hierarchy, Enterprise E1 is inheriting from Enterprise E2, which in turn is

inheriting from Enterprise E3. Enterprise E1 can view the configurations that are
defined for Enterprise E2 and Enterprise E3. In addition, Enterprise E1 can view
the configurations that are defined for the Hub.

10 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Organization Level Rules
The following table details the rules used to determine which organizations can
maintain a configuration group as defined by the organization level. The table also
describes the rules that determine how configuration groups are inherited when an
organization is created.
Table 2. Organization Level Rules
Organization Organizations That Can Modify
Level at this Level... Inheritance Details
Hub Level Only the Hub organization can All organizations share this
modify configuration groups at information.
the Hub level. All other
organizations have read-only
access.
Enterprise Level Only Enterprise organizations An Enterprise can inherit this
can modify configuration groups configuration from another
at the Enterprise level. Enterprise. Additionally, this
configuration can be overridden at a
Any business transaction configuration group level.
requiring Enterprise
configuration is picked up from
the Enterprise established by the
transactional context. For
example, order documents have
a specific Enterprise.
Catalog Organizations that are designated None.
Organization as catalog organizations can
modify configuration groups at
the catalog organization level.
Inventory Organizations that are designated None.
Organization as inventory organizations can
modify configuration groups at
the inventory organization level.
Pricing Organizations that are designated None.
Organizations as pricing organizations can
modify configuration groups at
the pricing organization level.
Organization Any organization assigned a role None.
(Seller, Buyer, etc.) can modify
configuration groups at the
organization level.

You cannot inherit from an Enterprise that does not have the same inventory,
capacity, and catalog organizations as the organization you are configuring.

Applications Rule Side Panel

The application rules side panel displays rules that have been inherited as grayed
out.

Chapter 2. Navigating the Applications Manager 11

 Figure 4. Inherited Rules in the Application Rules Side Panel

As stated in the table above, depending on the organization you are logged in as,
you may be able to override some inherited rules. If a rule can be overridden, the
Override Configuration icon becomes available in the application rule side panel
when you highlight the rule.

Figure 5. Override Configuration Icon

When you choose to override a rule you also override any other rules in the
configuration group the rule you are overriding is associated with. When you
choose the Override Configuration icon the Configuration Override Details pop-up
window displays. This window provides the list of rules that are overridden.

12 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Figure 6. Example of Configuration Override Details Pop-Up Window

Overriding a Configuration Group

If you override a configuration group and then decide to "re-inherit" the original
rules, you can choose the Give Back Configuration Ownership icon. This icon
becomes available in the application rules side panel for rules that have been
overridden.

Figure 7. Give Back Configuration Ownership Icon

Chapter 2. Navigating the Applications Manager 13

 When you select the Give Back Configuration Ownership Icon, the Configuration
Override Details pop-up window displays. This window provides the list of rules
that are re-inherited.

Note: If you select the Delete Rules field on the Configuration Override Details
pop-up window, you give back rule ownership to the organization you originally
inherited from, but you do not retain any of the rules that you inherited from
them. If you do not select this field, you give back rule ownership to the
organization you originally inherited from, but you retain the rules that you
inherited from them.

Loading Another Organization's Rules

About this task

An administrator organization is set for every organization defined within the

system. Only the administrator organization can modify the rules defined for a
particular organization. If a particular organization administers multiple
organizations, then they can load the rules of organization that it administers
within the application tree. See Table 2 on page 11 for the rules that determine
which organizations you can administer.

The rules that are available from the tree in the application rules side panel may
vary depending on the type of organization you select and the roles it has been
assigned.

To load another organization's rules:

Procedure
1. From the applicable application rules side panel, choose the Load Rules for
Organization icon. The Load Organizations for Configuration pop-up window
displays.
2. From Organization, select the organization that you want to work with.
3. Choose OK. The organization's rules display in the application rules side panel.

Results

The application rules side panel displays the organization you are working with in
parentheses.

Work Area
The work area is the main area in which different configuration screens appear.
The main types of screens that you can see in the work area are the Search, List,
Details, and Drag and Drop windows.

Search Window
A search window provides you with a means to perform a filtered search. The
upper panel of a search window offers criteria applicable to the entity you are
searching through which you can narrow your search. The lower panel lists the
results of a search once it has been performed.

14 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Figure 8. Search Window Example

List Window
When you choose to configure a specific rule or code that does not require a
search, the Applications Manager may display a basic list window of the rules and
codes that have previously been configured.

Chapter 2. Navigating the Applications Manager 15

Figure 9. List Window Example

Details Window
A details window is the main interface through which a bulk of the configuration
is done. A details window can contain editable fields and tables, tabs to configure
different aspects of an entity, and additional actions that can be performed on an
entity.

16 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Figure 10. Details Window Example

Drag and Drop Window

You can use a graphical drag and drop window to ease the construction of
pipelines, pipeline determination, event handlers, status monitoring rules, and
services. A drag and drop window consists of a pallet and a graphical work area.

Chapter 2. Navigating the Applications Manager 17

Figure 11. Drag and Drop Window Example

To begin building any of these entities, choose a component, such as a transaction,

from the pallet. Drag the component into the graphical work area. The transaction
is now displays as a graphical representation of itself.

To connect one component to another, you must drag the mouse from the outgoing
port of a component until it forms a connecting line with the incoming port of
another component. The links between components can be set up either
horizontally or vertically.

To delete components or links, right-click on the component and choose Delete.

Once components and links have been established you can move them around by
dragging them, the links redraw themselves according to the new position. If you
press and hold the CTRL key while dragging a component, the component is
copied within the graphical work area.

Actions Available in the Applications Manager

Through the Applications Manager, you can use the lookup functionality, view
logged in users, use lists and list filtering, troubleshoot errors, and use special
characters.

18 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Using the Applications Manager's Lookup Functionality
Throughout the Applications Manager there are many fields that have a lookup
functionality to find or create additional records as they pertain to that field. For
example, on the Primary Info tab of the Organization Details screen, the Locale
field has a lookup functionality to create a new locale from that screen. When you
choose the Create New lookup button the Locale Details information displays in a
pop-up screen for you to modify.

Figure 12. Lookup Icon Example

The information that displays in a lookup field varies depending on how many
records you have pertaining to that particular field. When there are 20 or less
records, the lookup displays as a drop-down list with a Create New button. When
there are between 21 and 75 records, the lookup displays as a drop-down list with
a Search button.

When there are more than 75 records, the lookup displays as a text box with a
Search button. You can type the value in the text box or search for the value using
the Search button. If you enter a value, it is validated when it is saved. You should
always type the value as it would appear if it was displayed as a drop-down list.
For example, for a currency lookup, you should type the currency description in
the text box even though the currency code is saved in the table. An error displays
on save if the user has entered an invalid value.

When you use a lookup for a particular field in the Applications Manager, you
should refer to the corresponding section in this guide to set up the particular
information.

Viewing the Document Types Associated with an Application

In the Distributed Order Management, Supply Collaboration, Reverse Logistics,
and Logistic Management configuration applications, you can view all of the
document types associated with the application. Sales Order, Transfer Order,
Master Order, Quote, and Purchase Order are all examples of document types.

To view an application's associated document types, open the applicable

application from the menu and choose the Create New icon from the application
rules side panel. The Associated Document Types window displays displaying a
list of all of the document types associated with the application you are working
in.

Chapter 2. Navigating the Applications Manager 19

 Figure 13. Associated Document Types Window

Adding a Document Type to an Application

About this task

You can add a document type that is associated with another application to the
application you are currently working in.

An added document type's associated screens may be irrelevant to the application

you are associating it with.

To add a document type to an application:

Procedure
1. From the Associated Document Types window, choose the Create New icon.
The Associated Document Type pop-up window displays.
2. From Document Type, select the document type that you want to associate with
the application.
3. Select Enable Access To This Document Through This Application's Console.
4. Choose the Save icon.

Viewing the User Logged into the Applications Manager

About this task

You can view the user logged into the Applications Manager and their locale at
any time. To view this information, move your mouse over the User icon and
Locale icons in the bottom right-hand corner of the application to display the tool
tips.

20 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Using Lists and List Filtering
About this task

When viewing any list in the Applications Manager, it is possible to filter the
contents of the list based in criteria that you define. Filtering is accomplished by
right-clicking anywhere on the list's column headings and using the Table Filter
Editor associated with the list.

Figure 14. Column Headings in a List

Table 3. Table Filter Editor Window

Field Description
Apply To Existing Records Checking this box applies a new filter set of results that have
been previously filtered instead of the whole set.
Max Records Specify the maximum number of records that are to be
returned from a filter. The default number is 100
Dynamic Fields Fields such as "Hold Type" and "Hold Type Description" are
dynamically populated based on the list you are currently
viewing.

These fields can be searched using text strings combined with

criteria such as Is, Starts With, or Contains.

Search strings are case sensitive. For example, "Item" does not return the same
values as "item".

Date and Time Entry

Date fields through the Applications Manager have a calendar icon that can be
used to find dates as it pertains to that field. When you click on this icon, a small
calendar displays. You can navigate through this calendar to determine the
appropriate date. For example, on the Create Calendar window, the Default
Effective To field has a calendar icon that you can use to verify the appropriate
ship by date to populate the field.

Figure 15. Calendar Icon example

Chapter 2. Navigating the Applications Manager 21

 You can also enter time of day information throughout the Applications Manager.
To do this, double click on the time field, and enter the time of day.

Figure 16. Time Field example

Time should be entered in a 24 hour time format everywhere throughout the

Applications Manager .

Troubleshooting Errors
About this task

You can view the description and cause of any error raised in Sterling Selling and
Fulfillment Foundation, as well as the actions to troubleshoot it.

To view the Sterling Selling and Fulfillment Foundation system error descriptions:

Procedure
1. From the menu bar, choose Help > Troubleshooting. The Error Search window
displays.
2. Enter the applicable search criteria and choose the Search icon. A list of error
codes and their descriptions display.
3. Choose the Details icon to view the cause of the error and action to
troubleshoot it.

Using Special Characters

Throughout the Applications Manager there may be instances where you need to
use special characters in data entry. For information about the use of special
characters in Sterling Selling and Fulfillment Foundation, see the Sterling Selling
and Fulfillment Foundation: Customization Basics.

22 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 3. Configuring Cross-Application Order Promising
Components
Configuring Cross-Application Order Promising Components
Order promising is the process of determining what node should be used to ship
or provide product, delivery service, and provided service items.

You can define the rules and components necessary to determine the appropriate
node and suppliers used to source items. These rules and components are used
when there are multiple nodes and suppliers from which you can source items and
services.

Order promising configurations can be used to determine sourcing based on:

v Where the items are being shipped from
v Ship to log50
v cation
v Availability at different locations
v Total number of shipments required to complete the request
v Node priority
v Delivery region

What Is the Fulfillment Network Model?

The Fulfillment Network Model is a geographical representation of your
configured nodes and their relationships. It also provides a variety of navigation
tools and filtering options that enable you to view only pertinent information.

Depending on the amount of data that needs to be processed, the fulfillment

network model may take up to a few minutes to load.

For more information about navigating in the Fulfillment Network Model, see
“The Fulfillment Network Model Work Area and Its Components.”

The Fulfillment Network Model Work Area and Its Components

The Fulfillment Network Model work area consists of a geographical map for
which you can define criteria such as node types, relationship types, and
distribution groups.

The Fulfillment Network Model: Map View

The Map View displays a geographical map. Depending on the filter criteria and
map legend options, the nodes and relationships in your fulfillment network
appear on this map. Nodes are represented as symbols of different shape, color,
and size. Relationships are represented as arrows of different color. The direction of
the arrow indicates the To Location and From Location for the relationship.

The Map Legend indicates what each symbol or arrow displayed on the Map
represents. Furthermore, unchecking the box next to a symbol or arrow on the Map

© Copyright IBM Corp. 1999, 2012 23

 Legend hides corresponding entities in the Map View. The Map Legend can be
dragged to any location within the Map View.

Note: The map could become unusable if your fulfillment network contains 4000
nodes and 3000 relationships.

The Fulfillment Network Model: Action Icons

The action icons allow you to navigate within the Map View, and perform various
tasks such as view node details or create relationships. Refer to Table 4 for
descriptions of each action icon available.
Table 4. Action Icons
Action Icon Description
Select Tool - With the Select tool, you can click on nodes or
relationships to select them. A selected node or relationship
becomes highlighted to distinguish it from other elements on
the map.

Double-clicking a node displays the node's details.

Double-clicking a relationship displays the relationship's

details.

You can click and drag to select multiple nodes and

relationships.
Zoom In - Click this action to zoom in on the current display
area.
Zoom Out - Click on this action to zoom out from the current
display area.
Zoom Selection Tool- With the Zoom Selection tool selected,
you can click and drag over the area of the map you want to
enlarge.
Zoom To Fit - Click this action to return the map to its
default magnification.
Pan Tool - With the Pan Tool selected, you can click and drag
within the display area to move the map.
View Node Types - Click this action to display the Node Type
List screen, where you can create, modify or delete node
types. For more information about configuring node types,
see “Defining Node Types” on page 27.
View Relationship Types - Click this action to display the
Relationship Type List screen, where you can create, modify
or delete relationship types. For more information about
configuring relationship types, see “Defining Relationship
Types” on page 30.
Create Distribution Group - Clicking this action after one or
more nodes are selected on the map displays the Create
Distribution Group screen. For more information about
creating a distribution group, see “Creating a Distribution
Group” on page 26.
View Distribution Groups - Click this action to display the
Product Sourcing Distribution Group screen, where you can
create, modify, or delete distribution groups. For more
information about defining distribution groups, see “Defining
Distribution Groups” on page 26.

24 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 4. Action Icons (continued)
Action Icon Description
Create Node - Click this action to display the Create Node
screen, where you can create a node organization. For more
information about defining nodes, see “Defining Nodes” on
page 28.
View Node Details - With a node selected on the map,
clicking this action displays the Node Details screen. For
more information about viewing and modifying node details,
see “Modifying a Node” on page 29.
Create Single Relationship - With two nodes selected on the
map, clicking this action displays the Relationship Details
screen, where you can create a relationship between the
nodes. For more information about defining relationships, see
“Defining Relationships” on page 31.
Create Relationships - With two or more nodes selected on
the map, clicking this action displays the Create Relationships
screen when you can create multiple relationships at once.
For more information about defining relationships, see
“Defining Relationships” on page 31.
View Relationship Details - With a relationship selected,
clicking this action displays the Relationship Details screen,
where you can view or modify relationships. For more
information about viewing or modifying relationships, see
“Modifying a Relationship” on page 32.
Remove Relationships - With one or more relationships
selected, clicking this action deletes the selected
relationship(s). For more information about deleting
relationships, see “Deleting a Relationship” on page 32.

The Fulfillment Network Model: Filter Criteria

The Filter Criteria enables a user to specify what entities display on the map. Users
can select or deselect what displays from a list of node types, relationship types
and distribution groups.

Using Filter Criteria

About this task

To use filter criteria:

Procedure
1. If the Filter Criteria panel is hidden, it can be made visible by clicking on the
UP arrow in the bottom-left corner of the work area.
2. Enter information into the applicable fields. Refer to Table 5 on page 26 for field
value descriptions.
3. Once you have specified your filter criteria, select the Refresh icon. The Map
View is updated with your filter criteria.
Upon clicking Refresh, your filter criteria is saved as a search. When revisiting
the Fulfillment Network Model, the most recently saved filter criteria and view
is used.

Chapter 3. Configuring Cross-Application Order Promising Components 25

 Table 5. Filter Criteria Panel
Field Description
Node Type The node type panel is dynamically populated with the node
types you have defined. Check the node types you want to
view, and uncheck the node types you want to hide.

For more information about defining node types, see

“Defining Node Types” on page 27.
Relationship Type The relationship type panel is dynamically populated with
the relationship types you have defined. Check the
relationship types you want to view, and uncheck the
relationship types you want to hide.
Note: Relationships only appear on the map if its To and
From nodes belong to a node type that has been selected in
the node type panel.

For more information about defining relationship types, see

“Defining Relationship Types” on page 30.
Highlight Distribution Select a distribution group from the drop-down list to be
Group highlighted on the map.

Node: Highlighted nodes only appear on the map if the

nodes belong to a node type that has been selected in the
node type panel.

For more information about defining distribution groups, see

“Defining Distribution Groups.”

Defining Distribution Groups

You can create a set of nodes that can be used when determining sourcing. You can
define distribution groups that establish the ship node determination process based
on priority.

Creating a Distribution Group

About this task

To create a distribution group:

Procedure
1. From the tree in the application rules side panel, choose Product Sourcing
Distribution Group. The Product Sourcing Distribution Groups window
displays in the work area.
2. Choose the Create New icon. The Distribution Group Detail window displays.
3. In Distribution Group, enter the name of the distribution group.
4. In Description, enter a brief description of the distribution rule.
5. Choose the Save icon.

Modifying a Distribution Group

About this task

To modify a distribution group from the Fulfillment Network Model screen:

26 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Procedure
1. Select the View Distribution Groups action icon. The Product Sourcing
Distribution Group screen displays.
2. Select the applicable distribution group from the list and choose the Details
icon. The Distribution Group Details screen displays.
3. Enter information into the applicable fields. Refer to Table 22 on page 59 for
field value descriptions.
4. Click the Save icon.

Deleting a Distribution Group

About this task

To delete a distribution group:

Procedure
1. From the tree in the application rules side panel, choose Product Sourcing
Distribution Group. The Product Sourcing Distribution Groups window
displays in the work area.
2. Select the applicable distribution rule and choose the Delete icon.

Defining Node Types

You can define node types to classify nodes. You can use node types to define
node relationships, and set inventory rules. For more information about defining
inventory node type rules, see the Sterling Selling and Fulfillment Foundation: Global
Inventory Visibility Configuration Guide.

Creating a Node Type

About this task

To create a node type:

Procedure
1. From the tree in the application rules side panel, choose Participant Modeling >
Node Types. The Node Type window displays in the work area.
2. Choose the Create New icon. The Node Type Details pop-up window displays.
3. Enter information into the applicable fields. Refer to Table 6 for field level
descriptions.
4. Choose the Save icon.
Table 6. Node Type Details Pop-up Window
Field Description
Node Type Enter a name for the node type.
Description Enter a description for the node type.

Modifying a Node Type

About this task

To modify a node type:

Chapter 3. Configuring Cross-Application Order Promising Components 27

 Procedure
1. From the tree in the application rules side panel, choose Participant Modeling >
Node Types. The Node Type window displays in the work area.
2. Select the applicable node type and choose the Details icon. The Node Type
Details pop-up window displays.
3. Enter information into the applicable fields. Refer to Table 6 on page 27 for field
level descriptions.
4. Choose the Save icon.

Deleting a Node Type

About this task

To delete a node type:

Procedure
1. From the tree in the application rules side panel, choose Participant Modeling >
Node Types. The Node Type window displays in the work area.
2. Select the applicable node type and choose the Delete icon.

Defining Nodes
You can use the Fulfillment Network Model to define node organizations.

Nodes created through the Fulfillment Network Model screen are automatically
defined as child organizations of the Enterprise that the fulfillment network model
belongs to.

For more information about participant modeling, see the Sterling Selling and
Fulfillment Foundation: Configuration Guide.

Creating a Node
About this task

To create a node from the Fulfillment Network Model screen:

Procedure
1. Select the Create Node action icon. The Create Node screen displays.
2. Enter information into the applicable fields. Refer to Table 7 for field value
descriptions.
3. Click the Save icon.
Table 7. Create Node Screen
Field Description
Organization Code Enter a unique code that identifies the node.
Organization Name Enter the name of the node.
DUNS Number Enter a unique nine-digit identification sequence, which
provides unique identifiers of single business entities. Sterling
Selling and Fulfillment Foundation does not associate any
logic with the DUNS number.
Account Number With Hub If the node is not the Hub, enter the account number that the
node has with the Hub.
Locale Select the node's geographic location.

28 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 7. Create Node Screen (continued)
Field Description
Parent Organization Select the node's parent organization.
Primary Enterprise If the node is not an Enterprise, select the applicable primary
Enterprise. The primary enterprise is defaulted on the entry
point order console screens (for example, on search screens
and create screens).

On the organization details screen, when creating or

modifying a node organization, the actions that appear on the
primary info tab of the node attributes tab are the actions
created for that enterprise. Whenever any enterprise level
configuration is retrieved in the back-end business logic for a
specific organization, the rules are always retrieved for the
primary enterprise of that organization. For more
information, refer to the Sterling Selling and Fulfillment
Foundation: Configuration Guide.
Node Type Select the node type for this node.
Address and Contact Info The address and contact information for this node
organization.

Choose the Details icon to enter an address.

Choose the Contact tab to view additional contact

information.

You can also specify latitude and longitude coordinates for

this address. If specified for a node, these coordinates are
used to plot the node on the Fulfillment Network Model.

Latitude and longitude need to be entered using decimal

format with a range of -90 to +90 for latitude and -180 to
+180 for longitude.
Note: When latitude and longitude coordinates have not
been specified, Sterling Selling and Fulfillment Foundation
plots the node using the zip code specified in the address
details.

Specifying latitude and longitude coordinates overrides the

plotting of a node by zip code location.

Modifying a Node
About this task

To modify a node's details from the Fulfillment Network Model screen:

Procedure
1. Double-click on the applicable node in the map view, or select the applicable
node in the map view and select the Node Details action icon. The
Organization Details screen displays.
For more information about defining node attributes, see the Sterling Selling and
Fulfillment Foundation: Configuration Guide.
2. Enter information into the applicable fields.
3. Click the Save icon.

Chapter 3. Configuring Cross-Application Order Promising Components 29

 Defining Relationship Types
You can define relationship types to classify relationships.

Creating a Relationship Type

About this task

To create a relationship type:

Procedure
1. Select the View Relationship Types action icon. The Relationship Type List
screen displays.
2. Choose the Create New icon. The Relationship Type Detail screen displays.
3. Enter information into the applicable fields. Refer to Table 8 for field value
descriptions.
4. Click the Save icon.
Table 8. Relationship Type Detail Screen
Field Description
Relationship Type Enter the name of the relationship type.
Description Enter a description for the relationship type.
From Name Enter a From Name. The From Name is used to identify the
From Location for this relationship type.

For example, in a "Store Replenishment" relationship type, the

From Name could be "Distribution Center".
To Name Enter a To Name. The To Name is used to identify the To
Location for this relationship type.

For example, in a "Store Replenishment" relationship type, the

To Name could be "Store".

Modifying a Relationship Type

About this task

To modify a relationship type:

Procedure
1. Select the View Relationship Types action icon. The Relationship Type List
screen displays.
2. Select the applicable relationship type from the list and choose the Details icon.
The Relationship Type Detail screen displays.
3. Enter information into the applicable fields. Refer to Table 8 for field value
descriptions.
4. Choose the Save icon.

Deleting a Relationship Type

About this task

To delete a relationship type from the Fulfillment Network model screen:

30 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Procedure
1. Select the View Relationship Types action icon. The Relationship Type List
screen displays.
2. Select the applicable relationship type from the list and choose the Delete icon.

Defining Relationships
You can define relationships between two nodes.

Creating a Relationship
About this task

You can create a single relationship between two nodes.

To create a single relationship between two nodes:

Procedure
1. Select the Add Single Relationship action icon.
2. On the map, click on the From Node. A line is extended from that node.
3. Click on the To Node to connect the From Node to the To Node. The
Relationship Type List displays.
4. From the Relationship Type List, select the relationship type for this
relationship and choose Select.

Results

To create multiple relationships of the same type from one node to several other
nodes, or from several nodes to one node, refer to “Creating Multiple Relationships
of the Same Relationship Type.”
Table 9. Relationships Creation Criteria Details Screen
Field Description
Node If you are creating relationships from one node to many
nodes, select the single From Node from the dropdown list.

If you are creating relationships from many nodes to one

node, select the single To Node from the dropdown list.
Selected Node Is From Node - choose this option if the node selected in the
"Node" field is the From Node for the relationships.

To Node - choose this option if the node selected in the

"Node" field is the To Node for the relationships.
Relationship Type Select the relationship type for the relationships.

Creating Multiple Relationships of the Same Relationship Type

About this task

To create multiple relationships of the same relationship type from one node to
several other nodes, or from several nodes to one node:

Procedure
1. Using the Select tool, select the From Node(s) and To Node(s) between which
you want to create the same relationship.

Chapter 3. Configuring Cross-Application Order Promising Components 31

 2. Select the Add Relationships action icon. The Relationships Creation Criteria
Details window displays.
3. Enter information into the applicable fields. Refer to Table 9 on page 31 for field
value descriptions.
4. Choose OK.

Results

For additional information, refer to “Creating a Relationship” on page 31.

Modifying a Relationship
About this task

To modify a relationship:

Procedure
1. On the map, double-click the relationship you want to modify. The relationship
details screen displays.
2. Enter information into the applicable fields. Refer to the following table for
field value descriptions.
3. Choose the Save icon.

Results
Table 10. Relationship Details Window
Field Description
Relationship Type Select a relationship type for this
relationship from the drop-down list.
From Node Select the node from which items are sent.
For the Relationship To Node tab, this
option is defaulted to the node you are
configuring and disabled.
To Node Select the node at which transfer order items
are received. For the Relationship From
Node tab, this option is defaulted to the
node you are configuring and disabled.
Transfer Schedules
Effective From Indicates the date on which the schedule
takes effect.
Effective To Indicates the date on which the specified
transfer schedule stops being effective.
Days of the Week Indicates which days are eligible for items to
ship on during the transfer schedule.

Deleting a Relationship
About this task

To delete a relationship:

Procedure
1. On the map, select the relationship you want to delete. The relationship
displays highlighted.

32 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 2. Select the Remove Relationship action icon.
3. Click OK to confirm the deletion.

Defining Item Level Controls

About this task

You can define the notification and promising rules for a particular item. These
rules are used to determine node scheduling. For more information about
scheduling and scheduling rules, see “Defining Scheduling Rules” on page 47.

To define item level controls:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Item Level Controls. The Product Item Search window
displays in the work area.
2. Enter the applicable search criteria and choose the Search icon. A list of
product items displays.
3. Select the applicable item and choose the Details icon. The Item Level Control
pop-up window displays.
4. Enter information into the applicable fields. Refer to Table 11 for field value
descriptions.
5. Choose the Save icon.
Table 11. Item Level Control Pop-Up Window
Field Description
Release an order for this Enter how many days before an order's expected ship date a
item n days before node needs to receive communication to ship the item.
expected time of shipment
Minimum notification time Enter the minimum business hours it takes to ship the item
required at this node is n once an order has been released to the node.
hours prior to expected
time of shipment
ATP Rule Select the default available-to-promise rule to use to
determine availability for the item. For more information
about configuring ATP rules, see the Sterling Selling and
Fulfillment Foundation: Global Inventory Visibility Configuration
Guide.

Defining Levels of Service

The Level of Service Details window lets you define levels of service at the hub
level. After you define the levels of service, set up notification periods at the node
level for the different levels of service. See “Creating a Notification Period” on
page 40 for more information.

Creating a Level of Service

About this task

To create a level of service:

Chapter 3. Configuring Cross-Application Order Promising Components 33

 Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Levels of Service. The Levels of Service window displays in
the work area.
2. Choose the Create New icon. The Level of Service Details pop-up window
displays.
3. In Level of Service, enter the name of the level of service.
4. In Short Description, enter a brief description of the level of service. The
description is displayed on the corresponding service level tab in the Current
Notification Period window.
5. In Long Description, enter a more detailed description of the level of service.
6. Choose the Save icon.

Modifying a Level of Service

About this task

To modify a level of service:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Levels of Service. The Levels of Service window displays in
the work area.
2. Select the applicable level of service and choose the Details icon. The Level of
Service Details pop-up window displays.
3. In Short Description, enter a brief description of the level of service.
4. In Long Description, enter a more detailed description of the level of service.
5. Choose the Save icon.

Deleting a Level of Service

About this task

To delete a level of service:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Levels of Service. The Levels of Service window displays in
the work area.
2. Select the applicable level of service and choose the Delete icon.

Defining Node Level Controls

You can define the notification and promising rules for individual nodes that
belong to the organization. These rules are used to determine node scheduling. You
can also define the procurement transfer orders for the node, as well as view the
transfer schedules of the other nodes it participates with. For more information
about scheduling and scheduling rules, see “Defining Scheduling Rules” on page
47.

34 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Defining a Node's Primary Order Promising Information
About this task

To define a node's primary order promising information:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Node Level Controls. The Ship Node Search window
displays in the work area.
2. Enter the applicable search criteria and choose the Search icon. A list of nodes
displays.
3. Select the applicable node and choose the Details icon. The Node Details
pop-up window displays.
4. Enter information into the applicable fields. Refer to Table 12 for field value
descriptions.

Note: Any information entered in this window overrides any information

previously defined for the node in Sterling Application Platform's Participant
Modeling configuration. For more information about configuring a node
organization, see the Sterling Selling and Fulfillment Foundation: Configuration
Guide.
5. Choose .
Table 12. Node Details Pop-Up Window, Primary Information Tab
Field Description
Do not schedule an order Enter the maximum number of business days that a schedule
to this node more than n can be sent to a node for it to be fulfilled. This number is
days before expected time used when performing earliest schedule date calculations.
of shipment Note: This parameter is only considered if the node is
pre-specified on the order line.
Receiving Calendar Select the calendar to use to determine the available shifts for
receiving deliveries at the node. The calendars of the node as
well as the calendars of the primary enterprise of the node
display in this drop-down list.
Shipping Calendar Select the calendar to use to determine the available shifts
during which the node can ship orders. The calendars of the
node as well as the calendars of the primary enterprise of the
node display in this drop-down list.
Track Inventory Select Track Inventory if you want the ship node to track
minimum and maximum inventory levels for an item.

Chapter 3. Configuring Cross-Application Order Promising Components 35

 Table 12. Node Details Pop-Up Window, Primary Information Tab (continued)
Field Description
Use End Of Shift Time Check this box if you want the node to base shipment time
by the end of the next feasible shift.

Uncheck this field if you want the node to base shipment

time by any given node parameters, such as Minimum
Notification Time, and the time a shipment can actually be
shipped.

For example, a node works five days a week, with two shifts,
8AM - 4PM and 4PM - 8PM.

The node's Minimum Notification Time is set to 2 hours.

If an order is sent to a node on Friday at 1PM, the order is

scheduled to ship on same day at 4PM if Use End Of Shift
Time box is checked. The order is scheduled to ship on the
same day at 3PM if Use End Of Shift Time box is unchecked.

If an order is sent to a node on Friday at 3PM, the order

scheduled to ship on the same day at 8PM if Use End Of
Shift Time box is checked. The order is scheduled to ship on
the same day at 5PM if Use End Of Shift Time box is
unchecked.
Note: Use End Of Shift Time is only applicable to nodes that
use a shipping calendar that has shift times defined.
Note: Use End Of Shift Time is only applicable for product
lines.
Work Order Creation Is Choose this box if you want to use Work Orders to support
Allowed compliance services at this node. Work Orders describe the
service activities to customize items based on a buyer's
requests.
Substitution Is Allowed Choose this if substitution of product items within an order is
allowed.
Procure/Transfer to this Check this box if the node can accept procurement/transfer
Node when Inventory is orders. For more information about procurement orders, see
not available “Defining Procurement Rules” on page 71.
Requires Transfer Check this box if you want this node to accept a procurement
Acceptance to confirm availability before proceeding with the order.
Item-Based Allocation Check this box to allow item based allocation for the item.
Allowed When the 'Use Item Based Allocation' rule is enabled, the
item based allocation are only applicable for the items and
nodes which have the Item Based Allocation Allowed
attribute enabled. For more information about item-based
allocation, see the Sterling Selling and Fulfillment Foundation:
Product Concepts Guide
Receipt Processing Time Enter how many hours it takes the node to process receipts.
For Procurement (Hours)
Receipt Processing Time for Enter the time it takes the node to process receipts for
Forwarding (Hours) forwarding in hours.
Receipt Processing Time for Enter how many days are required to process incoming
Future Inventory (Days) future supplies before they are available for orders.
Node Can Ship To
Any Address Check this box if this node can ship to any address.

36 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 12. Node Details Pop-Up Window, Primary Information Tab (continued)
Field Description
All Nodes Select this option if this node can ship to all nodes.
Specific Nodes of Type If this node can only ship to nodes with a specific node type,
select this option, and check the applicable node types
available. For more information about creating node types,
see the Sterling Selling and Fulfillment Foundation: Configuration
Guide.

Defining a Node’s Relationships

A transfer order is a type of chained order that is created when a node that
belongs to the organization you are configuring needs to replenish their stock from
another node within the organization to fulfill an order. A chained order is an
order that is linked to a parent order in which the lifecycle of one effects the other.

You can define a relationship between the node you are defining and another
node. Within this relationship you can define a transfer schedule, including the
transit time to procure items from a node, on a day-of-week basis. The schedule is
used for calculating expected dates.

You can define a transfer schedule that determines when items can be shipped
from one node to another, including the transit time to procure items from a node,
on a day-of-week basis. The schedule is used for calculating expected dates. For
more information on creating Transfer Schedules, refer to section “Defining a
Transfer Schedule” on page 39.

You can create, modify, and delete relationships.

Creating a Node Relationship

About this task

To create a node relationship:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. To create a node relationship from the node to another node, choose the
Relationship To Node tab. To create a node relationship to the node from
another node, choose the Relationship To Node tab.
3. Choose the Create New icon. The Relationship Details pop-up window
displays.
4. Enter information into the applicable fields. Refer to Table 13 for field value
descriptions.
5. Choose the Save icon.
Table 13. Relationship Details Pop-Up Window
Field Description
Relationship Type Select a relationship type for this relationship from the
drop-down list.

Chapter 3. Configuring Cross-Application Order Promising Components 37

 Table 13. Relationship Details Pop-Up Window (continued)
Field Description
From Node Select the node from which items are sent. If you select the
ShipNode from a lookup, a description must be configured
for the ShipNode in order to display a value in the From
Node field.

For the Relationship To Node tab, this option is defaulted to

the node you are configuring and disabled.
To Node Select the node at which transfer order items are received. If
you select the ShipNode from a lookup, a description must be
configured for the ShipNode in order to display a value in
the To Node field.

For the Relationship From Node tab, this option is defaulted

to the node you are configuring and disabled.
Transfer Schedules
Effective From Indicates the date on which the schedule takes effect.
Effective To Indicates the date on which the specified transfer schedule
stops being effective.
Days of the Week Indicates on which days during the transfer schedule items
are eligible for items to ship.

Modifying a Node Relationship

About this task

To modify a node relationship:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. To modify a node relationship from the node to another node, choose the
Relationship To Node tab. To modify a node relationship to the node from
another node, choose the Relationship To Node tab.
3. From the table, locate the applicable relationship and choose the Details icon.
The Relationship Details pop-up window displays.
4. Enter information into the applicable fields. Refer to Table 13 on page 37 for
field value descriptions.
5. Choose the Save icon.

Deleting a Node Relationship

About this task

To delete a node relationship:

Procedure
1. From the Roles & Participation tab in the Organization Details window, choose
Node Attributes.
2. To delete a node relationship from the node to another node, choose the
Relationship To Node tab. To modify a node relationship to the node from
another node, choose the Relationship To Node tab.
3. From the table, locate the applicable relationship choose the Delete icon.

38 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Defining a Transfer Schedule
Transfer schedules provide a means to allow or disallow a transfer during a
specific period of time.

Creating a Transfer Schedule

About this task

To create a transfer schedule:

Procedure
1. From the Relationship Details screen, choose the Create New icon from the
Transfer Schedules panel. The Transfer Schedule window displays.
2. Enter information into the applicable fields. For field value descriptions see
Table 14.
3. Click the Save icon.
Table 14. Transfer Schedule Window
Field Description
Effective From Date Select the date on which the transfer schedule becomes
effective.

If this value is left empty, it is assumed that the Transfer

Schedule has been effective for an infinite number of days.
Effective To Date Select the date on which the transfer schedule ends.

If this value is left empty, it is assumed that the Transfer

Schedule remains effective indefinitely.
Default Transit Days Enter the minimum number of days shipments are expected
to take to reach the end location.
Shipped On
Day Of Week Check the box for each day of the week on which transfers
are permitted.
Override Transit Days Enter the number of transit days for a specific day of the
week. For example, shipping on a Saturday may add one day
to the number of transfer days. As a result, the new Transfer
Days value would be 1 + the amount of the standard value.
Ship Date Overrides
Ship Date Select the date for which you would like to override
shipping. For example, Tuesday, December 25, 2007, a
holiday.
Can Ship Select Yes to allow or No to disallow shipping on the
specified day.
Override Transit Days Enter the override transit days for the override dates.

Note: If a transfer schedule exists for one day, it is assumed that a transfer
schedule exists for all days.

Modifying a Transfer Schedule

About this task

To modify a transfer schedule:

Chapter 3. Configuring Cross-Application Order Promising Components 39

 Procedure
1. From the Relationship Details screen, Transfer Schedules panel, select the
Transfer Schedule you would like to modify.
2. Choose the Details icon.
3. Enter information into the applicable fields. For field value descriptions, see
Table 14 on page 39.
4. Click the Save icon.

Deleting a Transfer Schedule

About this task

To delete a transfer schedule:

Procedure
1. From the Relationship Details screen, Transfer Schedules panel, select the
Transfer Schedule you would like to delete.
2. Choose the Delete icon.

Defining Notification Periods

You can configure specific days and times that a node will receive notification of
orders for shipping, and within each notification period, set up different levels of
service.

The Current Notification Period window enables you to specify:

v Advance notification time - the number of hours a node requires for notification
prior to expected time of shipment.
v Maximum working hours and system days - the number of working hours and
system days required by the ship node between releasing an order and expected
time of shipment. This parameter takes the ship node's calendar - such as
holidays and nonworking days- into account.
v Notification schedule - the times and days of the week that a ship node will
accept notifications.

You can create a variety of notification schedules based on calendar timeframes.

The resulting Notification Schedule List shows all the schedules, which you can
modify and delete.

Notification date is calculated as Expected shipment date - Maximum working

hours (including the shipping node's calendar) - Advanced notification days. An
order release is created on the notification date that is communicated to the
shipping node.

Creating a Notification Period

About this task

To create a notification period:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Node Level Controls. The Ship Node Search window
displays in the work area.
2. Enter the applicable search criteria and choose the Search icon. A list of nodes
displays.

40 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
3. Select the applicable node and choose the Details icon. The Node Details
pop-up window displays.
4. To create a notification period, choose the Notification Period tab.
5. Enter information into the applicable fields. Refer to Table 15 for field value
descriptions. You can create multiple Notification Periods, which will be
displayed in a list in the Notification Period List screen.
6. Choose the Save icon.
Table 15. Node Details Pop-Up Window, Notification Period Tab
Field Description
Current Notification Period
Effective From Date Enter the starting date of the notification period.
Effective To Date Enter the end date of the notification period.
Notification Details
Tabs: Specifies that the notification period is for advanced rush,
v Advanced Rush regular orders, or rush orders.
v Regular Orders See “Defining Levels of Service” on page 33 for information.
v Rush
Node needs to be notified Enter the minimum number of hours a node needs to be
at least <number of hours> notified before the expected time of shipment.
hours prior to expected
time of shipment
Release an order to this Enter the total number of working hours and system days an
node a total of <number of order for this item should be released before it is expected to
hours> working hours and ship.
<number of days> system
days before expected time
of shipment.
Notification Schedule List
Time Enter the time of day when this node can be contacted.
Day check box Click in the boxes for the days of the week to which this
schedule applies.
Notification Period List Displays a cumulative list of existing notification periods.

Modifying a Notification Period

About this task

To modify a notification period:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Node Level Controls. The Ship Node Search window
displays in the work area.
2. Enter the applicable search criteria and choose the Search icon. A list of nodes
displays.
3. Select the applicable node and choose the Details icon. The Node Details
pop-up window displays.
4. To modify a notification period, choose the Notification Period tab.
5. From the table, locate the applicable notification period and choose the Details
icon. The Notification Period Details pop-up window displays.

Chapter 3. Configuring Cross-Application Order Promising Components 41

 6. Enter information into the applicable fields. Refer to Table 15 on page 41 for
field value descriptions.
7. Choose the Save icon.

Deleting a Notification Period

About this task

To delete a notification period:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Node Level Controls. The Ship Node Search window
displays in the work area.
2. Enter the applicable search criteria and choose the Search icon. A list of nodes
displays.
3. Select the applicable node and choose the Details icon. The Node Details
pop-up window displays.
4. To delete the Notification Period from the notification period list, choose the
Notification Period tab.
5. Select the Notification Period from the list and choose the Delete icon to delete
it (or choose the Details icon to see more details about the Notification Period
before deleting it on the Node Details pop-up window).
6. Choose the Save icon.

Specifying Levels of Service

About this task

The tabs in the Current Notification Period window let you set up different levels
of shipping service at a node. For each notification period, use the Regular Orders
tab to set up notification schedules for regular orders and any additional tabs to
set up notification schedules for other levels of service, such as rush orders. See
“Defining Levels of Service” on page 33 for more information.

To specify levels of service:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Node Level Controls. The Ship Node Search window
displays in the work area.
2. Enter the applicable search criteria and choose the Search icon. A list of nodes
displays.
3. Select the applicable node and choose the Details icon. The Node Details
pop-up window displays.
4. Choose the Notification Period tab.
5. From the table, locate the applicable notification period and choose the Details
icon. The Notification Period Details pop-up window displays.
6. Choose the applicable tab for the level of service. You can configure as many
levels of service for a notification period as there are tabs. For example, to
create notification schedules for regular orders, choose the Regular Orders tab;
to create notification schedules for rush orders, choose the tab for rush orders.
7. Enter information into the applicable fields. Refer to Table 15 on page 41 for
field value descriptions.

42 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 8. Choose the Save icon.

Defining Sourcing and Scheduling Rules

You can define the sourcing and scheduling rules for product items, delivery
services, and provided services.

Defining Fulfillment Types

You must associate fulfillment types with sourcing and procurement rules.
Fulfillment types are used to define custom requirements that allow you to
determine sourcing and procurement locations based on parameters that Sterling
Selling and Fulfillment Foundation does not provide logic for, such as, customers
and order type. For example, you want to source or procure orders for a special
promotion from a particular node. You can create a fulfillment type called
Promotion that you can associate with a sourcing or procurement rule that sources
from the node.

The sourcing rules for product sourcing and procurement must have the same
fulfillment type for sourcing setup to work properly.

Creating a Fulfillment Type

About this task

To create a fulfillment type:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Fulfillment Types. The
Fulfillment Types window displays in the work area.
2. Choose the Create New icon. The Fulfillment Types Details pop-up window
displays.
3. In Fulfillment Type, enter the name of the fulfillment type.
4. In Short Description, enter a brief description of the fulfillment type.
5. In Long Description, enter a more detailed description of the fulfillment type.
6. Choose the Save icon.

Modifying a Fulfillment Type

About this task

To modify a fulfillment type:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Fulfillment Types. The
Fulfillment Types window displays in the work area.
2. Select the applicable fulfillment type and choose the Details icon. The
Fulfillment Types Details pop-up window displays.
3. In Short Description, enter a brief description of the fulfillment type.
4. In Long Description, enter a more detailed description of the fulfillment type.
5. Choose the Save icon.

Chapter 3. Configuring Cross-Application Order Promising Components 43

 Deleting a Fulfillment Type
About this task

To delete a fulfillment type:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Fulfillment Types. The
Fulfillment Types window displays in the work area.
2. Select the applicable fulfillment type and choose the Delete icon.

Defining Basic Sourcing Configuration

About this task

You can determine whether or not the organization you are configuring uses
sourcing rules. When an organization only has one or two nodes from which they
source all of their products and services, you may not need to define complex
sourcing configurations. However, when an organization has many nodes and
suppliers with whom they interact, you would want to define sourcing rules to
ensure that the optimal nodes are used to handle shipping and service fulfillment.

In cases when you do not define sourcing rules for an organization but may have
more than one node, the system still uses optimization logic, such as distance to
ship to location, to determine the appropriate node to use.

To configure basic sourcing rules:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Basic Configuration. The
Sourcing Basic Configuration window displays in the work area.
2. Enter information into the applicable fields. Refer to Table 16 for field value
descriptions.
3. Choose the Save icon.

Table 16. Sourcing Basic Configuration Window

Field Description
Default Fulfillment Type to Select the fulfillment type you want to be use by default for
be used when not specified sourcing when no fulfillment type is specified on the order.
on the order For more information about configuring fulfillment types, see
“Defining Fulfillment Types” on page 43.
Products being shipped
Use any of my nodes for Select this option if you do not want to define product item
shipping the product sourcing rules for the organization you are configuring. If you
select this option, the system optimizes product sourcing
based on the node(s) you have defined for the organization.

Important: If an Enterprise inherits sourcing rules from

another organization, they inherit the parent Enterprise's
nodes when they select this option.

44 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 16. Sourcing Basic Configuration Window (continued)
Field Description
Find node based on Select this option if you want to use configured product item
sourcing rule setup sourcing rules with the organization you are configuring. For
more information about configuring product item sourcing
rules, see “Defining Sourcing Rules for Product Items” on
page 61.
Default Distribution Rule to Select the default distribution group you want to use to
be used when no sourcing source product items when the system cannot determine an
rule found appropriate sourcing rule to use for an order. A distribution
group is a defined set of nodes and source organizations.

For more information about configuring distribution groups

for product items, see “Defining Distribution Groups for
Product Items” on page 58.
Products being delivered
Use any node for Select this option if you want the system to select any
delivering the product delivery location that services a given delivery region.
Find nodes based on Select this option if you want to use configured delivery
sourcing rule setup service item sourcing rules with the organization you are
configuring. For more information about configuring delivery
service item sourcing rules, see “Defining Sourcing Rules for
Product Items” on page 61.
Provided Services
Use any node that can Select this option if you want the system to select any
provide the service provided service location that services a given shipping
region.
Find node based on Select this option if you want to use configured provided
sourcing rule setup service item sourcing rules with the organization you are
configuring. For more information about configuring
provided service item sourcing rules, see “Defining Sourcing
Rules for Product Items” on page 61.

Defining Order Sourcing Classifications

An order sourcing classification represents a customizable sourcing criteria used to
determine which ship node to ship a product from, at scheduling time. For more
information about order sourcing classifications, see the Sterling Selling and
Fulfillment Foundation: Product Concepts Guide.

Creating an Order Sourcing Classification

About this task

To create or modify an order sourcing classification:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Order Sourcing Classifications.
The Sourcing Classifications window displays in the work area.
2. Click the Create New icon. The Order Sourcing Classification Details pop-up
window displays.
3. In Order Sourcing Classification, enter the name of the sourcing classification.
4. In Short Description, enter the name of the short description.

Chapter 3. Configuring Cross-Application Order Promising Components 45

 5. In Long Description, enter the name of the long description.
6. Click the Save icon.

Modifying an Order Sourcing Classification

About this task

To modify an order sourcing classification:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Order Sourcing Classifications.
The Sourcing Classifications window displays in the work area.
2. Select the applicable sourcing classification and click the Details icon. The
Order Sourcing Classification Details pop-up window displays.
3. In Short Description, enter the name of the short description.
4. In Long Description, enter the name of the long description.
5. Click the Save icon.

Deleting an Order Sourcing Classification

About this task

To delete an order sourcing classification:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Order Sourcing Classifications.
The Order Sourcing Classifications window displays in the work area.
2. Select the applicable order sourcing classification and click the Delete icon.

Sourcing Region Selection

A region schema represents the complete set of regions defining a given
geography. You can use Sourcing Region Selection to associate preexisting region
schemas for use within sourcing configuration. For more information about
configuring region schemas, see the Sterling Selling and Fulfillment Foundation:
Configuration Guide.

You can associate region schemas with the following:

v Shipped Product Region Schema - You can select a region schema that to be
used when configuring the product specific sourcing rules. The regions within
the selected region schema can then be associated with nodes or groups of nodes
from which product items can be shipped to a destination.
v Delivery Region Schema - You can select a region schema to be used when
configuring delivery service specific sourcing rules. The regions within the
selected region schema can then be associated with nodes or groups of nodes
that provide a given delivery service when a delivery is requested to the specific
region.
v Provided Service Region Schema – You can select a region schema to be used
when configuring provided service specific sourcing rules. The regions within
the selected region schema be associated with nodes or groups of nodes that can
provide a requested service when the service location is within the specific
region.

46 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 You can select the same region schema for product, delivery, and provided service
sourcing configuration or you can select a different region schema for each if you
would like to define a more granular region definition for any of the three.

Defining Sourcing Region Selection

About this task

To define sourcing region selection:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Sourcing Region Selection. The
Region Usage For Sourcing pop-up window displays in the work area.
2. From Schema for Product being shipped, select the region schema you want to
use for product item sourcing.
3. From Schema for Product being delivered, select the region schema you want
to use for delivery service item sourcing.
4. From Schema for Provided Service, select the region schema you want to use
for provided service item sourcing.

Defining Scheduling Rules

Scheduling rules determine shipping, inventory scheduling, and node preferences.
When the Schedule time-triggered transaction schedules inventory, scheduling
rules are used. You can have one scheduling rule for all orders or you can associate
a specific scheduling rule with an order. This allows different scheduling rules to
be used based on your business requirements.

There are three ways to assign a scheduling rule to an order:

v The scheduling rule is passed as part of the order data when creating an order.
v A customer service representative selects a scheduling rule from the Application
Consoles.
v If a scheduling rule is not assigned by other means, Sterling Selling and
Fulfillment Foundation uses the default SYSTEM scheduling rule.

Note: When creating scheduling rules for Enterprises, there must always be one
scheduling rule named SYSTEM to be used as a default throughout the system.

Note: The scheduling rule can be passed as input to APIs that read inventory
(AllocationRuleID), for example FindInventory. If not passed, the system
searches for a scheduling rule named SYSTEM for the calling organization's
primary enterprise. If a scheduling rule with the name SYSTEM is not found, the
SYSTEM rule for the DEFAULT organization is used.

Note: The scheduling algorithm is based only on ship node priority and
geography.

Creating a Scheduling Rule

About this task

To create a scheduling rule:

Chapter 3. Configuring Cross-Application Order Promising Components 47

 Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Scheduling Rules. The
Scheduling Rules screen displays in the work area.
2. Choose the Create New icon. The Scheduling Rule Details screen displays.
3. Enter information into the applicable fields. Refer to Table 17 for field value
descriptions.
4. Choose the Save icon.
Table 17. Scheduling Rule Details Screen
Field Description
Primary Information
Scheduling Rule Enter the name of the scheduling rule.
Scheduling Rule Enter a brief description of the scheduling rule.
Description
Retry Intervals
If Product is Backordered, Enter how many hours after an order has been backordered
retry scheduling after this that the system should try to reprocess the order.
time (Hours) Note: The minimum wait period for retrying to schedule an
order is 30 minutes, even if the value specified is less than
that. For instance, if the wait period is set to 0.2, the business
logic of Sterling Selling and Fulfillment Foundation still treats
it as if it were 0.5.
If scheduling fails for any For products, after this time (Hours) - Enter how many hours
other reason retry after which the Schedule time-triggered transaction should try
scheduling: to schedule a product item order line if the order line is not
ready to schedule when it is initially picked up.

For delivery or provided services, after this time (Hours) -

Enter how many hours after which the Schedule
time-triggered transaction should try to schedule a service
item order line if the order line is not ready to schedule when
it is initially picked up.
Constraints
Ship Complete Check this box to ensure that all product lines in the
promising inquiry request are either completely scheduled or
not scheduled at all. However, lines could be sourced from
different shipping locations.
Line Ship Complete Check this box to ensure that every product line on an
individual line basis is either completely sourced or not
sourced at all. However, lines could be sourced from different
shipping locations.
Note: The difference between this and the Ship Complete
constraint is that this rule does not enforce that all lines of the
request are completely sourced. A particular line can be
sourced while another line of the same request could be
backordered.
Ship from Single Node Check this box to ensure that the request is sourced from a
single node on a single date.

48 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 17. Scheduling Rule Details Screen (continued)
Field Description
Line Ship from Single Node Check this box to ensure that each individual line is sourced
from a single node on the same date.
Note: This rule does not enforce that all lines are shipped
from the same node. A particular line may be completely
shipped from node 1 while another line could be completely
shipped from node 2.
Inventory Controls
Always Select this option to consider using unplanned inventory at
both the inquiring and scheduling stages when other sourcing
options have been exhausted.
Note: In order to use unplanned inventory, the "Use
Unplanned Inventory" flag must be set to "Yes" at the Item
level.
Only During Inquiry Select this option to consider using unplanned inventory only
during the inquiring stage when other sourcing options have
been exhausted.
Note: In order to use unplanned inventory, the "Use
Unplanned Inventory" flag must be set to "Yes" at the Item
level.
Cancel Order for Inventory Check this box if you want the system to cancel an order
Shortage when there is an inventory shortage.

When unchecked, the item is backordered.

Apply On Hand Safety Check this box to apply the on hand safety factor to on hand
Factor To On Hand inventory availability.
Inventory Availability Note: For safety factors to apply, this control must also be
checked for the supply type and node type. For more
information on Safety Factors, refer to the Sterling Selling and
Fulfillment Foundation: Global Inventory Visibility Configuration
Guide.
Apply Future Safety Factor Check this box to apply the future safety factor to future
To Future Inventory inventory availability.
Availability Note: For safety factors to apply, this control must also be
checked for the supply type and node type. For more
information on Safety Factors, refer to the Sterling Selling and
Fulfillment Foundation: Global Inventory Visibility Configuration
Guide.
Lead Times
Maximum no. of days Enter a lead time for orders to be picked up by the Schedule
order can be scheduled agent.
before its ship date

Chapter 3. Configuring Cross-Application Order Promising Components 49

 Table 17. Scheduling Rule Details Screen (continued)
Field Description
Maximum no. of days Enter the number of days after the requested ship date that
order can be an order can be released.
shipped/delivered beyond Note: For tag controlled items, if demands are being matched
its requested date against future inventory (purchase orders), during an existing
supply and demand reallocation, the “Maximum no. of days
order can be shipped/delivered beyond its requested date”
rule is not considered. This may cause an existing order
which was previously scheduled, to be backordered during
release. To avoid this, if possible, set the
ForwardConsumptionDays in the ATP rule equal to the value
defined in the “Maximum no. of days order can be
shipped/delivered beyond its requested date” rule.

For more information, see that note in the "ATP Rules Details
Pop-Up Window" table for the Forward Consumption (Days)
field, in the Sterling Selling and Fulfillment Foundation: Global
Inventory Visibility Configuration Guide.
Maximum no. of days Enter the maximum number of days before the ship date that
order can be scheduled an order can be scheduled.
before its ship date
Maximum no. of days to Enter the maximum number of days through which you want
search service availability to look up service and slot availability.
for
Reservations
Allow Reservation During Check this box to allow the items to be reserved while
Scheduling scheduling.
Reserve Bundle Out of Check this box to reserve components that are out of ratio for
Ratio a bundle.
Ignore Fill Quantity (Ship Check this box to allow the reservation of partial quantity of
Complete) a line that has a ship complete constraint or to reserve the
quantity that is less than the fill quantity.
Priority
Consider distance between Check this box to enable the geography-based distance
ship-to and ship-from calculations for choosing a ship node.
locations for prioritization
Important: If you select this field, ensure Optimize On is set
to Priority.
Weightage given of Enter the weighting factor for distance. Once the distance
distance between the ship-location and the ship node address is
calculated using longitude and latitude, it is multiplied by
this weighting factor.

Enter any fractional number greater than, or equal to, zero. A

value of 0 nullifies any distance considerations in the
calculation.

50 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 17. Scheduling Rule Details Screen (continued)
Field Description
Weightage given to Node Enter the weighting factor for node priority. The ship node
priority specified in the distribution group is multiplied by
this weighting factor.

Enter any fractional number greater than, or equal to, zero. A

value of 0 nullifies any node priority considerations in the
calculation.

Important: For this weighting factor to be applied,

distribution groups must be used to determine the set of
possible ship nodes from which a product can be shipped.
Optimize On
Date Select this option for inventory scheduling to be optimized by
date.
Priority Select this option for inventory scheduling to be optimized by
node priority.
Cost, Number of Shipments Select this option for inventory scheduling to be optimized by
number of shipments.
Note: When landed cost optimization is enabled, it takes
precedence over optimization by the number of shipments.
When landed cost optimization is disabled, optimization by
the number of shipments is used. For more information, refer
to “Configuring Landed Cost Optimization” on page 53.
Additional Optimization Criteria
When Optimizing On Cost, Check this box to combine the optimization based on both
Combine Shipments In cost and specified number of days.
<number of days> Day
Intervals. This May Avoid In this case, enter the number of days up to which the
Shipment Delay, But May optimization should be considered.
Lead To Extra Cost
Delay Shipment Against Check this box to delay shipments against the onhand
Current Inventory To Be inventory to be consolidated with the future inventory.
Consolidated With
Shipments Against Future This option can be chosen only when the "When Optimizing
Inventory. On Cost, Combine Shipments" box is checked.

When this option is selected, the onhand inventory is kept on

hold for the specified number of days to combine with
shipments that include future inventory.

If the future inventory is not received on or before the

specified number of days, the onhand inventory is shipped
individually.
Delay Procurements To Be Check this box to delay shipments when the inventory
Consolidated With through transfers are available.
Shipments Against Future
Inventory. This option can be chosen only when the "When Optimizing
On Cost, Combine Shipments" is checked.

When this option is selected, the inventory through transfers

is kept on hold for the specified number of days to combine
with shipments that include future inventory.

If the future inventory is not received on or before the

specified days, the inventory is shipped individually.

Chapter 3. Configuring Cross-Application Order Promising Components 51

 Table 17. Scheduling Rule Details Screen (continued)
Field Description
Backward Compatibility Controls
Assume Infinite Inventory Check this box if you want the system to consider any
Availability Beyond Lead inventory beyond the lead time + processing time frame to be
Time infinite.
Note: This flag should only be used for backward
compatibility purposes. New customers should not use this
flag.
Other Rules
Ignore Merging To Check this box if you want to ignore the merging of
Minimize Shipment shipments at the scheduling level.

When this option is selected, the "Minimize Number Of

Shipments To Customer Through Transfers Between Shipping
Nodes" option is overridden at the enterprise level in
Forwarding/Transfer Rules.

For more information about forwarding and transfer rules,

see “Forwarding/Transfer Rules” on page 57.
Ignore Use Of Landed Cost Check this box if you want to ignore the use of landed cost
For Optimization optimization at the scheduling level.

When this option is selected, the "Use landed Cost" option is

overridden at the enterprise level in Landed Cost
Optimization.

For more information about configuring the landed cost

parameters, see “Configuring Landed Cost Optimization” on
page 53.

Modifying a Scheduling Rule

About this task

To modify a scheduling rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Scheduling Rules. The
Scheduling Rules screen displays in the work area.
2. Select the applicable scheduling rule and choose the Details icon. The
Scheduling Rule Details screen displays.
3. Modify information into the applicable fields. Refer to Table 17 on page 48 for
field value descriptions.
4. Choose the Save icon.

Deleting a Scheduling Rule

About this task

To delete a scheduling rule:

52 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Scheduling Rules. The
Scheduling Rules screen displays in the work area.
2. Select the applicable scheduling rule and choose the Delete icon.

Configuring Landed Cost Optimization

About this task

Sterling Selling and Fulfillment Foundation enables you to specify landed cost
parameters to be considered for evaluation during order promising, if the "Cost,
Number of Shipments" optimization type has been selected in your scheduling
rule. For more information about optimization types, see “Defining Scheduling
Rules” on page 47, or the Sterling Selling and Fulfillment Foundation: Product Concepts
Guide.

Promising selects the sourcing option with the least landed cost. Landed cost
comprises item cost, handling cost, and transportation cost, which can be
configured separately.

When landed cost optimization is enabled, it takes precedence over optimization

by the number of shipments. When landed cost optimization is disabled,
optimization by the number of shipments is used.

To configure landed cost optimization:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Landed Cost. The Landed Cost
window displays in the work area.
2. Enter information into the applicable fields. Refer to Table 18 for field value
descriptions.
3. Choose the Save icon.
Table 18. Landed Cost Window
Field Description
Use Landed Cost Check this box to enable the use of landed cost optimization.
Uncheck this box to disable all options in this window.
Use Item Cost Check this box to indicate that item cost should be used
when computing landed cost.
Use Transportation Cost Check this box to indicate that transportation cost criteria
should be used when computing landed cost.
Transfers
Transfer Cost Factor Select the currency used for the transfer cost factor from the
Currency drop-down list.
Transfer Cost Factor for Enter the transfer cost factor and select the correct UOMs for
Internal Transfers internal transfers.

The internal transfer cost factor is used to calculate transfer

cost when there is a transfer schedule between two nodes.
Note: The value of the Transfer Cost Factor Per Unit
specified in the Transfer Schedule pop-up window overrides
the value of the Transfer Cost Factor for the internal transfers.

Chapter 3. Configuring Cross-Application Order Promising Components 53

 Table 18. Landed Cost Window (continued)
Field Description
Transfer Cost Factor for Enter the transfer cost factor and select the correct UOMs for
External Transfers external transfers.

The external transfer cost factor is used when a transfer

schedule does not exist between two nodes.
Note: The value of the Transfer Cost Factor Per Unit
specified in the Transfer Schedule pop-up window overrides
the value of the Transfer Cost Factor for the internal transfers.
Last Leg Transportation
Outbound Constraints Choose the Details icon to open the Outbound Constraints
window, where you can configure outbound constraints and
define routing guides.

For more information about outbound constraints, see Section

5.4, Defining Outbound Constraints.
For Transportation Cost Enter a volume and volume UOM to be used when
Based On Number Of transportation cost is based on the number of cartons.
Cartons, Assume Maximum
Volume Per Carton To Be
Use Handling Cost Check this box to indicate that handling cost should be used
when computing landed cost. Unchecking this box disables
the Enterprise Node Type Rules inner panel.

For more information about defining enterprise node type

rules, see “Defining Enterprise Node Type Rules” on page 55.
Convert Node Attributes Check this box to use the attributes of the node to be
Into Cost converted into cost.
Node Cost Factor Currency Choose the currency for computing the cost of node attributes
from the drop-down list.

To create a new currency, choose the Create New icon and

enter information in the applicable fields. For more
information about defining the currency for the node
attributes cost factor, see Currency Details.
Node Priority Cost Factor Enter the node priority cost factor.

This factor applies to the distance of the node to the customer

to determine the cost of shipping from a node. During
scheduling optimization, when the system compares two
possible nodes to determine the best one to use during
costing, the cost will be based on the node that has the closest
proximity to the customer.

You can enter values to this field only when the "Convert
Node Attributes Into Cost" check box is enabled. When this
check box is enabled, Sterling Selling and Fulfillment
Foundation calculates the shipping cost from the node, based
on the factor entered in this field. For example, if the node
priority is based on geography, and if you have a node that is
300 miles away and a factor of $0.20, the system calculates
the shipping cost for this node to be $60.00, assuming USD.

54 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 18. Landed Cost Window (continued)
Field Description
Node Consumption Enter the node consumption percentage cost factor.
Percentage Cost Factor
This factor applies to the consumed capacity percentage to
determine the cost of shipping from a node. During
scheduling optimization, when the system compares two
possible nodes to determine the best one to use during
costing, the cost will be based on the lowest consumption
factor.

You can enter values to this field only when the "Convert
Node Attributes Into Cost" check box is enabled.

When this check box is enabled, Sterling Selling and

Fulfillment Foundation calculates the node's available
capacity based on the factor entered in this field. For
example, if you have 30% available capacity and a factor of 2,
the system calculates the cost for this node to be $60.00,
assuming USD.

For additional information about adjusting node capacity,

refer to the Business Center: Inventory Management Guide.

Currency Details
You can define the currency for the node priority cost factor in the currency details
pop-up window.
Table 19. Currency Details
Field Description
Currency Enter the currency in which you want to define the cost
factor.
Description Enter a description for the currency.
Prefix Symbol Enter the prefix symbol for the currency defined.
Postfix Symbol Enter the postfix symbol for the currency defined.
Euro Member Check this box if you have defined the currency as a Euro
currency member.
Expiration Date Enter the date on which the Euro membership expires.

Note: The Create New (currency) icon is available only at the hub level.

Defining Enterprise Node Type Rules

About this task

You can define Enterprise Node Type Rules to specify the handling costs of various
node types at the Enterprise level.

To create an Enterprise node type rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Landed Cost. The Landed Cost
window displays in the work area.

Chapter 3. Configuring Cross-Application Order Promising Components 55

 2. In the Enterprise Node Type Rules panel, choose the Create New icon. The
Enterprise Node Type Rule window displays.

Note: The "Use Handling Cost" checkbox must be selected to enable Enterprise
Node Type Rules.
3. Enter information into the applicable fields. Refer to Table 20 for field value
descriptions.
4. Choose the Save icon.
Table 20. Enterprise Node Type Rule Pop-up Window
Field Description
Node Type Select the node type from the drop-down list.
Currency Select the currency to use for this rule from the drop-down
list.
Inbound Handling Cost
Per Shipment Enter the handling cost for each shipment, in the currency
selected above.
Per Line Enter the handling cost for each line, in the currency selected
above.
Per Unit Choose this option to enter the handling cost for each unit.

Choosing this option disables the "Per Unit Weight" option.

Per Unit Weight Choose this option to enter the handling cost for each unit
weight.

Choosing this option disables the "Per Unit" option.

Outbound Handling Cost
Per Shipment Enter the handling cost for each shipment, in the currency
selected above.
Per Line Enter the handling cost for each line, in the currency selected
above.
Per Unit Choose this option to enter the handling cost for each unit.

Choosing this option disables the "Per Unit Weight" option.

Per Unit Weight Choose this option to enter the handling cost for each unit
weight.

Choosing this option disables the "Per Unit" option.

Modifying an Enterprise Node Type Rule

About this task

To modify an Enterprise node type rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Landed Cost. The Landed Cost
window displays in the work area.
2. In the Enterprise Node Type Rules panel, select the applicable rule and choose
the Details icon.. The Enterprise Node Type Rule window displays.

56 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Note: The "Use Handling Cost" checkbox must be selected to enable Enterprise
Node Type Rules.
3. Enter information into the applicable fields. Refer to Table 20 on page 56 for
field value descriptions.
4. Choose the Save icon.

Deleting an Enterprise Node Type Rule

About this task

To delete an Enterprise node type rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Landed Cost. The Landed Cost
window displays in the work area.
2. In the Enterprise Node Type Rules panel, select the applicable rule and choose
the Delete icon.

Forwarding/Transfer Rules
Forwarding rules enable you to minimize transportation costs by allowing you to
specify a default carrier service to move shipments from one node to another
before shipping to a customer, otherwise known as zone skipping.

When evaluating options, Sterling Selling and Fulfillment Foundation identifies

ship nodes that can fulfill the request, then utilizes routing guides to determine the
best possible drop location and carrier that meets any item constraints.

Forwarding is not applied in the following scenarios:

v If forwarding is not enabled at the Enterprise level.
v If forwarding is not enabled at the line level.
v If forwarding is not enabled at the item level.
v If a shipment is being delivered.
v If a shipment has shipping and receiving nodes with a transfer schedule
between them.
v If the shipment is not a final shipment to the customer (procurements cannot be
forwarded).
v If a carrier service code is not specified at the line or header level.
v If the document type classification is not "Sales Order" or "Other".

Transfer rules enable you to minimize the number of shipments to a customer by

determining a merge node, where shipments can be consolidated before shipping
to a customer.

Defining Forwarding/Transfer Rules

About this task

To define forwarding/transfer rules:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Forwarding/Transfer Rules. The
Forwarding/Transfer Rules window displays in the work area.

Chapter 3. Configuring Cross-Application Order Promising Components 57

 2. Enter information into the applicable fields. Refer to Table 21 for field value
descriptions.
3. Choose the Save icon.
Table 21. Forwarding/Transfer Rules Window
Field Description
Forwarding Rules
Use Forwarding Select this checkbox if you want use forwarding.

Deselecting this checkbox disables all other forwarding

options.
Default Carrier Service For Select a default carrier service to use during forwarding from
Forwarding the drop-down list.
For Transportation Considerations Based On Number Of Cartons:
Assume Average Volume Enter a volume and volume UOM to be used as the assumed
Per Carton To Be average volume per carton.
Outbound Constraints Choosing the Details icon opens the Outbound Constraints
window, where you can configure outbound constraints and
define routing guides.

For more information about outbound constraints, see Section

5.4, Defining Outbound Constraints.
Transfer Rules
Minimize Number Of Select this checkbox to minimize the number of shipments
Shipments To Consider Sterling Selling and Fulfillment Foundation considers through
Through Transfers Between transfers between shipping nodes.
Shipping Nodes
Consider Transfers Only Select a relationship type from the drop-down list. Transfers
When Following are considered only when this relationship exists between two
Relationship Exists Between shipping nodes.
Two Shipping Nodes
This field is disabled if the "Minimize Number of Shipments
To Consider Through Transfers Between Shipping Nodes"
checkbox is not selected.
Multi-Stop Transfer Rules
Maximum Number Of Enter the maximum number of in-between nodes Sterling
In-Between Nodes To Be Selling and Fulfillment Foundation considers when
Considered When determining multi-stop transfer paths between nodes. If the
Determining Multi-Stop maximum number of in-between nodes is not defined, it will
Transfer Paths Between be treated as zero (0).
Nodes
Consider Multi-Stop Select a relationship type from the drop-down list. Multi-stop
Transfers Only When transfers are considered only when this relationship exists
Following Relationship between two shipping nodes.
Exists Between Two
Shipping Nodes

Defining Distribution Groups for Product Items

You can create a set of nodes/external organizations that can be used when
determining sourcing. You can define distribution groups that establish the ship
node determination process based on priority.

58 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
For backward compatibility purposes, you can also create rules for individual
items at a source node or for the entire source node.

Product Items: Creating a Distribution Group

About this task

To create a distribution group:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Product Being Shipped >
Distribution Rules. The Distribution Rules window displays in the work area.
2. Choose the Create New icon. The Distribution Group Detail window displays.
3. In Distribution Group, enter the name of the distribution rule.
4. In Description, enter a brief description of the distribution rule.
5. Choose the Save icon.

Product Items: Adding Nodes/External Organizations to a Distribution Group:

About this task

To add a node/external organization to a distribution group:

Procedure
1. In the Distribution Group Details window, choose the Distribution Detail tab.
2. Choose the Create New icon. The Distribution Details pop-up window
displays.
3. Enter information into the applicable fields. Refer to Table 22 for field value
descriptions.
4. Choose the Save icon.
Table 22. Distribution Details Window
Field Description
Source
Source Ship Node Select Source Ship Node and select the applicable node if you
want to add a node within your organization to the
distribution group.
Source Organization Select Source Organization and select the applicable
organization if you want to add an external organization to
the distribution group.
Priority Enter the node/external organization's priority within the
distribution group.
Note: Priority is not unique to a distribution group, therefore
more than one distribution group can have the same priority.

Results

If you adding nodes or external organizations to a distribution group, do not use

the advanced tab. Use sourcing rules instead. For more information about
configuring sourcing rules, see Section 3.5, Defining Sourcing and Scheduling
Rules.

Product Items: Modifying a Distribution Group's Node/External Organization:

Chapter 3. Configuring Cross-Application Order Promising Components 59

 About this task

To modify a distribution group's node/external organization:

Procedure
1. In the Distribution Group Details window, choose the Distribution Detail tab.
2. Select the applicable distribution detail and choose the Details icon. The
Distribution Details pop-up window displays.
3. Enter information into the applicable fields. Refer to Table 22 on page 59 for
field value descriptions.
4. Choose the Save icon.

Product Items: Deleting a Distribution Group's Node/External Organization:

About this task

To delete a distribution group's node/external organization:

Procedure
1. In the Distribution Group Details window, choose the Distribution Detail tab.
2. Select the applicable distribution detail and choose the Delete icon.

Product Items: Adding Advanced Distribution Details to a

Distribution Group (For Backward Compatibility Only)
About this task

You can add specific details, such as sourcing information, and assign them a date
range through which they are effective.

Note: IBM strongly recommends the use of sourcing rules instead of advanced
distribution groups. This feature is provided for backward compatibility purposes
only.

Note: If setting up advanced distribution rules, do not use the base distribution
rules under the distribution detail tab.

To add advanced distribution details to a distribution rule:

Procedure
1. In the Distribution Group Details window, choose the Advanced tab.
2. From the Distribution table, choose the Create New icon. The Distribution
Details pop-up window displays.
3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.
4. Choose the Save icon.
Table 23. Advanced Distribution Details window
Field Description
All Items Select this option to apply the distribution rule to all of the
items in the node you are setting the rule up for.
Apply To Specific Item At Select this option to apply the distribution rule to a specific
This Source item in the node or organization you are setting the rule up
for.
Primary Info

60 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 23. Advanced Distribution Details window (continued)
Field Description
Item ID If you selected Apply To Specific Item At This Source, enter
the item ID for which you are creating the Distribution Rule.
Active Check Active if the distribution rules are active.
Item Name at Node If you selected Apply To Specific Item At This Source, enter
the node's name for the item. The distribution record created
for the inventory consolidator displays in the Inventory
Console.
Priority Enter a priority number for the node for this item and
inventory scheduling, with 0 being the highest priority.
Effective Start Date The date the distribution details take effect.
Effective End Date The date after which the distribution details are no longer
applied.
Source
Source Ship Node Choose Source Ship Node and select the applicable node if
you are setting up the distribution details to be sourced from
a particular ship node.
Source Organization Choose Source Organization and select the applicable
organization if you are setting up the distribution details to
be sourced from a particular organization.

Product Items: Deleting Advanced Distribution Details

About this task

To delete a advanced distribution details:

Procedure
1. In the Distribution Group Details window, choose the Advanced tab.
2. From the Distribution table, select the applicable distribution details and choose
the Delete icon.

Product Items: Deleting a Distribution Group

About this task

To delete a distribution group:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose Cross Application >
Order Promising > Sourcing And Scheduling > Product Being Shipped >
Distribution Rules. The Distribution Group window displays in the work area.
3. Select the applicable distribution group and choose the Delete icon.

Defining Sourcing Rules for Product Items

You can define sourcing rules to control what node, external organization, or group
of nodes should be considered for sourcing a product based on the following
parameters (in order of priority):
v Fulfillment Type

Chapter 3. Configuring Cross-Application Order Promising Components 61

 v Order Sourcing Classification
v Seller organization
v Item ID
v Primary Item Classification
v Secondary Item Classification
v Tertiary Item Classification
v Geographical region of the ship to location

When a node is passed on an order line, the system uses that node regardless of
the sourcing rules you may have configured.

Creating a Product Item Sourcing Rule

About this task

To create a sourcing rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Product Being Shipped >
Sourcing Rules. The Product Sourcing Rules Search window displays in the
work area.
2. Choose the Create New icon. The Sourcing Rule for Product Being Shipped
window displays.
3. Enter information into the applicable fields. Refer to Table 24 for field value
descriptions.
4. Choose the Save icon.
Table 24. Sourcing Rule for Product Being Shipped Window
Field Description
Fulfillment Type Select the applicable fulfillment type to associate with the
sourcing rule. For more information about configuring
fulfillment types, see “Defining Fulfillment Types” on page
43.
Order Sourcing Select the applicable order sourcing classification if you want
Classification to associate this sourcing rule with a particular order sourcing
classification. For more information about configuring order
sourcing classifications, see “Defining Order Sourcing
Classifications” on page 45.
When Seller organization is
This Organization Select this option and select the applicable Seller organization
if you want to associate this sourcing rule with a particular
Seller.
All Sellers Select All Sellers if this sourcing rule can be associated with
any Seller organization.
And Product characteristics are
Item ID Select Item ID and enter the applicable item if you want to
associate the sourcing rule with a particular item.
Item Classification Select Item Classification and enter the applicable
classification if you want to associate the sourcing rule with a
particular classification.

62 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 24. Sourcing Rule for Product Being Shipped Window (continued)
Field Description
All Items Select Apply To All Items At This Source if you want to
associate the sourcing rule with all of the items maintained at
the source node.
And Product is being shipped to
This Region Select Region and enter the applicable region if you want this
sourcing rule to be used when products are shipped to a
specific region.

Important: The region you identify must belong to the region

schema associated with product item sourcing for the
organization you are working with. For more information
about setting an organization's region schema for product
items, see “Sourcing Region Selection” on page 46.
This Node Select Node and select the applicable node if you want this
sourcing rule to be used when products are shipped to this
node.
Nodes of Type Select Nodes of Type and select the applicable node types
available if you want this sourcing rule to be used when
products are shipped to a specific node type.
Any Address Select Any Address and if this sourcing rule can be used
when products are shipped to any node.
Sourced From List

The system tries to source the product from the node/distribution group with the highest
sequence (lowest number). If the sourcing template contains a distribution group or a set of
nodes, the final node selection is optimized based on the parameters configured in your
scheduling rule associated with a given order. For more information about scheduling
rules, see “Defining Scheduling Rules” on page 47.

If there is no product availability for a node/distribution group specified in a given

sequence, the system tries to source from the next node/distribution group in the
sequence.
Sequence No The sequence priority of the sourcing template.
Sourcing Template A list of the node/distribution group sequences used for
sourcing. The sequence is determined by priority. For more
information about sourcing templates, see “Defining Sourcing
Template Details” on page 74.

Modifying a Product Item Sourcing Rule

About this task

To modify a sourcing rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Product Being Shipped >
Sourcing Rules. The Sourcing Rule for Product Being Shipped Search window
displays in the work area.
2. Select the applicable sourcing rule and choose the Details icon. The Product
Sourcing Rules Search window displays.
3. Enter information into the applicable fields. Refer to Table 24 on page 62 for
field value descriptions.

Chapter 3. Configuring Cross-Application Order Promising Components 63

 4. Choose the Save icon.

Deleting a Product Item Sourcing Rule

About this task

To delete a sourcing rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Product Being Shipped >
Sourcing Rules. The Product Sourcing Rules Search window displays in the
work area.
2. Select the applicable sourcing rule and choose the Delete icon.

Defining Sourcing Rules for Delivery Service Items

You can define sourcing rules to control what node should be considered for
sourcing a delivery service based on the fulfillment type, order sourcing
classification, delivery region, or deliver to node.

When a node is passed on an order line, the system uses that node regardless of
the sourcing rules you may have configured.

Creating a Delivery Service Item Sourcing Rule

About this task

To create a sourcing rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Product Being Delivered >
Sourcing Rules. The Delivery Service Sourcing Rules Search window displays in
the work area.
2. Choose the Create New icon. The Sourcing Rule for Product Being Delivered
window displays.
3. Enter information into the applicable fields. Refer to Table 25 for field value
descriptions.
4. Choose the Save icon.
Table 25. Sourcing Rule for Product Being Delivered Window
Field Description
Fulfillment Type Select the applicable fulfillment type to associate with the
sourcing rule. For more information about configuring
fulfillment types, see “Defining Fulfillment Types” on page
43.
Order Sourcing Select the applicable order sourcing classification if you want
Classification to associate this sourcing rule with a particular order sourcing
classification. For more information about configuring order
sourcing classifications, see “Defining Order Sourcing
Classifications” on page 45.
When Seller organization is
This Organization Select this option and select the applicable Seller organization
if you want to associate this sourcing rule with a particular
Seller.

64 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 25. Sourcing Rule for Product Being Delivered Window (continued)
Field Description
All Sellers Select All Sellers if this sourcing rule can be associated with
any Seller organization.
And Product is being delivered to
This Region Select This Region and enter the applicable region if you
want the sourcing rule to be used when deliveries are made
to a specific region.

Important: The region you identify must belong to the region

schema associated with delivery service item sourcing for the
organization you are working with. For more information
about setting an organization's region schema for delivery
service items, see “Sourcing Region Selection” on page 46.
This Node Select This Node and select the applicable node if you want
the sourcing rule to be used when deliveries are made to a
specific node.
Any Address Select Any Address if this sourcing rule can be used when
deliveries are made to any node
Use the following Node
Node Select the node the delivery service is sourced from.
Note: Delivery service items can only be sourced from one
node per sourcing rule.
Procure/Transfer to this Check this box if the node handles transfer orders and/or
Node when inventory is procurement purchase orders. For more information about
not available. transfer orders and procurement purchase orders, see
“Defining a Node’s Relationships” on page 37 and “Defining
Procurement Rules” on page 71.
Sourced From List

The system tries to source the product from the node/distribution group with the highest
sequence (lowest number). If the sourcing template contains a distribution group or a set of
nodes, the final node selection is optimized based on the parameters configured in your
scheduling rule associated with a given order. For more information about scheduling
rules, see “Defining Scheduling Rules” on page 47.

If there is no product availability for a node/distribution group specified in a given

sequence, the system tries to source from the next node/distribution group in the
sequence.
Sequence No The sequence priority of the sourcing template.
Sourcing Template A list of the node/distribution group sequences used for
sourcing. The sequence is determined by priority. For more
information about sourcing templates, see “Defining Sourcing
Template Details” on page 74.

Modifying a Delivery Service Sourcing Rule

About this task

To modify a sourcing rule:

Chapter 3. Configuring Cross-Application Order Promising Components 65

 Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Product Being Delivered >
Sourcing Rules. The Delivery Service Sourcing Rules Search window displays in
the work area.
2. Select the applicable sourcing rule and choose the Details icon. The Sourcing
Rule for Product Being Delivered window displays.
3. Enter information into the applicable fields. Refer to Table 25 on page 64 for
field value descriptions.
4. Choose the Save icon.

Deleting a Delivery Service Sourcing Rule

About this task

To delete a sourcing rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Product Being Delivered >
Sourcing Rules. The Delivery Service Sourcing Rules Search window displays in
the work area.
2. Select the applicable sourcing rule and choose the Delete icon.

Defining Distribution Groups for Delivery Service Items

You can create a set of nodes/external organizations that can be used when
determining sourcing. You can define distribution groups that establish the ship
node determination process based on priority.

You can use the Distribution Rules branch for:

v Creating a Distribution Group
v Deleting a Distribution Group

Delivery Service Items: Creating a Distribution Group

To create a distribution group:
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Product Being Delivered >
Distribution Group. The Delivery Service Distribution Groups window displays
in the work area.
2. Choose the Create New icon. The Distribution Group Details window displays.
3. In Distribution Group, enter the name of the distribution rule.
4. In Description, enter a brief description of the distribution rule.
5. Choose the Save icon.

You can use the Distribution Group Details window for:

v Adding Nodes/External Organizations to a Distribution Group
v Modifying a Distribution Group's Node/External Organization
v Deleting a Distribution Group's Node/External Organization

Delivery Service Items: Adding Nodes/External Organizations to a Distribution

Group: To add a node/external organization to a distribution group:
1. In the Distribution Group Details window, choose the Distribution Detail tab.

66 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 2. Choose the Create New icon. The Distribution Details pop-up window
displays.
3. Enter information into the applicable fields. Refer to Table 26 for field value
descriptions.
4. Choose the Save icon.
Table 26. Distribution Details Window
Field Description
Source
Source Ship Node Select Source Ship Node and select the applicable node if you
want to add a node within your organization to the distribution
group.
Priority Enter the node/external organization's priority within the
distribution group.

Delivery Service Items: Modifying a Distribution Group's Node/External

Organization: To modify a distribution group's node/external organization:
1. In the Distribution Group Details window, choose the Distribution Detail tab.
2. Select the applicable distribution detail and choose the Details icon. The
Distribution Details pop-up window displays.
3. Enter information into the applicable fields. Refer to Table 26 for field value
descriptions.
4. Choose the Save icon.

Delivery Service Items: Deleting a Distribution Group's Node/External

Organization: To delete a distribution group's node/external organization:
1. In the Distribution Group Details window, choose the Distribution Detail tab.
2. Select the applicable distribution detail and choose the Delete icon.

Delivery Service Items: Deleting a Distribution Group

To delete a distribution group:
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Product Being Delivered >
Distribution Group. The Delivery Service Distribution Groups window displays
in the work area.
2. Select the applicable distribution group and choose the Delete icon.

Defining Distribution Groups for Provided Service Items

You can create a set of nodes/external organizations that can be used when
determining sourcing. You can define distribution groups that establish the ship
node determination process based on priority.

Provided Service Items: Creating a Distribution Group

About this task

To create a distribution group:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Provided Services >
Distribution Rules. The Distribution Rules window displays in the work area.

Chapter 3. Configuring Cross-Application Order Promising Components 67

 2. Choose the Create New icon. The Distribution Group Detail window displays.
3. In Distribution Group, enter the name of the distribution rule.
4. In Description, enter a brief description of the distribution rule.
5. Choose the Save icon.

Provided Service Items: Adding Nodes/External Organizations to a Distribution

Group:
About this task

To add a node/external organization to a distribution group:

Procedure
1. In the Distribution Group Details window, choose the Distribution Detail tab.
2. Choose the Create New icon. The Distribution Details pop-up window
displays.
3. Enter information into the applicable fields. Refer to Table 27 for field value
descriptions.
4. Choose the Save icon.
Table 27. Distribution Details Window
Field Description
Source
Source Ship Node Select Source Ship Node and select the applicable node if you
want to add a node within your organization to the
distribution group.
Source Organization Select Source Organization and select the applicable
organization if you want to add an external organization to
the distribution group.
Priority Enter the node/external organization's priority within the
distribution group.

Provided Service Items: Modifying a Distribution Group's Node/External

Organization:
About this task

To modify a distribution group's node/external organization:

Procedure
1. In the Distribution Group Details window, choose the Distribution Detail tab.
2. Select the applicable distribution detail and choose the Details icon. The
Distribution Details pop-up window displays.
3. Enter information into the applicable fields. Refer to Table 27 for field value
descriptions.
4. Choose the Save icon.

Provided Service Items: Deleting a Distribution Group's Node/External

Organization:
About this task

To delete a distribution group's node/external organization:

68 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Procedure
1. In the Distribution Group Details window, choose the Distribution Detail tab.
2. Select the applicable distribution detail and choose the Delete icon.

Provided Service Items: Deleting a Distribution Group

About this task

To delete a distribution group:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Provided Services >
Distribution Rules. The Distribution Group window displays in the work area.
2. Select the applicable distribution group and choose the Delete icon.

Defining Sourcing Rules for Provided Service Items

You can define sourcing rules to control what node, external organization, or group
of nodes should be considered for sourcing provided service items based on the
following parameters:
v Fulfillment type
v Order sourcing classification
v Seller organization
v Item ID
v Geographical region of the location where the service is to be provided
v Node where the service is to be provided

When a node is passed on an order line, the system uses that node regardless of
the sourcing rules you may have configured.

Creating a Provided Service Item Sourcing Rule

About this task

To create a sourcing rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Provided Services > Sourcing
Rules. The Provided Service Sourcing Rules Search window displays in the
work area.
2. Choose the Create New icon. The Sourcing Rule for Provided Service window
displays.
3. Enter information into the applicable fields. Refer to Table 28 for field value
descriptions.
4. Choose the Save icon.
Table 28. Sourcing Rule for Provided Service
Field Description
Fulfillment Type Select the applicable fulfillment type to associate with the
sourcing rule. For more information about configuring
fulfillment types, see “Defining Fulfillment Types” on page
43.

Chapter 3. Configuring Cross-Application Order Promising Components 69

 Table 28. Sourcing Rule for Provided Service (continued)
Field Description
Order Sourcing Select the applicable order sourcing classification if you want
Classification to associate this sourcing rule with a particular order sourcing
classification. For more information about configuring order
sourcing classifications, see “Defining Order Sourcing
Classifications” on page 45.
When Seller organization is
This Organization Choose This Organization and select the applicable Seller
organization if you want to associate this sourcing rule with a
particular Seller.
All Sellers Select All Sellers if this sourcing rule can be associated with
any Seller organization.
And Product characteristics are
Item ID Enter the provided service item you want to associate the
sourcing rule with.
And Service Location Is
This Region Select This Region and enter the applicable region if you
want the sourcing rule to be used when a service request is to
be provided within a specific region.

Important: The region you identify must belong to the region

schema associated with provided service item sourcing for
the organization you are working with. For more information
about setting an organization's region schema for provided
service items, see “Sourcing Region Selection” on page 46.
This Node Select This Node and select the applicable node if you want
the sourcing rule to be used when a service request is to be
provided to a specific node.
Any Address Select Any Address if the sourcing rule can be used when a
service request is to be provided for any node.
Sourced From List

The system tries to source the product from the node/distribution group with the highest
sequence (lowest number). If the sourcing template contains a distribution group or a set of
nodes, the final node selection is optimized based on the parameters configured in your
scheduling rule associated with a given order. For more information about scheduling
rules, see “Defining Scheduling Rules” on page 47.

If there is no product availability for a node/distribution group specified in a given

sequence, the system tries to source from the next node/distribution group in the
sequence.
Sequence No The sequence priority of the sourcing template.
Sourcing Template A list of the node/distribution group sequences used for
sourcing. The sequence is determined by priority. For more
information about sourcing templates, see “Defining Sourcing
Template Details” on page 74.

Modifying a Provided Service Sourcing Rule

About this task

To modify a sourcing rule:

70 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Provided Services > Sourcing
Rules. The Provided Service Sourcing Rules Search window displays in the
work area.
2. Select the applicable sourcing rule and choose the Details icon. The Sourcing
Rule for Provided Service window displays.
3. Enter information into the applicable fields. Refer to Table 28 on page 69 for
field value descriptions.
4. Choose the Save icon.

Deleting a Provided Service Sourcing Rule

About this task

To delete a sourcing rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Provided Services > Sourcing
Rules. The Provided Service Sourcing Rules Search window displays in the
work area.
2. Select the applicable sourcing rule and choose the Delete icon.

Defining Procurement Rules

You can define the nodes that handle procurement transfer and purchase orders for
a specified item or item classification. A chained order is an order that is linked to
a parent order in which the lifecycle of one effects the other.

A transfer order is a type of chained order that is created when a node that
belongs to the organization you are configuring needs to replenish their stock from
another node within the organization to fulfill an order. For information about
configuring transfer schedules, see “Defining a Node’s Relationships” on page 37.

A procurement purchase order is a type of chained order that is created when a

node that belongs to the organization you are configuring needs to replenish their
stock from another node that belongs to a different legal entity organization to
fulfill an order.

Creating a Sourcing Rule for Procurement

About this task

To create product procurement sourcing rules:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Procurement > Sourcing Rules.
The Procurement - Sourcing Rule Search window displays in the work area.
2. Choose the Create New icon. The Sourcing Rules for Procurement window
displays.
3. Enter information into the applicable fields. Refer to Table 29 on page 72 for
field

Chapter 3. Configuring Cross-Application Order Promising Components 71

 Table 29. Sourcing Rules for Procurement Window
Field Description
Fulfillment Type Select the applicable fulfillment type to associate with the
product procurement rule. For more information about
configuring fulfillment types, see “Defining Fulfillment
Types” on page 43.
Order Sourcing Select the applicable order sourcing classification if you want
Classification to associate this sourcing rule with a particular order sourcing
classification. For more information about configuring order
sourcing classifications, see “Defining Order Sourcing
Classifications” on page 45.
And Product characteristics are
Item ID Select Item ID and enter the item you want the node to be
able to procure.
All Items Select All Items if you want the node to be able to procure
any item.
And Procuring To
This Node Select Node and select the applicable node if you want this
sourcing rule to be used when products are shipped to this
node.
The Nodes of Type Select Nodes of Type and select the applicable node types
available if you want this sourcing rule to be used when
products are shipped to a specific node type.
Any Node Select Any Node and if this sourcing rule can be used when
products are shipped to any node.
Sourced From List

The system tries to source the product from the node/distribution group with the highest
sequence (lowest number). If the sourcing template contains a distribution group or a set of
nodes, the final node selection is optimized based on the parameters configured in your
scheduling rule associated with a given order. For more information about scheduling
rules, see “Defining Scheduling Rules” on page 47.

If there is no product availability for a node/distribution group specified in a given

sequence, the system tries to source from the next node/distribution group in the
sequence.
Sequence No The sequence priority of the sourcing template.
Sourcing Template A list of the node/distribution group sequences used for
sourcing. The sequence is determined by priority. For more
information about sourcing templates, see “Defining Sourcing
Template Details” on page 74.

4. Choose the Save icon.

Modifying a Sourcing Rule for Procurement

About this task

To modify a sourcing rule for procurement:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Procurement > Sourcing Rules.
The Procurement - Sourcing Rule Search window displays in the work area.

72 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
2. Select the applicable sourcing rule and choose the Details icon. The Sourcing
Rules for Procurement window displays.
3. Enter information into the applicable fields. Refer to Table 29 on page 72 for
field value descriptions.
4. Choose the Save icon.

Deleting a Product Procurement Rule

About this task

To delete a sourcing rule for procurement:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Procurement > Sourcing Rules.
The Procurement - Sourcing Rule Search window displays in the work area.
2. Select the applicable sourcing rule and choose the Delete icon.

Creating a Procurement Distribution Group

About this task

To create a distribution group:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Procurement > Distribution
Group. The Procurement Distribution Groups window displays in the work
area.
2. Choose the Create New icon. The Distribution Group Detail window displays.
3. Enter information into the applicable fields. Refer to Table 30 for field value
descriptions.
Table 30. Procurement Distribution Group Details Window
Field Description
Distribution Group Enter a name for the distribution group.
Description Enter a description for the distribution group.
Distribution Group List

Note: The Distribution Group needs to be saved before adding ship nodes.
Ship Node The identifier for the ship node

4. Choose the Save icon.

Modifying a Procurement Distribution Group

About this task

To modify a distribution group:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Procurement > Distribution
Group. The Procurement Distribution Groups window displays in the work
area.

Chapter 3. Configuring Cross-Application Order Promising Components 73

 2. Select the applicable distribution group and choose the Details icon. The
Distribution Group Details window displays.
3. Enter information into the applicable fields. Refer to Table 30 on page 73 for
field value descriptions.
4. Choose the Save icon.

Deleting a Procurement Distribution Group

About this task

To delete a distribution group:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Order Promising > Sourcing And Scheduling > Procurement > Distribution
Group. The Procurement Distribution Groups window displays in the work
area.
2. Select the applicable distribution group and choose the Delete icon.

Defining Sourcing Template Details

Sourcing templates enables you to specify a node, a set of nodes, or distribution
groups to be used in sourcing rules. For more information about the available
sourcing templates, see the Sterling Selling and Fulfillment Foundation: Javadocs.

Applying a Sourcing Template to a Sourcing Rule

About this task

To apply a sourcing template to a sourcing rule:

Procedure
1. From the Sourcing Rule Window, choose the Create New icon from the Sourced
From List panel. The Sourced From Details pop-up window displays.
2. Enter information into the applicable fields. Refer to Table 31 for field value
descriptions.
3. Choose the Save icon.
Table 31. Sourced From Details Pop-Up Window
Field Description
Sequence No Enter the sequence priority.
Template Type Select a sourcing template from the drop-down list. After
choosing a template, it displays dynamically in the lower
panel. If applicable, populate the template by clicking as
indicated. The search window displays, where you can select
the correct entities.
Substitution Is Allowed Check this box if substitution of product items within an
order is allowed.
Procure/Transfer to this Check this box if the node handles transfer orders or
Node when inventory is procurement purchase orders. For more information about
not available transfer orders and procurement purchase orders, see
“Defining a Node’s Relationships” on page 37 and “Defining
Procurement Rules” on page 71.

74 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 31. Sourced From Details Pop-Up Window (continued)
Field Description
Expand to the next Check this box if you want sourcing for product items to
sourcing sequence to expand to the next sourcing sequence to minimize the
minimize number of number of shipments. This expansion occurs only if the
shipments expandAllLines property in yfs.properties=N or is not set and
the scheduling optimization rule type is 03 (Optimize on
Cost, Number of Shipments.) In any case, if product items are
unavailable, sourcing always expands to the next sequence
until the product item is found.
Work Order Creation Is Check this box if you want to use Work Orders to support
Allowed compliance services at the node(s). Work Orders describe the
service activities to customize items based on a buyer's
requests.
Consider only those nodes This option is enabled when you select "Receiving Node's
that are <...>" or "Distribution Group" or "All Nodes of Types"
Template Type from the drop-down list.

Based on the "Radius" and "RadiusUOM" set, the system will

expand only those nodes in the Distribution Group whose
distance from the 'ShipTo' location is within set miles.

For example, if you set "Radius" as 100 and "RadiusUOM" as

MILE, the system will expand only those nodes in the
Distribution Group whose distance from the 'ShipTo' location
is within 100.0 miles.
Consider Only Those Use this field to specify the capacity percentage for each node
Nodes That Have A and the number of days to which that capacity applies. Only
Minimum Available nodes that have this level of capacity available will be used; if
Capacity of <capacity>% a node does not meet this defined availability percentage, it
Within The Next <number of will not be used.
days> Day(s)
For additional information about adjusting node capacity,
refer to the Business Center: Inventory Management Guide.
Consider the following inventory during sourcing
All Inventory Select this option to consider both the onhand and future
inventory.
Inventory that will be Select this option to consider inventory that will be made
available in the next available in the specified number of days.
<number of days> day(s)
Enter the number of day(s) in the text box indicating how far
in the future from the requested ship date that the inventory
should be considered.
Only Onhand Inventory Select this option to consider only onhand inventory.
Use Shipping/Delivery Select this option to use the Shipping or Delivery Sourcing
Sourcing Rule Inventory Rule Inventory Window.
Window

Note: The Sourced From Details window is applicable for Product Sourcing
only.

Modifying a Sourcing Template for a Sourcing Rule

About this task

To modify a sourcing template for a sourcing rule:

Chapter 3. Configuring Cross-Application Order Promising Components 75

 Procedure
1. From the Sourcing Rule Window, select the sourcing template you want to
modify from the Sourced From List and choose the Details icon. The Sourced
From Details pop-up window displays.
2. Enter information into the applicable fields. Refer to Table 31 on page 74 for
field value descriptions.
3. Choose the Save icon.

Removing a Sourcing Template from a Sourcing Rule

About this task

To remove a sourcing template from a sourcing rule, from the Sourcing Rule
Window, select the Sourced From Detail you want to remove from the Sourced
From List and choose the Delete icon.

76 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 4. Configuring Cross-Application Service Execution
Components
Configuring Service Supervisors
You can specify the supervisor associated with a node for a given seller
organization. You can also assign a default supervisor to a node for all seller
organizations.

The system allows you assign only one supervisor for a given node and seller
organization combination. The default supervisor can only be a supervisor of a
node, if no other supervisor is defined for that node and seller organization
combination. If both are defined, the supervisor specified for a node and seller
organization combination takes precedence over the default supervisor.

Note: The supervisor must be a user defined in the context of the node that is
being configured. For more information about configuring users, see the Sterling
Selling and Fulfillment Foundation: Configuration Guide.

Defining a Service Supervisor for a Node

About this task

To define a service supervisor for a node:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Service Supervisors. The Node Supervisor Search window
displays.
2. Enter the applicable search criteria and choose the Search icon. A list of nodes
displays. Select the node to which you want to assign the supervisor and
choose the Details icon. The Supervisor Setup pop-up window displays.
3. Enter information in the applicable fields. See Table 32 for field value
descriptions.
4. Choose the Save icon.
Table 32. Supervisor Setup pop-up window
Field Description
Default Supervisor Select the default supervisor from the drop-down list. If a
supervisor is not defined for a given seller organization for
this node, the user specified becomes that supervisor of the
node for all non-specified seller organizations.
Supervisor Setup
Seller Organization Select the seller organization from the drop-down list. If you
define a seller organization, you must select a supervisor
identifier in the Supervisor ID field.
Supervisor ID Select the supervisor identifier from the drop-down list. If
you define a supervisor, you must select a seller organization
in the Seller Organization field.

© Copyright IBM Corp. 1999, 2012 77

 Modifying a Service Supervisor for a Node
About this task

To modify a service supervisor for a node:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Service Supervisors. The Node Supervisor Search window
displays.
2. Enter the applicable search criteria and choose the Search icon. The Nodes list
displays. Select the node for which you want to assign a supervisor and choose
the Details icon. The Supervisor Setup pop-up window displays.
3. Enter information in the applicable fields. See Table 32 on page 77 for field
value descriptions.
4. Choose the Save icon.

Deleting a Service Supervisor for a Node

About this task

To delete a service supervisor for a node:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Service Supervisors. The Node Supervisor Search window
displays.
2. Enter the applicable search criteria and choose the Search icon. A list of node
displays. Select the node to which you want to assign a supervisor and choose
the Details icon. The Supervisor Setup pop-up window displays.
3. Select the row which contains the seller organization and supervisor ID that
you want to delete and choose the Delete icon.
4. Choose the Save icon.

Configuring Questions
You can define a set of questions that the customer can be asked when it is
determined that additional address or permit information is required.

Defining Address Question Groups

About this task

To define address question groups:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. The Address Questions tab displays by default.
2. Choose the Create New icon. The Question Group Details pop-up window
displays. Refer to the following table for field values.

78 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 33. Question Group Details
Fields
Question Group ID Enter the unique question group ID.
Question Group Text Enter the question group text as you want it to appear in the
UI.

3. Enter information in the applicable fields.

4. Choose the Save icon.

Note: Identifiers are unique across Question IDs and Question Group IDs.

Modifying Address Question Groups

About this task

To modify address question groups:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. The Address Questions tab displays by default.
2. Select the question group you want to modify and choose the Details icon. The
Question Group Details pop-up window displays.
3. Enter information in the applicable fields. Refer to the Question Group Details
table for field value descriptions.
4. Choose the Save icon.

Deleting Address Question Groups

About this task

To delete address question groups:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. The Address Questions tab displays by default.
2. Select the Question Group you want to delete, and choose the Delete icon.

Defining Address Questions

About this task

To define address questions:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. The Address Questions tab displays by default.
2. Questions can be defined from the root level, a question group, or an answer
option. If a question derives from an answer option, in the console it appears
on the questionnaire only when the corresponding answer option has been
selected. Follow-up questions cannot be added to answer options for other
follow-up questions, however several follow-up questions can be added to the

Chapter 4. Configuring Cross-Application Service Execution Components 79

 same answer option for a question. Furthermore, follow-up questions can only
be defined off of the ‘Yes' Answer Option from a checkbox, or Answer Options
whose display control type is Dropdown or Radio Button.
Select the desired location for the question and choose the Create New icon.
The Question Details pop-up window displays. Refer to the following table for
field value descriptions.
Table 34. Question Details
Fields
Question ID Enter the question identifier.
Question Text Enter the question text as you want the question to appear in
the UI.
Data Type Select the data type for the answers. The data type you select
governs the possible display control type options:

Text - Textbox, Text Area, Dropdown, Radio Button

Integer - Textbox

Decimal - Textbox

Boolean - Checkbox
Display Control Type Select how you want the answer options to appear in the UI.
The Display Control Types available depend on the Data
Type you have selected.
Answer Options - the following fields appear when you have chosen Dropdown or Radio
Button as the desired display control type.
Value Enter the value for the answer option.
Display Text Enter the answer option text as you want the answer to
appear in the UI.

3. Enter information in the applicable fields.

4. Choose the Save icon.

Modifying Address Questions

About this task

To modify address questions:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. The Address Questions tab displays by default.
2. Select the question you want to modify, and choose the Details icon. The
Question Details pop-up window displays.
3. Enter information in the applicable fields. Refer to the Question Details table
for field value descriptions.
4. Choose the Save icon.

Deleting Address Questions

About this task

To delete address questions:

80 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. The Address Questions tab displays by default.
2. Select the question you want to delete, and choose the Delete icon.

Defining Capacity Impact

About this task

You can define capacity impact for an answer option which is added to the
capacity demand on the order, based on service type. You can add different
capacity impact values for different service types. There are two types of capacity
impact:

Fixed Capacity Impact - A fixed capacity value can be added to a ‘Yes' Answer
Option from a checkbox, or Answer Options whose display control type is
Dropdown or Radio Button.

Capacity Impact Multiplier - A capacity multiplier value can be added to a

Answer Option whose display control type is Integer or Decimal. The value is
multiplied by the numeric answer given to determine the amount of capacity to
add.

To define capacity impact:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. The Address Questions tab displays by default.
2. Select the Answer Option to which you want to add Capacity Impact and click
the Check Additional Questions icon. The Answer Option Details pop-up
window displays.
Table 35. Answer Option Details
Fields
Question ID The identifier for the question this answer option is for.
Question Text The text for the question this answer option is for.
Answer Option Value The value of the answer option.
Answer Option Text The text for the answer option.
Answer Capacity Impact
Service Type Select the Service Type for which capacity is added.
Fixed Capacity Impact If available, enter the amount of capacity you want to add if
this answer option is selected.
Capacity Impact Multiplier If available, enter the value you want to multiply the answer
by, which determines the amount of capacity to add for this
answer option.
UOM The unit of measure for the selected Service Type. This field
is not modifiable.

3. Enter information in the applicable fields. Refer to Table 35 for field value
descriptions.

Chapter 4. Configuring Cross-Application Service Execution Components 81

 4. Choose the Save icon.

Modifying Capacity Impact

About this task

To modify capacity impact:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. The Address Questions tab displays by default.
2. Select the Answer Option for which you want to modify Capacity Impact and
click the Check Additional Questions icon. The Answer Option Details pop-up
window displays.
3. Enter information in the applicable fields. See Table 35 on page 81 for field
value descriptions.
4. Choose the Save icon.

Deleting Capacity Impact

About this task

To delete capacity impact:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. The Address Questions tab displays by default.
2. Select the Answer Option for which you want to remove Capacity Impact and
click the Check Additional Questions icon. The Answer Option Details pop-up
window displays.
3. Select the Capacity Impact you want to delete and choose the Delete icon.

Rearranging Address Question Entities

The questionnaire tree represents how the questionnaire appears in the console. By
arranging question groups, questions, and answer options, you modify how you
want the questionnaire to appear in the console.

There are two methods you can use to move question groups, questions, and
answer options, depending on how you want to move.

Using the and icons, you can move question groups, questions and answer
options up and down the questionnaire tree, within the entity it is currently
contained in:
v Questions Groups - these can be arranged on the questionnaire tree at the root
level.
v Questions - these can be arranged within a question group, in and out of
question groups, and up and down levels.
v Answer Options - these can be arranged within a question.

Using the drag and drop functionality, you can:

v Move questions in and out of question groups

82 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 v Change a follow-up question into a standalone question by dropping onto a
question group or the root of the tree
v Change a question into a follow-up question by dropping onto an answer option
that allows follow-up questions.

The questionnaire tree represents how the questions appear in the Questionnaire in
the console. By arranging question groups, questions, and answer options, and you
modify how you want the questionnaire to appear in the console.

Defining Permit Question Groups

About this task

To define permit question groups:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. Select the Permit Questions tab to view the Permit Questions window.
2. Choose the Create New icon. The Question Group Details pop-up window
displays.
Table 36. Question Group Details
Fields
Question Group ID Enter the unique question group ID.
Question Group Text Enter the question group text as you want it to appear in the
UI.

3. Enter information in the applicable fields. Refer to Table 36 for field value
descriptions.
4. Click the Save icon.

Note: Identifiers are unique across Question IDs and Question Group IDs.

Modifying Permit Question Groups

About this task

To modify permit question groups:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. Select the Permit Questions tab to view the Permit Questions window.
2. Select the question group you want to modify and click the Details icon. The
Question Group Details pop-up window displays.
3. Enter information in the applicable fields. See Table 36 for field value
descriptions.
4. Choose the Save icon.

Deleting Permit Question Groups

About this task

To delete permit question groups:

Chapter 4. Configuring Cross-Application Service Execution Components 83

 Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. Select the Permit Questions tab to view the Permit Questions window.
2. Select the Question Group you want to delete, and choose the Delete icon.

Defining Permit Questions

About this task

To define permit questions:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. Select the Permit Questions tab to view the Permit Questions window.
2. Questions can be defined from the root level, a question group, or an answer
option. Questions that are derived from an answer option appear on the
questionnaire only when the corresponding answer option has been selected.
Follow-up questions cannot be added to answer options for other follow-up
questions, however several follow-up questions can be added to the same
answer option for a question. Furthermore, follow-up questions can only be
defined off of the ‘Yes' Answer Option from a checkbox, or Answer Options
whose display control type is Dropdown or Radio Button.
Select the desired location for the question and choose the Create New icon.
The Question Details pop-up window displays.
Table 37. Question Details
Fields
Question ID Enter the unique question ID.
Question Text Enter the question text as you want the question to appear in
the UI.
Data Type Select the data type for the answers. The data type you select
governs the possible display control type options:

Text - Textbox, Text Area, Dropdown, Radio Button

Integer - Textbox

Decimal - Textbox

Boolean - Checkbox
Display Control Type Select how you want the answer options to appear in the UI.
The display control types available depend on the Data Type
you have selected.
Answer Options - the following fields appear when you have chosen Dropdown or Radio
Button as the desired display control type.
Value Enter the value for the answer option.
Display Text Enter the answer option text as you want the answer to
appear in the UI.

3. Enter information in the applicable fields. Refer to Table 37 for field value
descriptions.
4. Choose the Save icon.

84 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Modifying Permit Questions
About this task

To modify permit questions:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. Select the Permit Questions tab to view the Permit Questions window.
2. Select the question you want to modify, and choose the Details icon. The
Question Details pop-up window displays.
3. Enter information in the applicable fields. Refer to Table 37 on page 84 for field
value descriptions.
4. Choose the Save icon.

Deleting Permit Questions

About this task

To delete permit questions:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Service Execution > Questions. The Questions window displays in the work
area. Select the Permit Questions tab to view the Permit Questions window.
2. Select the question you want to delete, and choose the Delete icon.

Rearranging Permit Questionnaire Entities

The questionnaire tree represents how the questionnaire appears in the console. By
arranging question groups, questions, and answer options, and you modify how
you want the questionnaire to appear in the console.

There are two methods you can use to move question groups, questions, and
answer options, depending on how you want to move.

Using the Move Up Arrow icon and Move Down Arrow icon,, you can move
question groups, questions and answer options up and down the questionnaire
tree, within the entity it is currently contained in:
v Questions Groups - these can be arranged on the questionnaire tree at the root
level.
v Questions - these can be arranged within a question group, in and out of
question groups, and up and down levels.
v Answer Options - these can be arranged within a question.

Using the drag and drop functionality, you can:

v Move questions in and out of question groups
v Change a follow-up question into a standalone question by dropping onto a
question group or the root of the tree
v Change a question into a follow-up question by dropping onto an answer option
that allows follow-up questions.

Chapter 4. Configuring Cross-Application Service Execution Components 85

 The questionnaire tree represents how the questions appear in the Questionnaire in
the console. By arranging question groups, questions, and answer options, and you
modify how you want the questionnaire to appear in the console.

86 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 5. Configuring Cross-Application Logistics
Components
Configuring Cross-Application Logistics Components
You can configure the components used by different logistics related functionality
throughout the business application module.

You can use the Logistics branch for defining logistical attributes, delivery codes,
shipment modes, and outbound constraints.

Defining Logistics Attributes

You can define rules and common codes associated logistics of shipping an order.

You can use the Logistics Attributes branch for defining freight terms, shipment
modes, carrier modification reasons, and additional logistic rules.

Defining Freight Terms

You can define common codes used when associating a freight term to a Carrier. A
freight term identifies how transportation costs are calculated.

The default freight terms of Sterling Selling and Fulfillment Foundation are:
v Cost Insurance and Freight (CIF) - The freight cost is completely paid by either
the Seller, the Enterprise, or the Hub.
v Cost and Freight (CFR) - The freight cost is paid by the Buyer and either the
Seller, the Enterprise, or the Hub.
v Free On Board (FOB) - The freight cost is paid by the Buyer.

You can use the Freight Terms tab for creating, modifying, and deleting freight
terms.

Creating a Freight Term

About this task

To create a freight term:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Logistics Attributes. The Logistics window displays in the work
area.
2. Choose the Freight Terms tab.
3. Choose the Create New icon. The Freight Terms Details pop-up window
displays.
4. Enter information in the applicable fields. Refer to Table 38 on page 88 for field
value descriptions.
5. Enter Choose the Save icon.

© Copyright IBM Corp. 1999, 2012 87

 Table 38. Freight Terms Details
Field Description
Freight Terms Enter the name of the freight term.
Short Description Enter a brief description of the freight term.
Long Description Enter a more detailed description of the freight term.
Consider Buyer's Routing Both the Buyer and the Enterprise can establish routing
Guide guides (rules for shipping), and Economic Shipping
parameters (ESP), which control how items are shipped. In
some cases only the Buyer organization has established
values for these rules. In other cases, only the enterprise has
established values for these rules. If neither is set, then Hub
rules are used.

In cases where both the Buyer and the Enterprise have set
values for these rules, this setting determines whether to
apply the Buyer's routing rules before applying the routing
rules of the Enterprise. See the Sterling Selling and Fulfillment
Foundation: Product Concepts Guide for more information about
these shipping concepts.
First Buyer then Enterprise Select to use any shipping rules established by the buyer first.
Enterprise rules are applied if no applicable Buyer rule exists.
First Enterprise then Buyer Select to use any shipping rules established by the enterprise
first. Buyer rules are applied if no applicable Enterprise rule
exists.
Charges paid by
Buyer Select this option if the Buyer pays shipping charges.
Shipper Select this option if the Shipper pays shipping charges.

Modifying a Freight Term

About this task

To modify a freight term:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Logistics Attributes. The Logistics window displays in the work
area.
2. Choose the Freight Terms tab.
3. Select the applicable freight term and choose the Details icon. The Freight
Terms Details pop-up window displays.
4. Enter the new information in the applicable fields. Refer to Table 38 for field
value descriptions.
5. Choose the Save icon.

Deleting a Freight Term

About this task

To delete a freight term:

88 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Logistics Attributes. The Logistics window displays in the work
area.
2. Choose the Freight Terms tab.
3. Select the applicable freight term and choose the Delete icon.

Defining Carrier Modification Reasons

You can define common codes that appear in the Reason Code drop-down list
when you modify a Carrier. This code should provide a standard reason for
modifying a Carrier, such as ‘Requested Change' which would be used when the
customer requests a change of Carrier.

The default carrier modification reason of Sterling Selling and Fulfillment

Foundation is "Requested Change."

You can use the Modify Carrier Reason tab for creating, modifying, and deleting a
carrier modification reason.

Creating a Carrier Modification Reason

About this task

To create a carrier modification reason:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Logistics Attributes. The Logistics window displays in the work
area.
2. Choose the Modify Carrier Reason tab.
3. Choose the Create New icon. The Modify Carrier Reason Details pop-up
window displays.
4. In Modify Carrier Reason, enter the name of the carrier modification reason.
5. In Short Description, enter a brief description of the carrier modification reason.
6. In Long Description, enter a more detailed description of the carrier
modification reason.
7. Choose the Save icon.

Modifying a Carrier Modification Reason

About this task

To modify a carrier modification reason:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Logistics Attributes. The Logistics window displays in the work
area.
2. Choose the Modify Carrier Reason tab.
3. Select the applicable carrier modification reason and choose the Details icon.
The Modify Carrier Reason Details pop-up window displays.
4. In Short Description, enter a brief description of the carrier modification reason.
5. In Long Description, enter a more detailed description of the carrier
modification reason.

Chapter 5. Configuring Cross-Application Logistics Components 89

 6. Choose the Save icon.

Deleting a Carrier Modification Reason

About this task

To delete a carrier modification reason:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Logistics Attributes. The Logistics window displays in the work
area.
2. Choose the Modify Carrier Reason tab.
3. Select the applicable carrier modification reason and choose the Delete icon.

Defining Additional Logistic Rules

About this task

You can define additional rules that pertain to an order document type.

To define additional logistic rules:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Logistics Attributes. The Logistics window displays in the work
area.
2. Choose the Other Rules tab.
3. Enter information in the applicable fields. Refer to Table 39 for field value
descriptions.
4. Choose the Save icon.
Table 39. Other Rules Tab
Field Description
Advance Transit Time Calculation
Use Advanced Transit Select this field if advance transit time calculation is required
Time Calculation when considering ship dates and delivery dates.

Transit time is calculated as Lead Time + Distance Per Day

(either from the Distance Per Day for a selected Carrier
service).
Based on SCAC and Select Based on Carrier if you want transit time calculations
Carrier Service to be based on the carrier and carrier service being used for
an order.
Based on Carrier Service Select Based on Carrier Service if you want transit time
calculations to be based on the specific carrier service being
used for an order.

90 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 39. Other Rules Tab (continued)
Field Description
Delivery Lead Time (Days) Enter the default delivery lead time.

Delivery lead time is used to determine when an order line

must be shipped based on the requested delivery date. The
delivery lead time indicates the amount of time it takes to
transport a load from a ship node to a customer. When
calculating the delivery date:
v If neither the ship date or delivery date are provided, the
ship date is defaulted to the current days date and the
delivery date is defaulted to that date + delivery lead time.
v If the ship date is provided but the delivery date is not, the
delivery date is defaulted to ship date + delivery lead time.
v If the delivery date is provided but the ship date is not, the
ship date is defaulted to delivery date - delivery lead time.
v If both the ship date and delivery date are provided, this
rule is not applied.
Round Up Transit Time To If selected, transit time calculations are not specific down to
Nearest Day the actual hour. Instead, the system performs the calculations
and rounds up to the next available day.
Distance Per Day Enter the default distance for calculating transit time if a
Carrier service is not selected or the service selected does not
have a distance per day associated with it.
UOM Select the distance unit of measure.
Default Carrier Service for Select the carrier service you want to use to compute the
Transfer transfer time between two nodes if they do not have a
transfer schedule configured for them.

For more information about configuring transfer schedules

between nodes, see the Sterling Selling and Fulfillment
Foundation: Distributed Order Management Configuration Guide.

Defining Delivery Codes

You can define common codes used for indicating the delivery code when creating
or modifying a Carrier. The delivery code identifies the entity that pays for the
transportation costs.

The default delivery codes of Sterling Selling and Fulfillment Foundation are:
v ENTERPRISE
v MARKETPLACE
v SUPPLIER

You can use the Delivery Codes branch for creating, modifying, and deleting a
delivery code.

Creating a Delivery Code

About this task

To create a delivery code:

Chapter 5. Configuring Cross-Application Logistics Components 91

 Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Delivery Codes. The Delivery Codes window displays in the work
area.
2. Choose the Create New icon. The Delivery Code Details pop-up window
displays.
3. In Delivery Code, enter the name of the delivery code.
4. In Short Description, enter a brief description of the delivery code.
5. In Long Description, enter a more detailed description of the delivery code.
6. Choose the Save icon.

Modifying a Delivery Code

About this task

To modify a delivery code:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Delivery Codes. The Delivery Codes window displays in the work
area.
2. Select the applicable delivery code and choose the Details icon. The Delivery
Code Details pop-up window displays.
3. In Short Description, enter a brief description of the delivery code.
4. In Long Description, enter a more detailed description of the delivery code.
5. Choose the Save icon.

Deleting a Delivery Code

About this task

To delete a delivery code:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Delivery Codes. The Delivery Codes window displays in the work
area.
2. Select the applicable delivery code and choose the Delete icon.

Defining Shipment Modes

You can define common codes used when indicating the ship mode. The shipment
mode describes how an order is being shipped.

The default shipment modes of Sterling Selling and Fulfillment Foundation are:
v TL - Truckload
v LTL - Less-Than Truckload
v PARCEL

You can use the Shipment Modes tab for creating, modifying, and deleting a
shipment mode.

92 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Creating a Shipment Mode
About this task

To create a shipment mode:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Shipment Modes. The Shipment Modes window displays in the
work area.
2. Choose the Create New icon. The Shipment Mode Details pop-up window
displays.
3. In Shipment Mode, enter the name of the shipment mode.
4. In Short Description, enter a brief description of the shipment mode.
5. In Long Description, enter a more detailed description of the shipment mode.
6. Choose the Save icon.

Modifying a Shipment Mode

About this task

To modify a shipment mode:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Shipment Modes. The Shipment Modes window displays in the
work area.
2. Select the applicable shipment mode and choose the Create New icon. The
Shipment Mode Details pop-up window displays.
3. In Short Description, enter a brief description of the shipment mode.
4. In Long Description, enter a more detailed description of the shipment mode.
5. Choose the Save icon.

Deleting a Shipment Mode

About this task

To delete a shipment mode:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Shipment Modes. The Shipment Modes window displays in the
work area.
2. Select the applicable shipment mode and choose the Delete icon.

Defining Outbound Constraints

Outbound constraints are used to describe conditions that control how shipping is
done. These include whether certain items can be shipped together, such as regular
and rush orders, whether to use Economic Shipping Parameters, and how routing
is performed. You can also use Outbound Constraints for creating, modifying, and
deleting a routing guide.

Chapter 5. Configuring Cross-Application Logistics Components 93

 The Outbound Constraints node does not apply to Reverse Logistics or Supply
Collaboration.

To define outbound constraints:

1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Outbound Constraints. The Outbound Constraints window displays
in the work area.
2. Enter information in the applicable fields. Refer to Table 40 for field value
descriptions.
3. Choose the Save icon.
Table 40. Outbound Constraint Window
Field Description
Do not mix in a shipment If any of the following are selected, separate shipments must
be create for items that have different values for these
attributes.

For example, if Department Code is selected, items that are

for different departments can not be included in the same
shipment.
Buyer Mark For The buyer mark for node id.
Node Id
Customer PO # Customer's Purchase Order number.
Department Code The department for which the item is intended.
Gift Flag The gift flag.
Level of Service The level of service on the order.
Mark For Person for whom this shipment is marked for
Order # The order number.
Order Type The order type.
Transportation optimization
Economic shipping Economic Shipping Parameters (ESP) are used in shipping
parameters maintained consolidation. Select this field to enable the following
Economic Shipping Parameters fields.

ESP support consolidation of shipments until a weight or

volume threshold is met, or until an certain time elapses. By
consolidating shipments, shipping costs can be reduced

For example, you can set that shipments should be

consolidated until the shipment weight is 300 pounds, or 50
cubic feet in volume. To ensure that eventually the shipment
is set, you can establish a maximum number of days to wait
until the conditions are met.

When either the weight, volume or delay shipment threshold

is met, the shipment is moved to the next stage in shipping.
Delay shipment by not Enter the number of days this shipment can be delayed
more than __ Days before it should be shipped.

For example, if a value is set for weight threshold of 300

pounds, and this field has been set to 3 days, the shipment is
shipped after 3 days, regardless of whether the weight
threshold has been met.

94 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 40. Outbound Constraint Window (continued)
Field Description
Consolidate up to weight Enter a weight.
threshold of
Consolidate up to volume Enter a volume
threshold of
Routing Guide
Not Maintained Select this to use manual routing. Shipments are managed in
the shipment console, and any routing guides are not
consulted.
Maintained in Sterling Select this to use the Routing Guides maintained in Sterling
Selling and Fulfillment Foundation to determine how
shipments should be routed. See “Creating a Routing Guide.”

In addition to the routing guide maintained here by the

enterprise, there may be a routing guide for the buyer
organization.

For more information about using both buyer and enterprise

routing guides, see “Creating a Freight Term” on page 87.
Maintained Externally Select this to indicate that an external routing system is used.
The routing guides maintained in Sterling Selling and
Fulfillment Foundation is not consulted.

Examples of external routing systems include using an

integrated Transportation Management System (TMS), or
implementing a User Exit which consults with the buyer
organization.

Creating a Routing Guide

About this task

Routing Guides are a list of conditions which determine how a shipment should be
routed. A routing guide has a time period for which is effective, and conditions for
when it should be applied. These conditions are based on Freight Terms and
Department.

Each routing guide contains a list of routing guide lines, each of which describe
detailed conditions for selecting a carrier. The routing guide information is based
on data used by VICS (Voluntary InterIndustry Commerce Standards) routing.

To create a routing guide:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Outbound Constraints. The Outbound Constraints window displays
in the work area.
2. Select the Create New icon on the Routing Guides list window. The Routing
Guide Details window displays in the work area.
3. Enter information in the applicable fields. Refer to Table 41 on page 96 for field
value descriptions.
4. Choose the Save icon.

Chapter 5. Configuring Cross-Application Logistics Components 95

 Table 41. Routing Guide Details Window
Field Description
Name Enter a name for the routing guide.
Routing Guide # A number for the routing guide.
Publish Date When this routing guide is available within the system.
Supersedes Routing Tracking information. For example, if a minor revision is
Guide # made to routing guide "1234", you might create a routing
guide "1234-A", and enter that it supersedes routing guide
"1234". This field is for informational purposes and is not
used to determine the effective routing guide.
Effective Date The start date for applying the routing information in this
routing guide. You can use the effective date and expiration
date to apply routing guidelines for particular periods of
time.
Expiration Date The end date for applying the routing information in this
routing guide.
Apply this Routing Guide when
Freight Terms Apply this routing guide when this condition is met. Select is,
is in, or is not. Use:
v is to specify a single Freight Term.
v is in to specify a group of Freight Terms, one of which
must be matched.
v is not in to specify a group of Freight Terms. The routing
guide is used if the Freight Term does not match one of
these values.
Item Classification Items can be classified.

This field displays when valid item classifications have been

set up for Routing Guide.

Modifying a Routing Guide

About this task

To modify a routing guide:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Outbound Constraints. The Outbound Constraints window displays
in the work area.
2. Select a routing guide in the Routing Guide list window, and select the Details
icon.
3. The Routing Guide Details window displays in the work area.
4. Enter information in the applicable fields. Refer to Table 41 for field value
descriptions.
5. Choose the Save icon.

Creating a Routing Guide Line

About this task

Routing guide lines contain the specific conditions to use when routing a shipment.
A routing guide can contain multiple routing guide lines.

96 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
When routing occurs, the shipment is matched against the routing guide lines.
Based on the criteria specified, a carrier and carrier service is selected.

When routing results in a change to the shipment destination, the system reroutes,
with the revised destination as the factor for routing. This type of configuration is
used for consolidator nodes. While routing the second time, system looks for the
routing guide entry that contains destination node, but without any other
destination parameters filled out (such as address, etc.).

To create a routing guide line:

Procedure
1. From the Routing Guide Details window, select the Routing Guidelines Tab. To
have access to the Routing Guidelines Tab, save the information you have
entered on the Primary Info Tab.
2. A Routing Guide Line search window displays.
3. Select the Create New icon. A Routing Guide Line Details screen displays in
the work area.
4. Enter information in the applicable fields. Refer to Table 42 for field value
descriptions.
5. Choose the Save icon.
Table 42. Routing Guide Line Details
Setting conditions:

In many of the following fields, you can select is, is in, or is not in and then specify a
value. Use:
v is to specify that a single value must be matched
v is in to specify a group of values, one of which must be matched.
v is not in to specify a group of values. The routing guide line is used if none of these
values match.

For example to match any one of a group of states, specify State is in California,
Washington, Oregon, Nevada. When assessing the condition, California would match,
Florida would not.
Field Description
Ship From
Node Select the node.
When ship from is not Enter this option if not shipping from the node and then
node, select the following enter one or more of the following conditions.
attribute(s)
Country/Region Select the country or region name(s).
State Enter the state name(s).
City Enter the city name(s).
Zip Code Enter the zip code or zip code range.
Ship To
Node Select the node.
Region Enter the region.
When ship to is not node Select this option if not shipping to a node within a specific
and region, select the region and then select one or more of the following
following attribute(s) conditions.

Chapter 5. Configuring Cross-Application Logistics Components 97

 Table 42. Routing Guide Line Details (continued)
Country/Region Select the country or region name(s).
State Enter the state name(s).
City Enter the city name(s).
Zip Code Enter the zip code or zip code range.
Consolidator Select the consolidator name(s).
Store# Select the store number(s).
And weight is in the range: You can match weight. For example, if you want packages
that weigh between 100 and 500 pounds to be shipped using
a specific carrier, you would specify From as ‘100' and To as
‘500'.
From Enter the minimum value.
To Enter the maximum value.
And volume is in the You can match volume. For example, if you want packages
range: that are between 3 and 10 cubic feet to be shipped using a
specific carrier, you would specify From as ‘3' and To as ‘10'.
From Enter the minimum value.
To Enter the maximum value.
And handling units are in Number of containers.
the range:
From Enter the minimum value.
To Enter the maximum value.
And if requested carrier
service code is
Carrier Service Code Select a carrier service code.
For more information about defining carrier services, see “Defining Carrier Services” on
page 99.
Then ship via:
Priority Indicates the number to give this rule a relative importance.

When a shipment is compared to the routing guide lines,

there may be two carrier services that could be used. This
priority serves as a tie breaker. The carrier service with the
lowest number is used.
Carrier / Service Indicates the carrier and service code that is desired.
Break Bulk Node The break bulk node that is close to the buyer.
Contact Specified Indicates whether the contact details for the shipment is
specified.
With overrides:
Override Freight Terms Select to override the shipment's Freight Term.
Override Ship To To override the Ship To value, select this field, and then select
one of the following. This is only used when performing
routing again due to a revised ship to address.
Node Select the node name.
Consolidator Select the consolidator name.
Store# Select the store number.

98 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Results

When the conditions set are assessed, the routing guide line which matches the
most conditions is used. For example, imagine there are three routing guide lines:

Routing guide line A - What to do when shipping from Massachusetts

Routing guide line B - What to do when shipping from Massachusetts, and when
shipping from the zip code 01810.

Routing guide line C - What to do when shipping from Massachusetts or NY.

If the shipment originates from the zip code 01810, it matches all of these routing
guide lines. The actions specified in Routing guide line B is used, as more conditions
are met (both the state and the zip code).

If the shipment originates from Massachusetts, but not from zip code 01810, then
both Routing guideline A and Routing guide line C match. The priority on the
guidelines are used to determine which is used, with the lowest numbered priority
being selected. If Routing guideline A had a priority number of 3, and Routing
guideline C had a priority number of 5, Routing guideline A is used.

Defining Carrier Services: When routing occurs, the shipment is matched against
the routing guidelines. Based on the criteria specified, you select a carrier service
to use.

You can use the Carrier Services panel for creating, modifying, or deleting a carrier
service.

Creating a Carrier Service:

About this task

To create a carrier service:

Procedure
1. From the Routing Guidelines Details window, in the Carrier Services panel,
select the Create New icon. The Carrier Services window displays.
2. Enter information in the applicable fields. Refer to Table 43 for field value
descriptions.
3. Choose the Save icon.
Table 43. Carrier Services
Field Description
Priority Enter a number to give this rule a relative importance.

When a shipment is compared to the routing guide lines,

there may be two carrier services that could be used. This
priority serves as a tie breaker. The carrier service with the
lowest number is used.
Carrier/Service Select the carrier or service code that is desired.
Break Bulk Node Select the break bulk node that is close to the buyer.
Contact Address This is used to specify the address information for the carrier
service's contact person. Click the Details icon to change the
contact Address.

Chapter 5. Configuring Cross-Application Logistics Components 99

 Modifying a Carrier Service:
About this task

To modify a carrier service:

Procedure
1. From the Routing Guidelines Details window, in the Carrier Services panel,
select a carrier service from the list in the Carrier Services list window, and
select the Details icon. The Carrier Services window displays.
2. Enter the new information in the applicable fields. Refer to Table 43 on page 99
for field value descriptions.
3. Choose the Save icon.

Deleting a Carrier Service:

About this task

To delete a carrier service:

Procedure
1. From the Routing Guidelines Details window, in the Carrier Services panel,
select a carrier service in the Carrier Services list window and select the Delete
icon.
2. Choose the Save icon.

Modifying a Routing Guide Line

About this task

To modify a routing guide line:

Procedure
1. From the Routing Guidelines Details window, select the Routing Details Tab. A
Routing Guide Line search window displays.
2. Select a routing guide line in the Routing Guide Line list window, and select
the Modify icon. The Routing Guide Line Details window displays.
3. Enter the new information in the applicable fields. Refer to the "Routing Guide
Line Details" table for field value descriptions.
4. Choose the Save icon.

Deleting a Routing Guide Line

About this task

To delete a Routing Guide Line:

Procedure
1. From the Routing Guide Lines Details window, select the Routing Details Tab.
A Routing Guide Line search window displays.
2. Select a routing guide line in the Routing Guide Line list window, and choose
the Delete icon.

Deleting a Routing Guide

About this task

To delete a routing guide:

100 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Logistics > Outbound Constraints. The Outbound Constraints window displays
in the work area.
2. Select the applicable Routing Guide and choose the Delete icon.

Chapter 5. Configuring Cross-Application Logistics Components 101

102 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 6. Configuring Cross-Application Payment
Components
Configuring Cross-Application Payment Components
You can configure the components used in Sterling Selling and Fulfillment
Foundation to define the types of payment the system accepts and the rules
surrounding payment collection.

You can use the Financials branch for defining payment types and payment rules.

System Payment Processing Rules

About this task

Payment Processing Rules, such as the type of payment, or the order in which
multiple payment types are applied, can be determined at either the seller
organization or enterprise level. You can also specify whether payment processing
is performed for draft orders.

To configure payment processing rules:

Procedure
1. From the tree in the application rules side panel, select Cross Application >
Financials > System Payment Processing Rules. The System Payment Processing
Rules window is displayed in the work area.
2. Enter information in the applicable fields. Refer to Table 44 for field value
descriptions.
Table 44. System Payment Processing Rules Window
Field Description
Payment Rule
Use Enterprise of an Order Check this box to enable Payment Processing Rules to be
(Instead of the Seller configured at the enterprise level.
Organization) to
Determine Payment This rule is only supported when using a compatible PCA
Processing Rules and not by the Console alone.
Draft Order
Enable Draft Order Check this box to enable payment processing for draft orders.
Payment Processing
This option is on by default.
Ignore Charge Request on Check this box to ignore charge requests when calculating the
Draft Order request amount to authorize on draft orders. Normal charge
request processing begins when the draft order is confirmed.

This option is off by default and can be configured only

when Enable Draft Order Payment Processing is on.

3. Choose the Save icon.

© Copyright IBM Corp. 1999, 2012 103

Defining Payment Rules
You can set up the rules that the organization uses at the time of payment
collection.

You can use the Payment Rules branch for creating, modifying, or deleting a
payment rule.

Creating a Payment Rule

About this task

To create a payment rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Payment Rules. The Payment Rules window displays in the work
area.
2. Choose the Create New icon. The Payment Rule Details pop-up window
displays.
3. Enter information in the applicable fields. Refer to Table 45 for field value
descriptions.
4. Choose the Save icon.
Table 45. Payment Rule Pop-Up Window
Field Description
Payment Rule ID Enter the payment rule ID as you would like it to appear
throughout the system.
Publish Invoice Choose At Creation to publish an order's invoice when it is
created.

Choose At Collection to publish an order's invoice after

payment is collected on the invoice.

The PUBLISH_INVOICE_DETAIL event must be configured

and the Send Invoice time-triggered transaction must be run
for an invoice to be published.
Collect Externally Through If checked, all the invoice details are published to an external
Accounts Receivable accounts receivable system. Any collections performed
outside of Sterling Selling and Fulfillment Foundation need
not be reported.

If unchecked, Sterling Selling and Fulfillment Foundation

handles all financial collections, provided you have
programmed the user exits to do so.

If using an external system to handle your accounts, Collect

Externally Through Accounts Receivable must be checked
and Settlement Required and Authorization Required must be
unchecked.
Merchant ID If the organization uses a third-party agency to handle
payments, enter their merchant identifier.
Deferred Credit On Return Select Deferred Credit On Return Required if an event should
Required be raised with the cancelled amount that was not refunded
when part of a pre-collected order is cancelled.

104 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 45. Payment Rule Pop-Up Window (continued)
Field Description
Allow Immediate Refund Select Allow Immediate Refund From Hold Amount if you
From Hold Amount want to instantly refund the credit amount from the
pre-collected hold amount to the customer.

Allow Immediate Refund From Hold Amount is mutually

exclusive of Deferred Credit On Return Required.
Settlement Required Select Settlement Required if payments require settlement
before they can be processed.
Ignore Payment Status For Select Ignore Payment Status For Purge if you want to purge
Purge orders regardless of the payment status of the orders.

If Settlement Required is selected, Ignore Payment Status For

Purge is disabled.
Authorization Required Select Authorization Required if payments require any type of
authorization before they can be processed.

If you select this rule, an attached Reauthorization pane is

enabled with reauthorization options.
Customer Account Select Customer Account Maintained Internally if the
Maintained Internally payment processing for an account is handled from within
Sterling Selling and Fulfillment Foundation.

This rule prevents the YFSCollectionCustomerAccountUE

user exit from being called for Authorization if the Customer
Payment Method has a limit set for it.
Reauthorization
Authorize Before Select this button if you want payment methods to be
Scheduling And authorized before scheduling an order and then reauthorized
Reauthorize On Expiration each time the previous authorization expires.

This rule is the default if Authorization Required is enabled.

Only Authorize Charge Select Only Authorize Charge Transaction Request Total to
Transaction Request Total create authorizations for charge transaction requests only. If
Charge Transaction Requests exist, the system splits
authorizations by the Charge Transaction Requests. If this
option is selected and no Charge Transaction Request exists,
the system does not authorize the order. If not selected, the
system authorizes the order total.
Authorize Before Select this button if you want authorization to take place
Scheduling and Delay before the order is scheduled and then to delay
Reauthorization Until reauthorization until the Expected Release Date/Expected
Appointment Date.

If you enter numbers in the Expected Release Date and the

Expected Appointment Date fields and the numbers differ,
reauthorization will occur on both dates.
Hours Before Expected Enter the number of hours before the Expected Release Date
Release Date For Products that you want an authorization for product items to take
place.
Hours Before Expected Enter the number of hours before Expected Appointment
Appointment Start Date Start Date that you want an authorization for provided and
For Services delivery services to take place.

Chapter 6. Configuring Cross-Application Payment Components 105

 Table 45. Payment Rule Pop-Up Window (continued)
Field Description
Delay Authorization Until Select this button if you want authorization to take place only
before the Expected Release Date/Expected Appointment
Date.
Hours Before Expected Enter the number of hours before the Expected Release Date
Release Date For Products that you want an authorization for product items to take
place.
Hours Before Expected Enter the number of hours before Expected Appointment
Appointment Start Date Start Date that you want an authorization for provided and
For Services delivery services to take place.

Results

To further explain the business impact of authorization options, Table 46, shows
that potentially, many authorizations could take place while awaiting inventory
with the standard authorization configuration. Only 1-2 authorizations take place
when delayed reauthorization is configured.
Table 46. Standard and Delayed Reauthorization
Before Order is Scheduled
Configuration Before Order is and Each Time <n> Hours
Options Scheduled Authorization Expires Before Release
Authorize Before AUTH AUTH...AUTH...AUTH... AUTH
Scheduling and
Reauthorize on
Expiration
(standard)
Authorize Before AUTH AUTH
Scheduling and
Delay
Reauthorization
Until <n> Hours
Before Ship Date
Delay Authorization AUTH
Until <n> Hours
Before Ship Date

Modifying a Payment Rule

About this task

To modify a payment rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Payment Rules. The Payment Rules window displays in the work
area.
2. Select the applicable payment rule and choose the Details icon. The Payment
Rule Details pop-up window displays.
3. Modify information in the applicable fields. Refer to Table 45 on page 104 for
field value descriptions.
4. Choose the Save icon.

106 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Deleting a Payment Rule
About this task

To delete a payment rule:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Payment Rules. The Payment Rules window displays in the work
area.
2. Select the applicable payment rule and choose the Delete icon.

Defining Payment Types

You can define common codes for payment types. Payment types are the different
methods of payment that can be used in financial transactions between
organizations, for example, credit card or check.

The default payment types of Sterling Selling and Fulfillment Foundation are:
v CHECK
v CREDIT_CARD
v CUSTOMER_ACCOUNT
v OTHER

You can use the Payment Types branch for creating, modifying, or deleting a
payment type.

Creating a Payment Type

About this task

To create a payment type:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Payment Types. The Payment Types window displays in the work
area.
2. Choose the Create New icon. The Payment Type Details pop-up window
displays.
3. Enter information in the applicable fields. Refer to Table 47 for field value
descriptions.
4. Choose the Save icon.
Table 47. Payment Type Details Pop-Up Window
Field Description
Payment Type
Payment Type Enter a name for the payment type.
Payment Type Group Select a payment type group
Description Enter a brief description of the payment type.
Charge

Chapter 6. Configuring Cross-Application Payment Components 107

 Table 47. Payment Type Details Pop-Up Window (continued)
Field Description
Charge Sequence Enter the preferred charge sequence for the payment type, 0
being highest.

When defining payment types you can set the default order
in which payment types are charged. For example, if the
Seller organization uses gift certificates and prefers to collect
against the gift certificate and then collect any remaining
amount against a credit card, you may configure a payment
type of Gift Certificate to have a charge sequence of 1 and a
payment type of Credit Card to have a charge sequence of 2.
For more information about charge sequencing, see the
Sterling Selling and Fulfillment Foundation: Product Concepts
Guide.
Charge Instead of Select this field if you want to create a charge request for this
Authorize payment type instead of an authorization request.

This flag is used to trigger the GetFundsAvailable user exit

that determines the amount of funds available in the account
when a payment type is charged during order processing. For
more information about the GetFundsAvailable user exit, see
the Sterling Selling and Fulfillment Foundation: Javadocs.
Authorization Reversal
Strategy
Do Not Reverse Select this option if you do not want to implement an
authorization reversal strategy. This is the default.
Reverse When Expired If you enable this option, a reverse authorization request is
generated when an authorization expires. This request is for
the same authorization ID, only in a negative amount. If you
have enabled automatic reversal of authorization without
enabling Payment Card Types and the specific payment
method does not support reverse authorization, Sterling
Selling and Fulfillment Foundation generates a request for
reversal, and in YFSCollectionCreditCardUE you may return
success to avoid incurring transaction fees from the payment
system.

Settlement and Authorization are required to use this feature.

This option supports any payment method that requires
authorizations, with the exception of customer accounts.
Note: This option is mutually exclusive with the "Use Same
Authorization Multiple Times" payment rule.

For further information on setting up this strategy as well as

handling differing authorization and settlement amounts
through collectionCreditCardUE implementations, refer to the
Sterling Selling and Fulfillment Foundation: Product Concepts
Guide.
Reverse Excess Select this option to reverse the excess authorization when an
authorization exceeds the order total or settlement request.
This option reverses expired authorizations and any charge
request transaction that is not usable.

108 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 47. Payment Type Details Pop-Up Window (continued)
Field Description
Partial Reversal Supported If Reverse Excess is selected, select Partial Reversal Supported
to reverse authorizations in excess of the order total by
reversing the excess authorization amount only. If Reverse
Excess is selected but Partial Reversal Supported is not
selected, the entire authorization amount is reversed and a
new authorization for the order total is submitted.
Charge Up To Available Select this field to allowing charging up to the available
amount.
Charge Consolidation Select Charge Consolidation Allowed if you want to
Allowed consolidate charge requests.

If this option is selected, when a charge transaction record is

created the collection date for the record is set to the
execution date of the authorization + the time you enter in
the Consolidation Window (hrs) field. The collection date is
the date (and time) after which the executeCollection
time-triggered transaction picks up the record(s) for
processing.

If further charging is required for a given order for the same

payment type, the existing charge transaction record is
updated instead of a new record being inserted.

This flag is only applicable to document types.

If the charge is not created from an authorization, it is not

taken into consideration for consolidation.
Support Zero Amount Select this option if you want to support zero amount
Authorization authorization for this payment type. This flag is used by the
capturePayment API.
Processing Not Required Select this option if you want to create a preprocessed Charge
Transaction record of type CHARGE for this payment type.
For example, cheque or cash.

This flag indicates that the payment type added is already

processed. This flag is used by the capturePayment API.
Consolidation Window If you selected Charge Consolidation Allowed, enter the
(Hrs) timeframe (in hours) for charges to be consolidated within.
Allow Authorizations To Select this option to allow an authorization amount to exceed
Exceed Settlement Request a settlement amount. If disabled, an authorization is not valid
if it exceeds the charge amount. This option is enabled by
default.
Hours Before Use this field to record the number of hours before
Authorization Expiration authorization for a particular credit card expires.
Hours Authorization Can Use this field to record the number of hours that
Still Be Reversed authorization for a particular credit card can still be reversed.
Refund
Valid for Return Select Valid for Return if this payment type can be credited
according to the Seller's business practices.

Chapter 6. Configuring Cross-Application Payment Components 109

 Table 47. Payment Type Details Pop-Up Window (continued)
Field Description
Refund Sequence Enter the preferred refund sequence for the payment type, 0
being highest.

When defining payment types you can set the default order
in which the Seller credits a Buyer's payment types. For
example, if the Seller organization prefers to credit a
customer's account and then a customer's credit card, you
may configure a payment type of Customer Account to have
a refund sequence of 1 and a payment type of Credit Card to
have a charge sequence of 2. For more information about
refund sequencing, see the Sterling Selling and Fulfillment
Foundation: Product Concepts Guide.
Default for Return Select Default for Return to designate this payment type as
the default type to be credited in the Return Console. If an
order does not have any payments valid for a return, the
payment type for which this is selected is used to create a
new payment record.
Refund To Same Payment Select this field to allow refunds to the same payment
Method method.
Refund To New Payment Select this field to allow refunds to a new payment method.
Method
Refund To New Payment If you selected ‘Refund To New Payment Method' above, use
Method of Payment Type this field to select a new payment type to use.

Only payment types in the STORED_VALUE_CARD or

OTHER payment type group are available.

If you select STORED_VALUE_CARD or OTHER, you can

select the same payment type and then a new payment
method of the same type. For example, if the original
payment method was a STORED_VALUE_CARD and an item
has been returned, you can issue a new gift card by entering
STORED_VALUE_CARD into this field. If you want this new
STORED_VALUE_CARD to be a tracked inventory item, enter
the Item ID in the ‘Create Refund Fulfillment Order Using
Item ID' field described below.

If you specify that you want to refund to a different payment

method, configure the refund options for the payment
method that will be used. For example, if the original
payment method was a CREDIT_CARD and you specify that
the new payment method should be a
STORED_VALUE_CARD, Sterling Selling and Fulfillment
Foundation will use the STORED_VALUE_CARD
configuration settings, not the CREDIT_CARD settings, for
the refund process.
When Refunding to a New Payment Method
Use the Following Select this option to denote that this payment type has a
Constraints refund constraint.

This allows you to issue a refund using a different payment

type if the refund amount is greater than or less than a
certain value.
If The Refund Amount is Choose 'Greater Than' or 'Less Than' from the drop-down
menu, and enter a refund amount to use as a constraint.

110 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 47. Payment Type Details Pop-Up Window (continued)
Field Description
Refund Using Payment Choose a refund payment type to use if the constraint is
Type valid.
Create Refund Fulfillment Select this option to create a refund fulfillment order instead
Order Using of creating a new payment method.
ItemID From the drop down menu select the Item ID of the item to
fulfill the refund.
UOM When you select the Item ID, the corresponding UOM is
populated.
Create Refund Payment Select this option to create a refund payment and charge
and Charge Request request when refunding to a new payment method.
Create Refund Payment Select this option to not create a refund charge request. This
and Wait for Payment also raises the Incomplete Payment Information event, if it is
Information enabled.

Modifying a Payment Type

About this task

To modify a payment type:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Payment Types. The Payment Types window displays in the work
area.
2. Select the applicable payment type and choose the Details icon. The Payment
Type Details pop-up window displays.
3. Enter information in the applicable fields. Refer to Table 47 on page 107 for
field value descriptions.
4. Choose the Save icon.

Deleting a Payment Type

About this task

To delete a payment type:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Payment Types. The Payment Types window displays in the work
area.
2. Select the applicable payment type and choose the Delete icon.

Defining Payment Card Types

Because each credit card vendor may have different authorization and payment
rules – particularly around authorization reversal – you can configure settings on
the Payment Card Type Details window for each payment card type.

Note: The settings on the Payment Card Type Details window override those on
the Payment Type Details window. For example, if you specify on the Payment
Type Details window that you want Payment Type CREDIT_CARD to “Reverse

Chapter 6. Configuring Cross-Application Payment Components 111

 Excess” authorizations, and then you configure a specific vendor's credit card on
the Payment Card Type Details window to “Do Not Reverse,” then for that credit
card type, reversal is disabled.

Creating a Payment Card Type

About this task

The Payment Card Type Details window lets you configure each payment card
type.

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Payment Card Types. The Payment Card Types window displays
in the work area.
2. Choose the Create New icon. The Payment Card Type Details pop-up window
displays.
3. Enter information in the applicable fields. Refer to Table 48 for field value
descriptions.
4. Choose the Save icon.
Table 48. Payment Card Type Details Window
Field Description
Payment Card Type
Payment Type Select the name for the payment type. These
are restricted to payment types of the
payment type group CREDIT_CARD.
Payment Card Type ID Select the type of credit card or add a new
credit card type.
Short Description Enter a short description for the payment
card type.
Long Description Enter a long description for the payment
card type.

112 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 48. Payment Card Type Details Window (continued)
Field Description
Authorization Reversal Strategy Select Do Not Reverse if you do not want to
implement an authorization reversal
strategy. This is the default.

Select Reverse When Expired if you want a

reverse authorization request to be
generated when an authorization expires.
This request is for the same authorization
ID, only in a negative amount. If you have
enabled automatic reversal of authorization
and the specific payment method does not
support reverse authorization, a request for
reversal is generated, and in
YFSCollectionCreditCardUE you may return
success to avoid incurring transaction fees
from the payment system. Settlement and
Authorization are required to use this
feature. This option supports any payment
method that requires authorizations, with
the exception of customer accounts.

Select Reverse Excess if you do not want to

use authorizations that exceed the order
total or settlement request. This option
reverses expired authorizations and any
charge request transaction that is not usable.

If you want to inherit Authorization

Reversal Strategy from the Payment Type
Details window, leave this field blank.
Partial Reversal Supported Select Yes to reverse authorizations in excess
of the order total by reversing the excess
authorization amount only.

Select No to reverse authorizations in excess

of the order total by reversing the entire
authorization amount and then submitting a
new authorization for the order total.

If you want to inherit Partial Reversal

Supported from the Payment Type Details
window, leave this field blank.
Use Same Authorization Multiple Times Select Yes if you want to allow the same
authorization for multiple transactions.

If you want to inherit Use Same

Authorization Multiple Times from the
Payment Type Details window, leave this
field blank.

Chapter 6. Configuring Cross-Application Payment Components 113

 Table 48. Payment Card Type Details Window (continued)
Field Description
Charge Consolidation Allowedk Select Yes if you want to consolidate charge
requests.

If Yes is selected, when a charge transaction

record is created the collection date for the
record is set to the execution date of the
authorization + the time you enter in the
Consolidation Window (hrs) field. The
collection date is the date (and time) after
which the executeCollection time-triggered
transaction picks up the record(s) for
processing.

If further charging is required for a given

order for the same payment type, the
existing charge transaction record is updated
instead of a new record being inserted.

Note: This flag is applicable only to Sales

Order document types.
Note: If the charge is not created from an
authorization, it is not taken into
consideration for consolidation.

If you want to inherit Charge Consolidation

Allowed from the Payment Type Details
window, leave this field blank.
Consolidation Window (Hrs) If you selected Charge Consolidation
Allowed, enter the timeframe (in hours) for
charges to be consolidated within.
Allow Authorization To Exceed Settlement Select Yes to allow an authorization amount
Request to exceed a settlement amount. If you No,
an authorization is not valid if it exceeds the
charge amount.
Note: This option is mutually exclusive with
the Reverse Excess option. If Use Same
Authorization Multiple Times and Charge
Consolidation Allowed are enabled, this
option is implicitly Y.

If you want to inherit Allow Authorization

to Exceed Settlement Request from the
Payment Type Details window, leave this
field blank.
Hours Before Authorization Expiration Use this field to record the number of hours
before authorization for a particular credit
card expires; this can be used in the
executeCollection API.
Hours Authorization Can Still Be Reversed Use this field to record the number of hours
that authorization for a particular credit card
can still be reversed; this can be used in the
executeCollection API.

114 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 48. Payment Card Type Details Window (continued)
Field Description
Charge Up To Available Select Yes to allow charging up to the
available amount.

If you want to inherit Charge Up To

Available from the Payment Type Details
window, leave this field blank.
Support Zero Amount Authorization Select Yes if you want to support zero
amount authorization for this payment type.
This flag is used by the capturePayment
API.

If you want to inherit Support Zero Amount

Authorization from the Payment Type
Details window, leave this field blank.
Processing Not Required Select Yes if you want to create a
preprocessed Charge Transaction record of
type CHARGE. For example, cheque or cash.

This flag indicates that the payment type

added is already processed. This flag is used
by the capturePayment API.

If you want to inherit Processing Not

Required from the Payment Type Details
window, leave this field blank.

Modifying a Payment Card Type

About this task

To modify a payment card type:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Payment Card Types. The Payment Card Types window displays
in the work area.
2. Select the applicable payment card type and choose the Details icon. The
Payment Card Type Details pop-up window displays.
3. Enter information in the applicable fields. Refer to Table 48 on page 112 for
field value descriptions.
4. Choose the Save icon.

Deleting a Payment Card Type

About this task

To delete a payment card type:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Payment Card Types. The Payment Card Types window displays
in the work area.
2. Select the applicable payment card type and choose the Delete icon.

Chapter 6. Configuring Cross-Application Payment Components 115

116 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 7. Configuring Cross-Application Pricing Components
Configuring Cross-Application Pricing Components
As of Sterling Selling and Fulfillment Foundation Release 9.1:
v The previous pricing functionality described in “Legacy Pricing Service” has
been deprecated.
v The current pricing functionality for the Sterling Selling and Fulfillment
Foundation is described in “Pricing Service” on page 122.
See the Business Center: Pricing Administration Guide and the Sterling Selling and
Fulfillment Foundation: Pricing Concepts Guide for information about these new
features.

Legacy Pricing Service

Note: To use this deprecated pricing functionality, you must first select the Use
Deprecated Pricing Functionality check box in the Installation Rules window. To
access this window, from the tree in the Application Platform application rules side
panel, choose System Administration > Installation Rules. The Installation Rules
window displays in the work area.

You can configure the Pricing Service that is being used throughout Sterling Selling
and Fulfillment Foundation. From the tree in the Distributed Order Management
application rules side panel, choose Cross Application > Financials.

Defining Pricing by Region

About this task

You can define the region schema the organization you are configuring uses for
product, delivery service, and provided service pricing.

For example, if you are configuring an organization that offers a delivery service
that is associated with a region schema in which they deliver to a given metro area
region and a suburb region, the organization may want to charge more for delivery
in the metro area than the suburbs. In this case you would want to associate a
region schema to configure different service pricing for the different regions.

For more information about region schemas, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To define pricing by region:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Region Usage For Pricing. The Region Usage For Pricing pop-up
window displays in the work area.
2. Enter information in the applicable fields. Refer to Table 49 on page 118 for
field value descriptions.
3. Choose the Save icon.

© Copyright IBM Corp. 1999, 2012 117

 Table 49. Region Usage For Pricing Pop-Up Window
Field Description
Schema for Product being Select the region schema you want to use for the
shipped organization's product item pricing.
Schema for Product being Select the region schema you want to use for the
delivered organization's delivery service pricing.
Schema for Provided Select the region schema you want to use for the
Service organization's provided service pricing.

Defining Price Programs and Price Lists

Note: This configuration is not required if you are using an external pricing
engine.

A price program is a way to offer different pricing to different customers at

different times. A price program may have one or more price lists. Each price list
defines pricing for a specific currency. A price program definition defines which
price list to use for specific time period.

For example, you may want to set up a special price program for your best
customers offering items at a discounted price if they order before Christmas. You
can create two price lists; "Before" and "After". "Before" lists each item's discounted
price before Christmas. "After" lists the item's regular price after Christmas. You
can then create a price program to specify that between now and December 25,
orders in that price program are calculated using "Before" and after December 25,
using "After".

If a customer orders an item that is part of the price program, but falls outside of
the specified date range, quantity range, or currency, the price is calculated as zero.
In this case, the CSR must manually enter the price.

Note: An organization that is defined as an enterprise cannot inherit price

programs from its 'Inherit Configuration from' organization.

Note: You must select Allow Price Calculation For Draft Orders to apply pricing
during draft order creation for the order document. You must select Allow Price
Calculation For Confirmed Orders, if you want to apply pricing during both draft
order confirmation and order creation. For more information about this parameter,
see the Sterling Selling and Fulfillment Foundation: Configuration Guide.

Creating a Price List

About this task

To create a price list:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Price Lists. The Price Lists window displays in the work area.
2. Choose the Create New icon. The Price List Details window displays.
3. Enter information in the applicable fields. Refer to Table 50 on page 119 for
field values.
4. Choose the Save icon.

118 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 50. Price List Details Window
Field Description
Price List Name Enter the name of the price list.
Currency Select the currency that applies to the items in the price list.
Description Enter a brief description of the price list.
Valid Until Enter the date the price list is valid until.
Active Select Active if you want the price list to be active in the
system.
Product Price List Select Product Price List if you want to create a price list for
product items.
Delivery Service Price List Select Delivery Service Price List if you want to create a price
list for delivery services.
Provided Service Price List Select Provided Service Price List if you want to create a price
list for provided services.

Adding Items to a Price List:

About this task

To add items to a price list:

Procedure
1. In the Price List Details window, choose the Create New icon from the Item
Level Pricing list. The Price List: Item Details window displays.
2. Enter information in the applicable fields. Refer to Table 51 for field value
descriptions.
3. Choose the Save icon.

Modifying an Item Price List:

About this task
Table 51. Price List: Item Details Window
Field Description
Item ID Enter the item ID for the item you are adding to the price list.
UOM Select a unit of measure for the item.
Product Class Select the product class the item falls under.
List Price Enter the price the item is listed for.
Retail Price Enter the price the item is sold for.
Unit Price By Quantity Once the item is created choose the Create New icon to add
Range item price set details.

Choose the Details icon to modify a detail.

Choose the Delete icon to delete a detail.

Chapter 7. Configuring Cross-Application Pricing Components 119

 Table 51. Price List: Item Details Window (continued)
Field Description
Region Enter the region that the item pricing is applicable to.

For example, if you adding a delivery service item that

delivers to both a metro region and a suburb region, but
charges for delivery to the metro regions, you would create
two records: one specifying the metro region and its pricing
and one for the suburb region.
Note: This field is optional. If left blank, the quantity pricing
range works for any region.
Note: The region specified here must be part of the region
schema associated with the item you are creating. For more
information about associating a region schema for pricing, see
“Defining Pricing by Region” on page 117.
From Quantity Enter the beginning amount for quantity pricing.
To Quantity Enter the end amount for a price range based on purchase of
a particular number of items.
Unit Price Enter the cost per item for that start and end quantity.

To modify an item price list:

Procedure
1. In the Price List Details window select the applicable item and choose the
Details icon from the Item Level Pricing list. The Item Price Set Details window
displays.
2. Enter information in the applicable fields. Refer to Table 51 on page 119 for
field value descriptions.
3. Choose the Save icon.

Deleting an Item Price List:

About this task

To delete an item price list, in the Price List Details window, select the applicable
item and choose the Delete icon.

Modifying a Price List

About this task

To modify a price list:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose Cross Application >
Financials > Price Lists. The Price Lists window displays in the work area.
3. Select the applicable price list and choose the Details icon. The Price Set Details
window displays.
4. In Description, enter a brief description of the price list.
5. Choose the Save icon.

120 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Deleting a Price List
About this task

To delete a price list:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose Cross Application >
Financials > Price Lists. The Price Lists window displays in the work area.
3. Select the applicable price list and choose the Delete icon.

Creating a Price Program

About this task

To create a price program:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose Cross Application >
Financials > Price Programs. The Price Programs window displays in the work
area.
3. Choose the Create New icon. The Price Program Details window displays.
4. In Price Program Name, enter the name of the price program.
5. In Description, enter a brief description of the price program.
6. Choose the Save icon.

Adding a New Price List to a Price Program:

About this task

To add a new price list to a price program:

Procedure
1. In the Price Program Details window, choose the Create New icon from the
Price Program Definitions list. The Price Program Definition pop-up window
displays.
2. From Price List, select the price list you want to add to the price program.
3. From Currency, select the currency the price list is in.
4. In Start Date, enter the date that the pricing for the items in the price program
begins.
5. In End Date, enter the date that the pricing for the items in the price program
ends.
6. Choose the Save icon.

Deleting a Price List in a Price Program:

About this task

To delete a price list in a price program, from the Price Program Details window,
select the applicable price list and choose the Delete icon.

Chapter 7. Configuring Cross-Application Pricing Components 121

 Modifying a Price Program
About this task

To modify a price program:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Price Programs. The Price Programs window displays in the work
area.
2. Select the applicable Price Program and choose the Details icon. The Price
Program Details window displays.
3. In Description, enter a brief description of the price program.
4. Choose the Save icon.

Deleting a Price Program

About this task

To delete a price program:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Price Programs. The Price Programs window displays in the work
area.
2. Select the applicable Price Program and choose the Delete icon.

Pricing Service
You can configure the Pricing Service that is being used throughout Sterling Selling
and Fulfillment Foundation. From the tree in the Distributed Order Management
application rules side panel, choose Cross Application > Financials.

For information about how to configure prices, see Business Center: Pricing
Administration Guide.

Defining Region Schema for Selling

You can define the region schema the organization you are configuring uses for
selling.

For information about defining region schemas for selling, see “Defining Region
Usage for Selling” on page 127.

Defining Pricing Organization Rules

About this task

This section describes the rules or configurations that are defined by the pricing
organization. These rules affect how the pricing engine calculates prices. In
addition, this section describes the rules that affect the Pricing Administration user
interface.

To define pricing organization rules:

122 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Pricing Organization Rules. The Pricing Organization Rules: Sales
Order window displays.
2. Enter information in the applicable fields. Refer to Table 52 for field value
descriptions.
3. Choose the Save icon.
Table 52. Pricing Organization Rules: Sales Order Window
Field Description
Run promotions pricing rules (Item Select this check box if you want to run item
quantity rule) in getItemPrice API quantity pricing rules during the getItemPrice API
call. The item quantity pricing rules are applied if
defined to give additional discounts or uplifts to
the price of an item.
Distribute non-uniform item Select this check box if you want to evenly
adjustment across the lines of the same distribute item-level pricing rule or coupon
item adjustments across order lines that contain the
same item.
Unit price precision Calculated prices are rounded to a fixed number
of decimal places.

Enter the number of decimal places to be applied

to unit prices. By default, unit price precision is
six decimal places.

Sterling Distributed Order Management supports

a maximum of six decimal places.
Total price precision Calculated prices are rounded to a fixed number
of decimal places.

Enter the number of decimal places to be applied

to total prices. By default, total price precision is
two decimal places.

Sterling Distributed Order Management supports

a maximum of two decimal places.
Rules For IBM Sterling Business Center Application
Maintain Absolute Adjustment Select this check box if you want to display the
Adjustment (+/-) field in the Pricing
Administration user interface. When this field is
displayed, you can apply absolute adjustments to
the list price of items.
Maintain Percent Adjustment Select this check box if you want to display the
Adjustment % (+/-) field in the Pricing
Administration user interface. When this field is
displayed, you can apply percentage adjustments
to the list price of items.
Maintain Effective Dates On Price List Select this check box if you want to display the
Lines Effective Date field in the Pricing Administration
user interface. When this field is displayed, you
can create or change the effective dates of a price
list.
Maintain Quantity Tiers On Price List Select this check box if you want the ability to
Lines create or modify quantity tiers in the Pricing
Administration user interface.

Chapter 7. Configuring Cross-Application Pricing Components 123

 Table 52. Pricing Organization Rules: Sales Order Window (continued)
Field Description
Hide Item Unit Of Measure Select this check box if you want to hide the
UOM field in the Pricing Administration user
interface.

Note: If the UOM field is displayed, the data is

not editable.
Charge Category For Pricing Rules

To search for a charge category, choose the Search icon.

Charge Category To Be Used For Applying Surcharge For Each Pricing Rule Type
Charge Category For Combination Select the charge category to use for applying
surcharges for the Combination pricing rule.
Charge Category For Item Quantity Select the charge category to use for applying
surcharges for the Item Quantity pricing rule.
Charge Category For Order Total Select the charge category to use for applying
surcharges for the Order Total pricing rule.
Charge Category For Ship Order Total Select the charge category to use for applying
surcharges for the Ship Order Total pricing rule.
Charge Category For Shipping Select the charge category to use for applying
Surcharge surcharges for the Shipping Surcharge pricing
rule.
Charge Category To Be Used For Applying Discount For Each Pricing Rule Type
Charge Category For Combination Select the charge category to use for applying
discounts for the Combination pricing rule.
Charge Category For Item Quantity Select the charge category to use for applying
discounts for the Item Quantity pricing rule.
Charge Category For Order Total Select the charge category to use for applying
discounts for the Order Total pricing rule.
Charge Category For Ship Order Total Select the charge category to use for applying
discounts for the Ship Order Total pricing rule.
Charge Category For Shipping Select the charge category to use for applying
Surcharge discounts for the Shipping Surcharge pricing rule.
Charge Category To Be Used For Applying Discount Coupon For Each Pricing Rule Type
Charge Category For Combination Select the charge category to use for applying
discount coupons for the Combination pricing
rule.
Charge Category For Ship Order Total Select the charge category to use for applying
discount coupons for the Ship Order Total pricing
rule.
Charge Category For Order Total Select the charge category to use for applying
discount coupons for the Order Total pricing rule.
Charge Category For Item Quantity Select the charge category to use for applying
discount coupons for the Item Quantity pricing
rule.

124 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Defining Pricing Enterprise Rules
About this task

This section describes the rules that are defined by the enterprise of the pricing
organization. These rules control the behavior of the price list selection based on
assignments.

To define pricing enterprise rules:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Financials > Pricing Enterprise Rules. The Pricing Enterprise Rules window
displays.
2. Enter information in the applicable fields. Refer to Table 53 for field value
descriptions.
3. Choose the Save icon.
Table 53. Pricing Enterprise Rules Window
Field Description
Use The Price List Select this check box if you want to use the price list directly
Assigned To The Closest assigned to the customer or, if this price list is not available,
Customer In The Hierarchy use the price list assigned to the closest customer in the
customer hierarchy.

If you do not select this check box, all price lists in the
customer hierarchy that are shared with the child customers
are used.
Use The Price List Select this check box if you want to use the price list assigned
Assigned To The Exact Or to the exact region or, if this price list is not available, use the
Closest Region In The price list assigned to the closest region in the region
Region Hierarchy hierarchy.

If you do not select this check box, all price lists in the region
hierarchy are used.
Exclude Attribute Select this check box if you want to use the price list assigned
Assignments Of A Price to a customer, if it exists, rather than the price list assigned to
List If Direct Assignments customer attributes.
Exist
If you do not select this check box, both the price list
assigned to the customer and the price list assigned to
customer attributes are used.

Chapter 7. Configuring Cross-Application Pricing Components 125

126 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 8. Configuring Cross-Application Customer
Components
Configuring Cross-Application Customer Components
You can define the customers that buy from an organization, and attributes about
them such as their classification, primary information, and service preferences.

Defining Region Usage for Selling

About this task

You can define the region schema the organization you are configuring uses for
selling.

For example, if you are configuring an organization that offers a product that is
associated with a region schema in a given metro area region and a suburb region,
the organization may want to charge more for the product in the metro area than
in the suburbs. In this case, you would want to associate a region schema to
configure different product pricing for the different regions.

Similarly, you can use region schemas to define different entitlements for different
regions. For example, you can define a region schema that restricts users in
Massachusetts from being able to view and purchase firearms online.

For more information about region schemas, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To define a region usage for selling:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Customer > Region Usage For Selling.

Note: If you are using the deprecated pricing functionality, from the tree in the
application rules side panel, choose Cross Application > Financials > Region
Usage For Pricing. For additional information, see “Defining Pricing by Region”
on page 117.
The Region Usage For Selling pop-up window displays in the work area.
2. Select a region schema from the drop-down list. Refer to Table 54 for the field
value description.
Table 54. Region Usage for Selling Pop-Up Window
Field Description
Schema for Selling Select the name of the region schema to use for determining
selling regions.

3. Choose the Details icon to view the details of the selected region schema. The
Region Schema Details pop-up window displays.
4. Enter information in the applicable fields. Refer to Table 55 on page 128 for
field value descriptions.

© Copyright IBM Corp. 1999, 2012 127

 5. Choose the Save icon.
Table 55. Region Schema Details Pop-Up Window
Field Description
Region Schema Name Enter the name of the region schema.
Country/Region Enter a country or region code.

To search for a country or region code, choose the Search

icon. In the Search pop-up window, enter applicable search
criteria and choose the Search icon. The search results are
displayed in the Country/Region Codes panel. Select a
country or region code and click Select.
Description Enter a brief description of the region schema.

Defining Customer Classifications

Configuring Customer Classification Codes
You can configure the customer classification codes to associate with a customer
identification master. For more information about creating a customer identification
master, refer to the section entitled "Defining Customer Definitions".

You can use the Customer Classification branch for creating, modifying, and
deleting customer classifications.

Creating a Customer Classification

About this task

To create a customer classification:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Customer > Customer Rules. The Customer Rules window displays in the work
area.
2. Click the Customer Classification tab.
3. Click the Create New icon. The Customer Classification Code Details pop-up
window displays.
4. In Customer Classification Code, enter the classification ID code.
5. In Short Description, enter a brief description of the classification ID code.
6. In Long Description, enter a more detailed description of the classification ID
code.
7. Click the Save icon.

Modifying a Customer Classification

About this task

To modify a customer classification:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Customer > Customer Rules. The Customer Rules window displays in the work
area.
2. Click the Customer Classification tab.

128 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 3. Select the applicable customer classification code and click the Details icon. The
Customer Classification Code Details pop-up window displays.
4. In Short Description, enter a brief description of the classification ID code.
5. In Long Description, enter a more detailed description of the classification ID
code.
6. Click the Save icon.

Deleting a Customer Classification

About this task

To delete a customer classification:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Customer > Customer Rules. The Customer Rules window displays in the work
area.
2. Click the Customer Classification tab.
3. Select the applicable customer classification code and click the Delete icon.

Defining Additional Customer Rules

About this task

To define additional customer rules:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Customer > Customer Rules. The Customer Rules window displays in the work
area.
2. Click the Other Rules tab.
3. In the Service Slot Group Used By Customer For Slot Preferences field, select
from the drop-down list the identifier of the service slot group that is used to
define customer preferences.
4. If you want specific users (or members of a team) to manage the relationship
with certain customers, select the Manual User To Customer Assignment Is
Required check box. This provides the assigned user with access to all of this
customer's orders and related information.
5. When you select the Use Parent Customer For Default Address And Payment
check box, and if the customer does not have default address or payment
information set, the parent customer's default address or payment information
will be used for defaulting on the order.
6. Select the Get Customer Grade Information From Sterling Business Intelligence
check box to source customer grades from Sterling Business IntelligenceTM.

Note: If this check box is selected, ensure that Sterling Business Intelligence is
installed and integrated with Sterling Selling and Fulfillment Foundation. If
either the installation or integration is incomplete, an error message is
displayed. For information about installing Sterling Business Intelligence, refer
to Sterling Business IntelligenceTM: Installation Guide. For information about
integrating Sterling Business Intelligence with Sterling Selling and Fulfillment
Foundation, refer to Sterling Business IntelligenceTM: Implementation Guide.
If the Get Customer Grade Information From Sterling Business Intelligence
check box is not selected, customer grades, if available, are sourced from an

Chapter 8. Configuring Cross-Application Customer Components 129

 external Business Intelligence system and stored in the
YFS_CUSTOMER_ANALYTICS table. For additional information about the
YFS_CUSTOMER_ANALYTICS table, refer to the Sterling Selling and Fulfillment
Foundation: Javadocs.

Note: A user exit is provided that enables customers to override this

configuration and implement their own custom logic for computing and
sourcing customer grades. For additional information about the user exit,
YSCGetAdditionalCustomerInformationUE, refer to the Sterling Selling and
Fulfillment Foundation: Javadocs.
7. In the Default User Group For Customer Users field, select from the drop-down
list the user group to be associated with customer users.
8. Click the Save icon.

Defining Customer Definitions

You can configure customer definitions that establish a relationship between an
organization and its Buyers. When creating a customer definition, you associate an
existing Buyer organization with a specific customer ID and classification. The
customer identification uniquely identifies the Buyer organization in instances
where multiple ERP systems download Buyer information in to Sterling Selling
and Fulfillment Foundation.

Creating a Customer Definition

About this task

To create a customer definition:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Customer > Customer Definitions. The Customer Search window displays in
the work area.
2. Choose the Create New icon. The Customer pop-up window displays.
3. Enter information into the applicable fields. Refer to the following table for
field value descriptions.
Table 56. Create Customer Window
Field Description
This Customer Is a Business Select this if the customer with whom you
trade participates as a company (as in a B2B
scenario). If you choose this option, see
Business Customer Details in this table for
further information specific to this scenario.
This Customer Is a Consumer Select this if the customer with whom you
trade participates as an individual (as in a
B2C scenario). If you choose this option, see
Business Customer Details in this table for
further information specific to this scenario.
Customer ID Enter the unique Identifier.
Customer Classification Select the classification, if applicable.
Business Customer Details

130 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 56. Create Customer Window (continued)
Field Description
Select Existing Organization Choose this and select the applicable Buyer
if you want to associate the customer ID
with an existing Buyer organization.
Create A New Organization Choose this if you want to create a new
organization to associate with the customer.
Organization Code If you chose Create Buyer Organization,
enter the Buyer's organization code.
Organization Name When creating a new organization, enter the
Buyer's organization name.
This Organization Is Also a Ship To When creating a new organization, choose
this if the organization also functions as a
receiving node.
DUNS Number If you chose Create Buyer Organization,
enter the Buyer's DUNS number.
Account Number With Hub If you chose Create Buyer Organization,
enter the Buyer's account number with the
Hub organization.
Locale If you chose Create Buyer Organization,
select the Buyer's locale.
Identifies This Enterprise As Enter the customer assigned Vendor
Identifier with which the customer identifies
this Enterprise.
Send Functional Acknowledgement Check this box if a functional
acknowledgement must be sent to the
customer.
Functional Acknowledgement Time (Hrs) Enter the number of hour taken by the
supplier to send the functional
acknowledgement.
Send Commitment Check this box if a commitment must be
sent to the customer.
Commitment Time (Hrs) Enter the number of hours taken by the
supplier to send the commitment.
Send ASN Check this box if an Advanced Shipment
Notice (ASN) must be sent to the customer.
Consumer Address Details
Address Enter the consumer's name and shipping
address.
Contact Info Enter the consumer's telephone, cell phone,
fax number, and e-mail address.

4. Choose the Save icon.

Modifying a Customer Definition

About this task

To modify a customer definition:

Chapter 8. Configuring Cross-Application Customer Components 131

 Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Customer > Customer Definitions. The Customer Search window displays in
the work area.
2. Enter applicable search criteria and choose the Search icon. A list of customers
displays.
3. Locate the applicable customer and choose the Modify icon. The Customer
window displays.

Defining the Customer's Primary Information

The information displayed on the Primary Information tab depends on what type
of customer has been defined.

If the Customer Is a Consumer:

About this task

If the customer is a consumer, a consumer address panel displays. Click the

Details icon to edit the consumer's address.

A customer that is a consumer may have as many ship to addresses as it wants to

define. A child customer in Sterling Selling and Fulfillment Foundation is defined
as a node organization. Therefore, you can use the Child Customers panel to add,
modify, or delete organizations to which products can alternatively be shipped.
Use the Create New icon to define a new one, the Details icon to modify an
existing one, or the Delete icon to delete an existing one.

If the Customer Is a Business: If the customer is a business, an organization field

displays, as well as a Ship To inner panel. You can click the Details icon to edit the
organization details. For more information about configuring organizations, see the
Sterling Selling and Fulfillment Foundation: Configuration Guide.

A business customer may have as many ship to addresses as it may wish to define.
A Ship To address in Sterling Selling and Fulfillment Foundation is defined as a
node organization. Therefore, you can use the Ship To panel to add, modify or
delete organizations to which products can alternatively be shipped. Use the
Create New icon to define a new one, the Details icon to modify an existing one,
or the Delete icon to delete an existing one.

While creating additional ship to addresses, you may want to specify an

organization that is an independent buyer. When a customer is not a buyer
organization, it cannot have multiple ship to addresses. Therefore, in the create
window that pops up through the Ship To inner panel, the
This Organization Is Also a Ship To

radio button is replaced with a This Organization Is Also A Buyer radio button.

Defining Customer Service Preferences

Customers defined in Sterling Selling and Fulfillment Foundation can specify slot
preferences for deliveries in the Service Preferences window.

Refer to the following table for field value descriptions:

132 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 57. Delivery Preferences
Field Description
Consider Supplemental Capacity While Check this if you want to consider
Planning Appointment By Default supplemental capacity by default when
planning an appointment for this customer.
When Appointments Are Planned For This
Customer
Any Slot Can Be Used Check this if any slot can be used when
planning an appointment for this customer.
The Slot Preferences table is hidden then.
Specific Slots Must Be Used Check this if only the slots specified in the
Slot Preferences table can be used when
planning an appointment for this customer.
Customer Prefers Specific Slots (Other Check this if the slots specified in the Slot
Slots Can Be Used) Preferences table preferred slot table.
Slot Preferences
Slot The name of the slot.
Start Time The start time of the slot, in 24 hour format.
End Time The end time of the slot, in 24 hour format.
Sun Check this if you want this slot to be part of
the customer's preferred slots.
Mon Check this if you want this slot to be part of
the customer's preferred slots.
Tue Check this if you want this slot to be part of
the customer's preferred slots.
Wed Check this if you want this slot to be part of
the customer's preferred slots.
Thu Check this if you want this slot to be part of
the customer's preferred slots.
Fri Check this if you want this slot to be part of
the customer's preferred slots.
Sat Check this if you want this slot to be part of
the customer's preferred slots.

Answering Customer Address Questions

About this task

Answering address questions for a customer populates answers for address

questions the next time this customer places an order.

Procedure

From the Service Preferences tab, select the Address Questions tab. If configured,
the address questions configured for the Enterprise appear.

Defining Customer Scheduling Constraints

You can define scheduling constraints for a specific customer by specifying these
scheduling preferences. Constraints passed at the order level override customer
scheduling preferences.

Chapter 8. Configuring Cross-Application Customer Components 133

 Refer to the following table for field value descriptions:
Table 58. Customer Scheduling Constraints
Field Description
Constraints
Ship from Single Node Check this box to ensure that orders are
shipped from a single node. this
automatically checks the Line Ship from
Single Node checkbox.
Line Ship from Single Node Check this box to ensure that order lines are
shipped from a single node. This is disabled
if the Ship from Single Node checkbox is
checked.
Ship Complete Check this box to ensure that order are
shipped complete. This automatically checks
the Line Ship complete checkbox.
Line Ship Complete Check this box to ensure that order lines are
shipped complete. This is disabled fit he
Ship Complete checkbox is checked.
Inventory Controls
Cancel Order for Inventory Shortage Check this box to cancel the backordered
quantity in the event of inventory shortage.
Allow item Substitution If Inventory Is Check this box to allow item substitution if
Not Available inventory for the selected item is not
available.
Sourcing Controls
Allow Scheduling Against The Node That Check this box to allow scheduling against
Requires Drop Ship Chained Order the node that requires a drop-shipped
Creation chained order to be created.

Defining Multiple Contacts for Each Customer

You can define multiple contacts for each customer. These contacts represent
individuals at a customer location. Refer to the following table for more
information.
Field Definition
Customer Contact ID
The ID of the customer contact.
Last Name
The contact's last name.
First Name
The contact's first name.
Email Address
The contact's e-mail address.
User ID
The user ID of the contact.
Spending Limit
The contact's spending limit, if defined.

Defining Customer Contact Information:

134 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
About this task

To define customer contact information:

Procedure
1. From the Customer Definition screen, select the Contacts tab. The Customer
Contact Info screen displays.
2. Choose the Create New icon to add an additional customer contact.
3. Select the Customer Contact Info tab.
4. Enter information in the applicable fields. Refer to the following table for field
values.
Table 59. Customer Contact Information
Field Description
Name
First Name Enter the contact's first name.
Middle Name Enter the contact's middle name.
Last Name Enter the contact's last name.
Company Enter the company at which the contact
works.
Phone
Day time Phone Enter the contact's day time phone number.
Evening Phone Enter the contact's event phone number.
Cell Phone Enter the contact's cellular phone number.
Fax Enter the contact's fax number.
Email Enter the contact's fax number.
User ID Enter the contact's user ID.
Date of Birth Enter the contact's date of birth.
Spouse Date of Birth Enter the contact's spouse's date of birth.
Wedding Anniversary Enter the contact's wedding anniversary.
Customer Contact ID Enter the contact's customer contact ID.

5. Choose OK.

Defining Limits for Customer Contacts:

About this task

To define limits for customer contacts:

Procedure
1. From the Customer Definition screen, select the Contacts tab. The Customer
Contact Info screen displays.
2. Choose the Create New icon to add an additional customer contact.
3. Select the Limits tab.
4. Enter information in the applicable fields. Refer to the following table for field
value descriptions:

Chapter 8. Configuring Cross-Application Customer Components 135

 Table 60. Limits for Customer Contacts
Field Description
Approval
Spending Limit Enter the spending limit for the customer
contact. Choose the currency in which the
spending limit is configured from the
drop-down list. To create a new currency,
choose and enter information about the
applicable fields.
Approver User ID Enter the user ID of the primary approver.
Approver Proxy Enter the proxy for the approver.

5. Choose OK.

Defining Additional Contact Addresses:

Procedure
1. From the Customer Definition screen, select the Contacts tab. The Customer
Contact Info screen displays.
2. Choose the Create New icon to add an additional customer contact
information. The Customer Contact Info screen displays.
3. Select the Additional Addresses tab.
4. Refer to Step 2 in the section entitled "Defining Additional Addresses" for
information about defining additional addresses.

Defining Additional Addresses for a Customer

About this task

You can define multiple additional or alternative addresses for a customer or

contact. Refer to the following table for field value descriptions.
Field Description
Additional Address ID
The ID of the additional address.
Is Ship To
This field appears checked if the address is configured as a ship to address.
Is Default Ship To
This field appears checked if the address is configured as the default ship
to address.
Is Bill To
This field appears checked if the address is configured as a bill to address.
Is Default Bill To
This field appears checked if the address is configured as the default bill to
address.

To define an additional address:

Procedure
1. From the Customer Definition screen, select the Additional Address tab. The
Additional address screen displays.
2. Choose the Create New icon to add an additional address.

136 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 3. Enter information in the applicable fields. Refer to the following table for field
values.
Field Description
Additional Address ID
Enter an ID for the additional address
Is Bill To
Check this box if this is a bill to address.
Is Default Bill To
Check this box if this is the default bill to address.
Is Ship To
Check this box if this is a ship to address.
Is Default Ship To
Check this box if this is the default ship to address.
Is Sold To
Check this box if this is a sold to address.
Is Default Sold To
Check this box if this is the default sold to address.
4. Choose the Details icon to enter the additional address.
5. Choose OK.

Deleting a Customer Definition

About this task

To delete a customer definition:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Customer > Customer Definitions. The Customer Search window displays in
the work area.
2. Enter applicable search criteria and choose the Search icon. A list of customers
displays.
3. Locate the applicable customer and choose the Delete icon.

Defining Contact Types

You can configure the contact types of both business and consumer customers
when specifying the contact information of a customer on work order notes. For
more information about creating a customer, refer to the section entitled "Defining
Customer Definitions".

You can use the Contact Types branch for creating, modifying, or deleting a
customer contact type.

Creating a Customer Contact Type

About this task

To create a contact type:

Chapter 8. Configuring Cross-Application Customer Components 137

 Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Customer > Contact Types. The Customer Contact Types window displays in
the work area.
2. Click the Create New icon. The Contact Type Details pop-up window displays.
3. In Contact Type, enter the contact type.
4. In Short Description, enter a brief description of the contact type.
5. In Long Description, enter a more detailed description of the contact type.
6. Click the Save icon.

Modifying a Customer Contact Type

About this task

To modify a contact type:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Customer > Contact Types. The Customer Contact Types window displays in
the work area.
2. Select the applicable contact type and click the Details icon. The Contact Type
Details pop-up window displays.
3. In Short Description, enter a brief description of the contact type.
4. In Long Description, enter a more detailed description of the contact type.
5. Click the Save icon.

Deleting a Customer Contact Type

About this task

To delete a contact type:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Customer > Contact Types. The Contact Types window displays in the work
area.
2. Select the contact type and click the Delete icon.

Defining Customer Entitlements

About this task

You can define a customer entitlement strategy for the enterprise by specifying
rules for enforcing customer entitlements.

To define a customer entitlement strategy:

Procedure
1. From the tree in the application rules side panel, choose Cross Application >
Customer > Customer Entitlement. The Customer Entitlement window displays
in the work area.

138 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 2. In the Enforce Customer Entitlement Based On field, select from the drop-down
list the customer entitlement strategy that is used for the enterprise. Refer to
the following table for field value descriptions.
3. If you want to use direct entitlement assignments, select the Use Direct
Entitlement Assignment, If Exists check box.
4. Click the Save icon.
Table 61. Customer Entitlement Strategy
Field Description
Enforce Customer Entitlement Based On Select the type of customer entitlement
strategy you want to use for enforcing
customer entitlements:

You can choose from the following options:

v No Item Entitlement - Customers can
access all items regardless of customer
entitlements and pricelists.
v Item Entitlement Rules Assigned to
Customer - Customers can access only the
items that are assigned to the customer in
customer entitlements.
v Pricelists Assigned to Customer -
Customers can access only the items that
are assigned to the customer in pricelists.
v Intersection of Item Entitlement Rules and
Pricelists Assigned to Customer -
Customers can access only the items that
are assigned to the customer in both
pricelists and customer entitlements.

Defining Customer Grades

About this task

You can define customer grades that, when assigned to customers, enable you to
offer a higher discount to a customer with an excellent rating and a smaller or no
discount to a customer with a lower rating.

Note: Sterling Selling and Fulfillment Foundation does not validate whether
customer grade configurations cover the entire range of customer ratings in
Sterling Business Intelligence.

To define customer grades:

Procedure
1. From the tree in the application rules side panel, choose
Cross Application > Customer > Business Intelligence > Customer Grades. The
Customer Grades window displays in the work area.
2. Enter information in the applicable fields. For field value descriptions, refer to
Table 62 on page 140.

Chapter 8. Configuring Cross-Application Customer Components 139

 Table 62. Customer Grades Window
Field Description
Grade Code Enter a grade code for the customer. For example, you could
enter A for an excellent customer or B for an average customer.
Description Enter a description of the grade code. For example, you could
enter Excellent or Average.
Minimum Rating Enter the minimum rating value for the grade.
Note: Ensure that the ratings for different grades do not overlap
with each other. If the customer ratings do overlap, an error
message is displayed.
Maximum Rating Enter the maximum rating value for the grade.
Note: Ensure that the ratings for different grades do not overlap
with each other. If the customer ratings do overlap, an error
message is displayed.

3. Click the Save icon.

140 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 9. Configuring a Document's Attributes
Configuring a Document's Attributes
You can define common codes as they pertain to order documents viewed in the
Application Consoles.

You can use the Order Attributes branch to:

v Define order types
v Define order sources
v Define external references for the order level
v Define external references for the order line level
v Define order address types
v Define line types
v Define other attributes

Defining Order Types

About this task

You can define codes for order types that appear on a document type. This code
has no application logic associated with it and can be set up as per your business
practices. Examples of order types are Consumer Orders, Service Rep Orders, and
Retail Orders.

You can use the Order Types tab for creating, modifying, and deleting an order
type.

Creating an Order Type

About this task

To create an order type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order Types tab.
3. Choose the Create New icon. The Order Type Details pop-up window displays.
4. In Order Type, enter the name of the order type.
5. In Short Description, enter a brief description of the order type.
6. In Long Description, enter a more detailed description of the order type.
7. Choose the Save icon.

Modifying an Order Type

About this task

To modify a order type:

© Copyright IBM Corp. 1999, 2012 141

 Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order Types tab.
3. Select the applicable order type and choose the Details icon. The Order Type
Details pop-up window displays.
4. In Short Description, enter a brief description of the order type.
5. In Long Description, enter a more detailed description of the order type.
6. Choose the Save icon.

Deleting an Order Type

About this task

To delete a order type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order Types tab.
3. Select the applicable order type and choose the Delete icon.

Defining Order Sources

You can define codes for order sources that appear on a document type. This code
has no application logic associated with it and can be set up as per your business
practices.

You can use the Order Sources tab for creating, modifying, or deleting an order
source.

Creating an Order Source

About this task
To create an order source:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order Sources tab.
3. Choose the Create New icon. The Order Source Details pop-up window
displays.
4. In Order Source, enter the name of the order source.
5. In Short Description, enter a brief description of the order source.
6. In Long Description, enter a more detailed description of the order source.
7. Choose the Save icon.

142 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Modifying an Order Source
About this task

To modify a order source:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order Sources tab.
3. Select the applicable order source and choose the Details icon. The Order
Source Details pop-up window displays.
4. In Short Description, enter a brief description of the order source.
5. In Long Description, enter a more detailed description of the order source.
6. Choose the Save icon.

Deleting an Order Source

About this task

To delete a order source:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order Sources tab.
3. Select the applicable order source and choose the Delete icon.

Defining External References for the Order Level

You can define codes for external references that appear on a document type at the
order level. This code has no application logic associated with it and can be set up
as per your business practices. You can create, modify, and delete external
references.

You can use the Order References tab to create, modify, or delete an external
reference for the order header level.

Creating an External Reference for the Order Header Level

About this task

To create an order reference for the order level:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order References tab.
3. From the Order Header External References list choose the Create New icon.
The External Reference Details pop-up window displays.
4. In External Reference, enter the name of the external reference.

Chapter 9. Configuring a Document's Attributes 143

 5. In Short Description, enter a brief description of the external reference.
6. In Long Description, enter a more detailed description of the external reference.
7. Choose the Save icon.

Modifying an External Reference for the Order Header Level

About this task

To modify an external reference for the order level:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order References tab.
3. In Order Header External References select the applicable external reference
and choose the Details icon. The External Reference Details pop-up window
displays.
4. In Short Description, enter a brief description of the external reference.
5. In Long Description, enter a more detailed description of the external reference.
6. Choose the Save icon.

Deleting an External Reference for the Order Header Level

About this task

To delete an external reference for the order level:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order References tab.
3. In Order Header External References select the applicable external reference
and choose the Delete icon.

Defining External References for the Order Line Level

You can define codes for external references that appear on a document type at the
order line level. This code has no application logic associated with it and can be set
up as per your business practices. You can create, modify, and delete external
references.

You can use the Order References tab to create, modify, or delete an external
reference for the order line level.

Creating an External Reference for the Order Line Level

About this task

To create an order reference for the order line level:

144 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order References tab.
3. From the Order Line External References list choose the Create New icon. The
External Reference Details pop-up window displays.
4. In External Reference, enter the name of the external reference.
5. In Short Description, enter a brief description of the external reference.
6. In Long Description, enter a more detailed description of the external reference.
7. Choose the Save icon.

Modifying an External Reference for the Order Line Level

About this task

To modify an external reference for the order line level:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order References tab.
3. In Order Line External References select the applicable external reference and
choose the Details icon. The External Reference Details pop-up window
displays.
4. In Short Description, enter a brief description of the external reference.
5. In Long Description, enter a more detailed description of the external reference.
6. Choose the Save icon.

Deleting an External Reference for the Order Line Level

About this task

To delete an external reference for the order level:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order References tab.
3. In the Order Line External References list select the applicable external
reference and choose the Delete icon.

Defining Order Address Types

You can define codes for order address types that appear in the Additional
Addresses view in the User Interface for a document type.

You can use the Order Address Types tab to create, modify, or delete an order
address type.

Chapter 9. Configuring a Document's Attributes 145

 Creating an Order Address Type
About this task

To create an order address type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order Address Types tab.
3. Choose the Create New icon. The Order Address Type Details pop-up window
displays.
4. In Order Address Type, enter the name of the order address type.
5. In Short Description, enter a brief description of the order address type.
6. In Long Description, enter a more detailed description of the order address
type.
7. Choose the Save icon.

Modifying an Order Address Type

About this task

To modify a order address type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order Address Types tab.
3. Select the applicable order address type and choose the Details icon. The Order
Address Type Details pop-up window displays.
4. In Short Description, enter a brief description of the order type.
5. In Long Description, enter a more detailed description of the order type.
6. Choose the Save icon.

Deleting an Order Address Type

About this task

To delete a order address type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Order Address Types tab.
3. Select the applicable order address type and choose the Delete icon.

146 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Defining Line Types
You can define codes and for line types that appear on a document type.

You can use the Line Types tab to create, modify, or delete a line type.

Creating a Line Type

About this task

To create a line type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Line Types tab.
3. Choose the Create New icon. The Line Type Details pop-up window displays.
4. In Line Type, enter the name of the line type.
5. In Description, enter a brief description of the line type.
6. Choose the Save icon.

Modifying a Line Type

About this task

To modify a line type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Line Types tab.
3. Select the applicable line type and choose the Details icon. The Line Type
Details pop-up window displays.
4. In Description, enter a brief description of the line type.
5. Choose the Save icon.

Deleting a Line Type

About this task

To delete a line type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Line Types tab.
3. Select the applicable line type and choose the Delete icon.

Defining Other Attributes

You can define other attributes that appear on the document type.

Chapter 9. Configuring a Document's Attributes 147

 You can use the Others tab for generating a prime line number from a
pre-configured number.

Generating a Prime Line Number for a New Line from a

Pre-Configured Number
About this task

Generating a prime line number for a new line from a pre-configured number
prevents conflicts between prime line numbers in Sterling Selling and Fulfillment
Foundation and in an external system when order synchronization occurs.

To specify a pre-configured starting number:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Attributes. The Order Attributes window displays in
the work area.
2. Choose the Others tab.
3. In Generate Prime Line No. For New Line Starting From, enter the starting
number. The starting prime line number must be a positive integer
4. If you select the Assign Group Sequence Number To Order Lines option, order
lines created during order creation or order modification are assigned sequence
numbers to sort order lines based on their relationships.
5. Choose the Save icon.

Results

The value entered in the "Generate Prime Line Number for New Line Starting
From:" field only affects orders created through the Console UI, not through direct
API calls (e.g. createOrder())

148 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 10. Configuring a Document's Order Validation
Configuring a Document's Order Validation
About this task

You can define the configuration for defaulting Seller and Buyer validation during
order creation for a particular Enterprise and document type. This validation is
used to determine the Sellers and Buyers available to create an order for, and
narrows the search results in the Application Consoles based on the validation type
you configured.

For example, you are configuring a Hub environment with 10 Enterprises, 50

Sellers, and 100 Buyers. A particular Enterprise only interacts with 10 of the 50
Sellers and 25 of the 100 Buyers as defined in the organization hierarchy. If you set
both the Seller and Buyer validations to 'Defined In The Enterprise Hierarchy',
when a user creates an order the system verifies that the Seller on the order is one
of the 10 Sellers defined in the Enterprise's hierarchy and the Buyer on the order is
one of the 25 Buyers defined in the Enterprise's hierarchy. Also, if the user chooses
the lookup for either the Seller or Buyer fields, only the Sellers and Buyers defined
for the Enterprise appear in the results.

To define an order document's order validation:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Order Validation. The Order Validation pop-up window
displays in the work area.
2. Enter information into the applicable fields. Refer to Table 63 for field value
descriptions.
3. Choose the Save icon.
Table 63. Order Validation Pop-Up Window
Field Description
Seller Validation Select the type of validation you want to use to verify the
Seller on the order document. You can choose from the
following options:
v None - No validation is performed for Sellers on an order.
All Sellers in the system can be used during order creation.
Also, all Sellers in the system display when the Seller
lookup is chosen in the Application Consoles.

© Copyright IBM Corp. 1999, 2012 149

 Table 63. Order Validation Pop-Up Window (continued)
Field Description

v Same As Enterprise - The system validates the Seller on the

order is the Enterprise.
v Defined In The Enterprise Hierarchy - The system validates
that the Seller on the order is defined within the
Enterprise's organizational hierarchy. Also, only the Sellers
defined within the Enterprise's organizational hierarchy
display when the Seller lookup is chosen in the Application
Consoles. For more information about configuring the
organizational hierarchy, see the Sterling Selling and
Fulfillment Foundation: Configuration Guide.

Customer Of The Enterprise - The system validates that the

Seller on the order has been configured as a customer. Also,
only the organizations defined as customers of the Enterprise
display when the Seller lookup is chosen in the Application
Consoles.
Buyer Validation Select the type of validation you want to use to verify the
Buyer on the order document. You can choose from the
following options:
v None - No validation is performed for Buyers on an order.
All Buyers in the system can be used during order creation.
Also, all Buyers in the system display when the Buyer
lookup is chosen in the Application Consoles.
v Save As Enterprise - The system validates the Buyer on the
order is the Enterprise.
v Defined In The Enterprise Hierarchy - The system validates
that the Buyer on the order is defined within the
Enterprise's organizational hierarchy. Also, only the Buyers
defined within the Enterprise's organizational hierarchy
display when the Buyer lookup is chosen in the
Application Consoles. For more information about
configuring the organizational hierarchy, see the Sterling
Selling and Fulfillment Foundation: Configuration Guide.
v Customer of the Enterprise - The system validates that the
Buyer on the order has been configured as a customer.
Also, only the organizations defined as customers of the
Enterprise display when the Buyer lookup is chosen in the
Application Consoles.
Validate Bill To ID As Select Validate Bill To ID As Customer ID if you want to
Customer ID validate that the customer ID on an order is defined for the
Enterprise.
Validate Vendor ID Select Validate Vendor ID if you want to validate that the
vendor ID on an order is defined for the Enterprise.
Validate Item Select Validate Item if you want to validate that the product
items on the order belong to the Enterprises catalog. Service
items, on the other hand, always need to exist within .

150 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 11. Configuring a Document's Instruction Types
Configuring a Document's Instruction Types
You can define the common codes used when adding special instructions to an
order document.

The default instruction types of Sterling Selling and Fulfillment Foundation are:
v PICK
v PACK
v SHIP
v GIFT
v ORDERING
v OTHER

You can use the Instruction Types branch to create, modify, or delete an instruction
type.

Creating an Instruction Type

About this task

To create an instruction type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Instruction Types. The Instruction Types window displays in
the work area.
2. Choose the Create New icon. The Instruction Type Details pop-up window
displays.
3. In Instruction Type, enter the instruction type.
4. In Short Description, enter a brief description of the instruction type.
5. In Long Description, enter a more detailed description of the instruction type.
6. Check Automatically Copy Item Instruction with Matching Type To Order Line
to force the system to automatically copy item instructions with matching
instruction types to order lines when the items are added onto an order.
7. Choose the Save icon.

Modifying an Instruction Type

About this task

To modify an instruction type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Instruction Types. The Instruction Types window displays in
the work area.

© Copyright IBM Corp. 1999, 2012 151

 2. Select the applicable instruction type and choose the Details icon. The
Instruction Type Details pop-up window displays.
3. In Short Description, enter a brief description of the instruction type.
4. In Long Description, enter a more detailed description of the instruction type.
5. Check Automatically Copy Item Instruction with Matching Type To Order Line
to force the system to automatically copy item instructions with matching
instruction types to order lines when the items are added onto an order.
6. Choose the Save icon.

Deleting an Instruction Type

About this task

To delete an instruction type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Instruction Types. The Instruction Types window displays in
the work area.
2. Select the applicable instruction type and choose the Delete icon.

152 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 12. Configuring a Document's Modification Reasons
Configuring a Document’s Modification Reasons
You can define common codes for modification reasons. These codes define why a
modification was made by a user in the Application Consoles.

In addition to modification reasons, the codes that you define are used as hold
reasons when you put an order on hold in the Application Consoles.

You can use the Modification Reasons branch for creating, modifying, and deleting
a modification reason.

Creating a Modification Reason

About this task

To create a modification reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Modification Reasons. The Modification Reasons window
displays in the work area.
2. Choose the Create New icon. The Modification Reason Details pop-up window
displays.
3. In Modification Reason, enter the modification reason.
4. In Short Description, enter a brief description of the modification reason.
5. In Long Description, enter a more detailed description of the modification
reason.
6. If this modification reason requires that the order be repriced due to a reduced
quantity, check the Re-Price Order With Reduced Quantity checkbox.
This flag is applicable only if this modification reason is used for cancellations,
where repricing needs to occur against a reduced quantity: the quantity against
which the order line is repriced (repricing quantity) is adjusted to the reduced
quantity. For more information about repricing quantity, see the Sterling Selling
and Fulfillment Foundation: Javadocs.
If this modification reason is used for a modification that does not reduce
quantity, this flag is not applicable.
This field does not exist for Load Modification Reasons.
7. Choose the Save icon.

Modifying a Modification Reason

About this task

To modify a modification reason:

© Copyright IBM Corp. 1999, 2012 153

 Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Modification Reasons. The Modification Reasons window
displays in the work area.
2. Select the applicable modification reason and choose the Details icon. The
Modification Reason Details pop-up window displays.
3. In Short Description, enter a brief description of the modification reason.
4. In Long Description, enter a more detailed description of the modification
reason.
5. If this modification reason requires that the order be repriced due to a reduced
quantity, check the Re-Price Order With Reduced Quantity checkbox.
This flag is applicable only if this modification reason is used for cancellations,
where repricing needs to occur against a reduced quantity: the quantity against
which the order line is repriced (repricing quantity) is adjusted to the reduced
quantity. For more information about repricing quantity, see the Sterling Selling
and Fulfillment Foundation: Javadocs.
If this modification reason is used for a modification that does not reduce
quantity, this flag is not applicable.
This field does not exist for Load Modification Reasons.
6. Choose the Save icon.

Deleting a Modification Reason

About this task

To delete a modification reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Modification Reasons. The Modification Reasons window
displays in the work area.
2. Select the applicable modification reason and choose the Delete icon.

154 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 13. Configuring a Document's Backorder Reasons
Configuring a Document's Backorder Reasons
You can define common codes for backorder reasons. These codes describe why an
order was backordered.

The default backorder reason of Sterling Selling and Fulfillment Foundation is "No
Stock."

You can use the Backorder Reasons branch for creating, modifying, and deleting a
backorder reason.

Creating a Backorder Reason

About this task

To create a backorder reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Backorder Reasons. The Backorder Reasons window displays
in the work area.
2. Choose the Create New icon. The Backorder Reason Details pop-up window
displays.
3. In Backorder Reason, enter the backorder reason.
4. In Short Description, enter a brief description of the backorder reason.
5. In Long Description, enter a more detailed description of the backorder reason.
6. Choose the Save icon.

Modifying a Backorder Reason

About this task

To modify a backorder reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Backorder Reasons. The Backorder Reasons window displays
in the work area.
2. Select the applicable backorder reason and choose the Details icon. The
Backorder Reason Details pop-up window displays.
3. In Short Description, enter a brief description of the backorder reason.
4. In Long Description, enter a more detailed description of the backorder reason.
5. Choose the Save icon.

© Copyright IBM Corp. 1999, 2012 155

Deleting a Backorder Reason
About this task

To delete a backorder reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Backorder Reasons. The Backorder Reasons window displays
in the work area.
2. Select the applicable backorder reason and choose the Delete icon.

156 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 14. Configuring a Document's Note Reasons
Configuring a Document's Note Reasons
You can define reason codes for entering a note. These codes define why a note
was entered by a user in the Console.

You can use the Note Reasons branch for creating, modifying, and deleting a note
reason.

Creating a Note Reason

About this task

To create a note reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Note Reasons. The Note Reasons window displays in the
work area.
2. Choose the Create New icon. The Note Reason Details window displays.
3. In Note Reason, enter the note reason as you want it to appear throughout the
system.
4. In Short Description, enter a brief description of the note reason.
5. In Long Description, enter a more detailed description of the note reason.
6. Choose the Save icon.

Modifying a Note Reason

About this task

To modify a note reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Note Reasons. The Note Reasons window displays in the
work area.
2. Select the applicable appointment failure reason and choose the Details icon.
The Note Reason Details window displays.
3. In Short Description, enter a brief description of the note reason.
4. In Long Description, enter a more detailed description of the note reason.
5. Choose the Save icon.

Creating a New Note Reason Based on an Existing One

About this task

To create a new note reason based on an existing one:

© Copyright IBM Corp. 1999, 2012 157

 Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Note Reasons. The Note Reasons window displays in the
work area.
2. Select the applicable note reason and choose the Save As icon. The Note
Reason Details window displays.
3. Enter information in the applicable fields.
4. Choose the Save icon.

Deleting a Note Reason

About this task

To delete a note reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Note Reasons. The Note Reasons window displays in the
work area.
2. Select the applicable appointment failure reason and choose the Delete icon.
The Confirmation window displays.
3. Choose OK.

158 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 15. Configuring a Quote Document's Approval Rule
Violation Reason
Configuring a Quote Document’s Approval Rule Violation Reason
You can define reason codes to explain why an approval rule has been violated.

Creating an Approval Rule Violation Reason

About this task

To create an approval rule violation reason:

Procedure
1. From the tree in the application rules side panel, select Document Specific >
Quote > Approval Rule Violation Reasons. The
Approval Rule Violation Reasons window is displayed in the work area.
2. Click the Create New icon. The Approval Rule Violation Reason Details
window is displayed.
3. In Approval Rule Violation Reason, enter the approval rule violation reason as
you want it to appear throughout the system.
4. In Short Description, enter a brief description of the approval rule violation
reason.
5. In Long Description, enter a detailed description of the approval rule violation
reason.
6. Click the Save icon.

Modifying an Approval Rule Violation Reason

About this task

To modify an approval rule violation reason:

Procedure
1. From the tree in the application rules side panel, select Document Specific >
Quote > Approval Rule Violation Reasons. The Approval Rule Violation
Reasons window is displayed in the work area.
2. Select the applicable approval rule violation reason and click the Details icon.
The Approval Rule Violation Reason Details window is displayed.
3. In Short Description, modify the brief description of the approval rule violation
reason.
4. In Long Description, modify the more detailed description of the approval rule
violation reason.
5. Click the Save icon.

© Copyright IBM Corp. 1999, 2012 159

Creating a New Approval Rule Violation Reason Based on an Existing
One
About this task

To create a new approval rule violation reason based on an existing one:

Procedure
1. From the tree in the application rules side panel, select Document Specific >
Quote > Approval Rule Violation Reasons. The Approval Rule Violation
Reasons window is displayed in the work area.
2. Select the applicable approval rule violation reason and click the Save As icon.
The Approval Rule Violation Reason Details window is displayed.
3. Enter information in the applicable fields.
4. Click the Save icon.

Deleting an Approval Rule Violation Reason

About this task

To delete an approval rule violation reason:

Procedure
1. From the tree in the application rules side panel, select Document Specific >
Quote > Approval Rule Violation Reasons. The Approval Rule Violation
Reasons window is displayed in the work area.
2. Select the applicable approval rule violation reason and click the Delete icon.
The Confirmation window is displayed.
3. Click OK.

160 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 16. Configuring a Document's Line Relationship Type
Configuring a Document’s Line Relationship Type
You can define the relationship types used when linking two related lines together.
These relationships are used to group similar products together on an order.

Defining a Line Relationship Type

About this task
To create a line relationship type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Line Relationship Type. The Line Relationship Type window
appears in the work area.
2. Choose the Create New icon. The Line Relationship Details window appears.
3. In Relationship Type, enter the relationship type as you want it to appear
throughout the system.
4. In Short Description, enter a brief description of the relationship type.
5. In Long description, enter a more detailed description of the relationship type.
6. To enable sorting on this relationship type, check the Consider For Sorting
checkbox.
7. Choose the Save icon.

Modifying a Line Relationship Type

About this task

To modify a line relationship type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Line Relationship Type. The Relationship Type window
appears in the work area.
2. Select the applicable relationship and choose the Details icon. The Relationship
Type Details window appears.
3. In Short Description, enter a brief description of the relationship type.
4. In Long description, enter a more detailed description of the relationship type.
5. To enable sorting on this relationship type, check the Consider For Sorting
checkbox.
6. Choose the Save icon.

Creating a New Line Relationship Type Based on an Existing One

About this task

To create a new line relationship type based on an exiting one.

© Copyright IBM Corp. 1999, 2012 161

 Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Line Relationship Type. The Relationship Type window
appears in the work area.
2. Select the applicable relationship type and choose the Save As icon. The
Relationship Type Details window appears.
3. Enter information in the applicable fields
4. Choose the Save icon.

Deleting a Line Relationship Type

About this task

To delete a line relationship type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Line Relationship Type. The Relationship Type window
appears in the work area.
2. Select the applicable relationship type and choose the Delete icon. The
Confirmation window appears.
3. Choose OK.

162 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 17. Configuring an Opportunity Document's Lead
Origin
Configuring an Opportunity Document's Lead Origin
You can define the lead origin of an opportunity, which indicates from where the
opportunity originated. For example, you may define lead origins such as Trade
Show, Call Center, and Existing Customer.

You can use the Lead Origin branch for creating or modifying a lead origin,
creating a lead origin based on an existing one, or deleting a lead origin.

Creating a Lead Origin

About this task

To create a lead origin:

Procedure
1. From the tree in the application rules side panel, choose
Opportunity > Lead Origin. The Lead Origins window displays in the work
area.
2. Choose the Create New icon. The Lead Origin Details window displays.
3. In Lead Origin, enter the lead origin as you want it to appear throughout the
system.
4. In Short Description, enter a brief description of the lead origin.
5. In Long Description, enter a more detailed description of the lead origin.
6. Choose the Save icon.

Modifying a Lead Origin

About this task

To modify a lead origin:

Procedure
1. From the tree in the application rules side panel, choose
Opportunity > Lead Origin. The Lead Origins window displays in the work
area.
2. Select the applicable lead origin and choose the Details icon. The Lead Origin
Details window displays.
3. In Short Description, enter a brief description of the lead origin.
4. In Long Description, enter a more detailed description of the lead origin.
5. Choose the Save icon.

Creating a New Lead Origin Based on an Existing One

About this task

To create a new lead origin based on an existing one:

© Copyright IBM Corp. 1999, 2012 163

 Procedure
1. From the tree in the application rules side panel, choose
Opportunity > Lead Origin. The Lead Origins window displays in the work
area.
2. Select the applicable lead origin and choose the Save As icon. The Lead Origin
Details window displays.
3. Enter information in the applicable fields.
4. Choose the Save icon.

Deleting a Lead Origin

About this task

To delete a lead origin:

Procedure
1. From the tree in the application rules side panel, choose
Opportunity > Lead Origin. The Lead Origins window displays in the work
area.
2. Select the applicable lead origin and choose the Details icon. The Confirmation
window displays.
3. Choose OK.

164 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 18. Configuring an Opportunity Document's Lost
Reason
Configuring an Opportunity Document's Lost Reason
You can define reason codes for why an opportunity is lost.

You can use the Lost Reason branch for:

v Creating a Lost Reason
v Modifying a Lost Reason
v Creating a New Lost Reason Based on an Existing One
v Deleting a Lost Reason

Creating a Lost Reason

About this task

To create a lost reason:

Procedure
1. From the tree in the application rules side panel, choose
Opportunity > Lost Reason. The Lost Reasons window displays in the work
area.
2. Choose the Create New icon. The Lost Reason Details window displays.
3. In Lost Reason, enter the lost reason as you want it to appear throughout the
system.
4. In Short Description, enter a brief description of the lost reason.
5. In Long Description, enter a more detailed description of the lost reason.
6. Choose the Save icon.

Modifying a Lost Reason

About this task

To modify a lost reason:

Procedure
1. From the tree in the application rules side panel, choose
Opportunity > Lost Reason. The Lost Reasons window displays in the work
area.
2. Select the applicable lost reason and choose the Details icon. The Lost Reason
Details window displays.
3. In Short Description, enter a brief description of the lost reason.
4. In Long Description, enter a more detailed description of the lost reason.
5. Choose the Save icon.

© Copyright IBM Corp. 1999, 2012 165

Creating a New Lost Reason Based on an Existing One
About this task

To create a new lost reason based on an existing one:

Procedure
1. From the tree in the application rules side panel, choose
Opportunity > Lost Reason. The Lost Reasons window displays in the work
area.
2. Select the applicable lost reason and choose the Save As icon. The Lost Reason
Details window displays.
3. Enter information in the applicable fields.
4. Choose the Save icon.

Deleting a Lost Reason

About this task

To delete a lost reason:

Procedure
1. From the tree in the application rules side panel, choose
Opportunity > Lost Reason. The Lost Reasons window displays in the work
area.
2. Select the applicable lost reason and choose the Delete icon. The Confirmation
window displays.
3. Choose OK.

166 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 19. Configuring a Document's Modification
Components
Configuring a Document's Modification Components
You can configure the modification rules and types of a document when it is in a
specific status. These rules determine which parts of a document can be modified
as well as in which status the modifications can be performed. The set of rules and
types can be classified into modification groups. Each modification group can be
associated with a user-defined condition.

If you are using the Distributed Order Management module, you can configure
modification components at the following process type levels:
v Fulfillment
v Outbound Logistics

If you are using the Logistics Management module, you can configure modification
components at the load process type level.

If you are using the Supply Collaboration module, you can configure modification
components at the following process type levels:
v Fulfillment
v Inbound Logistics
v Receipt
v Negotiation

If you are using the Reverse Logistics module, you can configure modification
components at the following process type levels:
v Fulfillment
v Logistics
v Receipt

You can use the Order Modification branch to define custom modification types,
modification groups, modifications impacting pricing, and modifications requiring
auditing.

Defining Custom Modification Types

You can define custom modification types for a process type. Creating a
modification type allows you to classify certain attributes (including extended
attributes) into one group. Later, when you define status modification groups, you
can configure modification rules for the custom modification type. Modification
rules determine modification permissions for the attributes. You can decide
whether to allow, disallow, or ignore the custom modification type for a given
status.

You can use the Order Modification Types branch for creating, modifying, and
deleting a custom modification type. After you define a custom modification type,
use the Status Modification Group Details window to configure modification rules
for the custom modification type.

© Copyright IBM Corp. 1999, 2012 167

 Creating a Custom Modification Type
About this task

To create a custom modification type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > (Process Type) > (Process Type) Modification > (Process Type)
Modification Types. The Custom Modification List window displays in the
work area.
2. From the Custom Modification List, click the Create New icon. The Custom
Modification window displays. Enter information in the applicable fields. Refer
to Table 64 for field value descriptions.
3. Click the Save icon. A pop-up warning you to sign out of the application for
changes to take place displays.
Table 64. Custom Modification Window
Field Description
Modification Level Select the level of the modification type. For example, Header,
Line, or Release.
Modification Type Enter the name of the modification type.
Description Enter a brief description of the modification type.
Min Allowed Status Select the minimum status the modification type can be
performed at.
Max Allowed Status Select the maximum status the modification type can be
performed at.
Available A list of XML attributes that can be associated with the
modification type. To add an available attribute to the
modification type, select the attribute you want to add and
click the Right Arrow icon.
Subscribed A list of XML attributes that have been associated with the
modification type. To remove a subscribed attribute, select the
attribute you want to remove and click the Left Arrow icon.

Modifying a Custom Modification Type

About this task

To modify a custom modification type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > (Process Type) > (Process Type) Modification > (Process Type)
Modification Types. The Custom Modification List window displays in the
work area.
2. From the Custom Modification List, locate the applicable Custom Modification
and click the Details icon. The Custom Modification window displays.
3. Enter information in the applicable fields. Refer to Table 64 for field value
descriptions.
4. Click the Save icon.

168 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Deleting a Custom Modification Type
About this task

To delete a custom modification type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > (Process Type) > (Process Type) Modification > (Process Type)
Modification Types. The Custom Modification List window displays in the
work area.
2. From the Custom Modification List, locate the applicable Custom Modification
and click the Delete icon.

Defining Status Modification Groups

Status modification groups enable you to configure status modification rules that
are based on enterprise, process type, and order conditions. You define a status
modification group by configuring the following functionalities:
v Modification Rules - Define modification rules for subscribed modification types.
v Condition - Specify a condition for validating the status modification group.
v Is Override - Specify the status modification group has priority over other status
modification groups.
v Inherited From Status Modification Group - Specify the status modification
group inherits status modification rules from another status modification group.

Defining Modification Rules

Most documents flow through a pipeline without requiring any intervention by a
customer service representative. However, there are times when modifications are
required, such as changing credit card information or quantity. Sterling Selling and
Fulfillment Foundation supports modification through the Console and APIs. It is
critical for you to decide which modifications are allowed for each modification
type, modification level, and status combination.

Note: Contemplate business and system integration implications before allowing a

modification that is disallowed as part of the system defaults. For example, adding
instructions to a document type is disallowed after the release has been sent to the
node. If you change the modification to be allowed, the system has no way of
communicating the new instruction to the node center because the release has
already been sent.

The modification type indicates the type of modification carried out on a

document. Sterling Selling and Fulfillment Foundation provides the ability to
perform modifications on specific attributes. An example of a modification type is
adding an order line to an order.

Modification level indicates the level at which a particular modification type is

carried out. These include the following levels:
v Header
v Line
v Release
v Release Line
v Negotiation

Chapter 19. Configuring a Document's Modification Components 169

 v Negotiation Line
v Shipment
v Receipt

For a complete list of the system modification types and their modification levels,
see “Order Modification Types” on page 455.

Modifications are applied to a particular level and a particular processing status.

For example, if modifications are requested for a document at the header level or
at the line level, then the order lines, as well as the order release lines, are picked
up for validating whether or not modifications are allowed for those order
statuses. If modifications are requested at the release or release line level, then
order release lines are picked up for validating whether or not modifications are
allowed for those order statuses.

You can group modifications in the Modification Rules tab of the Status
Modification Group Details window by modification type, modification level, or
status, by selecting the corresponding grouping from Group By. The Modification
Rules tab then displays the grouping you have chosen in a hierarchical structure.

All modification rules operate within a certain system-defined range. For instance,
for Sales Orders, the Cancel modification on the order entity is always defined to
be between the statuses 1000 (Draft Order Created) and 3350 (Included In
Shipment). The system never allows a Cancel modification at a status of 3701
(Return Created). On the other hand, you are able to allow modifications between
the statuses 1000 and 3350. If an entity is in multiple statuses, the modification is
allowed, provided that at least one of the statuses is within the system-defined
range.

If you make modifications such as changing a Bill To address after an order has
shipped or a return has been created, the changed Bill To address will not be
propagated to the shipment, the return order, and so forth.

The following table defines the different settings you can apply to modifications:
Table 65. Order Document Type Rule Modifications
Field Description
Status Indicates each status that is applicable to a modification level
and type.
Allow Indicates whether or not modifications may be made at this
modification level and type for the specified status.
Disallow Indicates that no modifications may be made at this
modification level and type for the specified status.
Ignore Indicates that modifications are ignored at this modification
level and type for the specified status.

170 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 65. Order Document Type Rule Modifications (continued)
Field Description
Within a status modification group, there are several scenarios to consider for the Allow,
Disallow, and Ignore settings:
v If one line is in status 1 and another line is in status 2 - and both statuses are set to
Allow, the modification is allowed.
v If one line is in status 1, another line is in status 2, and another is in status 3 - and the 1
and 2 statuses are set to Allow, but the 3 status is set to Disallow, all modifications are
disallowed, because one of the currently applied statuses is disallowed.
v If one line is in status 1 and one is in the extended status 2 - If the 1 status is set to
Allow, but the extended status is set to Ignore (all extended statuses are defaulted to
ignore, so that they pick up their base status settings unless you have explicitly
overridden the setting) then all modifications are allowed only if the base status is set to
allow. If the base status is set to disallow, then all modifications are disallowed.

If all lines are set to Ignore, then all modifications are disallowed, regardless of the base
status settings.

Application Console users can be granted permission to override the modification

rules through user group permissions. When a user has been granted this
permission, the user can perform a modification that has been disallowed within
the Application Consoles. For more information about configuring user group
permissions, see the Sterling Selling and Fulfillment Foundation: Configuration Guide.

Specifying a Condition for a Status Modification Group

You can define a condition for a status modification group that determines how
the group is validated against status modifications. For example, when a user of an
enterprise performs an operation on a supported document type or calls an
order-related API, such as getOrderDetails, the status modification is validated
using this process:
v Obtain the conditional XML file from the order. The conditional XML file is
created when you specify a condition for the status modification group.
v Obtain all applicable status modification groups that meet the conditions
specified in the conditional XML file.
v Obtain all modification types from applicable status modification groups,
including inherited configurations. Then, any conflicting status modification
rules are resolved.

Conditions for status modification groups are specified by order attribute. For
example, the CurrentUserRole attribute lets you configure status modification rules
for a primary user group, such as Field Sales. Consider a scenario in which you
want to give field sales representatives the ability to create quotes. However, you
do not want to allow them to change the price on existing quotes. To configure this
scenario, you would create a status modification group where the CurrentUserRole
attribute is set to the primary user group id for field sales representatives. As part
of creating the status modification group, you would define status modification
rules that allow changes to quotes but prevent changes to prices on existing
quotes. Additionally, you could create a different status modification group that
allows supervisors to change the price on existing quotes. In this example, assume
that the enterprise and process type are the same for both status modification
groups.

Chapter 19. Configuring a Document's Modification Components 171

 If you do not specify a condition for a status modification group, the status
modification group validation is enforced. Use the Condition field in the Status
Modification Group Details window to specify a condition for a status modification
group.

Overriding Status Modification Groups

You can use the Is Override option to specify that a status modification group has
priority over other status modification groups. For example, if three status
modification groups contain the same status modification rule, where one group
has the Is Override option selected, the modification rule is set to the value
specified in the override group.

When multiple status modification groups have the Is Override option selected,
conflicts are resolved using the logic described in Table 66.
Table 66. Multiple Status Modification Groups and the Is Override Option
Status Status Status Status Status Status
Is Override Allow Allow Ignore Disallow Allow Disallow
- checked
for Group 1
Is Override Allow Disallow Ignore Disallow Ignore Ignore
- checked
for Group 2
Result Allow Disallow Disallow Disallow Allow Disallow

Inheriting Modification Rules from a Status Modification

Group
When you create a status modification group, it inherits modification rules from
the default status modification group. You can then define the group by
configuring its modification rules. Additionally, modification groups can inherit
status modification rules from other status modification groups. For example, you
can create a status modification group that allows field sales representatives to
create orders. If you create a group for managers that inherits status modifications
rules from the Field Sales Representative Group, the managers can also create
orders. Later, if you want to prevent field sales representatives and managers from
creating orders, you only need to disallow the create order status for the Field
Sales Representative Group. The Manager Group inherits the updated status
modification.

When one group inherits rules from another group, the modification rules defined
in the child modification group override the parent's modification rules. For
example, the Field Sales Representative Group can create orders but cannot change
the price on a quote. If you want the Manager Group to have the ability to create
orders and change the price on quotes, configure the Manager Group to inherit
status modification rules from the Field Sales Representative group, and then
configure the Manager Group to have the ability to change the price on a quote.

Additionally, the Is Override option can be enabled for child groups. For example,
a manager belongs to the following status modification groups:
v Manager Group 1 - This group is not allowed to create orders.
v Manager Group 2 - This group inherits the ability to create orders from the Field
Sales Group. Manager Group 2 has the Is Override option enabled.

172 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Because the Is Override option is enabled for Manager Group 2, the manager has
the ability to create orders.

Resolving Conflicts Between Status Modification Groups

In some cases, multiple status modification groups contain conflicting status
modification rules. Conflicts between status modification groups are resolved in
the following way:
v If two status modification groups contain the same rule, where one group has
the rule set to Allow and the other group has the rule set to Disallow, the rule is
set to Allow.
v If no status modification group has the rule defined, the rule is set to the value
specified in the parent group. If there is no parent group, the rule is set to the
value in Default Group.
v If multiple status modification groups have the Is Override option selected, but
the groups do not have the rule defined, the rule is set to the value specified in
the parent group. If there is no parent group, the rule is set to the value in
Default Group.

The following example provides a scenario for resolving conflicts between status
modification groups.

Example: Resolving Conflicts Between Status Modification

Groups

In this example, three status modification groups contain status modification rules
that affect the same order.
Table 67. Default Status Modification Group
1500 OrderLine Cancel Disallow
2300 Order ShipTo Change Disallow
2400 Order ShipNode Change Disallow

Use Status Modification Group 1 when condition 1 is true:

Table 68. Status Modification Group 1
Inherits from Default Group
1500 OrderLine Cancel Disallow
2400 Order ShipNode Change Disallow

Use Status Modification Group 2 when condition 2 is true:

Table 69. Status Modification Group 2
Inherits from Default Group
1500 OrderLine Cancel Disallow

Use Status Modification Group 3 when condition 3 is true:

Table 70. Status Modification Group 3
Inherits from Default Group
Is Override is Yes
2400 Order ShipNode Change Disallow

Chapter 19. Configuring a Document's Modification Components 173

 If the order satisfies all conditions, status modification groups 1, 2, and 3 are
applicable. As a result, the following access is granted:
Table 71. Resulting Access for Conflicting Status Modification Groups
1500 OrderLine Cancel Allowed Condition 1 applied
2300 Order ShipTo Change Disallow Default applied
2400 Order ShipNode Change Disallow Condition 3 applied

Creating a Status Modification Group

About this task

To create a status modification group:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > (Process Type) > (Process Type) Modification > (Process Type)
Modification Groups. The Status Modification Group List window displays in
the work area.
2. From the Status Modification Group List, click the Create New icon. The Status
Modification Group Details window displays.
3. Enter information in the applicable fields. For field value descriptions, see
Table 72.
4. Click the Save icon to save the modification group.
Table 72. Status Modification Group Details Window
Field Description
Status Modification Group ID Enter a name for the status modification
group.
Description Enter a description for the status
modification group.
Inherited From Status Modification Group (Optional) Select a parent status
modification group if you want to inherit
modification rules from another group.
Is Override (Optional) Check this option if you want
this status modification group to take
precedence.
Condition (Optional) Select a condition if you want to
specify a condition for this status
modification group. Or, you can create a
condition by clicking the Create New icon,
which opens the Condition Detail window.
Refer to “Adding Conditions to a Status
Modification Group” on page 175 for
information about configuring conditions for
status modification groups.
Note: If you do not specify a condition, this
group's validation is enforced.
Subscribed Modification Types

174 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 72. Status Modification Group Details Window (continued)
Field Description
Available Displays a list of available modification
types. This list includes all system-supplied
modification types as well as the custom
modification types that you created in the
Custom Modification window. To subscribe
a modification type, select the modification
type in the Available list and click the Right
Arrow icon.
Subscribed Displays a list of the modification types for
which you want to define modification
rules. To remove a modification type from
the subscribed list, select the modification
type in the Subscribed list and click the Left
Arrow icon. Click the Save icon to display
the subscribed modification types in the
Modification Rules tab.
Modification Rules
Group By Select a sort option for displaying
modification types in the Primary Info tab.
You can sort modification types by type,
level, and status.
Primary Info Displays the modification types that you
subscribed in the Subscribed Modification
Types tab. Expand the applicable
modification types and levels for which you
want to set up modification rules. Right
click on the applicable rule and choose
Allow, Disallow, or Ignore as per your
business practices.

Adding Conditions to a Status Modification Group

About this task

The Condition Detail window allows you to create a new condition for the status
modification group. The Condition Detail window opens when you click the
Create New icon, next to the Condition field, in the Status Modification Group
Details window.

To create a condition for the status modification group:

Procedure

In the Condition Detail window, enter information in the following fields:

Option Description
Condition ID Enter the condition ID.
Condition Name Enter the name of the condition for the
status modification group.
Condition Group Enter the name of the condition's group, if
applicable. Condition Group allows you to
group related conditions within the
condition tree.

Chapter 19. Configuring a Document's Modification Components 175

 Option Description
Static If this is checked, you must enter a
condition value for the static condition.
Dynamic If this is checked, you must enter a Java
class name that evaluates the condition at
runtime.
Advanced XML If you are creating a new condition, this
option is disabled as a new condition of the
advanced XML type must be created using
the IBM Greex Editor IDE tool. For more
information about creating an advanced
XML condition using the IBM Greex Editor,
see the Sterling Selling and Fulfillment
Foundation: Extending the Condition Builder.

This option is automatically selected

whenever you modify a condition of the
advanced XML type.
Condition Value (if Static is checked) Click the Condition Builder icon to use the
condition builder, which is where you set up
the conditional value for the status
modification group. You can set it up in a
formulaic readout using the available
symbols. You can enter your own attribute
or an extended attribute if Static condition is
checked. For example, if you are configuring
a status modification group for the Field
Sales Representative Group, use the {Enter
Your Own Attribute} option in the Condition
Builder to set the CurrentUserGroup
attribute equal to the primary user group id
for field sales. For more information about
creating these attributes, see the Sterling
Selling and Fulfillment Foundation: Extending
the Condition Builder.
Class Name (if Dynamic is checked) Enter the class name that implements the
following Java interface:
com.yantra.ycp.japi.YCPDynamicCondition
Note: To use extended attributes for a
condition, implement the
YCPDynamicConditionEx interface. For
more information about implementing this
interface, refer to the Sterling Selling and
Fulfillment Foundation: Extending the Condition
Builder.
Condition Properties (if Dynamic is Specify the custom name or value properties
checked) which are set into the condition evaluating
Java class file before evaluating the
condition. For more information about
creating custom attributes, see the Sterling
Selling and Fulfillment Foundation: Extending
the Condition Builder.

176 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Modifying a Status Modification Group
About this task

To modify a status modification group:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > (Process Type) > (Process Type) Modification > (Process Type)
Modification Groups. The Status Modification Group List window displays in
the work area.
2. From the Status Modification Group List, select the applicable modification
group and choose the Details icon. The Status Modification Group Details
window displays.
3. Enter information in the applicable fields. Refer to Table 72 on page 174 for
field value descriptions.
4. Click the Save icon.

Deleting a Status Modification Group

About this task

To delete a status modification group:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > (Process Type) > (Process Type) Modification > (Process Type)
Modification Groups. The Status Modification Group List window displays in
the work area.
2. From the Status Modification Group List, locate the applicable status
modification group and click the Delete icon.

Defining Modifications Impacting Pricing

You can specify whether a modification type impacts pricing on an order. When
modifications of these modification types occur, OrderRepricingUE is called to
update price and charge information at the level indicated for that modification
type. For more information about OrderRepricingUE, see the Sterling Selling and
Fulfillment Foundation: Javadocs.

Adding/Removing a Modification Type for Modifications

Impacting Pricing
About this task

To specify whether a modification type has pricing impact:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > (Process Type) > (Process Type) Modification > Modifications
Impacting Pricing. The Modifications Impacting Pricing List window displays
in the work area.
2. From the Modifications Impacting Pricing List, choose the Details icon. The
Modification Type List window displays.

Chapter 19. Configuring a Document's Modification Components 177

 3. To add a modification type to the Modifications Impacting Pricing list, select
the desired modification type(s) from the Modification Types and choose the
Right Arrow icon.
4. To remove a modification type from the Modifications Impacting Pricing list,
select the desired modification type(s) from the Modification Types and choose
the Left Arrow icon.
5. Choose the Save icon.

Defining Modifications Requiring Auditing

You can specify which modification types will require an audit after being
completed.

To specify which modification types require an audit:

1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Order Modification > Modifications Requiring
Auditing. The Modifications Requiring Auditing window displays in the work
area.
2. From the Modifications Requiring Auditing window, choose the Details icon.
When opening the Modifications Requiring Auditing screen for the first time,
all modification types are listed as requiring audits.
3. To add a modification type to the Modifications Requiring Auditing list, select
the desired modification type(s) from the Modification Types column and
choose the Right Arrow icon.
4. To remove a modification type from the Modifications Requiring Auditing list,
select the desired modification type(s) from the Modification Types column and
choose the Left Arrow icon.
5. Choose the Save icon.

178 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 20. Configuring an Order Document's
Fulfillment-Specific Components
Configuring an Order Document's Fulfillment-Specific Components
To complete an order document's lifecycle, each document has a set of different
processes that it can go through. These processes are called process types. Every
order document has a defined set of process types in Sterling Selling and
Fulfillment Foundation.

The following process types are defined in Sterling Selling and Fulfillment
Foundation for the order document types:
v Order Fulfillment
v Order Negotiation
v Outbound Shipment

You can configure the rules and components specific to an order document's
fulfillment process type.

Defining Hold Types

Orders and order lines can be placed on hold manually or automatically, by
applying a particular hold type. Certain transactions can be configured to not
process documents that are on a specific type of hold. Likewise, modification types
can be configured to not process documents that are on a specific type of hold. By
default, all transactions and modification types are allowed to process all
documents for all hold types.

The transactions that can be prevented from processing orders or order lines on a
specific type of hold have the checkbox, This Transaction Can Be Stopped From
Processing Orders That Are On Hold, checked in the Others tab of the transaction
details screen. For more information about viewing transaction details, see the
Sterling Selling and Fulfillment Foundation: Configuration Guide.

Creating a Hold Type

About this task

To create a hold type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific
(Shipping) > Sales Order > Hold Types. The Hold Types window displays in
the work area.
2. Click the Create New icon. The Hold Type pop-up window displays.
3. In Hold Type, enter the type of the hold.
4. In Hold Type Description, enter the description of the hold.
5. Enter information in the applicable fields. See Table 73 on page 180, Table 74 on
page 181, and Table 75 on page 181 for field value descriptions.
6. Click the Save icon.

© Copyright IBM Corp. 1999, 2012 179

 Table 73. Hold Type Pop-Up Window, Hold Creation Tab
Field Description
Hold Created Automatically
On Shipment Creation Check this box to apply this hold type to all shipments upon
shipment creation.
On Resolution Of The Hold Check this box to apply this hold type upon resolution of
Type another hold type. From the drop-down list, select the hold
type that, upon resolution, triggers this hold type.
Note: Sterling Selling and Fulfillment Foundation does not
check whether or not you are defining a circular hold type
definition. For example, if you define hold type B as being
applied upon resolution of hold type A, and hold type A as
being applied upon resolution of hold type B, you could
create an infinite loop that Sterling Selling and Fulfillment
Foundation does not warn you against.
When The Following Check this box for modification types that automatically
Modifications Are apply this hold type to a shipment.
Performed
Click the Details icon to modify the list. In the Modification
Type List pop-up window:
v Use the right arrow to move the available modification
types that you wish to associate with this hold type to the
subscribed list.
v Use the left arrow to unsubscribe the modification types
that you wish to disassociate with this hold type and move
them back into the available list.
For All Shipments Choose this option if the above conditions need to be applied
to all shipments.
Note: You can select this option only after the created hold
has been saved.
Only For Shipments Choose this option if the above conditions need to be applied
Satisfying The Following to shipments satisfying a certain condition.
Condition
Click the Details icon to build or modify the condition that is
evaluated. For more information about using the condition
builder, refer to the Sterling Selling and Fulfillment Foundation:
Configuration Guide.

The available attributes for this condition can be extended.

For more information, refer to the Sterling Selling and
Fulfillment Foundation: Extending the Condition Builder.
Note: You can select this option only after the created hold
has been saved.
Hold Created Manually
By Any User Choose this option if any user group can apply this hold to a
shipment.

180 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 73. Hold Type Pop-Up Window, Hold Creation Tab (continued)
Field Description
By Users Who Belong To Choose this option if only users belonging to certain user
The Following Groups groups may apply this hold to a shipment.

Click the Details icon to modify the list. In the subsequent

pop-up window:
v Use the right arrow to move the available user groups that
you wish to associate with this hold type to the subscribed
list.
v Use the left arrow to unsubscribe the user groups that you
wish to disassociate with this hold type and move them
back into the available list.

Table 74. Hold Type Pop-Up Window, Hold Resolution Tab

Field Description
Hold Resolved Automatically
The Following Time From the drop-down list, select the time-triggered transaction
Triggered Transaction Will that processes the created holds.
Process Created Holds
The Following Time From the drop-down list, select the time-triggered transaction
Triggered Transaction Will that processes the rejected holds.
Process Rejected Holds
Hold Resolved Manually
Any User Can Process This Choose this option if any user group can process this hold.
Hold
Users Belonging To The Choose this option if only users belonging to certain user
Following User Groups groups can process this hold.
Can Process This Hold
Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available user groups that
you wish to associate with this hold type to the subscribed
list.
v Use the left arrow to unsubscribe the user groups that you
wish to disassociate with this hold type and move them
back into the available list.

Table 75. Hold Type Pop-Up Window, Hold Effects Tab

Field Description
The Following Transactions Transactions that are disallowed when this hold type is
Will Be Stopped From applied to a shipment.
Processing Shipments On
This Hold Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available modification
types that you wish to associate with this hold type to the
subscribed list.
v Use the left arrow to unsubscribe the modification types
that you wish to disassociate with this hold type and move
them back into the available list.

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 181

 Table 75. Hold Type Pop-Up Window, Hold Effects Tab (continued)
Field Description
The Following Modification types that are disallowed when this hold type is
Modifications Are Not applied to a shipment.
Allowed For Shipments On
This Hold Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available transactions that
you wish to associate with this hold type to the subscribed
list.
v Use the left arrow to unsubscribe transactions that you
wish to disassociate with this hold type and move them
back into the available list.

Creating an Order Level Hold Type

About this task

To create an order level hold type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Hold Types. The Hold Types window displays
in the work area.
2. Click the Create New icon in the Order Hold Types panel. The Hold Type
pop-up window displays.
3. In the Hold Type field, enter the type of the hold.
4. In the Hold Type Description field, enter the description of the hold type.
5. Enter the information in the applicable fields. For field value descriptions, see
Table 76, Table 77 on page 183 and Table 78 on page 184.
6. Click the Save icon.
Table 76. Hold Type Screen, Hold Creation tab
Field Description
Hold Created Automatically
On Draft Order Creation Check this option to apply this hold type to all orders during
draft order creation.
On Draft Order Check this option to apply this hold type to all orders during
Confirmation draft order confirmation.
On Order Creation Check this option to apply this hold type to all orders during
order creation.
On Resolution Of The Hold Check this option to apply this hold type during the
Type resolution of another hold type. From the drop-down list,
select the hold type that, upon resolution, triggers this hold
type.
Note: Sterling Selling and Fulfillment Foundation does not
check whether or not you are defining a circular hold type
definition. For example, if you define hold type B as being
applied during the resolution of hold type A, and hold type
A as being applied during the resolution of hold type B, you
could create an infinite loop that Sterling Selling and
Fulfillment Foundation does not warn you against.

182 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 76. Hold Type Screen, Hold Creation tab (continued)
Field Description
When The Following Modification types that automatically apply this hold type to
Modifications Are an order.
Performed
Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available modification
types that you wish to associate with this hold type to the
subscribed list.
v Use the left arrow to unsubscribe the modification types
that you wish to disassociate with this hold type and move
them back into the available list.
For All Orders Select this radio button if the above conditions should be
checked for all orders.
Note: You can only select this option after the created hold
has been saved.
Only For Orders Satisfying Select this radio button if the above conditions should only be
The Following Condition checked for orders satisfying a certain condition. Click the
Details icon to build or modify the condition that is
evaluated. For more information about using the condition
builder, see the Sterling Selling and Fulfillment Foundation:
Configuration Guide.

The available attributes for this condition can be extended.

For more information about extending condition attributes,
see the Sterling Selling and Fulfillment Foundation: Extending the
Condition Builder.
Note: You can only select this option after the created hold
has been saved
Hold Created Manually
By Any User Select this radio button if all user groups can apply this hold
to an order.
By Users Who Belong To Select this radio button if only users belonging to certain user
The Following Groups groups can apply this hold to an order.

Click the Details icon to modify the list of user groups. In the
subsequent pop-up window:
v Use the right arrow to move the available user groups that
you wish to associate with this hold type to the subscribed
list.
v Use the left arrow to unsubscribe the user groups that you
wish to disassociate with this hold type and move them
back into the available list.

Table 77. Hold Type Screen, Hold Resolution tab

Field Description
Hold Resolved Automatically
The Following From the drop-down list, select the time-triggered transaction
Time-Triggered Transaction that will process the created holds.
Will Process Created Holds
The Following From the drop-down list, select the time-triggered transaction
Time-Triggered Transaction that will process the rejected holds.
Will Process Rejected Holds

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 183

 Table 77. Hold Type Screen, Hold Resolution tab (continued)
Field Description
Can Resolve On Cancel Select this radio button to automatically remove a hold when
an order is cancelled.
Hold Resolved Manually
Any User Can Process This Select this radio button if all user groups can process this
Hold hold.
Users Belonging To The Select this radio button if only users belonging to certain user
Following User Groups groups can process this hold.
Can Process This Hold
Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available user groups that
you wish to associate with this hold type to the subscribed
list.
v Use the left arrow to unsubscribe the user groups that you
wish to disassociate with this hold type and move them
back into the available list.

Table 78. Hold Type Screen, Hold Effects tab

Fields Description
The Following Transactions Transactions that are disallowed when this hold type is
Will Be Stopped From applied to an order.
Processing Orders On This
Hold Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available transactions that
you wish to associate with this hold type to the subscribed
list.
v Use the left arrow to unsubscribe the transactions that you
wish to disassociate with this hold type and move them
back into the available list.
The Following Modification types that are disallowed when this hold type is
Modifications Are Not applied to an order.
Allowed For Orders On
This Hold Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available modification
types that you wish to associate with this hold type to the
subscribed list.
v Use the left arrow to unsubscribe the modification types
that you wish to disassociate with this hold type and move
them back into the available list.

Creating an Order Line Level Hold Type

About this task

To create an order line level hold type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Hold Types. The Hold Types window displays
in the work area.

184 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
2. Click the Create New icon in the Order Line Hold Types panel. The Hold Type
pop-up window displays.
3. In the Hold Type field, enter the type of the hold.
4. In the Hold Type Description field, enter the description of the hold type.
5. Enter the information in the applicable fields. For field value descriptions, see
Table 79, Table 80 on page 186 and Table 81 on page 187.
6. Click the Save icon.
Table 79. Hold Type Screen, Hold Creation tab
Field Description
Hold Created Automatically
On Draft Order Creation Check this option to apply this hold type to all lines on an
With Lines Or Adding order upon entering Draft Order Created status or when a
Lines To Draft Order line is added to an order that is already in Draft Order
Created status.
On Draft Order Check this option to apply this hold type to a line upon
Confirmation confirmation of a draft order.
On Order Creation Or Check this option to apply this hold type to a line upon
Adding Lines To An Order creation or addition to an order.
On Resolution Of The Hold Check this option to apply this hold type during the
Type resolution of another hold type. From the drop-down list,
select the hold type that, upon resolution, triggers this hold
type.
Note: Sterling Selling and Fulfillment Foundation does not
check whether or not you are defining a circular hold type
definition. For example, if you define hold type B as being
applied during the resolution of hold type A, and hold type
A as being applied during the resolution of hold type B, you
could create an infinite loop that Sterling Selling and
Fulfillment Foundation does not warn you against.
When The Following Modification types that automatically apply this hold type to
Modifications Are an order.
Performed
Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available modification
types that you wish to associate with this hold type to the
subscribed list.
v Use the left arrow to unsubscribe the modification types
that you wish to disassociate with this hold type and move
them back into the available list.
For All Order Lines Select this radio button if the above conditions should be
checked for all order lines.
Note: You can only select this option after the created hold
has been saved.

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 185

 Table 79. Hold Type Screen, Hold Creation tab (continued)
Field Description
Only For Order Lines Select this radio button if the above conditions should only be
Satisfying The Following checked for order lines satisfying a certain condition. Click
Condition the Details icon to build or modify the condition that is
evaluated. For more information about using the condition
builder, see the Sterling Selling and Fulfillment Foundation:
Configuration Guide.

The available attributes for this condition can be extended.

For more information about extending condition attributes,
see the Sterling Selling and Fulfillment Foundation: Extending the
Condition Builder.
Note: You can only select this option after the created hold
has been saved.
Hold Created Manually
By Any User Select this radio button if all user groups can apply this hold
to an order.
By Users Who Belong To Select this radio button if only users belonging to certain user
The Following Groups groups may apply this hold to an order.

Click the Details icon to modify the list. In the subsequent

pop-up window:
v Use the right arrow to move the available user groups that
you wish to associate with this hold type to the subscribed
list.
v Use the left arrow to unsubscribe the user groups that you
wish to disassociate with this hold type and move them
back into the available list.

Table 80. Hold Type Screen, Hold Resolution tab

Field Description
Hold Resolved Automatically
The Following From the drop-down list, select the time-triggered transaction
Time-Triggered Transaction that will process the created holds.
Will Process Created Holds
The Following From the drop-down list, select the time-triggered transaction
Time-Triggered Transaction that will process the rejected holds.
Will Process Rejected Holds
Can Resolve On Cancel Select this radio button to automatically remove a hold when
an order is cancelled.
Hold Resolved Manually
Any User Can Process This Select this radio button if all user groups can process this
Hold hold.

186 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 80. Hold Type Screen, Hold Resolution tab (continued)
Field Description
Users Belonging To The Select this radio button if only users belonging to certain user
Following Groups Can groups can process this hold.
Process This Hold
Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available user groups that
you wish to associate with this hold type to the subscribed
list.
v Use the left arrow to unsubscribe the user groups that you
wish to disassociate with this hold type and move them
back into the available list.

Table 81. Hold Type Screen, Hold Effects tab

Fields Description
The Following Transactions Transactions that are disallowed when this hold type is
Will Be Stopped From applied to an order.
Processing Orders On This
Hold Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available transactions that
you wish to associate with this hold type to the subscribed
list.
v Use the left arrow to unsubscribe the transactions that you
wish to disassociate with this hold type and move them
back into the available list.

The third column is used to select the effect level of the hold.
This determines at whether the transaction is held at the
order or order line level.
The Following Modification types that are disallowed when this hold type is
Modifications Are Not applied to an order.
Allowed For Orders On
This Hold Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available modification
types that you wish to associate with this hold type to the
subscribed list.
v Use the left arrow to unsubscribe modification types that
you wish to disassociate with this hold type and move
them back into the available list.

Modifying a Hold Type

About this task

To modify a hold type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific
(Shipping) > Sales Order > Hold Types. The Hold Types window displays in
the work area.
2. Select the applicable hold type and click the Details icon. The Hold Type
pop-up window displays.

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 187

 3. Enter information in the applicable fields. See Table 73 on page 180, Table 74 on
page 181 and Table 75 on page 181 for field value descriptions.
4. Click the Save icon.

Deleting a Hold Type

About this task

To delete a hold type:

Procedure
1. From the tree in the application rules side panel, choose Document Specific
(Shipping) > Sales Order > Hold Types. The Hold Types window displays in
the work area.
2. Select the applicable hold type and click the Delete icon.

Defining Order Tags

About this task

Order Tags enable the system to coordinate which order features are available
across multiple versions of PCAs when they are installed on Sterling Selling and
Fulfillment Foundation. This version awareness makes it possible to schedule an
order in one version of the IBM Sterling Call Center and IBM Sterling Store, for
example, and schedule delivery of that order in another version. If some features
are not available across PCA versions, a message can be displayed to the user
indicating when this is the case.

To define order tags:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Order Tags. The Order Tags window displays
in the work area.
2. Select the applicable order tag and double click to open it or click the Create
New icon to create a new order tag. The Order Tag Detail window is displayed.

Results

Table 82 contains field definitions.

Table 82. Order Tag Detail window
Field Description
Tag ID Select the Tag ID from the pull-down. (This tag is defined in
the Applications Manager Application Platform > Qualified
Tag Information, and must be only a tag of type
y.compatibility. See the Sterling Selling and Fulfillment
Foundation: Configuration Guide for more information.)
Description Enter a description of this tag determination.
Create Order Tags When the Following Criterion Is Met
For Orders Satisfying The If you click this check box, click the Details icon to open the
Following Order Condition Condition Detail pop-up window and define the Condition
ID, Name, Group, and Value under which the tag will be
applied to an order that satisfies these conditions.

188 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 82. Order Tag Detail window (continued)
Field Description
For Orders Satisfying The If you click this check box, click the Details icon to open the
Following Order Line Condition Detail pop-up window and define the Condition
Condition ID, Name, Group, and Value under which the tag will be
applied to an order when an order line satisfies these
conditions.
When The Following If you click this check box, click the Details icon to open the
Modifications Are Modification Type List pop-up window and enable available
Performed Modification Types that define when this condition will be
applied to an order.

Following is an example of the Condition Detail pop-up window, followed by

Table 83, which describes the field definitions.
Table 83. Condition Detail pop-up window

Condition Name Enter the name of the condition for this order tag to be
applied to the order.
Condition ID Enter the ID for this condition.
Condition Value This field contains information you enter in the General
Condition Builder. Click the Details icon to display the
General Condition Builder.

The Sterling Selling and Fulfillment Foundation: Configuration

Guide contains information about Condition Builder
attributes, and the Catalog Management: Configuration Guide
contains information about using the Condition Builder.

The following table describes the fields is the Modifications Type List window.
Table 84. Modifications Type List window
Field Description
Available A list of the available Modification Types and Levels.

To subscribe a Modification Type, select a Modification Type

that has a Level of Order or Order Line. Click the Move
Right arrow.
Subscribed A list of the Modification Types and Levels to which the
Order Tag is subscribed.

To remove a Modification Type from the subscribed list, select

the applicable Modification Type and choose the Move Left
arrow.

Modifying an Order Tag

About this task

To modify an Order Tag:

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 189

 Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Order Tags. The Order Tags window displays
in the work area.
2. Select the applicable Order Tag and click the Details icon. The Order Tag Detail
pop-up window displays. Enter information in the applicable fields. For field
value descriptions, see Table 82 on page 188.
3. Click the Save icon.

Deleting an Order Tag

About this task

To delete an Order Tag:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Order Tags. The Order Tags window displays
in the work area.
2. Select the applicable Order Tag and click the Delete icon.

Defining Fulfillment Rules

About this task

You can define generic rules that Sterling Selling and Fulfillment Foundation uses
at order fulfillment time. These can affect order controls and reservations.

To define fulfillment rules:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Fulfillment Rules. The Fulfillment Rules
window displays in the work area.
2. Enter information in the applicable fields. Refer to Table 85 for field value
descriptions.
3. Click the Save icon.
Table 85. Order Fulfillment window
Field Description
Order Controls
A line can be fulfilled from Check this box if you want any quantity of an order line to
a single node only be shipped from the same ship node. Checking this enables
the three checkboxes below to be checked.
For lines with a firm predefined ship node:
When the line is partially Check this box if you want Sterling Selling and Fulfillment
backordered or Foundation to automatically split partially backordered or
unscheduled, split it into unscheduled lines into two separate lines. This allows the
two separate lines so that a user to manually assign a new ship node for the backordered
different ship node can be portion of the line, so that the entire original order line may
selected for the new line be shipped.
For lines without a firm predefined ship node:

190 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 85. Order Fulfillment window (continued)
Field Description
When the line is partially Check this box if you want Sterling Selling and Fulfillment
backordered or Foundation to automatically split partially backordered or
unscheduled, split it into unscheduled lines into two separate lines. This allows the
two separate lines so that backordered portion of the line to be scheduled and
the sourcing logic can potentially find a new ship node so that the entire original
determine an alternate ship order line may be shipped.
node for the new line
When a complete line is Check this box if you want Sterling Selling and Fulfillment
backordered, backorder Foundation to automatically select the ship node that is
against the highest priority highest in the sourcing priority, even if that ship node is
ship node regardless of the different from the ship node specified on the order line in the
ship node present on the event of a backorder of the complete order line.
line.
When reserving or Check this box if you want Sterling Selling and Fulfillment
scheduling a product line, Foundation to use the node specified on the work order when
use node from the work reserving or scheduling a product line, if no ship node has
order been specified on the order line, or if the node is non-firm. If
a ship node is specified on the order line, Sterling Selling and
Fulfillment Foundation uses that node over the node
specified on the work order.
Allow scheduling of a Check this box if you want Sterling Selling and Fulfillment
product line that is part of Foundation to allow order lines with delivery method set to
a work order, before Delivery to be scheduled when an appointment has not yet
appointment is taken. been taken on the associated service work order.
Note: If scheduling and releasing the order line at the same
time, the order line is not scheduled, even with this flag
enabled.
Reservations
Attempt to reserve the Check this box if you want Sterling Selling and Fulfillment
complete quantity of an Foundation to try to promise the complete quantity of an
order line. order line against reserved inventory.

For example, if an order line is placed for quantity five, and

reserved inventory of quantity three is available, then Sterling
Selling and Fulfillment Foundation reserves quantity three of
that order line.
Reservation is mandatory Check this box if you want Sterling Selling and Fulfillment
for the complete quantity Foundation to always try to use reserved inventory for the
of an order line. complete quantity of an order line. If it is not possible, an
error is thrown.
Inventory reservations Check this box if you want to allow orders to be promised
created for a specific date against inventory that is reserved for a date anterior to the
are valid for all orders with requested ship date.
the same or future ship
date. For example, if an order is placed with a requested ship date
that is three days in the future, and if reserved inventory is
available two days in the future, Sterling Selling and
Fulfillment Foundation enables the order to use that
inventory if this is checked.

If this not checked, only inventory reserved for the same day
as the requested ship date is allowed to be used for order
promising.
Note: This field is primarily for backward compatibility
issues.

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 191

 Table 85. Order Fulfillment window (continued)
Field Description
Suppress the validation of Check this box if you do not want Sterling Selling and
reservations on order line Fulfillment Foundation to check for reservations for existing
modifications. reserved quantity when a modification is made to a
previously reserved order line.

For example, if an order line that has been reserved at Node

1 is modified to be sourced from Node 2, Sterling Selling and
Fulfillment Foundation does not check Node 2's inventory to
ensure it can be reserved there.
Note: This field is primarily for backward compatibility
issues.

Defining Process Type Details

You can define the parameters and templates that distinguish a process type.

For more information about defining process type details, see the Sterling Selling
and Fulfillment Foundation: Configuration Guide.

Order Fulfillment: Process Type Pipeline Configuration

A process type pipeline is a series of transactions and statuses that guide
document types, such as a Sales Order, through a predefined process. A pipeline
consists of the different statuses a document goes through during fulfillment,
negotiation, shipment, or receipt. You can also set up transactions consisting of
events, actions, and conditions, as they pertain to the pipeline you are configuring.

Repositories

A repository is a logical collection of entities that define the business process

workflow.

The following entities are included in a repository:

v Pipelines
v Transactions
v Statuses
v Conditions
v Actions
v Services

Sterling Selling and Fulfillment Foundation provides a base repository for each of
the system defined process types. Some of the entities within a repository are
copied when creating a new document type. For more information about creating a
new document type, see the Sterling Selling and Fulfillment Foundation: Configuration
Guide.

The process of order fulfillment is modeled through a pipeline. This represents the
process configuration that is unique to an organization. An organization may also
specify unique processes for each participating Enterprise.

192 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Order Fulfillment: Defining Pipeline Determination
Pipeline determination is used to set up conditions that affect which pipeline is
used during the start of the business process workflow. For example, an
organization deals with sales orders that sometimes contain hazardous materials.
They have two separate pipelines, one in which orders with order lines without
any hazardous materials go through and one in which orders with order lines
containing hazardous materials must go through for inspection before continuing
through the order process. The organization uses pipeline determination to set up
a condition that determines whether or not order lines contain hazardous materials
and sends the order line down the correct pipeline.

When you expand the Pipeline Determination branch, the components displayed
depends on what role you are logged in as. If you are logged in as a Hub role, the
Hub Rule displays. If you are logged in as an Enterprise role, both the Hub Rule
and My Rule components display. Double-click on the applicable node to display
the pipeline determination rules.

Note: If you are logged in as an Enterprise role, the Hub Rule screen is grayed out
and cannot be modified.

Drag conditions and pipelines into the work area to construct pipeline
determination rules. A single pipeline or condition must be the root. Conditions
cannot link back to an earlier component in the chain and a pipeline cannot be
linked to twice.

Note: When configuring pipeline determination for an order document type

pipeline, please note that pipeline determination is only considered when adding a
line or creating an order. When changes are made to draft orders pipeline
determination does not occur.

Order Fulfillment: Condition Variables for Pipeline Determination

For a list of the condition variables that can be used at the order header and order
line level for pipeline determination, refer to “Condition Builder Attributes” on
page 467.

Order Fulfillment: Pipelines

About this task

For more information about configuring pipelines, see the Sterling Selling and
Fulfillment Foundation: Configuration Guide.

To view the order fulfillment pipeline details:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Fulfillment Process Model. The Order
Fulfillment window displays.
2. In the Order Fulfillment window, choose Order Fulfillment Repository >
Pipelines > Sales Order Fulfillment.
3. The Pipeline Detail: Sales Order Fulfillment (Order Fulfillment) window
displays.

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 193

 Results

For more information about creating and modifying a pipeline, see the Sterling
Selling and Fulfillment Foundation: Configuration Guide.

Order Fulfillment: Transactions

About this task

Every process type has a set of base transactions defined for it. A transaction is a
logical unit of work that is necessary for performing activity within Sterling Selling
and Fulfillment Foundation. Base transactions are predefined transactions that
contain information about how the transaction behaves, such as how many copies
of a transaction can be kept in a process type and whether or not it can have
configurable base pick and drop statuses. Base transactions can be used to create
new transactions. These transactions can be changed within the limits defined in
the base transaction.

For more information about Transactions, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To view the transaction details for an order fulfillment pipeline:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Fulfillment Process Model. The Order
Fulfillment window displays.
2. In the Order Fulfillment window, choose the Transactions icon.
3. The Transactions tab window displays.

Results

For more information about creating and modifying transactions, see the Sterling
Selling and Fulfillment Foundation: Configuration Guide.

194 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 86. Order Fulfillment Pipeline - Transactions Tab Window
Field Description
Chained Order Create This transaction represents a point in the pipeline where a
chained order is created.
Change Order This transaction represents any modifications that may be
made to an order.
Change Order Release This transaction represents any modifications that may be
made to an order release.
Change Schedule This transaction represents any modifications that may be
made to the scheduling determinations for an order or order
line.
Change Status This transaction represents any modifications that may be
made involving an order or order line's status.
Close Order This transaction represents an order being closed and
archived in the system.
Confirm Draft Order This transaction represents a draft order is manually
confirmed and considered an actual order in the system.
Consolidate To Shipment This transaction the process of finding a shipment into which
a given order release can be included.
Create Draft Order This transaction represents the creation of a draft order in the
system.
Create Order This transaction represents the creation of an order in the
system.
Enhanced Order Monitor This transaction represents the advanced set of parameters
used to monitor orders in the system.
Import Order This transaction represents the process of importing an order
that has already been processed to some extent by an external
system.
Include In Return This transaction represents the process of creating a return.
Include Order In Shipment This transaction represents the process of creating a shipment.
Order Monitor This transaction represents the basic set of parameters used to
monitor orders in the system.
Payment Collection This transaction represents the process of requesting credit
validation for orders that are pending authorization or
charging.
Payment Execution This transaction represents the processing of all requests that
are pending authorization and charging.
Purge Order This transaction represents an order that can be purged
moved from the tables into history tables.
Purge Order History This transaction represents the process of purging orders from
the history tables and removing them from the system.
Purge Status Audit This transaction represents the process of removing order
status audit data from the system.
Receive Negotiation This transaction represents receiving negotiation requests
from the Buyer on the order. After a negotiation is finished,
this transaction applies the results of the negotiation to the
order.
Receive Return This listener transaction monitors the reverse logistics
pipeline and indicates when the return for an order has been
received at the receiving node.

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 195

 Table 86. Order Fulfillment Pipeline - Transactions Tab Window (continued)
Field Description
Release Order This transaction represents the process of releasing orders to
specific ship nodes, making sure that the scheduled ship
nodes have enough inventory to process the order.
Remove From Return This transaction represents the process of removing an order
from an existing return.
Remove Order From This transaction represents the process of removing an order
Shipment from an existing shipment. This transaction internally invokes
the confirmShipment API. See the Sterling Selling and
Fulfillment Foundation: Javadocs for more information.
Schedule Order This transaction represents the process of scheduling orders
to specific ship nodes making sure that the scheduled ship
nodes have enough inventory to process the order.
Send Invoice This transaction represents the process of publishing invoice
data that can be directed to an external accounts receivable
systems.
Send Release This transaction represents the process of dispatching releases
to ship nodes.
Ship Order This transaction represents the process of an order being
shipped when no shipment data has been created. This
transaction internally invokes the confirmShipment API. See
the Sterling Selling and Fulfillment Foundation: Javadocs for
more information.
Ship Shipment This transaction represents the process of an order being
shipped after shipment data is created. This transaction
internally invokes the confirmShipment API. See the Sterling
Selling and Fulfillment Foundation: Javadocs for more
information.
Start Negotiation - Order This transaction represents the process of initiating the
negotiation process with the Buyer on an order.
Synchronize Task Queue This transaction represents the process of synchronizing the
order fulfillment task queue.
Unschedule Order This transaction represents the process of unscheduling an
order that has already been scheduled to a ship node.
Work Order to Order This listener transaction notifies the pipeline of work order
Listener completion.

Order Fulfillment: Statuses

About this task

Statuses are the actual states that a document moves through in the pipeline. A
transaction can contain two types of statuses, a drop status and a pickup status. A
document is moved into a drop status when the events and conditions of a
transaction have been completed. A pickup status takes the document from the
previous drop status and moves it through the next transaction. Created and
Scheduled are examples of statuses.

For more information about Statuses, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To view the status details of an order fulfillment pipeline:

196 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Fulfillment Process Model. The Order
Fulfillment window displays.
2. In the Order Fulfillment window, choose the Statuses icon.
3. The Statuses tab window displays.

Results

For more information about creating and modifying statuses, see the Sterling Selling
and Fulfillment Foundation: Configuration Guide.
Table 87. Order Fulfillment Pipeline - Statuses Tab Window
Field Description
Draft Order Created This indicates that a draft order has been created.
Created This indicates that an order has been created.
Reserved This indicates the order has been created, but it is not ready
to schedule yet.
Being Negotiated This indicates that the order is undergoing the negotiation
process with the Buyer on the order.
Accepted This indicates that an order has been manually accepted.
Backordered This indicates that an order is backordered until sufficient
inventory is available.
Unscheduled This indicates that the order has been removed from
Scheduled status and any inventory that has been reserved
for the order at the scheduled node(s) is canceled.
Backordered From Node This indicates that the order has been created and released to
the node, but the node does not have enough inventory to
fulfill the order.
Scheduled This indicates that the applicable node(s) have the inventory
to fulfill the order and can be scheduled for release.
Awaiting Chained Order This indicates that the wave has been printed for picking.
Creation
Chained Order Created This indicates that a chained order must be created and sent
to the applicable node.
Procurement PO Created This indicates that a procurement purchase order has been
created.
Procurement PO Shipped This indicates that a procurement purchase order has been
shipped.
Procurement TO Created This indicates that a procurement transfer order has been
created.
Procurement TO Shipped This indicates that a procurement transfer order has been
shipped.
Work Order Created This indicates that a work order has been created.
Work Order Completed This indicates that a work order has been completed.
Released This indicates that there is enough inventory to schedule to
the order for fulfillment. The order is released to the
Application Consoles, the Sterling Warehouse Management
System version 9.1, or another third-party warehouse
management system.

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 197

 Table 87. Order Fulfillment Pipeline - Statuses Tab Window (continued)
Field Description
Awaiting Shipment This indicates that the order is to be grouped and
Consolidation consolidated with other shipments before it continues
through the pipeline.
Awaiting WMS Interface This indicates that the order must interface with the Sterling
Warehouse Management System version 9.1 before continuing
in the pipeline.
Sent To Node This indicates that the order is sent in the form of an order
release.
Included In Shipment This indicates that the order is included in a shipment.
Shipped This indicates that the order has been shipped
Return Created This indicates that the Buyer is returning one or more items
included in the order.
Return Received This indicates that returned items have been received at the
return node.
Held This indicates that the order is being held and no
modifications can be made until it is released from the hold.
Shipment Delayed This indicates that all or part of the order shipment has been
delayed.
Cancelled This indicates that the order has been canceled.
Shorted This indicates that the order contains less quantity than
requested.

Order Fulfillment: Conditions

About this task

A condition matches document type attributes against decision points and routes
the documents to different paths based on the specified attribute and value
combinations. The document type attributes against which conditions can be
created are predefined in Sterling Selling and Fulfillment Foundation. You can use
these attributes in any combination or you can create conditions that run the
appropriate application logic for specific circumstances.

For more information about conditions, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To view the condition details of an order fulfillment pipeline:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Fulfillment Process Model. The Order
Fulfillment window displays.
2. In the Order Fulfillment window, choose the Conditions icon.
3. The Conditions tab window displays.

Results

For more information about creating and modifying conditions, see the Sterling
Selling and Fulfillment Foundation: Configuration Guide.

198 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 88. Order Fulfillment Pipeline - Conditions Tab Window
Field Description
Conditions Displays conditions that are specific to the order fulfillment
pipeline, if any.

Order Fulfillment: Actions

About this task

An action is a process or program that is triggered by an event. These processes

and programs send user alert notifications and automatically resolve issues.

For example, when an order is released (the event), you can set an action to send
the customer an e-mail.

For more information about Actions, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To view the action details of an order fulfillment pipeline:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Fulfillment Process Model. The Order
Fulfillment window displays.
2. In the Order Fulfillment window, choose the Actions icon.
3. The Actions tab window displays.

Results

For more information about creating and modifying actions, see the Sterling Selling
and Fulfillment Foundation: Configuration Guide.

Defining Transaction Rules

About this task

You can define additional rules for shipment advice, shipment confirmation, order
entry, order monitoring, and negotiation monitoring.

Note: To define additional transaction rules for quotes, refer to 'Defining

Transaction Rules for Quotes".

To define additional transaction rules:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Transaction Specific Rules. The Transaction
Rules window displays.
2. Enter information in the applicable fields. Refer to the following table for field
value descriptions.
3. Choose the Save icon.

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 199

 Table 89. Transactions Rules Window
Field Description
Ship Advice
Include Price Information When selected, the system sends down price information on
in Instruction the order as a part of the ship advice instructions.

This is a DCS-specific parameter. Key price-related elements

from Sterling Selling and Fulfillment Foundation is sent to
DCS as instructions of type SHC (shipping and handling
charges at order header level), PRM (discount amount at the
order header level), and STX (tax at the order header level).
Ship Confirm
Cancel Order on Inventory When selected, items are canceled or backordered in case of
Shortage inventory shortage.
Note: This flag is used by the confirm shipment agent; it is
not used by the confirmShipment API. If you want to cancel
warehouse backorders, you need to pass the
CancelRemovedQuantity=Y flag in the changeShipment API.
Order Monitor
Order Monitor Relog Enter the number of hours after which the order monitor
Interval raises an action if a document type remains in the same
status in a pipeline.

The Inventory Monitor and Order Monitor run at predefined

(scheduled) intervals. Once an alert is raised, the same alert
should not be raised over and over again at every run. Relog
intervals control how soon after the previous alert the next
alert should be triggered.

Important: This field has no impact on the Enhanced Order

Monitor.
Negotiation Monitor
Negotiation Monitor Relog Enter the number of hours after which the Negotiation
Interval Monitor raises an action if a document type remains in the
same status in a negotiation pipeline.
Post Voided Sale on Order
Mark Post Voided Sale for Enter the number of hours based on which the auto-cancel
Auto-Cancellation After date is set on the order.
Reship Order
Minimum Reship Window Enter the minimum number of days allowed to pass after an
order line has been shipped before an order line may need to
be reshipped.
Action to take on parent line when chained line is canceled
Unschedule When selected the unschedule action is performed on the
parent order line when a chained order line is canceled. An
unscheduled parent line is synonymous with a backordered
line. For more information about chained orders, see the
Sterling Selling and Fulfillment Foundation: Configuration Guide.
Cancel When selected the parent line is canceled when a chained
order line is canceled. For more information about chained
orders, see the Sterling Selling and Fulfillment Foundation:
Configuration Guide.
Cancellation of Order Lines with Work Orders

200 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 89. Transactions Rules Window (continued)
Field Description
Allow Cancellation Even If An order may have generated a work order to customize the
Work Order Cannot Be item for the customer. In some scenarios, the work order
Cancelled cannot be cancelled. For example, the work order cannot be
cancelled because the work order has already been
completed, or because the work order is performed by an
organization that does not accept work order cancellations.

By default, the order associated with the work order cannot

be cancelled. Select ‘Allow Cancellation Even If Work Order
Cannot Be Cancelled' to permit the parent orders to be
cancelled if the work order cannot be cancelled.
Synchronize Dates
Synchronize Dates Between Check this box to synchronize the requested dates and the
Master Order Dates And expected ship dates for the Order, Order Header, Order Line,
Dates On Order Line And and Order Line Schedules.
Schedules
The requested dates synchronize with the requested ship,
requested deliver, and cancel dates on the order line or
header.

The expected dates synchronize with the order schedules.

Note: If this rule is not chosen, the synchronization between
dates is not possible.
Expected Dates On Order
Do Not Recompute Check this box when you do not want the requested dates on
Expected Dates When the order line to be synchronized with the expected dates on
Requested Dates On The the order line schedule.
Order Are Changed Note: The dates are synchronized only during the line
creation.
Note: Scheduling should not be used on orders which have
expected and requested dates that are not synchronized.
Pickup Order Lines
Compute Expected Dates Check this box to recompute the expected ship date of an
When Requested Dates On item when a customer chooses to pick up either a portion of
The Pickup Order Lines an order or the complete order at a later date.
Are Changed Note: This flag is available for outbound orders only.
Confirm Draft Order
Update Order Date On Check this box to set the order date to the date when the
Confirm Draft Order order is confirmed and not the date when the order is
created.
Action To Take When Unscheduling Last Product Line
Keep Association To When selected, if the last product line on a work order is
Delivery Service Line cancelled, the association with the delivery line is kept.
Remove Association To When selected, if the last product line on a work order is
Delivery Service Line cancelled, the association with the delivery line is removed.
Order Approval

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 201

 Table 89. Transactions Rules Window (continued)
Field Description
Hold Type To Be Applied Select the hold type you want to be applied when an order
When Order Needs requires approval.
Approval
The hold is triggered internally by the system, and therefore,
should not be set to automatically apply in the hold
configuration.
Note: This functionality differs from the Order Approval
functionality for Quotes.
Automatically Resolve Check this box if you want order approval holds to be
Order Approval Hold On resolved automatically when an order is changed and the
Order Change conditions necessary to require approval are no longer met.
Customer Contact Status
Hold Type To Be Applied Select the hold type you want to be applied on an order
To An Order When when a customer contact is on hold.
Customer Contact Is On
Hold
Pending Order Changes
Pending Order Changes Enter the number of hours after which the pending changes
Will Expire In on the order will expire.
Hold To Be Applied When Select the hold type you want to be applied on an order that
Order Has Pending has pending changes.
Changes

Defining Transaction Rules for Quotes

About this task

You can define additional rules for quotes, as follows:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
Quote > Fulfillment > Transaction Specific Rules. The Transaction Specific Rules
window displays.
2. Enter information in the applicable fields. Refer to Table 90 for field value
descriptions.
3. Choose the Save icon.
Table 90. Transaction Rules Window for Quotes
Field Description
Order Monitor
Order Monitor Relog Enter the number of hours after which the order monitor
Interval raises an action if a quote remains in the same status in the
pipeline.

Once an alert is raised, the same alert should not be raised

over and over again at every run. Relog intervals control how
soon after the previous alert the next alert should be
triggered.

Important: This field has no impact on the Enhanced Quote

Monitor.

202 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 90. Transaction Rules Window for Quotes (continued)
Field Description
Expected Dates On Order
Do Not Recompute Check this box when you do not want the requested dates on
Expected Dates When the order line to be synchronized with the expected dates on
Requested Dates On The the order line schedule.
Order Are Changed Note: The dates are synchronized only during the line
creation.
Order Approval
Hold Type To Be Applied Select the hold type you want to be applied when an order
When Order Needs requires approval.
Approval Note: The hold is triggered internally by the system, and
therefore, should not be set to automatically apply in the hold
configuration.

Defining Status Inventory Types

You can define how and when inventory is updated for Sellers and Buyers
tracking inventory, on a status-by-status basis. The Status Inventory Types table is
used to associate statuses with specific supply and demand types according to
organization. When an order moves through the statuses of a given fulfillment
pipeline the values corresponding to the Buyer supply type and Seller demand
type associated with the original status are decreased and the values for the status
the order is moving into are increased.

Example

Assume you have the following records in the Status Inventory Type table:
Table 91. Sample Status Inventory Type Records
Buyer Supply Seller Demand Increment Seller
Status Type Type Seller Supply Type Supply
1100 Purchase Open Order Onhand N
Order Placed
3200 Purchase Released Onhand N
Order Released
3700 Intransit Y

When an order with a line item quantity of 10 is created in Created (1100) status,
the Purchase Order Placed supply record is updated with a quantity of 10. A Open
Order demand type with a quantity of 10 is created for the Seller.

In this example, if a quantity of 3 is moved into Released (3200) status, the

Purchase Order Placed supply record is decreased by 3 and a new supply record
with a quantity of 3 is created for the Purchase Order Released supply type. The
Open Order demand record is also decreased by 3 and a new demand record is
with a quantity of 3 is created for the Released demand type.

When the order moves from Released (3200) status to Shipped (3700) status, the
Buyer's supply is decreased for the Purchase Order Released supply type and
increased for Intransit. The Seller's demand is decreased for the Released demand

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 203

 type. However, the demand type is not increased for a new type, because the Seller
Demand Type associated with the Shipped (3700) status is blank.

In the above configuration, the Increment Seller Supply flag is set to 'Y' and the
Seller's supply type for the Shipped (3700) status is Onhand. The Increment Seller
Supply flag indicates that the Seller's supply must be adjusted when moving any
quantity into the Shipped (3700) status.

The value in the Seller Supply Type column indicates the supply type that should
be updated, in this example, Onhand. Since the record for the Released (3200)
status has the Onhand Seller supply type associated with it and the Shipped (3700)
status record has a blank Seller supply type associated with it, the Onhand Seller
supply type decreases when moving from Released (3200) status to Shipped (3700)
status. The Seller supply type is not increased with this status move because the
value in the Seller Supply Type column for the Shipped (3700) status is blank.

To view a process type's status inventory types, from the tree in the application
rules side panel, choose Document Specific > (Document Type) > Fulfillment >
Status Inventory Types. The Status Inventory window displays. Refer to Table 92
for assistance.
Table 92. Status Inventory Types Window
Field Description
Orders Without Select the Orders Without Chaining tab to view the status
Chaining/Orders With inventory types for orders that flow through the process
Chained type pipeline without having any associated chained orders.
Children/Procurement
Orders Select the Orders With Chained Children tab to view the
status inventory types of orders having associated
drop-ship chained orders.

Select the Procurement Orders tab to view the status

inventory types of procurement orders.
Status The order document's status.
Buyer Supply Type The Buyer's supply type associated with the order
document's status.
Seller Supply Type The Seller's supply type associated with the order
document's status.
Update Seller Supply Indicates if inventory updates are made when an order
document moves into the associated status.
Seller Demand Type The Seller's demand type associated with the order
document's status.

For more fundamental and detailed information about supply and demand types
and how they relate to each other, refer to the Sterling Selling and Fulfillment
Foundation: Global Inventory Visibility Configuration Guide.

Creating a Status Inventory Type

About this task

To create a status inventory type:

204 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Procedure
1. In the Status Inventory Types window, choose the Create New icon. The Status
Inventory Type Details window displays.
2. Enter information in the applicable fields. Refer to Table 93 for field value
descriptions.
3. Choose the Save icon.
Table 93. Status Inventory Type Details Window
Field Description
Status Select the order document status that you want to associate
inventory types with.
Buyer Supply Type Select the Buyer supply type that you want to associate with
the order document status.
Seller Supply Type Select the Seller supply type that you want to associate with
the order document status.
Update Seller Supply Select this field if you want inventory updates to be
performed on the associated inventory types when the order
document enters this status.
Note: If you are integrating with Sterling Warehouse
Management System version 9.1, this field must be selected
and you must specify the Seller Supply Type.
Seller Demand Type Select the Seller demand type that you want to associate with
the order document status.

Modifying a Status Inventory Type

About this task

To modify a status inventory type:

Procedure
1. In the Status Inventory Types window, locate the applicable status inventory
type and choose the Details icon. The Status Inventory Type Details window
displays.
2. Enter information in the applicable fields. Refer to Table 93 for field value
descriptions.
3. Choose the Save icon.

Deleting a Status Inventory Type

About this task

To delete a status inventory type, locate the applicable status inventory type in the
Status Inventory Types window and choose the Delete icon.

Default status inventory types which are originally shipped with Sterling Selling
and Fulfillment Foundation cannot be deleted.

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 205

Defining Quote Rules
About this task

You can define additional rules that are specific to the Quote document type.

To define additional quote rules:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
Quote > Fulfillment > Quote Rules. The Quote Rules window displays.
2. Enter information in the applicable fields. Refer to Table 94 for field value
descriptions.
3. Choose the Save icon.
Table 94. Quote Rules Window
Field Description
Expiration Policy Before Presenting Quote To Buyer
Recalculate Expiration Date Select this check box if you want to recalculate the
expiration date before presenting a quote to a buyer.
Default Expiration Period By default, the expiration period is 30 days. However,
(Number Of Days) you can change the expiration period, as required. The
quote will expire after the specified number of days.
Recommended Items
Quote Line Type To Use For Select the quote line type you want to use for
Recommended Items recommended items from the drop-down list.

Defining Monitoring Components

You can define the components used to measure and report unexpected conditions
and delays in the order document's lifecycle. For more information about using
these components to configure monitoring rules, see the Sterling Selling and
Fulfillment Foundation: Configuration Guide.

To define a process type's monitoring components, from the tree in the application
rules side panel, choose Document Specific > (Document Type) > Fulfillment >
Order Monitoring. The Monitoring window displays.

Order Fulfillment: Defining Date Types

You can define custom date types. These dates automatically appear in the
configuration screen and the Order/Shipment Dates window in the Console.

Order Fulfillment: Creating a Date Type

About this task

To create a date type:

Procedure
1. In the Monitoring window, choose the Date Types tab.
2. From the Date Types list, choose the Create New icon. The Date Type Details
window displays.

206 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
3. Enter information in the applicable fields. Refer to Table 95 for field value
descriptions.
4. Choose the Save icon.
Table 95. Date Type Details Window
Field Description
Date Type Enter the name of the date type.
Description Enter a brief description of the date type.
Requested Check this box to indicate if the date type represents a date
requested by a Buyer, user, and so forth.
Expected Check this box to indicate if the date type represents the date
that the system expects or has calculated something to occur.
Actual Check this box to indicate if the date type represents the
actual date.
Committed Check this box to indicate if the date type represents a
committed date.

Order Fulfillment: Modifying a Date Type

About this task

To modify a date type:

Procedure
1. In the Monitoring window, choose the Date Types tab.
2. From the Date Types list, locate the applicable date type and choose the Details
icon. The Date Type Details window displays.
3. Enter information in the applicable fields. Refer to Table 95 for field value
descriptions.
4. Choose the Save icon.

Order Fulfillment: Deleting a Date Type

About this task

To delete a date type:

Procedure
1. In the Monitoring window, choose the Date Types tab.
2. From the Date Types list, locate the applicable date type and choose the Delete
icon.

Results

The following system dates cannot be deleted:

v Delivery Date
v Order Date
v Ship Date
v Next Iteration Date

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 207

 Order Fulfillment: Defining Milestones
You can configure applicable statuses in a process type to be milestones. A
milestone is a type of date that Sterling Selling and Fulfillment Foundation
automatically determines when an order moves from one status to another. A
milestone represents a significant point in the processing lifecycle that can be used
as a criterion for monitoring. Milestones can be defined at the order, order line,
order release, and order release line levels.

A milestone can be reached whenever there is a change in an order line. Sterling

Selling and Fulfillment Foundation marks a milestone as reached if an order line
reaches a status marked as a milestone. However, there may be times that only
part of an order line reaches a particular status defined as milestone.

Order Fulfillment: Creating a Milestone

About this task

To create a milestone:

Procedure
1. In the Monitoring window, choose the Milestones tab.
2. From the Milestones list, choose the Create New icon. The Milestone Details
window displays.
3. Enter information in the applicable fields. Refer to Table 96 for field value
descriptions.
4. Choose the Save icon.
Table 96. Milestone Details
Field Description
Date Type Enter the name of the milestone being created.
Note: You cannot use date types you have created on the
date type tab. You must create a unique name for the
milestone.
Description Enter a brief description of the milestone.
Requested Select this field to indicate if the milestone represents a date
requested by a Buyer, user, etc.
Expected Select this field to indicate if the milestone represents a date
the system expects or has calculated something to occur.
Actual This field is not applicable for milestones.
Committed Select this field to indicate if there is a committed date
available for this date type.

Order Fulfillment: Creating a Status Milestone:

About this task

To create a Status Milestone:

Procedure
1. From the Milestone Details window, choose the Milestone Statuses tab.
2. From the Status Milestones list, choose the Create New icon. The Status
Milestone Details window displays.
3. Enter information in the applicable fields. Refer to Table 97 on page 209 for
field value descriptions.
208 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 4. Choose the Save icon.
Table 97. Status Milestone Details
Field Description
Date Type The date type if any associated with the milestone.
Status Select the status you want use to indicate the milestone has
been reached.
Milestone Level Select Order to indicate this status must be reached at the
order header level.

Select Order Line to indicate that this status must be reached

at the order line level.

Select Order Release to indicate that this status must be

reached at the order release level.
Quantity Type Select Initial to indicate that the milestone is met when any
quantity at the above selected level moves into the status.

Select Complete to indicate that the milestone is met when all

quantity at the above selected level moves into the status.

Order Fulfillment: Modifying a Milestone

About this task

Note: If modifications are made to an existing milestone, the changes are only
applied to new orders. Existing orders for which milestone records have already
been created are not considered.

To modify a milestone:

Procedure
1. In the Monitoring window, choose the Milestones tab.
2. From the Milestones list, locate the applicable milestone and choose the Details
icon. The Milestone Details window displays.
3. Enter information in the applicable fields. Refer to Table 96 on page 208 for
field value descriptions.
4. Choose the Save icon.

Order Fulfillment: Deleting a Milestone

About this task

To delete a milestone:

Procedure
1. From the Monitoring window, choose the Milestones tab.
2. From the Milestones list, locate the applicable milestone and choose the Delete
icon.

Order Fulfillment: Defining Monitoring Events

Events are used in instances where the Enhanced Order Monitor may raise
multiple alerts of the same type. For example, if an order with multiple lines that
are shipped together has a shipment delay and you have configured the Enhanced
Order Monitor to raise alerts when shipments are delayed at the line level, an alert

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 209

 of the same type would be raised against each line in the order. You can create
rules to aggregate all of these similar alerts and raise one "root cause".

Order Fulfillment: Creating an Event Rule

About this task

To create an event rule:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Monitor Events. The Monitor Events window
displays.
2. From the Monitor Events list, choose the Create New icon. The Monitor Events
Details window displays.
3. Enter information in the applicable fields. Refer to Table 98 for field value
descriptions.
4. Choose the Save icon.
Table 98. Monitor Event Details Pop-Up Window
Field Description
Event ID Enter the event ID.
Description Enter a brief description of the event.
Requires Realert Select this field if you want users to be re-alerted if the issue
has not been resolved within a certain timeframe.
Realert Interval If you selected Requires Realert, enter the interval (in hours)
that re-alerts should be sent.
Automatically Resolve This flag must be checked to trigger a monitor event every
Alerts time an alert condition is detected on an order. To trigger an
alert only once when the alert condition is met, uncheck this
flag.
Event Identified By
Order Select this field if you want two or more alert conditions to
be treated the same if they belong to the same order.
Note: This field can be selected in conjunction with Order
Line and/or Order Release fields.
Order Line Select this field if you want two or more alert conditions to
be treated the same if they belong to the same order line.
Note: This field can be selected in conjunction with Order
and/or Order Release fields.
Order Release Select this field if you want two or more alert conditions to
be treated the same if they belong to the same order release.
Note: This field can be selected in conjunction with Order
and/or Order Line fields.
Ship Node Select this field if you want two or more alert conditions to
be treated the same if they belong to the same ship node.
Note: This field must be used in conjunction with the Order,
Order Line, and/or Order Release fields.
Seller Organization Select this field if you want two or more alert conditions to
be treated the same if they belong to the same Seller.
Note: This field must be used in conjunction with the Order,
Order Line, and/or Order Release fields.

210 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 98. Monitor Event Details Pop-Up Window (continued)
Field Description
Buyer Organization Select this field if you want two or more alert conditions to
be treated the same if they belong to the same Buyer.
Note: This field must be used in conjunction with the Order,
Order Line, and/or Order Release fields.
Service To Be Invoked Select the alert service to be invoked should the event
consolidation rule conditions be met.
Aggregate And Invoke Service For
Order Select this field if you want only one alert to be raised for an
order when alert conditions are detected.
Order Line Select this field if you want only one alert to be raised per
order line when alert conditions are detected.
Order Release Select this field if you want only one alert to be raised for an
order release when alert conditions are detected.
Ship Node Select this field if you want only one alert to be raised for a
particular ship node when alert conditions are detected.
Seller Organization Select this field if you want only one alert to be raised for a
particular Seller when alert conditions are detected.
Buyer Organization Select this field if you want only one alert to be raised for a
particular Buyer when alert conditions are detected.

Note: In most cases the attributes that identify an event should be a subset of
the attributes that specify event aggregation.

Order Fulfillment: Modifying an Event

About this task

To modify an event rule:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Monitor Events. The Monitor Events window
displays.
2. From the Monitor Events list, select the applicable event rule and choose the
Details icon. The Monitor Event Details window displays.
3. Enter information in the applicable fields. Refer to Table 98 on page 210 for
field value descriptions.
4. Choose the Save icon.

Order Fulfillment: Deleting an Event

About this task

To delete an event rule:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Monitor Events. The Monitor Events window
displays.

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 211

 2. From the Monitor Events list, select the applicable event rule and choose the
Delete icon.

Defining Transaction Dependencies

Transaction dependency enables you to process an order based on certain
conditions defined for a transaction. It provides the ability for a transaction to
allow some order lines to not be processed until certain conditions are met. These
conditions can also apply to other lines in the same order.

For example, a customer orders a DSL modem along with the DSL line activation
service. In this scenario, the modem cannot be shipped until the account is
activated. As a result, you need to sequence the order. The sequencing of the order
can be based on:
v Transaction completion of certain lines, such as the account activation being
completed before the modem could be shipped.
v Specific dates, such as not to ship the modem until 5 days before the activation
date.

Note: The above mentioned rules, do not apply for all types of order lines.
Bundle order fulfillment cannot be configured with the transaction or date-type
dependency because the order lines can have interdependencies such that a
bundle parent line cannot move forward in the pipeline until all the child lines
are fulfilled.

You can configure transaction dependencies in groups, with one dependency group
being active at a time. The dependencies are configured at an enterprise, document
type, or process type level and are applied while processing the order. If necessary,
the enterprise level inheritance can be used.

The dependencies are configured in two steps:

v The dependent lines are configured by specifying the item ID, classification, or a
service type. An optional condition builder is also included to identify lines
based on other order lines and header attributes such as a line type.
v Once the rules are defined, you can configure additional constraints based on
either of the dependency types:
– Transaction Based
– Date Based
Each of these dependencies are modeled as a constraint accounting for
approximately 20 different template types serving the general, bundle, and
item attributes.

The limitations assumed by transaction dependencies are:

v The dependency rules specified by a transaction is independent of the pipeline
or the order.
v Even though transaction dependency can understand the relationship between
multiple lines and dates, it does not take into consideration all the due date
dependencies. For example, if the DSL activation due date is modified, the
dependency does not identify how much longer the other dependent lines can
be delayed.

212 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Defining a Default Dependency Group
About this task

To define a Default Dependency Group:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Transaction Dependencies. The Transaction
Dependency window for the chosen document type displays.
2. In the Default Dependency Group field, select one of the available transaction
dependency groups from the drop-down list. Refer to Table 99 for field value
descriptions.
3. Choose the Save icon.
Table 99. Transaction Dependency Window
Field Description
Default Dependency Group Select the default transaction dependency group to use.
Transaction Dependency Groups

For more information about creating a transaction dependency group, see “Creating a
Transaction Dependency Group.”
Group The name of the transaction dependency group.
Group Description The description of the transaction dependency group.

Creating a Transaction Dependency Group

About this task

To create a Transaction Dependency Group:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Transaction Dependencies. The Transaction
Dependency window for the chosen document type displays.
2. From the Transaction Dependency Groups list, choose the Create New icon.
The Transaction Dependency Group Detail window displays.
3. Enter information into the applicable fields. Refer to Table 100 for field value
descriptions.
4. Choose the Save icon.
5. After saving the transaction dependency group, you can add transaction
dependency rules to the group. For more information refer to “Creating a
Transaction Dependency Rule” on page 214.
Table 100. Transaction Dependency Group Detail Window
Field Description
Group Enter the name of the transaction dependency group.
Group Description Enter the description of the transaction dependency group.
Transaction Dependency Rules

For more information about creating a transaction dependency rule, see “Creating a
Transaction Dependency Rule” on page 214.

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 213

 Table 100. Transaction Dependency Group Detail Window (continued)
Field Description
Transaction Dependency The name of the transaction dependency rule.
Name
Transaction Name The transaction allowed to run based on this transaction
dependency.

Creating a Transaction Dependency Rule

About this task

To create a transaction dependency rule:

Procedure
1. From the Transaction Dependency Group Detail window, choose the Create
New icon from the Transaction Dependency Rules list. The Transaction
Dependency Rule Detail window displays.
2. Enter information into the applicable fields. Refer to Table 101 for field value
descriptions.
3. Choose the Save icon.
Table 101. Transaction Dependency Rule Detail Window
Field Description
Dependency Enter the name for this transaction dependency.
Apply Dependency To Any From the drop-down list, select the criterion you want to use
Order Line Having for the order lines to which this dependency can be applied.

Depending on the criterion you select, you may have to

indicate specific items, or service types. To specify these items
or service types, choose the Details icon.. The corresponding
list screen displays.
Condition The condition that is created for this transaction dependency
rule. The order fulfillment condition builder displays.

For more information about creating conditions, see the

Sterling Selling and Fulfillment Foundation: Configuration Guide.

The field values of the order fulfillment condition builder are

provided in the ORDER_TRANDEP_CONDITION template.

<OrderLine LineType="" OrderedQty="">

<LinePriceInfo LineTotal="" UnitPrice=""/>
<Order BuyerOrganizationCode="" EnterpriseCode=""
OrderType="" SellerOrganizationCode=""/>
</OrderLine>
Note: The Zoom In icon is disabled in the condition builder
screen since there are no related entities affected by this
condition.
Allow Transaction To From this drop-down list, select the transaction that is
Execute Only If The allowed to run based on the conditions indicated in this
Following Conditions Are transaction dependency rule.
Met
Dependency Rule Constraints

214 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 101. Transaction Dependency Rule Detail Window (continued)
Field Description
The dependency constraints are populated based on the created rule. For information about
creating the dependency rule constraints, see “Creating a Dependency Rule Constraint.”

Creating a Dependency Rule Constraint:

About this task

To create a dependency constraint rule:

Procedure
1. From the Transaction Dependency Rule Detail window, choose the Create New
icon from the Dependency Rules Constraint List. The Constraint Detail window
for the chosen document type displays.
2. Enter information into the applicable fields. Refer to Table 102 for field value
descriptions.
3. Choose OK.
Table 102. Constraint Detail Window
Field Description
Transaction Based Choose this option if this dependency is transaction based,
Dependencies and select the constraint type you want to use from the
drop-down list.
Date Type Based Choose this option if this dependency is date type based, and
Dependencies select the constraint type you want to use from the
drop-down list.
Constraint Type Based on the template you have selected, click where
indicated to fill in the desired values necessary to complete
this constraint type.

Modifying a Dependency Rule Constraint:

About this task

To modify a dependency rule constraint:

Procedure
1. From the Transaction Dependency Rule Detail window, select the constraint
type you wish to modify and choose the Details icon. The Dependency Detail
window for the chosen constraint displays.
2. Edit the information in the applicable fields. Refer to Table 102 for field value
descriptions.
3. Choose the Save icon.

Deleting a Dependency Rule Constraint:

About this task

To delete a dependency rule constraint:

Procedure
1. From the Transaction Dependency Rule Detail window, select the constraint
type you wish to delete.

Chapter 20. Configuring an Order Document's Fulfillment-Specific Components 215

 2. Choose the Delete icon.

Modifying a Transaction Dependency Rule

About this task

To modify a transaction dependency rule:

Procedure
1. From the Transaction Dependency Group Details window, select the transaction
dependency rule you wish to modify and choose the Details icon. The
Transaction Dependency Rule Detail window for the chosen constraint displays.
2. Edit the information in the applicable fields. Refer to Table 101 on page 214 for
field value descriptions.
3. Choose OK.

Deleting a Transaction Dependency Rule

About this task

To delete a transaction dependency rule:

Procedure
1. From the Transaction Dependency Group Details window, select the transaction
dependency rule you wish to delete.
2. Choose the Delete icon.

Modifying a Transaction Dependency Group

About this task

To modify a transaction dependency group:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Transaction Dependencies. The Transaction
Dependencies window for the chosen document type displays.
2. From the Transaction Dependency Groups list, select the transaction
dependency group you wish to modify and choose the Details icon. The
Transaction Dependency Group Details window displays.
3. Edit the information in the applicable fields. Refer to Table 100 on page 213 for
field value descriptions.
4. Choose the Save icon.

Deleting a Transaction Dependency Group

About this task

To delete a transaction dependency group:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Transaction Dependencies. The Transaction
Dependencies window for the chosen document type displays.
2. From the Transaction Dependency Groups list, select the applicable transaction
dependency group and choose the Delete icon.

216 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 21. Configuring an Opportunity Document's
Fulfillment-Specific Components
Configuring an Opportunity Document’s Fulfillment-Specific
Components
To complete an Opportunity document’s lifecycle, an Opportunity flows through
the Opportunity Fulfillment process type. You can configure the rules and
components that are specific to an Opportunity document’s fulfillment process
type.

Opportunity Fulfillment: Configuring Process Type Pipelines

A process type pipeline is a series of transactions and statuses that guide a
document type, such as an Opportunity, through a predefined process. A pipeline
consists of the different statuses a document goes through during fulfillment. You
can also set up transactions consisting of events, actions, and conditions, as they
pertain to the Opportunity pipeline.

Repositories

A repository is a logical collection of entities that define the business process

workflow.

The following entities are included in a repository:

v Pipelines
v Transactions
v Statuses
v Conditions
v Actions
v Services

Sterling Selling and Fulfillment Foundation provides a base repository for the
Opportunity process type. Some of the entities within a repository are copied when
a new document type is created. For more information about creating a new
document type, see the Sterling Selling and Fulfillment Foundation: Configuration
Guide.

The process of Opportunity Fulfillment is modeled through a pipeline. This

represents the process configuration that is unique to an organization. An
organization may also specify unique processes for each participating Enterprise.

Opportunity Fulfillment: Pipelines

About this task

For more information about configuring pipelines, see the Sterling Selling and
Fulfillment Foundation: Configuration Guide.

To view the Opportunity Fulfillment pipeline details:

© Copyright IBM Corp. 1999, 2012 217

 Procedure
1. From the tree in the application rules side panel, select Opportunity >
Opportunity Fulfillment > Opportunity Process Model. The Opportunity
Fulfillment window is displayed.
2. Select Opportunity Fulfillment Repository > Pipelines > Opportunity
Fulfillment.
The Pipeline Detail: Opportunity Fulfillment (Opportunity Fulfillment) window
is displayed.

Results

For more information about creating and modifying a pipeline, see the Sterling
Selling and Fulfillment Foundation: Configuration Guide.

Opportunity Fulfillment: Transactions

About this task

The Opportunity process type has a set of base transactions defined for it. A
transaction is a logical unit of work that is necessary for performing activity within
Sterling Selling and Fulfillment Foundation. Base transactions are predefined
transactions that contain information about how the transactions behave. Base
transactions can be used to create new transactions. These transactions can also be
changed within the limits defined in the base transaction.

For more information about Transactions, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To view the transaction details pertaining to an Opportunity Fulfillment pipeline:

Procedure
1. From the tree in the application rules side panel, select
Opportunity > Opportunity Fulfillment > Opportunity Process Model. The
Opportunity Fulfillment window is displayed.
2. In the Opportunity Fulfillment window, click the Transactions icon.

218 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 The Transactions tab window, containing the information described in
Table 103, is displayed.
Table 103. Opportunity Fulfillment Pipeline - Transactions Tab Window
Field Description
Change Opportunity This transaction represents any modifications that may be
made to an opportunity.
Change Opportunity Status This transaction represents any modifications that may be
made involving the status of an opportunity.
Create Opportunity This transaction represents the creation of an opportunity in
the system.
Opportunity Lost This transaction represents the process of an opportunity
being lost.
Opportunity Won This transaction represents the process of an opportunity
being won, as a result of a sales order being created from a
quote that is associated with this opportunity.
Process Opportunity This transaction moves the status of an opportunity from
Inquiry to Negotiation.
Purge Opportunity This transaction represents an opportunity that can be purged
and moved from the tables into the history tables.
Purge Opportunity History This transaction represents the process of purging
opportunities from the history tables and removing them
from the system.

Results

For more information about creating and modifying transactions, see the Sterling
Selling and Fulfillment Foundation: Configuration Guide.

Opportunity Fulfillment: Statuses

About this task

Statuses are the actual states that an Opportunity document moves through in a
pipeline. A transaction can contain two types of statuses, a drop status and a
pickup status. An Opportunity document is moved into the drop status when the
events and conditions of a transaction have been completed. A pickup status takes
the Opportunity document from the previous drop status and moves it through the
next transaction. Negotiation and Won are examples of Opportunity statuses.

For more information about Statuses, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To view the status details of an Opportunity Fulfillment pipeline:

Procedure
1. From the tree in the application rules side panel, select
Opportunity > Opportunity Fulfillment > Opportunity Process Model. The
Opportunity Fulfillment window is displayed.
2. In the Opportunity Fulfillment window, click the Statuses icon.
The Statuses tab window, containing the information described in Table 104 on
page 220, is displayed.

Chapter 21. Configuring an Opportunity Document's Fulfillment-Specific Components 219

 Table 104. Opportunity Fulfillment Pipeline - Statuses Tab Window
Field Description
Inquiry This indicates that an opportunity has been created, and there
is no quote associated with the opportunity.
Negotiation This indicates that a negotiation pertaining to a quote for this
opportunity is in progress between a seller and a buyer.
Won This indicates that an opportunity has been won because a
sales order has been created from an associated quote.
Lost This indicates that an opportunity has been lost because the
associated quotes are abandoned or have expired.

Results

For more information about creating and modifying statuses, see the Sterling Selling
and Fulfillment Foundation: Configuration Guide.

Opportunity Fulfillment: Conditions

About this task

A condition matches document type attributes against decision points, and routes
the documents to different paths based on the specified attribute and value
combinations. The document type attributes against which conditions can be
created are predefined in Sterling Selling and Fulfillment Foundation. You can
either use these attributes in any combination, or you can create conditions that
run the appropriate application logic for specific circumstances.

For more information about conditions, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To view the condition details of an Opportunity Fulfillment pipeline:

Procedure
1. From the tree in the application rules side panel, select
Opportunity > Opportunity Fulfillment > Opportunity Process Model. The
Opportunity Fulfillment window is displayed.
2. In the Opportunity Fulfillment window, click the Conditions icon.
The Conditions tab window is displayed, containing the New Condition Group
field. The New Condition Group field displays conditions that are specific to
the Opportunity Fulfillment pipeline.

Results

For more information about creating and modifying conditions, see the Sterling
Selling and Fulfillment Foundation: Configuration Guide.

Opportunity Fulfillment: Actions

About this task

An action is a process or program that is triggered by an event. These processes

and programs send user alert notifications and automatically resolve issues.

220 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 For more information about Actions, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To view the action details of an Opportunity Fulfillment pipeline:

Procedure
1. From the tree in the application rules side panel, select
Opportunity > Opportunity Fulfillment > Opportunity Process Model. The
Opportunity Fulfillment window is displayed.
2. In the Opportunity Fulfillment window, click the Actions icon.
The Actions tab window is displayed.

Results

For more information about creating and modifying actions, see the Sterling Selling
and Fulfillment Foundation: Configuration Guide.

Configuring Purge Criteria

You can define parameters used when purging the records pertaining to an
opportunity from the system.

For more information about purge criteria, refer to “Configuring a Document's

Purge Criteria” on page 249

Chapter 21. Configuring an Opportunity Document's Fulfillment-Specific Components 221

222 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 22. Configuring an Order Document's
Shipment-Specific Components
Configuring an Order Document's Shipment-Specific Components
Note: Be aware that return fulfillment requires sourcing configuration. Sourcing
configuration is accessible through the Distributed Order Management
configuration grouping. For more information about configuring sourcing, see
Section 3.5, Defining Sourcing and Scheduling Rules.

To complete an order document's lifecycle, each document has a set of different

processes that it can go through. These processes are called process types. Every
order document has a defined set of process types in Sterling Selling and
Fulfillment Foundation.

The following process types are defined in Sterling Selling and Fulfillment
Foundation for the order document types:
v Fulfillment
v Negotiation
v Shipment
v Receipt

You can configure the rules and components specific to an order document's
shipment process type.

Shipments: Defining Hold Types

Shipments can be placed on hold manually or automatically by applying a
particular hold type. Certain transactions can be configured to ensure that
shipments put on hold are not processed. Likewise, modification types can be
configured to ensure shipments that are on hold are not processed. By default, all
transactions and modification types are allowed to process all documents for all
hold types.

To prevent transactions from processing shipments that are put on hold, in the
Others tab in the Transaction Detail screen, check the "This Transaction Can Be
Stopped From Processing Shipments That Are On Hold" box. For more information
about viewing transaction details, see the Sterling Selling and Fulfillment Foundation:
Configuration Guide.

To create, modify, and delete hold types, from the tree in the application rules side
panel, choose Document Specific > (Document Type) > Outbound Logistics > Hold
Types. For more information about defining hold types, see the Sterling Selling and
Fulfillment Foundation: Logistics Management Configuration Guide.

Shipments: Defining Process Type Details

You can define the parameters and templates that distinguish a process type.

For more information about defining process type details, see the Sterling Selling
and Fulfillment Foundation: Configuration Guide.

© Copyright IBM Corp. 1999, 2012 223

Shipments: Process Type Pipeline Configuration
A process type pipeline is a series of transactions and statuses that guide
document types, such as a Sales Order, through a predefined process. A pipeline
consists of the different statuses a document goes through during fulfillment,
negotiation, shipment, or receipt. You can also set up transactions consisting of
events, actions, and conditions, as they pertain to the pipeline you are configuring.

Repositories

A repository is a logical collection of entities that define the business process

workflow.

The following entities are included in a repository:

v Pipelines
v Transactions
v Statuses
v Conditions
v Actions
v Services

Sterling Selling and Fulfillment Foundation provides a base repository for each of
the system defined process types. Some of the entities within a repository are
copied when creating a new document type. For more information about creating a
new document type, see the Sterling Selling and Fulfillment Foundation: Configuration
Guide.

The process of shipment is modeled through a pipeline. This represents the process
configuration that is unique to an organization. An organization may also specify
unique processes for each participating Enterprise.

Shipments: Defining Pipeline Determination

Pipeline determination is used to set up conditions that affect which pipeline is
used during the start of the business process workflow. For example, an
organization deals with sales orders that sometimes contain hazardous materials.
They have two separate pipelines, one in which orders with order lines without
any hazardous materials go through and one in which orders with order lines
containing hazardous materials must go through for inspection before continuing
through the order process. The organization uses pipeline determination to set up
a condition that determines whether or not order lines contain hazardous materials
and sends the order line down the correct pipeline.

When you expand the Pipeline Determination branch, the components displayed
depends on what role you are logged in as. If you are logged in as a Hub role, the
Hub Rule displays. If you are logged in as an Enterprise role, both the Hub Rule
and My Rule components display. Double-click on the applicable node to display
the pipeline determination rules.

Note: If you are logged in as an Enterprise role, the Hub Rule screen is grayed out
and cannot be modified.

224 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Drag conditions and pipelines into the work area to construct pipeline
determination rules. A single pipeline or condition must be the root. Conditions
cannot link back to an earlier component in the chain and a pipeline cannot be
linked to twice.

Note: When configuring pipeline determination for an order document type

pipeline, please note that pipeline determination is only considered when adding a
line or creating an order. When changes are made to draft orders pipeline
determination does not occur.

Shipments: Pipelines
About this task

For more information about configuring pipelines, see the Sterling Selling and
Fulfillment Foundation: Configuration Guide.

To view the outbound shipment pipeline details:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Outbound Logistics > Shipment Process Model. The
Outbound Shipment window displays.
2. In the Outbound Shipment window, choose Outbound Shipment Repository >
Pipelines > Outbound Shipment.
3. The Pipeline Detail: Outbound Shipment (Outbound Shipment) window
displays.

Results

For more information about creating and modifying a pipeline, see the Sterling
Selling and Fulfillment Foundation: Configuration Guide.

Chapter 22. Configuring an Order Document's Shipment-Specific Components 225

 Shipments: Transactions
About this task

Every process type has a set of base transactions defined for it. A transaction is a
logical unit of work that is necessary for performing activity within Sterling Selling
and Fulfillment Foundation. Base transactions are predefined transactions that
contain information about how the transaction behaves, such as how many copies
of a transaction can be kept in a process type and whether or not it can have
configurable base pick and drop statuses. Base transactions can be used to create
new transactions. These transactions can be changed within the limits defined in
the base transaction.

For more information about transactions, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To view the transaction details for an outbound shipment pipeline:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Outbound Logistics > Shipment Process Model. The
Outbound Shipment window displays.
2. In the Outbound Shipment window, choose the Transactions icon.
3. The Transactions tab window displays.

226 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Results

For more information about creating and modifying transactions, see the Sterling
Selling and Fulfillment Foundation: Configuration Guide.
Table 105. Outbound Shipment Pipeline - Transactions Tab Window
Field Description
Cancel Shipment This transaction represents the process of cancelling a
shipment.
Change Shipment This transaction represents any modifications that may be
made to a shipment.
Change Shipment Status This transaction represents any modifications that may be
made involving an order or order line's status.
Close Shipment This transaction represents a shipment being closed and
archived in the system.
Confirm Shipment This transaction represents a shipment is manually confirmed
and shipped.
Create And Confirm This transaction represents the process of creating a shipment
Shipment and shipping it.
Create Shipment This transaction represents the creation of a shipment in the
system.
Create Shipment Invoice This transaction represents the creation of a shipment invoice.
Deliver Shipment This transaction represents a shipment being delivered.
ESP Evaluator This transaction represents the shipment being evaluated for
ESP terms of weight and volume.
Import Shipment This transaction represents the process of importing a
shipment that has already been processed to some extent by
an external system.
Pack Shipment This transaction represents the process of packing a shipment.
Pack Shipment Complete This transaction represents the completion of the packing
process.
Print Pick List This transaction represents the process of printing a pick list.
Purge Pick List This transaction represents a pick list that can be purged from
the system.
Purge Shipment This transaction represents the process of moving shipments
to the history tables.
Purge Shipment History This transaction represents the process of purging shipments
from the history tables and removing them from the system.
Receipt Closure Listener This listener transaction monitors the receipt pipeline and
indicates when the receipt has been closed.
Route Shipment This transaction represents the process of assigning carriers to
a shipment based on routing guidelines. When possible, it
creates consolidated shipments into loads to save on
transporting costs.
Sent To Node This transaction represents the process of sending a created
shipment to a node to be pick, packed, and shipped.
Shipment Monitor This transaction represents the process of monitoring
shipments in the system based on defined parameters.
Split Shipment This transaction represents splitting an existing shipment into
multiple shipments.

Chapter 22. Configuring an Order Document's Shipment-Specific Components 227

 Table 105. Outbound Shipment Pipeline - Transactions Tab Window (continued)
Field Description
Synchronize Task Queue This transaction represents the process of synching the order
fulfillment task queue.
Undo Pack Shipment This transaction indicates that a shipment that has moved
Complete through the Pack Shipment Complete transaction is undone.
Unpack Shipment This transaction represents the process of unpacking a
shipment that has already been packed.

Shipments: Statuses
About this task

Statuses are the actual states that a document moves through in the pipeline. A
transaction can contain two types of statuses, a drop status and a pickup status. A
document is moved into a drop status when the events and conditions of a
transaction have been completed. A pickup status takes the document from the
previous drop status and moves it through the next transaction. Created and
Scheduled are examples of statuses.

For more information about statuses, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To view the status details of an outbound shipment pipeline:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Outbound Logistics > Shipment Process Model. The
Outbound Shipment window displays.
2. In the Outbound Shipment window, choose the Statuses icon.
3. The Statuses tab window displays.

Results

For more information about creating and modifying statuses, see the Sterling Selling
and Fulfillment Foundation: Configuration Guide.
Table 106. Outbound Shipment Pipeline - Statuses Tab Window
Field Description
Shipment Created This indicates that a shipment has been created.
ESP Check Required This indicates that the ESP evaluator must be run to
determine if ESP conditions have been met.
On ESP Hold This indicates that the shipment is being held until ESP
conditions are met.
Released From ESP Hold Indicates that the shipment has been released from ESP hold.
Released For Routing Indicates that the shipment has met specified parameters for
routing guidelines to be applied to it. For more information
about configuring routing guidelines, see the Sterling Selling
and Fulfillment Foundation: Configuration Guide.

228 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 106. Outbound Shipment Pipeline - Statuses Tab Window (continued)
Field Description
Awaiting Routing Indicates that routing guidelines must be applied to the
shipment before it continues through the pipeline. For more
information about configuring routing guidelines, see the
Sterling Selling and Fulfillment Foundation: Configuration Guide.
Shipment Routed This indicates that routing guidelines have been applied to
the shipment. For more information about configuring
routing guidelines, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.
Sent To Node This indicates that the shipment has been sent to be packed
Shipment Being Picked This indicates that the line items are physically being picked
in preparation for shipment.
Shipment Packed This indicates that the shipment has been packed.
Shipment Shipped This indicates that the shipment has been shipped to the ship
to address.
Shipment Delivered This indicates that the shipment has been delivered to the
ship node address.
Included In Receipt This indicates that the shipment has been included in the
receipt.
Receipt Closed This indicates that the shipment has been received and is
considered complete.
Shipment Invoiced This indicates that an invoice has been created for the
shipment.
Shipment Cancelled This indicates that the shipment has been cancelled.

Shipments: Conditions
About this task

A condition matches document type attributes against decision points and routes
the documents to different paths based on the specified attribute and value
combinations. The document type attributes against which conditions can be
created are predefined in Sterling Selling and Fulfillment Foundation. You can use
these attributes in any combination or you can create conditions that run the
appropriate application logic for specific circumstances.

For more information about conditions, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To view the condition details of an outbound shipment pipeline:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Outbound Logistics > Shipment Process Model. The
Outbound Shipment window displays.
2. In the Outbound Shipment window, choose the Conditions icon.
3. The Conditions tab window displays.

Chapter 22. Configuring an Order Document's Shipment-Specific Components 229

 Results

For more information about creating and modifying conditions, see the Sterling
Selling and Fulfillment Foundation: Configuration Guide.
Table 107. Outbound Shipment Pipeline - Conditions Tab Window
Field Description
ESP Check Required This condition is used to determine whether a shipment
requires an ESP check.
Routing Required This condition is used to determine whether a shipment
requires routing guidelines to be applied to it. For more
information about configuring routing guidelines, see the
Sterling Selling and Fulfillment Foundation: Configuration Guide.

Shipments: Actions
About this task

An action is a process or program that is triggered by an event. These processes

and programs send user alert notifications and automatically resolve issues.

For example, when an order is released (the event), you can set an action to send
the customer an e-mail.

For more information about actions, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

To view the action details of an outbound shipment pipeline:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Outbound Logistics > Shipment Process Model. The
Outbound Shipment window displays.
2. In the Outbound Shipment window, choose the Actions icon.
3. The Actions tab window displays.

Results

For more information about creating and modifying actions, see the Sterling Selling
and Fulfillment Foundation: Configuration Guide.

Shipments: Defining Monitoring Components

You can define the components used to measure and report unexpected conditions
and delays in the order document's lifecycle. For more information about using
these components to configure monitoring rules, see the Sterling Selling and
Fulfillment Foundation: Configuration Guide.

To define monitoring components, from the tree in the application rules side panel,
choose Document Specific > (Document Type) > Outbound Logistics > Shipment
Monitoring. The Monitoring window displays.

230 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Shipments: Defining Date Types
You can define custom date types. These dates automatically appear in the
configuration screen and the Order/Shipment Dates window in the Console.

Shipments: Creating a Date Type

About this task

To create a date type:

Procedure
1. In the Monitoring window, choose the Date Types tab.
2. From the Date Types list, choose the Create New icon. The Date Type Details
window displays.
3. Enter information in the applicable fields. Refer to Table 108 for field value
descriptions.
4. Choose the Save icon.
Table 108. Date Type Details Window
Field Description
Date Type Enter the name of the date type.
Description Enter a brief description of the date type.
Requested Select this field to indicate if the date type represents a date
requested by a Buyer, user, etc.
Expected Select this field to indicate if the date type represents a date
the system expects or has calculated something to occur.
Actual Select this field to indicate if the date type represents the
actual date.

Shipments: Modifying a Date Type

About this task

To modify a date type:

Procedure
1. In the Monitoring window, choose the Date Types tab.
2. From the Date Types list, locate the applicable date type and choose the Details
icon. The Date Type Details window displays.
3. Enter information in the applicable fields. Refer to Table 108 for field value
descriptions.
4. Choose the Save icon.

Shipments: Deleting a Date Type

About this task

To delete a date type:

Procedure
1. In the Monitoring window, choose the Date Types tab.
2. From the Date Types list, locate the applicable date type and choose the Delete
icon.

Chapter 22. Configuring an Order Document's Shipment-Specific Components 231

 Results

The following system dates cannot be deleted:

v Delivery Date
v Ship Date

Shipments: Defining Milestones

You can configure applicable statuses in a process type to be milestones. A
milestone is a type of date that Sterling Selling and Fulfillment Foundation
automatically determines when an order moves from one status to another. A
milestone represents a significant point in the processing lifecycle that can be used
as a criterion for monitoring. Milestones can be defined at the order, order line,
and order release.

A milestone can be reached whenever there is a change in an order line. Sterling

Selling and Fulfillment Foundation marks a milestone as reached if an order line
reaches a status marked as a milestone. However, there may be times that only
part of an order line reaches a particular status defined as milestone.

Shipments: Creating a Milestone

About this task

To create a milestone:

Procedure
1. In the Monitoring window, choose the Milestones tab.
2. From the Milestones list, choose the Create New icon. The Milestone Details
window displays.
3. Enter information in the applicable fields. Refer to Table 109 for field value
descriptions.
4. Choose the Save icon.
Table 109. Milestone Details
Field Description
Date Type Enter the name of the milestone being created.
Note: You cannot use date types you have created on the
date type tab. You must create a unique name for the
milestone.
Description Enter a brief description of the milestone.
Requested Select this field to indicate if the milestone represents a date
requested by a Buyer, user, etc.
Expected Select this field to indicate if the milestone represents a date
the system expects or has calculated something to occur.
Actual This field is not applicable for milestones.
Milestone Statuses You can add statuses to associate with the milestone by
selecting the Create New icon and entering information in the
applicable fields.
Note: This tab can only be accessed once the Primary Info
tab has been filled out and saved.
Date Type The date type if any associated with the milestone.
Status Select the status you want use to indicate the milestone has
been reached.

232 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 109. Milestone Details (continued)
Field Description
Level Select Order to indicate this status must be reached at the
order header level.

Select Order Line to indicate that this status must be reached

at the order line level.

Select Order Release to indicate that this status must be

reached at the order release level.
Quantity Type Select Initial to indicate that the milestone is met when any
quantity at the above selected level moves into the status.

Select Complete to indicate that the milestone is met when all

quantity at the above selected level moves into the status.

Shipments: Modifying a Milestone

About this task

Note: If modifications are made to an existing milestone, the changes are only
applied to new orders. Existing orders for which milestone records have already
been created are not considered.

To modify a milestone:

Procedure
1. In the Monitoring window, choose the Milestones tab.
2. From the Milestones list, locate the applicable milestone and choose the Details
icon. The Milestone Details window displays.
3. Enter information in the applicable fields. Refer to Table 109 on page 232 for
field value descriptions.
4. Choose the Save icon.

Shipments: Deleting a Milestone

About this task

To delete a milestone:

Procedure
1. From the Monitoring window, choose the Milestones tab.
2. From the Milestones list, locate the applicable milestone and choose the Delete
icon.

Shipments: Defining Monitoring Events

Events are used in instances where the Order Monitor may raise multiple alerts of
the same type. For example, if an order with multiple lines that are shipped
together has a shipment delay and you have configured the Order Monitor to raise
alerts when shipments are delayed at the line level, an alert of the same type
would be raised against each line in the order. You can create rules to aggregate all
of these similar alerts and raise one "root cause".

Chapter 22. Configuring an Order Document's Shipment-Specific Components 233

 Shipments: Creating an Event Rule
About this task

To create an event rule:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Monitor Events. The Monitor Events window
displays.
2. From the Monitor Events list, choose the Create New icon. The Monitor Events
Details window displays.
3. Enter information in the applicable fields. Refer to Table 110 for field value
descriptions.
4. Choose the Save icon.
Table 110. Monitor Event Details Pop-Up Window
Field Description
Event ID Enter the event ID.
Description Enter a brief description of the event.
Requires Realert Select this field if you want users to be re-alerted if the issue
has not been resolved within a certain timeframe.
Realert Interval If you selected Requires Realert, enter the interval (in hours)
that re-alerts should be sent.
Automatically Resolve This flag must be checked to trigger a monitor event every
Alerts time an alert condition is detected on an order. To trigger an
alert only once when the alert condition is met, uncheck this
flag.
Event Identified By
Shipment Select this field if you want two or more alert conditions to
be treated the same if they belong to the same shipment.
Service To Be Invoked Select the alert service to be invoked should the event
consolidation rule conditions be met.
Aggregate And Invoke Service For
Shipment Select this field if you want only one alert to be raised for a
shipment when alert conditions are detected.

Results

In most cases the attributes that identify an event should be a subset of the
attributes that specify event aggregation.

Shipments: Modifying an Event

About this task

To modify an event rule:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Monitor Events. The Monitor Events window
displays.

234 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 2. From the Monitor Events list, select the applicable event rule and choose the
Details icon. The Monitor Event Details window displays.
3. Enter information in the applicable fields. Refer to Table 110 on page 234 for
field value descriptions.
4. Choose the Save icon.

Shipments: Deleting an Event

About this task

To delete an event rule:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Fulfillment > Monitor Events. The Monitor Events window
displays.
2. From the Monitor Events list, select the applicable event rule and choose the
Delete icon.

Defining Shipment Preferences

Shipment preferences can be created to enable over shipment of products, or allow
the creation of shipments without order information in the system.

Over Shipping Preferences

Over shipment is the ability to ship more than an ordered quantity. Over shipment
tolerance definitions can be configured using the following criteria:
v Line Type
v Seller Organization Code
v CustomerVendor Classification/BuyerSeller Organization Code
v Item Classification/Item ID

During shipment, if a shipping preference has not been configured that matches
the criteria of the shipment line, over shipment is not allowed. Otherwise, over
shipment within the specified percentage is allowed.

Creating a Shipment Preference

About this task

To create a shipment preference:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Outbound Logistics > Shipping Preference. The Shipping
Preferences window displays.
2. In the Shipping Preferences window, choose the Over Shipping Preferences tab.
The Shipping Preference Search panel displays.
3. In the Search Results panel, choose the Create New icon. The Shipping
Preference Details pop-up window displays.
4. Enter information into the applicable fields. Refer to Table 111 on page 236 for
field value descriptions.
5. Choose the Save icon.

Chapter 22. Configuring an Order Document's Shipment-Specific Components 235

 Table 111. Shipping Preference Details
Field Description
Line Type Select the line type you want to allow over shipment for.
Item ID Enter the item ID of the item you want to allow over
shipment for, if applicable.
Item Classification Enter the item classification group you want to allow over
shipment for, if applicable. For more information about item
classification, see the Catalog Management: Configuration Guide.
Seller Organization Select the Seller organization that you want to allow to over
ship.
Buyer Organization Select the Buyer organization that you want to be able to
receive over shipments.
Customer Classification Select the customer classification that you want to be able to
receive over shipments, if applicable.
Over Ship Percentage Enter the percentage allowed for over shipment.

Modifying a Shipment Preference

About this task

To modify a shipment preference:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Outbound Logistics > Shipping Preference. The Shipping
Preferences window displays.
2. In the Shipping Preferences window, choose the Over Shipping Preferences tab.
The Shipping Preference Search panel displays.
3. Enter the applicable search criteria and choose the Search icon. A list of
preferences displays.
4. Select the applicable preference and choose the Details icon. The Shipping
Preference Details pop-up window displays.
5. Enter information into the applicable fields. Refer to Table 111 for field value
descriptions.
6. Choose the Save icon.

Deleting a Shipment Preference

About this task

To delete a shipment preference:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Outbound Logistics > Shipping Preference. The Shipping
Preferences window displays.
2. In the Shipping Preferences window, choose the Over Shipping Preferences tab.
The Shipping Preference Search panel displays.
3. Enter the applicable search criteria and choose the Search icon. A list of
preferences displays.
4. Select the applicable preference and choose the Delete icon.

236 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Transaction Rules
About this task

Transaction Rules define whether the system allows the creation of shipments
without an existing order information on the system.

To define transaction rules:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Outbound Logistics > Shipping Preference. The Shipping
Preferences window displays.
2. In the Shipping Preferences window, choose the Transaction Rules tab.
3. Enter information in the applicable field. Refer to Table 112 for field value
descriptions.
4. Choose the Save icon.
Table 112. Transaction Rules Tab
Field Description
Order Available On System Select the appropriate option from the drop-down list to
ensure that the shipments are either created against existing
orders or not. Options are:
v May Be - Select this option if the orders might be available
on the system.
v No - Select this option if the orders are not available on the
system.
v Yes - Select this option if the orders are available on the
system.

Chapter 22. Configuring an Order Document's Shipment-Specific Components 237

238 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 23. Configuring a Document's Financial Components
Defining Payment Terms
You can define common codes for payment terms that you may have with your
customers. These terms are predefined methods of payment.

Creating a Payment Term

About this task

To create a payment term:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Financials > Payment Terms. The Payment Terms window
displays in the work area.
2. Choose the Create New icon. The Payment Term Details pop-up window
displays.
3. In Payment Term, enter the name of the payment term.
4. In Short Description, enter a brief description of the payment term.
5. In Long Description, enter a more detailed description of the payment term.
6. Choose the Save icon.

Modifying a Payment Term

About this task

To modify a payment term:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Financials > Payment Terms. The Payment Terms window
displays in the work area.
2. Select the applicable payment term and choose the Details icon. The Payment
Term Details pop-up window displays.
3. In Short Description, enter a brief description of the payment term.
4. In Long Description, enter a more detailed description of the payment term.
5. Choose the Save icon.

Deleting a Payment Term

About this task

To delete a payment term:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Financials > Payment Terms. The Payment Terms window
displays in the work area.
2. Select the applicable payment term and choose the Delete icon.

© Copyright IBM Corp. 1999, 2012 239

Defining Charge Definitions
You can define charge definitions that you can associate with orders and invoices
by creating charge categories. These categories contain a group of related charge
names that can be used when the particular category is used. When adding a
charge to an order header or an order line, you must use the charge categories that
you have defined here. The charge name that is used on the order header or on the
order line may or may not be defined in the system. The charge name is validated,
depending on the Validate Charge Name rule in the additional payment rules. For
more information about this rule, see “Defining Additional Payment Rules” on
page 243.

The default charge definitions of Sterling Selling and Fulfillment Foundation are:
v Shipping
v Handling
v Personalization
v Discount

The default charge definitions are only available to the Hub organization at the
time of installation. Any Enterprises that are created must create their own charge
definitions.

Creating a Charge Category

About this task

To create a charge category:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
Load > Charge Categories. The Charge Categories window displays in the
work area.
2. Choose the Create New icon. The Charge Category Details window displays.
3. In Charge Category, enter the name of the charge category.
4. In Description, enter a brief description of the charge category.
5. Select Billable if the charge is billable. Non-billable charges are not considered
in order totals, but do appear in invoices.
6. Select Discount if the charge you are creating is a discount charge type.
7. Select Consider For Profit Margin if the category should be used for profit
margin calculation.
8. Choose the Save icon.

Results

Charge categories cannot be localized. For more information about localization, see
the Sterling Selling and Fulfillment Foundation: Localization Guide.

Adding a Charge Name Associated with a Charge Category

About this task

Charge names are names of the actual charges included in the charge definition.

To add a charge name to a charge category:

240 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Procedure
1. In the Charge Category Details window, choose the Create New icon. The
Charge Name Details pop-up window displays.
2. In Charge Name, enter the charge name.
3. In Description, enter a brief description of the charge name.
4. Choose the Save icon.

Results

Charge names cannot be localized. For more information about localization, see the
Sterling Selling and Fulfillment Foundation: Localization Guide.

Modifying a Charge Name Associated with a Charge Category

About this task

To modify a charge category's charge name:

Procedure
1. In the Charge Category Details window, select the applicable charge name and
choose the Details icon. The Charge Name Details pop-up window displays.
2. In Description, enter a brief description of the charge name.
3. Choose the Save icon.

Deleting a Charge Name Associated with a Charge Category

About this task

To delete a charge category's charge name select the applicable charge name in the
Charge Category Details window and choose the Delete icon.

Modifying a Charge Category

About this task

To modify a charge category:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
Load > Charge Categories. The Charge Categories window displays in the
work area.
2. Select the applicable charge category and choose the Details icon. The Charge
Category Details window displays.
3. In Description, enter a brief description of the charge category.
4. Select Billable if the charge is billable. Non-billable charges are not considered
in order totals, but do appear in invoices.
5. Select Discount if the charge you are creating is a discount charge type.
6. Select Consider For Profit Margin if the category should be used for profit
margin calculation.
7. Choose the Save icon.

Deleting a Charge Category

About this task

To delete a charge definition:

Chapter 23. Configuring a Document's Financial Components 241

 Procedure
1. From the tree in the application rules side panel, choose Document Specific >
Load > Charge Categories. The Charge Categories window displays in the
work area.
2. Select the applicable charge category and choose the Delete icon.

Defining Tax Names

You can define common codes for tax names. Tax names are any specific taxes that
may pertain to orders and invoices.

Sterling Selling and Fulfillment Foundation understands three different types of

taxes: a tax against a price, against a charge, or a flat tax.
v A tax against a price is an additional cost for a percentage of the price of the
order line.
v A tax against a charge is an additional cost for a percentage of an existing charge
on the order header, or order line. When adding a tax against a charge, the
charge category must be one that already exists on the order header, or on the
order line.
v A flat tax is a fixed tax applied on an order, independently of any charge, or
price.

Creating a Tax Name

About this task

To create a tax name:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Financials > Financial Attributes. The Financial window
displays in the work area.
2. Choose the Tax Names tab.
3. Choose the Create New icon. The Tax Name Details pop-up window displays.
4. In Tax Name, enter the name of the tax name.
5. In Short Description, enter a brief description of the tax name.
6. In Long Description, enter a more detailed description of the tax name.
7. Choose the Save icon.

Modifying a Tax Name

About this task

To modify a tax name:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Financials > Financial Attributes. The Financial window
displays in the work area.
2. Choose the Tax Names tab.
3. Select the applicable tax name and choose the Details icon. The Tax Name
Details pop-up window displays.
4. In Short Description, enter a brief description of the tax name.

242 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 5. In Long Description, enter a more detailed description of the tax name.
6. Choose the Save icon.

Deleting a Tax Name

About this task
To delete a tax name:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Financials > Financial Attributes. The Financial window
displays in the work area.
2. Choose the Tax Names tab.
3. Select the applicable tax name and choose the Delete icon.

Defining Additional Payment Rules

About this task

You can set up payment collection rules that are used when an order is sent for
payment authorization.

Note: To define additional payment rules for quotes, refer to "Defining Additional
Payment Rules for Quotes".

To define additional payment rules:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Financials > Financial Rules. The Financial Rules window
displays in the work area.
2. Enter information in the applicable fields. Refer to the following table for field
value descriptions.
3. Choose the Save icon.

Results
Table 113. Financial Rules
Field Description
Hold Order For Authorization Check this box if you want to hold the order
for authorization purposes.
Use Same Authorization Multiple Times Check this box if you want to use the same
authorization for multiple transactions.
Allow Refund To Exceed Charged Amount Check this box if you want to allow refunds
of unlimited amount for an order.
Note: If this rule is enabled, it will
supersede the Allow Refunding Of Negative
Debits Before Sufficient Collection Has
Occurred rule.
Validate Charge Name Check this box to indicate that the system
needs to validate if the charge names used
for an order document exist in the system
before proceeding with payment collection.

Chapter 23. Configuring a Document's Financial Components 243

 Table 113. Financial Rules (continued)
Field Description
Create Invoice Before Order Or Shipment Check this box if you want to be able to
create an informational invoice before an
order or a shipment.
Apply Price Change To Invoiced Quantity Check this box to apply the price changes to
the invoiced quantity. If this box is
unchecked, then price change after invoicing
is not applied to the order.
Do Not Allow Debit And Credit Invoices Check this box to ensure that positive and
To Settle Each Other negative transactions are not able to negate
each other.
Invoice Open Header Charges/Taxes On Check this box if you want all open header
Invoice Complete charges and taxes to be invoiced when an
order is moved to the Invoice Complete
status.
Allow Refunding Of Negative Debits When "Do Not Allow Debit And Credit
Before Sufficient Collection Has Occurred Invoices To Settle Each Other" is checked,
this rule determines whether the credit
memo should refund immediately or wait
until there are sufficient credits to refund on
the order. This applies only to sales orders.
Note: The amount to refund cannot exceed
the total order amount.
Enable Payment Card Type Configuration Check this box to enable different
Level configurations for credit cards. Use the
Payment Card Type window to configure
credit cards.
Do Not Consolidate Settlement or Refund When "Do Not Allow Debit And Credit
Requests Across Invoices Invoices To Settle Each Other" is checked,
check this box if you want to charge and
refund each invoice separately. If this box is
unchecked, payments are consolidated.

If "Do Not Allow Debit And Credit Invoices

To Settle Each Other" is disabled, negative
invoices are used to pay positive invoices.
Prioritize INVOICED Payment Status Over Check this box if you want invoiced orders
REQUEST_CHARGE For Asynchronous to remain in INVOICED status when
Processing asynchronous payment requests are made on
the orders. If the box is unchecked, orders
move to REQUESTED_CHARGE status,
which indicates there is a pending charge on
the orders. By default, this option is enabled.

244 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 113. Financial Rules (continued)
Field Description
Disassociate Payment Processing of Check this box if you do not want to
Advanced Pre-Paid Exchange Order from transfer the fund between a return order and
Return Order an advanced prepaid exchange order. When
a return order is invoiced with this check
box selected, the amount will be refunded to
the payment method of the corresponding
sales order. The payment method on the
advanced prepaid exchange order will be
charged for the entire amount of the
advanced prepaid exchange order, and
refund will happen for the entire amount of
the return order. Note: If this check box is
selected, the return order invoice details will
also contain the details of the refund. Note:
In case of a blind return order, if this check
box is selected, the amount will be refunded
to the payment method of the blind return
order.
Expiration for Authorization (Days) Enter the number of days before the
authorization expires at which a
reauthorization request is automatically
created by the Payment Collection
time-triggered transaction. For example, if
an order expires on 4/15, and the fixed
number of days is 4, then the
reauthorization request is created on 4/11.
Hold To Be Applied Due To Insufficient Create or choose the hold type to be applied
Funds In Customer Account for cases in which a customer account
contains insufficient funds to complete a
transaction. The hold is triggered internally
by the system, and therefore, should not be
set to automatically apply in the hold
configuration.
Charge Name for Shipping Select the charge name that represents the
shipping charge on an order, as described in
“Creating a Charge Category” on page 240.
Note: Do not use the same charge name that
is used by a pricing rule. If the same charge
name is used, unexpected pricing
calculations will occur.
Create Shipment Invoice for Bundle Parent on Invoicing Of
All Bundle Components Check this box to create a shipment invoice
for the bundle parent once all bundle
components have been invoiced.
First Bundle Component Check this box to create a shipment invoice
for the bundle parent once the first bundle
component has been invoiced.
Date for Pricing Confirmed Orders
Use System Date Enable this radio button if you want pricing
to be based on the current system date.
User Order Date Enable this radio button if you want pricing
to be based on the order date.

Chapter 23. Configuring a Document's Financial Components 245

 Defining Additional Payment Rules for Quotes
About this task

You can set up payment rules for the Quote document type.

To define additional payment rules:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
Quote > Financials > Financial Rules. The Financial Rules window displays in
the work area.
2. Enter information in the applicable fields. Refer to Table 114 for field value
descriptions.
3. Choose the Save icon.
Table 114. Payment Rules for Quotes
Field Description
Validate Charge Name Check this box to indicate that the system is to check that the
charge names used for a quote document are valid before
proceeding with payment collection.
Charge Name for Shipping Select the charge name that represents the shipping charge on
a quote, as described in “Creating a Charge Category” on
page 240.

Defining Receiving Discrepancy Reasons

You can define codes to specify reasons for any discrepancies that may occur
during a receipt of a shipment or a return.

There are three types of receiving discrepancies:

v Over Receipt - Occurs when a receiving node receives additional quantity
compared to the expected quantity.
v Under Receipt - Occurs when a receiving node receives less than the expected
quantity for the receipt.
v Damaged Receipt - Occurs when the receiving disposition code indicates that a
damaged product has been received.

A given discrepancy type can have multiple reason codes defined for it. For
example, if a shipment is received with a quantity of 10 under the expected
receiving quantity, it is possible for the under receipt discrepancy to have two
different reasons for the receipt, such as 6 units SHORT_SHIPMENT and 4 units
CARRIER_FAULT.

Creating a Receiving Discrepancy Reason

About this task

To create a receiving discrepancy reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Receipt > Receiving Discrepancy Reasons. The Receiving
Discrepancy Reasons window displays in the work area.

246 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 2. Choose the Create New icon. The Receiving Discrepancy Reason Details
pop-up window displays.
3. Enter information into the applicable fields. Refer to Table 115 for field value
descriptions.
4. Choose the Save icon.
Table 115. Receiving Discrepancy Reason Details
Field Description
Discrepancy Reason Code Enter the name of the discrepancy reason code as you want it
to appear throughout the system.
Discrepancy Reason Enter a brief description of the reason discrepancy.
Description
Discrepancy Reference Enter any additional reference information according to your
business practices.
Discrepancy Type Group
Over Receipt Select Over Receipt if you want the discrepancy reason to
identify scenarios in which a receiving node receives more
than the expected quantity.
Under Receipt Select Under Receipt if you want the discrepancy reason to
identify scenarios in which a receiving node receives less than
the expected quantity.
Damaged Receipt Select Damaged Receipt to identify scenarios in which a
receiving node receives items with a receiving disposition
identifying them as damaged.
Requires Invoice Select Requires Invoice Adjustment if a monetary adjustment
Adjustment must be made when a receipt discrepancy is associated with
this discrepancy reason.
Invoice Adjustment Type Group
Credit If you selected Requires Invoice Adjustment, select Credit if
the adjustment amount results in a credit invoice.
Debit If you selected Requires Invoice Adjustment, select Debit if
the adjustment amount results in a debit invoice.
Invoice Line Reference If you selected Requires Invoice Adjustment, enter a name for
the adjustment. This reference value is used in instances
when multiple adjustment invoices are created for the same
order line, in which case they are split into different invoice
lines if they have different invoice line references.

Modifying a Receiving Discrepancy Reason

About this task

To modify a receiving discrepancy reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Receipt > Receiving Discrepancy Reasons. The Receiving
Discrepancy Reasons window displays in the work area.
2. Select the receiving discrepancy reason and choose the Details icon. The
Receiving Discrepancy Reason Details pop-up window displays.
3. Enter information into the applicable fields. Refer to Table 115 for field value
descriptions.

Chapter 23. Configuring a Document's Financial Components 247

 4. Choose the Save icon.

Deleting a Receiving Discrepancy Reason

About this task

To delete a receiving discrepancy reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Receipt > Receiving Discrepancy Reasons. The Receiving
Discrepancy Reasons window displays in the work area.
2. Select the receiving discrepancy reason and choose the Delete icon.

248 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 24. Configuring a Document's Purge Criteria
Configuring a Document's Purge Criteria
Purge Criteria business rules are used to define qualifications around each type of
purge. Purges are the process by which old data is removed from the system
database. Purges minimize the number of unused database records to increase
search efficiency and reduce the size of the required physical disk. In Purge
Criteria Rules, default purge rules are provided. These can be modified for your
system operations.

Table 116 lists the purge rules provided for order document types in Sterling
Selling and Fulfillment Foundation.
Table 116. Order Document Type Purge Rules
Default
Rule Description Retention Days
PRG_SHIP_STATS Purges shipment statistics and 30
archives them in the history
tables.
STATUSAUDITPRG Purges order age alerts (if you 30
have configured the system to
trigger alerts when the order
document type stays in a
particular status for a specified
time period).
NEGOTIATIONPRG Purges negotiation information 30
and archives it in the history
tables.
NEGOTIATIONHISTPRG Purges negotiation information 30
from the negotiation history
tables.
RECEIPTPRG Purges receipt information and 30
archives it in the history tables.
RECEIPTHISTPRG Purges receipt information from 30
the receipt history tables.
ORDERHISTPRG Purges order information from the 30
order history tables.
ORDERPRG Purges order information and 30
archives it in the history tables.
ORDER_RELEASE_STATUS_PURGE Purges order release status 30
records with a quantity of 0.
PICKLISTPRG Purges pick list information. 30
SHIPMENTHISTPRG Purges shipment information from 30
the shipment history tables.
SHIPMENTPRG Purges shipment information and 30
archives it in the history tables.
DRAFTORDERNOLINEPRG Purges draft orders that do not 30
have any order lines.

© Copyright IBM Corp. 1999, 2012 249

 Table 116. Order Document Type Purge Rules (continued)
Default
Rule Description Retention Days
DRAFTORDERNOLINEHISTPRG Purges draft orders without any 30
order lines from the history table.
DRAFTORDERHISTPRG Purges draft order information 30
from the draft order history
tables.
DRAFTORDERPRG Purges draft order information 30
and archives it in the history
tables.

Table 117 lists the purge rules provided for the opportunity document type in
Sterling Selling and Fulfillment Foundation.
Table 117. Opportunity Document Type Purge Rules
Default
Retention
Rule Description Days
OPPORTUNITYPRG Purges opportunity information and archives 30
it in the history tables.
OPPORTUNITYHISTPRG Purges opportunity information from the 30
opportunity history tables.

Modifying an Order Document Type's Purge Criteria Rule

About this task

To modify an order document type's purge criteria rule:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Purge Criteria. The Purge Criteria List window displays in
the work area.
2. Enter information in the applicable fields. Refer to Table 118 for field value
descriptions.
3. Choose the Save icon.
Table 118. Purge Criteria Details Pop-up Window
Field Description
Purge Code Identifies a purge program. This is a system defined code.
Description Describes the type of purge.
Rollback Segment Defines the rollback segment that should be explicitly used
for the purge transaction qualified by the purge code. This is
useful when there are huge logical data sets that have to be
purged. This is optional and used for order related purges.
Retention Days Enter the number of days the data is to be retained in the
database (going backwards from the time the program runs).
Make sure that your table size takes into account the number
of retention days entered here.

250 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 118. Purge Criteria Details Pop-up Window (continued)
Field Description
Write to Log File Check this box if you want purged data written to a log file.
The log file can be backed up and used as a journal at a later
date.
Log File Name Enter a log file name. The log file is created in the directory
specified in the yfs.purge.path property. If this is not passed,
it defaults to the value specified in the yfs.properties file. If
a variable is introduced, then the yfs.purge.path is ignored.

To override this property, add an entry for it in the

<INSTALL_DIR>/properties/customer_overrides.properties
file. For additional information about overriding properties
using the customer_overrides.properties file, see the Sterling
Selling and Fulfillment Foundation: Properties Guide.

For more information about using variables for the log file
directory, see the Sterling Selling and Fulfillment Foundation:
Extending the Condition Builder.

For information about filename limitations related to

internationalization, see the Sterling Selling and Fulfillment
Foundation: Localization Guide.
Additional Purge Criteria

These parameters are used to override the order history purge retention days. This
override is configured based on the line types within each order defined at the enterprise
and document type levels.
Note: These additional parameters can be defined only for order history purge
(ORDHISTPRG) criteria.
Line Type Select the line types from the drop-down list. For more
information about defining line types, see the Sterling Selling
and Fulfillment Foundation: Distributed Order Management
Configuration Guide.
Additional Retention Days Enter the additional number of days (apart from the retention
days specified by the order history purge) the data is to be
retained in the database. Make sure that your table size takes
into account the number of retention days entered here.
Note: To be considered for additional retention days, the
order line must have at least some quantity that is not
cancelled or shorted.

Note: The history purge date cannot be reset when you restore the order after
it was purged. For example, if an order is purged with a history purge date of
20070801 and when the order is restored in the year 2006, the history purge
date still remains as 20070801.

Results

The following example provides an use-case of the line type purge in an order
placement scenario:

An order is placed with the following 4 order lines:

v Order Line 1 - Television
v Order Line 2 - 2 year Television service plan with Line Type as
2YR_WARRANTY. Therefore, the additional retention days are 721.

Chapter 24. Configuring a Document's Purge Criteria 251

 v Order Line 3 - Stereo
v Order Line 4 - 4 year Stereo service plan with Line Type as 4YR_WARRANTY.
Therefore, the additional retention days are 1451.

Assume that the order is set to be purged after 30 days. On day 1, the order moves
into a purgeable status. On day 30, the order is purged to the history table. The
purge history date is set as:

Today + 10 + Maximum(721, 1491) = 1491 days, where 10 is the number of

retention days for the history purge.

On day 40, the history purge agent does not pick up this order to purge, since the
purge history date is set. Rather, the order is purged from the history on day 1491.

252 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 25. Configuring Value-Added Services
Configuring Value-Added Services
Enterprises provide services along with the products they sell to their customers.
Some examples of services provided include:
v Annual maintenance contract.
v Installing a customer's home theater system.
v Installing software on a new computer, and configuring the computer to work
on a home network.

These services are either fulfilled by the enterprise, or by third-party service

providers who have a relationship with the enterprise to provide such services.

Defining Value-Added Services Modification Reasons

You can define reason codes for modifications. These codes define why
modification was made by a user in the Application Consoles.

Value-Added Services: Creating a Modification Reason

About this task

To create a modification reason:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Modification
Reasons. The Modification Reasons window displays in the work area.
3. Choose the Create New icon. The Modification Reason Details window
displays.
4. In Modification Reason, enter the modification reason as you want it to appear
throughout the system.
5. In Short Description, enter a brief description of the modification reason.
6. In Long Description, enter a more detailed description of the modification
reason.
7. Choose the Save icon.

Value-Added Services: Modifying a Modification Reason

About this task

To modify a modification reason:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Modification
Reasons. The Modification Reasons window displays in the work area.

© Copyright IBM Corp. 1999, 2012 253

 3. Select the applicable modification reason and choose the Details icon. The
Modification Reason Details window displays.
4. In Short Description, enter a brief description of the modification reason.
5. In Long Description, enter a more detailed description of the modification
reason.
6. Choose the Save icon.

Value-Added Services: Creating a New Modification Reason

Based on an Existing One
About this task

To create a new modification reason based on an existing one:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Modification
Reasons. The Modification Reasons window displays in the work area.
3. Select the applicable modification reason and choose the Save icon. The
Modification Reason Details window displays.
4. Enter information in the applicable fields.
5. Choose the Save icon.

Value-Added Services: Deleting a Modification Reason

About this task

To delete a modification reason:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Modification
Reasons. The Modification Reasons window displays in the work area.
3. Select the applicable modification reason and choose the Delete icon. The
Confirmation window displays.
4. Choose OK.

Defining Value-Added Services Cancellation Reasons

You can define reason codes for cancellation. These codes define why cancellation
was made by a user in the Application Consoles.

Creating a Cancellation Reason

About this task

To create a cancellation reason:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.

254 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 2. From the Distributed Order Management tree, choose VAS > Cancellation
Reasons. The Cancellation Reasons window displays in the work area.
3. Choose the Create New icon. The Cancellation Reason Details window
displays.
4. In Cancellation Reason, enter the cancellation reason as you want it to appear
throughout the system.
5. In Short Description, enter a brief description of the cancellation reason.
6. In Long Description, enter a more detailed description of the cancellation
reason.
7. Choose the Save icon.

Modifying a Cancellation Reason

About this task

To modify a cancellation reason:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Cancellation
Reasons. The Cancellation Reasons window displays in the work area.
3. Select the applicable cancellation reason and choose the Details icon. The
Cancellation Reason Details window displays.
4. In Short Description, enter a brief description of the cancellation reason.
5. In Long Description, enter a more detailed description of the cancellation
reason.
6. Choose the Save icon.

Creating a New Cancellation Reason Based on an Existing

One
About this task

To create a new cancellation reason based on an existing one:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Cancellation
Reasons. The Cancellation Reasons window displays in the work area.
3. Select the applicable cancellation reason and choose the Save As icon. The
Cancellation Reason Details window displays.
4. Enter information in the applicable fields.
5. Choose the Save icon.

Deleting a Cancellation Reason

About this task

To delete a cancellation reason:

Chapter 25. Configuring Value-Added Services 255

 Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Cancellation
Reasons. The Cancellation Reasons window displays in the work area.
3. Select the applicable cancellation reason and choose the Delete icon. The
Confirmation window displays.
4. Choose OK.

Defining Value-Added Services Appointment Failure Reasons

You can define reason codes for appointment failures. These codes define why an
appointment was failed by a user in the Application Consoles.

Creating a Appointment Failure Reason

About this task

To create a appointment failure reason:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Appointment
Failure Reasons. The Appointment Failure Reasons window displays in the
work area.
3. Choose the Create New icon. The Appointment Failure Reason Details window
displays.
4. In Appointment Failure Reason, enter the failure reason as you want it to
appear throughout the system.
5. In Short Description, enter a brief description of the appointment failure reason.
6. In Long Description, enter a more detailed description of the appointment
failure reason.
7. Choose the Save icon.

Modifying an Appointment Failure Reason

About this task

To modify a Appointment Failure reason:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Appointment
Failure Reasons. The Appointment Failure Reasons window displays in the
work area.
3. Select the applicable appointment failure reason and choose the Details icon.
The Appointment Failure Reason Details window displays.
4. In Short Description, enter a brief description of the appointment failure reason.
5. In Long Description, enter a more detailed description of the appointment
failure reason.
6. Choose the Save icon.

256 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Creating a New Appointment Failure Reason Based on an
Existing One
About this task

To create a new Appointment Failure reason based on an existing one:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Appointment
Failure Reasons. The Appointment Failure Reasons window displays in the
work area.
3. Select the applicable appointment failure reason and choose the Save As icon.
The Appointment Failure Reason Details window displays.
4. Enter information in the applicable fields.
5. Choose the Save icon.

Deleting an Appointment Failure Reason

About this task

To delete a Appointment Failure reason:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Appointment
Failure Reasons. The Appointment Failure Reasons window displays in the
work area.
3. Select the applicable appointment failure reason and choose the Delete icon.
The Confirmation window displays.
4. Choose OK.

Defining Value-Added Services Note Reasons

You can define reason codes for entering a note. These codes define why a note
was entered by a user in the Console.

Creating a Note Reason

About this task

To create a note reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Note Reasons. The Note Reasons window displays in the
work area.
2. Choose the Create New icon. The Note Reason Details window displays.
3. In Note Reason, enter the note reason as you want it to appear throughout the
system.
4. In Short Description, enter a brief description of the note reason.
5. In Long Description, enter a more detailed description of the note reason.
Chapter 25. Configuring Value-Added Services 257
 6. Choose the Save icon.

Modifying a Note Reason

About this task

To modify a note reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Note Reasons. The Note Reasons window displays in the
work area.
2. Select the applicable appointment failure reason and choose the Details icon.
The Note Reason Details window displays.
3. In Short Description, enter a brief description of the note reason.
4. In Long Description, enter a more detailed description of the note reason.
5. Choose the Save icon.

Creating a New Note Reason Based on an Existing One

About this task

To create a new note reason based on an existing one:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Note Reasons. The Note Reasons window displays in the
work area.
2. Select the applicable note reason and choose the Save As icon. The Note
Reason Details window displays.
3. Enter information in the applicable fields.
4. Choose the Save icon.

Deleting a Note Reason

About this task

To delete a note reason:

Procedure
1. From the tree in the application rules side panel, choose Document Specific >
(Document Type) > Note Reasons. The Note Reasons window displays in the
work area.
2. Select the applicable appointment failure reason and choose the Delete icon.
The Confirmation window displays.
3. Choose OK.

Defining Value-Added Services Instruction Types

You can define the common codes used when adding special instructions to an
work order document.

258 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Value-Added Services: Creating an Instruction Type
About this task

To create an instruction type:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Instruction Types.
The Instruction Types window displays in the work area. Choose the Create
New icon. The Instruction Type Details pop-up window displays.
3. In Instruction Type, enter the instruction type.
4. In Short Description, enter a brief description of the instruction type.
5. In Long Description, enter a more detailed description of the instruction type.
6. Choose the Save icon.

Value-Added Services: Modifying an Instruction Type

About this task

To modify an instruction type:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Instruction Types.
The Instruction Types window displays in the work area. Choose the Create
New icon. The Instruction Type Details pop-up window displays.
3. Select the applicable instruction type and choose the Details icon. The
Instruction Type Details pop-up window displays.
4. In Short Description, enter a brief description of the instruction type.
5. In Long Description, enter a more detailed description of the instruction type.
6. Choose the Save icon.

Value-Added Services: Deleting an Instruction Type

About this task

To delete an instruction type:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > Instruction Types.
The Instruction Types window displays in the work area. Choose the Create
New icon. The Instruction Type Details pop-up window displays.
3. Select the applicable instruction type and choose the Delete icon.

Defining Value-Added Services Rules

Pre-calling a customer is required for appointments that are made for distant dates.
You can make a pre-calls closer to the service date, to confirm the appointment
from the customer.

Chapter 25. Configuring Value-Added Services 259

 Setting Up Value-Added Services Pre-Call Rules
About this task

To set up Value-Added Services pre-call rules:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Rules. The VAS Rules Details window displays in the work area.
3. Select the appropriate condition for which you need to make a pre-call. The
pre-call status on work order is determined based on the selected condition. For
more information about the pre-call statuses, see the Sterling Selling and
Fulfillment Foundation: Javadocs.
4. Enter how many days in advance you need to make a pre-call closer to the
appointment date.
5. Choose the Save icon.

Setting Up Value-Added Services Other Rules

About this task

To set up Value-Added Services other rules:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Rules. The VAS Rules Details window displays in the work area.
3. Enter how many hours in advance you need to consolidate product lines to the
work order before the appointment date. A lead time zero (0) is equivalent to
12 a.m. the next day and excludes all work orders whose first appointment is
on the current date. Negative numbers can be entered in this field to apply the
rule to the current date. For example, -24 corresponds to 12 a.m. of the current
date. -12 corresponds to 12 p.m. (noon) of the current date.
4. Check the box in the Automatically remove association between product and
delivery service lines field if you want the system to automatically remove the
association between product and delivery service lines in a work order.

Note: However, even if the Automatically remove association between product

and delivery service lines is selected, the association will be removed only
when the corresponding product line or delivery service line is removed from
the work order.

Note: If the product line is removed from the work order, the association to the
corresponding delivery service will also be removed.

Note: If the delivery service line is removed from the work order, the
associations to all the product lines that are associated with the delivery service
line will be removed.

260 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 5. Select the Allow appointment date change to an earlier date after schedule
check box if you want to reschedule an appointment for a product line that
requires delivery and that has already been scheduled after taking an
appointment, to an earlier date.
6. Choose the Save icon.

Defining Value-Added Services Modification Groups

Most order document types flow through a pipeline without requiring any
intervention by a customer service representative. However, there are times when
modifications are required, such as modifying quantity or activities required.
Sterling Selling and Fulfillment Foundation supports modifications through the
Application Console and APIs. It is critical to decide which modifications are
allowed for each modification type, modification level, and status combination.

Note: Contemplate business and system integration implications before allowing a

modification that is disallowed as part of the system defaults.

You can configure rules and components used when determining what parts of
value-added services can be modified as well as when in the value-added services
lifecycle the modifications can be performed. The set of rules and components can
be classified into modification groups. Each modification group can be associated
with a user-defined condition. For more information about modification rules, see
the Sterling Selling and Fulfillment Foundation: Distributed Order Management
Configuration Guide.

Setting Up Value-Added Services Modification Groups

About this task

To set up a Value-Added Services modification group:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Modification Groups. The Status Modification Group List window displays
in the work area.
3. From the Status Modification Group List window, choose the Plus icon. The
Status Modification Group Details window displays.
4. Enter information in the applicable fields. For field value descriptions, see the
following table.
5. Click the Save icon to save the modification group.
Table 119. Status Modification Group Details Window
Field Description
Status Modification Group ID Enter a name for the status modification
group.
Description Enter a description for the status
modification group.
Inherited From Status Modification Group (Optional) Select a parent status
modification group if you want to inherit
modification rules from another group.

Chapter 25. Configuring Value-Added Services 261

 Table 119. Status Modification Group Details Window (continued)
Field Description
Is Override (Optional) Check this option if you want
this status modification group to take
precedence.
Condition (Optional) Select a condition if you want to
specify a condition for this status
modification group. Or, you can create a
condition by clicking the Plus icon, which
opens the Condition Detail window. Refer to
“Adding Conditions to a Status Modification
Group” on page 175 for information about
configuring conditions for status
modification groups.
Note: If you do not specify a condition, this
group's validation is enforced.
Subscribed Modification Types
Available Displays a list of available modification
types. This list includes all system-supplied
modification types as well as the custom
modification types that you created in the
Custom Modification window. To subscribe
a modification type, select the modification
type in the Available list and click the Right
Arrow icon.
Subscribed Displays a list of the modification types for
which you want to define modification
rules. To remove a modification type from
the subscribed list, select the modification
type in the Subscribed list and click the Left
Arrow icon. Click the Save icon to display
the subscribed modification types in the
Modification Rules tab.
Modification Rules
Group By Select a sort option for displaying
modification types in the Primary Info tab.
You can sort modification types by type,
level, and status.
Primary Info Displays the modification types that you
subscribed in the Subscribed Modification
Types tab. Expand the applicable
modification types and levels for which you
want to set up modification rules. Right
click on the applicable rule and choose
Allow, Disallow, or Ignore as per your
business practices. Refer to Table 65 on page
170 for field value descriptions.

Value-Added Services: Modifying a Modification Group

About this task

To modify a Value-Added Services modification group:

262 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Modification Groups. The Status Modification Group List window displays
in the work area.
3. From the Status Modification Group List window, select the applicable
modification group and choose the Edit icon. The Status Modification Group
Details window displays.
4. Enter information in the applicable fields. Refer to Table 119 on page 261 for
field value descriptions.
5. Click the Save icon.

Value-Added Services: Deleting a Modification Group

About this task

To delete a Value-Added Services modification group:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Modification Groups. The Status Modification Group List window displays
in the work area.
3. From the Status Modification Group List window, select the applicable
modification group and click the Delete icon.

Defining Value-Added Services Hold Types

Work orders can be placed on hold manually or automatically, by applying a
particular hold type. Certain transactions can be configured to not process
documents that are on a given hold. Likewise, modification types can be
configured to not process documents that are on a given hold. By default, all
transactions and modification types are allowed to process all documents for all
hold types.

The transactions that can be prevented from processing work orders on a given
hold type have the checkbox This Transaction Can Be Stopped From Processing
Orders That Are On Hold checked in the Others tab of the transaction details. For
more information about viewing transaction details, refer to the Sterling Selling and
Fulfillment Foundation: Configuration Guide.

Value-Added Services: Creating a Hold Type

About this task

To create a hold type:

Procedure
1. From the tree in the application rules side panel, choose VAS > VAS Process >
Hold Types. The Hold Types window displays in the work area.
2. Click the Create New icon. The Hold Type pop-up window displays. The type
of this hold in the Hold Type field, and its description in the Description field.

Chapter 25. Configuring Value-Added Services 263

 Enter the rest of the information in the applicable fields. Refer to Table 120,
Table 121 on page 265 and Table 122 on page 265 for field value descriptions.
3. Click the Save icon.
Table 120. Hold Type window, Hold Creation tab
Field Description
Hold Created Automatically
On Work Order Creation Check this to apply this hold type to all work orders on work
order creation.
On Resolution Of Hold Check this to apply this hold type on resolution of another
Type hold type. Select from the drop-down list the hold type that,
upon resolution, triggers this hold type.
Note: Sterling Selling and Fulfillment Foundation does not
check whether or not you are defining a circular hold type
definition. For example, if you define hold type B as being
applied on resolution of hold type A, and hold type A as
being applied on resolution of hold type B, you could create
an infinite loop that Sterling Selling and Fulfillment
Foundation does not warn you against.
When The Following Modification types that automatically apply this hold type to
Modifications Are a work order.
Performed
Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available modification
types that you wish to associate with this hold type to the
subscribed list.
v Use the left arrow to unsubscribe the modification types
that you wish to disassociate with this hold type and move
them back into the available list.
For All Work Orders Select this radio button if the above conditions should be
checked for all work orders.
Note: This option is only selectable once the created hold has
been saved.
Only For Work Orders Select this radio button if the above conditions should only be
Satisfying Following checked for work orders satisfying a certain condition. Click
Condition the Details icon to build or modify the condition for
evaluation. For more information about using the condition
builder, see the Sterling Selling and Fulfillment Foundation:
Configuration Guide.

The available attributes for this condition can be extended.

For more information, refer to the Sterling Selling and
Fulfillment Foundation: Extending the Condition Builder.
Note: This option is only selectable once the created hold has
been saved.
Hold Created Manually
By All Users Select this radio button if all user groups can apply this hold
to a work order.

264 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 120. Hold Type window, Hold Creation tab (continued)
Field Description
By Users Who Belong To Select this radio button if only users belonging to certain user
The Following User Groups groups may apply this hold to a work order.

Click the Details icon to modify the list. In the subsequent

pop-up window:
v Use the right arrow to move the available user groups that
you wish to associate with this hold type to the subscribed
list.
v Use the left arrow to unsubscribe the user groups that you
wish to disassociate with this hold type and move them
back into the available list.

Table 121. Hold Type window, Hold Resolution tab

Field Description
Hold Resolved Automatically
The Following From the drop-down list, select the time-triggered transaction
Time-Triggered Transaction that will process created holds.
Will Process Created Holds
The Following from the drop-down list, select the time-triggered transaction
Time-Triggered Transaction that will process rejected holds.
Will Process Rejected Holds
Hold Resolved Manually
By All Users Select this radio butting if all user groups may process this
hold.
By All Users Who Belong Select this radio button if only users belonging to certain user
To The Following Groups groups may process this hold.

Click the Details icon to modify the list. In the subsequent

pop-up window:
v Use the right arrow to move the available user groups that
you wish to associate with this hold type to the subscribed
list.
v Use the left arrow to unsubscribe the user groups that you
wish to disassociate with this hold type and move them
back into the available list.

Table 122. Hold Type window, Hold Effects tab

Fields Description
The Following Transactions Transactions that are disallowed when this hold type is
Will Be Stopped From applied to a work order.
Processing Work Orders
Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available modification
types that you wish to associate with this hold type to the
subscribed list.

Use the left arrow to unsubscribe the modification types that

you wish to disassociate with this hold type and move them
back into the available list.

Chapter 25. Configuring Value-Added Services 265

 Table 122. Hold Type window, Hold Effects tab (continued)
Fields Description
The Following Modification types are disallowed when this hold type is
Modifications Are Not applied to a work order.
Allowed For Work Orders
On This Hold Click the Details icon to modify the list. In the subsequent
pop-up window:
v Use the right arrow to move the available transactions that
you wish to associate with this hold type to the subscribed
list.

Use the left arrow to unsubscribe transactions that you wish

to disassociate with this hold type and move them back into
the available list.

Value-Added Services: Modifying a Hold Type

About this task

To modify a hold type:

Procedure
1. From the tree in the application rules side panel, choose VAS > VAS Process >
Hold Types. The Hold Types window displays in the work area.
2. Select the applicable hold type and click the Details icon. The Hold Type
pop-up window displays. Enter information in the applicable fields. Refer to
Table 120 on page 264, Table 121 on page 265 and Table 122 on page 265 for
field value descriptions.
3. Click the Save icon.

Value-Added Services: Deleting a Hold Type

About this task

To delete a hold type:

Procedure
1. From the tree in the application rules side panel, choose VAS > VAS Process >
Hold Types. The Hold Types window displays in the work area.
2. Select the applicable hold type and click the Delete icon.

Defining Value-Added Services Process Types

Value Added Services Process Type Details define parameters and templates that
distinguish a process type.

A process type pipeline is a series of transactions and statuses that guide document
types, such as a Value Added Services execution, through a predefined process.
You can also set up transactions consisting of events, actions, and conditions, as
they pertain to the pipeline you are configuring.

VAS Repositories

A value-added services repository is a logical collection of entities that define the

business process workflow.

266 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 The following entities are included in a repository:
v Pipelines
v Transactions
v Statuses
v Conditions
v Actions
v Service Definitions

Viewing Value-Added Services Process Type Details

About this task

To view Value-Added Services process type details:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Process Type Details. The Process Type Details window displays in the
work area.
3. In Process Type, VAS is automatically populated by the system.
4. In Process Type Name, the name of the process type displays, which is editable.
5. In Description, a brief description of the process type displays, which is
editable.

Defining Value-Added Services Process Model

The Value-Added Services process is modeled through a pipeline. This represents
the process configuration that is unique to an enterprise. For example, installing
Television at the customer’s site.

Value-Added Services: Pipeline Determination

Pipeline determination is used to set up conditions that affect which pipeline is
used during the start of the business process workflow.

Hub Rule
When you expand the Pipeline Determination branch, the components displayed
depends on what role you are logged in as. If you are logged in as a Hub role, the
Hub Rule displays. If you are logged in as an Enterprise role, both the Hub Rule
and all user created determination rules (For example, My Rule) components
display. Double-click on the Standard Work Order Pipeline rule to view the
pipeline determination rules.

Note: If you are logged in as an Enterprise role, the Hub Rule screen is grayed out
and cannot be modified.

Drag conditions and pipelines into the work area to construct pipeline
determination rules. A single pipeline or condition must be the root.

Conditions cannot link back to an earlier component in the chain and a pipeline
cannot be linked to twice.

Chapter 25. Configuring Value-Added Services 267

 Note: When configuring pipeline determination for an order document type
pipeline, please note that pipeline determination is only considered when adding a
line or creating an order. When changes are made to draft orders pipeline
determination does not occur.

Value-Added Services: Condition Variables for Pipeline

Determination
When using conditions for pipeline determination, the following condition
variables can be used:
v Enterprise Code
v Node
v Provider Organization
v Service Item ID

Value-Added Services: Pipelines

About this task

To view Value-Added Services pipeline details:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Process Model > Pipelines > Standard Work Order Pipeline. The Pipeline
Detail: Standard Work Order Pipeline (VAS Process) window displays in the
work area.

Results

For more information about creating, modifying, deleting, and monitoring rules,
see the Sterling Selling and Fulfillment Foundation: Configuration Guide.

268 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Value-Added Services: Transactions
About this task

Every process type has a set of base transactions defined for it. A transaction is a
logical unit of work that is necessary for performing activity within Sterling Selling
and Fulfillment Foundation. Base transactions are predefined transactions that
contain information about how the transaction behaves, such as how many copies
of a transaction can be kept in a process type and whether or not it can have
configurable base pick and drop statuses. Base transactions can be used to create
new transactions. These transactions can be changed within the limits defined in
the base transaction.

To view the transaction details of Value-Added Services pipeline:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Process Models.

Chapter 25. Configuring Value-Added Services 269

 3. In the VAS window, choose the Transactions icon. The Transactions tab
window displays.

Results

For more information about creating, modifying, or deleting transactions, see the
Sterling Selling and Fulfillment Foundation: Configuration Guide.
Table 123. Transactions Tab Window
Field Description
Allocate Work Order This transaction indicates the allocation of a work order
created for VAS.
Cancel Work Order This transaction indicates the cancellation of a work order
created for VAS.
Change Work Order Status This transaction indicates the change in status of a work
order created for VAS.
Confirm Work Order This transaction indicates that the work order needs to be
confirmed for VAS.
Create Work Order This transaction indicates creation of a work order for VAS.
Modify Work Order This transaction indicates the modification of a work order
for VAS.
Purge Work Order This transaction indicates the purge of work orders created
for VAS.
Purge Work Order History This transaction indicates the purge of the work order history
for VAS.
Release Work Order The transaction indicates the release of a work order created
for VAS.
Synchronize Task Queue The transaction indicates synchronization of task queue for
work orders created for VAS.
Work Order Monitor This transaction indicates monitoring of work orders created
for VAS.

Value-Added Services: Statuses

About this task

Statuses are the actual states that a document moves through in the pipeline. A
transaction can contain two types of statuses, a drop status and a pickup status. A
document is moved into a drop status when the events and conditions of a
transaction have been completed. A pickup status takes the document from the
previous drop status and moves it through the next transaction.

To view the status details of a Value-Added Services pipeline:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Process Models.
3. In the VAS window, choose the Status icon. The Statuses tab window displays.

270 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Results

For more information about creating, modifying, or deleting statuses, see the
Sterling Selling and Fulfillment Foundation: Configuration Guide.
Table 124. Statuses Tab Window
Field Description
Work Order Created This indicates that a work order is created.

This corresponds to the first step of the 'Create Work Order'

transaction.
Work Order Completed This indicates that a work order is complete.

This corresponds to the ‘Confirm Work Order' transaction.

Work Order Cancelled This indicates cancellation of a work order.

This corresponds to the ‘Cancel Work Order' transaction.

Value-Added Services: Conditions

About this task

A condition matches document type attributes against decision points and routes
the documents to different paths based on the specified attribute and value
combinations. The document type attributes against which conditions can be
created are predefined in Sterling Selling and Fulfillment Foundation. You can use
these attributes in any combination or you can create conditions that run the
appropriate application logic for specific circumstances.

To view the condition details of a Value-Added Services pipeline:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Process Models.
3. In the VAS window, choose the Conditions icon. The Conditions tab window
displays.

Results

For more information about creating, modifying, or deleting conditions, see the
Sterling Selling and Fulfillment Foundation: Configuration Guide.
Table 125. Conditions Tab Window
Field Description
Pre-Call This indicates the pre-call conditions specific to VAS pipeline.
Service Status This indicates the service status conditions specific to VAS
pipeline.

Chapter 25. Configuring Value-Added Services 271

 Value-Added Services: Actions
About this task

An action is a process or program that is triggered by an event. These processes

and programs send user alert notifications and automatically resolve issues.

For example, when the service is completed, you can set an action to send the
customer an e-mail.

To view the action details of a Value-Added Services pipeline:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Process Models.
3. In the VAS window, choose the Actions icon. The Actions tab window displays.

Results

For more information about creating, modifying, or deleting actions, see the
Sterling Selling and Fulfillment Foundation: Configuration Guide.
Table 126. Actions Tab Window
Field Description
Templates Default settings are provided for:

Publish Data—Sends data to external queue or internal

tables.

Raising an Exception—Raises an alert using the Event

Management from the published information.

Send Email—Raises an email action utilizing a template to

format from the published information.

Send Email-HTML format—Raises an email action to create

an HTML email format from the published information.

Value-Added Services: Service Definitions

About this task

Service definitions are a representation of the logic that regulates document

workflow services. The Service Builder is a graphical interface that enables you to
create a graphical representation of these services.

To view the service definition details of a Value-Added Services pipeline:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Process Models.

272 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 3. In the VAS window, choose the Service Definitions icon. The Service
Definitions tab window displays.

Results

For more information about creating, modifying, or deleting service conditions, see
the Sterling Selling and Fulfillment Foundation: Configuration Guide.
Table 127. Service Conditions Tab Window
Field Description
Service Definitions Displays service definitions that are specific to the VAS
pipeline.

Viewing Value-Added Services Date Types

About this task
Use Value-Added Services Monitoring to view Date Types and configure
Monitoring Events.

You can view Value-Added Services date types. To view date types:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Monitoring. The Monitoring: Work Order window displays. Choose the
Date Types tab.
Table 128. Monitoring: Work Order - Date Types
Field Description
Date Type The name of VAS date type.
Description The date type description.
Requested Indicates if the date type is requested by a user.
Expected Indicates if the date type represents a date the system expects
or has calculated something to occur.
Actual Indicate if the date type represents the actual date.

Defining Value-Added Services Event Monitoring

Events are used in instances where the Work Order Monitor may raise multiple
alerts of the same type. For example, for a work order if the pre-call status is
pending, and you have configured the Work Order Monitor to raise alerts and if
the pre-call confirmation is delayed, an alert would be raised against the work
order. You can create rules to aggregate all of these similar alerts and raise one
"root cause".
Table 129. View Events
Field Description
Event ID The event ID.
Description A brief description of the event.

Chapter 25. Configuring Value-Added Services 273

 Value-Added Services: Creating an Event Rule
About this task

To create an event rule:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Monitoring. The Monitoring: Work Order window displays. Choose the
Monitor Events tab.
3. In the Monitor Events list window, choose . The Monitor Event Details pop-up
window displays.
4. Enter information in the applicable fields. Refer to Table 130 for field value
descriptions.
5. Choose the Save icon.
Table 130. Event Monitoring
Field Description
Event ID The event ID.
Description A brief description of the event.
Requires Realert Check this box if you want the users to be re-alerted if the
issue has not been resolved within a certain timeframe.
Realert Interval If you have selected Requires Realert, enter the interval (in
hours) that re-alerts should be sent.
Automatically Resolve This flag must be checked to trigger a monitor event every
Alerts time an alert condition is detected on an order. To trigger an
alert only once when the alert condition is met, uncheck this
flag.
Event Identified By
Work Order Select this field if you want two or more alert conditions to
be treated the same, belonging to the same work order.
Service To Be Invoked Select the service to be invoked, whenever the event is raised.
Aggregate And Invoke Service For
Work Order Select this field if you want only one alert to be raised for a
work order when alert conditions are detected.

Value-Added Services: Modifying an Event

About this task

To modify an event rule:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Monitoring. The Monitoring: Work Order window displays. Choose the
Monitor Events tab.
3. In the Monitor Events window, choose the Details icon. The Monitor Event
Details window displays.

274 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 4. Enter information in the applicable fields. Refer to Table 130 on page 274 for
field value descriptions.
5. Choose the Save icon.

Value-Added Services: Creating a New Event

About this task

To create a new event rule:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Monitoring. The Monitoring: Work Order window displays. Choose the
Monitor Events tab.
3. In the Monitor Events window, choose the Details icon. The Monitor Event
Details window displays.
4. Choose the Save icon.

Value-Added Services: Deleting an Event

About this task

To delete an event:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
VAS Monitoring. The Monitoring: Work Order window displays. Choose the
Monitor Events tab.
3. In the Monitor Events window, choose the Delete icon. The Confirmation
window displays.
4. Choose OK.

Viewing Value-Added Services Purge Criteria

About this task

Transactional data collected by Sterling Selling and Fulfillment Foundation during

the execution are periodically removed from the 'live' transactional tables. It is
common to retain work order related information for extended period of time.
There are history tables provided for relevant transactional tables to move data
from the day-to-day 'live' tables to a historical table. Purges are the process by
which old data is removed from the system database. Purges minimize the number
of unused database records to increase search efficiency and reduce the size of the
required physical disk.

To view purge criteria:

Procedure
1. From the menu bar, choose Applications > Distributed Order Management. The
Distributed Order Management tree displays in the side panel.

Chapter 25. Configuring Value-Added Services 275

 2. From the Distributed Order Management tree, choose VAS > VAS Process >
Purge Criteria. The Purge Criteria List window displays.
Table 131. Purge Criteria
Field Description
Purge Code Identifies a purge program. This is a system defined code.
Purge Description A brief description of the purge.
Retention Days Automatically purges the work order information on
exceeding the specified retention days.

276 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 26. Time-Triggered Transaction Reference
Time-Triggered Transaction Reference
Sterling Selling and Fulfillment Foundation provides a collection of time-triggered
transactions, which are utilities that perform a variety of individual functions,
automatically and at specific time intervals.

Time-triggered transactions perform repetitive actions on a scheduled basis,

typically performing database updates, raising events, or calling APIs. One type of
transaction, monitors, are designed to watch for processes or circumstances that are
out of bounds and then raise alerts. Often, but not always, they retrieve tasks from
the task queue or work from the pipeline.

Some transactions enable you to collect statistical data regarding the application's
health. This data is collected periodically, using the value specified for the
yantra.statistics.persist.interval attribute in the yfs.properties file. By
default, statistics collection set to on. To override this property, add an entry in the
<INSTALL_DIR>/properties/customer_overrides.properties file. For additional
information about overriding properties using the customer_overrides.properties
file, see the Sterling Selling and Fulfillment Foundation: Properties Guide.

For more information about statistics persistence, see the Sterling Selling and
Fulfillment Foundation: Performance Management Guide. For more information about
the specific statistics parameters used, see the applicable time-triggered
transactions.

The time-triggered transactions described in this chapter are unique transactions,

that may or may not be document type specific. For document specific
transactions, the nomenclature helps define which unique transaction it is based
on: a transaction ID is in the format Unique_Transaction_ID.Document_Type_Code.
For example, the transaction ID for Purge Return is PURGE.0003, indicating that it is
based on the unique transaction PURGE, for document type 0003, which is Return
Order. Therefore, in order to be able to configure Purge Return, you should look
for the PURGE transaction ID in this chapter, which is Order Purge.

Sterling Selling and Fulfillment Foundation provides the following types of

time-triggered transactions:
v Business Process Time-Triggered Transactions - responsible for processing
v Time-Triggered Purge Transactions - clear out data that may be discarded after
having been processed
v Task Queue Syncher Time-Triggered Transactions - update the task queue
repository with the latest list of open tasks to be performed by each transaction,
based on the latest pipeline configuration
v Monitors - watch and send alerts for processing delays and exceptions

Sterling Selling and Fulfillment Foundation tracks the following statistics for each
time-triggered transaction:
v ExecuteMessageCreated - The number of jobs added to the JMS queue in a given
time interval.
v ExecuteMessageSuccess - The number of jobs that were run successfully in a
given time interval.
© Copyright IBM Corp. 1999, 2012 277
 v ExecuteMessageError - The number of jobs that failed to run in a given time
interval.
v GetJobsProcessed - The number of GetJob messages that were processed in a
given time interval.

Note: Some of the statistics collected and tracked in Release 9.1 for
time-triggered transactions, monitors, and integration and application servers
may change with the next release of Sterling Selling and Fulfillment Foundation.

Running Time-Triggered Transactions

All time-triggered transactions are threadable. This means that you can run
multiple instances of a transaction within a single process. For more information
about running time-triggered transactions, see the Sterling Selling and Fulfillment
Foundation: Installation Guide. For more information about fine-tuning system
performance while running them concurrently, see the Sterling Selling and
Fulfillment Foundation: Performance Management Guide.

Steps to Complete Before Scheduling Time-Triggered

Transactions
About this task

Before running and scheduling a time-triggered transaction, ensure that you have
completed the following:

Procedure
1. Configure a JMS Connection Factory to correlate with the QCF name
configured for the time-triggered transaction. The Sterling Selling and
Fulfillment Foundation factory defaults include the AGENT_QCF as the JMS
Connection Factory. For more information about configuring JMS, see the
documentation for your specific application server.
2. Configure JMS Server Destinations to correlate with the group or individual
name of the time-triggered transaction. The Sterling Selling and Fulfillment
Foundation factory defaults include the DefaultAgentQueue as the server
destination.
Do not put a dot (.) in the name of a JMS Server Destination, for
example,'A.0001'. If you do, Sterling Selling and Fulfillment Foundation is
unable to communicate with it.
3. Using the Applications Manager, configure each time-triggered transaction
required for your business process as described in the section entitled "Defining
Transactions" in the Sterling Selling and Fulfillment Foundation: Configuration
Guide. Each set of time-triggered transaction criteria parameters must ensure
the appropriate association of a JMS Agent Server.

Configuring Communication Between an Agent and a JMS Server

About this task

Setting up communication between an agent (time-triggered transaction) and a

remote JMS server requires that you do some prerequisite setup on your JMS
system, then do some configuration within the application, which consists of the
following procedures:

278 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 v If an initial context factory code for your JMS system is not provided with the
application, you must create one. See “Create an Initial Context Factory Code”
for the list of codes that are provided.
v Defining the transaction details – the time-triggered transaction, or agent, must
be edited to include connection information for your JMS system and the initial
context factory you create. See “Define the Transaction Information” on page
280.

For more information about time-triggered transactions and how they fit into the
larger picture of application business process modeling, see the Configuring Process
Models chapter. Also see the Configuring Alert Queues chapter for additional
information about queues and agents.

Prerequisites
About this task

Before starting, complete these tasks for your JMS Server. See your JMS Server
documentation for more information about performing these tasks.

Procedure
1. Configure the JMS Queue Connection Factory (QCF) and queues on your JMS
server.
2. Configure the JNDI representation of the queues on your JMS server.
Ensure that you have the following information available from these tasks:
v JNDI name for each queue
v JNDI QCF lookup
v JMS location - the provider URL for the JMS server

Results

Once you have completed the preceding tasks, complete the next two procedures
in the order shown. These are both done in the application.

Create an Initial Context Factory Code

About this task

Using an Initial Context Factory (ICF) class enables remote Java clients to connect
to your application. This class is provided by the application vendor. The
application uses ICF codes to identify these when setting up agents. Initial context
factory codes are predefined in the application for the following JMS vendors:
v IBM WebSphere® MQ (for MQSeries® accessed through a IBM WebSphere
Internet Inter-ORB Protocol URL)
v File (for MQSeries accessed through a file URL, as with Oracle WebLogic)
v Oracle WebLogic (for WebLogic JMS)
v JBoss (for JBoss JMS)

If you are using a JMS server that is not in the preceding list (for example,
ActiveMQ), you must create an initial context factory code for it in the application:

Chapter 26. Time-Triggered Transaction Reference 279

 Procedure
1. Open the Applications Manager. From the tree in the application rules side
panel, choose System Administration > Initial Context Factory Codes. The
Initial Context Factory Codes window displays in the work area.
2. Select the + icon to create a new initial context factory code. The Initial Context
Factory window is displayed.
3. In the Initial Context Factory field, enter the name of the class provided by
your JMS vendor. For example, for ActiveMQ, the class name is
org.apache.activemq.jndi.ActiveMQInitialContextFactory.
4. In the Short Description field, enter a descriptive name, up to 40 characters.
Make note of this name, because you will use it in the next procedure (see
“Define the Transaction Information”). For ActiveMQ, enter ActiveMQ.
5. In the Long Description field, enter a more detailed description for the initial
context factory, up to 100 characters.
6. Save the new initial context factory code and close the window.

Results

For more information about ICFs, see Creating an Initial Context Factory Code.

Define the Transaction Information

About this task

For the JMS server to communicate with the application, there must be a
time-triggered transaction configured with the JMS server and ICF information.

Procedure
1. Open the Applications Manager. From the tree in the application rules side
panel, double-click Process Modeling. The Process Modeling window displays
in the work area.
2. Select the desired tab, then Base Document Type, then double-click Process
Type.
3. Double-click the transaction that corresponds to the agent to be run.
4. Select the Time Triggered tab.
5. Create or select an existing Agent Criteria Definition to edit.
6. The Agent Criteria Details screen is displayed. Select the Runtime Properties
tab.
7. Select an existing Agent Server from the list or create your own
(recommended).
8. Select an existing Alert Queue from the list or create your own.
9. In the JMS Queue Name field, enter the JNDI name for the queue that you
created. See “Prerequisites” on page 279.
10. Enter the desired number of threads the agent should run (recommended not
to exceed 5 threads - if more than 5 are needed, start another agent in its own
JVM).
11. Select the Initial Context Factory code you created. See “Create an Initial
Context Factory Code” on page 279.
12. In the QCF Lookup field, enter the JNDI QCF lookup for the queue that you
created (this is the Queue Connection Factory created for the applicable JMS
Server). See “Prerequisites” on page 279.

280 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 13. Enter the Provider URL. This is the location where the JMS system resides,
and is JMS vendor specific.
14. Select whether the agent should trigger itself (recommended) and at what
interval (in minutes) or use an external trigger (triggeragent.sh in the
<install_dir>/install/bin directory).
15. See Setting up the JMS Security Properties for information about setting the
JMS Security option.
16. Leave the Criteria Parameters tab values at the default values.
17. Save the Agent Criteria Details and close the window.
18. Launch the agent in its own JVM by executing the startagentserver.sh/cmd
script in the <install_dir>/install/bin directory.

Results

For additional information about defining transactions and about this procedure,
see the sections Defining Transactions and Specifying a Transaction as Time-Triggered in
the Sterling Selling and Fulfillment Foundation: Configuration Guide.

Business Process Time-Triggered Transactions

All Business Process Time-Triggered Transactions have a CollectPendingJobs
criteria parameter. If this parameter is set to N, the agent does not collect
information about the pending jobs pertaining to this monitor. This pending job
information is used for monitoring the monitor in the System Management
Console.

By default, CollectPendingJobs is set to Y. It can be helpful to set it to N if one

particular time-triggered transaction is performing a significant amount of
getPendingJobs queries, and the overhead cost is too high.

Asynchronous Request Processor

This transaction completes any API request or service request in offline mode. It
picks up the API messages or service messages from the YFS_ASYNC_REQ table
and invokes the corresponding API or service. The messages can be inserted into
the YFS_ASYNC_REQ table using the createAsyncRequest API.

Attributes

Following are the attributes for this time-triggered transaction:

Table 132. Asynchronous Request Processor Attributes
Attribute Value
Base Transaction ID ASYNC_REQ_PROCESSOR
Base Process Type General
Abstract Transaction No

Chapter 26. Time-Triggered Transaction Reference 281

 Criteria Parameters

Following are the criteria parameters for this transaction:

Table 133. Asynchronous Request Processor Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Lead Days Number of days before the present date the agent will purge
the records. If left blank or specified as 0 (zero), it defaults to
30.
Maximum Error Count Maximum number of times the record is processed if an
exception is thrown. Once the number of unsuccessful
attempts equals this number, that record is not processed
further by the agent. If left blank or specified as 0 (zero), it
defaults to 20.
Reprocess Interval In Time in minutes after which the transaction will be
Minutes reprocessed - after it has been processed and has thrown an
exception.
ColonyID Required in a multischema deployment where the
YFS_ASYNC_REQ table may exist in multiple schemas. Runs
the agent for the colony.

Statistics Tracked

None

Pending Job Count

None

Events Raised

The following events are raised by this time-triggered transaction:

Table 134. Events Raised by the Asynchronous Request Processor
Template
Transaction/Event Key Data Data Published* Support?
HAS_EXCEPTIONS None YCP_ASYNC_REQ_ Yes
PROCESSOR.HAS_
EXCEPTIONS.html
*These files are located in the following directory:

<INSTALL_DIR>/xapidocs/api_javadocs/XSD/HTML

Case Insensitive Data Loader

The Case Insensitive Data Loader agent migrates data from columns marked
CaseInsensitiveSearch to shadow columns. The agent uses the transaction criteria
to identify the records that need to be updated and then converts the original

282 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
column values to lowercase values in the shadow columns. For more information
about enabling case insensitive searches, refer to the Sterling Selling and Fulfillment
Foundation: Extending the Database.

The Case Insensitive Data Loader agent is required for updating the existing data.
Once the shadow columns have been created, the Case Insensitive Data Loader
agent only needs to be run once for each table or table type. The shadow columns
are then populated in real-time by the application.

Attributes

The following are the attributes for this time-triggered transaction:

Table 135. Case Insensitive Data Loader Attributes
Attribute Value
Base Transaction ID DATA_LOADER
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 136. Case Insensitive Data Loader Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time.
v If left blank or the number specified is less than 10000, it
defaults to 5000.
v If the number specified is greater than 10000, then that
value is used.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
TableType Required in a multischema deployment when a table may
exist in multiple schemas.

Valid Values: CONFIGURATION, TRANSACTION, MASTER.

If set to CONFIGURATION, the agent runs for the records

associated with tables that have TableType as
CONFIGURATION.

If set to TRANSACTION, the agent runs for the records

associated with tables that have TableType as TRANSACTION.
Table Name Required. The table name for the records to be migrated to
shadow columns.

Chapter 26. Time-Triggered Transaction Reference 283

 Table 136. Case Insensitive Data Loader Criteria Parameters (continued)
Parameter Description
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

None.

Events Raised

None.

Change Load Status

This transaction is equivalent to the changeLoadStatus() API. For detailed
information about this transaction, see the Sterling Selling and Fulfillment Foundation:
Javadocs.

To be configured as part of your load processing pipeline, this transaction can be

used whenever an automatic change in the status of a load is required. This
automatic change could represent exporting load information to load planning
software or transmission to the load's carrier.

This transaction should be configured to work from the task queue.

Attributes
The following are the attributes for this time-triggered transaction:
Table 137. Change Load Status Attributes
Attribute Value
Base Transaction ID CHANGE_LOAD_STATUS
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction Yes
APIs Called changeLoadStatus()

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 138. Change Load Status Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

284 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 138. Change Load Status Parameters (continued)
Parameter Description
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 139. Change Load Status Statistics
Statistic Name Description
NumLoadsChanged Number of loads whose status was changed.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the CurrentDate value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the changeLoadStatus() API in the
Sterling Selling and Fulfillment Foundation: Javadocs.

Change Shipment Status

This transaction is equivalent to the changeShipmentStatus() API. For detailed
information about this transaction, see the Sterling Selling and Fulfillment Foundation:
Javadocs.

To be configured as part of your shipment processing pipeline, this transaction can

be used whenever an automatic change in the status of a shipment is required. For
example, this automatic change could represent exporting shipment information to
a warehouse management system or to transmit an Advance Shipping Notice to
the buyer.

This transaction should be configured to work from the task queue.

Attributes

The following are the attributes for this time-triggered transaction:

Table 140. Change Shipment Status Attributes
Attribute Value
Base Transaction ID CHANGE_SHIPMENT_STATUS
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction Yes
APIs Called None

Chapter 26. Time-Triggered Transaction Reference 285

 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 141. Change Shipment Status Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 142. Create Chained Order Statistics
Statistic Name Description
NumShipmentsChanged Number of shipments whose status was changed.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the changeShipmentStatus() API

in the Sterling Selling and Fulfillment Foundation: Javadocs.

Close Delivery Plan

To boost system performance, this transaction serves as a temporary purge until
the Delivery Plan Purge deletes delivery plan-related data (see “Delivery Plan
Purge” on page 357).

This transaction picks all delivery plans that do not have any of their loads or
shipments still open and marks the deliveryplan_closed_flag='Y'. This flag
indicates no further operations are possible on the plan.

This transaction corresponds to the base transaction close delivery plan

(CLOSE_DELIVERY_PLAN) in the load pipeline.

Any enterprise using the Console must schedule purge jobs.

286 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 143. Close Delivery Plan Attributes
Attribute Value
Base Transaction ID CLOSE_DELIVERY_PLAN
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 144. Close Delivery Plan Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:
Table 145. Close Delivery Plan Statistics
Statistic Name Description
NumDeliveryPlansClosed Number of delivery plans closed.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

The following events are raised by this time-triggered transaction:

Table 146. Events Raised by Close Delivery Plan Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS delivery_plan_ YDM_CLOSE_DELIVERY Yes
dbd.txt _PLAN.ON_
SUCCESS.xml

Chapter 26. Time-Triggered Transaction Reference 287

 However, note that the template name would read
<TransactionId>.ON_SUCCESS.xml.

Close Load
To boost system performance, this transaction serves as a temporary purge until
the Load Purge deletes load-related data (see “Load Purge” on page 371).

This transaction corresponds to the base transaction Close Load (CLOSE_LOAD) in

the load pipeline.

If you use the Load processing pipeline, you must schedule this transaction. Only
closed loads are picked up by the purge transaction. Therefore, it is required that
this transaction be made part of the pipeline and scheduled to run at the end of
the day.

This transaction should be made part of the pipeline. In addition, it should be

configured to work from the task queue.

Attributes

The following are the attributes for this time-triggered transaction:

Table 147. Close Load Attributes
Attribute Value
Base Transaction ID CLOSE_LOAD
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 148. Close Load Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

288 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Statistics Tracked

The following statistics are tracked for this transaction:

Table 149. Close Load Statistics
Statistic Name Description
NumLoadsClosed Number of loads closed.

Pending Job Count

For this transaction the pending job count is the number of open delivery plans,
which are not associated to any open loads and open shipments.

Events Raised

The following events are raised by this time-triggered transaction:

Table 150. Events Raised by the Close Load Transaction
Template
Transaction/Event Data Published Support?
ON_SUCCESS YDM_CLOSE_LOAD_PLAN.ON_ Yes
SUCCESS.xml

However, note that the template name would read

<TransactionId>.ON_SUCCESS.xml.

Close Manifest
This time-triggered transaction sets the manifest's MANIFEST_CLOSED_FLAG flag
to ‘Y' and updates the manifest status to CLOSED. This time-triggered transaction
confirms all the shipments that are pending confirmation, and closes the manifest.

Note: If the Close Manifest Agent is triggered without any criteria, it closes all the
candidate manifests across all ShipNodes.

The yfs.closemanifest.online property in the yfs.properties_ysc_ext.in file is

used to set this time-triggered transaction to work in online or offline mode.
v Online mode: In the online mode, the close manifest transaction runs as usual,
confirming all shipments in the manifest and then closing the manifest.
v Offline mode: In the offline mode, the close manifest transaction triggers an
agent and changes the manifest status to ‘Closure Requested'. When the agent
runs, it confirms either each shipment of the manifest, or closes the manifest, in
an execution call.

The mode of operation (online or offline) is decided on the basis of the value
specified for the yfs.closemanifest.online property in the
yfs.properties_ycs_ext.in file. To override this property, add an entry for it in
the <INSTALL_DIR>/properties/customer_overrides.properties file. For additional
information about overriding properties using the customer_overrides.properties
file, see the Sterling Selling and Fulfillment Foundation: Properties Guide.

The default out-of-the-box shipped property causes the Close Manifest transaction
to run in online mode.

Chapter 26. Time-Triggered Transaction Reference 289

 In instances where the Close Manifest transaction is run in offline mode, ensure
that all Agent Criteria defined for the transaction are configured properly.

Attributes

The following are the attributes for this time-triggered transaction:

Table 151. Close Manifest Attributes
Attribute Value
Base Transaction ID CLOSE_MANIFEST
Base Document Type General
Base Process Type Manifesting
Abstract Transaction No
APIs Called confirmShipment()

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 152. Close Manifest Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
AgentCriteriaGroup Optional. Used to classify nodes. This value can be accepted
by Sterling Selling and Fulfillment Foundation time-triggered
transactions that only perform their tasks on the nodes with a
matching node transactional velocity value.

Valid values are: LOW, HIGH, and any additional values

defined by the Hub from Application Platform > System
Administration > Agent Criteria Groups.
ShipNode Optional. Ship node for which the Close Manifest needs to be
run. If not passed, then all ship nodes are monitored.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following are statistics are tracked for this transaction:

Table 153. Close Manifest Statistics
Statistic Name Description
NumShipmentsConfirmed Number of shipments confirmed.
NumManifestsClosed Number of manifests closed.
NumManifestsErrored Number of manifests errored.
NumShipmentsErrored Number of shipments errored.

290 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Pending Job Count

For this transaction the pending job count is the sum of open manifests and
shipments belonging to manifests (with MANIFEST_STATUS='1200').

Events Raised

The following events are raised by this time-triggered transaction:

Table 154. Events Raised by the Close Manifest Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS manifest_dbd.txt YDM_CLOSE_MANIFEST Yes
.ON_SUCCESS.xml

Close Order
This time-triggered transaction sets the order's ORDER_CLOSED flag to ‘Y' and
raises the ON_SUCCESS event. These actions are only performed when the entire
ORDER_QTY for all the order lines reaches the configured pickup status. If an
order has ORDER_CLOSED set to ‘Y', it is not picked up for monitoring.

The Close Order agent must be configured along with the Purge transaction in the
pipeline.

Many of this transaction's elements and attributes are template-driven. Refer to the
XML for element level details.

The Close Order agent must be run before running the Monitor agent in order to
avoid alerts getting raised for cancelled orders.

Attributes

The following are the attributes for this time-triggered transaction:

Table 155. Close Order Attributes
Attribute Value
Base Transaction ID CLOSE_ORDER
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 156. Close Order Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

Chapter 26. Time-Triggered Transaction Reference 291

 Table 156. Close Order Criteria Parameters (continued)
Parameter Description
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 157. Close Order Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumOrdersClosed Number of orders closed.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table, if tasks on hold are not
ready to be processed.

Events Raised

The following events are raised by this time-triggered transaction:

Table 158. Events Raised by the Close Order Transaction
Transaction/Event Data Published Template Support?
ON_SUCCESS YFS_CLOSE_ORDER.ON_ Yes
SUCCESS.xml

Close Receipts
This time-triggered transaction closes receipts using the receiving rule specified.

Attributes

The following are the attributes for this time-triggered transaction:

Table 159. Close Receipts Attributes
Attribute Value
Base Transaction ID RECEIPT_COMPLETE
Base Document Type Order
Base Process Type Receipt (Purchase Order Receipt, Return Receipt, Transfer
Order Receipt, Receipt)
Abstract Transaction No

292 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 159. Close Receipts Attributes (continued)
Attribute Value
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 160. Close Receipts Criteria Parameters
Parameter Description
Action Triggers the transaction. If left blank, it defaults to Get, the
only valid value.
Number of Records To Number of records to retrieve and process at one time. If left
Buffer blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Enterprise for which the Close Receipts needs to be run. If not
passed, then all enterprises are monitored.
Node Node for which the Close Receipts needs to be run.
Note: Both Node and AgentCriteriaGroup cannot be blank.
You must specify a value for the Node parameter, the
AgentCriteriaGroup parameter, or both parameters.
AgentCriteriaGroup Used to classify nodes. This value can be accepted by Sterling
Selling and Fulfillment Foundation time-triggered transactions
that only perform their tasks on the nodes with a matching
node transactional velocity value.

Valid values are: LOW, HIGH, and any additional values

defined by the Hub from Application Platform > System
Administration > Agent Criteria Groups.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 161. Close Receipts Statistics
Statistic Name Description
NumReceiptsClosed Number of receipts closed.

Pending Job Count

For this transaction the pending job count is the number of Receipts that can be
closed (with OPEN_RECEIPT_FLAG='Y').

Chapter 26. Time-Triggered Transaction Reference 293

 Events Raised

The following events are raised by this time-triggered transaction:

Table 162. Events Raised by the Close Receipts Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS receipt_dbd.txt YFS_RECEIPT_COMPLETE Yes
.ON_SUCCESS.xml

Close Shipment
To boost system performance, this transaction serves as a temporary purge until
the Shipment Purge deletes all shipment-related data (see “Shipment Purge” on
page 408).

This transaction picks all shipments eligible to be closed, based on the pipeline
configuration for pickup for transaction CLOSE_SHIPMENT, and marks the
shipment_closed_flag='Y'. This flag indicates no further operations are possible on
the shipment. There is no status change involved. This transaction can be
configured in the pipeline so that it picks up either Shipped or Delivered status.

This transaction corresponds to the base transaction close shipment

(CLOSE_SHIPMENT) in the shipment pipeline.

This transaction should be made part of the pipeline. In addition, it should be

configured to work from the task queue.

Attributes

The following are the attributes for this time-triggered transaction:

Table 163. Close Shipment Attributes
Attribute Value
Base Transaction ID CLOSE_SHIPMENT
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 164. Close Shipment Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.

294 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 164. Close Shipment Criteria Parameters (continued)
Parameter Description
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following are statistics are tracked for this transaction:

Table 165. Close Shipment Statistics
Statistic Name Description
NumShipmentsClosed Number of shipments closed.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

The following events are raised by this time-triggered transaction:

Table 166. Events Raised by the Close Shipment Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS shipment_dbd.txt YDM_CLOSE_SHIPMENT. Yes
ON_SUCCESS.xml

Collect Shipment Statistics

Collect Shipment Statistics is a time-triggered transaction which can be invoked to
process the shipments, and generate information required for the Daily Shipment
Report.

Attributes

The following are the attributes for this time-triggered transaction:

Table 167. Collect Shipment Statistics Attributes
Attribute Value
Transaction Name Collect Shipment Statistics
Transaction ID COLLECT_STATISTICS
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None

Chapter 26. Time-Triggered Transaction Reference 295

 Table 167. Collect Shipment Statistics Attributes (continued)
Attribute Value
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 168. Collect Shipment Statistics Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Node Required. The ship node for which records are being
processed.
AgentCriteriaGroup Optional. Used to classify nodes. This value can be accepted
by Sterling Selling and Fulfillment Foundation time-triggered
transactions that only perform their tasks on the nodes with a
matching node transactional velocity value.

Valid values are: LOW, HIGH, and any additional values

defined by the Hub from Application Platform > System
Administration > Agent Criteria Groups.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 169. Statistics for Collect Shipment Statistics
Statistic Name Description
NumDaysStatisticsCollected Number of days for which shipment statistics have
been collected.

Pending Job Count

For this transaction the pending job count is the number of days for which
shipment statistics needs to be collected. The number of days is calculated as the
difference (in days) between the current date and the last date when shipment
statistics was collected.

296 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Events Raised

The following events are raised by this time-triggered transaction:

Table 170. Events Raised by the Collect Shipment Statistics Transaction
Template
Transaction/Event Data Published Support?
ON_SUCCESS YDM_COLLECT_STATISTICS.ON_ No
SUCCESS.xml

Consolidate Additional Inventory

The Consolidate Additional Inventory time-triggered transaction consolidates
supply and demand from the YFS_INVENTORY_SUPPLY_ADDNL and
YFS_INVENTORY_DEMAND_ADDNL tables. Consolidation is performed by
summing up the quantities of additional supply and demand in the
YFS_INVENTORY_SUPPLY and YFS_INVENTORY_DEMAND tables.

If no matching supply or demand is found, a new supply or demand is created

with the sum quantity of the changes in the YFS_INVENTORY_SUPPLY_ADDNL
and YFS_INVENTORY_DEMAND_ADDNL tables. After the changes are applied,
the records in the YFS_INVENTORY_SUPPLY_ADDNL and
YFS_INVENTORY_DEMAND_ADDNL tables that were used in the consolidation
process, are deleted.

Attributes

The following are the attributes for this time-triggered transaction:

Table 171. Consolidate Additional Inventory Attributes
Attribute Value
Base Transaction ID CONSOLIDATE_ADDNL_INV
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the parameters for this transaction:

Table 172. Consolidate Additional Inventory Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of inventory item records (whose
Buffer additional supplies and demands are consolidated) to retrieve
and process at one time. If left blank or specified as 0 (zero),
it defaults to 5000.

Chapter 26. Time-Triggered Transaction Reference 297

 Table 172. Consolidate Additional Inventory Criteria Parameters (continued)
Parameter Description
ColonyID Required in a multischema deployment where the
YFS_INVENTORY_SUPPLY_ADDNL and
YFS_INVENTORY_DEMAND_ADDNL tables may exist in
multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 173. Consolidate Additional Inventory Statistics
Statistic Name Description
NumInventorySupplyAddnlsProcessed Number of additional inventory supply
records processed in the consolidation.
NumInventoryDemandAddnlsProcessed Number of additional inventory
demand records processed in the
consolidation.
NumInventoryDemandDtlsProcessed Number of inventory demand details
records processed in the consolidation.

Pending Job Count

For this transaction the pending job count is the number of distinct inventory items
in the YFS_INVENTORY_SUPPLY_ADDNL and
YFS_INVENTORY_DEMAND_ADDNL tables, multiplied by two.

Events Raised

None.

Consolidate To Shipment
This is a task queue based transaction in the order pipeline that corresponds to
base transaction CONSOLIDATE_TO_SHIPMENT. This transaction finds a
shipment into which a given order release can be included. If it finds an existing
shipment, it calls changeShipment() API. Otherwise, it calls the createShipment()
API.

To find the existing shipments it matches ShipNode, ShipTo Address,

SellerOrganizationCode, Carrier, DocumentType and so forth, of the Order Release
with that of existing shipments.

This transaction is applicable only to the shipments in one of the following

Statuses:
v Shipment Created
v ESP Check Required
v On ESP Hold
v Released from ESP Hold
v Released For Routing
v Awaiting Routing

298 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
v Shipment Routing
v Sent To Node

To successfully consolidate an Order Release to an existing shipment, the Add Line

and related modification types on shipment in its current status should be allowed.

This transaction is a part of the Order Fulfillment pipeline. In addition, it should

be configured to work from the task queue.

Order releases with GIFT_FLAG set to Y are never consolidated with any other
release.

For more information, see the details provided under the createShipment(),
changeShipment(), releaseOrder(), and consolidateToShipment() APIs in the
Sterling Selling and Fulfillment Foundation: Javadocs.

Attributes

The following are the attributes for this time-triggered transaction:

Table 174. Consolidate to Shipment Attributes
Attribute Value
Base Transaction ID CONSOLIDATE_TO_SHIPMENT
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called createShipment() and changeShipment()
User Exits v It calls beforeConsolidateToShipment in
com.yantra.ydm.japi.ue.
v YDMBeforeConsolidateToShipment for each release before
it begins processing.
v After it finds the shipments, it calls
determineShipmentToConsolidateWith in
com.yantra.ydm.japi.ue.

YDMDetermineShipmentToConsolidateWith.

For more information, see the Sterling Selling and Fulfillment

Foundation: Javadocs.

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 175. Consolidate to Shipment Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.

Chapter 26. Time-Triggered Transaction Reference 299

 Table 175. Consolidate to Shipment Criteria Parameters (continued)
Parameter Description
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 176. Consolidate to Shipment Statistics
Statistic Name Description
NumOrderReleasesConsolidated Number of order releases consolidated.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

The following events are raised by this time-triggered transaction:

Table 177. Events Raised by the Consolidate to Shipment Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS shipment_dbd.txt YDM_CONSOLIDATE_TO Yes
_SHIPMENT.ON_
SUCCESS.xml

This transaction also raises events as specified under the createShipment() and
changeShipment() APIs in the Sterling Selling and Fulfillment Foundation: Javadocs.

However, note that the template name would read

<TransactionId>.ON_SUCCESS.xml.

Create Catalog Index

The Create Catalog Index transaction builds the Apache Lucene index file that is
used by catalog search. This index file enhances search performance by storing
denormalized item data that has been extracted from the Sterling Selling and
Fulfillment Foundation database or from an external source.

The Create Catalog Index transaction can be configured to perform the following
tasks:
v Run either a scheduled index build or user-initiated index build
v Build either a full or incremental index file
v Activate the index file

300 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
The Index Building Process

The Create Catalog Index transaction provides an agent for index building. Index
building is a multithread process in which the index building agent extracts item
and item-related information from the active selling catalog in the Sterling Selling
and Fulfillment Foundation database. If the corresponding XML configuration file
has been extended, the agent may extract this information from an external source.

The agent writes this information to multiple files, which identify the item data
that should be included in the final index. After the agent finishes writing the files,
it merges them into the final index file.

The multithread process provides the advantage of parallel processing. Large

amounts of database data are segmented and processed simultaneously, which is
faster and more scalable than sequentially processing one long file.

When writing information to multiple files, the index building agent performs the
following tasks for each item before looping to the next item:
v Queries the Sterling Selling and Fulfillment Foundation database or an external
source for data about the item.
v Uses information from the XML configuration file and extension file to
determine the data that be retrieved from the query.
v Retrieves relevant data from the Sterling Selling and Fulfillment Foundation
database.
v Creates a Lucene document for the item.

After the transaction creates a Lucene document for each item, the transaction
writes the documents to the index file based on the organization and the
organization's locales.

Configuration Options for Accessing Catalog Index Files

You can configure catalog index builds in one of the following two ways,
depending on your business requirements:
v Build the index on a shared, central disk that is accessible from all servers.
– Advantages:
- Centralized control of shared index
- No file transfer issues because the index is not copied across multiple
servers
– Limitation:
- Shared disk could become a single point of failure (if no redundancy is
involved)
- Volume of reads and writes from shared disk might slow performance,
depending on the setup
v Build and push a copy of the index to multiple servers via file transfer.
Automate this file transfer process to occur on completion of an index build, but
do not automatically activate the index. When all servers have acknowledged
the completion of the file transfer, call the manageSearchIndexTrigger API to
activate the index.
– Advantage:
- No central point of failure
– Limitation:

Chapter 26. Time-Triggered Transaction Reference 301

 - Possible overhead to building an pushing index files across servers
If you choose this method of building the index in one location and reading
it from another, refer to the Sterling Selling and Fulfillment Foundation:
Properties Guide for information about enabling different properties for
individual processes.

For more information about building and searching catalog indexes, see the Sterling
Selling and Fulfillment Foundation: Catalog Management Concepts Guide.

Attributes

The following table displays the attributes for the Create Catalog Index transaction.
Table 178. Create Catalog Index Attributes
Attribute Value
Base Transaction ID Create_Catalog_Index
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YCMParseAssetUE

YCMGetAdditionalCatalogIndexInformationUE

Criteria Parameters

The following table displays the criteria parameters for the Create Catalog Index
transaction.
Table 179. Create Catalog Index Criteria Parameters
Parameter Description
Organization Code Required. The organization code of the catalog organization or
subcatalog organization that maintains the search index.
Number of Messages Required. Number of messages to use when building the
index file.

Sterling Selling and Fulfillment Foundation processes only one

message per thread. For example, if Number of Messages is
set to 10 and Threads is set to 3, Sterling Selling and
Fulfillment Foundation processes only 3 messages at a time.
For more information about fine-tuning system performance,
see the Sterling Selling and Fulfillment Foundation: Performance
Management Guide.

302 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 179. Create Catalog Index Criteria Parameters (continued)
Parameter Description
Incremental Build Y or N.

Y to rebuild the existing index file. If you specify Y, Sterling

Selling and Fulfillment Foundation rebuilds the index based
on the last successful index build. The MaxModifyTS column
in the YFS_ITEM table determines whether or not an item's
attributes have changed. If any external attributes of an item
have changed, update the MaxModifyTS column by calling the
manageItem API on the item.

N to build a full index file.

This parameter is ignored for user-initiated index builds.

However, if scheduled builds are configured, ensure that you
specify whether you want a full or incremental index build.
Category Domain Optional. The catalog from which the index is built. The active
selling catalog of the catalog organization or subcatalog
organization is the default. If scheduled builds are configured,
ensure that you specify a catalog.
Auto Activate Y or N. Optional.

Y to activate the index after building the index file.

The default is N.
Auto Insert Search Index Y or N. Optional.
Trigger Y to enable scheduled builds of the catalog index file. The
agent refers to information stored in the
YFS_SEARCH_INDEX_TRIGGER table to determine when to
run the scheduled index build. Specify the type of index build,
whether full or incremental, in the agent criteria.

N to enable user-initiated builds of the catalog index file. The

agent continuously queries the
YFS_SEARCH_INDEX_TRIGGER table to determine whether
an index build is indicated. If a user starts an index build from
the IBM Sterling Business Center, the status setting in the table
changes to Scheduled, triggering the agent to build the index.
The user specifies the type of index build, whether full or
incremental, from the Sterling Business Center.

After a scheduled or user-initiated build runs, the user can

activate the index from the Sterling Business Center.
Alternatively, the agent can be configured to automatically
activate the index.

To allow both scheduled and user-initiated index builds,

configure the transaction to include two instances of the agent.
Configure one instance to trigger user-initiated builds and the
second instance to trigger scheduled index builds.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Chapter 26. Time-Triggered Transaction Reference 303

 Statistics Tracked

The following table shows the statistics for the Create Catalog Index transaction.
Table 180. Create Catalog Index Statistics
Statistic Name Description
SearchIndicesBuilt Number of search indices that have been built.

Pending Job Count

None.

Events Raised

The following events are raised by this time-triggered transaction:

Table 181. Events Raised by the Create Catalog Index Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS Not Published CATALOG_INDEX_BUILD.ON Yes
_SUCCESS.xml

Create Chained Order

This transaction creates one or more chained orders from an order whose
OrderHeaderKey is stored in the task queue object. Chainable lines of the order
can also be added to existing chained orders, instead of creating new chained
orders with these lines. The existing chained orders must be identified by the
determineChainedOrderForConsolidation user exit. If the user exit is not
implemented, or if the user exit returns a blank document, one or more new
chained orders are created.

For more information about the creation of chained orders, see the information
provided under the createChainedOrder() API and the
YFSDetermineChainedOrderForConsolidation user exit in the Sterling Selling and
Fulfillment Foundation: Javadocs.

This transaction should be invoked after order scheduling.

Attributes

The following are the attributes for this time-triggered transaction:

Table 182. Create Chained Order Attributes
Attribute Value
Base Transaction ID CHAINED_ORDER_CREATE
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction Yes
APIs Called createChainedOrder()

304 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 183. Create Chained Order Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 184. Create Chained Order Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed for creating chained
order.
NumOrdersCreated Number of chained orders created.

If there are 2 orders being processed and the first order creates a chained order, the
DetermineChainedOrderForConsolidation user exit causes the lines of the 2nd
order to be added to the first order. The number of chained orders created is
counted as 2.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the createChainedOrder() API in

the Sterling Selling and Fulfillment Foundation: Javadocs.

Create Derived Order

This transaction creates one or more derived orders from an order whose
OrderHeaderKey is stored in the task queue object. For existing derived orders,
you can add derivable lines or create new derived orders with these lines. The
existing derived orders must be identified by the
determineDerivedOrderForConsolidation user exit. If the user exit is not
implemented or if the user exit returns a null document, new derived orders are
created. For more information about the creation of derived orders, see the details

Chapter 26. Time-Triggered Transaction Reference 305

 provided under the createDerivedOrder() API and
YFSDetermineDerivedOrderForConsolidation user exit in the Sterling Selling and
Fulfillment Foundation: Javadocs.

Attributes

The following are the attributes for this time-triggered transaction:

Table 185. Create Derived Order Attributes
Attribute Value
Base Transaction ID DERIVED_ORDER_CREATE
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction Yes
APIs Called createDerivedOrder()

The TransactionKey posted in the task queue object must be an instance of the
Abstract Transaction DERIVED_ORDER_CREATE for the ProcessType associated
with the Order. Otherwise, an exception is thrown.

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 186. Create Derived Order Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 187. Create Derived Order Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumOrdersCreated Number of derived orders created.

If there are 2 orders being processed and the first order creates a derived order, the
DetermineChainedOrderForConsolidation user exit causes the lines of the 2nd
order to be added to the first order. The number of derived orders created is
counted as 2.

306 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the createDerivedOrder() API in

the Sterling Selling and Fulfillment Foundation: Javadocs.

Create Order Invoice

This transaction creates one or more invoices from an order whose
OrderHeaderKey is stored in a task queue object. The createOrderInvoice() API is
called for the OrderHeaderKey.

Configure this transaction in the pipeline only after all processing that can impact
quantity or price has been completed. Post invoice creation, the line quantity
cannot be reduced below the invoiced quantity.

Both the Create Order Invoice and Create Shipment Invoice transactions can create
invoices for an Order. When configuring your pipeline, ensure that only one of
these two transactions is configured to create invoices for a particular order line.
For more information, see “Create Shipment Invoice” on page 308.

Attributes

The following are the attributes for this time-triggered transaction:

Table 188. Create Order Invoice Attributes
Attribute Value
Base Transaction ID CREATE_ORDER_INVOICE
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction Yes
APIs Called createOrderInvoice()

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 189. Create Order Invoice Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Chapter 26. Time-Triggered Transaction Reference 307

 Statistics Tracked

The following statistics are tracked for this transaction:

Table 190. Create Order Invoice Statistics
Statistic Name Description
NumOrderInvoicesCreated Number of order invoices created.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the createOrderInvoice() API in

the Sterling Selling and Fulfillment Foundation: Javadocs.

Create Shipment Invoice

Invoicing is mandatory if an order requires payment processing. Invoicing occurs if
the following conditions are met:
v Invoicing is enabled at the document parameter level.
v The Seller requires payment processing.

This transaction creates one or more invoices for the shipment whose ShipmentKey
is stored in the task queue object. The createShipmentInvoice() API is called for
the ShipmentHeaderKey.

This transaction should be configured in the shipment pipeline only after the
shipment has reached a shipped status.

Both the Create Order Invoice and Create Shipment Invoice can create invoices for
an order. When configuring your pipeline, ensure that only one of these two
transactions is configured to create invoices for a particular order line. See “Create
Order Invoice” on page 307.

Attributes

The following are the attributes for this time-triggered transaction:

Table 191. Create Shipment Invoice Attributes
Attribute Value
Base Transaction ID CREATE_SHIPMENT_INVOICE
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction Yes
APIs Called createShipmentInvoice()

308 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 192. Create Shipment Invoice Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 193. Create Shipment Invoice Statistics
Statistic Name Description
NumShipmentInvoicesCreated Number of shipment invoices created.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the createShipmentInvoice() API

in the Sterling Selling and Fulfillment Foundation: Javadocs.

ESP Evaluator
The ESP Evaluator time-triggered transaction verifies whether a shipment meets
certain economic shipping parameters (ESP). ESP can be configured either for
buyer or enterprise, with the freight terms on the shipment determining which one
is used.

If the configuration is defined to hold shipment for ESP, the shipment when
created is held for ESP (with status On ESP Hold). This task queue based
time-triggered transaction evaluates the shipment for ESP, and passes it on to the
next step in the shipment pipeline if the criteria (weight and volume limits, plus
maximum days of hold up) are met. The shipment status is now set to Released
from ESP hold, and routing processing begins.

Chapter 26. Time-Triggered Transaction Reference 309

 Attributes

The following are the attributes for this time-triggered transaction:

Table 194. ESP Evaluator Attributes
Attribute Value
Base Transaction ID ESP_EVALUATOR.0001
Base Document Type Order
Base Process Type Outbound Shipment
Abstract Transaction No
APIs Called None
User Exits Called getNodeMinimumNotificationTime

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 195. ESP Evaluator Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
EnterpriseCode Optional. Enterprise for which the ESP Evaluator needs to be
run. If not passed, then all enterprises are monitored.
Number of Records to Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
Node Required. The ship node for which records are being
processed.
AgentCriteriaGroup Optional. Used to classify nodes. This value can be accepted
by Sterling Selling and Fulfillment Foundation time-triggered
transactions that only perform their tasks on the nodes with a
matching node transactional velocity value.

Valid values are: LOW, HIGH, and any additional values

defined by the Hub from Application Platform > System
Administration > Agent Criteria Groups.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

310 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Events Raised

The following events are raised by this time-triggered transaction:

Table 196. Events Raised by ESP Evaluator Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS shipment_dbd.txt ESP_EVALUATOR.ON_ Yes
SUCCESS.xml

Item Based Allocation

The Item Based Allocation transaction allocates unpromised and promised
demands of existing orders to more suitable supplies based upon inventory items
and nodes which have been triggered for the Item Based Allocation process in the
YFS_IBA_TRIGGER table.

The Item Based Allocation agent obtains and processes all Item Based Allocation
triggers from the YFS_IBA_TRIGGER table that meet the following conditions:
v IBA_RUN_REQUIRED = "Y"
v LAST_IBA_PROCESSED_TS was 'x' hours before current time, where 'x' is from
the ‘Item Based Allocation Agent Execution Interval (in hours)' rule in the
Installation rules. For more information about installation rules, refer to the topic
"System Administration Components: Defining Installation Rules" in the Sterling
Selling and Fulfillment Foundation: Configuration Guide. This rule is used to
indicate the interval that the Item Based Allocation agent should not reprocess
the triggers in the YFS_IBA_TRIGGER table, which were processed earlier. This
prevents the IBA agent from over-processing the item and node combination in
the given time interval to avoid any high loads on the system.
v PROCESSING_BY_AGENT="N" or PROCESS_OVER_BY_TS is before the current
timestamp. The PROCESSING_BY_AGENT field is used to prevent the picking
up of the IBA trigger which is being processed by another instance of the agent.

If InventoryOrganizationCode is specified in the agent criteria, only the IBA trigger

with inventory items of that inventory organization is retrieved.

For each triggered item and node combination, the agent finds all of the applicable
order lines or order line reservations that contain the item and node and tries to
move their unpromised and promised demands to more suitable available supplies
based on user-configured IBA selection rules or FIFO (First-In-First-Out) IBA
selection rules.

Sterling Selling and Fulfillment Foundation creates new positive order line
reservations with the matched supply's first ship date and negative order line
reservations for the existing demand ship date. Once all orders are processed, they
are placed on hold to be rescheduled if changes are detected in the order line
reservations.

The following configuration is required for the Item Based Allocation process:
v The Use Item Based Allocation rule needs to be enabled.
v Item and node need to have Item Based Allocation Allowed enabled.

Chapter 26. Time-Triggered Transaction Reference 311

 v A hold type is required to be set up for the change order line reservations
modification type so that the order can be placed on hold for rescheduling. For
more information, refer to the Sterling Selling and Fulfillment Foundation: Javadocs.

The ‘When a line is backordered, backorder against the highest priority ship node'
rule should be checked in order to reallocate backordered demand. For more
information, see the Fulfillment Rules section in the Sterling Selling and Fulfillment
Foundation: Distributed Order Management Configuration Guide.

Before processing the Item Based Allocation logic, the Item Based Allocation agent
updates the following fields on the Item Based Allocation trigger:
v PROCESSING_BY_AGENT = “Y”. This indicates that an instance of the agent is
currently processing this trigger.
v PROCESS_OVER_BY_TS = current time + 1 hr. This indicates the expected time
that the agent should finish with processing this IBA trigger. One hour is the
fixed window and cannot be changed. Sterling Selling and Fulfillment
Foundation treats the PROCESSING_BY_AGENT flag as “N” regardless of the
actual value when current timestamp is after this timestamp.
v IBA_RUN_REQUIRED = ”N”. This resets the IBA_RUN_REQUIRED flag back to
“N”.

Obtaining a List of Demands Based on Applicable Order Release

Statuses and Order Line Reservations to be Allocated

A list of demands is derived from applicable order release statuses and order line
reservations, which have the item and node in the IBA trigger. The following types
of demands are retrieved:
v Demands of chained orders
v Demands of orders with chained order already created
v Demands of orders with procurement node but chained order creation is not yet
created
v Demands of orders without procurement node
v Demands from order line reservations

The demand quantity is derived based on the order release status quantity with
the status from the Status Inventory Type configuration that has a demand type,
which considers the supply type with ‘Use Consider Demand Type for Item Based
Allocation' enabled. For more information, refer to the Sterling Selling and
Fulfillment Foundation: Global Inventory Visibility Configuration Guide.

Obtaining a List of Available Supplies for Allocation

Sterling Selling and Fulfillment Foundation obtains the available supply based on
the availability of the item at the node by ignoring unpromised and promised
demands. If the inventory organization maintains its inventory externally, the
external availability can be read by the YFSGetExternalInventoryUE user exit. Only
the availability of supplies that consider the ‘Demand Type Look for Availability
during Item Based Allocation' are used in the allocation logic. For more
information, refer to the Sterling Selling and Fulfillment Foundation: Global Inventory
Visibility Configuration Guide.

Allocated demands should be matched with the same supplies as "Demand to look
for during release".

312 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Matching Demands Against Supplies in FIFO (First-In-First-Out)
Order

Sterling Selling and Fulfillment Foundation sorts the list of available supplies in
the order of the first shippable date (ETA), and matches the obtained list of
demands using the top-down logic (unlike the normal matching logic for obtaining
availability, where matches are based on the closest ETA). Demands are allocated
in the following orders:
v Demands of chained orders - first based on user-configured sequencing rules,
and then in ascending order of order creation date. (These types of demands are
matched based on the closest ETA to avoid any changes in the chained orders).
v Demands of orders with a chained order already created - first based on
user-configured sequencing rules, then in ascending order of product availability
date. (These types of demands are matched based on the closest ETA to avoid
any changes in the orders).
v Demands of orders for which procurement node and chained order creation is
imminent (within the advanced notification time window) - first based on
user-configured sequencing rules, then in order of order creation date.
v Demands of orders without a procurement node and within the release window
(advanced notification time window) - first based on user-configured sequencing
rules, then in order of order creation date.
v Demands from order line reservations on the order lines in the order of
requested reservation date, and leftover demands (outside of the advanced
notification time window) of orders with or without a procurement node, first
based on user-configured sequencing rules and then in the order of order
creation date.
v Demands from inventory reservations in the order of ship date.

Notice that different types of demands are given different priorities based on their
significance. The demands of chained orders or orders related to chained orders
are treated with a higher priority than the demands of normal orders. Furthermore,
the demands with a ship date within the advanced notification time window also
have a higher priority than the demands with a date outside of the advanced
notification time window.

Updating Order Reservations for the Matched Demands

After matching the available supply and demand in user-configured sequencing

and then in FIFO order, the system builds up a list of order line reservation
changes and inventory demand changes (corresponding to the order line
reservation changes) and summarize them to optimize the number of order
reservation updates and inventory updates. Negative order line reservations are
added for the matched demands. Positive order reservations are added for the
matched demands with the product availability date set to the matched supplies'
first ship date.

After the Item Based Allocation agent completes its tasks for an Item Based
Allocation trigger, it updates the fields of the trigger with the following values:
v IBA_REQUIRED = "N"
v LAST_IBA_PROCESSED_TS = current timestamp.
v PROCESS_OVER_BY_TS = current timestamp.
v PROCESSING_BY_AGENT = ”N”

Chapter 26. Time-Triggered Transaction Reference 313

 The Item Based Allocation agent should be used in conjunction with the
rescheduling process as the rescheduling process reschedules the affected orders by
utilizing the order line reservations created by the Item Based Allocation process.

Attributes

The following are the attributes for this time-triggered transaction:

Table 197. Item Based Allocation Attributes
Attribute Value
Base Transaction ID ITEM_BASED_ALLOCATION
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called changeOrder – for updating the order line reservations created
as part of the Item Based Allocation process.
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 198. Item Based Allocation Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
InventoryOrganization The inventory organization code of the inventory items which
Code are processed by the Item Based Allocation agent. If provided,
only the IBA triggers with the inventory item that belongs to
this inventory organization are processed.
ColonyID Required in a multischema deployment where the
YFS_IBA_TRIGGER table may exist in multiple schemas. Runs
the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 199. Item Based Allocation Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed by the Item Based
Allocation agent.
NumOrdersRequiredReschedule Number of orders required rescheduling as the
result of Item Based Allocation process.

Pending Job Count

None.

314 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Events Raised

This transaction raises events as specified under the changeOrder API in the
Sterling Selling and Fulfillment Foundation: Javadocs.

Mark Load as Trailer Loaded

This is a time-triggered transaction which works on “Load pipeline”.

This time-triggered transaction gets records from the Task Q. This transaction is
used to mark the load as trailer loaded when all containers for the load are on the
trailer.

Attributes

The following are the attributes for this time-triggered transaction:

Table 200. Mark Load As Trailer Loaded Attributes
Attribute Value
Base Transaction ID MARK_AS_TRAILER_LOADED
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 201. Mark Load As Trailer Loaded Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ReprocessInterval Optional. Reprocess Interval is the time taken to reprocess the
load.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 202. Mark Load As Trailer Loaded Statistics
Statistic Name Description
NumLoadsChanged Number of trailer loads changed.

Chapter 26. Time-Triggered Transaction Reference 315

 Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

None.

Match Inventory
Match Inventory processes all pending records in the
YFS_INVENTORY_SHIPMENT table. Pending records have a smaller number in
POSTED_QUANTITY than in QUANTITY.

Each pending record is matched against the receipt records in

YFS_INVENTORY_RECEIPT table by applying the inventory cost determination
logic. The unit cost at which the sales and receipt data are matched is also posted
in YFS_INVENTORY_MATCH table.

Use this transaction if any of the configured ship nodes maintain inventory cost.

Attributes

The following are the attributes for this time-triggered transaction:

Table 203. Match Inventory Attributes
Attribute Value
Base Transaction ID INVENTORY_MATCH
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 204. Match Inventory Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
Number of Records To Buffer Optional. Number of records to retrieve and process at
one time. If left blank or specified as 0 (zero), it
defaults to 5000.
InventoryOrganizationCode Optional. Valid inventory owner organization.
Organization to process in this run. If not passed, all
inventory organizations are processed.
CutOffDate Optional. If passed, records are matched up to this
date. Defaults to all unmatched records in Database.

316 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 204. Match Inventory Criteria Parameters (continued)
Parameter Description
ColonyID Required in a multischema deployment where the
YFS_INVENTORY_SHIPMENT,
YFS_INVENTORY_RECEIPT, and the
YFS_INVENTORY_MATCH tables may exist in
multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 205. Match Inventory Statistics
Statistic Name Description
NumInventoryShipmentsProcessed Number of inventory shipments processed.
NumInventoryMatchesInserted Number of inventory matches inserted.

Pending Job Count

For this transaction the pending job count is the number of distinct inventory items
that exist in the YFS_INVENTORY_SHIPMENT table where the QUANTITY value
is not equal to the POSTED_QUANTITY value.

Events Raised

None.

Payment Collection
This transaction requests credit validation for orders that are pending authorization
or charging.

Use this transaction for creating authorization and charge requests.

This transaction works in combination with the Payment Execution transaction.

Although this transaction can run independent of that transaction, authorization
and collection occurs only after the Payment Execution dependencies are met. For
more details, see “Payment Execution” on page 319.

Attributes

The following are the attributes for this time-triggered transaction:

Table 206. Payment Collection Attributes for Sales Orders
Attribute Value
Base Transaction ID PAYMENT_COLLECTION
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called requestCollection()

Chapter 26. Time-Triggered Transaction Reference 317

 Table 207. Payment Collection Attributes for Return Orders
Attribute Value
Base Transaction ID PAYMENT_COLLECTION.0003
Base Document Type Order
Base Process Type Reverse Logistics
Abstract Transaction No
APIs Called requestCollection()

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 208. Payment Collection Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. The enterprise for which the transaction needs to be
run. If left blank, orders for all enterprises are processed. If
specified, only orders for that enterprise are processed.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.
HoldTypeOnRollback If the HoldTypeOnRollback criteria is populated and the
requestCollection agent throws an exception, for example,
from the getFundsAvailable user exit, HoldTypeOnRollback
will be used to put the order on hold. If using the old order
hold functionality, this will be used as the hold reason. If the
hold type does not exist, an exception is thrown.

If the HoldTypeOnRollback criteria is not populated, the order

will not be put on hold if an exception is thrown.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 209. Payment Collection Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumChargeReqsCreated Number of charge requests created.
NumAuthorizationReqsCreated Number of authorization requests created.

Pending Job Count

For this transaction the pending job count is the number of orders in the
appropriate payment statuses with the value of the
AUTHORIZATION_EXPIRATION_DATE is less than or equal to (<=) the current
date. The appropriate payment statuses for such orders are:
v AWAIT_PAY_INFO

318 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 v AWAIT_AUTH
v REQUESTED_AUTH
v REQUEST_CHARGE
v AUTHORIZED, INVOICED
v PAID
v RELEASE_HOLD
v FAILED_AUTH
v FAILED_CHARGE
v VERIFY
v FAILED

Events Raised

The following events are raised by this time-triggered transaction:

Table 210. Events Raised by the Payment Collection Transaction
Template
Transaction/Event Key Data Data Published Support?
INCOMPLETE_PAYMENT modifyOrder YFS_PAYMENT_ Yes
_INFORMATION _dbd.txt COLLECTON.INCOMPLETE
_PAYMENT
_INFORMATION.xml
PAYMENT_STATUS YFS_PAYMENT YFS_PAYMENT_ Yes
_COLLECTION COLLECTION.
.PAYMENT PAYMENT_STATUS.xml
_STATUS_
dtd.txt
REQUEST_PAYMENT_ YFS_PAYMENT_ Yes
STATUS COLLECTION.REQUEST
_PAYMENT_STATUS.
xml
ON_LIABILITY_ modifyOrder YFS_PAYMENT_ Yes
TRANSFER _dbd.txt COLLECTION.ON_
LIABILITY_TRANSFER.xml
ON_INVOICE_ order_dbd/txt YFS_CREATE_ORDER_ Yes
COLLECTION INVOICE.ON_
INVOICE_
COLLECTION.xml

Payment Execution
This transaction processes all requests that are pending authorization and charging.

Note: If the charge transaction request has an open authorization reversal, the
charges are not collected.

Use this time-triggered transaction for processing all authorization and charge
requests.

This transaction requires interfacing with a product that provides financial services.

Chapter 26. Time-Triggered Transaction Reference 319

 Attributes

The following are the attributes for this time-triggered transaction:

Table 211. Payment Execution Attributes for Sales Orders
Attribute Value
Base Transaction ID PAYMENT_EXECUTION
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called executeCollection()
User Exits Called collectionCreditCard, collectionOthers,
collectionCustomerAcct

Table 212. Payment Execution Attributes for Return Orders

Attribute Value
Base Transaction ID PAYMENT_EXECUTION.0003
Base Document Type Order
Base Process Type Reverse Logistics
Abstract Transaction No
APIs Called executeCollection()
User Exits Called collectionCreditCard, collectionOthers,
collectionCustomerAcct

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 213. Payment Execution Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ChargeType Type of credit card process. Valid values are:
v AUTHORIZATION - Validates the credit card account
v CHARGE - Applies the charge to the credit card
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 214. Payment Execution Statistics
Statistic Name Description
NumAuthTransProcessed Number of authorization transaction
processed.

320 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 214. Payment Execution Statistics (continued)
Statistic Name Description
NumAuthTransSuccessfullyProcessed Number of successful returns from user exit
for authorization transaction processed.
NumChargeTransProcessed Number of charge transaction processed.
NumChargeTransSuccessfullyProcessed Number of successful returns from user exit
for charge transaction processed.
NumCollectionValidations Number of successful returns from the
invoked validate collection user exits.
NumCreditCardCollections Number of credit card collections.
NumCustomerAccountCollections Number of successful returns from the
customer account collection user exits.
NumOtherCollections Number of successful returns from the other
collection user exits.

Pending Job Count

For this transaction the pending job count is the number of open charge and
authorization transactions.

Events Raised

The following events are raised by this time-triggered transaction:

Table 215. Events Raised by Payment Execution Transaction
Template
Transaction/Event Key Data Data Published Support?
CHARGE_FAILED modifyOrder PAYMENT_EXECUTION_ No
dbd.txt CHARGE_FAILED_dbd.txt

This transaction raises events as specified under the executeCollection() API in

the Sterling Selling and Fulfillment Foundation: Javadocs.

Post Inventory Match

This transaction processes all open records in YFS_INVENTORY_MATCH table
and posts the records to a financial system. An open record in the
YFS_INVENTORY_MATCH table has the status of 01. After posting, the status is
changed to 02.

Use this transaction if any of the configured ship nodes maintain inventory cost.

Attributes

The following are the attributes for this time-triggered transaction:

Table 216. Post Inventory Match Attributes
Attribute Value
Base Transaction ID POST_INVENTORY_MATCH
Base Document Type General

Chapter 26. Time-Triggered Transaction Reference 321

 Table 216. Post Inventory Match Attributes (continued)
Attribute Value
Base Process Type General
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 217. Post Inventory Match Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where the
YFS_INVENTORY_MATCH table may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 218. Post Inventory Match Statistics
Statistic Name Description
NumInventoryMatchPosted Number of inventory match records posted.

Pending Job Count

For this transaction the pending job count is the number of inventory matches with
an open status.

Events Raised

The following events are raised by this time-triggered transaction:

Table 219. Events Raised by the Post Inventory Match Transaction
Template
Transaction/Event Key Data Data Published Support?
POST_INVENTORY_MATCH POST_ YFS_postInventory No
INVENTORY_ Match_output.xml
MATCH_dbd.txt

Process Order Hold Type

You can create a time-triggered transaction, derived from the
PROCESS_ORDER_HOLD_TYPE abstract transaction. It can be configured as the
processing transaction for one or more hold types. If an order is associated with a

322 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
hold type that has a transaction configured as the processing transaction, a record
is created in the YFS_TASK_Q table for processing that transaction.

When the processing transaction is triggered, it checks the hold types that it can
process based on the hold type configuration. If no hold types can be processed,
the YFS_TASK_Q record is deleted. If some hold types can be processed, the
processOrderHoldType user exit is invoked with the list of hold types to be
processed. The processOrderHoldType user exit returns the list of hold types that
can be removed from the order.

The transaction then modifies the order and updates the order hold type list based
on the output returned by the processOrderHoldType user exit. If now no hold
types can be processed, the YFS_TASK_Q record is deleted. If some hold types can
still be processed, YFS_TASK_Q is updated with the next available date.

You can also call the processOrderHoldType user exit to add new hold types or
change the status of a hold type that is already applied to an order. For more
information about the processOrderHoldType user exit, see the Sterling Selling and
Fulfillment Foundation: Javadocs.

Attributes

The following are the attributes for this time-triggered transaction:

Table 220. Process Order Hold Type Attributes
Attribute Value
Base Transaction ID PROCESS_ORDER_HOLD_TYPE
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction Yes
APIs Called changeOrder

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 221. Process Order Hold Type Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where the
YFS_TASK_Q table may exist in multiple schemas. Runs the
agent for the colony.

Statistics Tracked

None.

Chapter 26. Time-Triggered Transaction Reference 323

 Pending Job Count

None

Events Raised

The following events are raised by this time-triggered transaction:

Table 222. Events Raised by Process Order Hold Type Transaction
Template
Transaction/Event Raised when... Key Data Data Published Support?
ON_SUCCESS On success modifyOrder_ YFS_ORDER_ Yes *
dbd.txt CHANGE.ON_
SUCCESS.xml
ON_HOLD_TYPE The status of a modifyOrder_ YFS_ON_ Yes
_STATUS_ hold type is dbd.txt HOLD_TYPE_
CHANGE changed. STATUS_
CHANGE.xml
ON_ORDER_ The status of a modifyOrder_ YFS_ON_ Yes
LINE_HOLD_ hold type is dbd.txt ORDER_LINE
TYPE_STATUS_ changed. _HOLD_TYPE
CHANGE _STATUS_
CHANGE.xml
* Note: Some of the elements and attributes are not template-driven. Refer to the xml for
element level details.

Process Work Order Hold Type

This time-triggered transaction is identical to the Process Order Hold Type
transaction, but it is used for work orders instead.

Attributes

The following are the attributes for this time-triggered transaction:

Table 223. Process Work Order Hold Type Attributes
Attribute Value
Base Transaction ID PROCESS_WO_ORDER_HOLD_TYPE
Base Document Type Work Order
Base Process Type VAS Process
Abstract Transaction Yes
APIs Called modifyWorkOrder

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 224. Process Work Order Hold Type Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

324 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 224. Process Work Order Hold Type Parameters (continued)
Parameter Description
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

None

Events Raised

The following events are raised by this time-triggered transaction:

Table 225. Events Raised by Process Work Order Hold Type Transaction
Template
Transaction/Event Raised when... Key Data Data Published Support?
ON_SUCCESS On success workOrder_ VAS_MODIFY_ Yes *
dbd.txt WORK_ORDER
.ON_SUCCESS.
xml
ON_HOLD_TYPE_ The status of a workOrder_ VAS_ON_HOLD Yes
STATUS_ hold type is |dbd.txt _TYPE_STATUS
CHANGE changed. _CHANGE.xml
* Note: Some of the elements and attributes are not template driven. Refer to the xml for
elements level details.

Publish Negotiation Results

This transaction publishes the negotiated terms to the order.

Use this transaction in environments where an order must go through a

negotiation phase.

This transaction needs to be run after negotiation is completed.

Attributes

The following are the attributes for this time-triggered transaction:

Table 226. Publish Negotiation Results Attributes
Attribute Value
Base Transaction ID PUBLISH_ORD_NEGOTIATION

Chapter 26. Time-Triggered Transaction Reference 325

 Table 226. Publish Negotiation Results Attributes (continued)
Attribute Value
Base Document Type Order
Base Process Type Order Negotiation
Abstract Transaction No
APIs Called None

Criteria Parameters
The following are the criteria parameters for this transaction:
Table 227. Publish Negotiation Results Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 228. Publish Negotiation Results Statistics
Statistic Name Description
NumNegotiationsProcessed Number of negotiations processed.
NumNegotiationsPublished Number of negotiations published.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

The following events are raised by this time-triggered transaction:

Table 229. Events Raised by Publish Negotiation Results Transaction
Template
Base Transaction Raised when... Key Data Data Published Support?
PUBLISH_ORD On success Negotiation_dbd YCP_get Yes *
_NEGOTIATION/ .txt Negotiation
ON_SUCCESS Details_output.
xml

326 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 229. Events Raised by Publish Negotiation Results Transaction (continued)
Template
Base Transaction Raised when... Key Data Data Published Support?
RECEIVE_ORD On success, when Number of receiveOrder No
_NEGOTIATION/ DocumentType is concurrent time- Negotiation_dbd.
ON_SUCCESS 0001, EntityType triggered txt
is ORDER. transactions
running.
* Note: Template used for this event is the same template used by the
getNegotiationDetails() API to form the output XML.

Release
This transaction releases orders to specific ship nodes, making sure that the
scheduled ship nodes have enough inventory to process the order.

This transaction should be invoked after the scheduling process.

For more details, see the information provided under the releaseOrder() API in
the Sterling Selling and Fulfillment Foundation: Javadocs.

If you run the combined ‘Schedule and Release' agent, do not also run the
individual Schedule or the individual Release agents.

Attributes

The following are the attributes for this time-triggered transaction:

Table 230. Release Attributes
Attribute Value
Base Transaction ID RELEASE
Base Document Type Order
Base Process Type Order Fulfillment
APIs Called releaseOrder()

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 231. Release Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
IgnoreReleaseDate Optional. Determines whether the schedule process should
ignore line release date criteria. Valid values are:
v Y - Releases line quantities regardless of release date criteria
v N - Default value. Releases line quantities only after release
date criteria have been met.

Chapter 26. Time-Triggered Transaction Reference 327

 Table 231. Release Criteria Parameters (continued)
Parameter Description
CheckInventory Optional. Determine whether inventory should be checked.
Valid values are:
v Y - Default value. Inventory needs to be checked.
v N - Inventory does not need to be checked.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 232. Release Criteria Statistics
Statistic Name Description
NumFutureDateFailures Number of orders did not attempt to release
because of future date failures.
NumOrdersAttempted Number of orders attempted to release.
NumOrdersCannotBeProcessed Number of orders did not attempt to release
Failures because of cannot be processed failures.
NumOrdersProcessed Number of orders processed.
NumOrdersReleased Number of orders released.
NumOrdersBackordered Number of orders backordered.
NumOrderLinesReleased Number of order lines released.
NumOrderLinesBackordered Number of order lines backordered.
NumReleasesCreated Number of order releases created.
NumOrdersCannotBeProcessed Number of orders that were not released due to
Failures process failure.

If the release process results in splitting of an order line, NumOrderLinesReleased,

NumOrderLinesBackordered, and NumOfReleasesCreated may result in more than
one count.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table, if tasks on hold are not
ready to be processed.

Events Raised

This transaction raises events as specified under the releaseOrder() API in the
Sterling Selling and Fulfillment Foundation: Javadocs.

328 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Route Shipment
This time-triggered transaction is used to route shipments and belongs to the
Outbound Shipment pipeline. It assigns the Carrier and Carrier Service codes for
the shipment based on the Routing Guide configured.

The Route Shipment transaction either includes shipments in an existing load or

creates a new load and includes the shipments in it.

Shipments can be consolidated to a load, only if the following conditions are met:
v Expected Ship Date - The expected ship date of the shipments must be less than
or equal to the must ship before date of the load.
v Expected Load Departure Date - The expected load departure date must be less
than or equal to the must ship before date of the shipments in the load.
The must ship before date is a date computed for the load, based on all
shipments present in the load. For example, if a load has three shipments with
their must ship before dates as 12.22.2005, 12.12.2005, and 12.19.2005 respectively,
then the must ship before date of the load is computed as 12.12.2005, as it is the
earliest of the three dates.

Attributes

The following are the attributes for this time-triggered transaction:

Table 233. Route Shipment
Attribute Value
Base Transaction ID ROUTE_SHIPMENT.0001
Base Document Type Order
Base Process Type ORDER_DELIVERY
Abstract Transaction No
APIs Called None
User Exits Called com.yantra.ydm.japi.ue.YDMOverrideDetermineRoutingUE
com.yantra.ydm.japi.ue.YDMBeforeDetermineRoutingUE

Criteria Parameters
The following are the criteria parameters for this transaction:
Table 234. Route Shipment Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where
YFS_SHIPMENT table may exist in multiple schemas. Runs
the agent for the colony.

Chapter 26. Time-Triggered Transaction Reference 329

 Table 234. Route Shipment Criteria Parameters (continued)
Parameter Description
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 235. Route Shipment Statistics
Statistic Name Description
NumRouted Number of shipments routed.

Pending Job Count

For this transaction the pending job count is the number of records representing
the unheld orders that are available to be processed by the transaction with the
AVAILABLE_DATE value less than or equal to (<=) the current date value in the
YFS_Task_Q table.

Events Raised

The following events are raised by this time-triggered transaction:

Table 236. Events Raised by the Route Shipment Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS shipment_dbd.txt YDM_ROUTE_SHIPMENT Yes
.ON_SUCCESS.xml
ON_FAILURE shipment_dbd.txt YDM_ROUTE_SHIPMENT Yes
.ON_FAILURE.xml

However, note that the template name would read

<TransactionId>.ON_SUCCESS.xml.

Schedule
This transaction schedules orders to specific ship nodes making sure that the
scheduled ship nodes have enough inventory to process the order.

Run this transaction after order creation.

Do not run the individual Schedule or Release agents when running the combined
"Schedule and Release" agent.

330 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 237. Schedule Attributes
Attribute Value
Base Transaction ID SCHEDULE
Base Document Type Order
Base Process Type Order Fulfillment
APIs Called scheduleOrder()

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 238. Schedule Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
MaximumRecords Determines the maximum number of possible solutions that
the Schedule Agent can find. This parameter may improve the
best solution found, but it also impacts the performance of this
agent.

If left blank or specified as 0 (zero), it defaults to 5.

OptimizationType Optional. Determines the optimization rules to apply to the
scheduling process. Valid values are:
v 01 - Optimize on date (Default)
v 02 - Optimize on ship node priority
v 03 - Optimize on number of shipments
OrderFilter Optional. Determines the types of orders to filter. Possible
values are:
v A - All orders (Default)
v B - Backorders only
v N - New orders only
ScheduleAndRelease Optional. Notify the schedule process to release all releasable
line quantities. Valid values are:
v Y - Releases successfully scheduled line quantities.
v N - Default value. Only schedules line quantities.

Enabling this parameter does not validate hold types

configured for the release transaction.
IgnoreReleaseDate Optional. Determines whether the schedule process should
ignore line release date criteria. Valid values are:
v Y - Releases line quantities regardless of release date criteria.
v N - Releases lines quantities only after release date criteria
have been met. Default.

Chapter 26. Time-Triggered Transaction Reference 331

 Table 238. Schedule Criteria Parameters (continued)
Parameter Description
Next Task Queue Interval Not used. This agent updates a failed task so that it is
suspended for the back order retry interval setup in the
appropriately scheduled rule.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 239. Schedule Statistics
Statistic Name Description
NumFutureDateFailures Number of orders that Sterling Selling and
Fulfillment Foundation did not attempt to schedule
because of future date failures.

Failures can be caused by any of the following:

v If the OrderFilter is “B” (Backorders Only) and
there are no backordered or unscheduled lines.
v If the OrderFilter is “N” (New orders Only) and
there are some backordered or unscheduled lines.
v If order has order lines within only backordered
or unscheduled status and the status modify
timestamp is after the current time - the back
order wait period specified in the scheduling
rule.
NumOrdersAttempted Number of orders attempted to schedule. This
statistic does not include the values for
NumFutureDateFailures and
NumOrdersCannotBeProcessedFailures statistics.
NumOrderLinesReleased Number of order lines that have been released.
NumOrdersCannotBeProcessed Number of orders that Sterling Selling and
Failures Fulfillment Foundation did not attempt to schedule
because of cannot be processed failures.

Failures can be caused by any of the following:

v The result of the
YFSCheckOrderBeforeProcessingUE user exit
returns as false.
v The Order has the HoldFlag attribute set to ‘Y'.
v The Order has the SaleVoided attribute set to ‘Y'.
v The Order does not have PaymentStatus as
AUTHORIZED, INVOICED, PAID, nor
NOT_APPLICABLE.
NumOrdersCreated Number of orders created. This also includes the
number of procurement orders created.
NumOrderLinesCreated Number of order lines created.
NumOrdersProcessed Number of orders processed.

332 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 239. Schedule Statistics (continued)
Statistic Name Description
NumOrdersScheduled Number of orders that have at least one line that
was scheduled.

This includes scheduled lines in any status except

BACKORDER.
NumOrdersProcOrdersCreated Number of procurement orders created.
NumWorkOrdersCreated Number of work orders created.
NumOrdersBackordered Number of orders backordered.
NumOrderLinesScheduled Number of order lines scheduled.
NumOrderLinesBackordered Number of order lines backordered.
NumReleasesCreated Number of order releases created.

Pending Job Count

For this transaction the pending job count is the number of records representing
the unheld orders that are available to be processed by the transaction with the
AVAILABLE_DATE value less than or equal to (<=) the current date value in the
YFS_Task_Q table, if tasks on hold are not ready to be processed.

Events Raised

This transaction raises events as specified under the scheduleOrder() API in the
Sterling Selling and Fulfillment Foundation: Javadocs.

Providing Oracle Hints

You can provide Oracle Hints to increase the performance of the scheduleOrder
agent. The two hints that can be provided for each criteria ID of the scheduleOrder
agent are the Outer Hint and the Inner Hint. The Outer Hint is always used for the
YFS_TASK_Q table. The Inner Hint is used for the YFS_ORDER_HEADER table
only if the earlier hold functionality is used; otherwise, the Inner Hint is used for
the YFS_ORDER_RELEASE_STATUS table.

Insert the following entries in the yfs.properties file in order to enable Oracle
Hints:
1. Edit the <INSTALL_DIR>/properties/yfs.properties file.
2. Insert yfs.<agent_criteria_id>.getjobs.hint.outer=/*+ parallel(YFS_TASK_Q
8) full(yfs_task_q) */
Insert yfs.<agent_criteria_id>.getjobs.hint.inner=/*+ NL_SJ */

Send Invoice
This transaction publishes invoice data that can be directed to an external accounts
receivable system.

In environments that require an interface with accounts receivable systems, this

transaction needs to be scheduled. This transaction raises an event for an invoice
based on the following configuration at the following times in the order lifecycle:

Chapter 26. Time-Triggered Transaction Reference 333

 v Publish invoice at shipment creation - This implies that your accounts payable
system takes care of payment collection. Invoices can be published as soon as
they are created.
v Publish invoice after payment collection - This implies that the Console take care
of the payment collection. When payment is in the AT_COLLECT status and the
payment is not from an external system, an invoice is published only if the
entire payment amount is collected. If the payment is in the AT_CREATE status
or the payment is from an external system, the invoice is published
unconditionally.

Many of this transaction's elements and attributes are template driven. Refer to the
XML for element level details.

Attributes

The following are the attributes for this time-triggered transaction:

Table 240. Send Invoice Attributes
Attribute Value
Base Transaction ID SEND_INVOICE
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called getOrderInvoiceDetails()

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 241. Send Invoice Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 242. Send Invoice Statistics
Statistic Name Description
NumInvoicesSent Number of invoices sent.

Pending Job Count

For this transaction the pending job count is the number of order invoices in
created (“00”) status.

334 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Events Raised

The following events are raised by this time-triggered transaction:

Table 243. Events Raised by the Send Invoice Transaction
Template
Transaction/Event Key Data Data Published Support?
PUBLISH_INVOICE_ modifyOrder_dbd. YFS_getOrderInvoice Yes
DETAIL txt and Details_output.xml
sendInvoice_dbd
.txt

Additional events may be raised by the getOrderInvoiceDetails() API. For

detailed information about the events, see the details provided under this API in
the Sterling Selling and Fulfillment Foundation: Javadocs.

Send Item Changes

In integrated environments, this transaction publishes item data changes that are
directed to an external system.

When item changes occur in Sterling Selling and Fulfillment Foundation, they need
to be communicated to the external system.

The business process may require the synchronization of items all at once in a
batch. For example, at the end of each business day, the sendItemChanges agent
can be configured to synchronize items based on the synchronization logic. This
transaction retrieves all items that are not logical kit or dynamic physical kit items
and whose SyncTS is null or MaxModifyTS is greater than the SyncTS.

The MaxModifyTS of an item is updated with the current timestamp whenever an

item is modified. The transaction then retrieves detailed information about those
items and raises the ON_SUCCESS event. This event should be configured to
invoke the Send Item Changes action.

For more information about how this integration is implemented, see the Sterling
Selling and Fulfillment Foundation: Integration Guide.

Attributes

The following are the attributes for this time-triggered transaction:

Table 244. Send Item Changes Attributes
Attribute Value
Base Transaction ID SEND_ITEM_CHANGES
Base Document Type None
Base Process Type General
Abstract Transaction No
APIs Called None

Chapter 26. Time-Triggered Transaction Reference 335

 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 245. Send Item Changes Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Organization Code Optional. The organization from which items are
synchronized. This field is blank by default.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

For this transaction the pending job count is the number of items requiring
synchronization. This is determined for product items that are not logical kit or
dynamic physical kit items and whose SyncTS is null or MaxModifyTS is greater
than the SyncTS.

Events Raised

The following events are raised by this time-triggered transaction:

Table 246. Events Raised by the Send Item Changes Transaction
Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS None YCM_SEND_ITEM_ Yes
CHANGES_ON_
SUCCESS.XML

Send Customer Changes

In integrated environments, this transaction publishes customer data changes that
are directed to an external system.

When customer changes occur in Sterling Selling and Fulfillment Foundation, they
need to be communicated to the external system.

The business process may require the synchronization of customers all at once in a
batch. For example, at the end of each business day, the sendItemChanges agent
can be configured to synchronize items based on the synchronization logic. This
transaction retrieves all customers that are consumers, have a user ID present, and
are required to synchronize. This transaction can also be used to complete the
initial synchronization of users between the two systems. For example, if an

336 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
external system is already in place, and Sterling Selling and Fulfillment Foundation
is then added, the SendCustomerChanges agent synchronizes the users from the
external system.

The sendCustomerChanges agent also serves as a backup mechanism. If a

customer synchronization event fails, the agent automatically retries the
synchronization after a specified amount of time.

The MaxModifyTS of an customer is updated with the current timestamp

whenever an customer is modified, whenever syncTS is less than MaxModifyTS, or
when syncTS is null. The transaction then retrieves detailed information about
those customers and raises the ON_SUCCESS event. This event should be
configured to invoke the Send Customer Changes action.

For more information about how this integration is implemented, see the Sterling
Selling and Fulfillment Foundation: Integration Guide.

Attributes
The following are the attributes for this time-triggered transaction:
Table 247. Send Customer Changes Attributes
Attribute Value
Base Transaction ID SEND_CUSTOMER_CHANGES
Base Document Type None
Base Process Type General
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 248. Send Customer Changes Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Organization Code Optional. The organization from which customers are
synchronized. This field is blank by default.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

For this transaction the pending job count is the number of customers requiring
synchronization. This is determined for customers that are consumers, have a user

Chapter 26. Time-Triggered Transaction Reference 337

 ID present, and are required to synchronize.

Events Raised

The following events are raised by this time-triggered transaction:

Table 249. Events Raised by the Send Customer Changes Transaction
Template
Transaction/Event Key Data Data Published Support?
SEND_CUSTOMER_ None YSC_SEND_CUSTOMER Yes
CHANGES.ON_SUCCESS _CHANGES.ON_
SUCCESS.XML

Send Order
This transaction tries to raise the ON_SUCCESS event for an order whose
OrderHeaderKey is stored in the task queue object. The event is raised only if all
of the order lines of the order reach particular status(es) completely. That is, the
entire ORDERED_QTY of each line must be in the particular status(es). In addition
to raising the event, the line statuses are also changed to the drop statuses,
corresponding to the pickup statuses. The SendOrder transaction, derived from the
abstract transaction SEND_ORDER, should have the event, pickup, and drop
statuses configured. For more information, see the details provided under the
sendOrder() API in the Sterling Selling and Fulfillment Foundation: Javadocs.

If an order needs to be communicated to a third party, use this transaction.

The TransactionKey posted in the task object must be an instance of the Abstract
Transaction SEND_ORDER for the ProcessType associated with the Order.
Otherwise, an exception is thrown.

Attributes

The following are the attributes for this time-triggered transaction:

Table 250. Send Order Attributes
Attribute Value
Base Transaction ID SEND_ORDER
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction Yes
APIs Called sendOrder()

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 251. Send Order Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

338 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 251. Send Order Criteria Parameters (continued)
Parameter Description
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the sendOrder() API in the
Sterling Selling and Fulfillment Foundation: Javadocs.

Send Release
The Send Release Agent dispatches releases to ship nodes.

Attributes

The following are the attributes for this time-triggered transaction:

Table 252. Send Release Attributes
Attribute Value
Transaction Name Send Release
Transaction ID SHIP_ADVICE
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called com.yantra.yfs.agent.YFSWMSShipAdviceAgent

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 253. Send Release Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

Chapter 26. Time-Triggered Transaction Reference 339

 Table 253. Send Release Criteria Parameters (continued)
Parameter Description
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 254. Send Release Statistics
Statistic Name Description
NumReleasesProcessed Number of order releases processed.
NumReleasesSent Number of order releases sent.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

The following events are raised by this time-triggered transaction:

Table 255. Events Raised by the Send Release Transaction
Transaction/Event Data Published
PUBLISH_SHIP_ADVICE YFS_publishShipAdvice_output.xml

Start Order Negotiation

This transaction creates the negotiations for orders that are configured to go
through the negotiation process.

Use this transaction in environments where an Order needs to go through a

Negotiation phase before it is released.

Attributes

The following are the attributes for this time-triggered transaction:

Table 256. Start Order Negotiation Attributes
Attribute Value
Base Transaction ID START_ORD_NEGOTIATION
Base Document Type Order
Base Process Type Order Fulfillment

340 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 256. Start Order Negotiation Attributes (continued)
Attribute Value
Abstract Transaction No
APIs Called createNegotiation()
User Exits Called YCPBeforeCreateNegotiationUE, YCPGetNegotiationNoUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 257. Start Order Negotiation Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
Node Required. The ship node for which records are being
processed.
ColonyID Required in a multischema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 258. Start Order Negotiation Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumNegotiationsCreated Number of negotiations created.

Pending Job Count

For this transaction the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

This transaction raises events as specified under the createNegotiation() API in

the Sterling Selling and Fulfillment Foundation: Javadocs.

Synchronize Colony Map

The Colony Map Synchronizer agent inserts or updates colony mappings of
organizations and users in the PLT_COLONY_MAP table. When you run the agent

Chapter 26. Time-Triggered Transaction Reference 341

 for the first time, it populates this table, which is a necessary step in upgrading to
multischema mode after installing or upgrading Sterling Selling and Fulfillment
Foundation.

For more information about upgrading to multischema mode, see the Sterling
Selling and Fulfillment Foundation: Multi-Tenant Enterprise Guide.

Attributes

The following are attributes for this time-triggered transaction:

Table 259. Colony Map Synchronizer Attributes
Attribute Value
Base Transaction ID COLONY_MAP_SYNC
Base Process Type General
Abstract Transaction No

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 260. Colony Map Synchronizer Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records to Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID The colony to be synchronized.

Initially, you must run the agent on the DEFAULT colony

provided by the Sterling Selling and Fulfillment Foundation
installation so that it populates the PLT_COLONY_MAP table.
After this, you can run the agent on another ColonyID.
InsertDefaultMappings If set to Y, users for which the colony cannot be determined
will be mapped to the colony for which the Colony Map
Synchronizer agent is run.

Statistics Tracked

None.

Pending Job Count

None.

Events Raised

None.

Tables Purged

None.

342 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Update Best Match Region
The Update Best Match Region transaction manages the
YFS_REGION_BEST_MATCH table, which is used by Data Warehouse Analytics to
report best match region data. The best match region is defined by the following
five address attributes in person info records:
v ADDRESS_LINE6
v CITY
v STATE
v SHORT_ZIP_CODE
v COUNTRY

Note: COUNTRY refers to Country/Region.

The agent for the Update Best Match Region transaction runs in two modes that
allow you to set up and update the YFS_REGION_BEST_MATCH table.

Attributes

The following are the attributes for this time-triggered transaction:

Table 261. Update Best Match Region Attributes
Attribute Value
Base Transaction ID UPDATE_BEST_MATCH_REGION
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YSCGetShortZipCode UE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 262. Update Best Match Region Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If UpdateOnly = N, only distinct records are returned
per agent call. If left blank, it defaults to 1000.

Chapter 26. Time-Triggered Transaction Reference 343

 Table 262. Update Best Match Region Criteria Parameters (continued)
Parameter Description
TableType Required in a multischema deployment when YFS_Person_Info
table may exist in multiple schemas.

Valid Values: CONFIGURATION, TRANSACTION, MASTER.

If set to CONFIGURATION, the agent runs for the

YFS_Person_Info records associated with tables that have
TableType as CONFIGURATION; for example,
YFS_Organization, YFS_Ship_Node, and so forth.

If set to TRANSACTION, the agent runs for the

YFS_Person_Info records associated with tables that have
TableType as TRANSACTION; for example,
YFS_Order_Header, YFS_Shipment, and so forth.

Note that the agent would run for all TableTypes that exist in
the same schema as the one passed. For example, if set to
TRANSACTION, the agent would also run for
YFS_Person_Info records associated with tables that have
TableType as MASTER, since they reside in the same schema.
ColonyID Required in a multi schema deployment where the
YFS_PERSON_INFO table may exist in multiple schemas.
Runs the agent for the colony.
UpdateOnly Mode in which to run. Valid values are:
v N - Default value. Adds records from the
YFS_PERSON_INFO table to the
YFS_REGION_BEST_MATCH table and populates the
region key in the YFS_BEST_MATCH table. To perform the
initial setup of Best Match Region for Analytics, set
UpdateOnly to N.
v Y - Update mode. Updates region keys based on addresses
in YFS_REGION_BEST_MATCH. After performing the initial
setup of Best Match Region for Analytics, set this value to Y
to specify update mode.
LastPersonInfoKey Optional. If UpdateOnly is set to N, LastPersonInfoKey
determines the first person info record to populate. If no key is
specified, the value defaults to Null.
LastRegionBest Optional. If UpdateOnly is set to Y, LastRegionBestMatchKey
MatchKey determines the first region best match key to update. If no key
is specified, the value defaults to Null.

Statistics Tracked

None.

Pending Job Count

None.

Events Raised

None.

344 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Tables Purged

None.

PopulateOwnershipTransferSummary
This method updates the YFS_OWNERSHIP_TRANSFER_SUMMARY table.

This transaction updates the YFS_OWNERSHIP_TRANSFER_SUMMARY table by

checking the records in YFS_INV_OWN_TRANSFER_RCD table.

It also updates the IS_STATISTICS_UPDATED to 'Y' in

YFS_INV_OWN_TRANSFER_RCD table after the record has been used by the
transaction.

Attributes
Following are the attributes for this time-triggered transaction:
Table 263. YFSPopulateOwnershipTransfer Attributes
Attribute Value
Base Transaction ID POPULATE_OWN_TRANS_SUMM
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Criteria Parameters

Following are the criteria parameters for this transaction:

Table 264. YFSPopulateOwnershipTransfer Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, which is the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multi schema deployment where the
YFS_OWNERSHIP_TRANSFER_SUMMARY and
YFS_INV_OWN_TRANSFER_RCD tables may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

None

Pending Job Count

None

Events Raised

Chapter 26. Time-Triggered Transaction Reference 345

 None

YSCRecycleEntityAttributeAgent
The YSCRecycleEntityAttributeAgent fetches all the "INACTIVE" attributes for a
given entity and document type, of an enterprise, and marks them as "DELETED".
The values in the corresponding columns mapped to "INACTIVE" attributes in the
hang off tables as well as the history table of the hang off tables are also cleaned
up. The agent queries the EntityDomain table for all the supported entities and
document types, and retrieves the INACTIVE custom attributes for these domains.
A message is created for each domain and for each message, the agent updates the
entity for columns listed in the message. The agent uses the criteria information,
NumberOfRecordsToBuffer, to determine the number of records to be updated per
the message in the hang-off tables. The corresponding YFS_Attribute records are
also deleted from the database for all the DELETED custom attributes.

Attributes
Table 265. YSCRecycleEntityAttributeAgent Attributes
Attribute Value
Base Transaction ID RECYCLE_ENTITY_ATTRIBUTE
Base Process Type General

Criteria Parameters
Table 266. YSCRecycleEntityAttributeAgent Criteria Parameters
Parameter Name Description
Action Required. This parameter triggers the
transaction. The default value is set to "Get".
Number of Records To Buffer The number of records to retrieve and
process by the agent is set in this attribute.
Default value is "0".
Enterprise Code The enterprise for which the recycle agent is
run.
CollectPendingJobs By default, this is set to "N". It cannot be
modified.

Events Raised

None.

Statistics Tracked

None.

Pending Job Count

None

Time-Triggered Purge Transactions

There are several transactions that you can use to purge your database tables at
specific time intervals.

346 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Purge transactions determine when a table should be purged by determining the
current date and subtracting the retention days specified by the purge. If the
timestamp on the table is less than or equal to (current day - retention days) the
table is purged.

In some cases, a purge may look at another field other than the table's timestamp.
These are pointed out in the documentation.

When an entity is being purged, the related or dependent information that is

present in other tables should be taken into consideration for purging along with
it. For example, if a sales order with live shipments is being purged, any cross
reference to that order is not accurate in the Order Shipment Console. As another
example, agents such as Purge Order and Purge Order History also purge the
records from extension tables, such as yfs_order_header_extension and
yfs_order_line_extension, as well as their associated histories.

Some of the statistics collected and tracked in Release 9.1 for time-triggered
transactions, monitors, and integration and application servers may change with
the next release of Sterling Selling and Fulfillment Foundation.

All Time-Triggered Purge Transactions have a CollectPendingJobs criteria

parameter. If this parameter is set to N, the agent does not collect information on
the pending jobs for that time-triggered transaction. This pending job information
is used for monitoring the monitor in the System Management Console.

By default, CollectPendingJobs is set to Y. It can be helpful to set it to N if one

particular time-triggered transaction is performing a significant amount of
getPendingJobs queries, and the overhead cost is too high.

Purge Strategy
The following recommendations should be taken into consideration when planning
a purge strategy for each purge transaction:
v Test purges by setting Live to ’N’.
v Turn on logging to test what is purged.
v Set up purge traces in the System Management Console and analyze the
information.

Configuring Purge Transaction Log Files

About this task

You can configure purges to write log files to a directory you specify. Each time
you run a particular purge, new data is appended to this file. If no file exists, one
is created.

To specify a purge log file directory:

Procedure
1. Configure the yfs.purge.path property in the <INSTALL_DIR>/properties/
customer_overrides.properties file. For example, on UNIX you might specify
the log files to be written to the /app/yfs/logs/purges directory.
For additional information about overriding properties using the
customer_overrides.properties file, see the Sterling Selling and Fulfillment
Foundation: Properties Guide.

Chapter 26. Time-Triggered Transaction Reference 347

 2. Run the <INSTALL_DIR>/bin/setupfiles.sh script on UNIX, or the
<INSTALL_DIR>/bin/setupfiles.cmd script on Windows.

Available Purges
This section contains details of all purge transactions in alphabetical order.

Access Token Purge

This purge removes access tokens from the system. If all of the following
conditions are met, the PLT_ACCESS_TOKEN table is picked up for purge:
v The access token is expired or is in inactive state.
v The last modified date is earlier than or equal to the current date minus the
purge criteria's retention days.

Attributes

The following are the attributes for this time-triggered transaction:

Table 267. Access Token Purge Attributes
Attribute Value
Base Transaction ID ACCESSTOKPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 268. Access Token Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the .
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.

348 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:

Table 269. Access Token Purge Statistics
Statistic Name Description
NumAccessTokenPurged Number of access token records purged.

Pending Job Count

For this transaction the pending job count is the number of records that can be
purged from the PLT_ACCESS_TOKEN table.

Events Raised

None.

Tables Purged

PLT_ACCESS_TOKEN

Capacity Purge
This purge removes capacity data from the system. This reduces the load on
frequently accessed tables.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a capacity data gets picked up for purge:
v All resource pool standard capacity periods with effective to date earlier than or
equal to the current date minus the purge criteria's retention days.
v All resource pool overridden capacity with the capacity date earlier than or
equal to the current date minus the purge criteria's retention days.
v All resource pool capacity consumption with consumption date less than or
equal to the current date minus the purge criteria's retention days.
v All resource pool capacity consumption details where appointment date is
earlier than the system date minus the purge criteria's retention days (or
ManualReservationPurgeLeadDays for manually created reservations).
v All resource pool capacity consumption details where expiration date has passed
and reservation Id is not blank.

Attributes

The following are the attributes for this time-triggered transaction:

Table 270. Capacity Purge Attributes
Attribute Value
Base Transaction ID CAPACITYPRG
Base Document Type General
Base Process Type General
Abstract Transaction No

Chapter 26. Time-Triggered Transaction Reference 349

 Table 270. Capacity Purge Attributes (continued)
Attribute Value
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 271. Capacity Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 272. Capacity Purge Statistics
Statistic Name Description
NumStdCapacityPeriodsPurged Number of standard capacity periods purged.
NumCapacityOverridesPurged Number of capacity overrides purged.
NumCapacityConsumptionsPurged Number of capacity consumptions purged.

Pending Job Count

For this transaction the pending job count is the total number of records that can
be purged from the YFS_RES_POOL_STD_CAPCTY_PERD,
YFS_RES_POOL_CAPCTY_OVERRIDE, YFS_RES_POOL_CONSMPTN_DTLS and
YFS_RES_POOL_CAPCTY_CONSMPTN tables.

Events Raised

None.

350 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Tables Purged

The YFS_RES_POOL_STD_CAPCTY_PERD table is purged when

EFFECTIVE_TO_DATE <= (CurrentDate - LeadDays)

The YFS_RES_POOL_CAPCTY_OVERRIDE table is purged when

CAPACITY_DATE <= (CurrentDate - LeadDays)

The YFS_RES_POOL_CAPCTY_CONSMPTN table is purged when

CONSUMPTION_DATE <= (CurrentDate - LeadDays), or if a manual reservation
is taken, when CONSUMPTION_DATE <= (CurrentDate - Manual Reservation
Retention Days). When this table is purged, YFS_RES_POOL_CONSMPTN_DTLS is
also purged.

The YFS_RES_POOL_CONSMPTN_DTLS table is purged when

RESERVATION_EXPIRATION_DATE <= (CurrentDate - LeadDays)

Draft Order History Purge

This purge deletes data from history tables after a specified interval, which in turn,
reduces the load on frequently accessed tables.

You can use purge codes' pseudo-logic to analyze the purges. If the following
condition is met, a draft order is picked up for history purge:
v The last modified date of the draft order exceeds the retention day period.

All the enterprise using the Console must schedule purge transactions.

For more information about Additional Purge Criteria Based on Line Type, see the
Sterling Selling and Fulfillment Foundation: Distributed Order Management
Configuration Guide.

Note: The draft order must be purged and moved to the history tables before you
purge the draft order history tables. See “Draft Order Purge” on page 354.

Sterling Selling and Fulfillment Foundation does not provide a transaction for draft
order history purges. If you are defining a transaction that purges draft order
history tables, refer to the following Criteria Parameters section for information
about the transaction criteria.

If you do not want to define your own transaction to purge draft order history
tables, you can use the Order Purge transaction and specify
DRAFTORDERHISTPRG for the PurgeCode. To configure the Order Purge
transaction for draft order history table purges, refer to “Order Purge” on page 382
for more information.

Criteria Parameters

The following are the criteria parameters for defining a draft order history
transaction:
Table 273. Draft Order History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

Chapter 26. Time-Triggered Transaction Reference 351

 Table 273. Draft Order History Purge Criteria Parameters (continued)
Parameter Description
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Required. Enterprise for which the Draft Order History Purge
has to be run. If not passed, all the enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Removes qualifying records from the
history tables that are listed in Tables Purged.
v N - Test mode. Determines the rows that are removed
without actually removing them.
PurgeCode Required. Set to DRAFTORDERHISTPRG. Used for internal
calculations, such as determining retention days. Corresponds
to the PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Events Raised

None.

Tables Purged

YFS_ANSWER_SET_TRAN_H

YFS_ANSWER_TRAN_H

YFS_CHARGE_TRAN_DIST_H

YFS_CHARGE_TRANSACTION_H

YFS_CREDIT_CARD_TRANSACTION_H

YFS_ENTITY_ADDRESS_H

YFS_HEADER_CHARGES_H

YFS_INSTRUCTION_DETAIL_H

YFS_INVOICE_COLLECTION_H

YFS_LINE_CHARGES_H

YFS_NOTES_H

YFS_ORDER_AUDIT_DETAIL_H

YFS_ORDER_AUDIT_H

352 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
YFS_ORDER_AUDIT_LEVEL_H

YFS_ORDER_DATE_H

YFS_ORDER_HEADER_H

YFS_ORDER_HEADER_H_EXTENSION

YFS_ORDER_HOLD_TYPE_H

YFS_ORDER_HOLD_TYPE_LOG_H

YFS_ORDER_INVOICE_DETAIL_H

YFS_ORDER_INVOICE_H

YFS_ORDER_KIT_LINE_H

YFS_ORDER_KIT_LINE_SCHEDULE_H

YFS_ORDER_LINE_H

YFS_ORDER_LINE_H_EXTENSION

YFS_ORDER_LINE_OPTION_H

YFS_ORDER_LINE_REQ_TAG_H

YFS_ORDER_LINE_SCHEDULE_H

YFS_ORDER_PROD_SER_ASSOC_H

YFS_ORDER_RELEASE_H

YFS_ORDER_RELEASE_STATUS_H

YFS_ORDER_SER_PROD_ITEM_H

YFS_PAYMENT_H

YFS_PROMOTION_AWARD_H

YFS_PROMOTION_H

YFS_RECEIVING_DISCREPANCY_DTL_H

YFS_RECEIVING_DISCREPANCY_H

YFS_REFERENCE_TABLE_H

YFS_TAX_BREAKUP_H

Chapter 26. Time-Triggered Transaction Reference 353

 Draft Order Purge
This purge archives data into history tables after a specified interval, which in
turn, reduces the load on frequently accessed tables. For information about purging
draft orders from history tables, see “Draft Order History Purge” on page 351.

Sterling Selling and Fulfillment Foundation does not provide a transaction for draft
order purges. If you are defining a transaction that purges draft orders, refer to the
following Criteria Parameters section for details about the transaction criteria.

If you do not want to define your own transaction to purge draft orders, you can
use the Order Purge transaction and specify DRAFTORDERPRG for the
PurgeCode. To configure the Order Purge transaction for draft order purges, refer
to “Order Purge” on page 382 for more information.

All the enterprise using the Console must schedule purge transactions.

Draft orders are picked up by the agent for validation when the following
conditions are met:
v Draft order flag is set to Y.
v Modifyts is set for the retention date.

After the draft orders are picked up, each draft order is validated for purging
based on the following conditions:
v No eligible order release status records (records with a status larger than zero)
exist for the order.
v All the open child orders (derived, chained, return, exchange, or refund
fulfillment) for the order are already purged.

If a draft order meets the set of conditions for validation listed earlier, the agent
continues to verify the draft orders against the following criteria:
v Contains the Draft Created (1000) status, and all the extended Draft Created
statuses.
v Does not have an order release status record that does not meet the retention
days.
v The order's last modification should be before the lead time (in days) setup.
v In the case when an exchange order is part of a return order, the exchange order
should be purged from history tables before the return order is purged.
v In the case of an order line reservation, the draft order cannot be purged.
v If the Draft Order Payment Processing flag is set to N, the draft orders are
purged.
v If the Draft Order Payment Processing flag is set to Y and a charge exists on a
draft order, the draft order is not purged. However, authorizations are not
considered when validating draft orders for purge.
v For order lines, except service order lines:
– If the Seller inventory update is required, the Status Inventory Type has the
Update Seller Supply option turned on, and the Seller Supply Type is
Onhand, or blank. (The Seller Supply Type can also be a custom seller supply
type, with the Onhand Supply check box enabled.)
– If the Seller Demand Type is blank.
– If the Buyer inventory update is required, and the Buyer Supply Type is
Onhand, or blank.

354 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for defining a draft order purge
transaction:
Table 274. Draft Order Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies (in hours) how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
EnterpriseCode Required. Enterprise for which the Draft Order Purge has to
be run. If not passed, all the enterprises are monitored.

When the EnterpriseCode is blank, the purge criteria

configured for the DEFAULT enterprise is used, and not the
purge criteria configured for the draft order's enterprise.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged, to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Set to DRAFTORDERPRG. Used for internal
calculations, such as determining retention days. Corresponds
to the PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Events Raised

None.

Tables Purged

YFS_ACTIVITY_DEMAND

YFS_ANSWER_SET_TRAN

YFS_ANSWER_TRAN

YFS_CHARGE_TRANSACTION

YFS_CHARGE_TRAN_DIST

YFS_CREDIT_CARD_TRANSACTION

Chapter 26. Time-Triggered Transaction Reference 355

 YFS_ENTITY_ADDRESS

YFS_HEADER_CHARGES

YFS_INSTRUCTION_DETAIL

YFS_INVOICE_COLLECTION

YFS_LINE_CHARGES

YFS_MONITOR_ALERT

YFS_NOTES

YFS_ORDER_AUDIT

YFS_ORDER_AUDIT_DETAIL

YFS_ORDER_AUDIT_LEVEL

YFS_ORDER_HEADER

YFS_ORDER_HEADER_EXTENSION

YFS_ORDER_HOLD_TYPE

YFS_ORDER_HOLD_TYPE_LOG

YFS_ORDER_INVOICE

YFS_ORDER_INVOICE_DETAIL

YFS_ORDER_KIT_LINE

YFS_ORDER_KIT_LINE_SCHEDULE

YFS_ORDER_LINE

YFS_ORDER_LINE_EXTENSION

YFS_ORDER_LINE_OPTION

YFS_ORDER_LINE_REQ_TAG

YFS_ORDER_LINE_RESERVATION

YFS_ORDER_LINE_SCHEDULE

YFS_ORDER_LINE_SRC_CNTRL

YFS_ORDER_PROD_SER_ASSOC

YFS_ORDER_RELEASE

YFS_ORDER_RELEASE_STATUS

356 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
YFS_ORDER_SER_PROD_ITEM

YFS_ORDER_DATE

YFS_PAYMENT

YFS_PMNT_TRANS_ERROR

YFS_PROMOTION

YFS_PROMOTION_AWARD

YFS_RECEIVING_DISCREPANCY

YFS_RECEIVING_DISCREPANCY_DTL

YFS_REFERENCE_TABLE

YFS_TAX_BREAKUP

Delivery Plan Purge

This purge deletes delivery plans after they have completed their typical life cycle.
All the loads and shipments that are associated with the delivery plans should
have been purged before running this purge agent.

It purges all the delivery plans that have been marked as ‘Closed' for a period
greater than the retention days specified in the criteria parameters and those that
do not have any shipments or loads. The order should have been moved to history
before the lead time (in days) setup.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a delivery plan is picked up for purge:
v The delivery plan should be in the "Closed" status.
v The delivery plan should not be associated with any load or shipment.
v All orders associated with the delivery plan should be purged.
v The last modification performed on the delivery plan should fall before the lead
time (in days) setup.

Attributes

The following are the attributes for this time-triggered transaction:

Table 275. Delivery Plan Purge Attributes
Attribute Value
Base Transaction ID DELIVERYPLANPRG
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Chapter 26. Time-Triggered Transaction Reference 357

 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 276. Delivery Plan Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Delivery Plan Purge needs
to be run. If not passed, then all enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
BatchDelete Required. The method by which all records are deleted from
the table. Valid values are:
v Y - Default value. Records are deleted in batches.
v N - Records are deleted one by one.
ColonyID Required in a multi schema deployment where the
YFS_DELIVERY_PLAN table may exist in multiple schemas.
Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 277. Delivery Plan Purge Statistics
Statistic Name Description
NumDeliveryPlansPurged Number of delivery plans purged.

Pending Job Count

For this transaction the pending job count is the number of records that can be
purged from the YFS_DELIVERY_PLAN table.

7 Events Raised

None.

Tables Purged

YFS_DELIVERY_PLAN

358 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Export Table Purge
This purge removes export table data from the system. This reduces the load on
frequently accessed tables.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, the YFS_EXPORT table is picked up for purge:
v YFS_EXPORT records should be marked as processed (Status = 10).
v The last modified time should fall before the lead time (in days) setup.
This purge reads only the rules defined by the hub. Enterprise overridden rules
are not considered. This purge should be single threaded when you run it in
batch delete mode(BatchDelete=Y).

Any enterprise using the Application Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:

Table 278. Export Table Purge Attributes
Attribute Value
Base Transaction ID EXPORTTBLPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 279. Export Table Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
BatchDelete Required. The method by which all records are deleted from
the table. Valid values are:
v Y - Records are deleted in batches.
v N - Default value. Records are deleted one by one.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.

Chapter 26. Time-Triggered Transaction Reference 359

 Table 279. Export Table Purge Criteria Parameters (continued)
Parameter Description
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This
pending job information is used for monitoring the monitor
in the System Management Console.
ColonyID Required in a multi schema deployment where the
YFS_EXPORT table may exist in multiple schemas. Runs the
agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 280. Export Table Purge Statistics
Statistic Name Description
NumExportsPurged Number of exports purged.

Pending Job Count

For this transaction the pending job count is the number of records that can be
purged from the YFS_Export table.

Events Raised

None.

Tables Purged

YFS_EXPORT

Import Table Purge

This purge removes import table data from the system. This reduces the load on
frequently accessed tables.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, the YFS_IMPORT table is picked up for purge:
v YFS_IMPORT records should be marked as processed (Status = "10").
v The "last modified time" should fall before the lead time (in days) setup.
This purge reads only the rules defined by the hub. Enterprise overridden rules
are not considered. This purge should be single threaded when you run it in
batch delete mode(BatchDelete=Y).

Any enterprise using the Console must schedule purge transactions.

360 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 281. Import Table Purge Attributes
Attribute Value
Base Transaction ID IMPORTTBLPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 282. Import Table Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
BatchDelete Required. The method by which all records are deleted from
the table. Valid values are:
v Y - Records are deleted in batches.
v N - Default value. Records are deleted one by one.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This
pending job information is used for monitoring the monitor
in the System Management Console.
ColonyID Required in a multi schema deployment where the
YFS_IMPORT table may exist in multiple schemas. Runs the
agent for the colony.

Chapter 26. Time-Triggered Transaction Reference 361

 Statistics Tracked

The following statistics are tracked for this transaction:

Table 283. Import Table Purge Statistics
Statistic Name Description
NumImportsPurged Number of import tables purged.

Pending Job Count

For this transaction the pending job count is the number of records that can be
purged from the YFS_Import table.

Events Raised

None.

Tables Purged

YFS_IMPORT

Inventory Audit Purge

This purge removes inventory audit data from the system. This reduces the load
on frequently accessed tables.

Any enterprise using the Console must schedule purge transactions.

All inventory audits of the provided organization with modify timestamp earlier
than the current date minus the purge criteria's retention days can be configured to
be picked up by the Inventory Audit Purge.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, an inventory audit record is picked up for purge:
v The inventory audit record's last modification is earlier than the current
timestamp minus the retention days.
Number of threads for this purge's agent criteria details must be set to 1. For
more information about agent criteria, see the Sterling Selling and Fulfillment
Foundation: Configuration Guide.

The following are the attributes for this time-triggered transaction:

Table 284. Inventory Audit Purge Attributes
Attribute Value
Base Transaction ID INVENTORYAUDITPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

362 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:

Table 285. Inventory Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. The inventory organization for which the Inventory
Audit Purge needs to be run. If not passed, then all enterprises
are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Table Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 286. Inventory Audit Statistics
Statistic Name Description
NumInventoryAuditsPurged Number of inventory audits purged.

Pending Job Count

For this transaction the pending job count is the number of records that can be
purged from the YFS_Inventory_Audit table.

Events Raised

None.

Table Purged

YFS_INVENTORY_AUDIT

Inventory Purge
This purge removes inventory data from the system. This reduces the load on
frequently accessed tables. This purge does not take retention days into account
when purging.

You can use purge codes pseudo-logic to analyze purges.

Chapter 26. Time-Triggered Transaction Reference 363

 For YFS_INVENTORY_SUPPLY, if the following conditions are met, an inventory
supply is picked up for purge:
v Supply record has the same availability type as the node. For example, TRACK
or INFINITE.
v Supply record has 0 quantity.
v Supply record does not contain the supply type “INFO”.

For YFS_INVENTORY_DEMAND, if the following conditions are met, an

inventory demand is picked up for purge:
v Demand record has 0 quantity or lesser.
v Demand record does not have demand details as well as matching demand
record in YFS_INVENTORY_DEMAND_ADDNL tables.

For YFS_INVENTORY_TAG, it is purged if the INVENTORY_TAG_KEY is not

used by any of the existing supply and demand.

For YFS_INVENTORY_RESERVATION, an inventory reservation is picked up for

purge if it meets the following conditions:
v Inventory reservation record has 0 quantity or ship date is earlier than the
system date minus the purge criteria's retention days.

For YFS_INVENTORY_NODE_CONTROL, it is purged if the

INV_PIC_INCORRECT_TILL_DATE is earlier than the current time stamp minus
the purge criteria's retention days.

For YFS_IBA_TRIGGER, it is purged if IBA_REQUIRED = 'N',

IBA_RUN_REQUIRED = 'N', and LAST_IBA_PROCESSED_TS is earlier than the
current time stamp minus the purge criteria's retention days.

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:

Table 287. Inventory Purge Attributes
Attribute Value
Base Transaction ID INVENTORYPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

364 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:

Table 288. Inventory Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode The inventory organization for which the Inventory Purge
needs to be run.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 289. Inventory Purge Statistics
Statistic Name Description
NumInventoryDemandsPurged Number of inventory demands purged.
NumInventoryNodeControlsPurged Number of inventory node controls purged.
NumInventoryReservationsPurged Number of inventory reservations purged.
NumInventoryTagsPurged Number of inventory tags purged.
NumItemBasedAllocationTriggers Number of item based allocation triggers purged.
Purged

Pending Job Count

For this transaction, the pending job count is the total number of records that can
be purged from the YFS_Inventory_Supply, YFS_Inventory_Demand,
YFS_Inventory_Tag, YFS_Inventory_Reservation, YFS_IBA_Trigger, and
YFS_Inventory_Node_Control tables.

Events Raised

None.

Chapter 26. Time-Triggered Transaction Reference 365

 Tables Purged

YFS_IBA_TRIGGER

YFS_INVENTORY_DEMAND

YFS_INVENTORY_TAG

YFS_INVENTORY_RESERVATION

YFS_INVENTORY_SUPPLY

YFS_INVENTORY_NODE_CONTROL

Inventory Supply Temp Purge

The Inventory Supply Temp purge agent cleans up the contents in the temporary
inventory tables generated by the process of synchronizing the Sterling Selling and
Fulfillment Foundation inventory picture with the actual inventory picture at the
nodes.

The node inventory picture is stored during the loading process into the
YFS_INVENTORY_SUPPLY_TEMP table. Once the synchronization phase is
complete and the YFS_INVENTORY_SUPPLY table has been updated, the
YFS_INVENTORY_SUPPLY_TEMP table needs to be purged, which is done
through this agent.

For more information about configuring the synchronization with node inventory,
see the Sterling Selling and Fulfillment Foundation: Global Inventory Visibility
Configuration Guide.

The Inventory Supply Temp purge agent is used to purge all records in the
YFS_INVENTORY_SUPPLY_TEMP table whose modify timestamp is less then
current time minus the purge criteria's retention days for a group of
YantraMessageGroupID.

Attributes

The following are the attributes for this time-triggered transaction:

Table 290. Inventory Supply Temp Purge Attributes
Attribute Value
Base Transaction ID SUPPLYTEMPPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

366 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:

Table 291. Inventory Supply Temp Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
EnterpriseCode Optional. The inventory organization for which the Inventory
Supply Temp Purge needs to be run. If not passed, then all
enterprises are monitored.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_INVENTORY_SUPPLY_TEMP table may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 292. Inventory Supply Temp Purge Statistics
Statistic Name Description
NumInventorySupplyTempsPurged Number of entries in the
YFS_INVENTORY_SUPPLY_TEMP table purged.

Pending Job Count

Number of unique YantraMessageGroupIDs from

YFS_INVENTORY_SUPPLY_TEMP table whose maximum modify timestamp is
less than current timestamp minus purge criteria's lead day.

Events Raised

None.

Tables Purged

YFS_INVENTORY_SUPPLY_TEMP

Chapter 26. Time-Triggered Transaction Reference 367

 Item Audit Purge
This purge removes the YFS_AUDIT table data from the system, which reduces the
load on frequently accessed tables. It purges records in the YFS_AUDIT and the
YFS_AUDIT_HEADER tables that meet the following conditions:
v YFS_AUDIT records that have ‘modifyts' greater than the retention days
specified and the records have the table name as 'YFS_ITEM'.
v The last modified time is before the lead time (in days) setup.

When the enterprise modifies records in the YFS_ITEM table through the
Applications Manager, the YFS_ITEM is audited and the audit records are inserted
in the YFS_AUDIT table. In order to clean up the audit records, this purge
transaction can be used.

Any enterprise using the Console must schedule purge transactions accordingly.

Attributes

The following are the attributes for this time-triggered transaction:

Table 293. Item Audit Purge Attributes
Attribute Value
Base Transaction ID YFS_ITEM_AUDIT_PURGE
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 294. Item Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, the value
defaults to Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), this value defaults
to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Production mode. Deletes records from
the regular tables.
v N - Test mode.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_AUDIT and YFS_AUDIT_HEADER tables may exist in
multiple schemas. Runs the agent for the colony.

368 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:

Table 295. Item Audit Purge Statistics
Statistic Name Description
NumItemAuditRecords Number of item audit records purged.
Purged

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_AUDIT table that match the criteria values.

Events Raised

None.

Tables Purged

YFS_AUDIT, YFS_AUDIT_HEADER

Load History Purge

This purge deletes the load data from history tables after it completes its typical
lifecycle. This reduces the load on frequently accessed tables.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the last modification
made to the load is before the lead time (in days) is met, a load is picked up for
purge.

Before you run this transaction, ensure to purge loads and move them to history
tables. For more information about purging loads, see “Load Purge” on page 371.

Attributes

The following are the attributes for this time-triggered transaction:

Table 296. Load History Purge Attributes
Attribute Value
Base Transaction ID LOADHISTPRG
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Chapter 26. Time-Triggered Transaction Reference 369

 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 297. Load History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Load Purge needs to be
run. If not passed, all enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
Purge Code Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 298. Load History Purge Statistics
Statistic Name Description
NumLoadHistoriesPurged Number of load histories purged.
NumLoadShipment Number of load shipment histories purged.
HistoriesPurged

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Load_H table.

Events Raised

None.

Tables Purged

YFS_LOAD_H

YFS_LOAD_STOP_H

YFS_LOAD_SHIPMENT_CHARGE_H

YFS_LOAD_STATUS_AUDIT_H

370 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
YFS_SHIPMENT_CONTAINER_H

YFS_CONTAINER_ACTIVITY_H

YFS_LOADED_CONTAINER_H

YFS_LOAD_SHIPMENT_H

YFS_ADDITIONAL_DATE_H

YFS_LOAD_HOLD_TYPE_H

YFS_LOAD_HOLD_TYPE_LOG_H

Load Purge
This purge removes load data from the system. It picks up all loads that have been
marked as ‘Closed' and purges them. Empty Loads (for example, loads with no
shipments) are not considered for purge. As a part of this purge, the associated
child tables are also purged.

This is not a pipeline transaction. It also does not work from the task queue.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, a load is picked up for purge:
v The Load's last modification should fall before the lead time (in days) setup.

Attributes

The following are the attributes for this time-triggered transaction:

Table 299. Load Purge Attributes
Attribute Value
Base Transaction ID LOADPRG
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 300. Load Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.

Chapter 26. Time-Triggered Transaction Reference 371

 Table 300. Load Purge Criteria Parameters (continued)
Parameter Description
EnterpriseCode Optional. Enterprise for which the Load Purge needs to be
run. If not passed, then all enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 301. Load Purge Statistics
Statistic Name Description
NumLoadShipmentsPurged Number of load shipments purged.
NumLoadsPurged Number of loads purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Load table.

Events Raised

None.

Tables Purged

YFS_ADDITIONAL_DATE

YFS_LOAD

YFS_LOAD_HOLD_TYPE

YFS_LOAD_HOLD_TYPE_LOG

YFS_LOAD_STOP

YFS_LOAD_SHIPMENT

YFS_LOAD_SHIPMENT_CHARGES (charges that pertain to this load)

YFS_LOAD_STATUS_AUDIT

372 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
YFS_LOADED_CONTAINER

YFS_SHIPMENT_CONTAINER

YFS_CONTAINER_ACTIVITY

Negotiation History Purge

This purge deletes negotiation history data from the system. This reduces the load
on frequently accessed tables. It purges data from the order negotiation history
tables.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, a negotiation is picked up for history purge:
v The last modified date of the negotiation exceeds the retention day period.

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:

Table 302. Negotiation History Purge Attributes
Attribute Value
Base Transaction ID NEGOTIATIONHISTPRG
Base Document Type Order
Base Process Type Order Negotiation
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 303. Negotiation History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Negotiation History Purge
needs to be run. If not passed, then all enterprises are
monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.

Chapter 26. Time-Triggered Transaction Reference 373

 Table 303. Negotiation History Purge Criteria Parameters (continued)
Parameter Description
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 304. Negotiation History Purge Statistics
Statistic Name Description
NumNegotiationHistoriesPurged Number of negotiation histories purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Negotiation_Hdr_H table.

Events Raised

None.

Tables Purged

YFS_AUDIT

YFS_NEGOTIATION_HDR_H

YFS_NEGOTIATION_LINE_H

YFS_RESPONSE_H

YFS_RESPONSE_HDR_H

YFS_RESPONSE_LINE_H

YFS_RESPONSE_LINE_DTL_H

Negotiation Purge
This purge archives data into history tables after it completes its typical lifecycle.
This reduces the load on frequently accessed tables. It works from the task queue
(YFS_TASK_Q) table.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, a negotiation is picked up for purge:
v The last modification performed on the negotiation falls before the lead time (in
days) setup.
v The negotiation is in pickable status.

374 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:

Table 305. Negotiation Purge Attributes
Attribute Value
Base Transaction ID ORD_NEGOTIATION_PURGE
Base Document Type Order
Base Process Type Order Negotiation
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 306. Negotiation Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Negotiation Purge needs to
be run. If not passed, then all enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 307. Negotiation Purge Statistics
Statistic Name Description
NumOrderNegotiationsPurged Number of order negotiations purged.

Chapter 26. Time-Triggered Transaction Reference 375

 Pending Job Count

For this transaction, the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

None

Tables Purged

YFS_AUDIT

YFS_NEGOTIATION_HDR

YFS_NEGOTIATION_LINE

YFS_RESPONSE

YFS_RESPONSE_HDR

YFS_RESPONSE_LINE

YFS_RESPONSE_LINE_DTL

Opportunity History Purge

This transaction deletes tasks previously archived by the Opportunity Purge. See
“Opportunity Purge” on page 378.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, an opportunity that is previously purged by the opportunity
purge agent is picked up for history purge:
v The last modified date of the opportunity should exceed the retention day
period.
v The quote history is purged.

Attributes

The following are the attributes for this time-triggered transaction:

Table 308. Opportunity History Purge Attributes
Attribute Value
Base Transaction ID OPPORTUNITYHISTPRG
Base Document Type Opportunity
Base Process Type Opportunity Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called None

376 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:

Table 309. Opportunity History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Live Optional. Mode in which to run. Defaults to N.
v Y - Default value. Removes qualifying records from the
history tables listed under Tables Purged.
v N- Test mode. Determines the rows that are removed
without actually removing them.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Opportunity History Purge
needs to be run. If not passed, then all enterprises are
monitored.

When the EnterpriseCode is blank, the purge criteria

configured for the DEFAULT enterprise is used; not the purge
criteria configured for the opportunity's enterprise.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 310. Opportunity History Purge Statistics
Statistic Name Description
NumOpportunityHistory Number of opportunity histories purged.
Purged

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_OPPORTUNITY_H table.

Events Raised

None.

Chapter 26. Time-Triggered Transaction Reference 377

 Tables Purged

YFS_OPPORTUNITY_H

YFS_OPPORTUNITY_H_EXTENSION

Opportunity Purge
This time-triggered transaction purges all the opportunities for a period greater
than the retention days specified in the Opportunity Purge criteria, and those
which are either in the status of cancelled or completed.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, an opportunity is picked up for purge:
v The last modified date of the opportunity should exceed the retention day
period.
v The quote associated with the opportunity should be purged.
v The opportunity should be in pickable status by the purge transaction.

Attributes

The following are the attributes for this time-triggered transaction:

Table 311. Opportunity Purge Attributes
Attribute Value
Base Transaction ID OPPORTUNITYPRG
Base Document Type Opportunity
Base Process Type Opportunity Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 312. Opportunity Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Live Optional. Mode in which to run. Defaults to Y.
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.

378 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 312. Opportunity Purge Criteria Parameters (continued)
Parameter Description
EnterpriseCode Optional. Enterprise for which the Opportunity Purge needs to
be run. If not passed, then all enterprises are monitored.

When the EnterpriseCode is blank, the purge criteria

configured for the DEFAULT enterprise is used; not the purge
criteria configured for the opportunity's enterprise.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 313. Opportunity Purge Statistics
Statistic Name Description
NumOpportunityPurged Number of opportunities purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_OPPORTUNITY table.

Events Raised

None.

Tables Purged

YFS_OPPORTUNITY

YFS_OPPORTUNITY_EXTENSION

Order History Purge

This purge deletes data from history tables after it completes its typical lifecycle.
This reduces the load on frequently accessed tables.

The order should have been purged and moved into the history tables before you
can run this transaction. For more information about this, see “Order Purge” on
page 382.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, an order is picked up for history purge:
v The last modified date of the order exceeds the retention day period.

Any enterprise using the Console must schedule purge transactions.

Chapter 26. Time-Triggered Transaction Reference 379

 For more information about Additional Purge Criteria Based on Line Type, see the
Sterling Selling and Fulfillment Foundation: Distributed Order Management
Configuration Guide.

Attributes

The following are the attributes for this time-triggered transaction:

Table 314. Order History Purge Attributes
Attribute Value
Base Transaction ID ORDERHISTPRG
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 315. Order History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Order History Purge needs
to be run. If not passed, then all enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Removes qualifying records from the
history tables listed under Tables Purged.
v N- Test mode. Determines the rows that are removed
without actually removing them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 316. Order History Purge Statistics
Statistic Name Description
NumOrderHistoriesPurged Number of order histories purged.

380 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Order_HEADER_H table.

Events Raised

None.

Tables Purged

YFS_ANSWER_SET_TRAN_H

YFS_ANSWER_TRAN_H

YFS_CHARGE_TRAN_DIST_H

YFS_CHARGE_TRAN_REQUEST_H

YFS_CHARGE_TRAN_RQ_MAP_H

YFS_CHARGE_TRANSACTION_H

YFS_CREDIT_CARD_TRANSACTION_H

YFS_ENTITY_ADDRESS_H

YFS_HEADER_CHARGES_H

YFS_INSTRUCTION_DETAIL_H

YFS_INVOICE_COLLECTION_H

YFS_LINE_CHARGES_H

YFS_NOTES_H

YFS_ORDER_AUDIT_DETAIL_H

YFS_ORDER_AUDIT_H

YFS_ORDER_AUDIT_LEVEL_H

YFS_ORDER_DATE_H

YFS_ORDER_HEADER_H

YFS_ORDER_HEADER_H_EXTENSION

YFS_ORDER_HOLD_TYPE_H

YFS_ORDER_HOLD_TYPE_LOG_H

YFS_ORDER_INVOICE_DETAIL_H

YFS_ORDER_INVOICE_H

Chapter 26. Time-Triggered Transaction Reference 381

 YFS_ORDER_KIT_LINE_H

YFS_ORDER_KIT_LINE_SCHEDULE_H

YFS_ORDER_LINE_H

YFS_ORDER_LINE_H_EXTENSION

YFS_ORDER_LINE_OPTION_H

YFS_ORDER_LINE_REQ_TAG_H

YFS_ORDER_LINE_SCHEDULE_H

YFS_ORDER_PROD_SER_ASSOC_H

YFS_ORDER_RELEASE_H

YFS_ORDER_RELEASE_STATUS_H

YFS_ORDER_SER_PROD_ITEM_H

YFS_PAYMENT_H

YFS_PROMOTION_AWARD_H

YFS_PROMOTION_H

YFS_RECEIVING_DISCREPANCY_DTL_H

YFS_RECEIVING_DISCREPANCY_H

YFS_REFERENCE_TABLE_H

YFS_TAX_BREAKUP_H

YIC_BOM_HEADER_H

YIC_BOM_LINE_H

YIC_BOM_MESSAGE_H

YIC_BOM_PROP_H

Order Purge
This purge archives data into history tables after it completes its typical lifecycle.
To purge orders from history tables, see “Order History Purge” on page 379. This
reduces the load on frequently accessed tables. It works on a task queue. It picks
up the orders from YFS_TASK_Q table that are available for the transaction
PURGE.

If purge criteria are not met, AVAILABLE_DATE is calculated based on the modify
time stamp of the order in YFS_ORDER_HEADER table as well as the
YFS_TASK_Q table, whichever is maximum. To this value, retention days is added
to the new AVAILABLE_DATE.

382 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
This transaction depends on all lines of an order being in a status pickable by the
Purge transaction.

The following statuses are available for configuration to be picked up by Order

Purge:
v Draft Created (1000) and all extended Draft Created Statuses.
v Created (1100) and all extended Created statuses. These statuses are available
only for document types Sales Order, Purchase Order and Transfer Order.
v Released (3200) and all extended Released statuses.
v Shipped (3700) and all extended Shipped statuses.
v Completed (3700) and all extended Completed statuses. These statuses are
available only for the document type Master Order.
v Received (3900) and all extended Received statuses.
v Cancelled (9000) and all extended Cancelled statuses.
v Shorted (9020) and all extended Shorted statuses.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, an order is picked up for purge:
v All open child orders (derived, chained, return, exchange, procurement, or
refund fulfillment) for the order must already be purged.
v No pending transfer-out charges to another order exceeding the transfer-ins.
v No pending adjustment invoices.

An order is purged immediately if it meets the above three criteria and is

completely cancelled with payment collection complete.

For the purge agent to pick up a cancelled order, the payment status of the order
must be one of the following:
v Paid
v Not Applicable

If an order does not meet any of the above criteria, continue checking for the
criteria given below:
v No order release status record that does not meet the retention days.
v It should be in the correct status for purge. For example,
– All service requests for the order should have Shipped or extended Shipped
status.
– The payment status for the order should be Paid or Not Applicable.
– It must not have any unpurged negotiations.
v For all order lines other than service request lines:
– If the Seller inventory update is required, the Status Inventory Type has the
“Update Seller Supply” option turned on, and the Seller Supply Type is
“Onhand”, or blank. (The Seller Supply Type can also be a custom seller
supply type with the “Onhand Supply” checkbox enabled.)
– If the Seller Demand Type is blank.
– If the Buyer inventory update is required and the Buyer Supply Type is
“Onhand”, or blank.
v The order's last modification should fall before the lead time (in days) setup.
v Any enterprise using the Console must schedule purge transactions.
v The order must not have a undelivered service line.

Chapter 26. Time-Triggered Transaction Reference 383

 v In the case of an exchange order for processing a return order, the exchange
order should be purged from history before the return order can be purged.

With no change to status inventory type, a in Shipped (3700) status or its extended
status is purged if the Buyer is not passed.

An order in Shipped status or extended Shipped status in the default pipeline is

not purged if the Buyer passed on the is tracking inventory. This prevents the
purging of the order relating to the pending supply for the Buyer tracking
inventory.

To purge such orders, the status inventory type for the Shipped or extended
Shipped status should be configured such that the Buyer Supply Type is
ONHAND for the status inventory type.

When the purge agent is run, the draft order without lines are purged to the order
history table. Once the purge history agent is run, the draft orders without lines
gets deleted permanently.

Attributes

The following are the attributes for this time-triggered transaction:

Table 317. Order Purge Attributes
Attribute Value
Base Transaction ID PURGE
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 318. Order Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
EnterpriseCode Optional. Enterprise for which the Order Purge needs to be
run. If not passed, then all enterprises are monitored.

When the EnterpriseCode is blank, the purge criteria

configured for the DEFAULT enterprise is used; not the purge
criteria configured for the order's enterprise.

384 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 318. Order Purge Criteria Parameters (continued)
Parameter Description
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Used for internal calculations, such as determining
retention days. Corresponds with the PurgeCode used in
Business Rules Purge Criteria. You can set this parameter to
the following values:
v DRAFTORDERHISTPRG to purge draft order information
from the order history tables.
v DRAFTORDERNOLINEHISTPRG to purge draft orders
without order lines from the order history tables.
v DRAFTORDERNOLINEPRG to purge draft orders that have
no order lines.
v DRAFTORDERPRG to purge draft order information and
archive it in the order history tables.

PurgeCode cannot be set to the value

ORDER_RELEASE_STATUS_PURGE.
AdditionalPurgeCode Optional. To purge order release status records, set this
parameter to ORDER_RELEASE_STATUS_PURGE.

For more information, see “Order Release Status Purge” on

page 387.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 319. Order Purge Statistics
Statistic Name Description
NumOrdersProcessed Number of order processed.
NumOrdersPurged Number of orders purged.

Pending Job Count

For this transaction, the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

None.

Chapter 26. Time-Triggered Transaction Reference 385

 Tables Purged

YFS_ACTIVITY_DEMAND

YFS_ANSWER_SET_TRAN

YFS_ANSWER_TRAN

YFS_CHARGE_TRANSACTION

YFS_CHARGE_TRAN_DIST

YFS_CHARGE_TRAN_REQUEST

YFS_CHARGE_TRAN_RQ_MAP

YFS_CREDIT_CARD_TRANSACTION

YFS_ENTITY_ADDRESS

YFS_HEADER_CHARGES

YFS_INSTRUCTION_DETAIL

YFS_INVOICE_COLLECTION

YFS_LINE_CHARGES

YFS_MONITOR_ALERT

YFS_NOTES

YFS_ORDER_AUDIT

YFS_ORDER_AUDIT_DETAIL

YFS_ORDER_AUDIT_LEVEL

YFS_ORDER_HEADER

YFS_ORDER_HEADER_EXTENSION

YFS_ORDER_HOLD_TYPE

YFS_ORDER_HOLD_TYPE_LOG

YFS_ORDER_INVOICE

YFS_ORDER_INVOICE_DETAIL

YFS_ORDER_KIT_LINE

YFS_ORDER_KIT_LINE_SCHEDULE

YFS_ORDER_LINE

386 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
YFS_ORDER_LINE_EXTENSION

YFS_ORDER_LINE_OPTION

YFS_ORDER_LINE_REQ_TAG

YFS_ORDER_LINE_RESERVATION

YFS_ORDER_LINE_SCHEDULE

YFS_ORDER_LINE_SRC_CNTRL

YFS_ORDER_PROD_SER_ASSOC

YFS_ORDER_RELEASE

YFS_ORDER_RELEASE_STATUS

YFS_ORDER_SER_PROD_ITEM

YFS_ORDER_DATE

YFS_PAYMENT

YFS_PMNT_TRANS_ERROR

YFS_PROMOTION

YFS_PROMOTION_AWARD

YFS_RECEIVING_DISCREPANCY

YFS_RECEIVING_DISCREPANCY_DTL

YFS_REFERENCE_TABLE

YFS_TAX_BREAKUP

YIC_BOM_HEADER

YIC_BOM_LINE

YIC_BOM_MESSAGE

YIC_BOM_PROP

Order Release Status Purge

The Order Release Status Purge agent extends the Order Purge agent's capabilities
by purging order release status records before the Order Purge agent completely
purges data to history tables.

If an order meets the criteria for purging, the order release status records with
quantities of 0 are deleted from the YFS_ORDER_RELEASE_STATUS table and are
not put into the history table.

Chapter 26. Time-Triggered Transaction Reference 387

 When the Order Release Status Purge agent has completed, the task queue's
AVAILABLE_DATE is reset to the date specified by the purge criteria for Order
Purge. This enables the Order Purge agent to pick up and process an order as
necessary. Order Purge will continue to purge order release status records as usual.

If the following conditions are met, the Order Purge agent purges order release
status records:
v All conditions for Order Purge have been met. See “Order Purge” on page 382
for information about conditions for Order Purge.
v Order release records have 0 quantity.
v AdditionalPurgeCode in the Order Purge criteria is set to
ORDER_RELEASE_STATUS_PURGE.
v The order has been modified within the Order Purge lead days
AdditionalPurgeCode.

Criteria Parameters

The following are the criteria parameters for Order Release Status Purge:
Table 320. Order Release Status Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Next Task Queue Interval Optional. Specifies in hours how long a failed task should be
suspended before it is considered for reprocessing. Defaults to
5 hours.
EnterpriseCode Optional. Enterprise for which the Order Purge needs to be
run. If not passed, then all enterprises are monitored.

When the EnterpriseCode is blank, the purge criteria

configured for the DEFAULT enterprise is used; not the purge
criteria configured for the order's enterprise.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. To extend the Order Purge agent to purge order
release status records, set to ORDERPRG. Used for internal
calculations, such as determining retention days. You must
also set AddtionalPurgeCode.
AdditionalPurgeCode Required. To purge order release status records, set this
parameter to ORDER_RELEASE_STATUS_PURGE.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

388 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Pending Job Count

The pending job count is the number of records available to be processed by Order
Purge with the AVAILABLE_DATE value less than or equal to (<=) the current
date value in the YFS_Task_Q table.

Events Raised

None.

Tables Purged

YFS_ORDER_RELEASE_STATUS

Order Status Audit Purge

This purge removes order status audit data from the system. This reduces the load
on frequently accessed tables.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, an order status audit is picked up for history purge:
v The last modified time falls before the lead time (in days) setup.

Any enterprise using the Console must schedule purge transactions.

This transaction needs to be run after negotiation is completed.

Attributes

The following are the attributes for this time-triggered transaction:

Table 321. Order Status Audit Purge Attributes
Attribute Value
Base Transaction ID STATUSAUDITPRG
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 322. Order Status Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.

Chapter 26. Time-Triggered Transaction Reference 389

 Table 322. Order Status Audit Purge Criteria Parameters (continued)
Parameter Description
EnterpriseCode Optional. Enterprise for which the Order Status Audit Purge
needs to be run. If not passed, then all enterprises are
monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_STATUS_AUDIT Table may exist in multiple schemas.
Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 323. Order Status Audit Purge Statistics
Statistic Name Description
NumStatusAuditsPurged Number of status audits purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Status_Audit table.

Events Raised

None.

Tables Purged

YFS_STATUS_AUDIT

Organization Audit Purge

This purge removes the YFS_AUDIT table data from the system, which reduces the
load on frequently accessed tables. It purges records in the YFS_AUDIT and the
YFS_AUDIT_HEADER tables that meet the following conditions:
v The YFS_AUDIT records that have ‘modifyts' greater than the retention days
specified and the records have the table name as 'YFS_ORGANIZATION'.
v The last modified time is before the lead time (in days) setup.

When the enterprise modifies records in the YFS_ORGANIZATION table through

the Applications Manager, the YFS_ORGANIZATION is audited and the audit
records are inserted in the YFS_AUDIT table. In order to clean up the audit
records, this purge transaction can be used.

390 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:

Table 324. Organization Audit Purge Attributes
Attribute Value
Base Transaction ID YFS_ORGANIZATION_AUDIT_PURGE
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 325. Organization Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, the value
defaults to Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), this value defaults
to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Production mode. Deletes records from
the regular tables.
v N - Test mode.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds to the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_AUDIT and YFS_AUDIT_HEADER tables may exist in
multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 326. Organization Audit Purge Statistics
Statistic Name Description
NumOrganizationAudit Number of organization audit records purged.
RecordsPurged

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_AUDIT table that match the criteria values.

Chapter 26. Time-Triggered Transaction Reference 391

 Events Raised

None.

Tables Purged

YFS_AUDIT

YFS_AUDIT_HEADER

Person Info Purge

This purge gets a list of dates with the person info record count and sorts them by
date in ascending order. Then, based on the specified number of records to buffer
and the modify timestamp, it purges the applicable records and places them in the
YFS_PERSON_INFO_H table.

Attributes

The following are the attributes for this time-triggered transaction:

Table 327. PersonInfo Purge Attributes
Attribute Value
Base Transaction ID PERSONINFOPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 328. PersonInfo Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time.
v If left blank or the number specified is less than 10000, it
defaults to 10000.
v If the number specified is greater than 10000, then that
value is used.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.

392 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 328. PersonInfo Purge Criteria Parameters (continued)
Parameter Description
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
EnterpriseCode Optional. Enterprise for which the PersonInfo Purge needs to
be run. If not passed, then all enterprises are monitored.
TableType Required in a multi schema deployment when
YFS_Person_Info table may exist in multiple schemas.

Valid Values: CONFIGURATION, TRANSACTION, MASTER.

If set to CONFIGURATION, purge runs for the

YFS_Person_Info records associated with tables that have
TableType as CONFIGURATION; for example,
YFS_Organization, YFS_Ship_Node, and so forth.

If set to TRANSACTION, purge runs for the YFS_Person_Info

records associated with tables that have TableType as
TRANSACTION; for example, YFS_Order_Header,
YFS_Shipment, and so forth.

Note that purge would run for all TableTypes that exist in the
same schema as the one passed. For example, if set to
TRANSACTION, purge would also run for YFS_Person_Info
records associated with tables that have TableType as
MASTER, since they reside in the same schema.
ColonyID Required in a multi schema deployment where the
YFS_PERSON_INFO table may exist in multiple schemas.
Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

If it is left blank or any number less than 10,000 is specified, then it defaults to
10,000. But if any number > 10,000 is specified, then that value would be used.
Table 329. PersonInfo Purge Statistics
Statistic Name Description
NumPersonInfoPurged Number of person info records purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_PERSON_INFO table.

Events Raised

None.

Chapter 26. Time-Triggered Transaction Reference 393

 Tables Purged

YFS_PERSON_INFO

Person Info History Purge

This purge deletes records from the YFS_PERSON_INFO_H table based on the
purge criteria.

Attributes

The following are the attributes for this time-triggered transaction:

Table 330. PersonInfo History Purge Attributes
Attribute Value
Base Transaction ID PERSONINFOHISTPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 331. PersonInfo History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time.
v If left blank or the number specified is less than 10000, it
defaults to 10000.
v If the number specified is greater than 10000, then that
value is used.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
EnterpriseCode Optional. Enterprise for which the PersonInfo Purge needs to
be run. If not passed, then all enterprises are monitored.

394 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 331. PersonInfo History Purge Criteria Parameters (continued)
Parameter Description
TableType Required in a multi schema deployment when
YFS_Person_Info table may exist in multiple schemas.

Valid Values: CONFIGURATION, TRANSACTION, MASTER.

If set to CONFIGURATION, purge runs for the

YFS_Person_Info records associated with tables that have
TableType as CONFIGURATION; for example,
YFS_Organization, YFS_Ship_Node, and so forth.

If set to TRANSACTION, purge runs for the YFS_Person_Info

records associated with tables that have TableType as
TRANSACTION; for example, YFS_Order_Header,
YFS_Shipment, and so forth.

Note that purge would run for all TableTypes that exist in the
same schema as the one passed. For example, if set to
TRANSACTION, purge would also run for YFS_Person_Info
records associated with tables that have TableType as
MASTER, since they reside in the same schema.
ColonyID Required in a multi schema deployment where the
YFS_PERSON_INFO_H table may exist in multiple schemas.
Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 332. PersonInfo History Purge Statistics
Statistic Name Description
NumPersonInfoHIstoryRecords Number of person info history records purged.
Purged

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_PERSON_INFO_H table.

Events Raised

None.

Tables Purged

YFS_PERSON_INFO_H

Picklist Purge
This purge picks up all picklists that have been existing for a period greater than
the retention days specified in the criteria parameters and those that do not have
any shipments.

Any enterprise using the Console must schedule purge transactions.

Chapter 26. Time-Triggered Transaction Reference 395

 You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a picklist is picked up for purge:
v The picklist should exist for more than the specified retention period.
v The picklist should not be associated with any shipment.

All shipments associated with the picklists should have been purged before
running this purge agent.

Attributes

The following are the attributes for this time-triggered transaction:

Table 333. Picklist Purge Attributes
Attribute Value
Base Transaction ID PICKLISTPRG
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 334. Picklist Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_PICK_LIST table may exist in multiple schemas. Runs the
agent for the colony.

396 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:

Table 335. Picklist Purge Statistics
Statistic Name Description
NumPickListsPurged Number of picklists purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_PICK_LIST table.

Events Raised

None.

Tables Purged

YFS_PICK_LIST

Price List Purge

This purge removes price list data from the system. This reduces the load on
frequently accessed tables.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, a price list is picked up for purge:
v The price list has valid date less than the current date minus the purge criteria's
retention days.

Attributes

The following are the attributes for this time-triggered transaction:

Table 336. Price List Purge Attributes
Attribute Value
Base Transaction ID PRICELISTPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Chapter 26. Time-Triggered Transaction Reference 397

 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 337. Price List Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 338. Price List Purge Statistics
Statistic Name Description
NumPriceSetsPurged Number of price sets purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Price_Set table.

Events Raised

None.

Tables Purged

YFS_PRICE_SET table with VALID_TILL_DATE less than or equal to (CurrentDate

- LeadDays)

YFS_PRICE_PROGRAM_DEFN

YFS_ITEM_PRICE_SET

YFS_ITEM_PRICE_SET_DTL

398 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Purge Catalog Mass Audits
This purge removes old audit records from the YFS_CATALOG_MASS_AUDIT
table. This table contains data about changes to the catalog due to assignment of
attributes and attribute values to categories and items. It also contains information
about inherited attributes and attribute values. The purge transaction finds mass
audit records that have not been modified in a specified number of days and
removes those records from the database.

Attributes

The following are the attributes for this time-triggered transaction:

Table 339. Purge Catalog Mass Audits Attributes
Attribute Value
Base Transaction ID CATALOG_MASS_AUDIT_PURGE
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 340. Purge Catalog Mass Audits Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_CATALOG_MASS_AUDIT table may exist in multiple
schemas. Runs the agent for the colony.

Chapter 26. Time-Triggered Transaction Reference 399

 Statistics Tracked

The following statistics are tracked for this transaction:

Table 341. Purge Catalog Mass Audits Statistics
Statistic Name Description
NumCatalogMassAuditsPurged Number of mass audit records purged.

Pending Job Count

For this transaction the pending job count is the total number of records that can
be purged from the YFS_CATALOG_MASS_AUDIT table.

Events Raised

None.

Tables Purged

The YFS_CATALOG_MASS_AUDIT table is purged when MODIFYTS <

(CurrentDate - LeadDays)

Receipt History Purge

This transaction deletes receipts previously archived by the Receipt Purge. See
“Receipt Purge” on page 402.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a receipt that is previously purged by the receipt purge agent is
picked up for history purge:
v The last modified date of the receipt should exceed the retention day period.
v The shipment associated with the receipt should be purged from the history
table.

To purge a receipt history, ensure that the Receipts are closed and Shipments are
purged.

Attributes

The following are the attributes for this time-triggered transaction:

Table 342. Receipt History Purge Attributes
Attribute Value
Base Transaction ID RECEIPTHISTPRG
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

400 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:

Table 343. Receipt History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Receipt History Purge
needs to be run. If not passed, then all enterprises are
monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Removes qualifying records from the
history tables listed under Tables Purged.
v N- Test mode. Determines the rows that are removed
without actually removing them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 344. Receipt History Purge Statistics
Statistic Name Description
NumReceiptLineHistoriesPurged Number of receipt line histories purged.
NumReceiptHistoriesPurged Number of receipt histories purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Receipt_Header_H table.

Events Raised

None.

Tables Purged

YFS_RECEIPT_HEADER_H

YFS_RECEIPT_LINE_H

YFS_RECEIPT_STATUS_AUDIT_H

YFS_INSTRUCTION_DETAIL_H

Chapter 26. Time-Triggered Transaction Reference 401

 Receipt Purge
This purge removes receipt data from the system. This reduces the load on
frequently accessed tables. This transaction picks up all receipts that are not open
and not pending inspection and archives them into their history tables. See
“Receipt History Purge” on page 400. It also archives and purges the receipt's child
tables.

This is a pipeline transaction and works from a task queue.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a receipt is picked up for purge:
v The last modified date of the receipt should exceed the retention day period.
v The shipment associated with the receipt should be purged.
v The receipt should be in pickable status for the purge transaction.
v The value of the OpenReceiptFlag field should be set to "N".
v The receipt should not have pending inspections.
v There is no inventory in the warehouse for the receipt.

To purge a receipt, ensure that the receipts are closed and Shipments are purged.

Attributes

The following are the attributes for this time-triggered transaction:

Table 345. Receipt Purge Attributes
Attribute Value
Base Transaction ID RECEIPTPRG
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 346. Receipt Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Receipt Purge needs to be
run. If not passed, then all enterprises are monitored.

402 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 346. Receipt Purge Criteria Parameters (continued)
Parameter Description
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 347. Receipt Purge Statistics
Statistic Name Description
NumReceiptLinesPurged Number of Receipt Lines purged.
NumReceiptsPurged Number of receipts purged.

Pending Job Count

For this transaction, the pending job count is the number of records available to be
processed by the transaction with the AVAILABLE_DATE value less than or equal
to (<=) the current date value in the YFS_Task_Q table.

Events Raised

None.

Tables Purged

YFS_RECEIPT_HEADER

YFS_RECEIPT_LINE

YFS_RECEIPT_STATUS_AUDIT

YFS_INSTRUCTION_DETAIL

Reprocess Error Purge

This purge deletes reprocess errors from the system. This reduces the load on
frequently accessed tables.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a YFS_REPROCESS_ERROR table is picked up for purge:
v YFS_REPROCESS_ERROR records with State = Fixed or Ignored is processed.
v The last modified time is earlier than the lead time (in days) setup.

Chapter 26. Time-Triggered Transaction Reference 403

 This purge reads only the rules defined by the hub. Enterprise overridden rules are
not considered.

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:

Table 348. Reprocess Error Purge Attributes
Attribute Value
Base Transaction ID REPROCESSPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 349. Reprocess Error Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_REPROCESS_ERROR table may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 350. Reprocess Error Purge Statistics
Statistic Name Description
NumReprocessErrorsPurged Number of reprocess errors purged.

404 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_REPROCESS_ERROR table.

Events Raised

None.

Tables Purged

YFS_REPROCESS_ERROR

Reservation Purge
This purge deletes expired inventory reservations from the system. This reduces
the load on frequently accessed tables as well as free up demands that are
consumed by expired reservations.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, all records in the YFS_INVENTORY_RESERVATION tables are picked up
for purge:
v EXPIRATION_DATE is earlier than the current date or quantity is less than or
equal to 0

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:

Table 351. Reservation Purge Attributes
Attribute Value
Base Transaction ID RESERVATIONPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 352. Reservation Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.

Chapter 26. Time-Triggered Transaction Reference 405

 Table 352. Reservation Purge Criteria Parameters (continued)
Parameter Description
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_INVENTORY_RESERVATION table may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 353. Reservation Purge Statistics
Statistic Name Description
NumReservationsPurged Number of reservations purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_INVENTORY_RESERVATION table.

Events Raised

None.

Tables Purged

YFS_INVENTORY_RESERVATION

Shipment History Purge

This transaction deletes shipments previously archived by the Shipment Purge. See
“Shipment Purge” on page 408.

Any enterprise using the Console must schedule purge transactions.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, all records archived in the history table are picked up for purge:
v The last modification performed on the shipment falls before the lead time (in
days) setup.

Orders related to the shipments should have been purged by order purge.
Shipments should have been closed by the Close Shipment transaction. See “Close
Shipment” on page 294.

406 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 354. Shipment History Purge Attributes
Attribute Value
Base Transaction ID SHIPMENTHISTPRG
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 355. Shipment History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Shipment History Purge
needs to be run. If not passed, then all enterprises are
monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Removes qualifying records from the
history tables listed under Tables Purged.
v N- Test mode. Determines the rows that are removed
without actually removing them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 356. Shipment History Purge Statistics
Statistic Name Description
NumShipmentHistoriesPurged Number of shipment histories purged.
NumShipmentLineHistoriesPurged Number of shipment line histories purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Shipment_H table.

Chapter 26. Time-Triggered Transaction Reference 407

 Events Raised

None.

Tables Purged

YFS_ADDITIONAL_ATTRIBUTE_H

YFS_ADDITIONAL_DATE_H

YFS_AUDIT

YFS_CONTAINER_DETAILS_H

YFS_CONTAINER_STS_AUDIT_H

YFS_INSTRUCTION_DETAIL_H

YFS_SHIPMENT_CONTAINER_H

YFS_SHIPMENT_H

YFS_SHIPMENT_LINE_H

YFS_SHIPMENT_LINE_REQ_TAG_H

YFS_SHIPMENT_STATUS_AUDIT_H

YFS_SHIPMENT_TAG_SERIAL_H

YFS_CONTAINER_ACTIVITY_H

Shipment Purge
This purge removes shipment data from the system. This reduces the load on
frequently accessed tables. This transaction picks up all shipments that have been
marked as ‘Closed' and archives them into their history tables. See “Shipment
History Purge” on page 406. It also archives and purges the shipment's child
tables.

This is not a pipeline transaction. It also does not work from the task queue.

Any enterprise using the Console must schedule purge transactions.

Orders related to the shipments should have been purged by order purge.
Shipments should have been closed by the Close Shipment transaction. For more
information, see “Close Shipment” on page 294.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a shipment is picked up for purge:
v The last modification performed on the shipment should fall before the lead
time (in days) setup.
v The value of the ShipmentClosedFlag field should be set to "Y".
v The order record should already be purged for all shipment lines.

408 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 357. Shipment Purge Attributes
Attribute Value
Base Transaction ID SHIPMENTPRG
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 358. Shipment Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Number of Days To Optional. Maximum number of days before the lead days the
Execute agent will look for shipment records to purge.
EnterpriseCode Optional. Enterprise for which the Shipment Purge needs to be
run. If not passed, then all enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 359. Shipment Purge Statistics
Statistic Name Description
NumShipmentsPurged Number of Shipments purged.
NumShipmentLinesPurged Number of Shipment Lines purged.

Chapter 26. Time-Triggered Transaction Reference 409

 Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_Shipment table.

Events Raised

None.

Tables Purged

YFS_ADDITIONAL_ATTRIBUTES

YFS_ADDITIONAL_DATE

YFS_AUDIT

YFS_CONTAINER_DETAILS

YFS_LOAD_SHIPMENT_CHARGE

YFS_MONITOR_ALERT

YFS_SHIPMENT_CONTAINER

YFS_SHIPMENT_STATUS_AUDIT

YFS_SHIPMENT

YFS_INSTRUCTION_DETAIL

YFS_SHIPMENT_MONITOR_ALERT

YFS_HEADER_CHARGES

YFS_LINE_CHARGES

YFS_TAX_BREAKUP

YFS_SHIPMENT_HOLD_TYPE

YFS_SHIPMENT_HOLD_TYPE_LOG

YFS_SHIPMENT_TAG_SERIALS

YFS_SHIPMENT_LINE

YFS_SHIPMENT_LINE_REQ_TAG

YFS_ACTIVITY_DEMAND

YFS_CONTAINER_STS_AUDIT

YFS_CONTAINER_ACTIVITY

410 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Shipment Statistics Purge
This transaction deletes the shipment statistics from the table older than the
specified retention days.

This agent should be used whenever shipment statistics records need to be

removed, such as after application server restart.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, the shipment statistics are picked up for purge:
v The last modification performed on the shipment statistics should fall before the
lead time (in days) setup.

Attributes

The following are the attributes for this time-triggered transaction:

Table 360. Shipment Statistics Purge Attributes
Attribute Value
Base Transaction ID PRG_SHIP_STATS
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 361. Shipment Statistics Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Shipment Statistics Purge
needs to be run. If not passed, then all enterprises are
monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
YFS_SHIPMENT_STATISTICS table may exist in multiple
schemas. Runs the agent for the colony.

Chapter 26. Time-Triggered Transaction Reference 411

 Statistics Parameters

The following are the statistics parameters for this transaction:

Table 362. Shipment Statistics Purge Statistics
Parameter Description
NumShipmentStatisticsPurged Number of shipment statistics purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_SHIPMENT_STATISTICS table.

Events Raised

None.

Tables Purged

YFS_SHIPMENT_STATISTICS

User Activity Purge

This purge deletes the user activity data from the system. It purges all records
older than the specified retention days, and those records which have a logged out
status. This purge must be single threaded when you run it in batch delete mode
(BatchDelete=Y).

The following limitation is assumed when purging records:

This purge do not purge any record if the Application server goes down abruptly
because the audit records of users connected to the application server at the time
when the server went down cannot be updated. As a result, the last activity time
or the logout time is not populated. The purge does not know whether the user
has logged out or still logged in. Therefore, you need to manually delete these
records.

The following are the attributes for this time-triggered transaction:

Table 363. User Activity Purge Attributes
Attribute Value
Base Transaction ID USERACTIVITYPRG
Base Document Type None
Base Process Type None
APIs Called None
User Exits Called None

412 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:

Table 364. User Activity Purge Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under to the corresponding history
tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This
pending job information is used for monitoring the monitor
in the System Management Console.
Number of Records To Required. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 100.
BatchDelete Required. The method by which all records are deleted from
the table. Valid values are:
v Y - Default value. Records are deleted in batches.
v N - Records are deleted one by one.
ColonyID Required in a multi schema deployment where the
YFS_USER_ACTIVITY table may exist in multiple schemas.
Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 365. Statistics Purge Statistics
Statistic Name Description
NumStatisticsPurged Number of statistics purged

Pending Job Count

None.

Events Raised

None.

Tables Purged

YFS_USER_ACTIVITY

Chapter 26. Time-Triggered Transaction Reference 413

 User Activity Audit Purge
This purge removes user activity audit data from the system. It purges all records
older than the specified retention days. It purges only those records which have a
logged out status (records with a Login_Type of ‘T' or ‘N'). This purge should be
single threaded when you run it in batch delete mode(BatchDelete=Y).

The following limitation is assumed when purging records:

v This purge does not purge any records if the Application server goes down
abruptly because the audit records of users connected to application servers at
the time the server went down cannot be updated. As a result, the last activity
time or the logout time does not get populated and the purge does not know
whether the user was logged out or was still logged in. These records have to be
deleted manually.

The following are the attributes for this time-triggered transaction:

Table 366. User Activity Audit Purge Attributes
Attribute Value
Base Transaction ID USERACTAUDPURGE
Base Document Type None
Base Process Type None
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 367. User Activity Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under to the corresponding history
tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
CollectPendingJobs If this parameter is set to "N", the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
Number of Records To Required. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 100.

414 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 367. User Activity Audit Purge Criteria Parameters (continued)
Parameter Description
BatchDelete Required. The method by which all records are deleted from
the table. Valid values are:
v Y - Default value. Records are deleted in batches.
v N - Records are deleted one by one.
ColonyID Required in a multi schema deployment where the
YFS_USER_ACT_AUDIT table may exist in multiple schemas.
Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 368. Statistics Purge Statistics
Statistic Name Description
NumStatisticsPurged Number of statistics purged

Pending Job Count

None.

Events Raised

None.

Tables Purged

YFS_USR_ACT_AUDIT

Work Order History Purge

This transaction deletes tasks previously archived by the Work Order Purge. See
“Work Order Purge” on page 417.

You can use purge codes pseudo-logic to analyze purges. If the last modified date
of the work order exceeds the retention day period, a work order that is previously
purged by the work order purge agent is picked up for history purge.

Attributes

The following are the attributes for this time-triggered transaction:

Table 369. Work Order History Purge Attributes
Attribute Value
Base Transaction ID WORK_ORDER_HISTORY_PURGE
Base Document Type Work Order
Base Process Type VAS
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Chapter 26. Time-Triggered Transaction Reference 415

 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 370. Work Order History Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Live Optional. Mode in which to run. Defaults to N.
v Y - Default value. Removes qualifying records from the
history tables listed under Tables Purged.
v N- Test mode. Determines the rows that are removed
without actually removing them.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Node Optional. Node for which the Work Order History Purge
needs to be run. If not passed, then all nodes are monitored.
AgentCriteriaGroup Optional. Used to classify nodes. This value can be accepted
by Sterling Selling and Fulfillment Foundation time-triggered
transactions that only perform their tasks on the nodes with a
matching node transactional velocity value.

Valid values are: LOW, HIGH, and any additional values

defined by the Hub from Application Platform > System
Administration > Agent Criteria Groups.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 371. Work Order History Purge Statistics
Statistic Name Description
NumWorkOrderHistoriesPurged Number of work order histories purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_WORK_ORDER_H table.

Events Raised

None.

416 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Tables Purged

YFS_AUDIT

YFS_WO_APPT_USER_H

YFS_WORK_ORDER_H

YFS_WORK_ORDER_APPT_H

YFS_WORK_ORDER_ACTIVITY_H

YFS_WORK_ORDER_ACTY_DTL_H

YFS_WORK_ORDER_AUDT_DTL_H

YFS_WORK_ORDER_COMPONENT_H

YFS_WORK_ORDER_COMP_TAG_H

YFS_WORK_ORDER_HOLD_TYPE_H

YFS_WORK_ORDER_HOLD_TYPE_LOG_H

YFS_WORK_ORDER_PROD_DEL_H

YFS_WORK_ORDER_SERVICE_LINE_H

YFS_WORK_ORDER_STS_AUDIT_H

YFS_WORK_ORDER_TAG_H

Work Order Purge

This time-triggered transaction purges all the work orders for a period greater than
the retention days specified in the Work Order Purge criteria and those, which are
either in the status of cancelled or completed.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a work order is picked up for purge:
v The last modified date of the work order should exceed the retention day
period.
v The order associated with the work order should be purged.
v The work order should be in pickable status by the purge transaction.

Attributes

The following are the attributes for this time-triggered transaction:

Table 372. Work Order Purge Attributes
Attribute Value
Base Transaction ID WORK_ORDER_PURGE
Base Document Type Work Order
Base Process Type VAS

Chapter 26. Time-Triggered Transaction Reference 417

 Table 372. Work Order Purge Attributes (continued)
Attribute Value
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 373. Work Order Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Live Optional. Mode in which to run. Defaults to Y.
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Node Optional. Node for which the Work Order Purge needs to be
run. If not passed, then all nodes are monitored.
AgentCriteriaGroup Optional. Used to classify nodes. This value can be accepted
by Sterling Selling and Fulfillment Foundation time-triggered
transactions that only perform their tasks on the nodes with a
matching node transactional velocity value.

Valid values are: LOW, HIGH, and any additional values

defined by the Hub from Application Platform > System
Administration > Agent Criteria Groups.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 374. Work Order Purge Statistics
Statistic Name Description
NumWorkOrdersPurged Number of work orders purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_WORK_ORDER table.

418 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Events Raised

None.

Tables Purged

YFS_AUDIT

YFS_WO_APPT_USER

YFS_WORK_ORDER

YFS_WORK_ORDER_ACTIVITY

YFS_WORK_ORDER_ACTY_DTL

YFS_WORK_ORDER_HOLD_TYPE

YFS_WORK_ORDER_HOLD_TYPE_LOG

YFS_WORK_ORDER_APPT

YFS_WORK_ORDER_AUDT_DTL

YFS_WORK_ORDER_COMPONENT

YFS_WORK_ORDER_COMP_TAG

YFS_WORK_ORDER_PROD_DEL

YFS_WORK_ORDER_SERVICE_LINE

YFS_WORK_ORDER_STS_AUDIT

YFS_WORK_ORDER_TAG

YFS Audit Purge

This purge removes the YFS_AUDIT table data from the system, which reduces the
load on frequently accessed tables. It purges records in the YFS_AUDIT and the
YFS_AUDIT_HEADER tables that meet the following conditions:
v YFS_AUDIT records that have ‘modifyts' greater than the retention days
specified and the value of table name matches in the YFS_AUDIT table.
v The last modified time is before the lead time (in days) setup.

The way you configure the YFS Audit Purge may have some effect on the
functioning of the Configuration Data Versioning Tool. For more information about
configuration of the Data Versioning Tool, see the Sterling Selling and Fulfillment
Foundation: Configuration Deployment Tool Guide.

When the enterprise extends the entities and sets the extended entities attribute
AuditTable="Y", the extended tables are audited and the audit records are inserted
in the YFS_AUDIT table. In order to clean up the audit records, this purge
transaction can be used.

Any enterprise using the Console must schedule purge transactions.

Chapter 26. Time-Triggered Transaction Reference 419

 Attributes

The following are the attributes for this time-triggered transaction:

Table 375. YFS Audit Purge Attributes
Attribute Value
Base Transaction ID YFS_AUDIT_PURGE
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 376. YFS Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, this value
defaults to Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), this value defaults
to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Production mode. Deletes records from
the regular tables.
v N - Test mode.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
Table Name Required. The table name for which the audit records need to
be purged.
TableType Required in a multischema deployment when YFS_AUDIT
table may exist in multiple schemas.

Valid Values: CONFIGURATION, TRANSACTION, MASTER.

If set to CONFIGURATION, the agent runs for the

YFS_AUDIT records associated with tables that have
TableType as CONFIGURATION; for example,
YFS_Organization, YFS_Ship_Node, and so forth.

If set to TRANSACTION, the agent runs for the YFS_AUDIT

records associated with tables that have TableType as
TRANSACTION; for example, YFS_Order_Header,
YFS_Shipment, and so forth.

Note that the agent would run for all TableTypes that exist in
the same schema as the one passed. For example, if set to
TRANSACTION, the agent would also run for YFS_AUDIT
records associated with tables that have TableType as
MASTER, since they reside in the same schema.

420 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 376. YFS Audit Purge Criteria Parameters (continued)
Parameter Description
ColonyID Required in a multi schema deployment where the
YFS_AUDIT and YFS_AUDIT_HEADER tables may exist in
multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 377. YFS Audit Purge Statistics
Statistic Name Description
NumAuditRecordsPurged Number of audit records purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_AUDIT table that match the criteria values.

Events Raised

None.

Tables Purged

YFS_AUDIT, YFS_AUDIT_HEADER

YFSInventoryOwnershipAudit Purge
This transaction purges all the records from YFS_INV_OWN_TRANSFER_RCD
prior to the lead days specified in criteria parameters.

Attributes

Following are the attributes for this time-triggered transaction:

Table 378. YFSInventoryOwnership Purge Attributes
Attribute Value
Base Transaction ID PURGE_INV_TRANSFR_RECORD
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Chapter 26. Time-Triggered Transaction Reference 421

 Criteria Parameters

Following are the criteria parameters for this transaction:

Table 379. YFSInventoryOwnership Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, this value
defaults to Get, which is the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), this value defaults
to 5000.
EnterpriseCode Optional. The inventory organization for which the
YFSInventoryOwnership Audit Purge needs to run. If not
passed, all the enterprises are monitored.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Production mode. Deletes records from
the regular tables.
v N - Test mode.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds to the
PurgeCode used in the Business Rules Purge Criteria.
Lead Days Number of days before the present date, the agent will purge
the records.
ColonyID Required in a multi schema deployment where the
YFS_INV_OWN_TRANSFER_RCD table may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

None.

Tables Purged

YFS_INV_OWN_TRANSFER_RCD

Password Reset Request Purge

This purge deletes password reset request data from the system.

You can use purge codes pseudo-logic to analyze purges.

Any enterprise using the Console must schedule purge transactions.

422 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 380. Password Reset Request Purge Attributes
Attribute Value
Base Transaction ID None
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 381. Password Reset Request Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
PLT_PWD_REQ table may exist in multiple schemas. Runs the
agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 382. Password Reset Request Purge Statistics
Statistic Name Description
NumPasswordRequestPurged Number of password requests purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the PLT_PWD_REQ table.

Chapter 26. Time-Triggered Transaction Reference 423

 Events Raised

None.

Tables Purged

PLT_PWD_REQ

User Login Failure Purge

This purge deletes data on number of failed login attempts of users from the
system.

You can use purge codes pseudo-logic to analyze purges.

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:

Table 383. User Login Failure Purge Attributes
Attribute Value
Base Transaction ID None
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 384. User Login Failure Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
v Y - Default value. Moves qualifying records from the
regular tables listed under Tables Purged to the
corresponding history tables.
v N - Test mode. Determines the rows that are moved to
history tables without actually moving them.
PurgeCode Required. Cannot be modified. Used for internal calculations,
such as determining retention days. Corresponds with the
PurgeCode used in Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where the
PLT_USER_LOGIN_FAILED table may exist in multiple
schemas. Runs the agent for the colony.

424 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Statistics Tracked

The following statistics are tracked for this transaction:

Table 385. User Login Failure Purge Statistics
Statistic Name Description
NumUserLoginFailPurged Number of failed login attempts purged.

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the PLT_USER_LOGIN_FAILED table.

Events Raised

None.

Tables Purged

PLT_USER_LOGIN_FAILED

Task Queue Syncher Time-Triggered Transactions

Many transactions use the task queue as their work repository. The workflow
manager automatically creates tasks for transactions to handle the next processing
step, as configured in your pipeline.

In some situations, the task queue repository may become out of date. For
example, when reconfiguring the processing pipeline while the pipeline is active,
the queue may go out of synch with the new pipeline configuration.

Alerts that indicate a halt in the lifecycle of a business document may indicate an
outdated task queue repository.

The task queue syncher transactions are designed to update the task queue
repository with the latest list of open tasks to be performed by each transaction,
based on the latest pipeline configuration.

Some of the statistics collected and tracked in Release 9.1 for time-triggered
transactions, monitors, and integration and application servers may change with
the next release.

Load Execution Task Queue Syncher

This transaction synchronizes the task queue for the load execution process type.

You can use the following pseudo-logic to analyze this time-triggered transaction.
If the following conditions are met, a task queue for the load execution process
type is synchronized:
v LOAD_CLOSED_FLAG of Load should not be 'Y'.
v Load should be in a status that is pickable by a transaction in the pipeline.

Chapter 26. Time-Triggered Transaction Reference 425

 v There should not be any Task Q record for the load, transaction combination in
the Task Q table. In this case, the system inserts one Task Q record for this load,
transaction combination with the current database time as the available date.

Attributes

The following are the attributes for this time-triggered transaction:

Table 386. Load Execution Task Queue Syncher Attributes
Attribute Value
Base Transaction ID TASK_QUEUE_SYNCHER_L_D
Base Document Type Load
Base Process Type Load Execution
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 387. Load Execution Task Queue Syncher Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 388. Load Execution Task Queue Syncher Statistics
Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised

None.

Order Delivery Task Queue Syncher

This transaction synchronizes the order delivery process type.

426 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Attributes

The following are the attributes for this time-triggered transaction:

Table 389. Order Delivery Task Queue Syncher Attributes
Attribute Value
Base Transaction ID TASK_QUEUE_SYNCHER_O_D
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 390. Order Delivery Task Queue Syncher Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:
Table 391. Order Delivery Task Queue Syncher Statistics
Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised

None.

Order Fulfillment Task Queue Syncher

This transaction synchronizes the order fulfillment process type.

Chapter 26. Time-Triggered Transaction Reference 427

 Attributes

The following are the attributes for this time-triggered transaction:

Table 392. Order Fulfillment Task Queue Syncher Attributes
Attribute Value
Base Transaction ID TASK_QUEUE_SYNCHER_O_F
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 393. Order Fulfillment Task Queue Syncher Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:
Table 394. Order Fulfillment Task Queue Syncher Statistics
Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised

None.

Order Negotiation Task Queue Syncher

This transaction synchronizes the order negotiation process type.

428 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Attributes

The following are the attributes for this time-triggered transaction:

Table 395. Order Negotiation Task Queue Syncher Attributes
Attribute Value
Base Transaction ID TASK_QUEUE_SYNCHER_O_N
Base Document Type Order
Base Process Type Order Negotiation
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 396. Order Negotiation Task Queue Syncher Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:
Table 397. Order Negotiation Task Queue Syncher Statistics
Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised

None.

Quote Fulfillment Task Queue Syncher

This transaction synchronizes the quote fulfillment process type.

Chapter 26. Time-Triggered Transaction Reference 429

 Attributes

The following are the attributes for this time-triggered transaction:

Table 398. Quote Fulfillment Task Queue Syncher Attributes
Attribute Value
Base Transaction ID TASK_QUEUE_SYNCHER_Q_F
Base Document Type Order
Base Process Type Quote Fulfillment
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 399. Quote Fulfillment Task Queue Syncher Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:
Table 400. Quote Fulfillment Task Queue Syncher Statistics
Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised

None.

Monitors
Monitors are transactions that watch for processes or circumstances that are out of
bounds and then raise alerts.

Some of the statistics collected and tracked in Release 9.1 for time-triggered
transactions, monitors, and integration and application servers may change with
the next release of Sterling Selling and Fulfillment Foundation.

430 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 All Monitors have a CollectPendingJobs criteria parameter. If this parameter is set
to N, the agent does not collect information on the pending jobs for that monitor.
This pending job information is used for monitoring the monitor in the System
Management Console. By default, CollectPendingJobs is set to Y. It can be helpful
to set it to N if one monitor is performing a significant amount of getPendingJobs
queries and the overhead cost is too high.

Availability Monitor
This time-triggered transaction monitors inventory availability. The Availability
Monitor raises global alerts when the available inventory falls below the
configured quantities on the current day, on subsequent days within the ATP time
frame, and on subsequent days outside of the ATP time frame. The quantities for
the days outside of the ATP time frame are determined by the maximum
monitoring days. Unlike the schedule and release transactions, the Availability
Monitor calculates the actual availability beyond the ATP horizon and does not
assume infinite inventory.

Attributes

The following are the attributes for this time-triggered transaction:

Table 401. Availability Monitor Attributes
Attribute Value
Base Transaction ID ATP_MONITOR
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this monitor:

Table 402. Availability Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
MonitorOption Optional. Specifies how to monitor inventory. Valid
values are:
v 1 - current inventory
v 0 - inventory within and outside of the ATP time
frame. This is the default value.
Number of Records To Buffer Optional. Number of records to retrieve and process
at one time. If left blank or specified as 0 (zero), it
defaults to 5000.
InventoryOrganizationCode Optional. Valid owner inventory organization.
Organization to process in this run. If not passed,
all inventory organizations are processed.

Chapter 26. Time-Triggered Transaction Reference 431

 Table 402. Availability Monitor Criteria Parameters (continued)
Parameter Description
CollectPendingJobs If this parameter is set to N, the agent does not
collect information on the pending jobs for this
monitor. This pending job information is used for
monitoring the monitor in the System Management
Console.
Status The negotiation status you are monitoring.
ColonyID Required in a multi schema deployment where a
table may exist in multiple schemas. Runs the agent
for the colony.

Statistics Tracked

None.

Pending Job Count

None.

Events Raised
No events are raised. Individual actions associated with the monitoring rule are
run.

Data published to the actions is AVAILABILITY_MONITOR_dbd.txt.

Exception Monitor
This time-triggered transaction monitors exceptions in your system as noted below.
It monitors the exceptions logged in the system and escalates these exceptions:
v If an exception has not been assigned to a user by a certain time
v If an exception has not been resolved by a certain time
v If the active size of the queue is more than a certain maximum size

In order to prevent re-alerts on exceptions during every run of the Exception

Monitor, specify a re-alert interval through Alert Management in the Applications
Manager. This attribute is associated with a queue and can be configured for each
queue.

Attributes

The following are the attributes for this time-triggered transaction:

Table 403. Exception Monitor Attributes
Attribute Value
Base Transaction ID EXCEPTION_MONITOR
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

432 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for this monitor:

Table 404. Exception Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
QueueID Optional. Defines the Alert Queue into which exceptions from
this monitor are stored.
OrganizationCode Optional. Organization to process in this run. If not passed, all
inventory organizations are processed.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
QueueGroup Optional. Defines the set of Queues for which the exceptions
will be monitored. If both QueueId and QueueGroup are
supplied, QueueId is ignored.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 405. Exception Monitor Statistics
Statistic Name Description
NumInboxProcessed Number of alerts processed.
NumExceededQueueSizeAlerts Number of actions raised when the number of
unresolved alerts exceeds the queue's maximum
active size.
NumUnResolvedAlerts Number of actions raised when the unresolved
alert time of an alert exceeds the queue's resolution
time.
NumUnAssignedAlerts Number of actions raised when the unassigned
alert time of an alert exceeds the queue's
assignment time.

Pending Job Count

None.

Events Raised

No events are raised. Individual actions associated with the monitoring rule are
run.

Chapter 26. Time-Triggered Transaction Reference 433

 Inventory Monitor
This time-triggered transaction monitors inventory availability at ship node level. It
raises alerts at the ship node level when the available inventory exceeds or drops
below the configured quantities.

This monitor uses the OPEN_ORDER demand type to calculate available inventory
at a given node. All supplies assigned to a supply type that is considered by the
OPEN_ORDER demand type are considered. For more information about
configuring inventory supply and demand considerations, refer to the Sterling
Selling and Fulfillment Foundation: Global Inventory Visibility Configuration Guide.

Attributes

The following are the attributes for this time-triggered transaction:

Table 406. Inventory Monitor Attributes
Attribute Value
Base Transaction ID INVENTORY_MONITOR
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called checkAvailability()

Criteria Parameters

The following are the criteria parameters for this monitor:

Table 407. Inventory Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
Number of Records To Buffer Optional. Number of records to retrieve and process
at one time. If left blank or specified as 0 (zero), it
defaults to 5000.
InventoryOrganizationCode Optional. Valid inventory owner organization.
Organization to process in this run. If not passed, all
inventory organizations are processed.
CollectPendingJobs If this parameter is set to N, the agent does not
collect information on the pending jobs for this
monitor. This pending job information is used for
monitoring the monitor in the System Management
Console.
AllowedOverriddenCriteria If this parameter is set to Y, the overriding value for
the agent criteria parameters can be provided in the
command line in the following format when
triggering the agent:
<AgentCriteriaAttribute>
<OverriddenValue>

For more information about passing these attributes,

see the Sterling Selling and Fulfillment Foundation:
Installation Guide

434 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 407. Inventory Monitor Criteria Parameters (continued)
Parameter Description
ShipNodes Optional. Comma-separated list of valid ship nodes
that should be processed in this run. If not passed,
all the ship nodes are processed.
ColonyID Required in a multi schema deployment where a
table may exist in multiple schemas. Runs the agent
for the colony.

Statistics Tracked

None.

Pending Job Count

None.

Events Raised

No events are raised. Individual actions associated with the monitoring rule are
run.

Data published to the actions is <INSTALL_DIR>/xapidocs/api_javadocs/dbd/

INVENTORY_MONITOR_dbd.txt.

Negotiation Monitor
This time-triggered transaction alerts the Enterprise when a negotiation remains in
a particular status for a specific amount of time. This also monitors the negotiation
expiration date. This time-triggered transaction invokes the actions configured
against the negotiation statuses. Configure status Expired (2000) to monitor
negotiation expiration date.

Use this monitor in environments where Order or order release has to go through
a negotiation phase and you want to monitor the negotiation.

Attributes
The following are the attributes for this time-triggered transaction:
Table 408. Negotiation Monitor Attributes
Attribute Value
Base Transaction ID ORD_NEGOTIATION_MONITOR
Base Document Type Order
Base Process Type Order Negotiation
Abstract Transaction No
APIs Called None

Chapter 26. Time-Triggered Transaction Reference 435

 Criteria Parameters

The following are the criteria parameters for this monitor:

Table 409. Negotiation Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Negotiation Monitor needs
to be run. If not passed, then all enterprises are monitored.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
Status The negotiation status you are monitoring.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 410. Negotiation Monitor Statistics
Statistic Name Description
NumNegotiationsProcessed Number of negotiations processed.
NumNegotiationsRequiringAlert Number of negotiations which have at least one
alert raised.

Pending Job Count

None.

Events Raised

This invokes the actions configured against the negotiation statuses.

Key Data - Not Applicable.

Data Published - YCP_getNegotiationDetails_output.xml

Enhanced Order Monitor

The enhanced order monitor enables you to monitor the following situations:
v Milestone x has not been reached y hours before a given date type.
v Milestone x has not been reached within y hours of a given date type.
v Milestone x has not been reached within y hours of milestone z.
v Milestone x has been reached y hours before a given date type.
v Milestone x has been reached within y hours of a given date type.
v Milestone x has been reached within y hours after milestone z.
436 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
v The order has been in status x for y hours.
v Date type x is y hours before date type z.
v Date type x is y hours after date type z.
v The order has been in hold type x for y hours.
v The order has been in hold type x for y hours before date type z.

The order monitor can be configured to monitor the following system date types
for and Purchase Order document types:
v Actual Order Date - Read from the ORDER_DATE column of the
YFS_ORDER_HEADER table.
v Actual Next Iteration Date - Read from the NEXT_ITER_DATE column of the
YFS_ORDER_HEADER table.
v Requested Ship Date - If there is an order release, read from the
REQ_SHIP_DATE column of the YFS_ORDER_RELEASE table. Otherwise, read
from the REQ_SHIP_DATE of the YFS_ORDER_LINE table.
v Expected Ship Date - Read from the EXPECTED_SHIPMENT_DATE column of
the YFS_ORDER_LINE_SCHEDULE table. If it is null, uses the same logic as
Requested Ship Date.
v Actual Ship Date - If the date is before 01/01/2500, read from he
EXPECTED_SHIPMENT_DATE column of the YFS_ORDER_LINE_SCHEDULE
table. If the date is on or after 01/01/2500, this date type is returned as null.
v Requested Delivery Date - If there is a release, read from the
REQ_DELIVERY_DATE column of the YFS_ORDER_RELEASE table.
v Expected Delivery Date - Read from the EXPECTED_DELIVERY_DATE column
of the YFS_ORDER_LINE_SCHEDULE table. If it is null, uses the same logic as
Requested Delivery Date.
v Actual Delivery Date - If the date is before 01/01/2500, read from he
EXPECTED_DELIVERY_DATE column of the YFS_ORDER_LINE_SCHEDULE
table. If the date is on or after 01/01/2500, this date type is returned as null.
For Order Fulfillment, Planned Order Execution, Reverse Logistics, and Purchase
Order Execution pipelines, the system defined dates such as Shipment and
Delivery are stored without a time component. Therefore when you configure a
rule using these dates, all time computations are carried out assuming they are
always 12:00:00 AM.

For more information about milestones, date types, and monitoring rules, refer to
the Sterling Selling and Fulfillment Foundation: Supply Collaboration Configuration
Guide, the Sterling Selling and Fulfillment Foundation: Distributed Order Management
Configuration Guide, and the Sterling Selling and Fulfillment Foundation: Reverse
Logistics Configuration Guide.

If you run the Enhanced Order Monitor, you must configure and run the Close
Order time-triggered transaction in all applicable pipelines. For more information
about the Close Order time-triggered transaction, see “Close Order” on page 291.

The same relog interval is used for all document types.

Chapter 26. Time-Triggered Transaction Reference 437

 Attributes

The following are the attributes for this time-triggered transaction:

Table 411. Enhanced Order Monitor Attributes
Attribute Value
Base Transaction ID ORDER_MONITOR_EX
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this monitor:

Table 412. Enhanced Order Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Order Monitor needs to be
run. If not passed, then all enterprises are monitored.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this monitor:

Table 413. Enhanced Order Monitor Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumAlertsRaised Number of alerts raised.

Pending Job Count

For this transaction the pending job count is the number of open orders with the
value of NEXT_ALERT_TS less than or equal to (<=) the current date.

Events Raised

The Enhance Order Monitor transaction raises the ON_AUTO_CANCEL event, but
does not cancel the order. A service on this event should be configured to cancel
the order.

438 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 414. Events Raised by the Enhanced Order Monitor Transaction
Template
Transaction/Event Key Data Data Published* Support?
ON_AUTO_CANCEL ORDER_ YFS_ORDER_MONITOR_EX.ON_ Yes
MONITOR AUTO_CANCEL.html
_dbd.txt
* These files are located in the following directory:
<INSTALL_DIR>/xapidocs/api_javadocs/XSD/HTML

Monitor Rule's Condition Template

If a monitor rule contains a condition, the <INSTALL_DIR>/repository/xapi/

template/source/smcfs/monitor/ORDER_MONITOR_EX_CONDITION.xml template file is
used to obtain both the order details and the evaluating monitor rule details. See
the provided <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX_CONDITION.xml.sample file for more details.

If the <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX_CONDITION.xml template file does not exist, the
MonitorConsolidation->Order element of the default monitor template, the
<INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX.xml file, is used.

If the default monitor template is used, the MonitorConsolidation->

Order->OrderStatuses-> OrderStatus-> MonitorRule element is ignored and is not
passed into the condition.

Enhanced Quote Monitor

The enhanced quote monitor enables you to monitor the following situations:
v Milestone x has not been reached y hours before a given date type.
v Milestone x has not been reached within y hours of a given date type.
v Milestone x has not been reached within y hours of milestone z.
v Milestone x has been reached y hours before a given date type.
v Milestone x has been reached within y hours of a given date type.
v Milestone x has been reached within y hours after milestone z.
v The order has been in status x for y hours.
v Date type x is y hours before date type z.
v Date type x is y hours after date type z.

The quote monitor can be configured to monitor the following system date types:
v Actual Expiration Date - Read from the EXPIRATION_DATE column of the
YFS_ORDER_HEADER table.

For more information about milestones, date types, and monitoring rules, refer to
the Sterling Selling and Fulfillment Foundation: Distributed Order Management
Configuration Guide.

If you run the Enhanced Quote Monitor, you must configure and run the Close
Order time-triggered transaction in all applicable pipelines. For more information
about the Close Order time-triggered transaction, see “Close Order” on page 291.

Chapter 26. Time-Triggered Transaction Reference 439

 The same relog interval is used for all document types.

Attributes

The following are the attributes for this time-triggered transaction:

Table 415. Enhanced Quote Monitor Attributes
Attribute Value
Transaction ID ORDER_MONITOR_EX.0015
Document Type Quote
Process Type Quote Fulfillment
Abstract Transaction No
APIs Called None

Criteria Parameters
The following are the criteria parameters for this monitor:
Table 416. Enhanced Quote Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Quote Monitor needs to be
run. If not passed, then all enterprises are monitored.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this monitor:

Table 417. Enhanced Quote Monitor Statistics
Statistic Name Description
NumOrdersProcessed Number of quotes processed.
NumAlertsRaised Number of alerts raised.

Pending Job Count

For this transaction the pending job count is the number of open orders with the
value of NEXT_ALERT_TS less than or equal to (<=) the current date.

440 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Events Raised

No events are raised. Individual actions associated with the monitoring rule are
run.

The data published is ORDER_MONITOR_EX.0015.xml.

Monitor Rule's Condition Template

If a monitor rule contains a condition, the <INSTALL_DIR>/repository/xapi/

template/source/smcfs/monitor/ORDER_MONITOR_EX_CONDITION.xml template file is
used to obtain both the order details and the evaluating monitor rule details. See
the provided <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX_CONDITION.xml.sample file for more details.

If the <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX_CONDITION.xml template file does not exist, the
MonitorConsolidation->Order element of the default monitor template, the
<INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX.xml file, is used.

If the default monitor template is used, the MonitorConsolidation->

Order->OrderStatuses-> OrderStatus-> MonitorRule element is ignored and is not
passed into the condition.

Enhanced Return Monitor

The enhanced return monitor allows you to monitor the following situations:
v Milestone x has not been reached y hours before a given date type.
v Milestone x has not been reached within y hours of a given date type.
v Milestone x has not been reached within y hours of milestone z.
v Milestone x has been reached y hours before a given date type.
v Milestone x has been reached within y hours of a given date type.
v Milestone x has been reached within y hours after milestone z.
v The order has been in status x for y hours.
v Date type x is y hours before date type z.
v Date type x is y hours after date type z.

The enhanced return monitor can be configured to monitor the following system
date types:
v Actual Order Date - Read from the ORDER_DATE column of the
YFS_ORDER_HEADER table
v Requested Ship Date - If there is an order release, read from the
REQ_SHIP_DATE column of the YFS_ORDER_RELEASE table. Otherwise, read
from the REQ_SHIP_DATE of the YFS_ORDER_LINE table.
v Expected Ship Date - Read from the EXPECTED_SHIPMENT_DATE column of
the YFS_ORDER_LINE_SCHEDULE table. If it is null, uses the same logic as
Requested Ship Date.
v Actual Ship Date - If the date is before 01/01/2500, read from he
EXPECTED_SHIPMENT_DATE column of the YFS_ORDER_LINE_SCHEDULE
table. If the date is on or after 01/01/2500, this date type is returned as null.

Chapter 26. Time-Triggered Transaction Reference 441

 v Requested Delivery Date - If there is a release, read from the
REQ_DELIVERY_DATE column of the YFS_ORDER_RELEASE table. Otherwise,
read from the REQ_DELIVERY_DATE of the YFS_ORDER_LINE table.
v Expected Delivery Date - Read from the EXPECTED_DELIVERY_DATE column
of the YFS_ORDER_LINE_SCHEDULE table. If it is null, uses the same logic as
Requested Delivery Date.
v Actual Delivery Date - If the date is before 01/01/2500, read from he
EXPECTED_DELIVERY_DATE column of the YFS_ORDER_LINE_SCHEDULE
table. If the date is on or after 01/01/2500, this date type is returned as null.
For Order Fulfillment, Planned Order Execution, Reverse Logistics, and Purchase
Order Execution pipelines, the system defined dates such as Shipment and
Delivery are stored without a time component. Therefore when you configure a
rule using these dates, all time computations are carried out assuming they are
always 12:00:00 AM.

For more information about milestones, date types, and monitoring rules, refer to
the Sterling Selling and Fulfillment Foundation: Supply Collaboration Configuration
Guide, the Sterling Selling and Fulfillment Foundation: Distributed Order Management
Configuration Guide, and the Sterling Selling and Fulfillment Foundation: Reverse
Logistics Configuration Guide.

If you run the Enhanced Return Monitor, you must configure and run the Close
Order time-triggered transaction in all applicable pipelines. For more information
about the Close Order time-triggered transaction, see “Close Order” on page 291.

The same relog interval is used for all document types.

Attributes

The following are the attributes for this time-triggered transaction:

Table 418. Enhanced Order Monitor Attributes
Attribute Value
Base Transaction ID RETURN_MONITOR_EX
Base Document Type Return Order
Base Process Type Reverse Logistics
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this monitor:

Table 419. Enhanced Order Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Order Monitor needs to be
run. If not passed, then all enterprises are monitored.

442 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 419. Enhanced Order Monitor Criteria Parameters (continued)
Parameter Description
FromStatus Optional. Statuses to monitor that are greater than or equal to
the passed status.
ToStatus Optional. Statuses to monitor that are less than or equal to the
passed status.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this monitor:

Table 420. Enhanced Order Monitor Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumAlertsRaised Number of alerts raised.

Pending Job Count

For this transaction the pending job count is the number of open orders with the
value of NEXT_ALERT_TS less than or equal to (<=) the current date.

Events Raised

No events are raised. Individual actions associated with the monitoring rule are
run.

The data published is RETURN_MONITOR_EX.xml.

Monitor Rule's Condition Template

If a monitor rule contains a condition, the <INSTALL_DIR>/repository/xapi/

template/source/smcfs/monitor/ORDER_MONITOR_EX_CONDITION.xml template file is
used to obtain both the order details and the evaluating monitor rule details. See
the provided <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX_CONDITION.xml.sample file for more details.

If the <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX_CONDITION.xml template file does not exist, the
MonitorConsolidation->Order element of the default monitor template, the
<INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
ORDER_MONITOR_EX.xml file, is used.

If the default monitor template is used, the MonitorConsolidation-> Order->

OrderStatuses-> OrderStatus-> MonitorRule element is ignored and is not passed
into the condition.

Chapter 26. Time-Triggered Transaction Reference 443

 Real-time Availability Monitor
The Real-time Availability Monitor time-triggered transaction monitors the
inventory availability of inventory items. It can be configured to raise the
REALTIME_AVAILABILITY_CHANGE event when the inventory level for a given item
changes between the thresholds defined in the Applications Manager in the Global
Inventory Visibility module.

It can be run in three modes:

v Activity Based: Raises the event in real time every time an item goes above or
below one of the thresholds.
v Quick Sync: Re-sends the most recently published inventory availability
information.
v Full Sync: Monitors all of the items regardless of activity and publishes the
inventory information for all of the items.

In all cases, the percentage of future inventory availability is used for considering
inventory availability at retrieval time. For more information about future
inventory availability, see the Sterling Selling and Fulfillment Foundation: Global
Inventory Visibility Configuration Guide.

Demand of type OPEN_ORDER is used in getting the inventory availability

picture. If sourcing is maintained, the Real-time Availability Monitor can either
monitor the total availability across nodes or the availability at individual nodes.
Inventory items without an Availability Monitor rule, or with a rule that is
disabled, are unable to be processed by this time-triggered transaction.

If item information is not available on the system, such as when inventory between
databases is not in sync, default inventory monitor rules can be configured so that
monitoring will proceed. Setting these default inventory monitor rules also ensures
that inventory activity will be recorded when the system is running in
activity-based mode.

When monitoring the total availability across nodes, the Real-time Availability
Monitor monitors all nodes in the default distribution group of the inventory
organization.

When monitoring the availability at individual nodes, the Real-time Availability

Monitor monitors all nodes in a specified distribution group. For more information
about configuring distribution groups and node-level inventory monitoring, see the
Sterling Selling and Fulfillment Foundation: Global Inventory Visibility Configuration
Guide.

If configured, the Real-time Availability Monitor also considers the onhand and
future inventory availability safety factor during monitoring. For more information
about the inventory availability safety factors and the findInventory() API, see the
Sterling Selling and Fulfillment Foundation: Global Inventory Visibility Configuration
Guide and the Sterling Selling and Fulfillment Foundation: Javadocs.

When the onhand quantity is greater than the configured low threshold, the
REALTIME_ONHAND alert type is raised, and the alert level is based on the onhand
quantity.

When the onhand quantity falls below the configured low threshold, the
REALTIME_FUTURE_MAX alert type is raised, and the alert level is based on the total

444 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
future supply (FutureAvailableQuantity) with FirstFutureAvailableDate set to
the date on which the first future supply is available, and FutureAvailableDate set
to the date on which the maximum future supply is available.

When the Real-time Availability Monitor is run in activity based mode, changing
one of the thresholds of an inventory item does not cause the agent to monitor it
unless there is a change in activity. For example, if item I with available quantity
700 is being monitored with a low threshold of 600, and the low threshold is then
changed to 1000, no event is published unless there is change in I's activity. In
order to ensure that in such a scenario I is not left unmonitored, call the
createInventoryActivity API when changing a monitoring rule for an item.

Computing and Publishing the Maximum Ship Dates for Available

Quantities

If enabled, the Real-Time Availability Monitor computes and publishes a matrix of

maximum ship dates for available quantities, which includes the following
information:
v Available Quantity - Refers to the number of items that are available for
shipping on the maximum ship date.
v Maximum Ship Date - Refers to the time and date when available quantities are
shipped by.
v Effective Until Date - Refers to the last time and date that an order can be
placed if it is to be shipped by the maximum ship date.

The matrix is published to the REALTIME_AVAILABILITY_CHANGE event and stored in

XML format in the AVAILABILITY_INFO field of the YFS_INVENTORY_ALERTS
table. The monitorItemAvailability() API can be used to update the matrix. For
more information about the monitorItemAvailability() API, refer to the Sterling
Selling and Fulfillment Foundation: Javadocs.

For information about using the Real-Time Availability Monitor to calculate and
publish a matrix of maximum ship dates for available quantities, refer to the
chapter on Configuring Inventory Rules in the Sterling Selling and Fulfillment
Foundation: Global Inventory Visibility Configuration Guide.

Computing the Maximum Ship Date

The maximum ship date is equal to the maximum expected ship date across all the
nodes being considered. For information about calculating the expected ship date,
refer to the Sterling Selling and Fulfillment Foundation: Product Concepts Guide.
Additionally, the following options can be configured as part of the maximum ship
date:
v Maximum Ship Date Time
v Number of Days To Offset the Maximum Ship Date

Maximum Ship Date Time - If you specify a time for the maximum ship date, the
Real-Time Availability Monitor calculates the maximum ship date, as described
earlier, and then applies the following logic:
v If the time specified for the maximum ship date occurs later in the day than the
calculated ship date, the Real-Time Availability Monitor resets the maximum
ship date to the specified time. For example, if the Real-Time Availability

Chapter 26. Time-Triggered Transaction Reference 445

 Monitor calculates the maximum ship date to be 10 a.m. on July 21 and
Maximum Ship Date Time is set to 11 a.m., the maximum ship date is
recalculated to be 11 a.m. on July 21.
v If the time specified for the maximum ship date occurs earlier in the day than
the calculated ship date, the maximum ship date is incremented by one day and
reset to the specified time. For example, if the maximum ship date is calculated
to be 11 a.m. on July 21 and Maximum Ship Date Time is set to 10 a.m., the
Real-Time Availability Monitor recalculates the maximum ship date to be 10 a.m.
on July 22.

Number of Days To Offset the Maximum Ship Date - You can specify a number
of days to offset the maximum ship date. The Real-Time Availability Monitor
calculates the maximum ship date, including the maximum ship date time, and
then increments the maximum ship date by the number of days specified by the
offset number. For example, if the Real-Time Availability Monitor has calculated a
maximum ship date to be 11 a.m. on July 19 and Number of Days to Offset the
Maximum Ship Date is set to 1, the maximum ship date is recalculated to be 11
a.m. on July 20.

Calculating the Effective Until Date

The Real-Time Availability Monitor calculates the effective until date by subtracting
the node's minimum notification time from the maximum ship date and then
adjusting for the preceding notification time on the node's notification schedule.
The effective until date is only valid while supplies are available at the node.

For example, if an available quantity has a maximum ship date of 4 p.m. on July
19 and the shipping node has the following notification schedule, the effective until
date is calculated to be 3 p.m. on July 18:
v 24-hour minimum notification time
v 3 p.m. and 5 p.m. notification times

In this example, the effective until date is calculated by first subtracting the
24-hour minimum notification time from the 4 p.m., July 19 maximum ship date
and then adjusting for the 3 p.m. notification time. If an order is not placed before
3 p.m. on July 18, the July 19 maximum ship date is no longer available because
the node must be notified at least 24 hours before shipping the items, by 4 p.m. on
July 19. Also, if a different order reduces available quantities at the node before the
order is placed at 3 p.m. on July 19, the maximum ship date cannot be met and the
effective until date becomes invalid.

Additionally, offset days are not considered when calculating the effective until
date. Thus, if the maximum ship date in the earlier example is updated to 4 p.m.
July 20 by setting Number of Days to Offset Maximum Ship Date to 1, the effective
until date is updated to 3 p.m., July 19.

Example 1: Computing Maximum Ship Dates for Available Quantities

Node 1 has the following supply picture:

v 24-hour minimum notification time
v Notification times are 3 p.m. and 5 p.m. daily
v Work Days are 24 hours-a-day, 7 days-a-week

Node 2 has the following supply picture:

446 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
v 48-hour minimum notification time
v Notification times are 2 p.m. and 5 p.m. daily
v Work Days are 24 hours-a-day, 7 days-a-week

The following table shows the availability matrix for Node 1 and Node 2, where
the following conditions are true:
v Current date is July 19
v Estimated time of arrival (ETA) equals the date that the quantity is expected to
be available at the node
v Maximum Ship Date Time is set to 4 p.m.
v Number of Days to Offset the Maximum Ship Date is set to 0
Table 421. Example: Availability Matrix of Maximum Ship Dates for Available Quantities
ETA Quantity Maximum Ship Date Effective Until Date
Node 1
7/19/2010 80 4 p.m., July 20 3 p.m., July 19
7/22/2010 10 4 p.m. July 22 3 p.m., July 21
Node 2
7/19/2010 100 4 p.m., July 21 2 p.m., July 19
7/22/2010 20 4 p.m., July 22 2 p.m., July 20

In this example, July 19 is the ETA for a quantity of 80 items at Node 1 and 100
items at Node 2. The matrix shows a 4 p.m., July 20 maximum ship date for the 80
available items from Node 1 and a 4 p.m., July 21 maximum ship date for the 100
available items from Node 2. For Node 1, the maximum ship date is calculated by
adding the 24-hour minimum notification time to the 3 p.m. notification time on
July 19, and then adjusting for the 4 p.m. maximum ship date time. The effective
until date is calculated by subtracting the 24-hour minimum notification time from
the maximum ship date and then adjusting for the 3 p.m. notification time. For
Node 2, the maximum ship date and effective until date are calculated similarly,
with the exception that Node 2 has a 48-hour minimum notification time and a 2
p.m. notification time.

Additionally, the example shows July 22 as the ETA for a quantity of 10 items at
Node 1 and 20 items at Node 2. The maximum ship date is 4 p.m., July 22 for the
10 items at Node 1 and 4 p.m., July 22 for the 20 items at Node 2. If the difference
between the current date and the ETA is greater than the node's minimum
notification time, the ETA date is used for the maximum ship date. In this example,
the difference between the current date, July 19, and the ETA date, July 22, is
greater than the minimum notification times at both nodes. Thus, the maximum
ship date is set to the maximum ship date time on the ETA date at the nodes,
which is 4 p.m., July 22 at Node 1 and 4 p.m., July 22 at Node 2.

Example 2: Computing the Maximum Ship Date at Nodes With Non-Working

Days

The following table displays the availability matrix for Node 1 and Node 2 when
the supply picture and conditions from Example 1 are applied. However, in this
scenario, July 19 and July 20 are nonworking days.

Chapter 26. Time-Triggered Transaction Reference 447

 Table 422. Example: Availability Matrix for Nodes with Non-Working Days
ETA Quantity Maximum Ship Date Effective Until Date
Node 1
7/19/2010 80 4 p.m., July 22 3 p.m., July 21
Node 2
7/19/2010 100 4 p.m., July 23 2 p.m., July 21

In the example, Node 1 has an available quantity of 80 on July 19 and a minimum

notification time of 24 hours. Because July 19 and July 20 are nonworking days at
Node 1, the 80 items are not considered available until July 21. In this case, the
maximum ship date is calculated by adding the 24-hour minimum notification time
to July 21 and adjusted for the 4 p.m. maximum ship date time. For Node 2, the
maximum ship date is calculated similarly, with the exception of a 48-hour
minimum notification time.

Example 3: Offsetting the Maximum Ship Date

The following table displays the availability matrix for Node 1 and Node 2 when
the supply picture and conditions from Example 2 are applied. However, in this
scenario, Number of Days To Offset the Maximum Ship Date is set to 1.
Table 423. Example: Availability Matrix When Offsetting the Maximum Ship Date
ETA Quantity Maximum Ship Date Effective Until Date
Node 1
7/19/2010 80 4 p.m., July 23 3 p.m., July 22
Node 2
7/19/2010 100 4 p.m., July 24 2 p.m., July 22

In the example, the maximum ship dates for Nodes 1 and 2 are calculated similarly
to Example 2. However, the maximum ship dates are incremented by 1 because
Number of Days to Offset the Maximum Ship Date is set to 1. In this example, the
effective until date is set to 3 p.m., July 22 for Node 1 and 2 p.m., July 22 for Node
2 because the offset days are not considered when calculating the effective until
date.

Attributes

The following are the attributes for this time-triggered transaction:

Table 424. Real-time Availability Monitor Attributes
Attribute Value
Base Transaction ID REALTIME_ATP_MONITOR
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called FindInventory

448 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for this monitor:

Table 425. Real-time Availability Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
Number of Records To Buffer Optional. Number of records to retrieve and process
at one time. If left blank or specified as 0 (zero), it
defaults to 5000.
InventoryOrganizationCode Inventory organization code to use when
MonitorOption is passed as 3. The inventory
organization has to be an enterprise.

If this is not passed, the monitor runs for all

inventory organizations.
MonitorOption 1 - Activity Based (Monitor based on distinct
inventory items in YFS_INVENTORY_ACTIVITY table).

2 – Quick Sync (Re-raise event to publish

information from the YFS_INVENTORY_ALERTS
table).

3 – Full Sync (Monitor based on all inventory items

maintained by the inventory organization provided.
If no InventoryOrganizationCode is provided, all
inventory item is monitored).

If not provided, default value is 1.

ItemStatuses List of valid statuses of items to be processed.
Statuses must be separated by a , for example
3000,2000. This is only used when MonitorOption is
passed as 2 or 3. If provided, only items with the
matching statuses is monitored.
FromAlertTimestamp This is only used when MonitorOption is passed as
2. If provided, the agent raises the
REALTIME_AVAILABILITY_CHANGE event to
republish inventory availability information which
was published between the time that the agent
started and FromAlertTimestamp.

If not provided, all inventory availability

information published before the time that the agent
started is republished.
AllowedOverriddenCriteria If set to Y, the overridden value for the agent criteria
parameters can be provided at the command line
while triggering the agent in the following format:
<AgentCriteriaAttribute> <OverriddenValue>

For more information about passing these attributes,

see the Sterling Selling and Fulfillment Foundation:
Installation Guide.

Chapter 26. Time-Triggered Transaction Reference 449

 Table 425. Real-time Availability Monitor Criteria Parameters (continued)
Parameter Description
FromLastNumberOfHours This is only used when MonitorOption is passed as
2 to calculate the FromAlertTimestamp parameter, if
necessary.

If the FromAlertTimestamp parameter is not

provided, it is calculated as current timestamp
minus FromLastNumberOfHours.
CollectPendingJobs If this parameter is set to N, the agent does not
collect information on the pending jobs for this
monitor. This pending job information is used for
monitoring the monitor in the System Management
Console.
RaiseEventsOnAllAvailability When set to Y,
Changes REALTIME_AVAILABILITY_CHANGE event is
raised on all availability changes regardless of
whether availability exceeds or falls below specified
thresholds. This is only used when MonitorOption is
passed as 1. Valid values: Y or N. Default value: N.
ColonyID Required in a multi schema deployment where a
table may exist in multiple schemas. Runs the agent
for the colony.

Note: Distribution Rule Id is used for internal purposes and should be left blank.

Statistics Tracked

None.

Pending Job Count

None.

Events Raised

The following events are raised by this time-triggered transaction:

Table 426. Events Raised by the Realtime Availability Monitor Transaction
Template
Transaction/Event Key Data Data Published* Support?
REALTIME_ None YFS_REALTIME_ATP_MONITOR. Yes
AVAILABILITY_ REALTIME_AVAILABILITY
CHANGE _CHANGE.html
* These files are located in the following directory:
<INSTALL_DIR>/xapidocs/api_javadocs/XSD/HTML

Although described as 'real time', availability changes may not be triggered

immediately as inventory changes occur if the agent has a backlog of messages to
process. Furthermore, this monitor exists as a time-triggered transaction, and thus
monitors availability of inventory items only when the monitor is triggered based
on the configured runtime properties.

450 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Shipment Monitor
This time-triggered transaction reports the states of a shipment, based on rules in
the YFS_MONITOR_RULE table. This transaction enables you to monitor the
following situations:
v If the Shipment has been in a status for more than a specified amount of time.
v If a specified date that is associated with the shipment is:
– n hours before another specified date
– n hours after another specified date
– n hours not before another specified date
– n hours not after another specified date
v If the Shipment has been in a hold type for a specified amount of time.
v If the Shipment has been in a hold type for n hours before a specified date.

Monitoring rules can be configured for shipment's origin and destination points.

Monitoring rules cannot be configured for a shipment's intermediate pickup and

drop off points. A shipment has intermediate pickup or drop off only if it has
multiple pickup or drop off points. For example, a shipment has more than one
loads carrying it. The shipment status on first load deposit, second load deposit,
and so forth cannot be monitored. Once the last load deposits the shipment at its
destination, then the shipment status can be marked and monitored.

This is not a pipeline transaction. It also does not work from the task queue.

For more information about milestones, date types, and monitoring rules, see the
Sterling Selling and Fulfillment Foundation: Supply Collaboration Configuration Guide,
the Sterling Selling and Fulfillment Foundation: Distributed Order Management
Configuration Guide, and the Sterling Selling and Fulfillment Foundation: Reverse
Logistics Configuration Guide.

Attributes

The following are the attributes for this time-triggered transaction:

Table 427. Shipment Monitor Attributes
Attribute Value
Base Transaction ID SHIPMENT_MONITOR
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None

Criteria Parameters

The following are the criteria parameters for this monitor:

Table 428. Shipment Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

Chapter 26. Time-Triggered Transaction Reference 451

 Table 428. Shipment Monitor Criteria Parameters (continued)
Parameter Description
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Shipment Monitor needs to
be run. If not passed, then all enterprises are monitored.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This pending
job information is used for monitoring the monitor in the
System Management Console.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 429. Shipment Monitor Statistics
Statistic Name Description
NumShipmentsMonitored Number of shipments monitored.

Pending Job Count

For this transaction the pending job count is the number of open shipments with
the value of NEXT_ALERT_TS less than or equal to (<=) the current date.

Events Raised
This invokes the actions configured against shipment statuses.

Key Data - Not Applicable.

Data Published - SHIPMENT_MONITOR.xml

Monitor Rule's Condition Template

If a monitor rule contains a condition, the <INSTALL_DIR>/repository/xapi/

template/source/smcfs/monitor/SHIPMENT_MONITOR_CONDITION.xml template file is
used to obtain the shipment details and the evaluating monitor rule details. See the
provided <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
SHIPMENT_MONITOR_CONDITION.xml.sample file for more details.

If the <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
SHIPMENT_MONITOR_CONDITION.xml template file does not exist, the
MonitorConsolidation->Shipment element of the default monitor template, the
<INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
SHIPMENT_MONITOR.xml file, is used.

If the default monitor template is used, the MonitorConsolidation->Shipment->

MonitorRule element is ignored and is not passed into the condition.

452 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Work Order Monitor
This time-triggered transaction alerts the enterprise when a work order remains in
a particular state or hold type for a specific amount of time.

Use this monitor to track how long work orders stay in a particular state or hold
type.

Attributes

The following are the attributes for this time-triggered transaction:

Table 430. Work Order Monitor Attributes
Attribute Value
Base Transaction ID WORK_ORDER_MONITOR
Base Document Type Work Order
Base Process Type VAS Process
Abstract Transaction No

Criteria Parameters

The following are the criteria parameters for this monitor:

Table 431. Work Order Monitor Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Work Order Monitor
needs to be run. If not passed, then all enterprises are
monitored.
Node Optional. Node for which the Work Order Monitor needs to
be run. If not passed, then all nodes are monitored.
CollectPendingJobs If this parameter is set to N, the agent does not collect
information on the pending jobs for this monitor. This
pending job information is used for monitoring the monitor
in the System Management Console.
ColonyID Required in a multi schema deployment where a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 432. Work Order Monitor Statistics
Statistic Name Description
NumWorkOrdersMonitored Number of work orders monitored.

Chapter 26. Time-Triggered Transaction Reference 453

 Pending Job Count

For this transaction the pending job count is the number of Work Orders that are
monitored, where NEXT_ALERT_TS less than or equal to (<=) current date.

Events Raised

No events are raised. Individual actions associated with the monitoring rule are
run. Data published to the actions is workOrder_dbd.txt.

Monitor Rule's Condition Template

If a monitor rule contains a condition, the <INSTALL_DIR>/repository/xapi/

template/source/smcfs/monitor/monitor/WORK_ORDER_MONITOR_CONDITION.xml
template file is used to obtain the work order details and the evaluating monitor
rule details. See the provided <INSTALL_DIR>/repository/xapi/template/source/
smcfs/monitor/WORK_ORDER_MONITOR_CONDITION.xml.sample file for more details.

If the <INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
WORK_ORDER_MONITOR_CONDITION.xml template file does not exist, the
MonitorConsolidation->WorkOrder element of the default monitor template, the
<INSTALL_DIR>/repository/xapi/template/source/smcfs/monitor/
WORK_ORDER_MONITOR.xml file, is used.

If the default monitor template is used, the MonitorConsolidation-> WorkOrder->

MonitorRule element is ignored and is not passed into the condition.

454 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 27. Order Modification Types
Order Modification Types
The following are the default order modification types and their associated
modification levels:
Table 433. Order Document Modification Types
Modification Types Description Modification Levels
Add Component A bundle component can be Line
added to an order document
line.
Add Instruction An instruction can be added to Header
an order document's header,
line, or shipment. Line

For example, you may want to Shipment

add an instruction stating that
a line item needs to be gift Receipt
wrapped.
Add Line A line can be added to an order Header
document's header, release,
negotiation, or shipment. Release

Important: When adding a line Negotiation

to an order, the Add Line
modification type does not get Shipment
audited, if the prices are not
configured.
Add Line Relationship A line relationship type can be Line
added to an order document
line.
Add Note A note can be added to an Header
order document's header or
release. Release
Add Option An option can be added to a Line
provided service or delivery
service order line.
Add Product Item For A product item for a Line
Stand Alone Service Line standalone service line can be
added to an order document
line.
Add Quantity Additional quantity can be Line
added to an order document's
line or release line. Release Line

© Copyright IBM Corp. 1999, 2012 455

 Table 433. Order Document Modification Types (continued)
Modification Types Description Modification Levels
Add/Remove Additional A date type used for shipment Shipment
Date monitoring (such as, Ship Date)
can either be added to or
removed from an order
document's shipment.

For example, you may want to

add an additional delivery date
used by your organization to
monitor shipments.
Add/Remove Charge A charge can either be added Shipment
to or removed from an order
document's shipment.

For example, if a shipment

contains hazardous materials
and your organization has an
extra shipping charge for
shipment of hazardous
materials, you can add an extra
charge to the shipment.
Add/Remove Container A container can either be Shipment
added to or removed from an
order document's shipment.
Associate Delivery Line When the delivery method of a Line
With Product Line product order line is delivery,
the product line can be
associated to a delivery line to
indicate how the product line is
delivered.
Associate Product Line When the delivery method of a Line
With Delivery Line product order line is delivery,
the product line can be
associated to a delivery line to
indicate how the product line is
delivered.
Associate Product Line A provided service can be Line
With Service Line associated to a product line to
indicate that the service is
somehow dependent on the
product line.
Associate Service Line A provided service can be Line
With Product Line associated to a product line to
indicate that the service is
somehow dependent on the
product line.
Attribute Modification A receipts attributes can be Receipt
modified. For a list of attributes
that can be modified, see the
changeReceipt API in the
Sterling Selling and Fulfillment
Foundation: Javadocs.

456 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 433. Order Document Modification Types (continued)
Modification Types Description Modification Levels
Backorder An order document's line, Line
release, or release line can be
backordered. Release

For example, if an order is Release Line

released to a node and the
node does not have enough
quantity to fulfill the order,
they can backorder the release.
Cancel An order document's header, Header
line, release, or release line can
be manually cancelled from the Line
Application Consoles.
Release

Release Line
Change Additional A modification can be made to Header
Address the fields of any additional
addresses that may have been Line
configured for an order
document's header or line.
Change Answer Set A modification can be made to Header
an answer associated with an
order document header.
Change Appointment Appointments can be taken and Line
changed for delivery and
provided service order lines.
Change Bill To A modification can be made to Header
any bill to address field
associated with an order Release
document's header or release.
Change Bundle Definition The existing bundle definition Line
can be replaced with the new
bundle definition.

For example, you can change

an existing bundle definition by
passing the
'REPLACE_BUNDLE' action to
the bundle parent. All the
components passed remain
with order and as well as with
bundle. All remaining
components are deleted.

Important: In addition to this,

the modification type DELETE
is executed on all the
components getting removed
and modification type
ADD_LINE is executed on
components getting added.
This modification is applied to
bundle parent's immediate
components.

Chapter 27. Order Modification Types 457

 Table 433. Order Document Modification Types (continued)
Modification Types Description Modification Levels
Change Bundle Parent A modification can be made to Line
the bundle parent associated
with an order document line.
Change Buyer The buyer organization Header
Organization associated with an order
document's header can be
changed. This modification can
only be made in the Order
Detail screen.
Change Carrier A modification can be made to Header
the Carrier/Service or Carrier
field associated with an order Line
document's header, line, or
release. Release

For example, you can change

the carrier and service from
UPS Next Day Air to FedEx
Express® Saver Pack.

Important: If you want this

modification type to be
allowed, Change Carrier
Service Code must also be
allowed.
Change Carrier Account A modification can be made to Header
No the Carrier Account # field
associated with an order Line
document's header, line, or
release. Release

Change Carrier Service A modification can be made to Header

Code the Carrier/Service field
associated with an order Line
document's header, line, or
release. Release

For example, you can change

the carrier and service from
UPS Next Day Air to FedEx
Express Saver Pack.

Important: If you want this

modification type to be
allowed, Change Carrier must
also be allowed.
Change Contact Info A modification can be made Header
the fields for the Buyer/Seller
contact information associated
with an order document's
header.
Change Cost A adjustment can be made to Release
the Unit Cost field associated
with an order document's Release Line
release or release line.

458 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 433. Order Document Modification Types (continued)
Modification Types Description Modification Levels
Change Currency The currency associated with Header
an order document's header
can be changed. Upon a change
to the currency, Sterling Selling
and Fulfillment Foundation
automatically reprices the
order. However, preexisting
charges and taxes have to be
converted manually.
Change Custom Date A modification can be made to Header
the date type fields used for
order monitoring associated Line
with an order document's
header, line, or release. Release

The following custom date

fields can be modified when
this modification type is
allowed:
v Requested
v Expected
v Actual

For example, if there is a delay

in a release's processing, you
can change the expected
delivery date.
Change Delivery Code A modification can be made to Header
the Delivery Code field
associated with an order Line
document's header, line, or
release. Release

For example, if you want to

indicate that an order's freight
charges are paid by the
Enterprise, you can choose the
ENTERPRISE delivery code.
Change Delivery Method A product order line indicates Line
how the product id sent to its
final destination. It can be
changed to SHIP, DELIVER, or
PICKUP.
Change Freight Terms A modification can be made to Header
the Freight Terms field
associated with an order Line
document's header, line, or
release. Release

For example, you can change

an order line's freight term
from CIF (Cost Insurance and
Freight) to CFR (Cost and
Freight).

Chapter 27. Order Modification Types 459

 Table 433. Order Document Modification Types (continued)
Modification Types Description Modification Levels
Change Gift Flag A modification can be made to Line
the Gift Flag field associated
with an order document line.
Change Gift Wrap A modification can be made to Line
the Gift Wrap fields associated
with an order document line.
Change Instruction A modification can be made to Header
an instruction associated with
an order document's header, Line
line, or shipment.
Shipment
The following instruction fields
can be modified when this Receipt
modification type is allowed:
v Instruction Type
v Text
v URL
Change Inventory A modification can be made to Line
Attributes inventory attributes associated
with an order document line.
Change Item Description A modification can be made to Line
the Description field of an item
associated with an order
document's line.
Change Iteration A modification can be made to Header
the iteration fields associated
with an order document's Line
header or line.

For example, you can change

the next iteration date of a
master order to a time in the
future.
Change Level of Service A modification can be made to Header
the Level of Service fields
associated with an order Line
document's header or line.
Change Mark For A modification can be made to Header
the fields of the mark for
address associated with an Line
order document's header, line,
or release. Release

Change Order Name A modification can be made to Header

the Order Name field
associated with an order
document's header.

460 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 433. Order Document Modification Types (continued)
Modification Types Description Modification Levels
Change Other Attributes A modification can be made to Header
fields that do not have system
or user-defined modification Line
types associated with them.
Release

Negotiation

Negotiation Line

Shipment
Change Other Not used in this version. Shipment
Relationships
Change Payment Method A modification can be made to Header
the Payment Type field
associated with an order Release
document's header or release.

For example, you can change

an order's payment type from
Check to Credit Card.
Change Payment Rule ID The Payment Rule field Header
associated with an order
document's header can be
changed.

For example, you can change

the payment rule from the
default rule to a custom rule
that pertains to the order.
Change Payment Status The Payment Status field Header
associated with an order
document's header can be
changed.

For example, you can change

an order's payment status from
Await Authorization to
Authorized.
Change Pipeline A change can be made to the Line
pipeline associated with an
order document line.
Change Price Charges can be added to an Header
order document's header or
line. Line
Change Promotion An order document's Header
promotion can be changed at
the header or line. Promotions Line
include coupons and manual
pricing rules.

Chapter 27. Order Modification Types 461

 Table 433. Order Document Modification Types (continued)
Modification Types Description Modification Levels
Change Receiving Node The Receiving Node field Line
associated with an order
document's line can be
changed.

For example, if for some reason

it has been determined that an
order line's original receiving
node cannot receive the line,
you can change it to another
receiving node.
Change References A modification can be made to Header
the name/value pair in the
YFS_REFERENCE_TABLE Line
using APIs.
Change Requested Ship A modification can be made to Header
Date the Requested Ship Date
associated with an order Line
document's header, line, or
release. Release

For example, if the customer

decides they want an order to
be shipped on a date later than
what they originally requested,
you can change the requested
shipment date.
Change Schedule A modification can be made to Header
schedule attributes, such as
expected ship date, expected Line
delivery date, and lot number,
associated with an order Release
document's header, line,
Release Line
release, or release line.
Change Schedule Rule ID A modification can be made to Header
the schedule rule associated
with an order document's
header. This allows the user to
select the scheduling rule they
want to use for the order from
the Scheduling Rule drop-down
list on the Schedule Order
popup window.
Change Seller The seller organization Header
Organization associated with an order
document's header can be
changed. This modification can
only be made in the Order
Detail screen.

462 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 433. Order Document Modification Types (continued)
Modification Types Description Modification Levels
Change Ship Node The Ship Node field associated Header
with an order document's
header or line can be changed. Line

For example, if for some reason

it has been determined that an
order line's original ship node
cannot handle the order line,
you can change it to another
node.
Change Ship To A modification can be made to Header
the fields of a ship to address
associated with an order Line
document's header, line, or
release. Release

Change Status The order status (such as, Header

Created) associated with an
order document's header, line, Line
release, release line, or
negotiation can be changed. Release

Only order statuses existing in Release Line

process type repositories are
Negotiation
affected by this modification
type. Actions performed
against order documents, such
as putting an order on hold or
canceling an order, are not
impacted.
Change Tax A modification can be made to Header
the Tax Amount associated
with an order document's Line
header or line.
Delete An order line can be deleted. Line
Delete Shipment An order document's shipment Shipment
can be deleted.
Expiration Date A modification can be made to Negotiation
the expiration date associated
with an order document's
negotiation.
Hold An order document's header or Header
release can be manually put on
hold. Release

For example, you may want to

perform a security check on a
particular Buyer, you can then
place the order on hold until
you clear the necessary
information before the order is
scheduled.

Chapter 27. Order Modification Types 463

 Table 433. Order Document Modification Types (continued)
Modification Types Description Modification Levels
Hold Type Modifications A modification can be made to Header
the Hold Type fields associated
with an order document's Line
header or line.
Include In Load An order document's shipment Shipment
can be included in a load
document.
Include Shipment in An order document's shipment Shipment
Delivery Plan can be included in a delivery
plan.
Pack Shipment An order document's shipment Shipment
can be packed.
Price Program The price program associated Header
with an order document's
header can be changed.
Receipt Complete An order document's receipt Receipt
can be marked as complete.
Release from Hold An order document's header Header
can be released from hold.
Remove Component A bundle component can be Line
removed from an order
document line.
Remove Delivery Line Delivery lines can be removed Line
From Product Line from product order lines.
Association
Remove Order Line A line can be removed from an Header
order document's header, line,
and shipment. Line

Shipment
Remove Option Options can be removed from Line
delivery and provided services.
Remove Product Item For A product item for a stand Line
Stand Alone Service Line alone service line can be
removed from an order
document line.
Remove Product Line Product lines can be removed Line
From Delivery Line from delivery lines.
Association
Remove Product Line Product lines can be removed Line
From Service Line from provided service order
Association lines.
Remove Promotion An order document's Header
promotion can be removed
from the header or line. Line
Promotions include coupons
and manual pricing rules.
Remove Service Line Provided service lines can be Line
From Product Line removed from product order
Association lines.

464 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 433. Order Document Modification Types (continued)
Modification Types Description Modification Levels
Remove Shipment From An order document's shipment Shipment
Delivery Plan can be removed from a
delivery plan.
Rework Quote A quote can be reworked. Header
Short An order document's header, Header
line, release, release line, and
receipt can be shorted. This Line
occurs when there is a shortage
in the expected quantity. Release

Release Line

Receipt
Sourcing Control Modifications can be made to Line
Modifications the Sourcing Control fields
associated with an order
document's line.
Split Line An order document's line or Line
release line can be split into
multiple lines. Release Line
Unpack Shipment An order document's shipment Shipment
can be unpacked.
Unreceive An order document's receipt Receipt
can be fully or partially
unreceived. This moves the
quantity you are identifying as
unreceived back to Shipped
status.
Unschedule An order document's header or Header
line can be unscheduled from a
scheduled node. This cancels Line
any inventory that has been
reserved for the order at the
scheduled node.

Chapter 27. Order Modification Types 465

466 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 28. Condition Builder Attributes
Condition Builder Attributes
Statements in the condition builder are built using attributes that are defined
throughout the Applications Manager.

These attributes are grouped as follows:

Sales Order
v Order fulfillment
v Order negotiation
v Outbound shipment
v Receipt

Planned Order
v Planed order execution
v Planned order negotiation

Return Order
v Reverse logistics
v Return shipment
v Return receipt

Template Order
v Template order

Purchase Order
v Purchase order execution
v Purchase order negotiation
v Inbound shipment
v Purchase order receipt

Transfer Order
v Transfer order execution
v Transfer order delivery
v Transfer order receipt

Master Order
v Master order fulfillment

Quote
v Quote fulfillment

Load
v Load execution

© Copyright IBM Corp. 1999, 2012 467

 General
v General
v WMS putaway
v WMS layout definition
v WMS inventory
v Trailer loading
v Task execution
v Move request execution
v Manifesting
v Over pack build

Count
v Count execution

Container
v Pack process

Wave
v Outbound picking

Work Order
v VAS process

Opportunity
v Opportunity fulfillment

Item-Based Allocation (IBA)

v Item-based allocation (IBA) order

Sales Order

Order Fulfillment
The Condition Builder attributes for Order Fulfillment, Order Execution, Quote
Fulfillment, Transfer Order Execution, and Template Order are identical.
Table 434. Order Fulfillment Condition Builder Attributes
Attribute Description
Order Attributes
Condition Variable 1 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Condition Variable 2 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Delivery Method The delivery method of the order (shipment, pickup or
delivery).

468 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 434. Order Fulfillment Condition Builder Attributes (continued)
Attribute Description
Disposition Code The disposition code of the item. This field is only applicable
for Reverse Logistics and Supply Collaboration.
Line Type The type of the order line. Sterling Selling and Fulfillment
Foundation has no application logic associated with the order
line type. This field can be set up as per your business
practices.
Order Type The type of the order. Sterling Selling and Fulfillment
Foundation has no application logic associated with the order
type. This field can be set up as per your business practices.
Payment Status The payment status of the order.
Sale Voided The flag indicating whether the order is voided.
Transaction ID The ID of the last transaction that was run on the order.
Participant Attributes
Bill To ID The ID of the bill to address for the order.
Buyer Organization Code The code of the organization that is buying the goods or
services.
Enterprise Code The code of the enterprise on the order.
Receiving Node The node that receives the shipment for the order.
Seller Organization Code The code of the organization that is selling the goods or
services.
Ship Node The node that ships the shipment for the order.
Ship Node Interface Type The interface type of the ship node on the order (External
Application, Console, Sterling Store Inventory Management,
or WMS 6.2).
Ship To ID The ID of the ship to address for the order.
Supplier Code The code of the supplier for the order.
Item Attributes
Item ID The ID of the item on the order line.
Item Group Code The group code of the service item. For example, if the
service is a provided service item, then the item group code
is PS.
Product Line The product line of the item on the order line.
Sourcing Attributes
Fulfillment Type The fulfillment type of the order.
Intentional Backorder The flag indicating whether the order was intentionally
dropped into backordered status at order creation.
Is Firm Predefined Node The flag indicating whether the node on the order is a firm
predefined node.
Order Sourcing The order sourcing classification of the order.
Classification
Reservation Mandatory The flag indicating whether the reservation is mandatory.
Related Order Attributes
Chain Type The chain type of the order.
Is Chained Line The flag indicating whether the order line is chained with
another order line.

Chapter 28. Condition Builder Attributes 469

 Table 434. Order Fulfillment Condition Builder Attributes (continued)
Attribute Description
Is Derived Line The flag indicating whether the order line is derived from
another order line.
Order Purpose The purpose of the order. If this is an exchange order, this
field is set to EXCHANGE.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Order Negotiation
The Condition Builder attributes for Order Negotiation and Planned Order
Negotiation are identical.
Table 435. Order Negotiation Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise on the order.
Initiator Organization The code of the organization that initiates the negotiation.
Code
Negotiator Organization The code of the organization that can accept, counter-offer, or
Code reject the initiator's offer.
Negotiation Pipeline Key The key of the negotiation pipeline this order is going
through.
Negotiation Number The negotiation number of this order.
Negotiation Rule Key The key of the negotiation rule for this order.
Header Entity The entity for which the negotiation was initiated. Currently,
the only applicable entity is Order.
Negotiation Status The status of the negotiation for this order.
Document Type The document type for this order. Typical value is Sales
Order.
Freight Terms The freight terms for this order.
Payment Terms The payment terms for this order.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

470 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Outbound Shipment
The condition builder attributes for Outbound Shipment, Inbound Shipment,
Transfer Order Delivery, and Return Shipment are identical.
Table 436. Outbound Shipment Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise on the outbound shipment.
Buyer Organization Code The code of the organization that is buying the goods or
services.
Seller Organization Code The code of the organization that is selling the goods or
services.
Ship Node The node that ships this shipment.
Ship Node Interface Type The interface type of the ship node on the order (External
Application, Console, Sterling Store Inventory Management,
or WMS 6.2).
Receiving Node The node that receives this shipment.
Ship Mode The shipment mode that is used for the shipment. For
example, Parcel, Truck Load, Less-Than Truck Load.
Freight Terms The freight terms for this shipment.
Carrier Type The shipment's carrier type for this shipment.
Hazardous Materials Flag The flag indicating whether these materials are hazardous.
ESP Check Required The flag indicating whether an Economic Shipping
Parameters check is required at shipment consolidation time.
Is Appointment Required The flag indicating whether an appointment is required for a
service execution.
Routing Guide Maintained The flag indicating whether a routing guide is maintained for
this shipment.
Carrier The carrier for the shipment.
Real-time Integration with The flag indicating whether the node this shipment is
WMS 6.2 shipping from is integrating with the Sterling Store Inventory
Management. Setting this field to N means that you are
integrating with WMS 6.2, or any other warehouse
management system.
Manually Entered The flag indicating whether or not the shipment was entered
through the Console.
Delivery Code The code of the entity that pays for the transportation costs.
Country/Region The country or region that the shipment is being shipped to.
Delivery Method The delivery method of the shipment (shipment, pickup or
delivery).
Is Serial Requested The flag indicating whether the shipment has any line with a
specific serial number passed. If that is the case, a different
outbound shipment process can be selected in the pipeline.
Is Provided Service The flag indicating whether the shipment has an associated
provided service item.
Shipment Type Indicates a set of shipments that are of the same nature.

Chapter 28. Condition Builder Attributes 471

 Table 436. Outbound Shipment Condition Builder Attributes (continued)
Attribute Description
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Receipt
The Receipt condition builder attributes are identical to the Return Receipt
attributes.

Planned Order

Planned Order Execution

The Planned Order Execution condition builder attributes are identical to the Order
Fulfillment attributes.

Planned Order Negotiation

The Planned Order Negotiation condition builder attributes are identical to the
Order Negotiation attributes.

Return Order

Reverse Logistics
Table 437. Return Fulfillment Condition Builder Attributes
Attribute Description
Order Attributes
Condition Variable 1 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Condition Variable 2 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Delivery Method The delivery method of the return (shipment, pickup or
delivery).
Disposition Code The disposition code of the item.
Line Type The type of the return line. Sterling Selling and Fulfillment
Foundation has no application logic associated with the
return line type. This field can be set up as per your business
practices.

472 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 437. Return Fulfillment Condition Builder Attributes (continued)
Attribute Description
Order Type The type of the return. Sterling Selling and Fulfillment
Foundation has no application logic associated with the
return type. This field can be set up as per your business
practices.
Payment Status The payment status of the return.
Sale Voided The flag indicating whether the return is voided.
Transaction ID The ID of the last transaction that was run on the return.
Participant Attributes
Bill To ID The ID of the bill to address for the return.
Buyer Organization Code The code of the organization that is buying the goods or
services.
Enterprise Code The code of the enterprise on the return.
Receiving Node The node that receives the shipment for the return.
Seller Organization Code The code of the organization that is selling the goods or
services.
Ship Node The node that be ships the shipment for the return.
Ship Node Interface Type The interface type of the ship node on the return (External
Application, Console, Sterling Store Inventory Management,
or WMS 6.2).
Ship To ID The ID of the ship to address for the return.
Supplier Code The code of the supplier for the return.
Item Attributes
Item ID The ID of the item on the return line.
Item Group Code The group code of the service item. For example, if the
service is a provided service item, then the item group code
is PS.
Product Line The product line of the item on the return line.
Sourcing Attributes
Fulfillment Type The fulfillment type of the return.
Intentional Backorder The flag indicating whether the return was intentionally
dropped into backordered status at return creation.
Is Firm Predefined Node The flag indicating whether the node on the return is a firm
predefined node.
Order Sourcing The order sourcing classification of the return.
Classification
Reservation Mandatory The flag indicating whether the reservation is mandatory.
Related Order Attributes
Chain Type The chain type of the return.
Is Chained Line The flag indicating whether the return line is chained with
another return line.
Is Derived Line The flag indicating whether the return line is derived from
another return line.
Order Purpose This field is only applicable to sales orders.

Chapter 28. Condition Builder Attributes 473

 Table 437. Return Fulfillment Condition Builder Attributes (continued)
Attribute Description
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Return Shipment
The Return Shipment condition builder attributes are identical to the Outbound
Shipment attributes.

Return Receipt
The Condition Builder attributes for Receipt, Purchase Order Receipt, Return
Receipt, Transfer Order Receipt are identical.
Table 438. Return Receipt Condition Builder Attributes
Attribute Description
Document Type The document type on the receipt. Typical value is Return
Order.
Enterprise Code The code of the enterprise that owns the receipt.
Seller Organization Code The code of the organization that is selling the goods or
services.
Ship Node The node where the shipment was shipped out of.
Buyer Organization Code The code of the organization that is buying the goods or
services.
Receiving Node The node where the shipment was received.
Receiving Node Interface The interface type of the receiving node on the order
Type (External Application, Console, Sterling Store Inventory
Management, or WMS 6.2).
Ship Mode The shipment mode that is used for the shipment. For
example, Parcel, Truck Load, Less-Than Truck Load.
Freight Terms The freight terms on the receipt.
Carrier Type The carrier type on the receipt.
Is Hazardous Material The flag indicating whether there are hazardous materials
that are being received.
Is Inspection Pending The flag indicating whether there is an inspection pending on
this return.
Is Receiving Node The flag indicating whether the receiving node is integrating
Integrated Real Time with WMS 6.2, or with another WMS system.

474 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 438. Return Receipt Condition Builder Attributes (continued)
Attribute Description
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Template Order
The Template Order condition builder attributes are identical to the Order
Fulfillment attributes.

Purchase Order

Purchase Order Execution

Table 439. Purchase Order Execution Condition Builder Attributes
Attribute Description
Order Attributes
Condition Variable 1 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Condition Variable 2 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Delivery Method The delivery method of the inbound order (shipment, pickup
or delivery).
Disposition Code The disposition code of the item.
Line Type The type of the inbound order line. Sterling Selling and
Fulfillment Foundation has no application logic associated
with the inbound order line type. This field can be set up as
per your business practices.
Order Type The type of the inbound order. Sterling Selling and
Fulfillment Foundation has no application logic associated
with the inbound order type. This field can be set up as per
your business practices.
Payment Status The payment status of the inbound order.
Sale Voided The flag indicating whether the inbound order is voided.
Transaction ID The ID of the last transaction that was run on the inbound
order.
Participant Attributes
Bill To ID The ID of the bill to address for the inbound order.
Buyer Organization Code The code of the organization that is buying the goods or
services.

Chapter 28. Condition Builder Attributes 475

 Table 439. Purchase Order Execution Condition Builder Attributes (continued)
Attribute Description
Enterprise Code The code of the enterprise on the inbound order.
Receiving Node The node that receives the shipment for the inbound order.
Seller Organization Code The code of the organization that is selling the goods or
services.
Ship Node The node that ships the shipment for the inbound order.
Ship Node Interface Type The interface type of the ship node on the inbound order
(External Application, Console, Sterling Store Inventory
Management, or WMS 6.2).
Ship To ID The ID of the ship to address for the inbound order.
Supplier Code The code of the supplier for the inbound order.
Item Attributes
Item ID The ID of the item on the inbound order line.
Item Group Code The group code of the service item. For example, if the
service is a provided service item, then the item group code
is PS.
Product Line The product line of the item on the inbound order line.
Sourcing Attributes
Fulfillment Type The fulfillment type of the inbound order.
Intentional Backorder The flag indicating whether the inbound order was
intentionally dropped into backordered status at inbound
order creation.
Is Firm Predefined Node The flag indicating whether the node on the inbound order is
a firm predefined node.
Order Sourcing The order sourcing classification of the inbound order.
Classification
Reservation Mandatory The flag indicating whether the reservation is mandatory.
Related Order Attributes
Chain Type The chain type of the inbound order.
Is Chained Line The flag indicating whether the inbound order line is chained
with another inbound order line.
Is Derived Line The flag indicating whether the inbound order line is derived
from another inbound order line.
Order Purpose This field is only applicable to sales orders.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

476 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Purchase Order Negotiation
Table 440. Purchase Order Negotiation Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise on the inbound order.
Initiator Organization The code of the organization that initiates the negotiation.
Code
Negotiator Organization The code of the organization that can accept, counter-offer, or
Code reject the initiator's offer.
Negotiation Pipeline Key The key of the negotiation pipeline this inbound order is
going through.
Negotiation Number The negotiation number of this inbound order.
Negotiation Rule Key The key of the negotiation rule for this inbound order.
Header Entity The entity for which the negotiation was initiated. Currently,
the only applicable entity is Order.
Negotiation Status The status of the negotiation for this inbound order.
Document Type The document type for this inbound order. Typical value is
Purchase Order.
Freight Terms The freight terms for this inbound order.
Payment Terms The payment terms for this inbound order.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Inbound Shipment
The Inbound Shipment condition builder attributes are identical to the Outbound
Shipment attributes.

Purchase Order Receipt

The Purchase Order Receipt condition builder attributes are identical to the Return
Receipt attributes.

Transfer Order

Transfer Order Execution

The Transfer Order Execution condition builder attributes are identical to the Order
Fulfillment attributes.

Transfer Order Delivery

The Transfer Order Delivery condition builder attributes are identical to the
Outbound Shipment attributes.

Chapter 28. Condition Builder Attributes 477

 Transfer Order Receipt
The Transfer Order Receipt condition builder attributes are identical to the Return
Receipt attributes.

Master Order Fulfillment

Table 441. Master Order Fulfillment Condition Builder Attributes
Attribute Description
Master Order Attributes
Condition Variable 1 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Condition Variable 2 A variable that can be used for condition building. This is an
existing field in the YFS_ORDER_LINE database table, and
can be used to create conditions without extending the
database.
Delivery Method The delivery method of the order (shipment, pickup or
delivery).
Disposition Code The disposition code of the item. This field is only applicable
for Reverse Logistics and Supply Collaboration.
Line Type The type of the order line. Sterling Selling and Fulfillment
Foundation has no application logic associated with the order
line type. This field can be set up as per your business
practices.
Order Type The type of the order. Sterling Selling and Fulfillment
Foundation has no application logic associated with the order
type. This field can be set up as per your business practices.
Payment Status The payment status of the order.
Sale Voided The flag indicating whether the order is voided.
Transaction ID The ID of the last transaction that was run on the order.
Participant Attributes
Bill To ID The ID of the bill to address for the order.
Buyer Organization Code The code of the organization that is buying the goods or
services.
Enterprise Code The code of the enterprise on the order.
Receiving Node The node that receives the shipment for the order.
Seller Organization Code The code of the organization that is selling the goods or
services.
Ship Node The node that ships the shipment for the order.
Ship Node Interface Type The interface type of the ship node on the order (External
Application, Console, Sterling Store Inventory Management,
or WMS 6.2).
Ship To ID The ID of the ship to address for the order.
Supplier Code The code of the supplier for the order.
Item Attributes
Item ID The ID of the item on the order line.

478 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 441. Master Order Fulfillment Condition Builder Attributes (continued)
Attribute Description
Item Group Code The group code of the service item. For example, if the
service is a provided service item, then the item group code
is PS.
Product Line The product line of the item on the order line.
Sourcing Attributes
Fulfillment Type The fulfillment type of the order.
Intentional Backorder The flag indicating whether the order was intentionally
dropped into backordered status at order creation.
Is Firm Predefined Node The flag indicating whether the node on the order is a firm
predefined node.
Order Sourcing The order sourcing classification of the order.
Classification
Reservation Mandatory The flag indicating whether the reservation is mandatory.
Related Master Order Attributes
Chain Type The chain type of the order.
Is Chained Line The flag indicating whether the order line is chained with
another order line.
Is Derived Line The flag indicating whether the order line is derived from
another order line.
Order Purpose The purpose of the order. If this is an exchange order, this
field is set to EXCHANGE.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Quote Fulfillment
The Quote Fulfillment condition builder attributes are identical to the Order
Fulfillment condition builder attributes.

Load Execution
Table 442. Load Execution Condition Builder Attributes
Attribute Description
Load Type The type of the load document.
Enterprise Code The code of the enterprise on the load document.
Owner Organization Code The code of the organization that owns the load document.
Carrier The carrier used to carry the load.
Carrier Service Code The code of the carrier service used to carry the load.
Ship Mode The shipment mode that is used for the shipment. For
example, Parcel, Truck Load, Less-Than Truck Load.

Chapter 28. Condition Builder Attributes 479

 Table 442. Load Execution Condition Builder Attributes (continued)
Attribute Description
Hazardous Material The flag indicating whether hazardous materials are being
carried in this load.
Origin Node The node where the load originated from.
Destination Node The node where the load is being shipped to.
Multiple Load Stop The flag indicating whether or not a shipment goes through
multiple stops to load or unload additional shipments.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

General
The following Condition Builder attributes are identical to those for WMS Putaway,
WMS Layout Definition, WMS Inventory, Trailer Loading, Task Execution, Move
Request Execution, Manifesting, and Over Pack Build.
Table 443. General Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise.
Organization Code The code of the organization.
Provider Organization The code of the organization that provides the service.
Code
Ship Node The node that ships this shipment.
Supply Type The supply type associated with the inventory status. Typical
values are Onhand, Held, etc.
Item ID The ID of the item on the order line.
Unit Of Measure The unit of measure of the item.
Product Class The inventory classification of an item based on the product's
characteristics. Typical values are FQ - First Quality, SQ -
Second Quality, etc.
Inventory Status The inventory sub classification of the product, based on the
results of the inventory control processes within the
warehouse. Typical values are Good - Good Inventory,
Damaged - Damaged inventory, Qlty-Hold - Quality Hold,
etc.
Adjustment Type The type of inventory adjustment. Typical values are Cycle
Count, Receipt, Picking, Packing, Shipping, etc.
Alert Type The type of alert raised when an exception occurs.
Carrier The carrier used to carry the shipment.
Task Type The Task Type applicable to a task. Typical values are Receipt,
QC, Count, Replenishment, Retrieval, Putaway, VAS, Pack,
Shipping, and Picking.

480 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 443. General Condition Builder Attributes (continued)
Attribute Description
Assigned To User ID The ID of the user to whom the task is assigned.
Task Status The Task Status within the pipeline that the task travels
through. Typical values are Open, Suggested, In Progress,
Held, Completed, Canceled, etc.
Document Type The document type for this order. Typical values are Sales
Order, Purchase Order, Transfer Order, and Return Order.
SC UI Client Version The Rich Client Platform application version number.
Activity Group ID The identifier for the activity group.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

WMS Putaway
The WMS Putaway condition builder attributes are identical to the General
attributes.

WMS Layout Definition

The WMS Layout Definition condition builder attributes are identical to the
General attributes.

WMS Inventory
The WMS Layout Inventory condition builder attributes are identical to the
General attributes.

Trailer Loading
The Trailer Loading condition builder attributes are identical to the General
attributes.

Task Execution
The Task Execution condition builder attributes are identical to the General
attributes.

Move Request Execution

The Move Request Execution condition builder attributes are identical to the
General attributes.

Chapter 28. Condition Builder Attributes 481

Manifesting
The Manifesting condition builder attributes are identical to the General attributes.

Over Pack Build

The Over Pack Build condition builder attributes are identical to the General
attributes.

Count Execution
Table 444. Count Execution Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise for which the count request is
created.
Request Type The type of count requested.
Count Program Name The name of the count program for which the count request
is created.
Node Key The node where the count request is processed.
Zone ID The zone where the count must be performed.
Location Size Code The capacity of the location where the count must be
performed.
Is LPN Level The flag indicating whether the count tasks are be performed
at the LPN level.
Is Case Level The flag indicating whether the count tasks are be performed
at the case level.
Is Pallet Level The flag indicating whether the count tasks are be performed
at the pallet level.
Is Item Level The flag indicating whether the count tasks are be performed
at the item level.
Is Resolvable The flag indicating whether variance can be resolved for this
count result.
Product Class The inventory classification of an item based on the product's
characteristics. Typical values are FQ - First Quality, SQ -
Second Quality, etc.
Unit Of Measure The unit of measure of the item that was counted.
Item Classification 1 The first item classification attribute for determining the
Count Strategy.
Item Classification 2 The second item classification attribute for determining the
Count Strategy.
Item Classification 3 The third item classification attribute for determining the
Count Strategy.
Has Variance The flag indicating whether the count request has a variance.
Has Absolute Variance The flag indicating whether the count request has an absolute
variance.
Variance Quantity The difference in quantity (+/-) between the count result and
system quantity.

482 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 444. Count Execution Condition Builder Attributes (continued)
Attribute Description
Absolute Variance The absolute difference between the count result and system
Quantity quantity.
Variance Value The difference in cost/value (+/-) between the count result
and system quantity.
Absolute Variance Value The absolute difference in cost/value between the count
result and system quantity.
Has Variance With The flag indicating whether the variance between the current
Previous Count count result and previous count results displays.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Pack Process
Table 445. Pack Process Condition Builder Attributes
Attribute Description
Node Attributes
Ship Node The node that ships this shipment.
Receiving Node The node that receives this shipment.
Ship from Ship Node The interface type of the ship node from which the shipment
Interface Type is shipped (External Application, Console, Sterling Store
Inventory Management, or WMS 6.2).
Ship from Supplier Code The code of the supplier that is shipping the shipment.
Ship from DCM The flag indicating whether the node from which the
Integration Real Time shipment is shipped uses WMS 6.2.
Ship from Country/Region The code of the country or region from which the shipment is
being shipped.
Ship to Ship Node The interface type of the ship node to which the shipment is
Interface Type shipped (External Application, Console, Sterling Store
Inventory Management, or WMS 6.2).
Ship to Supplier Code The code of the supplier to whom the shipment is being
shipped.
Ship to DCM Integration The flag indicating whether the node to which the shipment
Real Time is shipped uses WMS 6.2.
Ship to Country/Region The code of the country or region to which the shipment is
being shipped.
Organization Attributes
Enterprise Code The code of the enterprise that owns the shipment.
Buyer Organization Code The code of the organization that is buying the goods or
services.
Seller Organization Code The code of the organization that is selling the goods or
services.

Chapter 28. Condition Builder Attributes 483

 Table 445. Pack Process Condition Builder Attributes (continued)
Attribute Description
Shipment Attributes
Ship Mode The shipment mode that is used for the shipment. For
example, Parcel, Truck Load, Less-Than Truck Load.
Carrier The carrier used to carry the shipment.
Freight Terms The freight terms of the shipment.
Delivery Code The code of the entity that pays for the transportation costs.
Pack And Hold The flag indicating whether the shipment needs to be packed
and put away for retrieval at a later date.
Shipment Container Count The number of containers in the shipment.
Shipment Containerized The flag indicating the containerization state of the shipment.
Flag The values are: 01 - not containerized, 02 - containerization in
progress and 03 - containerization completed.
Container Attributes
Is Shipment Container The flag indicating whether the container belongs to a
shipment.
Is Load Container The flag indicating whether the container is part of a load.
Is Inventory Pallet The flag indicating whether the container is an inventory
pallet.
Is Converted From LPN The flag indicating whether the inventory container has been
converted to a shipment container.
Is Serial Capture Pending The flag indicating whether the serial capture is pending for
the container.
Is Pack Process Complete The flag indicating whether any more pack activities are
pending for the container.
Is Product Placing The flag indicating whether placing the product into the
Complete container according to the system's suggestion has been
completed.
Requires VAS The flag indicating whether the container requires value
added services.
Has Child Containers The flag indicating whether a container is a parent container
having other containers.
Number of Items The number of items contained in the container.
Container Type The attribute that specifies whether a shipment container is a
case or pallet.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

484 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Outbound Picking
Table 446. Outbound Picking Condition Builder Attributes
Attribute Description
Activity Group ID The identifier for the activity group.
Shipment Group ID The identifier for the shipment group.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

VAS Process
Table 447. VAS Process Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise that owns the item or license plate.
Provider Organization The code of the organization that provides the service.
Code
Node Key The node, where the work orders are run.
Purpose The purpose for the work order (ORDER / STOCK / SHIP)
Service Item Group Code The code of the service item group (KIT/DKIT/COMPL/
INVC/PS)
Service Item ID The identifier for the service Item.
Segment Type The type of segment. This may be MTO (made to order) or
MTC (made to customer).
Segment The segment to which the inventory involved in the work
order belongs.
Has Components The flag indicating whether the work order has component
items.
Status The status of the work order.
Pre Call Status The flag indicating the status of the pre-call process.
Appt Status The status of the appointment. This is in sync with the
service order line. The appointment status is used in case of
provided service work order.
Number Of Attempts The number of attempts made to run the work order.
Number Of Hours until The number of hours left before the appointment for the
Appointment service item.
Number Of Hours After The number of hours after the last appointment for the
Appointment service item.
Number Of Hours After The number of hours after the last attempt to run the service.
Last Execution
Last Execution Success The flag indicating whether the last attempt to run the service
was successful or not.

Chapter 28. Condition Builder Attributes 485

 Table 447. VAS Process Condition Builder Attributes (continued)
Attribute Description
Open Work Order Flag The flag indicating whether the execution of the work order
has ended or not.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Opportunity

Opportunity Fulfillment
Table 448. Opportunity Fulfillment Condition Builder Attributes
Attribute Description
Opportunity Attributes
Opportunity ID The ID of the opportunity.
Opportunity Name The name of the opportunity.
Status The status of the opportunity.
Currency Value The currency value of the opportunity.
Probable Success Rate The likelihood of whether an order will be created from the
opportunity.
Participant Attributes
Bill To ID The ID of the bill to address for the opportunity.
Buyer Organization Code The code of the organization that may buy the goods or
services.
Enterprise Code The code of the enterprise for the opportunity.
Owner User ID The user ID of the opportunity owner.
Co-Owner User ID The user ID of the opportunity co-owner.
Customer Contact ID The ID of the customer contact for the opportunity.
Team Code The code of the team that manages the opportunity.
{Enter Your Own A customizable condition builder attribute. For more
Attribute} information about customizing this field, see the Sterling
Selling and Fulfillment Foundation: Extending the Condition
Builder.

This field is limited only to unexposed key attributes that are

predefined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

486 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Item Based Allocation
The Item Based Allocation transaction allocates unpromised and promised
demands of existing orders to more suitable supplies based upon inventory items
and nodes which have been triggered for the Item Based Allocation process in the
YFS_IBA_TRIGGER table.

The Item Based Allocation agent obtains and processes all Item Based Allocation
triggers from the YFS_IBA_TRIGGER table that meet the following conditions:
v IBA_RUN_REQUIRED = "Y"
v LAST_IBA_PROCESSED_TS was 'x' hours before current time, where 'x' is from
the ‘Item Based Allocation Agent Execution Interval (in hours)' rule in the
Installation rules. For more information about installation rules, refer to the topic
"System Administration Components: Defining Installation Rules" in the Sterling
Selling and Fulfillment Foundation: Configuration Guide. This rule is used to
indicate the interval that the Item Based Allocation agent should not reprocess
the triggers in the YFS_IBA_TRIGGER table, which were processed earlier. This
prevents the IBA agent from over-processing the item and node combination in
the given time interval to avoid any high loads on the system.
v PROCESSING_BY_AGENT="N" or PROCESS_OVER_BY_TS is before the current
timestamp. The PROCESSING_BY_AGENT field is used to prevent the picking
up of the IBA trigger which is being processed by another instance of the agent.

If InventoryOrganizationCode is specified in the agent criteria, only the IBA trigger

with inventory items of that inventory organization is retrieved.

For each triggered item and node combination, the agent finds all of the applicable
order lines or order line reservations that contain the item and node and tries to
move their unpromised and promised demands to more suitable available supplies
based on user-configured IBA selection rules or FIFO (First-In-First-Out) IBA
selection rules.

Sterling Selling and Fulfillment Foundation creates new positive order line
reservations with the matched supply's first ship date and negative order line
reservations for the existing demand ship date. Once all orders are processed, they
are placed on hold to be rescheduled if changes are detected in the order line
reservations.

The following configuration is required for the Item Based Allocation process:
v The Use Item Based Allocation rule needs to be enabled.
v Item and node need to have Item Based Allocation Allowed enabled.
v A hold type is required to be set up for the change order line reservations
modification type so that the order can be placed on hold for rescheduling. For
more information, refer to the Sterling Selling and Fulfillment Foundation: Javadocs.

The ‘When a line is backordered, backorder against the highest priority ship node'
rule should be checked in order to reallocate backordered demand. For more
information, see the Fulfillment Rules section in the Sterling Selling and Fulfillment
Foundation: Distributed Order Management Configuration Guide.

Before processing the Item Based Allocation logic, the Item Based Allocation agent
updates the following fields on the Item Based Allocation trigger:
v PROCESSING_BY_AGENT = “Y”. This indicates that an instance of the agent is
currently processing this trigger.
Chapter 28. Condition Builder Attributes 487
 v PROCESS_OVER_BY_TS = current time + 1 hr. This indicates the expected time
that the agent should finish with processing this IBA trigger. One hour is the
fixed window and cannot be changed. Sterling Selling and Fulfillment
Foundation treats the PROCESSING_BY_AGENT flag as “N” regardless of the
actual value when current timestamp is after this timestamp.
v IBA_RUN_REQUIRED = ”N”. This resets the IBA_RUN_REQUIRED flag back to
“N”.

Obtaining a List of Demands Based on Applicable Order Release

Statuses and Order Line Reservations to be Allocated

A list of demands is derived from applicable order release statuses and order line
reservations, which have the item and node in the IBA trigger. The following types
of demands are retrieved:
v Demands of chained orders
v Demands of orders with chained order already created
v Demands of orders with procurement node but chained order creation is not yet
created
v Demands of orders without procurement node
v Demands from order line reservations

The demand quantity is derived based on the order release status quantity with
the status from the Status Inventory Type configuration that has a demand type,
which considers the supply type with ‘Use Consider Demand Type for Item Based
Allocation' enabled. For more information, refer to the Sterling Selling and
Fulfillment Foundation: Global Inventory Visibility Configuration Guide.

Obtaining a List of Available Supplies for Allocation

Sterling Selling and Fulfillment Foundation obtains the available supply based on
the availability of the item at the node by ignoring unpromised and promised
demands. If the inventory organization maintains its inventory externally, the
external availability can be read by the YFSGetExternalInventoryUE user exit. Only
the availability of supplies that consider the ‘Demand Type Look for Availability
during Item Based Allocation' are used in the allocation logic. For more
information, refer to the Sterling Selling and Fulfillment Foundation: Global Inventory
Visibility Configuration Guide.

Allocated demands should be matched with the same supplies as "Demand to look
for during release".

Matching Demands Against Supplies in FIFO (First-In-First-Out)

Order

Sterling Selling and Fulfillment Foundation sorts the list of available supplies in
the order of the first shippable date (ETA), and matches the obtained list of
demands using the top-down logic (unlike the normal matching logic for obtaining
availability, where matches are based on the closest ETA). Demands are allocated
in the following orders:
v Demands of chained orders - first based on user-configured sequencing rules,
and then in ascending order of order creation date. (These types of demands are
matched based on the closest ETA to avoid any changes in the chained orders).

488 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
v Demands of orders with a chained order already created - first based on
user-configured sequencing rules, then in ascending order of product availability
date. (These types of demands are matched based on the closest ETA to avoid
any changes in the orders).
v Demands of orders for which procurement node and chained order creation is
imminent (within the advanced notification time window) - first based on
user-configured sequencing rules, then in order of order creation date.
v Demands of orders without a procurement node and within the release window
(advanced notification time window) - first based on user-configured sequencing
rules, then in order of order creation date.
v Demands from order line reservations on the order lines in the order of
requested reservation date, and left-over demands (outside of the advanced
notification time window) of orders with or without a procurement node, first
based on user-configured sequencing rules and then in the order of order
creation date.
v Demands from inventory reservations in the order of ship date.

Notice that different types of demands are given different priorities based on their
significance. The demands of chained orders or orders related to chained orders
are treated with a higher priority than the demands of normal orders. Furthermore,
the demands with a ship date within the advanced notification time window also
have a higher priority than the demands with a date outside of the advanced
notification time window.

Updating Order Reservations for the Matched Demands

After matching the available supply and demand in user-configured sequencing

and then in FIFO order, the system builds up a list of order line reservation
changes and inventory demand changes (corresponding to the order line
reservation changes) and summarize them to optimize the number of order
reservation updates and inventory updates. Negative order line reservations are
added for the matched demands. Positive order reservations are added for the
matched demands with the product availability date set to the matched supplies'
first ship date.

After the Item Based Allocation agent completes its tasks for an Item Based
Allocation trigger, it updates the fields of the trigger with the following values:
v IBA_REQUIRED = "N"
v LAST_IBA_PROCESSED_TS = current timestamp.
v PROCESS_OVER_BY_TS = current timestamp.
v PROCESSING_BY_AGENT = ”N”

The Item Based Allocation agent should be used in conjunction with the
rescheduling process as the rescheduling process reschedules the affected orders by
utilizing the order line reservations created by the Item Based Allocation process.

Attributes

The following are the attributes for this time-triggered transaction:

Table 449. Item Based Allocation Attributes
Attribute Value
Base Transaction ID ITEM_BASED_ALLOCATION

Chapter 28. Condition Builder Attributes 489

 Table 449. Item Based Allocation Attributes (continued)
Attribute Value
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called changeOrder – for updating the order line reservations created
as part of the Item Based Allocation process.
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 450. Item Based Allocation Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.
Number of Records To Optional. Number of records to retrieve and process at one
Buffer time. If left blank or specified as 0 (zero), it defaults to 5000.
InventoryOrganization The inventory organization code of the inventory items which
Code are processed by the Item Based Allocation agent. If provided,
only the IBA triggers with the inventory item that belongs to
this inventory organization are processed.
ColonyID Required in a multischema deployment where the
YFS_IBA_TRIGGER table may exist in multiple schemas. Runs
the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 451. Item Based Allocation Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed by the Item Based
Allocation agent.
NumOrdersRequiredReschedule Number of orders required rescheduling as the
result of Item Based Allocation process.

Pending Job Count

None.

Events Raised

This transaction raises events as specified under the changeOrder API in the
Sterling Selling and Fulfillment Foundation: Javadocs.

490 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Index
A C delivery codes (continued)
defining 91
additional logistic rules calendars 35 deleting 92
defining 90 Cancel Order for Inventory Shortage modifying 92
Additional Optimization Criteria 51 flag 49 delivery locations 45
address question groups carrier modification reasons delivery service items
deleting 79 creating 89 sourcing rules 64
modifying 79 defining 89 Description field 55
address questions deleting 90 display control types 80
capacity impact modifying 89 distributed order management
capacity impact multiplier 81 Carrier Service Code field 98 configuration 2
defining 81 Carrier/Service field 98 distribution groups 45, 58
deleting 82 catalog advanced distribution details 60
fixed capacity impact 81 index building 301 deleting 61
modifying 82 chained orders 37 creating 26, 59, 67
defining 79 definition 71 creating for procurement 73
deleting 80 charge categories defining for product items 58
modifying 80 adding charge names 240 defining for provided service
rearranging 82 creating 240 items 67
See also questions 80 deleting 241 deleting 27, 61, 69
address questions groups deleting charge names 241 deleting for procurement 74
defining 78 modifying 241 modifying for procurement 73
Allow Reservation During Scheduling modifying charge names 241 nodes
field 50 charge definitions 240 adding 59, 68
answer options 80 common codes 151 deleting 60, 68
application rules side panel 8 condition builder 486 modifying 60, 68
Applications Manager configuration screens sourcing 59
actions 18 accessing 9 Do not mix in Shipment flag 94
document types 19 Configure Outbound Constraints Do Not Recompute Expected Dates When
entering dates/times 21 field 54 Requested Dates On The Order Are
lists 21 Consider Buyer's Routing Guide field 88 Changed field 201, 203
lookup functionality 19 Consolidator field 98 document types 250
special characters 22 Convert Node Attributes Into Cost
troubleshooting 22 field 54
users 20 Country/Region field 97, 98
layout 7 Currency field 55 E
starting 7 customer components enterprises 2
work area 14 customer grades 139 Euro Member field 55
Apply Future Safety Factor To Future definitions 130 Expiration Date field 55
Inventory Availability flag 49 Customer Components 127 external organizations 58
Apply On Hand Safety Factor To On customer identification master 128
Hand Inventory Availability flag 49 customers 3
approval rule violation reasons for F
quotes 159 financial components 239
ATP Rule 33
authorization reversal 108
D financials 3
date based dependency 212 freight terms
Available field 189 creating 87
default dependency group
defining 213 defining 87
deleting 216 deleting 88
B modifying 216 modifying 88
backorder reasons 4, 155, 156 default distribution rule 45 From field 98
Break Bulk Node field 98 Default Supervisor field 77 From Node field 38
building Delay Procurements To be Consolidated fulfillment types 43, 44, 62
catalog index 301 With Shipments Against Future Coming creating 33, 43
business models 1 Inventory. 51 deleting 34, 44
business rules 2 Delay Shipment Against Current modifying 34, 43
buyers 2 Inventory To Be Consolidated With
Shipments Against Future Coming
Inventory 51 I
delivery codes Ignore Fill Quantity (Ship Complete)
creating 91 field 50

© Copyright IBM Corp. 1999, 2012 491

index
catalog search 301
order attributes (continued)
generating prime line
Q
inheritance 44 numbers 148 questions
determining 9 order promising configuring 78
instruction types 4, 152 configuring 23 definition 78
creating 151 nodes quote rules, configuring 206
deleting 152 defining promising
modifying 151 information 35
inventory availability safety factors 49 order sources 142, 143 R
item classifications 71 order sourcing classification Receipt Processing Time (Hours)
item level controls defining 45 field 36
defining 33 definition 45 Receipt Processing Time for Forwarding
item substitution 36 order sourcing classifications 62 (Hours) 36
creating 45 receiving discrepancy reasons 246, 248
deleting 46 region schemas
L modifying 46
order types 141, 142, 161, 162
definition 46
lead origins 159, 163, 164 Delivery Region Schema 46
order validations 3, 150 Provided Service Region Schema 46
Line Ship Complete flag 48
seller validation 139 Shipped Product Region Schema 46
Line Ship from Single Node flag 49
organization levels 9 Reserve Bundle Out of Ratio field 50
logistics 3
rules 11 Retention Days field 250
defining attributes 87
organization rules 11 reverse authorization 108
lost reasons 165, 166
loading another organization's Rollback Segment field 250
rules 14 routing guide lines
overriding 12 creating 96
M outbound constraints definition 96
marketplaces 2 defining 93 deleting 100
Master Order Override Freight Terms field 98 modifying 100
Next iteration date 207 Override Ship To field 98 routing guides 95
Maximum no. of days order can be creating 95
scheduled before its ship date field 49, deleting 100
50
Maximum no. of days order can be
P modifying 96
payment rules 243
shipped/delivered beyond its requested
payment terms 239
date field 50
Maximum no. of days to search service
permit question groups S
defining 83 scheduling rules 43
availability for field 50
deleting 83 constraints 48
modification components 169
modifying 83 creating 47
rules 167
permit questions default rule 47
types 167, 169
defining 84 defining 47
modification reasons 4, 154
deleting 85 deleting 52
creating 153
modifying 85 inventory controls 49
deleting 154
rearranging 85 lead times 49
modifying 153
See also questions 80 modifying 52
modification rules 261
pipelines 261 optimize on 51
multidivisional corporations 1
Postfix Symbol field 55 primary information 48
Prefix Symbol field 55 priority 50
Pricing organization 10, 11 retry intervals 48
N Priority field 98 scheduling algorithm 47
Node Consumption Percentage Cost process type configuration 4 sellers 2
Factor field 55 procurement service execution
Node Cost Factor Currency field 54 distribution groups 73 configuring components 77
Node field 98 sourcing rules 71 service supervisors
Node Priority Cost Factor field 54 procurement orders 34, 71 configuring 77
nodes 44, 45, 58 procurement rules default 77
note reasons 158, 258 defining 71 defining 77
product items deleting 78
sourcing rules 61 modifying 78
O provided service items
distribution groups 67
Ship Complete flag 48
order attributes 3 Ship from Single Node flag 48
sourcing rules 69 ship node determination 58
external references
provided service locations 45 shipment modes
order level 143, 144
purchase orders creating 93
order line level 144, 145
definition 71 defining 92
line types 147
Purge Code field 250 deleting 93
order address types 145, 146
purge criteria 4, 249, 251 modifying 93
other attributes 147
rules 249

492 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
sourcing region selection
defining 46
U
sourcing rules 43, 44, 45 Use Advanced Transit Time Calculation
creating for delivery service items 64 flag 90
creating for procurement 71 Use End Of Shift Time flag 36
creating for product item 62 Use Handling Cost flag 54
creating for provided service Use Item Cost flag 53
items 69 Use Landed Cost flag 53
default distribution rule 45
defining basic configuration 44
defining for delivery service items 64 V
defining for product items 61 Validate Charge Name flag 246
defining for provided service Validate Customer ID flag 150
items 69 Validate Item flag 150
deleting for delivery service items 66 Validate Vendor ID flag 150
deleting for procurement 73
deleting for product items 64
deleting for provided service
items 71
W
modifying for delivery service When Optimizing On Cost, Combine
items 65 Shipments. 51
modifying for procurement 72 work orders 36
modifying for product items 63 workflows 2
modifying for provided service
items 70
sourcing setup 3 Z
State field 97, 98 Zip Code field 97, 98
Store# field 98
Subscribed field 189
Synchronize Dates Between Master Order
Dates And Dates On Order Line And
Schedules field 201
system integration 261

T
tax names 242, 243
third-party logistics models 2
Third-party logistics models 2
To field 98
To Node field 38
transaction based dependency 212
transaction dependencies
configuring 212
transaction dependency
configuring groups 212
creating rules 214
sequencing 212
types
date based 212
transaction based 212
transaction dependency rule
creating 214
creating constraints 215
transaction dependency rule
constraints 215
Transfer Cost Factor Currency field 53
Transfer Cost Factor for External
Transfers field 54
Transfer Cost Factor for Internal Transfers
field 53
transfer orders 37
definition 71
transfer schedules 37
transportation optimization 94

Index 493
494 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Notices
This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user's responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not grant you
any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing

IBM Corporation

North Castle Drive

Armonk, NY 10504-1785

U.S.A.

For license inquiries regarding double-byte character set (DBCS) information,

contact the IBM Intellectual Property Department in your country or send
inquiries, in writing, to:

Intellectual Property Licensing

Legal and Intellectual Property Law

IBM Japan Ltd.

1623-14, Shimotsuruma, Yamato-shi

Kanagawa 242-8502 Japan

The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore, this statement may not apply
to you.

This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be

© Copyright IBM Corp. 1999, 2012 495

 incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:

IBM Corporation

J46A/G4

555 Bailey Avenue

San Jose, CA 95141-1003

U.S.A.

Such information may be available, subject to appropriate terms and conditions,

including in some cases, payment of a fee.

The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement or any equivalent agreement
between us.

Any performance data contained herein was determined in a controlled

environment. Therefore, the results obtained in other operating environments may
vary significantly. Some measurements may have been made on development-level
systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurements may have been
estimated through extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers of

those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.

All statements regarding IBM's future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.

All IBM prices shown are IBM's suggested retail prices, are current and are subject
to change without notice. Dealer prices may vary.

496 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
This information is for planning purposes only. The information herein is subject to
change before the products described become available.

This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which

illustrate programming techniques on various operating platforms. You may copy,
modify, and distribute these sample programs in any form without payment to
IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating
platform for which the sample programs are written. These examples have not
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs. The sample
programs are provided "AS IS", without warranty of any kind. IBM shall not be
liable for any damages arising out of your use of the sample programs.

Each copy or any portion of these sample programs or any derivative work, must
include a copyright notice as follows:

© IBM 2012. Portions of this code are derived from IBM Corp. Sample Programs. ©
Copyright IBM Corp. 2012.

If you are viewing this information softcopy, the photographs and color
illustrations may not appear.

Trademarks

IBM, the IBM logo, and ibm.com® are trademarks or registered trademarks of
International Business Machines Corp., registered in many jurisdictions worldwide.
Other product and service names might be trademarks of IBM or other companies.
A current list of IBM trademarks is available on the Web at “Copyright and
trademark information” at http://www.ibm.com/legal/copytrade.shtml.

Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered
trademarks or trademarks of Adobe Systems Incorporated in the United States,
and/or other countries.

IT Infrastructure Library is a registered trademark of the Central Computer and

Telecommunications Agency which is now part of the Office of Government
Commerce.

Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo,
Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or
registered trademarks of Intel Corporation or its subsidiaries in the United States
and other countries.

Linux is a registered trademark of Linus Torvalds in the United States, other

countries, or both.

Notices 497
 Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.

ITIL is a registered trademark, and a registered community trademark of the Office

of Government Commerce, and is registered in the U.S. Patent and Trademark
Office.

UNIX is a registered trademark of The Open Group in the United States and other
countries.

Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Oracle and/or its affiliates.

Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the

United States, other countries, or both and is used under license therefrom.

Linear Tape-Open, LTO, the LTO Logo, Ultrium and the Ultrium Logo are
trademarks of HP, IBM Corp. and Quantum in the U.S. and other countries.

Connect Control Center®, Connect:Direct®, Connect:Enterprise®, Gentran®,

Gentran®:Basic®, Gentran:Control®, Gentran:Director®, Gentran:Plus®,
Gentran:Realtime®, Gentran:Server®, Gentran:Viewpoint®, Sterling Commerce™,
Sterling Information Broker®, and Sterling Integrator® are trademarks or registered
trademarks of Sterling Commerce™, Inc., an IBM Company.

Other company, product, and service names may be trademarks or service marks
of others.

498 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide



Printed in USA