Sterling Selling and Fulfillment Foundation



Distributed Order Management

Configuration Guide
Release 9.1.0.28
Sterling Selling and Fulfillment Foundation



Distributed Order Management

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

Copyright
This edition applies to the 9.1 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 Defining Levels of Service . . . . . . . . . 39
Introducing Distributed Order Management . . . . 1 Creating a Level of Service . . . . . . . . 39
Business Models . . . . . . . . . . . . . 1 Modifying a Level of Service . . . . . . . 40
Multi-Divisional Corporation . . . . . . . . 2 Deleting a Level of Service . . . . . . . . 40
Third-Party Logistics . . . . . . . . . . 2 Defining Node Level Controls . . . . . . . . 41
Marketplace . . . . . . . . . . . . . 2 Defining a Node's Primary Order Promising
Sterling Distributed Order Management Information . . . . . . . . . . . . . 41
Configuration . . . . . . . . . . . . . . 2 Defining a Node’s Relationships . . . . . . 44
Sourcing Setup . . . . . . . . . . . . 3 Defining Notification Periods . . . . . . . 48
Logistics . . . . . . . . . . . . . . . 3 Defining Sourcing and Scheduling Rules . . . 52
Financials . . . . . . . . . . . . . . 3 Defining Fulfillment Types . . . . . . . . 52
Customer . . . . . . . . . . . . . . 3 Defining Basic Sourcing Configuration . . . . 53
Order Attributes . . . . . . . . . . . . 3 Defining Order Sourcing Classifications . . . . 55
Order Validation . . . . . . . . . . . . 4 Sourcing Region Selection . . . . . . . . 56
Instruction Types . . . . . . . . . . . . 4 Defining Sourcing Region Selection . . . . . 57
Modification Reasons . . . . . . . . . . 4 Defining Scheduling Rules . . . . . . . . 57
Backorder Reasons . . . . . . . . . . . 4 Configuring Landed Cost Optimization . . . . 64
Process Type Configuration . . . . . . . . 4 Forwarding/Transfer Rules . . . . . . . . 69
Purge Criteria . . . . . . . . . . . . . 4 Defining Distribution Groups for Product Items 71
Defining Sourcing Rules for Product Items . . . 75
Chapter 2. Navigating the Applications Defining Sourcing Rules for Delivery Service
Items . . . . . . . . . . . . . . . 78
Manager . . . . . . . . . . . . . . 7 Defining Distribution Groups for Provided
Starting the Applications Manager . . . . . . . 7 Service Items . . . . . . . . . . . . . 81
The Applications Manager Layout . . . . . . . 7 Defining Sourcing Rules for Provided Service
Application Rules Side Panel . . . . . . . . 9 Items . . . . . . . . . . . . . . . 83
Work Area. . . . . . . . . . . . . . 16 Defining Procurement Rules . . . . . . . . 86
Actions Available in the Applications Defining Sourcing Template Details . . . . . 90
ManagerConfigurator . . . . . . . . . . . 19
Using the Applications Manager's Lookup
Functionality . . . . . . . . . . . . . 20
Chapter 4. Configuring
Viewing the Document Types Associated with an Cross-Application Service Execution
Application . . . . . . . . . . . . . 20 Components . . . . . . . . . . . . 93
Viewing the User Logged into the Applications Configuring Service Supervisors . . . . . . . 93
Manager . . . . . . . . . . . . . . 22 Defining a Service Supervisor for a Node . . . 93
Using Lists and List Filtering . . . . . . . 22 Modifying a Service Supervisor for a Node . . . 94
Date and Time Entry . . . . . . . . . . 23 Deleting a Service Supervisor for a Node . . . 94
Using Context-Sensitive Help . . . . . . . 23 Configuring Questions. . . . . . . . . . . 95
Troubleshooting Errors . . . . . . . . . 24 Defining Address Question Groups . . . . . 95
Using Special Characters . . . . . . . . . 24 Modifying Address Question Groups . . . . . 96
Deleting Address Question Groups . . . . . 96
Chapter 3. Configuring Defining Address Questions . . . . . . . . 96
Cross-Application Order Promising Modifying Address Questions . . . . . . . 97
Deleting Address Questions . . . . . . . . 98
Components . . . . . . . . . . . . 25 Defining Capacity Impact. . . . . . . . . 98
Configuring Cross-Application Order Promising Modifying Capacity Impact . . . . . . . . 99
Components . . . . . . . . . . . . . . 25 Deleting Capacity Impact . . . . . . . . . 99
What Is the Fulfillment Network Model? . . . . 25 Rearranging Address Question Entities . . . . 100
The Fulfillment Network Model Work Area and Defining Permit Question Groups . . . . . 100
Its Components . . . . . . . . . . . . 25 Modifying Permit Question Groups . . . . . 101
Defining Distribution Groups . . . . . . . 29 Deleting Permit Question Groups . . . . . 102
Defining Node Types . . . . . . . . . . 31 Defining Permit Questions . . . . . . . . 102
Defining Nodes . . . . . . . . . . . . 32 Modifying Permit Questions . . . . . . . 103
Defining Relationship Types . . . . . . . . 35 Deleting Permit Questions . . . . . . . . 103
Defining Relationships. . . . . . . . . . 36 Rearranging Permit Questionnaire Entities. . . 104
Defining Item Level Controls . . . . . . . . 38

© Copyright IBM Corp. 1999, 2012 iii

Chapter 5. Configuring Chapter 9. Configuring
Cross-Application Logistics Cross-Application Customer
Components . . . . . . . . . . . . 105 Components . . . . . . . . . . . . 153
Configuring Cross-Application Logistics Configuring Cross-Application Customer
Components. . . . . . . . . . . . . . 105 Components. . . . . . . . . . . . . . 153
Defining Logistics Attributes . . . . . . . . 105 Defining Region Usage for Selling . . . . . . 153
Defining Freight Terms . . . . . . . . . 105 Defining Customer Classifications . . . . . 154
Defining Carrier Modification Reasons . . . . 107 Defining Additional Customer Rules . . . . 156
Defining Additional Logistic Rules . . . . . 109 Defining Customer Definitions . . . . . . . 157
Defining Delivery Codes . . . . . . . . . 110 Creating a Customer Definition . . . . . . 157
Creating a Delivery Code . . . . . . . . 110 Modifying a Customer Definition. . . . . . 159
Modifying a Delivery Code . . . . . . . . 111 Deleting a Customer Definition . . . . . . 168
Deleting a Delivery Code . . . . . . . . 111 Defining Contact Types . . . . . . . . . . 168
Defining Shipment Modes . . . . . . . . . 112 Creating a Customer Contact Type . . . . . 168
Creating a Shipment Mode . . . . . . . . 112 Modifying a Customer Contact Type . . . . 169
Modifying a Shipment Mode . . . . . . . 112 Deleting a Customer Contact Type . . . . . 169
Deleting a Shipment Mode . . . . . . . . 113 Defining Customer Entitlements . . . . . . . 169
Defining Outbound Constraints . . . . . . . 113 Defining Customer Grades . . . . . . . . . 170
Creating a Routing Guide . . . . . . . . 116
Modifying a Routing Guide . . . . . . . 117 Chapter 10. Configuring a Document's
Deleting a Routing Guide . . . . . . . . 123 Attributes . . . . . . . . . . . . . 173
Configuring a Document's Attributes . . . . . 173
Chapter 6. Configuring Defining Order Types . . . . . . . . . . 173
Cross-Application Payment Creating an Order Type . . . . . . . . . 173
Components . . . . . . . . . . . . 125 Modifying an Order Type . . . . . . . . 174
Configuring Cross-Application Payment Deleting an Order Type . . . . . . . . . 174
Components. . . . . . . . . . . . . . 125 Defining Order Sources . . . . . . . . . . 174
System Payment Processing Rules . . . . . . 125 Creating an Order Source . . . . . . . . 175
Defining Payment Types. . . . . . . . . . 126 Modifying an Order Source. . . . . . . . 175
Creating a Payment Type . . . . . . . . 126 Deleting an Order Source . . . . . . . . 176
Modifying a Payment Type . . . . . . . . 130 Defining External References for the Order Level 176
Deleting a Payment Type . . . . . . . . 131 Creating an External Reference for the Order
Defining Payment Rules . . . . . . . . . . 131 Header Level . . . . . . . . . . . . 176
Creating a Payment Rule . . . . . . . . 131 Modifying an External Reference for the Order
Modifying a Payment Rule . . . . . . . . 135 Header Level . . . . . . . . . . . . 177
Deleting a Payment Rule . . . . . . . . 135 Deleting an External Reference for the Order
Header Level . . . . . . . . . . . . 177
Chapter 7. Defining Payment Card Defining External References for the Order Line
Level . . . . . . . . . . . . . . . . 177
Types . . . . . . . . . . . . . . . 137 Creating an External Reference for the Order
Creating a Payment Card Type . . . . . . . 137 Line Level . . . . . . . . . . . . . 177
Modifying a Payment Card Type . . . . . . . 140 Modifying an External Reference for the Order
Deleting a Payment Card Type . . . . . . . 140 Line Level . . . . . . . . . . . . . 178
Deleting an External Reference for the Order
Chapter 8. Configuring Line Level . . . . . . . . . . . . . 178
Cross-Application Pricing Defining Order Address Types . . . . . . . 179
Components . . . . . . . . . . . . 141 Creating an Order Address Type . . . . . . 179
Configuring Cross-Application Pricing Modifying an Order Address Type . . . . . 179
Components. . . . . . . . . . . . . . 141 Deleting an Order Address Type . . . . . . 180
Legacy Pricing Service . . . . . . . . . . 141 Defining Line Types . . . . . . . . . . . 180
Defining Pricing by Region . . . . . . . . 141 Creating a Line Type . . . . . . . . . . 180
Defining Price Programs and Price Lists . . . 142 Modifying a Line Type . . . . . . . . . 180
Pricing Service . . . . . . . . . . . . . 148 Deleting a Line Type . . . . . . . . . . 181
Defining Region Schema for Selling . . . . . 148 Defining Other Attributes . . . . . . . . . 181
Defining Pricing Organization Rules. . . . . 148 Generating a Prime Line Number for a New
Defining Pricing Enterprise Rules . . . . . 151 Line from a Pre-Configured Number . . . . 181

Chapter 11. Configuring a Document's

Order Validation . . . . . . . . . . 183
Configuring a Document's Order Validation . . . 183

iv Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 12. Configuring a Document's Deleting a Lead Origin . . . . . . . . . 200
Instruction Types. . . . . . . . . . 187
Configuring a Document's Instruction Types . . . 187 Chapter 19. Configuring an
Creating an Instruction Type . . . . . . . . 187 Opportunity Document's Lost Reason . 201
Modifying an Instruction Type . . . . . . . 188 Configuring an Opportunity Document's Lost
Deleting an Instruction Type . . . . . . . . 188 Reason . . . . . . . . . . . . . . . 201
Creating a Lost Reason . . . . . . . . . . 201
Chapter 13. Configuring a Document's Modifying a Lost Reason . . . . . . . . . 201
Modification Reasons . . . . . . . . 189 Creating a New Lost Reason Based on an Existing
Configuring a Document’s Modification Reasons 189 One . . . . . . . . . . . . . . . . 202
Creating a Modification Reason . . . . . . . 189 Deleting a Lost Reason . . . . . . . . . . 202
Modifying a Modification Reason . . . . . . 190
Deleting a Modification Reason . . . . . . . 190 Chapter 20. Configuring a Document's
Modification Components . . . . . . 203
Chapter 14. Configuring a Document's Configuring a Document’s Modification
Backorder Reasons. . . . . . . . . 191 Components. . . . . . . . . . . . . . 203
Configuring a Document's Backorder Reasons . . 191 Defining Modification Rules . . . . . . . . 203
Creating a Backorder Reason . . . . . . . . 191 Changing Modification Rules . . . . . . . 205
Modifying a Backorder Reason . . . . . . . 191 Defining Custom Modification Types . . . . . 206
Deleting a Backorder Reason . . . . . . . . 192 Creating a Custom Modification Type . . . . 207
Modifying a Custom Modification Type . . . 208
Deleting a Custom Modification Type . . . . 208
Chapter 15. Configuring a Document's Defining Modifications Impacting Pricing . . . . 208
Note Reasons . . . . . . . . . . . 193 Adding/Removing a Modification Type for
Configuring a Document's Note Reasons . . . . 193 Modifications Impacting Pricing . . . . . . 209
Creating a Note Reason . . . . . . . . . . 193 Defining Modifications Requiring Auditing . . . 209
Modifying a Note Reason . . . . . . . . . 193
Creating a New Note Reason Based on an Existing Chapter 21. Configuring an Order
One . . . . . . . . . . . . . . . . 194
Deleting a Note Reason . . . . . . . . . . 194
Document's Fulfillment-Specific
Components . . . . . . . . . . . . 211
Chapter 16. Configuring a Quote Configuring an Order Document's
Fulfillment-Specific Components . . . . . . . 211
Document's Approval Rule Violation Defining Hold Types . . . . . . . . . . . 211
Reason . . . . . . . . . . . . . . 195 Creating a Hold Type. . . . . . . . . . 211
Configuring a Quote Document’s Approval Rule Modifying a Hold Type . . . . . . . . . 224
Violation Reason . . . . . . . . . . . . 195 Deleting a Hold Type. . . . . . . . . . 224
Creating an Approval Rule Violation Reason . . . 195 Defining Order Tags . . . . . . . . . . . 225
Modifying an Approval Rule Violation Reason . . 195 Modifying an Order Tag. . . . . . . . . 227
Creating a New Approval Rule Violation Reason Deleting an Order Tag . . . . . . . . . 228
Based on an Existing One . . . . . . . . . 196 Defining Fulfillment Rules . . . . . . . . . 228
Deleting an Approval Rule Violation Reason . . . 196 Defining Approval Plans for Quotes . . . . . . 231
Defining Process Type Details . . . . . . . . 232
Chapter 17. Configuring a Document's Order Fulfillment: Process Type Pipeline
Line Relationship Type . . . . . . . 197 Configuration . . . . . . . . . . . . . 232
Configuring a Document’s Line Relationship Type 197 Order Fulfillment: Defining Pipeline
Defining a Line Relationship Type . . . . . . 197 Determination . . . . . . . . . . . . 232
Modifying a Line Relationship Type . . . . . . 197 Order Fulfillment: Pipelines . . . . . . . 233
Creating a New Line Relationship Type Based on Order Fulfillment: Transactions . . . . . . 235
an Existing One . . . . . . . . . . . . 198 Order Fulfillment: Statuses . . . . . . . . 238
Deleting a Line Relationship Type . . . . . 198 Order Fulfillment: Conditions . . . . . . . 241
Order Fulfillment: Actions . . . . . . . . 242
Defining Transaction Rules . . . . . . . . . 243
Chapter 18. Configuring an
Defining Transaction Rules for Quotes . . . . 247
Opportunity Document's Lead Origin . 199 Defining Status Inventory Types . . . . . . . 248
Configuring an Opportunity Document's Lead Creating a Status Inventory Type . . . . . . 250
Origin . . . . . . . . . . . . . . . . 199 Modifying a Status Inventory Type . . . . . 251
Creating a Lead Origin . . . . . . . . . 199 Deleting a Status Inventory Type . . . . . . 251
Modifying a Lead Origin . . . . . . . . 199 Defining Quote Rules . . . . . . . . . . 251
Creating a New Lead Origin Based on an Defining Monitoring Components . . . . . . 252
Existing One . . . . . . . . . . . . 200

Contents v
 Order Fulfillment: Defining Date Types. . . . 252 Modifying a Charge Category . . . . . . . 296
Order Fulfillment: Defining Milestones . . . . 254 Deleting a Charge Category . . . . . . . 297
Order Fulfillment: Defining Monitoring Events . . 256 Defining Tax Names . . . . . . . . . . . 297
Order Fulfillment: Creating an Event Rule. . . 257 Creating a Tax Name . . . . . . . . . . 297
Order Fulfillment: Modifying an Event . . . . 259 Modifying a Tax Name . . . . . . . . . 298
Order Fulfillment: Deleting an Event . . . . 259 Deleting a Tax Name . . . . . . . . . . 298
Defining Transaction Dependencies . . . . . . 259 Defining Additional Payment Rules . . . . . . 298
Defining a Default Dependency Group . . . . 260 Defining Additional Payment Rules for Quotes 301
Creating a Transaction Dependency Group . . 260 Defining Receiving Discrepancy Reasons . . . . 302
Modifying a Transaction Dependency Group 264 Creating a Receiving Discrepancy Reason . . . 302
Deleting a Transaction Dependency Group . . 264 Modifying a Receiving Discrepancy Reason . . 304
Deleting a Receiving Discrepancy Reason . . . 304
Chapter 22. Configuring an
Opportunity Document's Chapter 25. Configuring a Document's
Fulfillment-Specific Components . . . 265 Purge Criteria . . . . . . . . . . . 305
Configuring an Opportunity Document’s Configuring a Document's Purge Criteria . . . . 305
Fulfillment-Specific Components . . . . . . . 265 Modifying an Order Document Type's Purge
Opportunity Fulfillment: Configuring Process Type Criteria Rule . . . . . . . . . . . . 306
Pipelines . . . . . . . . . . . . . . . 265
Opportunity Fulfillment: Pipelines . . . . . 265 Chapter 26. Configuring Value-Added
Opportunity Fulfillment: Transactions . . . . 267 Services . . . . . . . . . . . . . 309
Opportunity Fulfillment: Statuses. . . . . . 268 Configuring Value-Added Services . . . . . . 309
Opportunity Fulfillment: Conditions. . . . . 269 Defining Value-Added Services Modification
Opportunity Fulfillment: Actions . . . . . . 270 Reasons . . . . . . . . . . . . . . . 309
Configuring a Load Document's Purge Criteria . . 270 Value-Added Services: Creating a Modification
Reason . . . . . . . . . . . . . . 309
Chapter 23. Configuring an Order Value-Added Services: Modifying a
Document's Shipment-Specific Modification Reason . . . . . . . . . . 309
Components . . . . . . . . . . . . 271 Value-Added Services: Creating a New
Configuring an Order Document's Modification Reason Based on an Existing One . 310
Shipment-Specific Components . . . . . . . 271 Value-Added Services: Deleting a Modification
Shipments: Defining Hold Types . . . . . . . 271 Reason . . . . . . . . . . . . . . 310
Shipments: Defining Process Type Details . . . . 271 Defining Value-Added Services Cancellation
Shipments: Process Type Pipeline Configuration 272 Reasons . . . . . . . . . . . . . . . 310
Shipments: Defining Pipeline Determination . . 272 Creating a Cancellation Reason . . . . . . 310
Shipments: Pipelines . . . . . . . . . . 273 Modifying a Cancellation Reason . . . . . . 311
Shipments: Transactions . . . . . . . . . 275 Creating a New Cancellation Reason Based on
Shipments: Statuses . . . . . . . . . . 278 an Existing One . . . . . . . . . . . 311
Shipments: Conditions . . . . . . . . . 280 Deleting a Cancellation Reason . . . . . . 312
Shipments: Actions . . . . . . . . . . 282 Defining Value-Added Services Appointment
Shipments: Defining Monitoring Components . . 282 Failure Reasons. . . . . . . . . . . . . 312
Shipments: Defining Date Types . . . . . . 282 Creating a Appointment Failure Reason . . . 312
Shipments: Defining Milestones . . . . . . 284 Modifying an Appointment Failure Reason . . 313
Shipments: Defining Monitoring Events . . . . 286 Creating a New Appointment Failure Reason
Shipments: Creating an Event Rule . . . . . 286 Based on an Existing One . . . . . . . . 313
Shipments: Modifying an Event . . . . . . 287 Deleting an Appointment Failure Reason . . . 314
Shipments: Deleting an Event . . . . . . . 287 Defining Value-Added Services Note Reasons . . 314
Defining Shipment Preferences . . . . . . . 288 Creating a Note Reason . . . . . . . . . 314
Over Shipping Preferences . . . . . . . . 288 Modifying a Note Reason . . . . . . . . 315
Transaction Rules . . . . . . . . . . . 290 Creating a New Note Reason Based on an
Existing One . . . . . . . . . . . . 315
Deleting a Note Reason . . . . . . . . . 315
Chapter 24. Configuring a Document's Defining Value-Added Services Instruction Types 315
Financial Components . . . . . . . 293 Value-Added Services: Creating an Instruction
Defining Payment Terms . . . . . . . . . 293 Type . . . . . . . . . . . . . . . 316
Creating a Payment Term . . . . . . . . 293 Value-Added Services: Modifying an Instruction
Modifying a Payment Term. . . . . . . . 293 Type . . . . . . . . . . . . . . . 316
Deleting a Payment Term . . . . . . . . 294 Value-Added Services: Deleting an Instruction
Defining Charge Definitions . . . . . . . . 294 Type . . . . . . . . . . . . . . . 317
Creating a Charge Category . . . . . . . 294 Defining Value-Added Services Rules . . . . . 317

vi Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Setting Up Value-Added Services Pre-Call Rules 317 Post Inventory Match. . . . . . . . . . 386
Setting Up Value-Added Services Other Rules 317 Process Order Hold Type . . . . . . . . 387
Defining Value-Added Services Modification Rules 318 Process Work Order Hold Type . . . . . . 389
Setting Up Value-Added Services Modification Publish Negotiation Results . . . . . . . 390
Rules . . . . . . . . . . . . . . . 318 Release . . . . . . . . . . . . . . 391
Defining Value-Added Services Hold Types . . . 320 Route Shipment . . . . . . . . . . . 393
Value-Added Services: Creating a Hold Type 320 Schedule . . . . . . . . . . . . . . 395
Value-Added Services: Modifying a Hold Type 322 Send Invoice . . . . . . . . . . . . 398
Value-Added Services: Deleting a Hold Type 323 Send Item Changes . . . . . . . . . . 399
Defining Value-Added Services Process Types . . 323 Send Customer Changes. . . . . . . . . 401
Viewing Value-Added Services Process Type Send Order . . . . . . . . . . . . . 402
Details . . . . . . . . . . . . . . 323 Send Release . . . . . . . . . . . . 403
Defining Value-Added Services Process Model . . 324 Start Order Negotiation . . . . . . . . . 405
Value-Added Services: Pipeline Determination 324 Synchronize Colony Map . . . . . . . . 406
Value-Added Services: Pipelines . . . . . . 325 Update Best Match Region . . . . . . . . 407
Value-Added Services: Transactions . . . . . 326 PopulateOwnershipTransferSummary . . . . 409
Value-Added Services: Statuses . . . . . . 327 Time-Triggered Purge Transactions . . . . . . 410
Value-Added Services: Conditions . . . . . 329 Purge Strategy . . . . . . . . . . . . 410
Value-Added Services: Actions . . . . . . 331 Configuring Purge Transaction Log Files . . . 410
Value-Added Services: Service Definitions . . . 332 Available Purges . . . . . . . . . . . 411
Viewing Value-Added Services Date Types . . 334 Task Queue Syncher Time-Triggered Transactions 491
Defining Value-Added Services Event Load Execution Task Queue Syncher . . . . 491
Monitoring . . . . . . . . . . . . . 336 Order Delivery Task Queue Syncher. . . . . 493
Viewing Value-Added Services Purge Criteria . . 338 Order Fulfillment Task Queue Syncher . . . . 493
Order Negotiation Task Queue Syncher . . . 494
Chapter 27. Time-Triggered Quote Fulfillment Task Queue Syncher . . . . 495
Transaction Reference . . . . . . . 341 Monitors . . . . . . . . . . . . . . . 496
Availability Monitor . . . . . . . . . . 497
Time-Triggered Transaction Reference . . . . . 341
Exception Monitor. . . . . . . . . . . 498
Running Time-Triggered Transactions . . . . . 342
Inventory Monitor. . . . . . . . . . . 500
Steps to Complete Before Scheduling
Negotiation Monitor . . . . . . . . . . 501
Time-Triggered Transactions . . . . . . . 342
Enhanced Order Monitor . . . . . . . . 502
Configuring Communication Between an Agent
Enhanced Quote Monitor . . . . . . . . 505
and a JMS Server . . . . . . . . . . . . 343
Enhanced Return Monitor . . . . . . . . 507
Prerequisites. . . . . . . . . . . . . 343
Real-time Availability Monitor . . . . . . . 509
Create an Initial Context Factory Code . . . . 343
Shipment Monitor . . . . . . . . . . . 516
Define the Transaction Information . . . . . 344
Work Order Monitor . . . . . . . . . . 518
Business Process Time-Triggered Transactions . . 345
Asynchronous Request Processor . . . . . . 345
Case Insensitive Data Loader . . . . . . . 347 Chapter 28. Order Modification Types 521
Change Load Status . . . . . . . . . . 348 Order Modification Types . . . . . . . . . 521
Change Shipment Status. . . . . . . . . 349
Close Delivery Plan . . . . . . . . . . 351 Chapter 29. Condition Builder
Close Load . . . . . . . . . . . . . 352 Attributes . . . . . . . . . . . . . 531
Close Manifest . . . . . . . . . . . . 353 Condition Builder Attributes . . . . . . . . 531
Close Order . . . . . . . . . . . . . 355 Sales Order . . . . . . . . . . . . . . 532
Close Receipts . . . . . . . . . . . . 357 Order Fulfillment . . . . . . . . . . . 532
Close Shipment. . . . . . . . . . . . 358 Order Negotiation . . . . . . . . . . . 534
Collect Shipment Statistics . . . . . . . . 360 Outbound Shipment . . . . . . . . . . 534
Consolidate Additional Inventory . . . . . 361 Receipt . . . . . . . . . . . . . . 536
Consolidate To Shipment . . . . . . . . 363 Planned Order . . . . . . . . . . . . . 536
Create Catalog Index . . . . . . . . . . 365 Planned Order Execution . . . . . . . . 536
Create Chained Order . . . . . . . . . 369 Planned Order Negotiation . . . . . . . . 536
Create Derived Order . . . . . . . . . 370 Return Order . . . . . . . . . . . . . 536
Create Order Invoice . . . . . . . . . . 371 Reverse Logistics . . . . . . . . . . . 536
Create Shipment Invoice. . . . . . . . . 373 Return Shipment . . . . . . . . . . . 537
ESP Evaluator . . . . . . . . . . . . 374 Return Receipt . . . . . . . . . . . . 537
Item Based Allocation . . . . . . . . . 375 Template Order. . . . . . . . . . . . . 538
Mark Load as Trailer Loaded . . . . . . . 379 Purchase Order. . . . . . . . . . . . . 538
Match Inventory . . . . . . . . . . . 380 Purchase Order Execution . . . . . . . . 538
Payment Collection . . . . . . . . . . 382 Purchase Order Negotiation . . . . . . . 540
Payment Execution . . . . . . . . . . 384

Contents vii
 Inbound Shipment. . . . . . . . . . . 541 Move Request Execution . . . . . . . . . 545
Purchase Order Receipt . . . . . . . . . 541 Manifesting . . . . . . . . . . . . . . 545
Transfer Order . . . . . . . . . . . . . 541 Over Pack Build . . . . . . . . . . . . 545
Transfer Order Execution . . . . . . . . 541 Count Execution . . . . . . . . . . . . 545
Transfer Order Delivery . . . . . . . . . 541 Pack Process. . . . . . . . . . . . . . 546
Transfer Order Receipt . . . . . . . . . 541 Outbound Picking . . . . . . . . . . . . 548
Master Order Fulfillment . . . . . . . . . 541 VAS Process . . . . . . . . . . . . . . 548
Quote Fulfillment . . . . . . . . . . . . 543 Opportunity . . . . . . . . . . . . . . 549
Load Execution. . . . . . . . . . . . . 543 Opportunity Fulfillment . . . . . . . . . 549
General . . . . . . . . . . . . . . . 543 Item-Based Allocation (IBA) Order . . . . . . 550
WMS Putaway . . . . . . . . . . . . . 544
WMS Layout Definition . . . . . . . . . . 544 Notices . . . . . . . . . . . . . . 553
WMS Inventory . . . . . . . . . . . . 544
Trailer Loading . . . . . . . . . . . . . 545
Index . . . . . . . . . . . . . . . 557
Task Execution . . . . . . . . . . . . . 545

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
IBM® 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 Warehouse Management System
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 FoundationSterling Application Platform
applications can be used. Therefore, there is no single way to configure your
Sterling Selling and Fulfillment FoundationSterling Application Platform
environment.

For example, your company might be considered a multi-divisional 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 FoundationSterling Application Platform configuration.

© Copyright IBM Corp. 1999, 2012 1

 Multi-Divisional Corporation
The multi-divisional corporation model is a business corporation whose primary
focus is managing purchase and sales activities. A typical multi-divisional
corporation can be a buyer, a seller, or both. It could also be a retailer, a
manufacturer, or both. Whatever form the multi-divisional corporation takes, it
normally has multiple channels with different types of customers, such as,
consumers, retailers, dealers, and original equipment manufacturers.

In the multi-divisional corporation model, each division might be set up as an

Enterprise in Sterling Selling and Fulfillment FoundationSterling Application
Platform. 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.

2 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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
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 25.

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” on page 141 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 153.

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.

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

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” on page 211 and “Configuring an
Order Document's Shipment-Specific Components” on page 271.

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

4 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
For more information about Purge Criteria, see Chapter 24, Configuring a
Document’s Purge Criteria.

Chapter 1. Introduction 5
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<application_name>/console/start.jsp
where,
v hostname is the computer name or IP address of the computer where Sterling
Selling and Fulfillment FoundationSterling Application Platform is installed.
v portnumber is the listening port of the computer where Sterling Selling and
Fulfillment FoundationSterling Application Platform 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 Configurator. 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
FoundationSterling Application Platform installation server>/
smcfs<application_name>/console/login.jsp.
If both the Applications ManagerConfigurator and the monitor in the System
Management Console Application System Management 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 FoundationSterling
Application Platform. The different configurations are defined by logical groupings
called applications that can be accessed from the Applications Manager menu bar.

© Copyright IBM Corp. 1999, 2012 7

 Figure 1. Applications Menu

Each application focuses on a particular aspect of Sterling Selling and Fulfillment

FoundationSterling Application Platform and contains all of the rules, common
codes, and settings necessary for Sterling Selling and Fulfillment
FoundationSterling Application Platform to work in a real-world business setting.

The following applications can be configured in this version of Sterling Selling and
Fulfillment FoundationSterling Application Platform:
v Distributed Order Management
v Global Inventory Visibility
v Catalog Management
v Logistics Management
v Supply Collaboration
v Reverse Logistics
v Warehouse Management
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.

8 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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.

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.

Chapter 2. Navigating the Applications Manager 9

 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 FoundationSterling Application Platform, 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 15.

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
FoundationSterling Application Platform are:
v Hub Level - Configuration groups that are associated with the Hub organization
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: Application Platform 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

10 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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.

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 1. 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 An Enterprise can view the
the Enterprise established by the configurations that are defined for
transactional context. For the other Enterprises (including the
example, order documents have Hub) in the inheritance hierarchy. In
a specific Enterprise. addition, the Enterprise can view the
configurations that are defined for
the Hub.

Chapter 2. Navigating the Applications Manager 11

 Table 1. Organization Level Rules (continued)
Organization Organizations That Can Modify
Level at this Level... Inheritance Details
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.

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.

12 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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.

Chapter 2. Navigating the Applications Manager 13

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

14 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 1 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
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.

Chapter 2. Navigating the Applications Manager 15

 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.

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.

16 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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.

Chapter 2. Navigating the Applications Manager 17

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.

18 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 ManagerConfigurator

Through the Applications ManagerConfigurator, you can use the lookup
functionality, view logged in users, use lists and list filtering, use Context-Sensitive
Help, troubleshoot errors, and use special characters.

Chapter 2. Navigating the Applications Manager 19

 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 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.

20 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 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.

Chapter 2. Navigating the Applications Manager 21

 4. Choose .

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.

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 2. 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" in
Figure 15 on page 23 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.

Table Filter Editor Window Example:

22 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Figure 15. Hold Type: Sales Order

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 16. Calendar Icon example

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

Figure 17. Time Field example

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

Applications Manager Configurator.

Using Context-Sensitive Help

About this task

You can access the Sterling Selling and Fulfillment FoundationSterling Application
Platform Context-Sensitive Help by clicking the Help button.

Chapter 2. Navigating the Applications Manager 23

 Troubleshooting Errors
About this task

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

To view the Sterling Selling and Fulfillment FoundationSterling Application

Platform 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 . A list of error codes and
their descriptions display.

3. Choose 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 FoundationSterling Application
Platform, see the Sterling Selling and Fulfillment Foundation: Customization Basics.

24 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

There are three main components in the Fulfillment Network Model work area, as
indicated in the screen shot below:

© Copyright IBM Corp. 1999, 2012 25

 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
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 3 on page 27
for descriptions of each action icon available.

26 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 3. 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 31.
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 35.
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 29.
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 29.
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 32.
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 34.

Chapter 3. Configuring Cross-Application Order Promising Components 27

 Table 3. Action Icons (continued)
Action Icon Description
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 36.
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 36.
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 37.
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 38.

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 4 on page 29 for field
value descriptions.

3. Once you have specified your filter criteria, select . The Map View is
updated with your filter criteria.

Upon clicking , your filter criteria is saved as a search. When revisiting the
Fulfillment Network Model, the most recently saved filter criteria and view is
used.

28 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 4. 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 31.
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 35.
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 Distribution Group Detail window displays.

Chapter 3. Configuring Cross-Application Order Promising Components 29

 3. In Distribution Group, enter the name of the distribution group.
4. In Description, enter a brief description of the distribution rule.
5. Choose .

Modifying a Distribution Group

About this task

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

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
Distribution Group Details screen displays.
3. Enter information into the applicable fields. Refer to Table 21 on page 73 for
field value descriptions.
4. Click .

30 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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 .

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 Node Type Details pop-up window displays.

3. Enter information into the applicable fields. Refer to Table 5 for field level
descriptions.
4. Choose .

Table 5. 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:

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.

Chapter 3. Configuring Cross-Application Order Promising Components 31

 2. Select the applicable node type and choose . The Node Type Details pop-up
window displays.
3. Enter information into the applicable fields. Refer to Table 5 on page 31 for field
level descriptions.
4. Choose .

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 .

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: Application Platform 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 6 on page 33 for field
value descriptions.
3. Click .

32 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 6. 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.
Parent Organization Select the node's parent organization.

Chapter 3. Configuring Cross-Application Order Promising Components 33

 Table 6. Create Node Screen (continued)
Field Description
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: Application Platform 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 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: Application Platform Configuration Guide.
2. Enter information into the applicable fields.
3. Click .

34 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 Relationship Type Detail screen displays.

3. Enter information into the applicable fields. Refer to Table 7 for field value
descriptions.
4. Click .

Table 7. 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
Relationship Type Detail screen displays.

Chapter 3. Configuring Cross-Application Order Promising Components 35

 3. Enter information into the applicable fields. Refer to Table 7 on page 35 for field
value descriptions.
4. Choose .

Deleting a Relationship Type

About this task

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

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 .

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” on page 37.

36 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 8. 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.
2. Select the Add Relationships action icon. The Relationships Creation Criteria
Details window displays.
3. Enter information into the applicable fields. Refer to Table 8 for field value
descriptions.
4. Choose OK.

Results

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

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 .

Chapter 3. Configuring Cross-Application Order Promising Components 37

 Results
Table 9. 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.
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 57.

38 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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 . A list of product items
displays.
3. Select the applicable item and choose . The Item Level Control pop-up
window displays.
4. Enter information into the applicable fields. Refer to Table 10 for field value
descriptions.
5. Choose .

Table 10. 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 for the
enterprise. After you define the enterprise's levels of service, set up notification
periods at the node level for the enterprise's different levels of service. See
“Creating a Notification Period” on page 49 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 39

 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 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 .

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 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 .

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.

40 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 2. Select the applicable level of service and choose .

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
57.

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 . A list of node displays.

3. Select the applicable node and choose . The Node Details pop-up window
displays.
4. Enter information into the applicable fields. Refer to Table 11 on page 42 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: Application
Platform Configuration Guide.
5. Choose .

Chapter 3. Configuring Cross-Application Order Promising Components 41

Figure 18. Node Details

Table 11. 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.

42 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 11. 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 86.
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.

Chapter 3. Configuring Cross-Application Order Promising Components 43

 Table 11. 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: Application
Platform 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.

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 Relationship Details pop-up window displays.

4. Enter information into the applicable fields. Refer to Table 12 on page 45 for
field value descriptions.
5. Choose .

44 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 12. Relationship Details Pop-Up 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. 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.

Chapter 3. Configuring Cross-Application Order Promising Components 45

 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
Relationship Details pop-up window displays.
4. Enter information into the applicable fields. Refer to Table 12 on page 45 for
field value descriptions.
5. Choose .

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 .

Creating a Transfer Schedule

About this task

To create a transfer schedule:

Procedure
1. From the Relationship Details screen, choose from the Transfer Schedules
panel. The Transfer Schedule window displays.
2. Enter information into the applicable fields. For field value descriptions see
Table 13 on page 47.

3. Click .

46 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 13. 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.

Chapter 3. Configuring Cross-Application Order Promising Components 47

 Table 13. Transfer Schedule Window (continued)
Field Description
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:

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

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 .

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 non-working 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.

48 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 . A list of nodes displays.

3. Select the applicable node and choose . 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 14 on page 50 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 .

Chapter 3. Configuring Cross-Application Order Promising Components 49

 Table 14. 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 39 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 . A list of nodes displays.

3. Select the applicable node and choose . 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
Notification Period Details pop-up window displays.
6. Enter information into the applicable fields. Refer to Table 14 for field value
descriptions.

7. Choose .

50 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 . A list of nodes displays.

3. Select the applicable node and choose . 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 to delete it (or
choose to see more details about the Notification Period before deleting it
on the Node Details pop-up window).

6. Choose .

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 39 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 . A list of nodes displays.

3. Select the applicable node and choose . 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
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 14 on page 50 for
field value descriptions.

8. Choose .

Chapter 3. Configuring Cross-Application Order Promising Components 51

 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 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 .

Modifying a Fulfillment Type

About this task

To modify a fulfillment type:

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 > Fulfillment Types. The
Fulfillment Types window displays in the work area.

2. Select the applicable fulfillment type and choose . 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 .

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 .

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 15 on page 54 for
field value descriptions.
3. Choose .

Chapter 3. Configuring Cross-Application Order Promising Components 53

 Table 15. 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 52.
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.
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 75.

54 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 15. Sourcing Basic Configuration Window (continued)
Field Description
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 71.
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 75.
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 75.

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 Order Sourcing Classification Details pop-up window displays.

Chapter 3. Configuring Cross-Application Order Promising Components 55

 3. In Order Sourcing Classification, enter the name of the sourcing classification.
4. In Short Description, enter the name of the short description.
5. In Long Description, enter the name of the long description.
6. Click .

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 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 .

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 .

Sourcing Region Selection

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

You can associate region schemas with the following:

56 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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.

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

Chapter 3. Configuring Cross-Application Order Promising Components 57

 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:

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 Scheduling Rule Details screen displays.

58 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
3. Enter information into the applicable fields. Refer to Table 16 for field value
descriptions.
4. Choose .
Table 16. 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

Chapter 3. Configuring Cross-Application Order Promising Components 59

 Table 16. Scheduling Rule Details Screen (continued)
Field Description
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.
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.

60 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 16. Scheduling Rule Details Screen (continued)
Field Description
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
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.

Chapter 3. Configuring Cross-Application Order Promising Components 61

 Table 16. Scheduling Rule Details Screen (continued)
Field Description
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.
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 64.
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

62 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 16. Scheduling Rule Details Screen (continued)
Field Description
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.
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 69.
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 64.

Chapter 3. Configuring Cross-Application Order Promising Components 63

 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 Scheduling Rule
Details screen displays.
3. Modify information into the applicable fields. Refer to Table 16 on page 59 for
field value descriptions.
4. Choose .

Deleting a Scheduling Rule

About this task

To delete 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 .

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 57, or the Sterling Selling and Fulfillment Foundation: Product Concepts
Guide.

Promising selects the sourcing option with the least landed cost. Landed cost is
comprised of 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 17 on page 65 for
field value descriptions.

64 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
3. Choose .

Table 17. 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.

Chapter 3. Configuring Cross-Application Order Promising Components 65

 Table 17. Landed Cost Window (continued)
Field Description
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.
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 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 67.
Convert Node Priority into Check this box to use the priority of the node to be converted
Cost into cost.

When this box is checked, the node with a lower priority is

considered when optimizing on cost.
Node Priority Cost Factor Enter the cost factor for the node. You can enter values to this
field only when the "Convert Node Priority into Cost" is
enabled.

Choose the currency for the cost from the drop-down list.

To create a new currency, choose

and enter information to the applicable fields. For more

information about defining the currency for the node priority
cost factor, see Currency Details.

66 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Currency Details
You can define the currency for the node priority cost factor in the currency details
pop-up window.

Figure 19. Currency Details

Table 18. 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 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.

2. In the Enterprise Node Type Rules panel, choose . 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 19 on page 68 for
field value descriptions.

4. Choose .

Chapter 3. Configuring Cross-Application Order Promising Components 67

 Table 19. 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.

68 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 19. Enterprise Node Type Rule Pop-up Window (continued)
Field Description
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 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 19 on page 68 for
field value descriptions.
4. Choose .

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
.

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.

Chapter 3. Configuring Cross-Application Order Promising Components 69

 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.
2. Enter information into the applicable fields. Refer to Table 20 for field value
descriptions.
3. Choose .

Table 20. Forwarding/Transfer Rules Window

Field Description
Forwarding Rules

70 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 20. Forwarding/Transfer Rules Window (continued)
Field Description
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 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.

For backward compatibility purposes, you can also create rules for individual
items at a source node or for the entire source node.

Chapter 3. Configuring Cross-Application Order Promising Components 71

 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 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 .

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 Distribution Details pop-up window displays.
3. Enter information into the applicable fields. Refer to Table 21 on page 73 for
field value descriptions.
4. Choose .

72 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 21. 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:

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 Distribution Details
pop-up window displays.
3. Enter information into the applicable fields. Refer to Table 21 for field value
descriptions.
4. Choose .

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

About this task

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

Chapter 3. Configuring Cross-Application Order Promising Components 73

 Procedure
1. In the Distribution Group Details window, choose the Distribution Detail tab.

2. Select the applicable distribution detail and choose .

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 Distribution Details pop-up

window displays.
3. Enter information in the applicable fields. Refer to the following table for field
value descriptions.
4. Choose .

Table 22. 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
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.

74 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 22. Advanced Distribution Details window (continued)
Field Description
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
.

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 .

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
v Order Sourcing Classification
v Seller organization
v Item ID

Chapter 3. Configuring Cross-Application Order Promising Components 75

 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 Sourcing Rule for Product Being Shipped window displays.
3. Enter information into the applicable fields. Refer to Table 23 on page 77 for
field value descriptions.
4. Choose .

76 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 23. 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
52.
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 55.
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.
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 56.
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.

Chapter 3. Configuring Cross-Application Order Promising Components 77

 Table 23. Sourcing Rule for Product Being Shipped Window (continued)
Field Description
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 57.

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 90.

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 Product Sourcing Rules
Search window displays.
3. Enter information into the applicable fields. Refer to Table 23 on page 77 for
field value descriptions.
4. Choose .

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 .

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.

78 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 Sourcing Rule for Product Being Delivered window displays.
3. Enter information into the applicable fields. Refer to Table 24 for field value
descriptions.
4. Choose .

Table 24. 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
52.

Chapter 3. Configuring Cross-Application Order Promising Components 79

 Table 24. Sourcing Rule for Product Being Delivered Window (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 55.
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 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 56.
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 44 and “Defining
Procurement Rules” on page 86.
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 57.

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 90.

80 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Modifying a Delivery Service 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 Delivered >
Sourcing Rules. The Delivery Service Sourcing Rules Search window displays in
the work area.

2. Select the applicable sourcing rule and choose . The Sourcing Rule for
Product Being Delivered window displays.
3. Enter information into the applicable fields. Refer to Table 24 on page 79 for
field value descriptions.
4. Choose .

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 .

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.
2. Choose . The Distribution Group Detail window displays.

Chapter 3. Configuring Cross-Application Order Promising Components 81

 3. In Distribution Group, enter the name of the distribution rule.
4. In Description, enter a brief description of the distribution rule.
5. Choose .

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 Distribution Details pop-up window displays.

3. Enter information into the applicable fields. Refer to Table 25 for field value
descriptions.
4. Choose .

Table 25. Distribution Details Window

Field Description
Source

82 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 25. Distribution Details Window (continued)
Field Description
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 Distribution Details
pop-up window displays.
3. Enter information into the applicable fields. Refer to Table 25 on page 82 for
field value descriptions.
4. Choose .

Provided Service 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 .

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 .

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:

Chapter 3. Configuring Cross-Application Order Promising Components 83

 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 Sourcing Rule for Provided Service window displays.

3. Enter information into the applicable fields. Refer to Table 26 on page 85 for
field value descriptions.
4. Choose .

84 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 26. 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
52.
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 55.
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 56.
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 57.

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 90.

Chapter 3. Configuring Cross-Application Order Promising Components 85

 Modifying a Provided Service 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 > 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 Sourcing Rule for
Provided Service window displays.
3. Enter information into the applicable fields. Refer to Table 26 on page 85 for
field value descriptions.
4. Choose .

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 .

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 44.

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.

86 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
2. Choose . The Sourcing Rules for Procurement window displays.
3. Enter information into the applicable fields. Refer to Table 27 for field value
descriptions.

Table 27. 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 52.
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 55.
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.

Chapter 3. Configuring Cross-Application Order Promising Components 87

 Table 27. Sourcing Rules for Procurement Window (continued)
Field Description
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 57.

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 90.

4. Choose .

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.
2. Select the applicable sourcing rule and choose . The Sourcing Rules for
Procurement window displays.
3. Enter information into the applicable fields. Refer to Table 27 on page 87 for
field value descriptions.
4. Choose .

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 .

88 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 Distribution Group Detail window displays.

3. Enter information into the applicable fields. Refer to Table 28 for field value
descriptions.

Table 28. 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 .

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.

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

Chapter 3. Configuring Cross-Application Order Promising Components 89

 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 .

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 from the Sourced From List panel.
The Sourced From Details pop-up window displays.
2. Enter information into the applicable fields. Refer to Table 29 on page 91 for
field value descriptions.

3. Choose .

Figure 20. Sourced From Details Window

90 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 29. 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 44 and “Defining
Procurement Rules” on page 86.
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 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

Chapter 3. Configuring Cross-Application Order Promising Components 91

 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:

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

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 .

92 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: Application Platform 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 . A list of node displays.
Select the node to which you want to assign the supervisor and choose .
The Supervisor Setup pop-up window displays.

3. Enter information in the applicable fields. See Table 30 on page 94 for field
value descriptions.
4. Choose .

© Copyright IBM Corp. 1999, 2012 93

 Table 30. 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.

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 Nodes list displays.
Select the node for which you want to assign a supervisor and choose . The
Supervisor Setup pop-up window displays.
3. Enter information in the applicable fields. See Table 30 for field value
descriptions.
4. Choose .

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 . A list of node displays.
Select the node to which you want to assign a supervisor and choose . 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 .
4. Choose .

94 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 Question Group Details pop-up window displays.

Table 31. 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. See Table 34 on page 101 for field
value descriptions.
4. Choose .

Chapter 4. Configuring Cross-Application Service Execution Components 95

 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 Question
Group Details pop-up window displays.
3. Enter information in the applicable fields. See Table 34 on page 101 for field
value descriptions.
4. Choose .

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 .

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
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 Question
Details pop-up window displays.

96 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 32. 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. See Table 35 on page 102 for field
value descriptions.
4. Choose .

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 Question Details
pop-up window displays.
3. Enter information in the applicable fields. See Table 35 on page 102 for field
value descriptions.
4. Choose .

Chapter 4. Configuring Cross-Application Service Execution Components 97

 Deleting Address Questions
About this task

To delete 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 delete, and choose .

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 Answer Option Details pop-up window displays.

98 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 33. 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 33 for field value
descriptions.
4. Choose .

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 Answer Option Details pop-up window displays.
3. Enter information in the applicable fields. See Table 33 for field value
descriptions.
4. Choose .

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 Answer Option Details pop-up window displays.
3. Select the Capacity Impact you want to delete and choose .

Chapter 4. Configuring Cross-Application Service Execution Components 99

 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
v Change a follow-up question into a stand-alone 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.

100 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 2. Choose . The Question Group Details pop-up window displays.

Table 34. 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 34 for field value
descriptions.
4. Click .

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.

Chapter 4. Configuring Cross-Application Service Execution Components 101

 2. Select the question group you want to modify and click . The Question
Group Details pop-up window displays.
3. Enter information in the applicable fields. See Table 34 on page 101 for field
value descriptions.
4. Choose .

Deleting Permit Question Groups

About this task
To delete 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 delete, and choose .

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 Question
Details pop-up window displays.

Table 35. 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.

102 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 35. Question Details (continued)
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 35 on page 102 for
field value descriptions.
4. Choose .

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 Question Details
pop-up window displays.
3. Enter information in the applicable fields. Refer to Table 35 on page 102 for
field value descriptions.
4. Choose .

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 .

Chapter 4. Configuring Cross-Application Service Execution Components 103

 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 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
v Change a follow-up question into a stand-alone 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.

104 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 Freight Terms Details pop-up window displays.

4. Enter information in the applicable fields. Refer to Table 36 on page 106 for
field value descriptions.
5. Enter Choose .

© Copyright IBM Corp. 1999, 2012 105

 Table 36. 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.

106 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 3. Select the applicable freight term and choose . The Freight Terms Details
pop-up window displays.
4. Enter the new information in the applicable fields. Refer to Table 36 on page
106 for field value descriptions.
5. Choose .

Deleting a Freight Term

About this task

To delete 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 .

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 Modify Carrier Reason Details pop-up window displays.

Chapter 5. Configuring Cross-Application Logistics Components 107

 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 .

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 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.

6. Choose .

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 .

108 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 37 for field value
descriptions.
4. Choose .
Table 37. 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.

Chapter 5. Configuring Cross-Application Logistics Components 109

 Table 37. 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 .

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:

110 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 > Delivery Codes. The Delivery Codes window displays in the work
area.

2. Choose . 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 .

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 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 .

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 .

Chapter 5. Configuring Cross-Application Logistics Components 111

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.

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 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 .

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 Shipment Mode
Details pop-up window displays.

112 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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 .

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 .

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.

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 38 on page 114 for
field value descriptions.

3. Choose .

Chapter 5. Configuring Cross-Application Logistics Components 113

 Table 38. 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

114 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 38. Outbound Constraint Window (continued)
Field Description
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.
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”
on page 116.

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 105.
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.

Chapter 5. Configuring Cross-Application Logistics Components 115

 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 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 39 for field value
descriptions.
4. Choose .

Figure 21. Routing Guide Details Window

Table 39. 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.

116 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 39. Routing Guide Details Window (continued)
Field Description
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 .
3. The Routing Guide Details window displays in the work area.
4. Enter information in the applicable fields. Refer to Table 39 on page 116 for
field value descriptions.
5. Choose .

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.

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 re-routes,
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.).

Chapter 5. Configuring Cross-Application Logistics Components 117

 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.

Figure 22. Routing Guide Details Window

3. Select . A Routing Guide Line Details screen displays in the work area.
4. Enter information in the applicable fields. Refer to Table 40 on page 119 for
field value descriptions.
5. Choose .

118 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 40. 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.
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:

Chapter 5. Configuring Cross-Application Logistics Components 119

 Table 40. Routing Guide Line Details (continued)
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 121.
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.

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.

120 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 Carrier Services window displays.

2. Enter information in the applicable fields. Refer to Table 41 for field value
descriptions.
3. Choose .
Table 41. 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.

Chapter 5. Configuring Cross-Application Logistics Components 121

 Table 41. Carrier Services (continued)
Field Description
Contact Address This is used to specify the address information for the carrier
service's contact person. Click to change the contact
Address.

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 Carrier Services window displays.
2. Enter the new information in the applicable fields. Refer to Table 41 on page
121 for field value descriptions.
3. Choose .

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 .

2. Choose .

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 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 .

Deleting a Routing Guide Line

About this task

To delete a Routing Guide Line:

122 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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
.

Deleting a Routing Guide

About this task

To delete 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 applicable Routing Guide and choose .

Chapter 5. Configuring Cross-Application Logistics Components 123

124 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 42 for field value
descriptions.
Table 42. 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

© Copyright IBM Corp. 1999, 2012 125

 Table 42. System Payment Processing Rules Window (continued)
Field Description
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 .

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 Payment Type Details pop-up window displays.

3. Enter information in the applicable fields. Refer to Table 43 on page 127 for
field value descriptions.

4. Choose .

126 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 43. 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
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.

Chapter 6. Configuring Cross-Application Payment Components 127

 Table 43. Payment Type Details Pop-Up Window (continued)
Field Description
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.
Charge Up To Available Select this field to allowing charging up to the available
amount. This field is only available for payment types in the
Stored Value Card payment type group.
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 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.

128 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 43. Payment Type Details Pop-Up Window (continued)
Field Description
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.
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.
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

Chapter 6. Configuring Cross-Application Payment Components 129

 Table 43. Payment Type Details Pop-Up Window (continued)
Field Description
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.
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:

130 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 > Payment Types. The Payment Types window displays in the work
area.

2. Select the applicable payment type and choose . The Payment Type Details
pop-up window displays.
3. Enter information in the applicable fields. Refer to Table 43 on page 127 for
field value descriptions.
4. Choose .

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 .

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 Payment Rule Details pop-up window displays.

3. Enter information in the applicable fields. Refer to Table 44 on page 132 for
field value descriptions.
4. Choose .

Chapter 6. Configuring Cross-Application Payment Components 131

 Table 44. 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.

132 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 44. Payment Rule Pop-Up Window (continued)
Field Description
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.
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.

Chapter 6. Configuring Cross-Application Payment Components 133

 Table 44. Payment Rule Pop-Up Window (continued)
Field Description
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.
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 45, 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 45. 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)

134 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 45. Standard and Delayed Reauthorization (continued)
Before Order is Scheduled
Configuration Before Order is and Each Time <n> Hours
Options Scheduled Authorization Expires Before Release
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 Payment Rule Details
pop-up window displays.
3. Modify information in the applicable fields. Refer to Table 44 on page 132 for
field value descriptions.
4. Choose .

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 .

Chapter 6. Configuring Cross-Application Payment Components 135

136 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 7. 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
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 Payment Card Type Details pop-up window displays.

3. Enter information in the applicable fields. Refer to Table 46 on page 138 for
field value descriptions.

4. Choose .

© Copyright IBM Corp. 1999, 2012 137

 Table 46. 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 a payment type group 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.

138 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 46. Payment Card Type Details Window (continued)
Field Description
Authorization Reversal Select Do Not Reverse if you do not want to implement an
Strategy 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.
Use Same Authorization Select Yes if you want to allow the same authorization for
Multiple Times multiple transactions.

If you want to inherit Use Same Authorization Multiple

Times from the Payment Type Details window, leave this field
blank.
Charge Consolidation Select Yes if you want to consolidate charge requests.
Allowed
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 If you selected Charge Consolidation Allowed, enter the
(Hrs) timeframe (in hours) for charges to be consolidated within.

Chapter 7. Defining Payment Card Types 139

 Table 46. Payment Card Type Details Window (continued)
Field Description
Allow Authorization To Select Yes to allow an authorization amount to exceed a
Exceed Settlement Request 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 Use this field to record the number of hours before
Authorization Expiration authorization for a particular credit card expires; this can be
used in the executeCollection API.
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;
this can be used in the executeCollection API.

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 Payment Card
Type Details pop-up window displays
3. Enter information in the applicable fields. Refer to Table 46 on page 138 for
field value descriptions.
4. Choose .

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 .

140 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 8. Configuring Cross-Application Pricing Components
Configuring Cross-Application Pricing Components
For the Sterling Selling and Fulfillment Foundation Release 9.1:
v The pricing functionality described in Section 4.1, "Configuring
Cross-Application Pricing Components", has been deprecated.
v The new pricing functionality for the Sterling Selling and Fulfillment
Foundation, Release 9.1 is described in “Pricing Service” on page 148.
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: Application Platform 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 47 on page 142 for
field value descriptions.
3. Choose .

© Copyright IBM Corp. 1999, 2012 141

 Table 47. 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: Application Platform Configuration
Guide.

142 Sterling Selling and Fulfillment Foundation: Distributed Order Management 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 Price List Details window displays.

3. Enter information in the applicable fields. Refer to Table 48 for field values.
4. Choose .

Table 48. 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:

Chapter 8. Configuring Cross-Application Pricing Components 143

 About this task

To add items to a price list:

Procedure

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

Modifying an Item Price List:

About this task
Table 49. 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 to add item price set
Range
details.

Choose to modify a detail.

Choose to delete a detail.

144 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 49. 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 141.
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 from
the Item Level Pricing list. The Item Price Set Details window displays.
2. Enter information in the applicable fields. Refer to Table 49 on page 144 for
field value descriptions.
3. Choose .

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 .

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 Price Set Details window
displays.
4. In Description, enter a brief description of the price list.
5. Choose .

Chapter 8. Configuring Cross-Application Pricing Components 145

 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 .

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 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 .

Adding a New Price List to a Price Program:

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

To add a new price list to a price program:

Procedure

1. In the Price Program Details window, choose 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 .

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 .

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 Price Program Details
window displays.
3. In Description, enter a brief description of the price program.

4. Choose .

Chapter 8. Configuring Cross-Application Pricing Components 147

 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 .

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 153.

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:

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 50 on page 149 for
field value descriptions.
3. Choose .

148 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 50. 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.

Chapter 8. Configuring Cross-Application Pricing Components 149

 Table 50. Pricing Organization Rules: Sales Order Window (continued)
Field Description
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.
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 .

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

150 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 50. Pricing Organization Rules: Sales Order Window (continued)
Field Description
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.

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 51 on page 152 for
field value descriptions.
3. Choose .

Chapter 8. Configuring Cross-Application Pricing Components 151

 Table 51. 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.

152 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 9. 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: Application Platform 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 141.
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 52 on page 154
for the field value description.

© Copyright IBM Corp. 1999, 2012 153

 Table 52. 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 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 53 for field value
descriptions.
5. Choose .
Table 53. 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 . In the

Search pop-up window, enter applicable search criteria and
choose . 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:

154 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 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 .

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.
3. Select the applicable customer classification code and click . 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 .

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 .

Chapter 9. Configuring Cross-Application Customer Components 155

 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
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.

156 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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. Click .

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 Customer pop-up window displays.

3. Enter information into the applicable fields. Refer to the following table for
field value descriptions.

Chapter 9. Configuring Cross-Application Customer Components 157

 Table 54. 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
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

158 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 54. Create Customer Window (continued)
Field Description
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 .

Modifying a Customer Definition

About this task

To modify 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 . A list of customers displays.

3. Locate the applicable customer and choose . 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 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 to define a new one, to modify an existing one, or to delete an
existing one.

Chapter 9. Configuring Cross-Application Customer Components 159

 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 to edit the
organization details. For more information about configuring organizations, see the
Sterling Selling and Fulfillment Foundation: Application Platform 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 to
define a new one, to modify an existing one, or 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.

160 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Refer to the following table for field value descriptions:
Table 55. 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.

Chapter 9. Configuring Cross-Application Customer Components 161

 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.

Refer to the following table for field value descriptions:

Table 56. 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.

162 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 56. Customer Scheduling Constraints (continued)
Field Description
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:

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 to add an additional customer contact.

3. Select the Customer Contact Info tab.

Chapter 9. Configuring Cross-Application Customer Components 163

 4. Enter information in the applicable fields. Refer to the following table for field
values.
Table 57. 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.

164 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 57. Customer Contact Information (continued)
Field Description
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 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:
Table 58. 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.

Chapter 9. Configuring Cross-Application Customer Components 165

 2. Choose 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 to add an additional address.
3. Enter information in the applicable fields. Refer to the following table for field
values.

166 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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 to enter the additional address.

5. Choose OK.

Chapter 9. Configuring Cross-Application Customer Components 167

 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 . A list of customers displays.

3. Locate the applicable customer and choose .

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:

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 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 .

168 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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 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 .

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 .

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.
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 .

Chapter 9. Configuring Cross-Application Customer Components 169

 Table 59. 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 60 on page 171.

170 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 60. 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 .

Chapter 9. Configuring Cross-Application Customer Components 171

172 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 10. 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 Order Type Details pop-up window displays.

© Copyright IBM Corp. 1999, 2012 173

 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 .

Modifying an Order Type

About this task

To modify 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 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 .

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 .

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.

174 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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 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 .

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 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 .

Chapter 10. Configuring a Document's Attributes 175

 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 .

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 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 .

176 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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 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 .

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 .

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:

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.

Chapter 10. Configuring a Document's Attributes 177

 3. From the Order Line External References list choose . 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 .

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 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 .

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 .

178 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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.

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 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 .

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 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.

Chapter 10. Configuring a Document's Attributes 179

 6. Choose .

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 .

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 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 .

Modifying a Line Type

About this task

To modify a line type:

180 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 Line Types tab.
3. Select the applicable line type and choose . The Line Type Details pop-up
window displays.
4. In Description, enter a brief description of the line type.
5. Choose .

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 .

Defining Other Attributes

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

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. Choose .

Chapter 10. Configuring a Document's Attributes 181

 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())

182 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 11. 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 61 on page 184 for
field value descriptions.
3. Choose .

© Copyright IBM Corp. 1999, 2012 183

 Table 61. 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.

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: Application Platform 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: Application Platform
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.

184 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 61. Order Validation Pop-Up Window (continued)
Field Description
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 .

Chapter 11. Configuring a Document's Order Validation 185

186 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 12. 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 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 .

© Copyright IBM Corp. 1999, 2012 187

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.

2. Select the applicable instruction type and choose . 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 .

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 .

188 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 13. 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 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 re-priced 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 re-pricing needs to occur against a reduced quantity: the quantity
against which the order line is re-priced (re-pricing quantity) is adjusted to the
reduced quantity. For more information about re-pricing 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.

© Copyright IBM Corp. 1999, 2012 189

 7. Choose .

Modifying a Modification Reason

About this task

To modify 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 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 re-priced 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 re-pricing needs to occur against a reduced quantity: the quantity
against which the order line is repriced (re-pricing quantity) is adjusted to the
reduced quantity. For more information about re-pricing 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 .

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 .

190 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 14. 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 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 .

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.

© Copyright IBM Corp. 1999, 2012 191

 2. Select the applicable backorder reason and choose . 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 .

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 .

192 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 15. 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 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 .

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 Note
Reason Details window displays.

© Copyright IBM Corp. 1999, 2012 193

 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 .

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 Note Reason Details
window displays.
3. Enter information in the applicable fields.
4. Choose .

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
Confirmation window displays.
3. Choose OK.

194 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 16. 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 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 .

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.

© Copyright IBM Corp. 1999, 2012 195

 2. Select the applicable approval rule violation reason and click . 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 .

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 Approval
Rule Violation Reason Details window is displayed.
3. Enter information in the applicable fields.
4. Click .

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
Confirmation window is displayed.
3. Click OK.

196 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 17. 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 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 .

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 Relationship Type Details
window appears.
3. In Short Description, enter a brief description of the relationship type.

© Copyright IBM Corp. 1999, 2012 197

 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 .

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.

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 Relationship Type
Details window appears.
3. Enter information in the applicable fields
4. Choose .

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 Confirmation
window appears.
3. Choose OK.

198 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 18. 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 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 .

Modifying a Lead Origin

About this task

To modify a lead origin:

© Copyright IBM Corp. 1999, 2012 199

 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 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 .

Creating a New Lead Origin Based on an Existing One

About this task

To create a new lead origin based on an existing one:

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 Lead Origin Details
window displays.
3. Enter information in the applicable fields.
4. Choose .

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 Confirmation window
displays.
3. Choose OK.

200 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 19. 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 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 .

Modifying a Lost Reason

About this task

To modify a lost reason:

© Copyright IBM Corp. 1999, 2012 201

 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 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 .

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 Lost Reason Details
window displays.
3. Enter information in the applicable fields.
4. Choose .

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 Confirmation window
displays.
3. Choose OK.

202 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 20. 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.

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

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 for defining modification rules, custom
modification types, and modifications impacting pricing.

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. 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.

© Copyright IBM Corp. 1999, 2012 203

 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
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 521.

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 window by modification

type, modification level, or status, by selecting the corresponding grouping from
Group By. The Modification Rules window 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 62. 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.

204 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 62. Order Document Type Rule Modifications (continued)
Field Description
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: Application Platform
Configuration Guide.

Changing Modification Rules

About this task

To change modification rules:

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

Chapter 20. Configuring a Document's Modification Components 205

 2. Expand the applicable modification types and levels for which you want to set
up rules.
3. Right click on the applicable rule and choose allow, disallow, or ignore as per
your business practices. Refer to Table 62 on page 204 for field value
descriptions.

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 for which rules that determine when these attributes can
and cannot be modified can be defined.

Once created, the custom modification type displays under the modification rules
for the business document of the process type you are defining. From there 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.

206 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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, choose . The Custom Modification

window displays.Enter information in the applicable fields. Refer to Table 63
for field value descriptions.

3. Choose . A pop-up warning you to sign out of the application for changes
to take place displays.

Table 63. 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.

Chapter 20. Configuring a Document's Modification Components 207

 Table 63. Custom Modification Window (continued)
Field Description
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
choose .
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 choose .

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 choose . The Custom Modification window displays.
3. Enter information in the applicable fields. Refer to Table 63 on page 207 for
field value descriptions.
4. Choose .

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 choose .

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.

208 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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 Modification

Type List window displays.
3. To add a modification type to the Modifications Impacting Pricing list, select
the desired modification type(s) from the Modification Types and choose .
4. To remove a modification type from the Modifications Impacting Pricing list,
select the desired modification type(s) from the Modification Types and choose
.

5. Choose .

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 .

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 .
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 .

5. Choose .

Chapter 20. Configuring a Document's Modification Components 209

210 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 21. 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: Application Platform 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 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 64 on page 212, Table 65 on
page 213, and Table 66 on page 214 for field value descriptions.

© Copyright IBM Corp. 1999, 2012 211

 6. Click .

Table 64. 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.

212 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 64. Hold Type Pop-Up Window, Hold Creation Tab (continued)
Field Description
When The Following Check this box for modification types that automatically
Modifications Are apply this hold type to a shipment.
Performed
Click 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 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: Application
Platform 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.
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 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 65. 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

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 213

 Table 65. Hold Type Pop-Up Window, Hold Resolution Tab (continued)
Field Description
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 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 66. 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 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.
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 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:

214 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 > Hold Types. The Hold Types window displays
in the work area.

2. Click 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 67, Table 68 on page 217 and Table 69 on page 219.
6. Click .

Table 67. 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.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 215

 Table 67. Hold Type Screen, Hold Creation tab (continued)
Field Description
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.
When The Following Modification types that automatically apply this hold type to
Modifications Are an order.
Performed
Click 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 to
build or modify the condition that is evaluated. For more
information about using the condition builder, see the Sterling
Selling and Fulfillment Foundation: Application Platform
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.

216 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 67. Hold Type Screen, Hold Creation tab (continued)
Field Description
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 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 68. 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.
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 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.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 217

218 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 69. 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 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 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 21. Configuring an Order Document's Fulfillment-Specific Components 219

 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.

2. Click 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 70 on page 221, Table 71 on page 222 and Table 72 on page 224.
6. Click .

220 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 70. 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 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.
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
to build or modify the condition that is evaluated. For
more information about using the condition builder, see the
Sterling Selling and Fulfillment Foundation: Application Platform
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.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 221

 Table 70. Hold Type Screen, Hold Creation tab (continued)
Field Description
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 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 71. 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.
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 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.

222 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 223
 Table 72. Hold Type Screen, Hold Effects tab
Fields Description
The Following Transactions Transactions that are disallowed when this hold type is is
Will Be Stopped From applied to an order.
Processing Orders On This
Hold Click 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 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 Hold Type pop-up window
displays.
3. Enter information in the applicable fields. See Table 64 on page 212, Table 65 on
page 213 and Table 66 on page 214 for field value descriptions.

4. Click .

Deleting a Hold Type

About this task

To delete a hold type:

224 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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 .

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 to create
a new order tag. The Order Tag Detail window is displayed.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 225

 Results

Table 73 contains field definitions.

Table 73. 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: Application Platform 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 to open the Condition
Following Order 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.
For Orders Satisfying The
If you click this check box, click to open the Condition
Following Order Line
Detail pop-up window and define the Condition ID, Name,
Condition
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 to open the Modification
Modifications Are
Type List pop-up window and enable available Modification
Performed
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 74, which describes the field definitions.

Table 74. 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.

226 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 74. Condition Detail pop-up window (continued)

Condition Value This field contains information you enter in the General
Condition Builder. Click to display the General Condition
Builder.

The Sterling Selling and Fulfillment Foundation: Application

Platform Configuration Guide contains information about
Condition Builder attributes, and the Catalog Management:
Configuration Guide contains information about using the
Condition Builder.

Following is an example of the Modification Type List, followed by Table 75, which
describes its fields.

Table 75. 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 .
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 .

Modifying an Order Tag

About this task

To modify an Order Tag:

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 227

 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 Order Tag Detail pop-up
window displays. Enter information in the applicable fields. For field value
descriptions, see Table 73 on page 226.
3. Click .

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 .

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 76 on page 229 for
field value descriptions.
3. Click .

228 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 76. 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 pre-defined 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 pre-defined 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 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.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 229

 Table 76. Order Fulfillment window (continued)
Field Description
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.
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.

230 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Defining Approval Plans for Quotes
About this task

One or more approvals are often required for quotes, depending on the approval
rules that are applicable for the quote. You can define an approval plan to
determine who must approve a quote, and the sequence in which the approvals
must occur.

To define an approval plan for quotes:

Procedure
1. From the tree in the application rules side panel, select Document Specific >
Quote > Fulfillment > Approval Plans. The Approval Plan Details window is
displayed in the work area.
2. Enter information in the applicable fields. For field value descriptions, refer to
Table 77.

Table 77. Approval Plan Details Window

Field Description
Approval Sequence Indicates the sequence of the approvals.
Approval Name Enter the name of an approval.
Team Code From the drop-down list, select a team to approve the quotes.
User Group From the drop-down list, select a user group (role) within the
team to approve the quotes.
Predecessor Sequence Enter the sequence number, which is associated with an
approval sequence, of predecessor approvers.

You can specify multiple predecessors by using commas, for

example, 1,2,3.
Note: Approvers do not necessarily need to approve in this
sequence.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 231

 Table 77. Approval Plan Details Window (continued)
Field Description
Is Approval Mandatory Check this box if the specified approver must approve the
quote regardless of whether approval rules have been
violated or not, and regardless of the approval hierarchy.

3. Click .

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: Application Platform 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: Application
Platform 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.

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

232 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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 AfcFnd_Common/
c_ConditionBuilderAttributes.dita.

Order Fulfillment: Pipelines

About this task

For more information about configuring pipelines, see the Sterling Selling and
Fulfillment Foundation: Application Platform 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.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 233

 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.

Results

For more information about creating and modifying a pipeline, see the Sterling
Selling and Fulfillment Foundation: Application Platform Configuration Guide.

234 Sterling Selling and Fulfillment Foundation: Distributed Order Management 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: Application Platform 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 .
3. The Transactions tab window displays.

Results

For more information about creating and modifying transactions, see the Sterling
Selling and Fulfillment Foundation: Application Platform Configuration Guide.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 235

 Table 78. 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.

236 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 78. Order Fulfillment Pipeline - Transactions Tab Window (continued)
Field Description
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.
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.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 237

 Table 78. Order Fulfillment Pipeline - Transactions Tab Window (continued)
Field Description
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: Application Platform Configuration Guide.

To view the status 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.

238 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
2. In the Order Fulfillment window, choose .
3. The Statuses tab window displays.

Results

For more information about creating and modifying statuses, see the Sterling Selling
and Fulfillment Foundation: Application Platform Configuration Guide.

Table 79. Order Fulfillment Pipeline - Statuses Tab Window

Field Description
Draft Order Created This indicates that a draft order has been created.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 239

 Table 79. Order Fulfillment Pipeline - Statuses Tab Window (continued)
Field Description
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, or another third-party warehouse management
system.
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 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.

240 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 79. Order Fulfillment Pipeline - Statuses Tab Window (continued)
Field Description
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: Application Platform 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 .

3. The Conditions tab window displays.

Results

For more information about creating and modifying conditions, see the Sterling
Selling and Fulfillment Foundation: Application Platform Configuration Guide.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 241

 Table 80. 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.

242 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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: Application Platform 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 .

3. The Actions tab window displays.

Results

For more information about creating and modifying actions, see the Sterling Selling
and Fulfillment Foundation: Application Platform 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” on page 247.

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 Table 81 on page 244 for
field value descriptions.
3. Choose .

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 243

 Table 81. Transactions Rules Window
Field Description
Ship Advice

244 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 81. Transactions Rules Window (continued)
Field Description
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.
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 pre-defined

(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: Application Platform
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:
Application Platform Configuration Guide.
Cancellation of Order Lines with Work Orders

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 245

 Table 81. 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

246 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 81. 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 82 for field value
descriptions.
3. Choose .

Table 82. Transaction Rules Window for Quotes

Field Description
Order Monitor

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 247

 Table 82. Transaction Rules Window for Quotes (continued)
Field Description
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.
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 83. 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.

248 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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
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 84
on page 250 for assistance.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 249

 Table 84. 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 to create a status inventory type:

Procedure
1. In the Status Inventory Types window, choose . The Status Inventory Type
Details window displays.
2. Enter information in the applicable fields. Refer to Table 85 on page 251 for
field value descriptions.
3. Choose .

250 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 85. 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, 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 Status Inventory Type Details window displays.
2. Enter information in the applicable fields. Refer to Table 85 for field value
descriptions.
3. Choose .

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 .

Default status inventory types which are originally shipped with Sterling Selling
and Fulfillment Foundation cannot be deleted.

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.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 251

 2. Enter information in the applicable fields. Refer to Table 86 for field value
descriptions.
3. Choose .

Table 86. 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: Application Platform 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 Date Type Details window displays.
3. Enter information in the applicable fields. Refer to Table 87 on page 253 for
field value descriptions.

252 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
4. Choose .

Figure 23. Date Type Details

Table 87. 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
Date Type Details window displays.
3. Enter information in the applicable fields. Refer to Table 87 for field value
descriptions.
4. Choose .

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 .

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 253

 Results

The following system dates cannot be deleted:

v Delivery Date
v Order Date
v Ship Date
v Next Iteration Date

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 Milestone Details window displays.
3. Enter information in the applicable fields. Refer to Table 88 for field value
descriptions.
4. Choose .

Table 88. 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.

254 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 88. Milestone Details (continued)
Field Description
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 Status Milestone Details
window displays.
3. Enter information in the applicable fields. Refer to Table 89 for field value
descriptions.
4. Choose .

Table 89. 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.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 255

 Table 89. Status Milestone Details (continued)
Field Description
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
Milestone Details window displays.
3. Enter information in the applicable fields. Refer to Table 88 on page 254 for
field value descriptions.
4. Choose .

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 .

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
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".

256 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 Monitor Events Details window
displays.
3. Enter information in the applicable fields. Refer to Table 90 for field value
descriptions.
4. Choose .

Table 90. 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.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 257

 Table 90. Monitor Event Details Pop-Up Window (continued)
Field Description
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.
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.

258 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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 Monitor Event Details window displays.
3. Enter information in the applicable fields. Refer to Table 90 on page 257 for
field value descriptions.
4. Choose .

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.

2. From the Monitor Events list, select the applicable event rule and choose .

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.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 259

 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.

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 91 for field value
descriptions.
3. Choose .

Table 91. 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:

260 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 > Transaction Dependencies. The Transaction
Dependency window for the chosen document type displays.

2. From the Transaction Dependency Groups list, choose . The Transaction

Dependency Group Detail window displays.
3. Enter information into the applicable fields. Refer to Table 92 for field value
descriptions.
4. Choose .
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.”

Table 92. 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.”
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 from the
Transaction Dependency Rules list. The Transaction Dependency Rule Detail
window displays.
2. Enter information into the applicable fields. Refer to Table 93 for field value
descriptions.
3. Choose .

Table 93. Transaction Dependency Rule Detail Window

Field Description
Dependency Enter the name for this transaction dependency.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 261

 Table 93. Transaction Dependency Rule Detail Window (continued)
Field Description
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 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: Application Platform
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 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
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 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 94 on page 263 for
field value descriptions.
3. Choose OK.

262 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 94. 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 Dependency Detail window for
the chosen constraint displays.
2. Edit the information in the applicable fields. Refer to Table 94 for field value
descriptions.
3. Choose .

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.

2. Choose .

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 Transaction
Dependency Rule Detail window for the chosen constraint displays.
2. Edit the information in the applicable fields. Refer to Table 93 on page 261 for
field value descriptions.
3. Choose OK.

Chapter 21. Configuring an Order Document's Fulfillment-Specific Components 263

 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 .

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 Transaction
Dependency Group Details window displays.
3. Edit the information in the applicable fields. Refer to Table 92 on page 261 for
field value descriptions.
4. Choose .

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 .

264 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 22. 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: Application
Platform 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: Application Platform Configuration Guide.

To view the Opportunity Fulfillment pipeline details:

© Copyright IBM Corp. 1999, 2012 265

 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.

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

For more information about creating and modifying a pipeline, see the Sterling
Selling and Fulfillment Foundation: Application Platform 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: Application Platform 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 tab window, containing the information described in Table 95,
is displayed.

Table 95. Opportunity Fulfillment Pipeline - Transactions Tab Window

Field Description
Change Opportunity This transaction represents any modifications that may be
made to an opportunity.

Chapter 22. Configuring an Opportunity Document's Fulfillment-Specific Components 267

 Table 95. Opportunity Fulfillment Pipeline - Transactions Tab Window (continued)
Field Description
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: Application Platform 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: Application Platform 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 tab window, containing the information described in Table 96 on
page 269, is displayed.

268 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 96. 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: Application Platform 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: Application Platform Configuration Guide.

To view the condition details of an Opportunity Fulfillment pipeline:

Chapter 22. Configuring an Opportunity Document's Fulfillment-Specific Components 269

 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 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: Application Platform 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.

For more information about Actions, see the Sterling Selling and Fulfillment
Foundation: Application Platform 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 tab window is displayed.

Results

For more information about creating and modifying actions, see the Sterling Selling
and Fulfillment Foundation: Application Platform Configuration Guide.

Configuring a Load Document's Purge Criteria

REQTEXT

270 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 23. 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:
Application Platform 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: Application Platform Configuration Guide.

© Copyright IBM Corp. 1999, 2012 271

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: Application
Platform 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.

272 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: Application Platform 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.

Chapter 23. Configuring an Order Document's Shipment-Specific Components 273

 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: Application Platform Configuration Guide.

274 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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: Application Platform 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 .
3. The Transactions tab window displays.

Chapter 23. Configuring an Order Document's Shipment-Specific Components 275

 Results

For more information about creating and modifying transactions, see the Sterling
Selling and Fulfillment Foundation: Application Platform Configuration Guide.

Table 97. 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.

276 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 97. Outbound Shipment Pipeline - Transactions Tab Window (continued)
Field Description
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.
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.

Chapter 23. Configuring an Order Document's Shipment-Specific Components 277

 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: Application Platform 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 .

3. The Statuses tab window displays.

Results

For more information about creating and modifying statuses, see the Sterling Selling
and Fulfillment Foundation: Application Platform Configuration Guide.

278 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 98. 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: Application Platform Configuration
Guide.

Chapter 23. Configuring an Order Document's Shipment-Specific Components 279

 Table 98. 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: Application Platform
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: Application Platform 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: Application Platform 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 .

3. The Conditions tab window displays.

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

For more information about creating and modifying conditions, see the Sterling
Selling and Fulfillment Foundation: Application Platform Configuration Guide.

Table 99. 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: Application Platform
Configuration Guide.

Chapter 23. Configuring an Order Document's Shipment-Specific Components 281

 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: Application Platform 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 .

3. The Actions tab window displays.

Results

For more information about creating and modifying actions, see the Sterling Selling
and Fulfillment Foundation: Application Platform 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: Application Platform 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.

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 Date Type Details window displays.
3. Enter information in the applicable fields. Refer to Table 100 on page 283 for
field value descriptions.
4. Choose .

282 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 100. 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
Date Type Details window displays.
3. Enter information in the applicable fields. Refer to Table 100 for field value
descriptions.
4. Choose .

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 .

Results

The following system dates cannot be deleted:

v Delivery Date
v Ship Date

Chapter 23. Configuring an Order Document's Shipment-Specific Components 283

 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 Milestone Details window displays.
3. Enter information in the applicable fields. Refer to Table 101 for field value
descriptions.
4. Choose .

Table 101. 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.

284 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 101. Milestone Details (continued)
Field Description
Milestone Statuses You can add statuses to associate with the milestone by
selecting 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.
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
Milestone Details window displays.
3. Enter information in the applicable fields. Refer to Table 101 on page 284 for
field value descriptions.
4. Choose .

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 .

Chapter 23. Configuring an Order Document's Shipment-Specific Components 285

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".

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 Monitor Events Details window
displays.
3. Enter information in the applicable fields. Refer to Table 102 on page 287 for
field value descriptions.
4. Choose .

286 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 102. 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.

2. From the Monitor Events list, select the applicable event rule and choose .
The Monitor Event Details window displays.
3. Enter information in the applicable fields. Refer to Table 102 for field value
descriptions.
4. Choose .

Shipments: Deleting an Event

About this task

To delete an event rule:

Chapter 23. Configuring an Order Document's Shipment-Specific Components 287

 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 .

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 Shipping Preference Details

pop-up window displays.

288 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
4. Enter information into the applicable fields. Refer to Table 103 for field value
descriptions.
5. Choose .

Table 103. 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.

Chapter 23. Configuring an Order Document's Shipment-Specific Components 289

 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 . A list of preferences

displays.

4. Select the applicable preference and choose . The Shipping Preference

Details pop-up window displays.
5. Enter information into the applicable fields. Refer to Table 103 on page 289 for
field value descriptions.
6. Choose .

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 . A list of preferences

displays.

4. Select the applicable preference and choose .

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 104 on page 291 for
field value descriptions.
4. Choose .

290 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Figure 24. Transaction Rules, Shipping Preference

Table 104. 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 23. Configuring an Order Document's Shipment-Specific Components 291

292 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 24. 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 pre-defined 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 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 .

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 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 .

© Copyright IBM Corp. 1999, 2012 293

 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 .

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, 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 298.

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 Charge Category Details window displays.

294 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 .

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:

Procedure
1. In the Charge Category Details window, choose . The Charge Name Details
pop-up window displays.

Chapter 24. Configuring a Document's Financial Components 295

 2. In Charge Name, enter the charge name.
3. In Description, enter a brief description of the charge name.

4. Choose .

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 Charge Name Details pop-up window displays.
2. In Description, enter a brief description of the charge name.

3. Choose .

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 .

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 Charge Category
Details window displays.

296 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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 .

Deleting a Charge Category

About this task

To delete a charge definition:

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 .

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 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.

Chapter 24. Configuring a Document's Financial Components 297

 7. Choose .

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 Tax Name Details pop-up
window displays.
4. In Short Description, enter a brief description of the tax name.
5. In Long Description, enter a more detailed description of the tax name.
6. Choose .

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 .

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” on page 301.

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.

298 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
2. Enter information in the applicable fields. Refer to the following table for field
value descriptions.
3. Choose .

Results
Table 105. Payment 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
to exceed the amount charged.
Validate Charge Name Check this box to indicate that the system is
to check that the charge names used for an
order document are valid before proceeding
with payment collection.
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.

Chapter 24. Configuring a Document's Financial Components 299

 Table 105. Payment Rules (continued)
Field Description
Allow Refunding of Negative Debts Before When "Do Not Allow Debit And Credit
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.
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.
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 pre-paid 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 pre-paid exchange order will be
charged for the entire amount of the
advanced pre-paid 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.
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.
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.

300 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 105. Payment Rules (continued)
Field Description
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 294.
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.

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 106 on page 302 for
field value descriptions.
3. Choose .

Chapter 24. Configuring a Document's Financial Components 301

 Table 106. 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 294.

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.

2. Choose . The Receiving Discrepancy Reason Details pop-up window

displays.
3. Enter information into the applicable fields. Refer to Table 107 on page 303 for
field value descriptions.
4. Choose .

302 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 107. 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.

Chapter 24. Configuring a Document's Financial Components 303

 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 Receiving

Discrepancy Reason Details pop-up window displays.
3. Enter information into the applicable fields. Refer to Table 107 on page 303 for
field value descriptions.
4. Choose .

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 .

304 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 25. 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 108 lists the purge rules provided for order document types in Sterling
Selling and Fulfillment Foundation.
Table 108. 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 305

 Table 108. 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 109 lists the purge rules provided for the opportunity document type in
Sterling Selling and Fulfillment Foundation.
Table 109. 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 110 on page 307 for
field value descriptions.

3. Choose .

306 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 110. 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.
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 .
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.

Chapter 25. Configuring a Document's Purge Criteria 307

 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.
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.

308 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 26. 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 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 .

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 309

 3. Select the applicable modification reason and choose . 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 .

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 Modification
Reason Details window displays.
4. Enter information in the applicable fields.
5. Choose .

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 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:

310 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 > Cancellation
Reasons. The Cancellation Reasons window displays in the work area.
3. Choose . 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 .

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 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 .

Creating a New Cancellation Reason Based on an Existing

One
About this task

To create a new cancellation reason based on an existing one:

Chapter 26. Configuring Value-Added Services 311

 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 Cancellation
Reason Details window displays.
4. Enter information in the applicable fields.
5. Choose .

Deleting a Cancellation Reason

About this task

To delete 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 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 Appointment Failure Reason Details window displays.

312 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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 .

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
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 .

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.

Chapter 26. Configuring Value-Added Services 313

 3. Select the applicable appointment failure reason and choose . The
Appointment Failure Reason Details window displays.
4. Enter information in the applicable fields.
5. Choose .

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

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 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.

314 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 6. Choose .

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 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 .

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 Note Reason Details
window displays.
3. Enter information in the applicable fields.

4. Choose .

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

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.

Chapter 26. Configuring Value-Added Services 315

 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
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 .

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
Instruction Type Details pop-up window displays.

3. Select the applicable instruction type and choose . 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 .

316 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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
Instruction Type Details pop-up window displays.

3. Select the applicable instruction type and choose .

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.

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 .

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.

Chapter 26. Configuring Value-Added Services 317

 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.
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 .

Defining Value-Added Services Modification Rules

You can configure the 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.

Most work 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 appointments. Sterling Selling and
Fulfillment Foundation supports modification through the Sterling Selling and
Fulfillment Foundation Consoles 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.

Setting Up Value-Added Services Modification Rules

About this task

You can group modifications in the Modification Rules window by modification

type, modification level, or status, by selecting the corresponding grouping from
Group By. The Modification Rules window then displays the grouping you have
chosen in a hierarchical structure.

To set up Value-Added Services modification rules:

318 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 Rules. The Modification Rules window displays in the work
area.

3. Expand the applicable modification types and levels for which you want to set
up rules.
4. Select the Value-Added Services process whose Modification Rule is to be set,
and choose any of the following option as per your business practices:

v to allow modification

v to disallow modification

v to ignore modification
5. Refer to the following table for settings definition you can apply to
modifications:
Table 111. Value-Added Services Rule Modifications
Field Description
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.
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.

Chapter 26. Configuring Value-Added Services 319

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: Application Platform 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 Hold Type pop-up window displays. The type of this hold in
the Hold Type field, and its description in the Description field. Enter the rest
of the information in the applicable fields. Refer to Table 112, Table 113 on page
321 and Table 114 on page 322 for field value descriptions.
3. Click .

Table 112. 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.

320 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 112. Hold Type window, Hold Creation tab (continued)
Field Description
When The Following Modification types that automatically apply this hold type to
Modifications Are a work order.
Performed
Click 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
to build or modify the condition for evaluation. For more
information about using the condition builder, see the Sterling
Selling and Fulfillment Foundation: Application Platform
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.
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 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 113. 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

Chapter 26. Configuring Value-Added Services 321

 Table 113. Hold Type window, Hold Resolution tab (continued)
Field Description
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 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 114. 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 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.
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 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.

322 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 2. Select the applicable hold type and click . The Hold Type pop-up window
displays. Enter information in the applicable fields. Refer to Table 112 on page
320, Table 113 on page 321 and Table 114 on page 322 for field value
descriptions.
3. Click .

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 .

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.

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.

Chapter 26. Configuring Value-Added Services 323

 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.

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

324 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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: Application Platform Configuration
Guide.

Chapter 26. Configuring Value-Added Services 325

 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.
3. In the VAS window, choose . The Transactions tab window displays.

Results

For more information about creating, modifying, or deleting transactions, see the
Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide.

Table 115. 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.

326 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 Statuses tab window displays.

Results

For more information about creating, modifying, or deleting statuses, see the
Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide.

Chapter 26. Configuring Value-Added Services 327

 Table 116. 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.

328 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 116. Statuses Tab Window (continued)
Field Description
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 tab window displays.

Results

For more information about creating, modifying, or deleting conditions, see the
Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide.

Chapter 26. Configuring Value-Added Services 329

 Table 117. 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.

330 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 tab window displays.

Results

For more information about creating, modifying, or deleting actions, see the
Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide.

Chapter 26. Configuring Value-Added Services 331

 Table 118. 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.
3. In the VAS window, choose . The Service Definitions tab window displays.

Results

For more information about creating, modifying, or deleting service conditions, see
the Sterling Selling and Fulfillment Foundation: Application Platform Configuration
Guide.

332 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 119. Service Conditions Tab Window
Field Description
Service Definitions Displays service definitions that are specific to the VAS
pipeline.

Chapter 26. Configuring Value-Added Services 333

 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.

334 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 120. Monitoring: Work Order - Date Types
Field Description
Date Type The name of VAS date type.

Chapter 26. Configuring Value-Added Services 335

 Table 120. Monitoring: Work Order - Date Types (continued)
Field Description
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 121. View Events
Field Description
Event ID The event ID.
Description A brief description of the event.

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.

336 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Figure 25. Monitor Event Details

4. Enter information in the applicable fields. Refer to Table 122 for field value
descriptions.
5. Choose .
Table 122. 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.

Chapter 26. Configuring Value-Added Services 337

 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 Monitor Event Details window
displays.
4. Enter information in the applicable fields. Refer to Table 122 on page 337 for
field value descriptions.
5. Choose .

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 Monitor Event Details window
displays.
4. Choose .

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 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.

338 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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.
2. From the Distributed Order Management tree, choose VAS > VAS Process >
Purge Criteria. The Purge Criteria List window displays.

Table 123. 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.

Chapter 26. Configuring Value-Added Services 339

340 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 27. Time-Triggered Transaction Reference
Time-Triggered Transaction Reference
Sterling Selling and Fulfillment FoundationSterling Application Platform 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 GuidePlatform
Property File Management for File System Users 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 FoundationSterling Application Platform 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 FoundationSterling Application Platform 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.

© Copyright IBM Corp. 1999, 2012 341

 v ExecuteMessageSuccess - The number of jobs that were run successfully in a
given time interval.
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
FoundationSterling Application Platform.

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 FoundationSterling Application Platform 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
FoundationSterling Application Platform 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 FoundationSterling
Application Platform 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: Application
Platform Configuration Guide. Each set of time-triggered transaction criteria
parameters must ensure the appropriate association of a JMS Agent Server.

342 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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:
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
344.

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)

Chapter 27. Time-Triggered Transaction Reference 343

 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:

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 343.
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).

344 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 11. Select the Initial Context Factory code you created. See “Create an Initial
Context Factory Code” on page 343.
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 343.
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: Application Platform Configuration
Guide.

Business Process Time-Triggered Transactions

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 FoundationApplication.

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
ConsolePlatform System Management and Administration Guide.

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. Some of the
business transactions in the Sterling Warehouse Management System also insert the
messages into the YFS_ASYNC_REQ table.

Chapter 27. Time-Triggered Transaction Reference 345

 Attributes

Following are the attributes for this time-triggered transaction:

Table 124. Asynchronous Request Processor Attributes
Attribute Value
Base Transaction ID ASYNC_REQ_PROCESSOR
Base Process Type General
Abstract Transaction No

Criteria Parameters

Following are the criteria parameters for this transaction:

Table 125. 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

346 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Events Raised

The following events are raised by this time-triggered transaction:

Table 126. 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
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 127. 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 128. Case Insensitive Data Loader Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

Chapter 27. Time-Triggered Transaction Reference 347

 Table 128. Case Insensitive Data Loader Criteria Parameters (continued)
Parameter Description
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.
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.

348 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Attributes

The following are the attributes for this time-triggered transaction:

Table 129. 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 130. Change Load 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 131. 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.

Chapter 27. Time-Triggered Transaction Reference 349

 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 132. 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

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 133. 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 134. 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.

350 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 422).

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.

Attributes

The following are the attributes for this time-triggered transaction:

Table 135. 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 136. 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 137. Close Delivery Plan Statistics
Statistic Name Description
NumDeliveryPlansClosed Number of delivery plans closed.

Chapter 27. Time-Triggered Transaction Reference 351

 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 138. 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

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 436).

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 139. 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

352 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 140. 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.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 141. 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 142. 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.

Chapter 27. Time-Triggered Transaction Reference 353

 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.

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 143. 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 144. 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 Warehouse Management System 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.

354 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 144. Close Manifest 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

The following are statistics are tracked for this transaction:

Table 145. 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.

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 146. 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.

Chapter 27. Time-Triggered Transaction Reference 355

 Attributes

The following are the attributes for this time-triggered transaction:

Table 147. 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 148. Close 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 149. 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.

356 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Events Raised

The following events are raised by this time-triggered transaction:

Table 150. 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 151. 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
APIs Called None
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 152. 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 Mandatory. Node for which the Close Receipts needs to be
run.
AgentCriteriaGroup Used to classify nodes. This value can be accepted by Sterling
Warehouse Management System 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.

Chapter 27. Time-Triggered Transaction Reference 357

 Statistics Tracked

The following statistics are tracked for this transaction:

Table 153. 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').

Events Raised

The following events are raised by this time-triggered transaction:

Table 154. 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

When multiple inbound shipments are received into the same location, and the
inventory received is not license plated, an error message, "There is no inventory
for put away at the SourceLocation" displays. The solution to this problem lies in
one of these steps:
v Manually create move requests for receipts that you already received. For more
information about creating move requests, refer to the Sterling Selling and
Fulfillment Foundation: Warehouse Management System User Guide.
v For receipts that are expected to be received, ensure that the inventory is license
plated and that you don't receive inbound shipments and inventory for put
away into the same location.

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 473).

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.

358 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 155. 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 156. 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.
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 157. 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.

Chapter 27. Time-Triggered Transaction Reference 359

 Events Raised

The following events are raised by this time-triggered transaction:

Table 158. 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 159. 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
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 160. 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 warehouse management ship node for which
records are being processed.
AgentCriteriaGroup Optional. Used to classify nodes. This value can be accepted
by Sterling Warehouse Management System 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.

360 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 160. Collect Shipment Statistics 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

The following statistics are tracked for this transaction:

Table 161. 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.

Events Raised

The following events are raised by this time-triggered transaction:

Table 162. 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.

Chapter 27. Time-Triggered Transaction Reference 361

 Attributes

The following are the attributes for this time-triggered transaction:

Table 163. 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 164. 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.
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 165. 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.

362 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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. List of attributes it matches is actually based on
Document Template for Document Type of the Order.

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
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(), and releaseOrder() APIs in the Sterling Selling and Fulfillment
Foundation: Javadocs.

Attributes

The following are the attributes for this time-triggered transaction:

Table 166. 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()

Chapter 27. Time-Triggered Transaction Reference 363

 Table 166. Consolidate to Shipment Attributes (continued)
Attribute Value
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 167. 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.
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 168. 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.

364 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Events Raised

The following events are raised by this time-triggered transaction:

Table 169. 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

The Index Building Process

The Create Catalog Index transaction provides an agent for index building. Index
building is a multi-thread 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 multi-thread 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.

Chapter 27. Time-Triggered Transaction Reference 365

 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:
- 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 170. 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

366 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following table displays the criteria parameters for the Create Catalog Index
transaction.
Table 171. 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.
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.

Chapter 27. Time-Triggered Transaction Reference 367

 Table 171. Create Catalog Index Criteria Parameters (continued)
Parameter Description
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.

Statistics Tracked

The following table shows the statistics for the Create Catalog Index transaction.
Table 172. 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 173. 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

368 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 174. 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()

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 175. 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.

Chapter 27. Time-Triggered Transaction Reference 369

 Statistics Tracked

The following statistics are tracked for this transaction:

Table 176. 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
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 177. 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

370 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 with the Order. Otherwise, an exception is thrown.

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 178. 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 179. 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.

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.

Chapter 27. Time-Triggered Transaction Reference 371

 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 373.

Attributes

The following are the attributes for this time-triggered transaction:

Table 180. 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 181. 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.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 182. 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.

372 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 371.

Attributes

The following are the attributes for this time-triggered transaction:

Table 183. 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()

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 184. 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 185. Create Shipment Invoice Statistics
Statistic Name Description
NumShipmentInvoicesCreated Number of shipment invoices created.

Chapter 27. Time-Triggered Transaction Reference 373

 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.

Attributes

The following are the attributes for this time-triggered transaction:

Table 186. 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 187. 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.

374 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 187. ESP Evaluator 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.
Node Required. The warehouse management ship node for which
records are being processed.
AgentCriteriaGroup Optional. Used to classify nodes. This value can be accepted
by Sterling Warehouse Management System 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.

Events Raised

The following events are raised by this time-triggered transaction:

Table 188. 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
Sterling Selling and Fulfillment Foundation: Application Platform Configuration Guide.
This rule is used to indicate the interval that the Item Based Allocation agent

Chapter 27. Time-Triggered Transaction Reference 375

 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.
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

376 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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).
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.

Chapter 27. Time-Triggered Transaction Reference 377

 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 189. 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 190. Item Based Allocation Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

378 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 190. Item Based Allocation 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.
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 191. 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.

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 192. 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

Chapter 27. Time-Triggered Transaction Reference 379

 Table 192. Mark Load As Trailer Loaded Attributes (continued)
Attribute Value
User Exits Called None

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 193. 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 194. Mark Load As Trailer Loaded Statistics
Statistic Name Description
NumLoadsChanged Number of trailer loads 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

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.

380 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 195. 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 196. 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.
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 197. 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.

Chapter 27. Time-Triggered Transaction Reference 381

 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 384.

Attributes
The following are the attributes for this time-triggered transaction:
Table 198. 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()

Table 199. 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 200. 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.

382 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 200. Payment Collection 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.
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 201. 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
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

Chapter 27. Time-Triggered Transaction Reference 383

 Events Raised

The following events are raised by this time-triggered transaction:

Table 202. 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.

Use this time-triggered transaction for processing all authorization and charge
requests.

This transaction requires interfacing with a product that provides financial services.

Attributes

The following are the attributes for this time-triggered transaction:

Table 203. 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

384 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 204. 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 205. 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 206. Payment Execution Statistics
Statistic Name Description
NumAuthTransProcessed Number of authorization transaction
processed.
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.

Chapter 27. Time-Triggered Transaction Reference 385

 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 207. 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 208. Post Inventory Match Attributes
Attribute Value
Base Transaction ID POST_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 209. 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.

386 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Statistics Tracked

The following statistics are tracked for this transaction:

Table 210. 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 211. 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
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.

Chapter 27. Time-Triggered Transaction Reference 387

 Attributes

The following are the attributes for this time-triggered transaction:

Table 212. 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 213. 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.

Pending Job Count

None

Events Raised

The following events are raised by this time-triggered transaction:

Table 214. 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

388 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 214. Events Raised by Process Order Hold Type Transaction (continued)
Template
Transaction/Event Raised when... Key Data Data Published Support?
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 215. 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 216. Process Work 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 a table may
exist in multiple schemas. Runs the agent for the colony.

Statistics Tracked

None.

Pending Job Count

None

Chapter 27. Time-Triggered Transaction Reference 389

 Events Raised

The following events are raised by this time-triggered transaction:

Table 217. 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 218. Publish Negotiation Results Attributes
Attribute Value
Base Transaction ID PUBLISH_ORD_NEGOTIATION
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 219. 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.

390 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 219. Publish Negotiation Results 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

The following statistics are tracked for this transaction:

Table 220. 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 221. 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
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.

Chapter 27. Time-Triggered Transaction Reference 391

 Attributes

The following are the attributes for this time-triggered transaction:

Table 222. 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 223. 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.
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 224. 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.

392 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 224. Release Criteria Statistics (continued)
Statistic Name Description
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.

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 225. Route Shipment
Attribute Value
Base Transaction ID ROUTE_SHIPMENT.0001

Chapter 27. Time-Triggered Transaction Reference 393

 Table 225. Route Shipment (continued)
Attribute Value
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 226. 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.
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 227. 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.

394 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Events Raised

The following events are raised by this time-triggered transaction:

Table 228. 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.

Attributes

The following are the attributes for this time-triggered transaction:

Table 229. 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 230. 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.

Chapter 27. Time-Triggered Transaction Reference 395

 Table 230. Schedule Criteria Parameters (continued)
Parameter Description
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.
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 231. 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.

396 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 231. Schedule Statistics (continued)
Statistic Name Description
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.
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.

Chapter 27. Time-Triggered Transaction Reference 397

 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:
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 232. 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()

398 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 233. 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 234. 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.

Events Raised

The following events are raised by this time-triggered transaction:

Table 235. 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

Chapter 27. Time-Triggered Transaction Reference 399

 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 236. 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

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 237. 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.

400 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Events Raised

The following events are raised by this time-triggered transaction:

Table 238. 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
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 239. 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

Chapter 27. Time-Triggered Transaction Reference 401

 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 240. 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
ID present, and are required to synchronize.

Events Raised

The following events are raised by this time-triggered transaction:

Table 241. 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.

402 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Attributes

The following are the attributes for this time-triggered transaction:

Table 242. 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 243. Send 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

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.

Chapter 27. Time-Triggered Transaction Reference 403

 Attributes

The following are the attributes for this time-triggered transaction:

Table 244. 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 245. Send 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.
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 246. 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 247. Events Raised by the Send Release Transaction
Transaction/Event Data Published
PUBLISH_SHIP_ADVICE YFS_publishShipAdvice_output.xml

404 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 248. Start Order Negotiation Attributes
Attribute Value
Base Transaction ID START_ORD_NEGOTIATION
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called createNegotiation()
User Exits Called YCPBeforeCreateNegotiationUE, YCPGetNegotiationNoUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 249. 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 warehouse management 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 250. Start Order Negotiation Statistics
Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumNegotiationsCreated Number of negotiations created.

Chapter 27. Time-Triggered Transaction Reference 405

 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
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 .

Attributes

The following are attributes for this time-triggered transaction:

Table 251. 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 252. 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.

406 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Statistics Tracked

None.

Pending Job Count

None.

Events Raised

None.

Tables Purged
None.

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

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 253. 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 254. Update Best Match Region Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

Chapter 27. Time-Triggered Transaction Reference 407

 Table 254. Update Best Match Region Criteria Parameters (continued)
Parameter Description
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.
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.

408 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Events Raised

None.

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 255. 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 256. 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

Chapter 27. Time-Triggered Transaction Reference 409

 Events Raised

None

Time-Triggered Purge Transactions

There are several transactions that you can use to purge your database tables at
specific time intervals.

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 with live shipments is being purged, any cross reference to
that order is not accurate in the Order Shipment Console.

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 FoundationSterling Application
Platform.

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 ConsolePlatform
System Management and Administration Guide.

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:

410 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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.
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 257. 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 258. 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
System Management.
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 27. Time-Triggered Transaction Reference 411

 Table 258. Access Token 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.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 259. 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

Inbox Purge
This purge removes alert data from the system. This reduces the load on frequently
accessed tables. The alert should be marked as CLOSED.

Any enterprise that uses the Application Console must schedule purge
transactions.

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, an alert is picked up for purge:
v The alert should be in "Closed" status.
v An inactive alert should have the resolution date earlier than or equal to the
current date minus the purge criteria's retention days.
v If the alert is in "Open" status, the number of expiration days should be greater
than 0, and the modified timestamp should be less than the current date minus
the number of expiration days.

412 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 260. Alert Console Purge Attributes
Attribute Value
Base Transaction ID INBOXPRG
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 261. Alert Console Purge Criteria Parameters
Criteria Parameters 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 System Management.
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 organization for which the Alert Purge needs to
be run. If not passed, then all enterprises are monitored.
ExceptionsWithBlank Optional. If the parameter is set to Y, the agent purges only
EnterpriseOnly those exceptions that has blank enterprise code. In this case,
the value set for the EnterpriseCode criteria parameter is
ignored.
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.

Chapter 27. Time-Triggered Transaction Reference 413

 Statistics Tracked

The following statistics are tracked for this transaction:

Table 262. Alert Console Purge Statistics
Statistic Name Description
NumInboxPurged Number of inbox records purged.

Pending Job Count

For this transaction the pending job count is the number of records that can be
purged from the YFS_INBOX table.

Events Raised

None.

Tables Purged

YFS_INBOX

YFS_INBOX_NOTES

YFS_INBOX_AUDIT

YFS_INBOX_REFERENCES

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.

414 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 263. Capacity Purge Attributes
Attribute Value
Base Transaction ID CAPACITYPRG
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 264. 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 265. 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,

Chapter 27. Time-Triggered Transaction Reference 415

 YFS_RES_POOL_CAPCTY_OVERRIDE, YFS_RES_POOL_CONSMPTN_DTLS and
YFS_RES_POOL_CAPCTY_CONSMPTN tables.

Events Raised

None.

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 418.

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 447
for more information.

Criteria Parameters

The following are the criteria parameters for defining a draft order history
transaction:

416 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 266. Draft 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 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

Chapter 27. Time-Triggered Transaction Reference 417

 YFS_ORDER_AUDIT_H

YFS_ORDER_AUDIT_LEVEL_H

YFS_ORDER_DATE_H

YFS_ORDER_HEADER_H

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_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

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 416.

418 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 447 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.

Criteria Parameters

The following are the criteria parameters for defining a draft order purge
transaction:

Chapter 27. Time-Triggered Transaction Reference 419

 Table 267. 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

YFS_ENTITY_ADDRESS

YFS_HEADER_CHARGES

420 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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_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_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

Chapter 27. Time-Triggered Transaction Reference 421

 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 268. 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

422 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:

Table 269. 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 270. 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

Chapter 27. Time-Triggered Transaction Reference 423

 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 271. 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 272. 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.

424 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 272. 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 ConsoleSystem Management.
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 273. 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.

Attributes

The following are the attributes for this time-triggered transaction:

Table 274. Import Table Purge Attributes
Attribute Value
Base Transaction ID IMPORTTBLPRG

Chapter 27. Time-Triggered Transaction Reference 425

 Table 274. Import Table Purge Attributes (continued)
Attribute Value
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 275. 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[Application 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.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 276. Import Table Purge Statistics
Statistic Name Description
NumImportsPurged Number of import tables purged.

426 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_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: Application Platform Configuration Guide.
The Inventory Audit purge does not purge any records under 60 days old, even
if configured to do so.

The following are the attributes for this time-triggered transaction:

Table 277. 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

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 278. Inventory Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it defaults to
Get, the only valid value.

Chapter 27. Time-Triggered Transaction Reference 427

 Table 278. Inventory Audit 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 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 279. 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.

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.

428 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 280. 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

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 281. 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.

Chapter 27. Time-Triggered Transaction Reference 429

 Table 281. Inventory 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 282. 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.

Tables Purged

YFS_IBA_TRIGGER

YFS_INVENTORY_DEMAND

YFS_INVENTORY_TAG

YFS_INVENTORY_RESERVATION

YFS_INVENTORY_SUPPLY

YFS_INVENTORY_NODE_CONTROL

430 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 283. 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

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 284. 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.

Chapter 27. Time-Triggered Transaction Reference 431

 Table 284. Inventory Supply Temp Purge Criteria Parameters (continued)
Parameter Description
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 285. 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

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.

432 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 286. 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 287. 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.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 288. 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.

Chapter 27. Time-Triggered Transaction Reference 433

 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 436.

Attributes

The following are the attributes for this time-triggered transaction:

Table 289. 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

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 290. 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.

434 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 290. Load History Purge Criteria Parameters (continued)
Parameter Description
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 291. 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

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

Chapter 27. Time-Triggered Transaction Reference 435

 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 292. 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 293. 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.
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.

436 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:

Table 294. 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

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.

Chapter 27. Time-Triggered Transaction Reference 437

 Attributes

The following are the attributes for this time-triggered transaction:

Table 295. 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 296. 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.
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 297. 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.

438 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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.

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:

Table 298. 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

Chapter 27. Time-Triggered Transaction Reference 439

 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 299. 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 300. Negotiation Purge Statistics
Statistic Name Description
NumOrderNegotiationsPurged Number of order negotiations 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_AUDIT

YFS_NEGOTIATION_HDR

YFS_NEGOTIATION_LINE

440 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 442.

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 301. 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

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 302. 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.

Chapter 27. Time-Triggered Transaction Reference 441

 Table 302. Opportunity History Purge Criteria Parameters (continued)
Parameter Description
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 303. 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.

Tables Purged

YFS_OPPORTUNITY_H

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.

442 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 304. 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 305. 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.
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.

Chapter 27. Time-Triggered Transaction Reference 443

 Statistics Tracked

The following statistics are tracked for this transaction:

Table 306. 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

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 447.

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.

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 307. 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

444 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:

Table 308. 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 309. Order History Purge Statistics
Statistic Name Description
NumOrderHistoriesPurged Number of 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_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

Chapter 27. Time-Triggered Transaction Reference 445

 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_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_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

446 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 444. 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.

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.

Chapter 27. Time-Triggered Transaction Reference 447

 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.
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.

448 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 310. 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 311. 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.
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 27. Time-Triggered Transaction Reference 449

 Table 311. Order Purge Criteria Parameters (continued)
Parameter Description
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 452.
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 312. 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.

Tables Purged

YFS_ACTIVITY_DEMAND

YFS_ANSWER_SET_TRAN

YFS_ANSWER_TRAN

YFS_CHARGE_TRANSACTION

450 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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_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_OPTION

YFS_ORDER_LINE_REQ_TAG

YFS_ORDER_LINE_RESERVATION

YFS_ORDER_LINE_SCHEDULE

YFS_ORDER_LINE_SRC_CNTRL

YFS_ORDER_PROD_SER_ASSOC

Chapter 27. Time-Triggered Transaction Reference 451

 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.

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 447
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.

452 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for Order Release Status Purge:
Table 313. 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.

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

Chapter 27. Time-Triggered Transaction Reference 453

 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 314. 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 315. 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.
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.

454 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:

Table 316. 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.

Any enterprise using the Console must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:

Table 317. 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

Chapter 27. Time-Triggered Transaction Reference 455

 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 318. 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 319. 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.

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.

456 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 320. 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 321. 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.
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.

Chapter 27. Time-Triggered Transaction Reference 457

 Table 321. PersonInfo 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 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 322. 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.

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.

458 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Attributes

The following are the attributes for this time-triggered transaction:

Table 323. 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 324. 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.

Chapter 27. Time-Triggered Transaction Reference 459

 Table 324. 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 325. 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.

460 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 326. 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 327. 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.

Chapter 27. Time-Triggered Transaction Reference 461

 Statistics Tracked

The following statistics are tracked for this transaction:

Table 328. 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 329. 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

462 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for this transaction:

Table 330. 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 331. 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

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

Chapter 27. Time-Triggered Transaction Reference 463

 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 332. 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 333. 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.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 334. Purge Catalog Mass Audits Statistics
Statistic Name Description
NumCatalogMassAuditsPurged Number of mass audit records purged.

464 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 466.

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 335. 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

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 336. 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.

Chapter 27. Time-Triggered Transaction Reference 465

 Table 336. Receipt History Purge Criteria Parameters (continued)
Parameter Description
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 337. 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

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 465. It also archives and purges the receipt's child
tables.

This is a pipeline transaction and works from a task queue.

466 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 338. 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 339. 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.
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.

Chapter 27. Time-Triggered Transaction Reference 467

 Statistics Tracked

The following statistics are tracked for this transaction:

Table 340. 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.

This purge reads only the rules defined by the hub. Enterprise overridden rules are
not considered.

Any enterprise using the ConsoleConsole must schedule purge transactions.

Attributes

The following are the attributes for this time-triggered transaction:

Table 341. Reprocess Error Purge Attributes
Attribute Value
Base Transaction ID REPROCESSPRG
Base Document Type General
Base Process Type General

468 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 341. Reprocess Error 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 342. 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 343. Reprocess Error Purge Statistics
Statistic Name Description
NumReprocessErrorsPurged Number of reprocess errors purged.

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

Chapter 27. Time-Triggered Transaction Reference 469

 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 344. 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 345. 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.
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.

470 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:

Table 346. 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 473.

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 358.

Attributes

The following are the attributes for this time-triggered transaction:

Table 347. 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

Chapter 27. Time-Triggered Transaction Reference 471

 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 348. 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 349. 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.

Events Raised

None.

Tables Purged

YFS_ADDITIONAL_ATTRIBUTE_H

YFS_ADDITIONAL_DATE_H

YFS_AUDIT

YFS_CONTAINER_DETA ILS_H

YFS_CONTAINER_STS_AUDIT_H

472 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 471. 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 358.

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.

Attributes

The following are the attributes for this time-triggered transaction:

Table 350. 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

Chapter 27. Time-Triggered Transaction Reference 473

 Criteria Parameters

The following are the criteria parameters for this transaction:

Table 351. 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 352. Shipment Purge Statistics
Statistic Name Description
NumShipmentsPurged Number of Shipments purged.
NumShipmentLinesPurged Number of Shipment Lines purged.

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

474 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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

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 353. Shipment Statistics Purge Attributes
Attribute Value
Base Transaction ID PRG_SHIP_STATS

Chapter 27. Time-Triggered Transaction Reference 475

 Table 353. Shipment Statistics Purge Attributes (continued)
Attribute Value
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 354. 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.

Statistics Parameters

The following are the statistics parameters for this transaction:

Table 355. 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.

476 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Tables Purged

YFS_SHIPMENT_STATISTICS

Statistics Purge
This purge removes statistics data from the system. It purges all records older than
the specified retention days.

You can use purge codes pseudo-logic to analyze purges. If the following condition
is met, the statistics detail is picked up for purge:
v The last modification performed on the statistics detail should fall before the
lead time (in days) setup.

This purge only reads 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).

It is important to run this agent often. In a production environment, the

YFS_STATISTICS_DETAIL table can grow large, very quickly. It does not carry any
old data, therefore it is a good practice to purge it aggressively, from once a day to
once a week, depending on the table size.

Attributes

The following are the attributes for this time-triggered transaction:

Table 356. Statistics Purge Attributes
Attribute Value
Base Transaction ID STATTBLPRG
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 357. 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.
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 27. Time-Triggered Transaction Reference 477

 Table 357. Statistics Purge Criteria Parameters (continued)
Parameter Description
BatchDelete Required. The mode in which all records get deleted from the
table. Valid values are:
v Y - Default value. Records are deleted in batches.
v N - 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.
ColonyID Required in a multi schema deployment where the
YFS_STATISTICS_DETAIL table may exist in multiple schemas.
Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 358. Statistics Purge Statistics
Statistic Name Description
NumStatisticsPurged Number of statistics purged

Pending Job Count

For this transaction, the pending job count is the number of records that can be
purged from the YFS_STATISTICS_DETAIL table.

Events Raised

None.

Tables Purged

YFS_STATISTICS_DETAIL

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.

478 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
The following are the attributes for this time-triggered transaction:
Table 359. 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

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 360. 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 Tables Purged 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 ConsoleSystem Management.
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 361. Statistics Purge Statistics
Statistic Name Description
NumStatisticsPurged Number of statistics purged

Chapter 27. Time-Triggered Transaction Reference 479

 Pending Job Count

None.

Events Raised

None.

Tables Purged

YFS_USER_ACTIVITY

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 362. 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 363. 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.

480 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 363. User Activity Audit 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.
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[Application 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_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 364. 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 483.

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.

Chapter 27. Time-Triggered Transaction Reference 481

 Attributes

The following are the attributes for this time-triggered transaction:

Table 365. 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

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 366. 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 Warehouse Management System 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.

482 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:

Table 367. 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.

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.

Chapter 27. Time-Triggered Transaction Reference 483

 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 368. Work Order Purge Attributes
Attribute Value
Base Transaction ID WORK_ORDER_PURGE
Base Document Type Work Order
Base Process Type VAS
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters

The following are the criteria parameters for this transaction:

Table 369. 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 Warehouse Management System 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.

484 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Statistics Tracked

The following statistics are tracked for this transaction:

Table 370. 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.

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:

Chapter 27. Time-Triggered Transaction Reference 485

 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.

Attributes

The following are the attributes for this time-triggered transaction:

Table 371. 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 372. 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.

486 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 372. YFS Audit Purge Criteria Parameters (continued)
Parameter Description
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.
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 373. 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.

Chapter 27. Time-Triggered Transaction Reference 487

 Attributes

Following are the attributes for this time-triggered transaction:

Table 374. 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

Criteria Parameters

Following are the criteria parameters for this transaction:

Table 375. 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

488 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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.

Attributes

The following are the attributes for this time-triggered transaction:

Table 376. 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 377. 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 378. Password Reset Request Purge Statistics
Statistic Name Description
NumPasswordRequestPurged Number of password requests purged.

Chapter 27. Time-Triggered Transaction Reference 489

 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.

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 379. 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 380. 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.

490 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 380. User Login Failure 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 the
PLT_USER_LOGIN_FAILED table may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked

The following statistics are tracked for this transaction:

Table 381. 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
out-dated 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.

Chapter 27. Time-Triggered Transaction Reference 491

 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.
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 382. 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 383. 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 384. Load Execution Task Queue Syncher Statistics
Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised

None.

492 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Order Delivery Task Queue Syncher
This transaction synchronizes the order delivery process type.

Attributes

The following are the attributes for this time-triggered transaction:

Table 385. 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 386. 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 387. 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 27. Time-Triggered Transaction Reference 493

 Attributes

The following are the attributes for this time-triggered transaction:

Table 388. 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 389. 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 390. 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.

494 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Attributes

The following are the attributes for this time-triggered transaction:

Table 391. 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 392. 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 393. 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 27. Time-Triggered Transaction Reference 495

 Attributes

The following are the attributes for this time-triggered transaction:

Table 394. 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 395. 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 396. 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.

496 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 ConsolePlatform System Management and Administration Guide. 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 397. 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 398. 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 27. Time-Triggered Transaction Reference 497

 Table 398. 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 399. Exception Monitor Attributes
Attribute Value
Base Transaction ID EXCEPTION_MONITOR
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

498 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Criteria Parameters

The following are the criteria parameters for this monitor:

Table 400. 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 401. 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 27. Time-Triggered Transaction Reference 499

 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 402. 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 403. 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

500 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 403. 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 404. 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 27. Time-Triggered Transaction Reference 501

 Criteria Parameters

The following are the criteria parameters for this monitor:

Table 405. 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 406. 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.

502 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 , 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 355.

The same relog interval is used for all document types

Chapter 27. Time-Triggered Transaction Reference 503

 Attributes

The following are the attributes for this time-triggered transaction:

Table 407. 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 408. 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 409. 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.

504 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 410. 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 .

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 355.

The same relog interval is used for all document types.

Chapter 27. Time-Triggered Transaction Reference 505

 Attributes

The following are the attributes for this time-triggered transaction:

Table 411. 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 412. 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 413. 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.

Events Raised

No events are raised. Individual actions associated with the monitoring rule are
run.

506 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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.
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.

Chapter 27. Time-Triggered Transaction Reference 507

 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 , 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 355.

The same relog interval is used for all document types.

Attributes

The following are the attributes for this time-triggered transaction:

Table 414. 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 415. 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.
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.

508 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 415. Enhanced Order Monitor Criteria Parameters (continued)
Parameter Description
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 416. 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.

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:

Chapter 27. Time-Triggered Transaction Reference 509

 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.

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
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.

510 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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
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

Chapter 27. Time-Triggered Transaction Reference 511

 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:

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

512 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 417. 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 non-working days.
Table 418. 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 non-working 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

Chapter 27. Time-Triggered Transaction Reference 513

 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 419. 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 420. 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

Criteria Parameters

The following are the criteria parameters for this monitor:

Table 421. 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.

514 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 421. Real-time Availability Monitor Criteria Parameters (continued)
Parameter Description
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
re-publish 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 re-published.
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.
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.

Chapter 27. Time-Triggered Transaction Reference 515

 Table 421. Real-time Availability Monitor Criteria Parameters (continued)
Parameter Description
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.

Statistics Tracked

None.

Pending Job Count

None.

Events Raised

The following events are raised by this time-triggered transaction:

Table 422. 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.

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.

516 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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 , and the Sterling Selling and Fulfillment Foundation: Reverse Logistics
Configuration Guide.

Attributes

The following are the attributes for this time-triggered transaction:

Table 423. 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 424. Shipment 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 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.

Chapter 27. Time-Triggered Transaction Reference 517

 Statistics Tracked

The following statistics are tracked for this transaction:

Table 425. 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.

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 426. Work Order Monitor Attributes
Attribute Value
Base Transaction ID WORK_ORDER_MONITOR
Base Document Type Work Order

518 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 426. Work Order Monitor Attributes (continued)
Attribute Value
Base Process Type VAS Process
Abstract Transaction No

Criteria Parameters

The following are the criteria parameters for this monitor:

Table 427. 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 428. Work Order Monitor Statistics
Statistic Name Description
NumWorkOrdersMonitored Number of work orders monitored.

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

Chapter 27. Time-Triggered Transaction Reference 519

 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.

520 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 28. Order Modification Types
Order Modification Types
The following are the default order modification types and their associated
modification levels:
Table 429. Order Document Modification Types
Modification Types Description Modification Levels
Ad 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 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 Quantity Additional quantity can be Line
added to an order document's
line or release line. Release Line
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.

© Copyright IBM Corp. 1999, 2012 521

 Table 429. Order Document Modification Types (continued)
Modification Types Description Modification Levels
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.
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.

522 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 429. Order Document Modification Types (continued)
Modification Types Description Modification Levels
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 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.
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.

Chapter 28. Order Modification Types 523

 Table 429. Order Document Modification Types (continued)
Modification Types Description Modification Levels
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.
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 re-prices the
order. However, pre-existing
charges and taxes have to be
converted manually.

524 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 429. Order Document Modification Types (continued)
Modification Types Description Modification Levels
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 Expiration Date A modification can be made to Negotiation
the expiration date associated
with an order document's
negotiation.
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 28. Order Modification Types 525

 Table 429. Order Document Modification Types (continued)
Modification Types Description Modification Levels
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 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 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.
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.

526 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 429. Order Document Modification Types (continued)
Modification Types Description Modification Levels
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 Price Charges can be added to an Header
order document's header or
line. Line
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.

Chapter 28. Order Modification Types 527

 Table 429. Order Document Modification Types (continued)
Modification Types Description Modification Levels
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 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 Shipment An order document's shipment Shipment
can be deleted.
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.

528 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 429. Order Document Modification Types (continued)
Modification Types Description Modification Levels
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 Delivery Line Delivery lines can be removed Line
From Product Line from product order lines.
Association
Remove 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 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 Service Line Provided service lines can be Line
From Product Line removed from product order
Association lines.
Remove Shipment From An order document's shipment Shipment
Delivery Plan can be removed from a
delivery plan.
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
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.

Chapter 28. Order Modification Types 529

 Table 429. Order Document Modification Types (continued)
Modification Types Description Modification Levels
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.

530 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Chapter 29. Condition Builder Attributes
Condition Builder Attributes
Statements in the condition builder are built using attributes that are defined
throughout the Applications ManagerConfigurator.

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 531

 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 430. 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).
Disposition Code The disposition code of the item. This field is only applicable
for Reverse Logistics and Supply Collaboration.

532 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 430. Order Fulfillment Condition Builder Attributes (continued)
Attribute Description
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 WMS, 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.
Is Derived Line The flag indicating whether the order line is derived from
another order line.

Chapter 29. Condition Builder Attributes 533

 Table 430. Order Fulfillment Condition Builder Attributes (continued)
Attribute Description
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

pre-defined 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 431. 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

pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Outbound Shipment
The condition builder attributes for Outbound Shipment, Inbound Shipment,
Transfer Order Delivery, and Return Shipment are identical.

534 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 432. 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 WMS, 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 Warehouse
Management System. 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.
{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

pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Chapter 29. Condition Builder Attributes 535

 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 433. 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.
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.

536 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 433. Return Fulfillment Condition Builder Attributes (continued)
Attribute Description
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 WMS, 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.
{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

pre-defined 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.

Chapter 29. Condition Builder Attributes 537

 Table 434. 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 WMS, 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.
{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

pre-defined 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 435. 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.

538 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 435. Purchase Order Execution Condition Builder Attributes (continued)
Attribute Description
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.
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 WMS, 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.

Chapter 29. Condition Builder Attributes 539

 Table 435. Purchase Order Execution Condition Builder Attributes (continued)
Attribute Description
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

pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Purchase Order Negotiation

Table 436. 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

pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

540 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 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.

Transfer Order Receipt

The Transfer Order Receipt condition builder attributes are identical to the Return
Receipt attributes.

Master Order Fulfillment

Table 437. 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.

Chapter 29. Condition Builder Attributes 541

 Table 437. Master Order Fulfillment Condition Builder Attributes (continued)
Attribute Description
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 WMS, 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 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

pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

542 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Quote Fulfillment
The Quote Fulfillment condition builder attributes are identical to the Order
Fulfillment condition builder attributes.

Load Execution
Table 438. 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.
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

pre-defined 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 439. 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.

Chapter 29. Condition Builder Attributes 543

 Table 439. General Condition Builder Attributes (continued)
Attribute Description
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.
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

pre-defined by Sterling Selling and Fulfillment
FoundationSterling Application Platform 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.

544 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
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.

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 440. 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.

Chapter 29. Condition Builder Attributes 545

 Table 440. Count Execution Condition Builder Attributes (continued)
Attribute Description
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.
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

pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Pack Process
Table 441. 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 WMS, 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 WMS, or
WMS 6.2).

546 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 441. Pack Process Condition Builder Attributes (continued)
Attribute Description
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.
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.

Chapter 29. Condition Builder Attributes 547

 Table 441. Pack Process 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

pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Outbound Picking
Table 442. 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

pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

VAS Process
Table 443. 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.

548 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
 Table 443. VAS Process Condition Builder Attributes (continued)
Attribute Description
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.
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

pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Opportunity

Opportunity Fulfillment
Table 444. 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.

Chapter 29. Condition Builder Attributes 549

 Table 444. Opportunity 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

pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Item-Based Allocation (IBA) Order

Table 445. IBA Attributes
Attribute Description
Order Attributes
Exchange Type The exchange type of the order.
Priority Code Customizable priority code of the order.
Priority Number The numeric priority code of the order.
Document Type The document type for this order. Typical value is 0001 (Sales
Order).
Order Type The order classification attribute. This field can be used for
reporting purposes or to build conditions for modeling your
business process. Sterling Selling and Fulfillment
FoundationSterling Application Platform has no default logic
based on this field.
Entry Type The channel through which this order was created.
Department Code Department code to which the order was placed.
Search Criteria 1 Customizable field for allowing searches.
Search Criteria 2 Customizable field for allowing searches.
Order Line
Line Type The line type can be used in process modeling for pipeline
determination or conditional processing.
Condition Variable 1 A user-defined variable that can be used for condition
building in process modeling.
Condition Variable 2 A user-defined variable that can be used for condition
building in process modeling.
Shipping Attributes
Level of Service The order or the line's level of service.
Ship To ID The ship-to identifier. If a customer definition representing
the buyer organization exists within Sterling Selling and
Fulfillment FoundationSterling Application Platform, the
ship-to ID can represent the Customer ID. Otherwise, the
ship-to ID can represent the PersonID of the ship-to address
or the receiving node of the order.
Carrier Service Code The code of the carrier service used to carry the load.
Participant Attributes
Enterprise Code The code of the enterprise on the order.

550 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Table 445. IBA Attributes (continued)
Attribute Description
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.
Bill To ID The identifier of the customer to whom the order is being
billed.
{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

pre-defined by Sterling Selling and Fulfillment Foundation as
opposed to any XML attribute that you can enter.

Chapter 29. Condition Builder Attributes 551

552 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 553

 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.

554 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 555
 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.

556 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
Index
A C delivery codes (continued)
defining 110
additional logistic rules calendars 42 deleting 111
defining 109 Cancel Order for Inventory Shortage modifying 111
Additional Optimization Criteria 62 flag 61 delivery locations 55
address question groups carrier modification reasons delivery service items
deleting 96 creating 107 sourcing rules 78
modifying 96 defining 107 Description field 67
address questions deleting 108 display control types 97
capacity impact modifying 108 distributed order management
capacity impact multiplier 98 Carrier Service Code field 120 configuration 2
defining 98 Carrier/Service field 120 distribution groups 55, 71
deleting 99 catalog advanced distribution details 74
fixed capacity impact 98 index building 365 deleting 75
modifying 99 chained orders 44 creating 29, 72, 81
defining 96 definition 86 creating for procurement 89
deleting 98 charge categories defining for product items 71
modifying 97 adding charge names 295 defining for provided service
rearranging 100 creating 294 items 81
See also questions 98 deleting 297 deleting 31, 75, 83
address questions groups deleting charge names 296 deleting for procurement 90
defining 95 modifying 296 modifying for procurement 89
Allow Reservation During Scheduling modifying charge names 296 nodes
field 61 charge definitions 294 adding 72, 82
answer options 97 common codes 187 deleting 73, 83
application rules side panel 9 condition builder 549 modifying 73, 83
Applications Manager configuration screens sourcing 73
actions 19 accessing 10 Do not mix in Shipment flag 114
Context-Sensitive Help 23 Configure Outbound Constraints Do Not Recompute Expected Dates When
document types 20 field 66 Requested Dates On The Order Are
entering dates/times 23 Consider Buyer's Routing Guide Changed field 246, 248
lists 22 field 106 document types 306
lookup functionality 20 Consolidator field 119, 120
special characters 24 Convert Node Priority into Cost field 66
troubleshooting 24 Country/Region field 119
users 22 Currency field 67 E
layout 7 customer components enterprises 2
starting 7 customer grades 170 Euro Member field 67
work area 16 definitions 157 Expiration Date field 67
Apply Future Safety Factor To Future Customer Components 153 external organizations 71
Inventory Availability flag 61 customer identification master 154
Apply On Hand Safety Factor To On customers 3
Hand Inventory Availability flag 61 F
approval plans for quotes, financial components 293
configuring 231
approval rule violation reasons for
D financials 3
date based dependency 260 freight terms
quotes 195 creating 105
default dependency group
ATP Rule 39 defining 105
defining 260
authorization reversal 128 deleting 107
deleting 264
Available field 227 modifying 106
modifying 264
default distribution rule 55 From field 119, 120
Default Supervisor field 94 From Node field 45
B Delay Procurements To be Consolidated fulfillment types 52, 54, 77
backorder reasons 4, 191, 192 With Shipments Against Future Coming creating 39, 52
Break Bulk Node field 120 Inventory. 63 deleting 40, 53
building Delay Shipment Against Current modifying 40, 52
catalog index 365 Inventory To Be Consolidated With
business models 1 Shipments Against Future Coming
business rules 2 Inventory 63 I
buyers 2 delivery codes Ignore Fill Quantity (Ship Complete)
creating 110 field 61

© Copyright IBM Corp. 1999, 2012 557

index
catalog search 365
order promising (continued)
nodes
Q
inheritance 54 defining promising questions
determining 10 information 41 configuring 95
instruction types 4, 188 order sources 174, 175, 176 definition 95
creating 187 order sourcing classification quote approval plans, configuring 231
deleting 188 defining 55 quote rules, configuring 251
modifying 188 definition 55
inventory availability safety factors 61 order sourcing classifications 77
item classifications 86 creating 55 R
item level controls deleting 56 Receipt Processing Time (Hours)
defining 38 modifying 56 field 43
item substitution 43 order types 173, 174, 197, 198 Receipt Processing Time for Forwarding
order validations 4, 185 (Hours) 43
seller validation 170 receiving discrepancy reasons 302, 304
L organization levels 10
rules 11
region schemas
lead origins 195, 199, 200 definition 56
organization rules 11 Delivery Region Schema 57
Line Ship Complete flag 60
loading another organization's Provided Service Region Schema 57
Line Ship from Single Node flag 60
rules 15 Shipped Product Region Schema 57
logistics 3
overriding 12 Reserve Bundle Out of Ratio field 61
defining attributes 105
outbound constraints Retention Days field 307
lost reasons 201, 202
defining 113 reverse authorization 128
Override Freight Terms field 120 Rollback Segment field 307
Override Ship To field 120 routing guide lines
M creating 117
marketplaces 2 definition 117
Master Order
Next iteration date 254
P deleting 122
payment rules 298 modifying 122
Maximum no. of days order can be routing guides 115
payment terms 293, 294
scheduled before its ship date field 61 creating 116
permit question groups
Maximum no. of days order can be deleting 123
defining 100
shipped/delivered beyond its requested modifying 117
deleting 102
date field 61
modifying 101
Maximum no. of days to search service
permit questions
availability for field 61
modification components 208
defining 102 S
deleting 103 scheduling rules 52
rules 203, 205
modifying 103 constraints 60
types 206, 208
rearranging 104 creating 58
modification reasons 4, 190
See also questions 98 default rule 58
creating 189
Postfix Symbol field 67 defining 57
deleting 190
Prefix Symbol field 67 deleting 64
modifying 190
Pricing organization 10, 12 inventory controls 60
multi-divisional corporations 2
Priority field 120 lead times 61
process type configuration 4 modifying 64
procurement optimize on 62
N distribution groups 89 primary information 59
Node field 120 sourcing rules 86 priority 62
Node Priority Cost Factor field 66 procurement orders 41, 86 retry intervals 59
nodes 54, 71 procurement rules scheduling algorithm 58
note reasons 194, 315 defining 86 sellers 2
product items service execution
sourcing rules 75 configuring components 93
O provided service items
distribution groups 81
service supervisors
order attributes 3 configuring 93
sourcing rules 83 default 93
external references
provided service locations 55 defining 93
order level 176, 177
purchase orders deleting 94
order line level 177, 178
definition 86 modifying 94
line types 180, 181
Purge Code field 307 Ship Complete flag 60
order address types 179, 180
purge criteria 4, 305, 307 Ship from Single Node flag 60
other attributes 181
rules 305 ship node determination 71
generating prime line
numbers 181 shipment modes
order promising creating 112
configuring 25 defining 112
deleting 113
modifying 112

558 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide
sourcing region selection
defining 56
U
sourcing rules 52, 54 Use Advanced Transit Time Calculation
creating for delivery service items 79 flag 109
creating for procurement 86 Use End Of Shift Time flag 43
creating for product item 76 Use Handling Cost flag 66
creating for provided service Use Item Cost flag 65
items 84 Use Landed Cost flag 65
default distribution rule 55
defining basic configuration 53
defining for delivery service items 78 V
defining for product items 75 Validate Charge Name flag 302
defining for provided service Validate Customer ID flag 184
items 83 Validate Item flag 185
deleting for delivery service items 81 Validate Vendor ID flag 184
deleting for procurement 88
deleting for product items 78
deleting for provided service
items 86
W
modifying for delivery service When Optimizing On Cost, Combine
items 81 Shipments. 62
modifying for procurement 88 work orders 43
modifying for product items 78 workflows 2
modifying for provided service
items 86
sourcing setup 3 Z
State field 119 Zip Code field 119
Store# field 119, 120
Subscribed field 227
Synchronize Dates Between Master Order
Dates And Dates On Order Line And
Schedules field 246

T
tax names 297, 298
third-party logistics models 2
Third-party logistics models 2
To field 119, 120
To Node field 45
transaction based dependency 260
transaction dependencies
configuring 259
transaction dependency
configuring groups 259
creating rules 261
sequencing 259
types
date based 260
transaction based 260
transaction dependency rule
creating 261
creating constraints 262
transaction dependency rule
constraints 262
Transfer Cost Factor Currency field 65
Transfer Cost Factor for External
Transfers field 66
Transfer Cost Factor for Internal Transfers
field 66
transfer orders 44
definition 86
transfer schedules 44
transportation optimization 114

Index 559
560 Sterling Selling and Fulfillment Foundation: Distributed Order Management Configuration Guide



Printed in USA