Sterling Distributed Order

Management: Configuration
Guide
Release 9.0

Last updated in HF 11

November 2010
Copyright Notice
Copyright © 1999 - 2010
Sterling Commerce, Inc.
ALL RIGHTS RESERVED

STERLING COMMERCE SOFTWARE

***TRADE SECRET NOTICE***
THE STERLING COMMERCE SOFTWARE DESCRIBED BY THIS DOCUMENTATION ("STERLING COMMERCE
SOFTWARE") IS THE CONFIDENTIAL AND TRADE SECRET PROPERTY OF STERLING COMMERCE, INC., ITS
AFFILIATED COMPANIES OR ITS OR THEIR LICENSORS, AND IS PROVIDED UNDER THE TERMS OF A
LICENSE AGREEMENT. NO DUPLICATION OR DISCLOSURE WITHOUT PRIOR WRITTEN PERMISSION.
RESTRICTED RIGHTS.
This documentation, the Sterling Commerce Software it describes, and the information and know-how
they contain constitute the proprietary, confidential and valuable trade secret information of Sterling
Commerce, Inc., its affiliated companies or its or their licensors, and may not be used for any
unauthorized purpose, or disclosed to others without the prior written permission of the applicable
Sterling Commerce entity. This documentation and the Sterling Commerce Software that it describes
have been provided pursuant to a license agreement that contains prohibitions against and/or
restrictions on their copying, modification and use. Duplication, in whole or in part, if and when
permitted, shall bear this notice and the Sterling Commerce, Inc. copyright notice.
U.S. GOVERNMENT RESTRICTED RIGHTS. This documentation and the Sterling Commerce Software it
describes are "commercial items" as defined in 48 C.F.R. 2.101. As and when provided to any agency or
instrumentality of the U.S. Government or to a U.S. Government prime contractor or a subcontractor at
any tier ("Government Licensee"), the terms and conditions of the customary Sterling Commerce
commercial license agreement are imposed on Government Licensees per 48 C.F.R. 12.212 or 227.7202
through 227.7202-4, as applicable, or through 48 C.F.R. § 52.244-6.
This Trade Secret Notice, including the terms of use herein is governed by the laws of the State of Ohio,
USA, without regard to its conflict of laws provisions. If you are accessing the Sterling Commerce
Software under an executed agreement, then nothing in these terms and conditions supersedes or
modifies the executed agreement.

Sterling Commerce, Inc.

4600 Lakehurst Court
Dublin, Ohio 43016-2000

Copyright © 1999 - 2010

Third-Party Software
Portions of the Sterling Commerce Software may include products, or may be distributed on the same
storage media with products, ("Third Party Software") offered by third parties ("Third Party Licensors").
Sterling Commerce Software may include Third Party Software covered by the following copyrights:
Copyright © 2006-2008 Andres Almiray. Copyright © 1999-2005 The Apache Software Foundation. Erik
Arvidsson. Copyright © 2008 Azer Koçulu http://azer.kodfabrik.com. Copyright © Einar Lielmanis,
einars@gmail.com. Copyright © 2006 John Reilly (www.inconspicuous.org) and Copyright © 2002
Douglas Crockford (www.crockford.com). Copyright © 2009 John Resig, http://jquery.com/. Copyright ©
2006-2008 Json-lib. Copyright © 2001 LOOX Software, Inc. Copyright © 2003-2008 Luck Consulting Pty.
Ltd. Copyright 2002-2004 © MetaStuff, Ltd. Copyright © 2009 Michael Mathews micmath@gmail.com.
Copyright © 1999-2005 Northwoods Software Corporation. Copyright © Microsoft Corp. 1981-1998.
Purple Technology, Inc. Copyright © 2004-2008 QOS.ch. Copyright © 2005 Sabre Airline Solutions.
Copyright © 2004 SoftComplex, Inc. Copyright © 2000-2007 Sun Microsystems, Inc. Copyright © 2001
VisualSoft Technologies Limited. Copyright © 2001 Zero G Software, Inc. All rights reserved by all listed
parties.
The Sterling Commerce Software is distributed on the same storage media as certain Third Party
Software covered by the following copyrights: Copyright © 1999-2006 The Apache Software Foundation.
Copyright © 2001-2003 Ant-Contrib project. Copyright © 1998-2007 Bela Ban. Copyright © 2005
Eclipse Foundation. Copyright © 2002-2006 Julian Hyde and others. Copyright © 2006-2009 Ext JS, Inc.
Copyright © 1997 ICE Engineering, Inc./Timothy Gerard Endres. Copyright 2000, 2006 IBM Corporation
and others. Copyright © 1987-2006 ILOG, Inc. Copyright © 2000-2006 Infragistics. Copyright ©
2002-2005 JBoss, Inc. Copyright LuMriX.net GmbH, Switzerland. Copyright © 1998-2009 Mozilla.org.
Copyright © 2003-2009 Mozdev Group, Inc. Copyright © 1999-2002 JBoss.org. Copyright © 2007, the
OWASP Foundation. Copyright Raghu K, 2003. Copyright © 2004 David Schweinsberg. Copyright ©
2005-2006 Darren L. Spurgeon. Copyright © 2005-2008 Sam Stephenson. Copyright © S.E. Morris
(FISH) 2003-04. Copyright © 1998 Regents of the University of California. Copyright © 2006 VisualSoft
Technologies. Copyright © 2002-2009 Zipwise Software. All rights reserved by all listed parties.
Third Party Software which is included, or are distributed on the same storage media with, the Sterling
Commerce Software where use, duplication, or disclosure by the United States government or a
government contractor or subcontractor, are provided with RESTRICTED RIGHTS under Title 48 CFR
2.101, 12.212, 52.227-19, 227.7201 through 227.7202-4, DFAR 252.227-7013(c) (1) (ii) and (2), DFAR
252.227-7015(b)(6/95), DFAR 227.7202-3(a), FAR 52.227-14(g)(2)(6/87), and FAR 52.227-19(c)(2)
and (6/87) as applicable.
Additional information regarding certain Third Party Software is located at installdir/SCI_License.txt.
Some Third Party Licensors also provide license information and/or source code for their software via
their respective links set forth below:
http://danadler.com/jacob/
http://www.dom4j.org
This product includes software developed by the Apache Software Foundation (http://www.apache.org).
This product includes software developed by the Ant-Contrib project
(http://sourceforge.net/projects/ant-contrib). This product includes software developed by the JDOM
Project (http://www.jdom.org/). This product includes code licensed from RSA Data Security (via Sun
Microsystems, Inc.). Sun, Sun Microsystems, the Sun Logo, Java, JDK, the Java Coffee Cup logo,
JavaBeans, JDBC, JMX and all JMX based trademarks and logos are trademarks or registered trademarks
of Sun Microsystems, Inc. All other trademarks and logos are trademarks of their respective owners.

THE APACHE SOFTWARE FOUNDATION SOFTWARE

The Sterling Commerce Software is distributed with or on the same storage media as the following
software products (or components thereof) and java source code files: Xalan version 2.5.2, Cookie.java,
Header.java, HeaderElement.java, HttpException.java, HttpState.java, NameValuePair.java,
CronTimeTrigger.java, DefaultTimeScheduler.java, PeriodicTimeTrigger.java, Target.java,
TimeScheduledEntry.java, TimeScheduler.java, TimeTrigger.java, Trigger.java, BinaryHeap.java,
PriorityQueue.java, SynchronizedPriorityQueue.java, GetOpt.java, GetOptsException.java,
IllegalArgumentException.java, MissingOptArgException.java (collectively, "Apache 1.1 Software").
Apache 1.1 Software is free software which is distributed under the terms of the following license:
License Version 1.1
Copyright 1999-2003 The Apache Software Foundation. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the
following disclaimer.
2. Redistribution in binary form must reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials provided with the distribution.
3.The end-user documentation included with the redistribution, if any, must include the following
acknowledgement: "This product includes software developed by the Apache Software Foundation
(http://www.apache.org)." Alternatively, this acknowledgement may appear in the software itself, if and
whenever such third-party acknowledgements normally appear.
4.The names "Commons", "Jakarta", "The Jakarta Project", "HttpClient", "log4j", "Xerces "Xalan",
"Avalon", "Apache Avalon", "Avalon Cornerstone", "Avalon Framework", "Apache" and "Apache Software
Foundation" must not be used to endorse or promote products derived from this software without
specific prior written permission. For written permission, please contact apache@apache.org.
5.Products derived from this software may not be called "Apache", nor may "Apache" appear in their
name, without the prior written permission of the Apache Software Foundation.
THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESS OR IMIPLIED WARRANTIES, INCLUDING ANY
IMPLIED WARRANTY OF MERCHANTIBILITY, AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTIAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
This software consists of voluntary contributions made by many individuals on behalf of the Apache
Software Foundation. The GetOpt.java, GetOptsException.java, IlligalArgumentException.java and
MissingOptArgException.java software was originally based on software copyright © 2001, Sun
Microsystems, http://www.sun.com. For more information on the Apache Software Foundation, please
see <http://www.apache.org/>.
The preceding license only applies to the Apache 1.1 Software and does not apply to the Sterling
Commerce Software or to any other Third Party Software.
The Sterling Commerce Software is also distributed with or on the same storage media as the following
software products (or components thereof): Ant, Antinstaller, Apache File Upload Package, Apache
Commons Beans, Apache Commons BetWixt, Apache Commons Collection, Apache Commons Digester,
Apache Commons IO, Apache Commons Lang., Apache Commons Logging, Apache Commons Net,
Apache Jakarta Commons Pool, Apache Jakarta ORO, Lucene, Xerces version 2.7, Apache Log4J, Apache
SOAP, Apache Struts and Apache Xalan 2.7.0, (collectively, "Apache 2.0 Software"). Apache 2.0
Software is free software which is distributed under the terms of the Apache License Version 2.0. A copy
of License Version 2.0 is found in the following directory files for the individual pieces of the Apache 2.0
Software: installdir/jar/commons_upload/1_0/ CommonsFileUpload_License.txt,
installdir/jar/jetspeed/1_4/RegExp_License.txt,
installdir/ant/Ant_License.txt
<install>/jar/antInstaller/0_8/antinstaller_License.txt
<install>/jar/commons_beanutils/1_7_0/commons-beanutils.jar (/META-INF/LICENSE.txt)
<install>/jar/commons_betwixt/0_8/commons-betwixt-0.8.jar (/META-INF/LICENSE.txt)
<install>/jar/commons_collections/3_2/LICENSE.txt
<install>/jar/commons_digester/1_8/commons-digester-1.8.jar (/META-INF/LICENSE.txt)
<install>/jar/commons_io/1_4/LICENSE.txt
<install>/jar/commons_lang/2_1/Commons_Lang_License.txt
<install>/jar/commons_logging/1_0_4/commons-logging-1.0.4.jar (/META-INF/LICENSE.txt)
<install>/jar/commons_net/1_4_1/commons-net-1.4.1.jar (/META-INF/LICENSE.txt)
<install>/jar/smcfs/9.0/lucene-core-2.4.0.jar (/META-INF/LICENSE.txt)
<install>/jar/struts/2_0_11/struts2-core-2.0.11.jar (./LICENSE.txt)
<install>/jar/commons_pool/1_4/Commons_License.txt
<install>/jar/jakarta_oro/2_0_8/JakartaOro_License.txt
<install>/jar/log4j/1_2_15/LOG4J_License.txt
<install>/jar/xalan/2_7/Xalan_License.txt
<install>/jar/soap/2_3_1/Apache_SOAP_License.txt
Unless otherwise stated in a specific directory, the Apache 2.0 Software was not modified. Neither the
Sterling Commerce Software, modifications, if any, to Apache 2.0 Software, nor other Third Party Code is
a Derivative Work or a Contribution as defined in License Version 2.0. License Version 2.0 applies only to
the Apache 2.0 Software which is the subject of the specific directory file and does not apply to the
Sterling Commerce Software or to any other Third Party Software. License Version 2.0 includes the
following provision:
"Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS
OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of
TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are
solely responsible for determining the appropriateness of using or redistributing the Work and assume
any risks associated with Your exercise of permissions under this License."
NOTICE file corresponding to the section 4 d of the Apache License, Version 2.0, in this case for the
Apache Ant distribution. Apache Ant Copyright 1999-2008 The Apache Software Foundation. This
product includes software developed by The Apache Software Foundation (http://www.apache.org/). This
product includes also software developed by:
- the W3C consortium (http://www.w3c.org)
- the SAX project (http://www.saxproject.org)
The <sync> task is based on code Copyright © 2002, Landmark Graphics Corp that has been kindly
donated to the Apache Software Foundation.
Portions of this software were originally based on the following:
- software copyright © 1999, IBM Corporation., http://www.ibm.com.
- software copyright © 1999, Sun Microsystems., http://www.sun.com.
- voluntary contributions made by Paul Eng on behalf of the Apache Software Foundation that were
originally developed at iClick, Inc., software copyright © 1999.
NOTICE file corresponding to the section 4 d of the Apache License, Version 2.0, in this case for the
Apache Lucene distribution. Apache Lucene Copyright 2006 The Apache Software Foundation. This
product includes software developed by The Apache Software Foundation (http://www.apache.org/).
The snowball stemmers in contrib/snowball/src/java/net/sf/snowball were developed by Martin Porter
and Richard Boulton. The full snowball package is available from http://snowball.tartarus.org/

Ant-Contrib Software
The Sterling Commerce Software is distributed with or on the same storage media as the Anti-Contrib
software (Copyright © 2001-2003 Ant-Contrib project. All rights reserved.) (the "Ant-Contrib Software").
The Ant-Contrib Software is free software which is distributed under the terms of the following license:
The Apache Software License, Version 1.1
Copyright © 2001-2003 Ant-Contrib project. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided
that the following conditions are met:
1.Redistributions of source code must retain the above copyright notice, this list of conditions and the
following disclaimer.
2.Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials provided with the distribution.
3. The end-user documentation included with the redistribution, if any, must include the following
acknowledgement:
"This product includes software developed by the Ant-Contrib project
(http://sourceforge.net/projects/ant-contrib)."
Alternately, this acknowledgement may appear in the software itself, if and wherever such third-party
acknowledgements normally appear.
4. The name Ant-Contrib must not be used to endorse or promote products derived from this software
without prior written permission. For written permission, please contact
ant-contrib-developers@lists.sourceforge.net.
5. Products derived from this software may not be called "Ant-Contrib" nor may "Ant-Contrib" appear in
their names without prior written permission of the Ant-Contrib project.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE ANT-CONTRIB PROJECT OR ITS
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The preceding license only applies to the Ant-Contrib Software and does not apply to the Sterling
Commerce Software or to any other Third Party Software.

ANTISAMY SOFTWARE
The Sterling Commerce Software is distributed with or on the same storage media as the AntiSamy
software (Copyright © 1998 Regents of the University of California. All rights reserved.) (the "AntiSamy
Software"). The AntiSamy Software is free software which is distributed under the terms of the following
license:
Copyright © 1998, Regents of the University of California
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided
that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the
following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to endorse or
promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

COOLBUTTONS SOFTWARE
The Sterling Commerce Software is also distributed with or on the same storage media as Coolbuttons.js
("Coolbuttons Software"), which is subject to the following license:
This Button Script was designed by Erik Arvidsson for WebFX. For more info and examples see:
http://webfx.eae.net or send email to erik@eae.net. Feel free to use this code as long as this disclaimer
is intact.
The preceding license only applies to the Coolbuttons Software and does not apply to the Sterling
Commerce Software, or any other Third Party Software.

DOM4J Software
The Sterling Commerce Software is distributed with or on the same storage media as the Dom4h
Software which is free software distributed under the terms of the following license:
Redistribution and use of this software and associated documentation ("Software"), with or without
modification, are permitted provided that the following conditions are met:
1.Redistributions of source code must retain copyright statements and notices. Redistributions must also
contain a copy of this document.
2.Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials provided with the distribution.
3.The name "DOM4J" must not be used to endorse or promote products derived from this Software
without prior written permission of MetaStuff, Ltd. For written permission, please contact
dom4j-info@metastuff.com.
4.Products derived from this Software may not be called "DOM4J" nor may "DOM4J" appear in their
names without prior written permission of MetaStuff, Ltd. DOM4J is a registered trademark of MetaStuff,
Ltd.
5.Due credit should be given to the DOM4J Project - http://www.dom4j.org
THIS SOFTWARE IS PROVIDED BY METASTUFF, LTD. AND CONTRIBUTORS ``AS IS'' AND ANY
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL METASTUFF, LTD. OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Copyright 2001-2004 © MetaStuff, Ltd. All Rights Reserved.
The preceding license only applies to the Dom4j Software and does not apply to the Sterling Commerce
Software, or any other Third Party Software.

THE ECLIPSE SOFTWARE FOUNDATION

The Sterling Commerce Software is also distributed with or on the same storage media as the following
software:
com.ibm.icu.nl1_3.4.4.v200606220026.jar, org.eclipse.ant.core.nl1_3.1.100.v200606220026.jar,
org.eclipse.ant.ui.nl1_3.2.0.v200606220026.jar, org.eclipse.compare.nl1_3.2.0.v200606220026.jar,
org.eclipse.core.boot.nl1_3.1.100.v200606220026.jar,
org.eclipse.core.commands.nl1_3.2.0.v200606220026.jar,
org.eclipse.core.contenttype.nl1_3.2.0.v200606220026.jar,
org.eclipse.core.expressions.nl1_3.2.0.v200606220026.jar,
org.eclipse.core.filebuffers.nl1_3.2.0.v200606220026.jar,
org.eclipse.core.filesystem.nl1_1.0.0.v200606220026.jar,
org.eclipse.core.jobs.nl1_3.2.0.v200606220026.jar,
org.eclipse.core.resources.nl1_3.2.0.v200606220026.jar,
org.eclipse.core.runtime.compatibility.auth.nl1_3.2.0.v200606220026.jar,
org.eclipse.core.runtime.compatibility.nl1_3.1.100.v200606220026.jar,
org.eclipse.core.runtime.nl1_3.2.0.v200606220026.jar,
org.eclipse.core.variables.nl1_3.1.100.v200606220026.jar,
org.eclipse.debug.core.nl1_3.2.0.v200606220026.jar,
org.eclipse.debug.ui.nl1_3.2.0.v200606220026.jar,
org.eclipse.equinox.common.nl1_3.2.0.v200606220026.jar,
org.eclipse.equinox.preferences.nl1_3.2.0.v200606220026.jar,
org.eclipse.equinox.registry.nl1_3.2.0.v200606220026.jar,
org.eclipse.help.appserver.nl1_3.1.100.v200606220026.jar,
org.eclipse.help.base.nl1_3.2.0.v200606220026.jar, org.eclipse.help.nl1_3.2.0.v200606220026.jar,
org.eclipse.help.ui.nl1_3.2.0.v200606220026.jar, org.eclipse.jdt.apt.core.nl1_3.2.0.v200606220026.jar,
org.eclipse.jdt.apt.ui.nl1_3.2.0.v200606220026.jar,
org.eclipse.jdt.core.manipulation.nl1_1.0.0.v200606220026.jar,
org.eclipse.jdt.core.nl1_3.2.0.v200606220026.jar,
org.eclipse.jdt.debug.ui.nl1_3.2.0.v200606220026.jar,
org.eclipse.jdt.doc.isv.nl1_3.2.0.v200606220026.jar,
org.eclipse.jdt.doc.user.nl1_3.2.0.v200606220026.jar,
org.eclipse.jdt.junit4.runtime.nl1_1.0.0.v200606220026.jar,
org.eclipse.jdt.launching.nl1_3.2.0.v200606220026.jar, org.eclipse.jdt.nl1_3.2.0.v200606220026.jar,
org.eclipse.jdt.ui.nl1_3.2.0.v200606220026.jar,
org.eclipse.jface.databinding.nl1_1.0.0.v200606220026.jar,
org.eclipse.jface.nl1_3.2.0.v200606220026.jar, org.eclipse.jface.text.nl1_3.2.0.v200606220026.jar,
org.eclipse.ltk.core.refactoring.nl1_3.2.0.v200606220026.jar,
org.eclipse.ltk.ui.refactoring.nl1_3.2.0.v200606220026.jar,
org.eclipse.osgi.nl1_3.2.0.v200606220026.jar, org.eclipse.osgi.services.nl1_3.1.100.v200606220026.jar,
org.eclipse.osgi.util.nl1_3.1.100.v200606220026.jar, org.eclipse.pde.core.nl1_3.2.0.v200606220026.jar,
org.eclipse.pde.doc.user.nl1_3.2.0.v200606220026.jar,
org.eclipse.pde.junit.runtime.nl1_3.2.0.v200606220026.jar,
org.eclipse.pde.nl1_3.2.0.v200606220026.jar, org.eclipse.pde.runtime.nl1_3.2.0.v200606220026.jar,
org.eclipse.pde.ui.nl1_3.2.0.v200606220026.jar,
org.eclipse.platform.doc.isv.nl1_3.2.0.v200606220026.jar,
org.eclipse.platform.doc.user.nl1_3.2.0.v200606220026.jar,
org.eclipse.rcp.nl1_3.2.0.v200606220026.jar, org.eclipse.search.nl1_3.2.0.v200606220026.jar,
org.eclipse.swt.nl1_3.2.0.v200606220026.jar, org.eclipse.team.core.nl1_3.2.0.v200606220026.jar,
org.eclipse.team.cvs.core.nl1_3.2.0.v200606220026.jar,
org.eclipse.team.cvs.ssh.nl1_3.2.0.v200606220026.jar,
org.eclipse.team.cvs.ssh2.nl1_3.2.0.v200606220026.jar,
org.eclipse.team.cvs.ui.nl1_3.2.0.v200606220026.jar, org.eclipse.team.ui.nl1_3.2.0.v200606220026.jar,
org.eclipse.text.nl1_3.2.0.v200606220026.jar, org.eclipse.ui.browser.nl1_3.2.0.v200606220026.jar,
org.eclipse.ui.cheatsheets.nl1_3.2.0.v200606220026.jar,
org.eclipse.ui.console.nl1_3.1.100.v200606220026.jar,
org.eclipse.ui.editors.nl1_3.2.0.v200606220026.jar,
org.eclipse.ui.externaltools.nl1_3.1.100.v200606220026.jar,
org.eclipse.ui.forms.nl1_3.2.0.v200606220026.jar, org.eclipse.ui.ide.nl1_3.2.0.v200606220026.jar,
org.eclipse.ui.intro.nl1_3.2.0.v200606220026.jar, org.eclipse.ui.navigator.nl1_3.2.0.v200606220026.jar,
org.eclipse.ui.navigator.resources.nl1_3.2.0.v200606220026.jar,
org.eclipse.ui.nl1_3.2.0.v200606220026.jar,
org.eclipse.ui.presentations.r21.nl1_3.2.0.v200606220026.jar,
org.eclipse.ui.views.nl1_3.2.0.v200606220026.jar,
org.eclipse.ui.views.properties.tabbed.nl1_3.2.0.v200606220026.jar,
org.eclipse.ui.workbench.nl1_3.2.0.v200606220026.jar,
org.eclipse.ui.workbench.texteditor.nl1_3.2.0.v200606220026.jar,
org.eclipse.update.configurator.nl1_3.2.0.v200606220026.jar,
org.eclipse.update.core.nl1_3.2.0.v200606220026.jar,
org.eclipse.update.scheduler.nl1_3.2.0.v200606220026.jar,
org.eclipse.update.ui.nl1_3.2.0.v200606220026.jar,
com.ibm.icu_3.4.4.1.jar,
org.eclipse.core.commands_3.2.0.I20060605-1400.jar,
org.eclipse.core.contenttype_3.2.0.v20060603.jar,
org.eclipse.core.expressions_3.2.0.v20060605-1400.jar,
org.eclipse.core.filesystem.linux.x86_1.0.0.v20060603.jar,
org.eclipse.core.filesystem_1.0.0.v20060603.jar, org.eclipse.core.jobs_3.2.0.v20060603.jar,
org.eclipse.core.runtime.compatibility.auth_3.2.0.v20060601.jar,
org.eclipse.core.runtime_3.2.0.v20060603.jar, org.eclipse.equinox.common_3.2.0.v20060603.jar,
org.eclipse.equinox.preferences_3.2.0.v20060601.jar, org.eclipse.equinox.registry_3.2.0.v20060601.jar,
org.eclipse.help_3.2.0.v20060602.jar, org.eclipse.jface.text_3.2.0.v20060605-1400.jar,
org.eclipse.jface_3.2.0.I20060605-1400.jar, org.eclipse.osgi_3.2.0.v20060601.jar,
org.eclipse.swt.gtk.linux.x86_3.2.0.v3232m.jar, org.eclipse.swt_3.2.0.v3232o.jar,
org.eclipse.text_3.2.0.v20060605-1400.jar,
org.eclipse.ui.workbench.texteditor_3.2.0.v20060605-1400.jar,
org.eclipse.ui.workbench_3.2.0.I20060605-1400.jar, org.eclipse.ui_3.2.0.I20060605-1400.jar,
runtime_registry_compatibility.jar, eclipse.exe, eclipse.ini, and startup.jar
(collectively, "Eclipse Software").
All Eclipse Software is distributed under the terms and conditions of the Eclipse Foundation Software
User Agreement (EFSUA) and/or terms and conditions of the Eclipse Public License Version 1.0 (EPL) or
other license agreements, notices or terms and conditions referenced for the individual pieces of the
Eclipse Software, including without limitation "Abouts", "Feature Licenses", and "Feature Update
Licenses" as defined in the EFSUA.
A copy of the Eclipse Foundation Software User Agreement is found at
<install_dir>/platformrcp/5_5/rcpdependencies/windows/eclipse/plugins/notice.html,
<install_dir>/platformrcp/5_5/rcpdependencies/windows/eclipse/plugins/notice.html,
<install_dir>/platformrcp/5_5/rcpdependencies/gtk.linux.x86/eclipse/plugins/notice.html, and
<install_dir>/platformrcp/5_5/rcpdependencies/gtk.linux.x86/eclipse/plugins/notice.html.
A copy of the EPL is found at
<install_dir>/platformrcp/5_5/rcpdependencies/windows/eclipse/plugins/epl-v10.htm,
<install_dir>/platformrcp/5_5/rcpdependencies/windows/eclipse/plugins/eclipse/epl-v10.htm,
<install_dir>/platformrcp/5_5/rcpdependencies/gtk.linux.x86/eclipse/plugins/epl-v10.html, and
<install_dir>/platformrcp/5_5/rcpdependencies/gtk.linux.x86/eclipse/plugins/epl-v10.html.
The reference to the license agreements, notices or terms and conditions governing each individual piece
of the Eclipse Software is found in the directory files for the individual pieces of the Eclipse Software as
described in the file identified as installdir/SCI_License.txt.

These licenses only apply to the Eclipse Software and do not apply to the Sterling Commerce Software,
or any other Third Party Software.
The Language Pack (NL Pack) piece of the Eclipse Software, is distributed in object code form. Source
code is available at
http://archive.eclipse.org/eclipse/downloads/drops/L-3.2_Language_Packs-200607121700/index.php. In
the event the source code is no longer available from the website referenced above, contact Sterling
Commerce at 978-513-6000 and ask for the Release Manager. A copy of this license is located at
<install_dir>/SI/repository/rcp/rcpdependencies/windows/eclipse/plugins/epl-v10.htm and
<install_dir>/SI/repository/rcp/rcpdependencies/gtk.linux.x86/eclipse/plugins/epl-v10.html.
The org.eclipse.core.runtime_3.2.0.v20060603.jar piece of the Eclipse Software was modified slightly in
order to remove classes containing encryption items. The org.eclipse.core.runtime_3.2.0.v20060603.jar
was modified to remove the Cipher, CipherInputStream and CipherOutputStream classes and rebuild the
org.eclipse.core.runtime_3.2.0.v20060603.jar.
Ehcache Software
The Sterling Commerce Software is also distributed with or on the same storage media as the Ehcache
v.1.5 software (Copyright © 2003-2008 Luck Consulting Pty. Ltd.) ("Ehcache Software"). Ehcache
Software is free software which is distributed under the terms of the Apache License Version 2.0. A copy
of License Version 2.0 is found in <install>/jar/smcfs/9.0/ehcache-1.5.0.jar (./LICENSE.txt).
The Ehcache Software was not modified. Neither the Sterling Commerce Software, modifications, if any,
to the Ehcache Software, nor other Third Party Code is a Derivative Work or a Contribution as defined in
License Version 2.0. License Version 2.0 applies only to the Ehcache Software which is the subject of the
specific directory file and does not apply to the Sterling Commerce Software or to any other Third Party
Software. License Version 2.0 includes the following provision:
"Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS
OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of
TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are
solely responsible for determining the appropriateness of using or redistributing the Work and assume
any risks associated with Your exercise of permissions under this License."

ESAPI SOFTWARE
The Sterling Commerce Software is also distributed with or on the same storage media
as the ESAPI software (Copyright © 2007, the OWASP Foundation) ("ESAPI Software"). ESAPI Software
Software is free software which is distributed under the terms of the following license:
Copyright © 2007, The OWASP Foundation
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided
that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the
following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of the OWASP Foundation nor the names of its contributors may be used to endorse or
promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

EZMorph Software
The Sterling Commerce Software is also distributed with or on the same storage media as the EZMorph
v. 1.0.4 software (Copyright © 2006-2008 Andres Almiray) ("EZMorph Software"). EZMorph Software is
free software which is distributed under the terms of the Apache License Version 2.0. A copy of License
Version 2.0 is found in <install>/jar/ezmorph/1_0_4/ezmorph-1.0.4.jar (./LICENSE.txt).
The EZMorph Software was not modified. Neither the Sterling Commerce Software, modifications, if any,
to the EZMorph Software, nor other Third Party Code is a Derivative Work or a Contribution as defined in
License Version 2.0. License Version 2.0 applies only to the EZMorph Software which is the subject of the
specific directory file and does not apply to the Sterling Commerce Software or to any other Third Party
Software. License Version 2.0 includes the following provision:
"Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS
OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of
TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are
solely responsible for determining the appropriateness of using or redistributing the Work and assume
any risks associated with Your exercise of permissions under this License."

Firebug Lite Software

The Sterling Commerce Software is distributed with or on the same storage media as the Firebug Lite
Software which is free software distributed under the terms of the following license:
Copyright © 2008 Azer Koçulu http://azer.kodfabrik.com. All rights reserved.
Redistribution and use of this software in source and binary forms, with or without modification, are
permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the
following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of Azer Koçulu. nor the names of any other contributors may be used to endorse or
promote products derived from this software without specific prior written permission of Parakey Inc.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

JAVASCRIPT MINIFIER
The Sterling Commerce Software is distributed with or on the same storage media as the JSMin Software
which is free software distributed under the terms of the following license:
JSMin.java 2006-02-13; Updated 2007-08-20 with updates from jsmin.c (2007-05-22)
Copyright © 2006 John Reilly (www.inconspicuous.org)
This work is a translation from C to Java of jsmin.c published by Douglas Crockford. Permission is hereby
granted to use the Java version under the same conditions as the jsmin.c on which it is based.
jsmin.c 2003-04-21
Copyright © 2002 Douglas Crockford (www.crockford.com)
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and
associated documentation files (the "Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the
following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial
portions of the Software.
The Software shall be used for Good, not Evil.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

ICE SOFTWARE
The Sterling Commerce Software is distributed on the same storage media as the ICE Software
(Copyright © 1997 ICE Engineering, Inc./Timothy Gerard Endres.) ("ICE Software"). The ICE Software is
independent from and not linked or compiled with the Sterling Commerce Software. The ICE Software is
a free software product which can be distributed and/or modified under the terms of the GNU General
Public License as published by the Free Software Foundation; either version 2 of the License or any later
version.
A copy of the GNU General Public License is provided at installdir/jar/jniregistry/1_2/ICE_License.txt.
This license only applies to the ICE Software and does not apply to the Sterling Commerce Software, or
any other Third Party Software.
The ICE Software was modified slightly in order to fix a problem discovered by Sterling Commerce
involving the RegistryKey class in the RegistryKey.java in the JNIRegistry.jar. The class was modified to
comment out the finalize () method and rebuild of the JNIRegistry.jar file.
Source code for the bug fix completed by Sterling Commerce on January 8, 2003 is located at:
installdir/jar/jniregistry/1_2/RegistryKey.java. Source code for all other components of the ICE Software
is located at http://www.trustice.com/java/jnireg/index.shtml.
The ICE Software is distributed WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

JBOSS SOFTWARE
The Sterling Commerce Software is distributed on the same storage media as the JBoss Software
(Copyright © 1999-2002 JBoss.org) ("JBoss Software"). The JBoss Software is independent from and not
linked or compiled with the Sterling Commerce Software. The JBoss Software is a free software product
which can be distributed and/or modified under the terms of the GNU Lesser General Public License as
published by the Free Software Foundation; either version 2.1 of the License or any later version.
A copy of the GNU Lesser General Public License is provided at:
<install_dir>\jar\jboss\4_2_0\LICENSE.html
This license only applies to the JBoss Software and does not apply to the Sterling Commerce Software,
or any other Third Party Software.
The JBoss Software is not distributed by Sterling Commerce in its entirety. Rather, the distribution is
limited to the following jar files: el-api.jar, jasper-compiler-5.5.15.jar, jasper-el.jar, jasper.jar,
jboss-common-client.jar, jboss-j2ee.jar, jboss-jmx.jar, jboss-jsr77-client.jar, jbossmq-client.jar,
jnpserver.jar, jsp-api.jar, servlet-api.jar, tomcat-juli.jar.
The JBoss Software was modified slightly in order to allow the ClientSocketFactory to return a socket
connected to a particular host in order to control the host interfaces, regardless of whether the
ClientSocket Factory specified was custom or note. Changes were made to org.jnp.server.Main. Details
concerning this change can be found at
http://sourceforge.net/tracker/?func=detail&aid=1008902&group_id=22866&atid=376687.
Source code for the modifications completed by Sterling Commerce on August 13, 2004 is located at:
http://sourceforge.net/tracker/?func=detail&aid=1008902&group_id=22866&atid=376687. Source code
for all other components of the JBoss Software is located at http://www.jboss.org.

JGO SOFTWARE
The Sterling Commerce Software is distributed with, or on the same storage media, as certain
redistributable portions of the JGo Software provided by Northwoods Software Corporation under a
commercial license agreement (the "JGo Software"). The JGo Software is provided subject to the
disclaimers set forth above and the following notice:
U.S. Government Restricted Rights
The JGo Software and documentation are provided with RESTRICTED RIGHTS. Use, duplication, or
disclosure by the Government is subject to restrictions as set forth in subparagraph (C)(1)(ii) of the
Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or subparagraphs (C)(1)
and (2) of the Commercial Computer Software - Restricted Rights at 48 CFR 52.227-19, as applicable.
Contractor / manufacturer of the JGo Software is Northwoods Software Corporation, 142 Main St.,
Nashua, NH 03060.

JSDoc Tookit Software

The Sterling Commerce Software is distributed with or on the same storage media as the JSDoc Toolkit
software (Copyright © 2008 Michael Mathews) ("JSDoc Toolkit Software"), which is subject to the
following license:
All code specific to JsDoc Toolkit are free, open source and licensed for use under the X11/MIT License.
JsDoc Toolkit is Copyright © 2008 Michael Mathews <micmath@gmail.com>
This program is free software; you can redistribute it and/or modify it under the terms below.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and
associated documentation files (the "Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the
following conditions: The above copyright notice and this permission notice must be included in all copies
or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

JSLib Software
The Sterling Commerce Software is distributed with or on the same storage media as the JSLib software
product (Copyright © 2003-2009 Mozdev Group, Inc.) ("JSLib Software"). The JSLib Software is
distributed under the terms of the MOZILLA PUBLIC LICENSE Version 1.1. A copy of this license is
located at <install>/repository/eardata/platform_uifwk_ide/war/designer/MPL-1.1.txt. The JSLib
Software code is distributed in source form and is located at http://jslib.mozdev.org/installation.html.
Neither the Sterling Commerce Software nor any other Third Party Code is a Modification or Contribution
subject to the Mozilla Public License. Pursuant to the terms of the Mozilla Public License, the following
notice applies only to the JSLib Software (and not to the Sterling Commerce Software or any other Third
Party Software):
"The contents of the file located at http://www.mozdev.org/source/browse/jslib/ are subject to the
Mozilla Public License Version 1.1 (the "License"); you may not use this file except in compliance with the
License. You may obtain a copy of the License at http://www.mozilla.org/MPL/
Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY
KIND, either express or implied. See the License for the specific language governing rights and
limitations under the License.
The Original Code is Mozdev Group, Inc. code. The Initial Developer of the Original Code is Mozdev
Group, Inc. Portions created by_Mozdev Group, Inc. are Copyright © 2003 Mozdev Group, Inc. All Rights
Reserved. Original Author: Pete Collins <pete@mozdev.org>one Contributor(s):_____none
listed________.
Alternatively, the contents of this file may be used under the terms of the ____ license (the "[___]
License"), in which case the provisions of [___] License are applicable instead of those above. If you
wish to allow use of your version of this file only under the terms of the [___] License and not allow
others to use your version of this file under the MPL, indicate your decision by deleting the provisions
above and replace them with the notice and other provisions required by the [___] License. If you do not
delete the provisions above, a recipient may use your version of this file under either the MPL or the
[___] License."
The preceding license only applies to the JSLib Software and does not apply to the Sterling Commerce
Software, or any other Third Party Software.

Json Software
The Sterling Commerce Software is also distributed with or on the same storage media as the Json 2.2.2
software (Copyright © 2006-2008 Json-lib) ("Json Software"). Json Software is free software which is
distributed under the terms of the Apache License Version 2.0. A copy of License Version 2.0 is found in
<install>/jar/jsonlib/2_2_2/json-lib-2.2.2-jdk13.jar.
This product includes software developed by Douglas Crockford (http://www.crockford.com).
The Json Software was not modified. Neither the Sterling Commerce Software, modifications, if any, to
the Json Software, nor other Third Party Code is a Derivative Work or a Contribution as defined in
License Version 2.0. License Version 2.0 applies only to the Json Software which is the subject of the
specific directory file and does not apply to the Sterling Commerce Software or to any other Third Party
Software. License Version 2.0 includes the following provision:
"Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS
OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of
TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are
solely responsible for determining the appropriateness of using or redistributing the Work and assume
any risks associated with Your exercise of permissions under this License."

Prototype Software
The Sterling Commerce Software is distributed with or on the same storage media as the Prototype
software (Copyright © 2005-2008 Sam Stephenson) ("Prototype Software"), which is subject to the
following license:
Copyright © 2005-2008 Sam Stephenson
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and
associated documentation files (the "Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the
following conditions:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Purple Technology
The Sterling Commerce Software is distributed with or on the same storage media as the Purple
Technology Software (Copyright © 1995-1999 Purple Technology, Inc.) ("Purple Technology Software"),
which is subject to the following license:
Copyright © 1995-1999 Purple Technology, Inc. All rights reserved.
PLAIN LANGUAGE LICENSE: Do whatever you like with this code, free of charge, just give credit where
credit is due. If you improve it, please send your improvements to alex@purpletech.com. Check
http://www.purpletech.com/code/ for the latest version and news.
LEGAL LANGUAGE LICENSE: Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the
following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or other materials provided with the distribution.
3. The names of the authors and the names "Purple Technology," "Purple Server" and "Purple Chat" must
not be used to endorse or promote products derived from this software without prior written permission.
For written permission, please contact server@purpletech.com.
THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND PURPLE TECHNOLOGY "AS IS'' AND ANY
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE AUTHORS OR PURPLE TECHNOLOGY BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The preceding license only applies to the Purple Technology Software and does not apply to the Sterling
Commerce Software, or any other Third Party Software.

Rico Software
The Sterling Commerce Software is also distributed with or on the same storage media as the Rico.js
software (Copyright © 2005 Sabre Airline Solutions) ("Rico Software"). Rico Software is free software
which is distributed under the terms of the Apache License Version 2.0. A copy of License Version 2.0 is
found in <install>/repository/eardata/platform/war/ajax/scripts/Rico_License.txt.
The Rico Software was not modified. Neither the Sterling Commerce Software, modifications, if any, to
the Rico Software, nor other Third Party Code is a Derivative Work or a Contribution as defined in License
Version 2.0. License Version 2.0 applies only to the Rico Software which is the subject of the specific
directory file and does not apply to the Sterling Commerce Software or to any other Third Party
Software. License Version 2.0 includes the following provision:
"Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS
OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of
TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are
solely responsible for determining the appropriateness of using or redistributing the Work and assume
any risks associated with Your exercise of permissions under this License."

Rhino Software
The Sterling Commerce Software is distributed with or on the same storage media as the Rhino js.jar
(Copyright © 1998-2009 Mozilla.org.) ("Rhino Software"). A majority of the source code for the Rhino
Software is dual licensed under the terms of the MOZILLA PUBLIC LICENSE Version 1.1. or the GPL v.
2.0. Additionally, some files (at a minimum the contents of
toolsrc/org/Mozilla/javascript/toolsdebugger/treetable) are available under another license as set forth in
the directory file for the Rhino Software.
Sterling Commerce's use and distribution of the Rhino Software is under the Mozilla Public License. A
copy of this license is located at <install>/jar/rhino/1_7R1/License.txt. The Rhino Software code is
distributed in source form and is located at http://mxr.mozilla.org/mozilla/source/js/rhino/src/. Neither
the Sterling Commerce Software nor any other Third Party Code is a Modification or Contribution subject
to the Mozilla Public License. Pursuant to the terms of the Mozilla Public License, the following notice
applies only to the Rhino Software (and not to the Sterling Commerce Software or any other Third Party
Software):
"The contents of the file located at <install>/jar/rhino/1_7R1/js.jar are subject to the Mozilla Public
License Version 1.1 (the "License"); you may not use this file except in compliance with the License. You
may obtain a copy of the License at http://www.mozilla.org/MPL/
Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY
KIND, either express or implied. See the License for the specific language governing rights and
limitations under the License.
The Original Code is Rhino code, released May 6, 1999. The Initial Developer is Netscape
Communications Corporation. Portions created by the Initial Developer are Copyright © 1997-1999. All
Rights Reserved. Contributor(s):_____none listed.
The preceding license only applies to the Rico Software and does not apply to the Sterling Commerce
Software, or any other Third Party Software

SLF4J Software
The Sterling Commerce Software is also distributed with or on the same storage media as the SLF4J
software (Copyright © 2004-2008) ("SLF4J Software"), which is subject to the following license:
Copyright © 2004-2008 QOS.ch All rights reserved.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and
associated documentation files (the "Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the
following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial
portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Sun Microsystems
The Sterling Commerce Software is distributed with or on the same storage media
as the following software products (or components thereof): Sun JMX, and Sun JavaMail (collectively,
"Sun Software"). Sun Software is free software which is distributed under the terms of the licenses
issued by Sun which are included in the directory files located at:
SUN COMM JAR -installdir/jar/comm/2_0
SUN ACTIVATION JAR -installdir/jar/jaf/1_0_2
SUN JavaMail -installdir/jar/javamail/1_4
The Sterling Commerce Software is also distributed with or on the same storage media as the
Web-app_2_3.dtd software (Copyright © 2007 Sun Microsystems, Inc.) ("Web-App Software").
Web-App Software is free software which is distributed under the terms of the Common Development
and Distribution License ("CDDL"). A copy of
<install>/repository/eardata/platform/war/WEB-INF/web_app_License.txt.
The source code for the Web-App Software may be found at:http://java.sun.com/dtd/.
Such licenses only apply to the Sun product which is the subject of such directory and does not apply to
the Sterling Commerce Software or to any other Third Party Software.
The Sterling Commerce Software is also distributed with or on the same storage media as the Sun
Microsystems, Inc. Java (TM) look and feel Graphics Repository ("Sun Graphics Artwork"), subject to the
following terms and conditions:
Copyright 2000 by Sun Microsystems, Inc. All Rights Reserved.
Sun grants you ("Licensee") a non-exclusive, royalty free, license to use, and redistribute this software
graphics artwork, as individual graphics or as a collection, as part of software code or programs that you
develop, provided that i) this copyright notice and license accompany the software graphics artwork; and
ii) you do not utilize the software graphics artwork in a manner which is disparaging to Sun. Unless
enforcement is prohibited by applicable law, you may not modify the graphics, and must use them true
to color and unmodified in every way.
This software graphics artwork is provided "AS IS," without a warranty of any kind. ALL EXPRESS OR
IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY
EXCLUDED. SUN AND ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY
LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE GRAPHICS
ARTWORK.
IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR
FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER
CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR INABILITY
TO USE SOFTWARE GRAPHICS ARTWORK, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
If any of the above provisions are held to be in violation of applicable law, void, or unenforceable in any
jurisdiction, then such provisions are waived to the extent necessary for this Disclaimer to be otherwise
enforceable in such jurisdiction.
The preceding license only applies to the Sun Graphics Artwork and does not apply to the Sterling
Commerce Software, or any other Third Party Software.

WARRANTY DISCLAIMER
This documentation and the Sterling Commerce Software which it describes are licensed either "AS IS"
or with a limited warranty, as set forth in the Sterling Commerce license agreement. Other than any
limited warranties provided, NO OTHER WARRANTY IS EXPRESSED AND NONE SHALL BE IMPLIED,
INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR USE OR FOR A PARTICULAR
PURPOSE. The applicable Sterling Commerce entity reserves the right to revise this publication from time
to time and to make changes in the content hereof without the obligation to notify any person or entity
of such revisions or changes.
The Third Party Software is provided "AS IS" WITHOUT ANY WARRANTY AND ANY EXPRESSED OR
IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. FURTHER, IF YOU
ARE LOCATED OR ACCESSING THIS SOFTWARE IN THE UNITED STATES, ANY EXPRESS OR IMPLIED
WARRANTY REGARDING TITLE OR NON-INFRINGEMENT ARE DISCLAIMED.
Without limiting the foregoing, the ICE Software and JBoss Software are distributed WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
 Contents

Preface
Intended Audience ................................................................................... xxxix
Structure ................................................................................................ xxxix
Selling and Fulfillment Foundation Documentation .......................................... xliii
Conventions ............................................................................................... xlv

1 Introduction
1.1 Business Models................................................................................. 2
1.1.1 Multi-Divisional Corporation ............................................................ 2
1.1.2 Third-Party Logistics ..................................................................... 2
1.1.3 Marketplace ................................................................................. 3
1.2 Sterling Distributed Order Management Configuration ............................. 3
1.2.1 Sourcing Setup ............................................................................. 4
1.2.2 Logistics ...................................................................................... 5
1.2.3 Financials..................................................................................... 5
1.2.4 Customer ..................................................................................... 5
1.2.5 Order Attributes ............................................................................ 5
1.2.6 Order Validation ............................................................................ 6
1.2.7 Instruction Types .......................................................................... 6
1.2.8 Modification Reasons ..................................................................... 6
1.2.9 Backorder Reasons ........................................................................ 6
1.2.10 Process Type Configuration............................................................. 6
1.2.11 Purge Criteria ............................................................................... 7

xix
2 Navigating the Applications Manager
2.1 Starting the Applications Manager ........................................................ 9
2.2 The Applications Manager Layout........................................................ 10
2.2.1 Application Rules Side Panel ......................................................... 12
2.2.1.1 Accessing Configuration Screens............................................... 13
2.2.1.2 Determining Inheritance.......................................................... 14
2.2.1.3 Loading Another Organization’s Rules........................................ 21
2.2.2 Work Area .................................................................................. 23
2.2.2.1 Search Window ...................................................................... 23
2.2.2.2 List Window ........................................................................... 24
2.2.2.3 Details Window ...................................................................... 25
2.2.2.4 Drag and Drop Window ........................................................... 26
2.3 Actions Available in the Applications Manager....................................... 28
2.3.1 Using the Configurator’s Lookup Functionality ................................. 28
2.3.2 Viewing the Document Types Associated with an Application ............. 29
2.3.2.1 Adding a Document Type to an Application ................................ 30
2.3.3 Viewing the User Logged into the Configurator ................................ 31
2.3.4 Using Lists and List Filtering.......................................................... 31
2.3.5 Date and Time Entry .................................................................... 34
2.3.6 Using Online Help ........................................................................ 34
2.3.7 Troubleshooting Errors ................................................................. 34
2.3.8 Using Special Characters .............................................................. 35

3 Configuring Cross-Application Order Promising Components

3.1 Configuring the Fulfillment Network Model ........................................... 38
3.1.1 Navigating in the Fulfillment Network Model .................................... 38
3.1.1.1 Using Filter Criteria................................................................. 42
3.1.2 Defining Distribution Groups ......................................................... 43
3.1.2.1 Creating a Distribution Group................................................... 44
3.1.2.2 Modifying a Distribution Group ................................................. 45
3.1.2.3 Deleting a Distribution Group ................................................... 45
3.1.3 Defining Node Types .................................................................... 46
3.1.3.1 Creating a Node Type ............................................................. 46
3.1.3.2 Modifying a Node Type ............................................................ 47

xx Configuration Guide
3.1.3.3 Deleting a Node Type...............................................................47
3.1.4 Defining Nodes ............................................................................47
3.1.4.1 Creating a Node ......................................................................47
3.1.4.2 Modifying a Node ....................................................................50
3.1.5 Defining Relationship Types ...........................................................51
3.1.5.1 Creating a Relationship Type.....................................................51
3.1.5.2 Modifying a Relationship Type ...................................................52
3.1.5.3 Deleting a Relationship Type .....................................................52
3.1.6 Defining Relationships...................................................................53
3.1.6.1 Creating a Relationship ............................................................53
3.1.6.2 Modifying a Relationship...........................................................54
3.1.6.3 Deleting a Relationship ............................................................56
3.2 Defining Item Level Controls...............................................................56
3.3 Defining Levels of Service ..................................................................57
3.3.1 Creating a Level of Service ............................................................57
3.3.2 Modifying a Level of Service...........................................................58
3.3.3 Deleting a Level of Service ............................................................59
3.4 Defining Node Level Controls ..............................................................59
3.4.1 Defining a Node’s Primary Order Promising Information.....................59
3.4.2 Defining a Node’s Relationships......................................................63
3.4.2.1 Creating a Node Relationship ....................................................64
3.4.2.2 Modifying a Node Relationship...................................................66
3.4.2.3 Deleting a Node Relationship ....................................................66
3.4.2.4 Creating a Transfer Schedule ....................................................67
3.4.2.5 Modifying a Transfer Schedule...................................................69
3.4.2.6 Deleting a Transfer Schedule ....................................................69
3.4.3 Defining Notification Periods ..........................................................70
3.4.3.1 Creating a Notification Period ....................................................70
3.4.3.2 Modifying a Notification Period ..................................................72
3.4.3.3 Deleting a Notification Period ....................................................73
3.4.3.4 Specifying Levels of Service ......................................................73
3.5 Defining Sourcing and Scheduling Rules ...............................................74
3.5.1 Defining Fulfillment Types .............................................................75
3.5.1.1 Creating a Fulfillment Type .......................................................75
3.5.1.2 Modifying a Fulfillment Type .....................................................76

xxi
 3.5.1.3 Deleting a Fulfillment Type ...................................................... 77
3.5.2 Defining Basic Sourcing Configuration ............................................ 77
3.5.3 Defining Order Sourcing Classifications........................................... 80
3.5.3.1 Creating an Order Sourcing Classification................................... 80
3.5.3.2 Modifying an Order Sourcing Classification ................................. 81
3.5.3.3 Deleting an Order Sourcing Classification ................................... 82
3.5.4 Defining Sourcing Region Selection ................................................ 82
3.5.5 Defining Scheduling Rules ............................................................ 83
3.5.5.1 Creating a Scheduling Rule ...................................................... 85
3.5.5.2 Modifying a Scheduling Rule .................................................... 92
3.5.5.3 Deleting a Scheduling Rule ...................................................... 92
3.5.6 Configuring Landed Cost Optimization ............................................ 92
3.5.6.1 Currency Details..................................................................... 96
3.5.6.2 Defining Enterprise Node Type Rules ......................................... 97
3.5.7 Defining Forwarding/Transfer Rules ..............................................100
3.5.8 Defining Distribution Groups for Product Items ...............................102
3.5.8.1 Creating a Distribution Group..................................................103
3.5.8.2 Adding Advanced Distribution Details to a Distribution Group (For
Backward Compatibility Only) ..................................................106
3.5.8.3 Deleting Advanced Distribution Details .....................................107
3.5.8.4 Deleting a Distribution Group ..................................................108
3.5.9 Defining Sourcing Rules for Product Items .....................................108
3.5.9.1 Creating a Product Item Sourcing Rule .....................................109
3.5.9.2 Modifying a Product Item Sourcing Rule....................................112
3.5.9.3 Deleting a Product Item Sourcing Rule .....................................113
3.5.10 Defining Sourcing Rules for Delivery Service Items .........................113
3.5.10.1 Creating a Delivery Service Item Sourcing Rule .........................113
3.5.10.2 Modifying a Delivery Service Sourcing Rule ...............................116
3.5.10.3 Deleting a Delivery Service Sourcing Rule .................................117
3.5.11 Defining Distribution Groups for Provided Service Items ..................117
3.5.11.1 Creating a Distribution Group..................................................117
3.5.11.2 Deleting a Distribution Group ..................................................120
3.5.12 Defining Sourcing Rules for Provided Service Items.........................120
3.5.12.1 Creating a Provided Service Item Sourcing Rule.........................121
3.5.12.2 Modifying a Provided Service Sourcing Rule ..............................124

xxii Configuration Guide

 3.5.12.3 Deleting a Provided Service Sourcing Rule ................................ 124
3.5.13 Defining Procurement Rules ......................................................... 124
3.5.13.1 Creating a Sourcing Rule for Procurement................................. 125
3.5.13.2 Modifying a Sourcing Rule for Procurement ............................... 127
3.5.13.3 Deleting a Product Procurement Rule ....................................... 128
3.5.13.4 Creating a Procurement Distribution Group ............................... 128
3.5.13.5 Modifying a Procurement Distribution Group.............................. 129
3.5.13.6 Deleting a Procurement Distribution Group ............................... 129
3.5.14 Defining Sourcing Template Details............................................... 130
3.5.14.1 Applying a Sourcing Template to a Sourcing Rule....................... 130
3.5.14.2 Modifying a Sourcing Template for a Sourcing Rule .................... 132
3.5.14.3 Removing a Sourcing Template from a Sourcing Rule ................. 132

4 Configuring Cross-Application Service Execution Components

4.1 Configuring Service Supervisors ........................................................ 133
4.1.1 Defining a Service Supervisor for a Node ....................................... 134
4.1.2 Modifying a Service Supervisor for a Node ..................................... 135
4.1.3 Deleting a Service Supervisor for a Node ....................................... 135
4.2 Configuring Questions...................................................................... 136
4.2.1 Defining Address Question Groups ................................................ 137
4.2.2 Modifying Address Question Groups .............................................. 138
4.2.3 Deleting Address Question Groups ................................................ 138
4.2.4 Defining Address Questions ......................................................... 138
4.2.5 Modifying Address Questions ....................................................... 140
4.2.6 Deleting Address Questions ......................................................... 140
4.2.7 Defining Capacity Impact ............................................................ 141
4.2.8 Modifying Capacity Impact........................................................... 142
4.2.9 Deleting Capacity Impact ............................................................ 143
4.2.10 Rearranging Address Question Entities .......................................... 143
4.2.11 Defining Permit Question Groups .................................................. 144
4.2.12 Modifying Permit Question Groups ................................................ 145
4.2.13 Deleting Permit Question Groups .................................................. 145
4.2.14 Defining Permit Questions ........................................................... 145
4.2.15 Modifying Permit Questions ......................................................... 147
4.2.16 Deleting Permit Questions ........................................................... 147

xxiii
 4.2.17 Rearranging Permit Questionnaire Entities .....................................147

5 Configuring Cross-Application Logistics Components

5.1 Defining Logistics Attributes..............................................................149
5.1.1 Defining Freight Terms................................................................149
5.1.1.1 Creating a Freight Term .........................................................150
5.1.1.2 Modifying a Freight Term ........................................................152
5.1.1.3 Deleting a Freight Term..........................................................152
5.1.2 Defining Carrier Modification Reasons............................................153
5.1.2.1 Creating a Carrier Modification Reason .....................................153
5.1.2.2 Modifying a Carrier Modification Reason....................................154
5.1.2.3 Deleting a Carrier Modification Reason .....................................154
5.1.3 Defining Additional Logistic Rules..................................................155
5.2 Defining Delivery Codes ...................................................................157
5.2.1 Creating a Delivery Code .............................................................157
5.2.2 Modifying a Delivery Code ...........................................................158
5.2.3 Deleting a Delivery Code .............................................................158
5.3 Defining Shipment Modes .................................................................158
5.3.1 Creating a Shipment Mode...........................................................159
5.3.2 Modifying a Shipment Mode .........................................................160
5.3.3 Deleting a Shipment Mode ...........................................................160
5.4 Defining Outbound Constraints..........................................................160
5.4.1 Creating a Routing Guide.............................................................163
5.4.2 Modifying a Routing Guide ...........................................................165
5.4.2.1 Creating a Routing Guide Line .................................................166
5.4.2.2 Modifying a Routing Guide Line ...............................................174
5.4.2.3 Deleting a Routing Guide Line .................................................174
5.4.3 Deleting a Routing Guide .............................................................174

6 Configuring Cross-Application Payment Components

6.1 System Payment Processing Rules .....................................................175
6.2 Defining Payment Types ...................................................................177
6.2.1 Creating a Payment Type ............................................................177
6.2.2 Modifying a Payment Type ...........................................................183

xxiv Configuration Guide

 6.2.3 Deleting a Payment Type............................................................. 184
6.3 Defining Payment Rules ................................................................... 184
6.3.1 Creating a Payment Rule ............................................................. 184
6.3.2 Modifying a Payment Rule ........................................................... 189
6.3.3 Deleting a Payment Rule ............................................................. 190

7 Configuring Cross-Application Pricing Components

7.1 Legacy Pricing Service ..................................................................... 191
7.1.1 Defining Pricing by Region ........................................................... 192
7.1.2 Defining Price Programs and Price Lists ......................................... 193
7.1.2.1 Creating a Price List............................................................... 195
7.1.2.2 Modifying a Price List ............................................................. 199
7.1.2.3 Deleting a Price List ............................................................... 199
7.1.2.4 Creating a Price Program........................................................ 200
7.1.2.5 Modifying a Price Program ...................................................... 202
7.1.2.6 Deleting a Price Program ........................................................ 202
7.2 Pricing Service ................................................................................ 202
7.2.1 Defining Region Schema for Selling............................................... 203
7.2.2 Defining Pricing Organization Rules............................................... 203
7.2.3 Defining Pricing Enterprise Rules .................................................. 207

8 Configuring Cross-Application Customer Components

8.1 Defining Region Usage for Selling ...................................................... 209
8.2 Defining Customer Rules .................................................................. 211
8.2.1 Defining Customer Classifications ................................................. 212
8.2.1.1 Creating a Customer Classification ........................................... 212
8.2.1.2 Modifying a Customer Classification ......................................... 213
8.2.1.3 Deleting a Customer Classification ........................................... 213
8.2.2 Defining Additional Customer Rules .............................................. 213
8.3 Defining Customer Definitions ........................................................... 214
8.3.1 Creating a Customer Definition..................................................... 215
8.3.2 Modifying a Customer Definition ................................................... 218
8.3.2.1 Defining the Customer’s Primary Information ............................ 219
8.3.2.2 Defining the Customer’s Service Preferences ............................. 220
8.3.2.3 Answering a Customer’s Address Questions .............................. 222

xxv
 8.3.2.4 Defining a Customer’s Scheduling Preferences ...........................222
8.3.2.5 Defining Customer Contacts....................................................223
8.3.2.6 Defining Additional Addresses .................................................228
8.3.3 Deleting a Customer Definition .....................................................230
8.4 Defining Contact Types ....................................................................230
8.4.1 Creating a Contact Type ..............................................................230
8.4.2 Modifying a Contact Type ............................................................231
8.4.3 Deleting a Contact Type ..............................................................232
8.5 Defining Customer Entitlements ........................................................232

9 Configuring a Document’s Attributes

9.1 Defining Order Types .......................................................................235
9.1.1 Creating an Order Type ...............................................................236
9.1.2 Modifying an Order Type .............................................................236
9.1.3 Deleting an Order Type ...............................................................237
9.2 Defining Order Sources ....................................................................237
9.2.1 Creating an Order Source ............................................................237
9.2.2 Modifying an Order Source ..........................................................238
9.2.3 Deleting an Order Source ............................................................239
9.3 Defining External References for the Order Level .................................239
9.3.1 Creating an External Reference for the Order Header Level ..............239
9.3.2 Modifying an External Reference for the Order Header Level.............240
9.3.3 Deleting an External Reference for the Order Header Level ..............241
9.4 Defining External References for the Order Line Level...........................241
9.4.1 Creating an External Reference for the Order Line Level ..................241
9.4.2 Modifying an External Reference for the Order Line Level .................242
9.4.3 Deleting an External Reference for the Order Line Level...................243
9.5 Defining Order Address Types ...........................................................243
9.5.1 Creating an Order Address Type ...................................................243
9.5.2 Modifying an Order Address Type .................................................244
9.5.3 Deleting an Order Address Type ...................................................245
9.6 Defining Line Types .........................................................................245
9.6.1 Creating a Line Type ...................................................................245
9.6.2 Modifying a Line Type .................................................................246
9.6.3 Deleting a Line Type ...................................................................246

xxvi Configuration Guide

 9.7 Defining Other Attributes ................................................................. 247
9.7.1 Generating a Prime Line Number for a New Line
from a Pre-Configured Number ..................................................... 247

10 Configuring a Document’s Order Validation

11 Configuring a Document’s Instruction Types

11.1 Creating an Instruction Type............................................................. 253
11.2 Modifying an Instruction Type ........................................................... 254
11.3 Deleting an Instruction Type ............................................................. 255

12 Configuring a Document’s Modification Reasons

12.1 Creating a Modification Reason ......................................................... 257
12.2 Modifying a Modification Reason ........................................................ 259
12.3 Deleting a Modification Reason.......................................................... 260

13 Configuring a Document’s Backorder Reasons

13.1 Creating a Backorder Reason ............................................................ 261
13.2 Modifying a Backorder Reason .......................................................... 262
13.3 Deleting a Backorder Reason ............................................................ 263

14 Configuring a Document’s Note Reasons

14.1 Creating a Note Reason.................................................................... 265
14.2 Modifying a Note Reason .................................................................. 266
14.3 Creating a New Note Reason Based on an Existing One ........................ 266
14.4 Deleting a Note Reason.................................................................... 267

15 Configuring a Quote Document’s Approval Rule Violation

Reason
15.1 Creating an Approval Rule Violation Reason ........................................ 269
15.2 Modifying an Approval Rule Violation Reason....................................... 270
15.3 Creating a New Approval Rule Violation
Reason Based on an Existing One ....................................................... 271

xxvii
 15.4 Deleting an Approval Rule Violation Reason ........................................271

16 Configuring a Document’s Line Relationship Type

16.1 Defining a Line Relationship Type ......................................................273
16.2 Modifying a Line Relationship Type ....................................................274
16.3 Creating a New Line Relationship Type Based on an Existing One...........275
16.3.1 Deleting a Line Relationship Type .................................................275

17 Configuring an Opportunity Document’s Lead Origin

17.1 Creating a Lead Origin .....................................................................277
17.2 Modifying a Lead Origin....................................................................278
17.3 Creating a New Lead Origin Based on an Existing One ..........................279
17.4 Deleting a Lead Origin......................................................................279

18 Configuring an Opportunity Document’s Lost Reason

18.1 Creating a Lost Reason ....................................................................281
18.2 Modifying a Lost Reason ...................................................................282
18.3 Creating a New Lost Reason Based on an Existing One .........................283
18.4 Deleting a Lost Reason.....................................................................283

19 Configuring a Document’s Modification Components

19.1 Defining Modification Rules ...............................................................286
19.1.1 Changing Modification Rules.........................................................289
19.2 Defining Custom Modification Types ...................................................290
19.2.1 Creating a Custom Modification Type.............................................291
19.2.2 Modifying a Custom Modification Type ...........................................293
19.2.3 Deleting a Custom Modification Type.............................................293
19.3 Defining Modifications Impacting Pricing .............................................294
19.3.1 Adding/Removing a Modification Type for
Modifications Impacting Pricing ....................................................294
19.4 Defining Modifications Requiring Auditing............................................294

xxviii Configuration Guide

20 Configuring an Order Document’s Fulfillment-Specific
Components
20.1 Defining Hold Types......................................................................... 298
20.1.1 Creating a Hold Type .................................................................. 298
20.1.1.1 Creating an Order Level Hold Type........................................... 300
20.1.1.2 Creating an Order Line Level Hold Type .................................... 306
20.1.2 Modifying a Hold Type................................................................. 312
20.1.3 Deleting a Hold Type .................................................................. 313
20.2 Defining Order Tags......................................................................... 313
20.2.1 Modifying an Order Tag ............................................................... 318
20.2.2 Deleting an Order Tag................................................................. 318
20.3 Defining Fulfillment Rules ................................................................. 318
20.4 Defining Approval Plans for Quotes .................................................... 321
20.5 Defining Process Type Details ........................................................... 323
20.6 Process Type Pipeline Configuration ................................................... 323
20.6.1 Defining Pipeline Determination.................................................... 324
20.6.1.1 Condition Variables for Pipeline Determination........................... 325
20.6.2 Pipelines ................................................................................... 325
20.6.3 Transactions .............................................................................. 326
20.6.4 Statuses ................................................................................... 330
20.6.5 Conditions................................................................................. 333
20.6.6 Actions ..................................................................................... 335
20.7 Defining Transaction Rules ............................................................... 335
20.7.1 Defining Transaction Rules for Quotes ........................................... 340
20.8 Defining Status Inventory Types ....................................................... 342
20.8.1 Creating a Status Inventory Type ................................................. 344
20.8.2 Modifying a Status Inventory Type................................................ 346
20.8.3 Deleting a Status Inventory Type ................................................. 346
20.9 Defining Quote Rules ....................................................................... 346
20.10 Defining Monitoring Components ....................................................... 347
20.10.1 Defining Date Types ................................................................... 348
20.10.1.1 Creating a Date Type ............................................................. 348
20.10.1.2 Modifying a Date Type ........................................................... 349
20.10.1.3 Deleting a Date Type ............................................................. 349
20.10.2 Defining Milestones .................................................................... 350

xxix
 20.10.2.1 Creating a Milestone ..............................................................351
20.10.2.2 Modifying a Milestone.............................................................353
20.10.2.3 Deleting a Milestone ..............................................................353
20.11 Defining Monitoring Events ...............................................................354
20.11.1 Creating an Event Rule................................................................354
20.11.2 Modifying an Event .....................................................................357
20.11.3 Deleting an Event .......................................................................357
20.12 Defining Transaction Dependencies....................................................358
20.12.1 Defining a Default Dependency Group ...........................................359
20.12.2 Creating a Transaction Dependency Group.....................................360
20.12.2.1 Creating a Transaction Dependency Rule ..................................362
20.12.2.2 Modifying a Transaction Dependency Rule.................................365
20.12.2.3 Deleting a Transaction Dependency Rule ..................................365
20.12.3 Modifying a Transaction Dependency Group ...................................366
20.12.4 Deleting a Transaction Dependency Group .....................................366

21 Configuring an Opportunity Document’s Fulfillment-Specific

Components
21.1 Defining Process Type Details ...........................................................367
21.2 Configuring Process Type Pipelines ....................................................367
21.2.1 Pipelines ...................................................................................368
21.2.2 Transactions ..............................................................................370
21.2.3 Statuses ...................................................................................372
21.2.4 Conditions .................................................................................374
21.2.5 Actions .....................................................................................375
21.3 Configuring Purge Criteria ................................................................375

22 Configuring an Order Document’s Shipment-Specific

Components
22.1 Defining Hold Types.........................................................................378
22.2 Defining Process Type Details ...........................................................378
22.3 Process Type Pipeline Configuration ...................................................378
22.3.1 Defining Pipeline Determination....................................................379
22.3.2 Pipelines ...................................................................................380

xxx Configuration Guide

 22.3.3 Transactions .............................................................................. 382
22.3.4 Statuses ................................................................................... 385
22.3.5 Conditions................................................................................. 388
22.3.6 Actions ..................................................................................... 389
22.4 Defining Monitoring Components ....................................................... 390
22.4.1 Defining Date Types ................................................................... 390
22.4.1.1 Creating a Date Type ............................................................. 391
22.4.1.2 Modifying a Date Type ........................................................... 392
22.4.1.3 Deleting a Date Type ............................................................. 392
22.4.2 Defining Milestones .................................................................... 392
22.4.2.1 Creating a Milestone .............................................................. 393
22.4.2.2 Modifying a Milestone ............................................................ 395
22.4.2.3 Deleting a Milestone .............................................................. 395
22.5 Defining Monitoring Events ............................................................... 396
22.5.1 Creating an Event Rule ............................................................... 396
22.5.2 Modifying an Event ..................................................................... 398
22.5.3 Deleting an Event....................................................................... 399
22.6 Defining Shipment Preferences.......................................................... 399
22.6.1 Over Shipping Preferences........................................................... 399
22.6.1.1 Creating a Shipment Preference .............................................. 400
22.6.1.2 Modifying a Shipment Preference............................................. 402
22.6.1.3 Deleting a Shipment Preference .............................................. 402
22.6.2 Transaction Rules ....................................................................... 402

23 Configuring a Document’s Financial Components

23.1 Defining Payment Terms .................................................................. 405
23.1.1 Creating a Payment Term ............................................................ 405
23.1.2 Modifying a Payment Term .......................................................... 406
23.1.3 Deleting a Payment Term ............................................................ 407
23.2 Defining Charge Definitions .............................................................. 407
23.2.1 Creating a Charge Category......................................................... 408
23.2.1.1 Adding a Charge Name Associated with a Charge Category ......... 409
23.2.1.2 Modifying a Charge Name Associated with a Charge Category ..... 410
23.2.1.3 Deleting a Charge Name Associated with a Charge Category ....... 411
23.2.2 Modifying a Charge Category ....................................................... 411

xxxi
 23.2.3 Deleting a Charge Category .........................................................411
23.3 Defining Tax Names.........................................................................412
23.3.1 Creating a Tax Name ..................................................................412
23.3.2 Modifying a Tax Name.................................................................413
23.3.3 Deleting a Tax Name ..................................................................414
23.4 Defining Additional Payment Rules.....................................................414
23.4.1 Defining Additional Payment Rules for Quotes ................................417
23.5 Defining Receiving Discrepancy Reasons ............................................418
23.5.1 Creating a Receiving Discrepancy Reason ......................................419
23.5.2 Modifying a Receiving Discrepancy Reason.....................................421
23.5.3 Deleting a Receiving Discrepancy Reason ......................................422

24 Configuring a Document’s Purge Criteria

24.1 Modifying an Order Document Type’s Purge Criteria Rule ......................425

25 Configuring Value-Added Services

25.1 Defining Value-Added Services Modification Reasons ............................430
25.1.1 Creating a Modification Reason.....................................................430
25.1.2 Modifying a Modification Reason ...................................................431
25.1.3 Creating a New Modification Reason Based on an Existing One .........431
25.1.4 Deleting a Modification Reason .....................................................432
25.2 Defining Value-Added Services Cancellation Reasons............................432
25.2.1 Creating a Cancellation Reason ....................................................432
25.2.2 Modifying a Cancellation Reason ...................................................433
25.2.3 Creating a New Cancellation Reason Based on an Existing One .........434
25.2.4 Deleting a Cancellation Reason.....................................................434
25.3 Defining Value-Added Services Appointment Failure Reasons.................435
25.3.1 Creating a Appointment Failure Reason .........................................435
25.3.2 Modifying an Appointment Failure Reason ......................................436
25.3.3 Creating a New Appointment Failure Reason
Based on an Existing One .............................................................436
25.3.4 Deleting an Appointment Failure Reason........................................437
25.4 Defining Value-Added Services Note Reasons ......................................437
25.4.1 Creating a Note Reason...............................................................437

xxxii Configuration Guide

25.4.2 Modifying a Note Reason ............................................................. 438
25.4.3 Creating a New Note Reason Based on an Existing One ................... 439
25.4.4 Deleting a Note Reason ............................................................... 439
25.5 Defining Value-Added Services Instruction Types................................. 439
25.5.1 Creating an Instruction Type........................................................ 440
25.5.2 Modifying an Instruction Type ...................................................... 440
25.5.3 Deleting an Instruction Type ........................................................ 441
25.6 Defining Value-Added Services Rules ................................................. 441
25.6.1 Setting Up Value-Added Services Pre-Call Rules ............................. 441
25.6.2 Setting Up Value-Added Services Other Rules ................................ 442
25.7 Defining Value-Added Services Modification Rules ................................ 444
25.7.1 Setting Up Value-Added Services Modification Rules........................ 444
25.8 Defining Value-Added Services Hold Types ......................................... 446
25.8.1 Creating a Hold Type .................................................................. 447
25.8.2 Modifying a Hold Type................................................................. 452
25.8.3 Deleting a Hold Type .................................................................. 453
25.9 Defining Value-Added Services Process Types ..................................... 453
25.9.1 Viewing Value-Added Services Process Type Details ........................ 453
25.10 Defining Value-Added Services Process Model ..................................... 454
25.10.1 Pipeline Determination ................................................................ 454
25.10.1.1 Hub Rule .............................................................................. 454
25.10.1.2 Condition Variables for Pipeline Determination........................... 455
25.10.2 Pipelines ................................................................................... 455
25.10.3 Transactions .............................................................................. 456
25.10.4 Statuses ................................................................................... 458
25.10.5 Conditions................................................................................. 460
25.10.6 Actions ..................................................................................... 461
25.10.7 Service Definitions...................................................................... 463
25.11 Defining Value-Added Services Monitoring .......................................... 464
25.11.1 Viewing Value-Added Services Date Types ..................................... 464
25.11.2 Defining Value-Added Services Event Monitoring ............................ 466
25.11.2.1 Creating an Event Rule .......................................................... 466
25.11.2.2 Modifying an Event ................................................................ 468
25.11.2.3 Creating a New Event ............................................................ 468
25.11.2.4 Deleting an Event.................................................................. 469

xxxiii
 25.12 Viewing Value-Added Services Purge Criteria.......................................469

A Time-Triggered Transaction Reference

A.1 Running Time-Triggered Transactions ................................................473
A.1.1 Steps to Complete Before Scheduling Time-Triggered Transactions ...473
A.2 Configuring Communication Between an Agent and a JMS Server...........474
A.2.1 Prerequisites..............................................................................474
A.2.2 Create an Initial Context Factory Code ..........................................475
A.2.3 Define the Transaction Information ...............................................476
A.3 Business Process Time-Triggered Transactions ....................................477
A.3.1 Asynchronous Request Processor..................................................478
A.3.2 Case Insensitive Data Loader .......................................................480
A.3.3 Change Load Status....................................................................482
A.3.4 Change Shipment Status .............................................................484
A.3.5 Close Delivery Plan .....................................................................486
A.3.6 Close Load ................................................................................488
A.3.7 Close Manifest ...........................................................................490
A.3.8 Close Order ...............................................................................492
A.3.9 Close Receipts ...........................................................................495
A.3.10 Close Shipment ..........................................................................497
A.3.11 Collect Shipment Statistics ..........................................................500
A.3.12 Consolidate Additional Inventory ..................................................502
A.3.13 Consolidate To Shipment .............................................................504
A.3.14 Create Catalog Index ..................................................................508
A.3.15 Create Chained Order .................................................................513
A.3.16 Create Derived Order ..................................................................515
A.3.17 Create Order Invoice ..................................................................517
A.3.18 Create Shipment Invoice .............................................................519
A.3.19 ESP Evaluator ............................................................................521
A.3.20 Item Based Allocation .................................................................524
A.3.21 Mark Load as Trailer Loaded ........................................................530
A.3.22 Match Inventory.........................................................................532
A.3.23 Payment Collection .....................................................................534
A.3.24 Payment Execution .....................................................................537
A.3.25 Post Inventory Match ..................................................................540

xxxiv Configuration Guide

A.3.26 Process Order Hold Type ............................................................. 542
A.3.27 Process Work Order Hold Type ..................................................... 545
A.3.28 Publish Negotiation Results.......................................................... 547
A.3.29 Release..................................................................................... 549
A.3.30 Route Shipment ......................................................................... 552
A.3.31 Schedule................................................................................... 555
A.3.32 Send Invoice ............................................................................. 559
A.3.33 Send Item Changes .................................................................... 562
A.3.34 Send Customer Changes ............................................................. 564
A.3.35 Send Order ............................................................................... 566
A.3.36 Send Release............................................................................. 568
A.3.37 Start Order Negotiation ............................................................... 570
A.3.38 Synchronize Colony Map ............................................................. 571
A.3.39 Update Best Match Region ........................................................... 573
A.3.40 PopulateOwnershipTransferSummary ............................................ 576
A.4 Time-Triggered Purge Transactions.................................................... 577
A.4.1 Purge Strategy........................................................................... 578
A.4.2 Configuring Purge Transaction Log Files......................................... 578
A.4.3 Available Purges......................................................................... 579
A.4.3.1 Access Token Purge ............................................................... 580
A.4.3.2 Capacity Purge...................................................................... 583
A.4.3.3 Draft Order History Purge ....................................................... 586
A.4.3.4 Draft Order Purge.................................................................. 589
A.4.3.5 Delivery Plan Purge ............................................................... 594
A.4.3.6 Export Table Purge ................................................................ 597
A.4.3.7 Import Table Purge................................................................ 599
A.4.3.8 Inventory Audit Purge ............................................................ 602
A.4.3.9 Inventory Purge .................................................................... 605
A.4.3.10 Inventory Supply Temp Purge ................................................. 608
A.4.3.11 Item Audit Purge................................................................... 610
A.4.3.12 Load History Purge ................................................................ 612
A.4.3.13 Load Purge ........................................................................... 615
A.4.3.14 Negotiation History Purge ....................................................... 618
A.4.3.15 Negotiation Purge.................................................................. 620
A.4.3.16 Opportunity History Purge ...................................................... 623

xxxv
 A.4.3.17 Opportunity Purge .................................................................625
A.4.3.18 Order History Purge ...............................................................628
A.4.3.19 Order Purge..........................................................................631
A.4.3.20 Order Release Status Purge ....................................................639
A.4.3.21 Order Status Audit Purge........................................................641
A.4.3.22 Organization Audit Purge ........................................................643
A.4.3.23 Person Info Purge..................................................................645
A.4.3.24 Person Info History Purge .......................................................648
A.4.3.25 Picklist Purge ........................................................................651
A.4.3.26 Price List Purge .....................................................................653
A.4.3.27 Purge Catalog Mass Audits......................................................655
A.4.3.28 Receipt History Purge.............................................................657
A.4.3.29 Receipt Purge .......................................................................660
A.4.3.30 Reprocess Error Purge............................................................663
A.4.3.31 Reservation Purge .................................................................665
A.4.3.32 Shipment History Purge..........................................................667
A.4.3.33 Shipment Purge ....................................................................670
A.4.3.34 Shipment Statistics Purge .......................................................674
A.4.3.35 User Activity Purge ................................................................676
A.4.3.36 User Activity Audit Purge ........................................................678
A.4.3.37 Work Order History Purge.......................................................681
A.4.3.38 Work Order Purge..................................................................684
A.4.3.39 YFS Audit Purge ....................................................................687
A.4.3.40 YFSInventoryOwnershipAudit Purge .........................................690
A.4.3.41 Password Reset Request Purge ................................................691
A.4.3.42 User Login Failure Purge.........................................................693
A.5 Task Queue Syncher Time-Triggered Transactions ...............................695
A.5.1 Load Execution Task Queue Syncher .............................................696
A.5.2 Order Delivery Task Queue Syncher ..............................................698
A.5.3 Order Fulfillment Task Queue Syncher...........................................699
A.5.4 Order Negotiation Task Queue Syncher .........................................701
A.5.5 Quote Fulfillment Task Queue Syncher ..........................................702
A.6 Monitors ........................................................................................703
A.6.1 Availability Monitor .....................................................................704
A.6.2 Exception Monitor.......................................................................706

xxxvi Configuration Guide

 A.6.3 Inventory Monitor ...................................................................... 708
A.6.4 Negotiation Monitor .................................................................... 710
A.6.5 Enhanced Order Monitor.............................................................. 712
A.6.6 Enhanced Quote Monitor ............................................................. 716
A.6.7 Enhanced Return Monitor ............................................................ 719
A.6.8 Real-time Availability Monitor....................................................... 723
A.6.9 Shipment Monitor....................................................................... 729
A.6.10 Work Order Monitor .................................................................... 732

B Order Modification Types

C Condition Builder Attributes

C.1 Sales Order .................................................................................... 753
C.1.1 Order Fulfillment ........................................................................ 753
C.1.2 Order Negotiation....................................................................... 756
C.1.3 Outbound Shipment.................................................................... 757
C.1.4 Sales Order Receipt .................................................................... 759
C.2 Planned Order ................................................................................ 759
C.2.1 Planned Order Execution ............................................................. 759
C.2.2 Planned Order Negotiation........................................................... 759
C.3 Return Order .................................................................................. 760
C.3.1 Reverse Logistics ....................................................................... 760
C.3.2 Return Shipment ........................................................................ 762
C.3.3 Return Receipt ........................................................................... 762
C.4 Template Order............................................................................... 763
C.5 Purchase Order ............................................................................... 764
C.5.1 Purchase Order Execution............................................................ 764
C.5.2 Purchase Order Negotiation ......................................................... 766
C.5.3 Inbound Shipment...................................................................... 767
C.5.4 Purchase Order Receipt ............................................................... 767
C.6 Transfer Order ................................................................................ 768
C.6.1 Transfer Order Execution............................................................. 768
C.6.2 Transfer Order Delivery............................................................... 768
C.6.3 Transfer Order Receipt ................................................................ 768
C.7 Master Order .................................................................................. 768

xxxvii
 C.7.1 Master Order Fulfillment ..............................................................768
C.8 Quote ............................................................................................771
C.8.1 Quote Fulfillment........................................................................771
C.9 Load Execution ...............................................................................771
C.10 General..........................................................................................772
C.11 WMS Putaway .................................................................................774
C.12 WMS Layout Definition .....................................................................774
C.13 WMS Inventory ...............................................................................774
C.14 Trailer Loading................................................................................774
C.15 Task Execution................................................................................774
C.16 Move Request Execution...................................................................774
C.17 Manifesting.....................................................................................774
C.18 Over Pack Build...............................................................................774
C.19 Count Execution ..............................................................................775
C.20 Pack Process...................................................................................776
C.21 Outbound Picking ............................................................................779
C.22 VAS Process ...................................................................................780
C.23 Opportunity ....................................................................................782
C.23.1 Opportunity Fulfillment................................................................782
C.24 Item-Based Allocation (IBA) Order.....................................................783

Index

xxxviii Configuration Guide

 Preface

This manual describes how to use the Distributed Order Management

business application module in the Applications Manager.

Intended Audience
This manual is intended for use by system administrators and managers
who need to configure the Selling and Fulfillment Foundation rules and
business processes as they pertain to their distributed order
management business practices.

Structure
This manual contains the following sections:

Chapter 1, "Introduction"
This chapter briefly describes the contents of this guide.

Chapter 2, "Navigating the Applications Manager"

This chapter explains the layout of the Applications Manager, the actions
you can perform throughout the solution, and the important concepts
you should be aware of before using the solution.

Chapter 3, "Configuring Cross-Application Order Promising

Components"
This chapter explains how you can define the rules and components
necessary to determine the appropriate node and suppliers used to
source items.

xxxix
 Chapter 4, "Configuring Cross-Application Service Execution
Components"
This chapter explains how you can define the components utilized during
service execution.

Chapter 5, "Configuring Cross-Application Logistics Components"

This chapter explains the configuration of components used by different
logistics related functionality throughout the business application module.

Chapter 6, "Configuring Cross-Application Payment Components"

This chapter explains the configuration of components used in Selling and
Fulfillment Foundation to define the types of payment the system accepts
and the rules surrounding payment collection.

Chapter 7, "Configuring Cross-Application Pricing Components"

This chapter explains how you can configure the components used for
pricing by the Selling and Fulfillment Foundation financial engine
throughout the Distributed Order Management business application
module.

Chapter 8, "Configuring Cross-Application Customer Components"

This chapter explains how you can configure customer classifications and
customer definitions.

Chapter 9, "Configuring a Document’s Attributes"

This chapter explains how you can configure common codes as they
pertain to order documents viewed in the Application Consoles.

Chapter 10, "Configuring a Document’s Order Validation"

This chapter explains how you can define configuration for defaulting
Seller and Buyer validation during order creation for a particular
Enterprise and document type.

Chapter 11, "Configuring a Document’s Instruction Types"

This chapter explains how you can define the common codes used when
adding special instructions to an order document.

xl Configuration Guide
Chapter 12, "Configuring a Document’s Modification Reasons"
This chapter explains how you can define common codes for modification
reasons.

Chapter 13, "Configuring a Document’s Backorder Reasons"

This chapter explains how you can define common codes for backorder
reasons.
Chapter 14, "Configuring a Document’s Note Reasons"
This chapter explains how you can configure common codes for note
reasons used when modifying an order.
Chapter 15, "Configuring a Quote Document’s Approval Rule
Violation Reason"
This chapter explains how you can define common codes for reasons why
an approval rule is violated when approving a quote.
Chapter 16, "Configuring a Document’s Line Relationship Type"
This chapter explains how you can configure line relationship types used
for linking similar items.

Chapter 17, "Configuring an Opportunity Document’s Lead Origin"

This chapter explains how you can define common codes for the lead
origin of opportunities.

Chapter 18, "Configuring an Opportunity Document’s Lost

Reason"
This chapter explains how you can define common codes for lost reasons
when an opportunity is lost.

Chapter 19, "Configuring a Document’s Modification Components"

This chapter explains how you can configure the modification rules and
types of a document when it is in a specific status.

Chapter 20, "Configuring an Order Document’s

Fulfillment-Specific Components"
This chapter explains how you can configure the fulfillment specific
process types used by each order document.

xli
 Chapter 21, "Configuring an Opportunity Document’s
Fulfillment-Specific Components"
This chapter explains how you can configure the fulfillment specific
process type used by an Opportunity document.

Chapter 22, "Configuring an Order Document’s Shipment-Specific

Components"
This chapter explains how you can configure the shipment specific
process types used by each order document.

Chapter 23, "Configuring a Document’s Financial Components"

This chapter explains how you can define rules and common codes as
they pertain to payments and charges given for a given order document.

Chapter 24, "Configuring a Document’s Purge Criteria"

This chapter explains the purge criteria business rules that are used to
define qualifications around each type of purge. Purges are the process
by which old data is removed from the system database.

Chapter 25, "Configuring Value-Added Services"

This chapter explains how you can configure value-added services in
Selling and Fulfillment Foundation.

Appendix A, "Time-Triggered Transaction Reference"

This chapter explains time-triggered transactions that are utilities that
perform a variety of individual functions, automatically and at specific
time intervals.

Appendix B, "Order Modification Types"

This chapter explains the default order modification types and their
associated modification levels.

Appendix C, "Condition Builder Attributes"

This chapter explains the attributes used in the condition builder to build
statements for each process type.

xlii Configuration Guide

Selling and Fulfillment Foundation
Documentation
For more information about Selling and Fulfillment Foundation
components, see the following manuals:
Q
Selling and Fulfillment Foundation: Release Notes
Q
Selling and Fulfillment Foundation: Installation Guide
Q
Selling and Fulfillment Foundation: Upgrade Guide
Q
Selling and Fulfillment Foundation: Configuration Deployment Tool
Guide
Q
Selling and Fulfillment Foundation: Performance Management Guide
Q
Selling and Fulfillment Foundation: High Availability Guide
Q
Selling and Fulfillment Foundation: System Management Guide
Q
Selling and Fulfillment Foundation: Localization Guide
Q
Selling and Fulfillment Foundation: Customization Basics Guide
Q
Selling and Fulfillment Foundation: Customizing APIs Guide
Q
Selling and Fulfillment Foundation: Customizing Console JSP Interface
for End User Guide
Q
Selling and Fulfillment Foundation: Customizing the RCP Interface
Guide
Q
Selling and Fulfillment Foundation: Customizing User Interfaces for
Mobile Devices Guide
Q
Selling and Fulfillment Foundation: Customizing Web UI Framework
Guide
Q
Selling and Fulfillment Foundation: Customizing Swing Interface
Guide
Q
Selling and Fulfillment Foundation: Extending the Condition Builder
Guide
Q
Selling and Fulfillment Foundation: Extending the Database Guide
Q
Selling and Fulfillment Foundation: Extending Transactions Guide
Q
Selling and Fulfillment Foundation: Using Sterling RCP Extensibility
Tool Guide

xliii
 Q
Selling and Fulfillment Foundation: Integration Guide
Q
Selling and Fulfillment Foundation: Product Concepts Guide
Q
Sterling Warehouse ManagementTM System: Concepts Guide
Q
Selling and Fulfillment Foundation: Application Platform Configuration
Guide
Q
Sterling Distributed Order ManagementTM: Configuration Guide
Q
Sterling Supply Collaboration: Configuration Guide
Q
Sterling Global Inventory VisibilityTM: Configuration Guide
Q
Catalog ManagementTM: Configuration Guide
Q
Sterling Logistics Management: Configuration Guide
Q
Sterling Reverse LogisticsTM: Configuration Guide
Q
Sterling Warehouse Management System: Configuration Guide
Q
Selling and Fulfillment Foundation: Application Platform User Guide
Q
Sterling Distributed Order Management: User Guide
Q
Sterling Supply Collaboration: User Guide
Q
Sterling Global Inventory Visibility: User Guide
Q
Sterling Logistics Management: User Guide
Q
Sterling Reverse Logistics: User Guide
Q
Sterling Warehouse Management System: User Guide
Q
Selling and Fulfillment Foundation: Mobile Application User Guide
Q
Selling and Fulfillment Foundation: Business Intelligence Guide
Q
Selling and Fulfillment Foundation: Javadocs
Q
Sterling Selling and Fulfillment SuiteTM: Glossary
Q
Parcel Carrier: Adapter Guide
Q
Visual ModelerTM: Application Guide
Q
Selling and Fulfillment Foundation: Multitenant Enterprise Guide
Q
Selling and Fulfillment Foundation: Password Policy Management
Guide

xliv Configuration Guide

 Q
Selling and Fulfillment Foundation: Properties Guide
Q
Catalog Management: Concepts Guide
Q
Selling and Fulfillment Foundation: Pricing Concepts Guide
Q
Selling and Fulfillment Foundation: Setting Up Quotes
Q
Sterling Sensitive Data Capture Server, Release 1.0: Configuration
Guide
Q
Sterling Sensitive Data Capture Server, Release 1.0: PA-DSS
Implementation Guide
Q
Selling and Fulfillment Foundation: Secure Deployment Guide
Q
Business Center: Item Administration Guide
Q
Business Center: Pricing Administration Guide
Q
Business Center: Customization Guide
Q
Business Center: Localization Guide

Conventions
The following conventions may be used in this manual:

Convention Meaning
... Ellipsis represents information that has been
omitted.
<> Angle brackets indicate user-supplied input.

mono-spaced text Mono-spaced text indicates a file name, directory

path, attribute name, or an inline code example or
command.
/ or \ Slashes and backslashes are file separators for
Windows, UNIX, and Linux operating systems. The
file separator for the Windows operating system is
"\" and the file separator for UNIX and Linux
systems is "/". The UNIX convention is used unless
otherwise mentioned.
<INSTALL_DIR> User-supplied location of the Selling and Fulfillment
Foundation installation directory. This is only
applicable for Release 8.0 and later.

xlv
 Convention Meaning
<INSTALL_DIR_OLD> User-supplied location of the Selling and Fulfillment
Foundation installation directory (for Release 8.0
and later).
Note: This is applicable only for users upgrading
from Release 8.0 and later.
<SSDCS_DIR> User-supplied location of the Sterling Sensitive Data
Capture Server installation directory.
This is applicable for Selling and Fulfillment
Foundation, Release 9.0 and later.
<YANTRA_HOME> User-supplied location of the Sterling Supply Chain
Applications installation directory. This is only
applicable for Releases 7.7, 7.9, and 7.11.
<YANTRA_HOME_OLD> User-supplied location of the Sterling Supply Chain
Applications installation directory (for Releases 7.7,
7.9, or 7.11).
Note: This is applicable only for users upgrading
from Releases 7.7, 7.9, or 7.11.
<YFS_HOME> For Releases 7.3, 7.5, and 7.5 SP1, this is the
user-supplied location of the Sterling Supply Chain
Applications installation directory.
For Releases 7.7, 7.9, and 7.11, this is the
user-supplied location of the <YANTRA_
HOME>/Runtime directory.
For Release 8.0 and later, the <YANTRA_
HOME>/Runtime directory is no longer used and has
been substituted with the location <INSTALL_DIR>.
<YFS_HOME_OLD> This is the <YANTRA_HOME>/Runtime directory for
Releases 7.7, 7.9, or 7.11.
Note: This is only applicable for users upgrading
from Releases 7.7, 7.9, or 7.11.
<ANALYTICS_HOME> User-supplied location of the Sterling Analytics
installation directory.
Note: This convention is used only in the
Selling and Fulfillment Foundation: Business
Intelligence Guide.

xlvi Configuration Guide

 Convention Meaning
<COGNOS_HOME> User-supplied location of the IBM Cognos 8
Business Intelligence installation directory.
Note: This convention is used only in the
Selling and Fulfillment Foundation: Business
Intelligence Guide.
<MQ_JAVA_INSTALL_ User-supplied location of the IBM WebSphere®
PATH> MQ Java components installation directory.
Note: This convention is used only in the
Selling and Fulfillment Foundation: System
Management and Administration Guide.
<DB> Refers to Oracle®, IBM DB2®, or Microsoft SQL
Server® depending on the database server.
<DB_TYPE> Depending on the database used, considers the
value oracle, db2, or sqlserver.

Note: The Selling and Fulfillment Foundation documentation set uses the
following conventions in the context of the product name:
Q
Yantra is used for Release 7.7 and earlier.
Q
Sterling Supply Chain Applications is used for Releases 7.9 and 7.11.
Q
Sterling Multi-Channel Fulfillment Solution is used for Releases 8.0
and 8.2.
Q
Selling and Fulfillment Foundation is used for Releases 8.5 and 9.0.

xlvii
xlviii Configuration Guide
 1
Introduction

This book concentrates on the rules and setup configurations that make
up the 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 Selling and
Fulfillment Foundation environment. Business analysts should also use
this book to plan appropriate business practices as they pertain to Selling
and Fulfillment Foundation. Programmers and System Integrators should
refer to the Selling and Fulfillment Foundation: Extending Transactions
Guideand the Selling and Fulfillment Foundation: Integration Guide for
information about extending or integrating external applications with
Selling and Fulfillment Foundation.

Important: This book assumes that you have read and

are familiar with the concepts and business functionality
detailed in the Selling and Fulfillment Foundation: Product
Concepts Guide.

The Applications Manager is a collection of all the rules and setup

configurations necessary to implement 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:
Q
Distributed Order Management
Q
Global Inventory Visibility
Q
Catalog Management
Q
Logistics Management

Introduction 1
Business Models

Q
Supply Collaboration
Q
Reverse Logistics
Q
Warehouse Management
Q
Application Platform

1.1 Business Models

There is no single business model that encompasses the environment in
which the entire Selling and Fulfillment Foundation can be used.
Therefore, there is no single way to configure your Selling and Fulfillment
Foundation 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 Selling and Fulfillment Foundation configuration.

1.1.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 Selling and Fulfillment Foundation. This setup allows
both segregation of transactions by division and global visibility at the
corporate level. Each Enterprise configures their own business rules,
workflow, and transaction processing.

1.1.2 Third-Party Logistics

Traditional third-party logistics companies provide a range of out
sourced 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

2 Configuration Guide
 Sterling Distributed Order Management Configuration

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.
Selling and Fulfillment Foundation provides the engine needed to run the
operations of a contract fulfillment provider as well as a centralized
system for real-time order execution and event driven problem solving
for an entire fulfillment network. It enables fulfillment providers to
configure the fulfillment process to meet the needs of their clients.
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.

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

1.2 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

Introduction 3
Sterling Distributed Order Management Configuration

automatically creates and tracks any processes that result from, or

depend upon, the original customer order.
In the Applications Manager, you can use Sterling Distributed Order
Management configuration grouping to establish both cross-application
and order document specific rules and attributes. Cross-application rules
and attributes can impact other applications, such as Supply
Collaboration or Reverse Logistics. Order document specific rules and
attributes pertain only to the order document type you are 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 the following aspects of Selling and Fulfillment Foundation for
your business application modules:
Q
Sourcing Setup
Q
Logistics
Q
Financials
Q
Customer
Q
Order Attributes
Q
Order Validation
Q
Instruction Types
Q
Modification Reasons
Q
Backorder Reasons
Q
Process Type Configuration
Q
Purge Criteria

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

4 Configuration Guide
 Sterling Distributed Order Management Configuration

For more information about Sourcing Setup, see Chapter 3, "Configuring

Cross-Application Order Promising Components".

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

1.2.3 Financials
You can configure the components used by the Selling and Fulfillment
Foundation financial engine throughout the Distributed Order
Management business application module.
For more information about Financials, see Chapter 7, "Configuring
Cross-Application Pricing Components" and Chapter 23, "Configuring a
Document’s Financial Components".

1.2.4 Customer
You can define the customers that buy from an organization in the
Distributed Order Management module.
For more information about Customer, see Chapter 8, "Configuring
Cross-Application Customer Components".

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

Introduction 5
Sterling Distributed Order Management Configuration

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

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

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

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

1.2.10 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 Selling and Fulfillment Foundation.
The following process types are defined in Selling and Fulfillment
Foundation for the order document types:
Q
Fulfillment
Q
Negotiation

6 Configuration Guide
 Sterling Distributed Order Management Configuration

Q
Shipment
Q
Receipt
You can configure the rules and components that define an order
document’s process types.
For more about Process Type Configuration, see Chapter 20, "Configuring
an Order Document’s Fulfillment-Specific Components" and Chapter 22,
"Configuring an Order Document’s Shipment-Specific Components".

1.2.11 Purge Criteria

You can define the parameters used when purging order document
related records from the system.
For more information about Purge Criteria, see Chapter 24, "Configuring
a Document’s Purge Criteria".

Introduction 7
Sterling Distributed Order Management Configuration

8 Configuration Guide
 2
Navigating the Applications Manager

This chapter discusses the layout of the Applications Manager, actions

you can perform throughout the application, and important concepts you
should be aware of before using the application.

2.1 Starting the Applications Manager

To access the Applications Manager:
1. Point your browser to
http://<hostname>:<portname>/smcfs/console/start.jsp
where,
Q
hostname is the computer name or IP address of the computer
where Selling and Fulfillment Foundation is installed.
Q
portnumber is the listening port of the computer where Selling
and Fulfillment Foundation is installed.
The browser displays the Sign In window.
2. Enter your login ID and password and choose the Sign In button. The
Console Home Page is displayed.
3. From the menu bar, choose Configuration > Launch Configurator. The
Applications Manager opens in a new window.

Navigating the Applications Manager 9

The Applications Manager Layout

Note: Additionally, enterprise users who maintain an

enterprise can access the Applications Manager by means
of http://<Selling and Fulfillment Foundation
installation server>/smcfs/console/login.jsp.

Note: If both the Applications Manager and the monitor in

the System Management Console are opened at the same
time, and if a dialogue window is opened in either
application, the other stops responding to user input until
that dialogue window is closed. This is due to a bug in the
Java platform.

2.2 The Applications Manager Layout

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

Figure 2–1 Applications Menu

Each application focuses on a particular aspect of Selling and Fulfillment

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

10 Configuration Guide
 The Applications Manager Layout

The following applications can be configured in this version of Selling and

Fulfillment Foundation:
Q
Distributed Order Management
Q
Global Inventory Visibility
Q
Catalog Management
Q
Logistics Management
Q
Supply Collaboration
Q
Reverse Logistics
Q
Warehouse Management
Q
Application Platform
When you select the application that you want to configure, the
Configurator 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.

Navigating the Applications Manager 11

The Applications Manager Layout

Figure 2–2 The Standard Configurator Application Interface

2.2.1 Application Rules Side Panel

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

12 Configuration Guide
 The Applications Manager Layout

Figure 2–3 Example of Application Rules Side Panel

The application rules side panel also identifies the organization you are
configuring rules for and what, if any, rules are inherited from another
organization.
You can use the application rules side panel for:
Q
Accessing Configuration Screens
Q
Determining Inheritance
Q
Loading Another Organization’s Rules

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

Navigating the Applications Manager 13

The Applications Manager Layout

2.2.1.2 Determining Inheritance

In Selling and Fulfillment Foundation, when an Enterprise is created it
can inherit all or part of an existing Enterprise’s configuration rules. This
inheritance is done at the configuration group level. A configuration
group is a classification of similar configuration elements. For example,
all of the rules and configurations dealing with items are grouped
together into one configuration group and all of the rules and
configurations dealing with organizations are grouped into another.
An administrator organization is set for every organization defined within
the system. Only the administrator organization can modify the rules
defined for a particular organization. If a particular organization
administers multiple organizations, then they can load the rules of
organization that it administers within the application tree. For more
information about loading another organization’s rules, see
Section 2.2.1.3, "Loading Another Organization’s Rules".
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 Selling and Fulfillment Foundation are:
Q
Hub Level - Configuration groups that are associated with the Hub
organization
Q
Enterprise Level - Configuration groups that are associated with the
individual Enterprise organizations within the Hub environment
Q
Catalog Organization - Configuration groups that are associated with
the organization(s) that maintains the catalog(s) within the Hub
environment
Q
Inventory Organization - Configuration groups that are associated
with the organization(s) that maintains the inventory within the Hub
environment
Q
Pricing Organization - Configuration groups that are associated with
the organization(s) that maintains the pricing within the Hub
environment
Q
Organization - Configuration groups that are associated with any
organization within the Hub environment

14 Configuration Guide
 The Applications Manager Layout

Note: The Configurator does not load configuration data

and permissions based on Data Access Policies that are
described in the 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:
Q
Pipelines
Q
User Exits
Q
Services
Q
Actions
Q
Conditions
Q
Statuses
Q
Transactions
Q
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.

Navigating the Applications Manager 15

The Applications Manager Layout

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

16 Configuration Guide
 The Applications Manager Layout

Table 2–1 Organization Level Rules

Organization Organizations That Can
Level Modify at this Level... Inheritance Details
Hub Level Only the Hub organization All organizations share this
can modify configuration information.
groups at the Hub level. All
other organizations have
read-only access.
Enterprise Only Enterprise organizations An Enterprise can inherit this
Level can modify configuration configuration from another
groups at the Enterprise Enterprise. Additionally, this
level. configuration can be overridden
at a configuration group level.
Any business transaction
requiring Enterprise
configuration is picked up
from the Enterprise
established by the
transactional context. For
example, order documents
have a specific Enterprise.
Catalog Organizations that are None.
Organization designated as catalog
organizations can modify
configuration groups at the
catalog organization level.
Inventory Organizations that are None.
Organization designated as inventory
organizations can modify
configuration groups at the
inventory organization level.
Pricing Organizations that are None.
Organizations designated as pricing
organizations can modify
configuration groups at the
pricing organization level.
Organization Any organization assigned a None.
role (Seller, Buyer, etc.) can
modify configuration groups
at the organization level.

Navigating the Applications Manager 17

The Applications Manager Layout

Important: You cannot inherit from an Enterprise that

does not have the same inventory, capacity, and catalog
organizations as the organization you are configuring.

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

Figure 2–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.

18 Configuration Guide
 The Applications Manager Layout

Figure 2–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.

Navigating the Applications Manager 19

The Applications Manager Layout

Figure 2–6 Example of Configuration Override Details Pop-Up Window

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.

20 Configuration Guide
 The Applications Manager Layout

Figure 2–7 Give Back Configuration Ownership Icon

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.

Important: 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, however 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.

2.2.1.3 Loading Another Organization’s Rules

An administrator organization is set for every organization defined within
the system. Only the administrator organization can modify the rules
defined for a particular organization. If a particular organization
administers multiple organizations, then they can load the rules of
organization that it administers within the application tree. See Table 2–1
for the rules that determine which organizations you can administer.

Navigating the Applications Manager 21

The Applications Manager Layout

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

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.

Note: The application rules side panel displays the

organization you are working with in parentheses.

22 Configuration Guide
 The Applications Manager Layout

2.2.2 Work Area

The work area is the main area in which different configurationscreens
appear. The following are the main types of screens that you can be seen
in the work area:
Q
Search Window
Q
List Window
Q
Details Window
Q
Drag and Drop Window

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

Navigating the Applications Manager 23

The Applications Manager Layout

Figure 2–8 Search Window Example

2.2.2.2 List Window

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

24 Configuration Guide
 The Applications Manager Layout

Figure 2–9 List Window Example

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

Navigating the Applications Manager 25

The Applications Manager Layout

Figure 2–10 Details Window Example

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

26 Configuration Guide
 The Applications Manager Layout

Figure 2–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.

Navigating the Applications Manager 27

Actions Available in the Applications Manager

2.3 Actions Available in the Applications Manager

The following actions can be performed throughout the Applications
Manager:
Q
Using the Configurator’s Lookup Functionality
Q
Viewing the User Logged into the Configurator
Q
Using Lists and List Filtering
Q
Using Online Help
Q
Troubleshooting Errors
Q
Using Special Characters

2.3.1 Using the Configurator’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 2–12 Lookup Icon Example

Lookup
Icon
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

28 Configuration Guide
 Actions Available in the Applications Manager

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 Configurator, you
should refer to the corresponding section in this guide to set up the
particular information.

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

Navigating the Applications Manager 29

Actions Available in the Applications Manager

Figure 2–13 Associated Document Types Window

2.3.2.1 Adding a Document Type to an Application

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

30 Configuration Guide
 Actions Available in the Applications Manager

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

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

2.3.3 Viewing the User Logged into the Configurator

You can view the user logged into the Configurator 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.

2.3.4 Using Lists and List Filtering

When viewing any list in the Configurator, it is possible to filter the
contents of the list based in criteria that you define. Filtering is

Navigating the Applications Manager 31

Actions Available in the Applications Manager

accomplished by right-clicking anywhere on the list’s column headings

and using the Table Filter Editor associated with the list.

Figure 2–14 Column Headings in a List

32 Configuration Guide
 Actions Available in the Applications Manager

Figure 2–15 Table Filter Editor Window Example

Table 2–2 Table Filter Editor Window

Field Description
Apply To Existing Checking this box applies a new filter set of results
Records 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 2–15 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.

Important: Search strings are case sensitive. For

example, "Item" does not return the same values as
"item".

Navigating the Applications Manager 33

Actions Available in the Applications Manager

2.3.5 Date and Time Entry

Date fields through the Configurator 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 2–16 Calendar Icon example

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

Figure 2–17 Time Field example

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

the Configurator.

2.3.6 Using Online Help

You can access the Selling and Fulfillment Foundation Online Help
through Help > Online Help.

2.3.7 Troubleshooting Errors

You can view the description and cause of any error raised in Selling and
Fulfillment Foundation, as well as the actions to troubleshoot it.
To view the Selling and Fulfillment Foundation system error descriptions:
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.

34 Configuration Guide
 Actions Available in the Applications Manager

3. Choose to view the cause of the error and action to troubleshoot

it.

2.3.8 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 Selling and Fulfillment Foundation, see the
Selling and Fulfillment Foundation: Customization Basics Guide.

Navigating the Applications Manager 35

Actions Available in the Applications Manager

36 Configuration Guide
 3
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.
The configurations detailed in this chapter can be used to determine
sourcing based on:
Q
Where the items are being shipped from
Q
Ship to log50
Q
cation
Q
Availability at different locations
Q
Total number of shipments required to complete the request
Q
Node priority
Q
Delivery region
You can use the Sourcing Setup branch for:
Q
Configuring the Fulfillment Network Model
Q
Defining Item Level Controls
Q
Defining Levels of Service
Q
Defining Node Level Controls

Configuring Cross-Application Order Promising Components 37

Configuring the Fulfillment Network Model

Q
Defining Sourcing and Scheduling Rules

3.1 Configuring 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.
For more information about navigating in the Fulfillment Network Model,
see Section 3.1.1, "Navigating in the Fulfillment Network Model".
You can use the Fulfillment Network Model branch for:
Q
Defining Distribution Groups
Q
Defining Node Types
Q
Defining Nodes
Q
Defining Relationship Types
Q
Defining Relationships

Note: Depending on the amount of data that needs to be

processed, the fulfillment network model may take up to a
few minutes to load.

3.1.1 Navigating in the Fulfillment Network Model

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

38 Configuration Guide
 Configuring 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.

Configuring Cross-Application Order Promising Components 39

Configuring the Fulfillment Network Model

Note: The map could become unusable if your fulfillment

network contains 4000 nodes and 3000 relationships.

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–1 for descriptions of each action icon available.

Table 3–1 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 Section 3.1.3, "Defining
Node Types".

40 Configuration Guide
 Configuring the Fulfillment Network Model

Table 3–1 Action Icons

Action Icon Description

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
Section 3.1.5, "Defining Relationship Types".
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
Section 3.1.2.1, "Creating a Distribution Group".
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 Section 3.1.2, "Defining Distribution
Groups".
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 Section 3.1.4, "Defining Nodes".
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 Section 3.1.4.2, "Modifying a Node".
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 Section 3.1.6,
"Defining Relationships".
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 Section 3.1.6,
"Defining Relationships".

Configuring Cross-Application Order Promising Components 41

Configuring the Fulfillment Network Model

Table 3–1 Action Icons

Action Icon Description

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 Section 3.1.6.2,
"Modifying a Relationship".
Remove Relationships - With one or more relationships
selected, clicking this action deletes the selected
relationship(s). For more information about deleting
relationships, see Section 3.1.6.3, "Deleting a
Relationship".

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.

3.1.1.1 Using Filter Criteria

To use filter criteria:
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 3–2 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.

42 Configuration Guide
 Configuring the Fulfillment Network Model

Table 3–2 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
Section 3.1.3, "Defining Node Types".
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 Section 3.1.5, "Defining Relationship
Types".
Highlight Distribution Select a distribution group from the drop-down list to
Group be 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 Section 3.1.2, "Defining Distribution
Groups".

3.1.2 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.
Select one of the following tasks:
Q
Creating a Distribution Group
Q
Modifying a Distribution Group
Q
Deleting a Distribution Group

Configuring Cross-Application Order Promising Components 43

Configuring the Fulfillment Network Model

3.1.2.1 Creating a Distribution Group

To create a distribution group from the Fulfillment Network Model screen:
1. Using the Select tool, select the nodes on the map that you want to
include in the distribution group.
2. Select the Create Distribution Group action icon. The Create
Distribution Group screen displays.
3. Enter information into the applicable fields. Refer to Table 3–3 for
field value descriptions.
4. Click .

Table 3–3 Create Distribution Group Screen

Field Description
Distribution Group Enter the name of the distribution group.
Description Enter a description for the distribution group.
Node List
The node list displays the nodes that were selected in the Fulfillment Network
Model. These nodes are added to this distribution group.
Node The name of the node.
Description The description for the node.

44 Configuration Guide
 Configuring the Fulfillment Network Model

Note: You can also create distribution groups without

using the Fulfillment Network Model. For more information
about creating distribution groups by selecting nodes from
a list of nodes, see Section 3.5.8.1, "Creating a
Distribution Group".

3.1.2.2 Modifying a Distribution Group

To modify a distribution group from the Fulfillment Network Model
screen:
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 3–20 for
field value descriptions.
4. Click .

3.1.2.3 Deleting a Distribution Group

To delete a distribution group from the Fulfillment Network model screen:
1. Select the Distribution Group List action icon. The Product Sourcing
Distribution Group screen displays.
2. Select the applicable distribution group from the list and choose .

Configuring Cross-Application Order Promising Components 45

Configuring the Fulfillment Network Model

3.1.3 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 Global
Inventory Visibility: Configuration Guide.
Select one of the following tasks:
Q
Creating a Node Type
Q
Modifying a Node Type
Q
Deleting a Node Type

3.1.3.1 Creating a Node Type

To create a node type from the Fulfillment Network Model screen:
1. Select the View Node Types action icon. The Node Type List screen
displays.
2. Choose . The Node Type Detail screen displays.
3. Enter information into the applicable fields. Refer to Table 3–4 for
field value descriptions.
4. Click .

Table 3–4 Node Type Details

Field Description
Node Type Enter a name for the node type.
Description Enter a description for the node type.

46 Configuration Guide
 Configuring the Fulfillment Network Model

3.1.3.2 Modifying a Node Type

To modify a node type from the Fulfillment Network Model screen:
1. Select the View Node Types action icon. The Node Type List screen
displays.
2. Select the applicable node type from the list and choose . The Node
Type Detail screen displays.
3. Enter information into the applicable fields. Refer to Table 3–4 for
field value descriptions.
4. Click .

3.1.3.3 Deleting a Node Type

To delete a node type from the Fulfillment Network Model screen:
1. Select the View Node Types action icon. The Node Type List screen
displays.
2. Select the applicable node type from the list and choose .

3.1.4 Defining Nodes

You can use the Fulfillment Network Model to define node organizations.
For more information about participant modeling, see the Selling and
Fulfillment Foundation: Application Platform Configuration Guide.

Note: Nodes created through the Fulfillment Network

Model screen are automatically defined as child
organizations of the Enterprise that the fulfillment network
model belongs to.

Select one of the following tasks:

Q
Creating a Node
Q
Modifying a Node

3.1.4.1 Creating a Node

To create a node from the Fulfillment Network Model screen:
1. Select the Create Node action icon. The Create Node screen displays.

Configuring Cross-Application Order Promising Components 47

Configuring the Fulfillment Network Model

2. Enter information into the applicable fields. Refer to Table 3–5 for
field value descriptions.
3. Click .

Table 3–5 Create Node Screen

Field Description
Organization Code Enter a unique code that identifies the node.
Organization Name Enter the name of the node.

48 Configuration Guide
 Configuring the Fulfillment Network Model

Table 3–5 Create Node Screen

Field Description
DUNS Number Enter a unique nine-digit identification sequence,
which provides unique identifiers of single business
entities. Selling and Fulfillment Foundation does not
associate any logic with the DUNS number.
Account Number With If the node is not the Hub, enter the account number
Hub that the node has with the Hub.
Locale Select the node’s geographic location.
Parent Organization Select the node’s parent organization.
Primary Enterprise If the node is not an Enterprise, select the applicable
primary Enterprise. The primary enterprise is
defaulted on the entry point order console screens (for
example, on search screens and create screens).
On the organization details screen, when creating or
modifying a node organization, the actions that appear
on the primary info tab of the node attributes tab are
the actions created for that enterprise. Whenever any
enterprise level configuration is retrieved in the
back-end business logic for a specific organization, the
rules are always retrieved for the primary enterprise of
that organization. For more information, refer to the
Selling and Fulfillment Foundation: Application
Platform Configuration Guide.

Configuring Cross-Application Order Promising Components 49

Configuring the Fulfillment Network Model

Table 3–5 Create Node Screen

Field Description
Node Type Select the node type for this node.
Address and Contact The address and contact information for this node
Info 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, 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.

3.1.4.2 Modifying a Node

To modify a node’s details from the Fulfillment Network Model screen:
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 Selling
and Fulfillment Foundation: Application Platform Configuration Guide.
2. Enter information into the applicable fields.
3. Click .

50 Configuration Guide
 Configuring the Fulfillment Network Model

3.1.5 Defining Relationship Types

You can define relationship types to classify relationships.
Select one of the following tasks:
Q
Creating a Relationship Type
Q
Modifying a Relationship Type
Q
Deleting a Relationship Type

3.1.5.1 Creating a Relationship Type

To create a relationship type:
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 3–6 for
field value descriptions.
4. Click .

Table 3–6 Relationship Type Detail Screen

Field Description
Relationship Type Enter the name of the relationship type.
Description Enter a description for the relationship type.

Configuring Cross-Application Order Promising Components 51

Configuring the Fulfillment Network Model

Table 3–6 Relationship Type Detail Screen

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

3.1.5.2 Modifying a Relationship Type

To modify a relationship type:
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.
3. Enter information into the applicable fields. Refer to Table 3–6 for
field value descriptions.
4. Choose .

3.1.5.3 Deleting a Relationship Type

To delete a relationship type from the Fulfillment Network model screen:
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 .

52 Configuration Guide
 Configuring the Fulfillment Network Model

3.1.6 Defining Relationships

You can define relationships between two nodes.
Select one of the following tasks:
Q
Creating a Relationship
Q
Modifying a Relationship
Q
Deleting a Relationship

3.1.6.1 Creating a Relationship

You can create a single relationship between two nodes.
To create a single relationship between two nodes:
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.
You can also create multiple relationships of the same type from one
node to several other nodes, or from several nodes to one node.
To create multiple relationships of the same relationship type.
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 3–7 for
field value descriptions.
4. Choose OK.

Configuring Cross-Application Order Promising Components 53

Configuring the Fulfillment Network Model

Table 3–7 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.

3.1.6.2 Modifying a Relationship

To modify a relationship:
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 Table 3–8 for
field value descriptions.
3. Choose .

54 Configuration Guide
 Configuring the Fulfillment Network Model

Table 3–8 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.

Configuring Cross-Application Order Promising Components 55

Defining Item Level Controls

3.1.6.3 Deleting a Relationship

To delete a relationship:
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.

3.2 Defining Item Level Controls

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 Section 3.5.5, "Defining
Scheduling Rules".
To define item level controls:
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 3–9 for
field value descriptions.
5. Choose .

56 Configuration Guide
 Defining Levels of Service

Table 3–9 Item Level Control Pop-Up Window

Field Description
Release an order for Enter how many days before an order’s expected ship
this item n days before date a node needs to receive communication to ship
expected time of the item.
shipment
Minimum notification Enter the minimum business hours it takes to ship the
time required at this item once an order has been released to the node.
node is n 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 Global Inventory Visibility: Configuration
Guide.

3.3 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 Section 3.4.3.1, "Creating a Notification Period" for more
information. You can use the Levels of Service branch for:
Q
Creating a Level of Service
Q
Modifying a Level of Service
Q
Deleting a Level of Service

3.3.1 Creating a Level of Service

To create a level of service:
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.

Configuring Cross-Application Order Promising Components 57

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

3.3.2 Modifying a Level of Service

To modify a level of service:
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 .

58 Configuration Guide
 Defining Node Level Controls

3.3.3 Deleting a Level of Service

To delete a level of service:
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 .

3.4 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 Section 3.5.5, "Defining Scheduling Rules".
You can use the Node Level Controls branch for:
Q
Defining a Node’s Primary Order Promising Information
Q
Defining a Node’s Relationships

3.4.1 Defining a Node’s Primary Order Promising

Information
To define a node’s primary order promising information:
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 3–10 for
field value descriptions.

Configuring Cross-Application Order Promising Components 59

Defining Node Level Controls

Important: Any information entered in this window

overrides any information previously defined for the node
in Application Platform’s Participant Modeling configuration.
For more information about configuring a node
organization, see the Selling and Fulfillment Foundation:
Application Platform Configuration Guide.

5. Choose .

Figure 3–1 Node Details

60 Configuration Guide
 Defining Node Level Controls

Table 3–10 Node Details Pop-Up Window, Primary Information Tab

Field Description
Do not schedule an Enter the maximum number of business days that a
order to this node schedule can be sent to a node for it to be fulfilled.
more than n days This number is used when performing earliest
before expected time 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.

Configuring Cross-Application Order Promising Components 61

Defining Node Level Controls

Table 3–10 Node Details Pop-Up Window, Primary Information Tab

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
Allowed support 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 Check this box if the node can accept
this Node when procurement/transfer orders. For more information
Inventory is not about procurement orders, see Section 3.5.13,
available "Defining Procurement Rules".
Requires Transfer Check this box if you want this node to accept a
Acceptance procurement to confirm availability before proceeding
with the order.

62 Configuration Guide
 Defining Node Level Controls

Table 3–10 Node Details Pop-Up Window, Primary Information Tab

Field Description
Item-Based Allocation Check this box to allow item based allocation for the
Allowed item. 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
Selling and Fulfillment Foundation: Product Concepts
Guide
Receipt Processing Enter how many hours it takes the node to process
Time For Procurement receipts.
(Hours)
Receipt Processing Enter the time it takes the node to process receipts for
Time for Forwarding forwarding in hours.
(Hours)
Receipt Processing Enter how many days are required to process
Time for Future incoming future supplies before they are available for
Inventory (Days) orders.
Node Can Ship To
Any Address Check this box if this node can ship to any address.
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 Selling and Fulfillment
Foundation: Application Platform Configuration Guide.

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

Configuring Cross-Application Order Promising Components 63

Defining Node Level Controls

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.
You can create, modify, and delete relationships.

3.4.2.1 Creating a Node Relationship

To create a node relationship:
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 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.
5. Choose . The Relationship Details pop-up window displays.
6. Enter information into the applicable fields. Refer to Table 3–11 for
field value descriptions.
7. Choose .

64 Configuration Guide
 Defining Node Level Controls

Table 3–11 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 can be procured.
For the Relationship To Node tab, this option is
defaulted to the node you are configuring and
disabled.
To Node Select the node to which transfer order items are sent.
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.

Configuring Cross-Application Order Promising Components 65

Defining Node Level Controls

3.4.2.2 Modifying a Node Relationship

To modify a node relationship:
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 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.
5. From the table, locate the applicable relationship and choose . The
Relationship Details pop-up window displays.
6. Enter information into the applicable fields. Refer to Table 3–11 for
field value descriptions.
7. Choose .

3.4.2.3 Deleting a Node Relationship

To delete a node relationship:
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 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.
5. From the table, locate the applicable relationship choose .

66 Configuration Guide
 Defining Node Level Controls

3.4.2.4 Creating a Transfer Schedule

To create a transfer schedule:
1. From the Relationship Details pop-up window, choose in the
Transfer Schedules panel. The Transfer Schedule pop-up window
displays.
For more information about the Relationship Details pop-up window,
see Section 3.4.2.1, "Creating a Node Relationship".
2. Enter information in the applicable fields. Refer to Table 3–12 for field
value descriptions.
3. Choose .

Configuring Cross-Application Order Promising Components 67

Defining Node Level Controls

Table 3–12 Transfer Schedule Pop-Up Window

Field Description
Effective From Date Indicates the date on which the schedule becomes
effective.
If this value is not specified, it is assumed that the
Transfer Schedule will be effective for an indefinite
number of days.
Effective To Date Indicates the date on which the specified transfer
schedule stops being effective.
If this value is not specified, it is assumed that the
Transfer Schedule will remain effective indefinitely.
Default Transit Days Enter the minimum number of days the transfer order
shipments will take to reach the end node.
Transfer Cost
Transfer Cost Factor Enter the cost of transferring an item to a node.
Per Unit
Note: To calculate the Transfer Cost Factor Per Unit,
the Landed Cost check box and the Use Transportation
Cost check box in the Landed Cost window must be
selected.
Specifying the Transfer Cost Factor Per Unit overrides
the value of the Transfer Cost Factor for both internal
and external transfers in the Landed Cost window.
Currency Select the currency used for the Transfer Cost Factor
Per Unit from the drop-down list.

To create a new currency, choose

and enter information in the applicable fields. For
more information about defining the currency for the
transfer cost, see Currency Details.
If the currency is not specified, the currency that is
specified for the Enterprise will be used.
Shipped On
Day of Week Select the check box pertaining to the day of the week
on which item transfers are permitted.

68 Configuration Guide
 Defining Node Level Controls

Table 3–12 Transfer Schedule Pop-Up Window

Field Description
Override Transit Days Enter the number of transit days pertaining to 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 value of the Transit Days
will be 1 + the standard value.
Ship Date Overrides
Ship Date Select the date on which you want to override
shipping, for example, a holiday.
Can Ship Select either Yes to allow, or No to disallow shipping
on a specified day.
Override Transit Days Enter the override transit days for the Ship Date that
is overridden in the Ship Date Overrides.

Note: If a transfer schedule exists for one day, it is

assumed that this transfer schedule exists for all days.

3.4.2.5 Modifying a Transfer Schedule

To modify a transfer schedule:
1. From the Transfer Schedules panel in the Relationship Details pop-up
window, select the Transfer Schedule you want to modify.
2. Choose .
3. Enter information in the applicable fields. For field value descriptions,
see Table 3–12.
4. Click .

3.4.2.6 Deleting a Transfer Schedule

To delete a transfer schedule:
1. From the Transfer Schedules panel in the Relationship Details pop-up
window, select the Transfer Schedule you want to delete.
2. Choose .

Configuring Cross-Application Order Promising Components 69

Defining Node Level Controls

3.4.3 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:
Q
Advance notification time - the number of hours a node requires for
notification prior to expected time of shipment.
Q
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.
Q
Notification schedule - the times and days of the week that a ship
node will accept notifications.
You can create a variety of notification schedules based on calendar
timeframes. The resulting Notification Schedule List shows all the
schedules, which you can modify and delete.
Notification date is calculated as Expected shipment date - Maximum
working hours (including the shipping node’s calendar) - Advanced
notification days. An order release is created on the notification date that
is communicated to the shipping node.

3.4.3.1 Creating a Notification Period

To create a notification period:
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.

70 Configuration Guide
 Defining Node Level Controls

5. Enter information into the applicable fields. Refer to Table 3–13 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 .

Table 3–13 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.

Configuring Cross-Application Order Promising Components 71

Defining Node Level Controls

Table 3–13 Node Details Pop-Up Window, Notification Period Tab

Field Description
Notification Details
Tabs:
Q
Advanced Rush Specifies that the notification period is for advanced
rush, regular orders, or rush orders.
Q
Regular Orders
See Section 3.3, "Defining Levels of Service" for
Q
Rush
information.
Node needs to be Enter the minimum number of hours a node needs to
notified at least be notified before the expected time of shipment.
<number of hours>
hours prior to expected
time of shipment
Release an order to Enter the total number of working hours and system
this node a total of days an order for this item should be released before
<number of hours> it is expected to ship.
working hours and
<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.

3.4.3.2 Modifying a Notification Period

To modify a notification period:
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.

72 Configuration Guide
 Defining Node Level Controls

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

3.4.3.3 Deleting a Notification Period

To delete a notification period:
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 .

3.4.3.4 Specifying Levels of Service

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 Section 3.3, "Defining Levels of
Service" for more information.

Configuring Cross-Application Order Promising Components 73

Defining Sourcing and Scheduling Rules

To specify levels of service:

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 3–13 for
field value descriptions.
8. Choose .

3.5 Defining Sourcing and Scheduling Rules

You can define the sourcing and scheduling rules for product items,
delivery services, and provided services.
You can use the Sourcing and Scheduling branch for:
Q
Defining Fulfillment Types
Q
Defining Basic Sourcing Configuration
Q
Creating an Order Sourcing Classification
Q
Defining Sourcing Region Selection
Q
Defining Scheduling Rules
Q
Configuring Landed Cost Optimization
Q
Defining Forwarding/Transfer Rules

74 Configuration Guide
 Defining Sourcing and Scheduling Rules

Q
Defining Distribution Groups for Product Items
Q
Defining Sourcing Rules for Product Items
Q
Defining Sourcing Rules for Delivery Service Items
Q
Defining Distribution Groups for Provided Service Items
Q
Defining Sourcing Rules for Provided Service Items
Q
Defining Procurement Rules

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

Important: The sourcing rules for product sourcing and

procurement must have the same fulfillment type for
sourcing setup to work properly.

You can use the Fulfillment Types branch for:

Q
Creating a Fulfillment Type
Q
Modifying a Fulfillment Type
Q
Deleting a Fulfillment Type

3.5.1.1 Creating a Fulfillment Type

To create a fulfillment type:
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.

Configuring Cross-Application Order Promising Components 75

Defining Sourcing and Scheduling Rules

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 .

3.5.1.2 Modifying a Fulfillment Type

To modify a fulfillment type:
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 .

76 Configuration Guide
 Defining Sourcing and Scheduling Rules

3.5.1.3 Deleting a Fulfillment Type

To delete a fulfillment type:
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 .

3.5.2 Defining Basic Sourcing Configuration

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.

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

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

Configuring Cross-Application Order Promising Components 77

Defining Sourcing and Scheduling Rules

Table 3–14 Sourcing Basic Configuration Window

Field Description
Default Fulfillment Select the fulfillment type you want to be use by
Type to be used when default for sourcing when no fulfillment type is
not specified on the specified on the order. For more information about
order configuring fulfillment types, see Section 3.5.1,
"Defining Fulfillment Types".
Products being shipped
Use any of my nodes Select this option if you do not want to define product
for shipping the item sourcing rules for the organization you are
product 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.

78 Configuration Guide
 Defining Sourcing and Scheduling Rules

Table 3–14 Sourcing Basic Configuration Window

Field Description
Find node based on Select this option if you want to use configured
sourcing rule setup product item sourcing rules with the organization you
are configuring. For more information about
configuring product item sourcing rules, see
Section 3.5.9, "Defining Sourcing Rules for Product
Items".
Default Distribution Select the default distribution group you want to use
Rule to be used when to source product items when the system cannot
no sourcing rule found determine an appropriate sourcing rule to use for an
order. A distribution group is a defined set of nodes
and source organizations.
Note: Sterling Commerce recommends you to
configure a default Distribution Rule for each
demand owner. The default Distribution Rule is
used to map unassigned demands to supply. If
you do not configure the default Distribution
Rule, the APIs may return results as AVAILABLE,
causing orders to get accepted even though they
cannot be actually sourced.
For more information about configuring distribution
groups for product items, see Section 3.5.8, "Defining
Distribution Groups for Product Items".
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
sourcing rule setup delivery service item sourcing rules with the
organization you are configuring. For more information
about configuring delivery service item sourcing rules,
see Section 3.5.9, "Defining Sourcing Rules for Product
Items".
Provided Services

Configuring Cross-Application Order Promising Components 79

Defining Sourcing and Scheduling Rules

Table 3–14 Sourcing Basic Configuration Window

Field Description
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
sourcing rule setup provided service item sourcing rules with the
organization you are configuring. For more information
about configuring provided service item sourcing rules,
see Section 3.5.9, "Defining Sourcing Rules for Product
Items".

3.5.3 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 Selling and Fulfillment Foundation: Product
Concepts Guide.
You can use the Order Sourcing Classifications branch for:
Q
Creating an Order Sourcing Classification
Q
Modifying an Order Sourcing Classification
Q
Deleting an Order Sourcing Classification

3.5.3.1 Creating an Order Sourcing Classification

To create or modify an order sourcing classification:
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.

80 Configuration Guide
 Defining Sourcing and Scheduling Rules

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 .

3.5.3.2 Modifying an Order Sourcing Classification

To modify an order sourcing classification:
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 .

Configuring Cross-Application Order Promising Components 81

Defining Sourcing and Scheduling Rules

3.5.3.3 Deleting an Order Sourcing Classification

To delete an order sourcing classification:
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 .

3.5.4 Defining 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 Selling and
Fulfillment Foundation: Application Platform Configuration Guide.
You can associate region schemas with the following:
Q
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.
Q
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.
Q
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.

82 Configuration Guide
 Defining Sourcing and Scheduling Rules

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

To define sourcing region selection:

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.

3.5.5 Defining Scheduling Rules

Scheduling rules determine shipping, inventory scheduling, and node
preferences. When the Schedule time-triggered transaction schedules

Configuring Cross-Application Order Promising Components 83

Defining Sourcing and Scheduling Rules

inventory, scheduling rules are used. You can have one scheduling rule
for all orders or you can associate a specific scheduling rule with an
order. This allows different scheduling rules to be used based on your
business requirements.
There are three ways to assign a scheduling rule to an order:
Q
The scheduling rule is passed as part of the order data when creating
an order.
Q
A customer service representative selects a scheduling rule from the
Application Consoles.
Q
If a scheduling rule is not assigned by other means, Selling and
Fulfillment Foundation uses the default SYSTEM scheduling rule.

Important: When creating scheduling rules for

Enterprises, there must always be one scheduling rule
named SYSTEM to be used as a default throughout the
system.
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.
Therefore, while creating scheduling rules, a rule named
SYSTEM should be created if the scheduling rule is not
always passed as API input.

Note: The scheduling algorithm is based only on ship

node priority and geography.

You can use the Scheduling Rules branch for:

Q
Creating a Scheduling Rule
Q
Modifying a Scheduling Rule
Q
Deleting a Scheduling Rule

84 Configuration Guide
 Defining Sourcing and Scheduling Rules

3.5.5.1 Creating a Scheduling Rule

To create a scheduling rule:
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.

Configuring Cross-Application Order Promising Components 85

Defining Sourcing and Scheduling Rules

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

Table 3–15 Scheduling Rule Details Screen

Field Description
Primary Information
Scheduling Rule Enter the name of the scheduling rule.
Scheduling Rule Enter a brief description of the scheduling rule.
Description
Retry Intervals
If Product is Enter how many hours after an order has been
Backordered, retry backordered that the system should try to reprocess
scheduling after this 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 Selling and
Fulfillment Foundation still treats it as if it were 0.5.
If scheduling fails for For products, after this time (Hours) - Enter how many
any other reason retry hours after which the Schedule time-triggered
scheduling: transaction should try 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.

86 Configuration Guide
 Defining Sourcing and Scheduling Rules

Table 3–15 Scheduling Rule Details Screen

Field Description
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 Check this box to ensure that each individual line is
Node sourced from a single node on the same date.
Note: This rule does not enforce that all lines are
shipped from the same node. A particular line may be
completely shipped from node 1 while another line
could be completely shipped from node 2.
Inventory Controls
Always Select this option to consider using unplanned
inventory at both the inquiring and scheduling stages
when other sourcing options have been exhausted.
Note: In order to use unplanned inventory, the "Use
Unplanned Inventory" flag must be set to "Yes" at the
Item level.
Only During Inquiry Select this option to consider using unplanned
inventory only during the inquiring stage when other
sourcing options have been exhausted.
Note: In order to use unplanned inventory, the "Use
Unplanned Inventory" flag must be set to "Yes" at the
Item level.
Cancel Order for Check this box if you want the system to cancel an
Inventory Shortage order when there is an inventory shortage.
When unchecked, the item is backordered.

Configuring Cross-Application Order Promising Components 87

Defining Sourcing and Scheduling Rules

Table 3–15 Scheduling Rule Details Screen

Field Description
Apply On Hand Safety Check this box to apply the on hand safety factor to on
Factor To On Hand 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 Global Inventory Visibility: Configuration
Guide.
Apply Future Safety Check this box to apply the future safety factor to
Factor To Future future 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 Global Inventory Visibility: Configuration
Guide.
Lead Times
Maximum no. of days Enter a lead time for orders to be picked up by the
order can be scheduled Schedule agent.
before its ship date
Maximum no. of days Enter the number of days after the requested ship
order can be date that an order can be released.
shipped/delivered
Note: For tag controlled items, if demands are being
beyond its requested
matched against future inventory (purchase orders),
date
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 Table 3-5 "ATP
Rules Details Pop-Up Window" for the Forward
Consumption (Days) field, in the Sterling Global
Inventory Visibility: Configuration Guide.
Maximum no. of days Enter the maximum number of days before the ship
order can be scheduled date that an order can be scheduled.
before its ship date

88 Configuration Guide
 Defining Sourcing and Scheduling Rules

Table 3–15 Scheduling Rule Details Screen

Field Description
Maximum no. of days Enter the maximum number of days through which
to search service you want to look up service and slot availability.
availability for
Reservations
Allow Reservation Check this box to allow the items to be reserved while
During Scheduling scheduling.
Reserve Bundle Out of Check this box to reserve components that are out of
Ratio ratio for a bundle.
Ignore Fill Quantity Check this box to allow the reservation of partial
(Ship Complete) quantity of a line that has a ship complete constraint
or to reserve the quantity that is less than the fill
quantity.
Priority
Consider distance Check this box to enable the geography-based
between ship-to and distance calculations for choosing a ship node.
ship-from locations for
Important: If you select this field, ensure Optimize
prioritization
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 Enter the weighting factor for node priority. The ship
Node 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.

Configuring Cross-Application Order Promising Components 89

Defining Sourcing and Scheduling Rules

Table 3–15 Scheduling Rule Details Screen

Field Description
Priority Select this option for inventory scheduling to be
optimized by node priority.
Cost, Number of Select this option for inventory scheduling to be
Shipments 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 Section 3.5.6, "Configuring
Landed Cost Optimization" on page 92.
Additional Optimization Criteria
When Optimizing On Check this box to combine the optimization based on
Cost, Combine both cost and specified number of days.
Shipments In <number
In this case, enter the number of days up to which the
of days> Day
optimization should be considered.
Intervals. This May
Avoid Shipment Delay,
But May Lead To Extra
Cost
Delay Shipment Check this box to delay shipments against the onhand
Against Current inventory to be consolidated with the future inventory.
Inventory To Be
This option can be chosen only when the "When
Consolidated With
Optimizing On Cost, Combine Shipments" box is
Shipments Against
checked.
Future Inventory.
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.

90 Configuration Guide
 Defining Sourcing and Scheduling Rules

Table 3–15 Scheduling Rule Details Screen

Field Description
Delay Procurements To Check this box to delay shipments when the inventory
Be Consolidated With through transfers are available.
Shipments Against
This option can be chosen only when the "When
Future Inventory.
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 Check this box if you want the system to consider any
Inventory Availability inventory beyond the lead time + processing time
Beyond Lead Time frame to be 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 Section 3.5.7, "Defining Forwarding/Transfer
Rules".
Ignore Use Of Landed Check this box if you want to ignore the use of landed
Cost For Optimization cost 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 Section 3.5.6, "Configuring
Landed Cost Optimization".

Configuring Cross-Application Order Promising Components 91

Defining Sourcing and Scheduling Rules

3.5.5.2 Modifying a Scheduling Rule

To modify a scheduling rule:
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 3–15 for
field value descriptions.
4. Choose .

3.5.5.3 Deleting a Scheduling Rule

To delete a scheduling rule:
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 .

3.5.6 Configuring Landed Cost Optimization

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
Section 3.5.5, "Defining Scheduling Rules", or the 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.

92 Configuration Guide
 Defining Sourcing and Scheduling Rules

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.

To configure landed cost optimization:

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

Configuring Cross-Application Order Promising Components 93

Defining Sourcing and Scheduling Rules

Figure 3–2 Landed Cost

Table 3–16 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 Check this box to indicate that transportation cost
Cost criteria should be used when computing landed cost.
Transfers

94 Configuration Guide
 Defining Sourcing and Scheduling Rules

Table 3–16 Landed Cost Window

Field Description
Transfer Cost Factor Select the currency used for the transfer cost factor
Currency from the drop-down list.
Transfer Cost Factor __ Enter the transfer cost factor and select the correct
Per __ Per __ for 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 __ Enter the transfer cost factor and select the correct
Per __ Per __ for 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
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 Section 3.5.6.2, "Defining Enterprise
Node Type Rules".

Configuring Cross-Application Order Promising Components 95

Defining Sourcing and Scheduling Rules

Table 3–16 Landed Cost Window

Field Description
Convert Node Priority Check this box to use the priority of the node to be
into Cost converted into cost.
When this box is checked, the node with a lower
priority is considered when optimizing on cost.
Node Priority Cost Enter the cost factor for the node. You can enter
Factor 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.

3.5.6.1 Currency Details

You can define the currency for the node priority cost factor in the
currency details pop-up window.

Figure 3–3 Currency Details

96 Configuration Guide
 Defining Sourcing and Scheduling Rules

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

3.5.6.2 Defining Enterprise Node Type Rules

You can define Enterprise Node Type Rules to specify the handling costs
of various node types at the Enterprise level.
Q
Creating an Enterprise Node Type Rule
Q
Modifying an Enterprise Node Type Rule
Q
Deleting an Enterprise Node Type Rule

Creating an Enterprise Node Type Rule

To create an Enterprise node type rule:
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.

Configuring Cross-Application Order Promising Components 97

Defining Sourcing and Scheduling Rules

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 3–18 for
field value descriptions.
4. Choose .

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

98 Configuration Guide
 Defining Sourcing and Scheduling Rules

Table 3–18 Enterprise Node Type Rule Pop-up Window

Field Description
Per Unit Choose this option to enter the handling cost for each
unit.
Choosing this option disables the "Per Unit Weight"
option.
Per Unit Weight Choose this option to enter the handling cost for each
unit weight.
Choosing this option disables the "Per Unit" option.
Outbound Handling Cost
Per Shipment Enter the handling cost for each shipment, in the
currency selected above.
Per Line Enter the handling cost for each line, in the currency
selected above.
Per Unit Choose this option to enter the handling cost for each
unit.
Choosing this option disables the "Per Unit Weight"
option.
Per Unit Weight Choose this option to enter the handling cost for each
unit weight.
Choosing this option disables the "Per Unit" option.

Modifying an Enterprise Node Type Rule

To modify an Enterprise node type rule:
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 3–18 for
field value descriptions.
4. Choose .

Configuring Cross-Application Order Promising Components 99

Defining Sourcing and Scheduling Rules

Deleting an Enterprise Node Type Rule

To delete an Enterprise node type rule:
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 .

3.5.7 Defining 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, 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:
Q
If forwarding is not enabled at the Enterprise level.
Q
If forwarding is not enabled at the line level.
Q
If forwarding is not enabled at the item level.
Q
If a shipment is being delivered.
Q
If a shipment has shipping and receiving nodes with a transfer
schedule between them.
Q
If the shipment is not a final shipment to the customer
(procurements cannot be forwarded).
Q
If a carrier service code is not specified at the line or header level.
Q
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.

100 Configuration Guide

 Defining Sourcing and Scheduling Rules

To define forwarding/transfer rules:

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

Table 3–19 Forwarding/Transfer Rules Window

Field Description
Forwarding Rules
Use Forwarding Select this checkbox if you want use forwarding.
Deselecting this checkbox disables all other forwarding
options.
Default Carrier Service Select a default carrier service to use during
For Forwarding forwarding from the drop-down list.
For Transportation Considerations Based On Number Of Cartons:
Assume Average Enter a volume and volume UOM to be used as the
Volume Per Carton To assumed average volume per carton.
Be __

Configuring Cross-Application Order Promising Components 101

Defining Sourcing and Scheduling Rules

Table 3–19 Forwarding/Transfer Rules Window

Field Description
Link To 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 To Consider shipments Selling and Fulfillment Foundation considers
Through Transfers through transfers between shipping nodes.
Between Shipping
Nodes
Consider Transfers Select a relationship type from the drop-down list.
Only When Following Transfers are considered only when this relationship
Relationship Exists exists between two shipping nodes.
Between Two Shipping
This field is disabled if the "Minimize Number of
Nodes
Shipments To Consider Through Transfers Between
Shipping Nodes" checkbox is not selected.

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

Note: For backward compatibility purposes, you can also

create rules for individual items at a source node or for the
entire source node.

You can use the Distribution Rules branch for:

Q
Creating a Distribution Group
Q
Deleting a Distribution Group

102 Configuration Guide

 Defining Sourcing and Scheduling Rules

3.5.8.1 Creating a Distribution Group

To create a distribution group:
1. From the tree in the application rules side panel, choose Cross
Application > Order Promising > Sourcing And Scheduling > Product
Being 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 .
You can use the Distribution Group Details window for:
Q
Adding Nodes/External Organizations to a Distribution Group
Q
Modifying a Distribution Group’s Node/External Organization
Q
Deleting a Distribution Group’s Node/External Organization

Configuring Cross-Application Order Promising Components 103

Defining Sourcing and Scheduling Rules

3.5.8.1.1 Adding Nodes/External Organizations to a Distribution

Group
To add a node/external organization to a distribution group:
1. In the Distribution Group Details window, choose the Distribution
Detail tab.
2. Choose . The Distribution Details pop-up window displays.
3. Enter information into the applicable fields. Refer to Table 3–20 for
field value descriptions.
4. Choose .

Table 3–20 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.

104 Configuration Guide

 Defining Sourcing and Scheduling Rules

Table 3–20 Distribution Details Window

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

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

3.5.8.1.2 Modifying a Distribution Group’s Node/External

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

3.5.8.1.3 Deleting a Distribution Group’s Node/External

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

Configuring Cross-Application Order Promising Components 105

Defining Sourcing and Scheduling Rules

3.5.8.2 Adding Advanced Distribution Details to a Distribution

Group (For Backward Compatibility Only)
You can add specific details, such as sourcing information, and assign
them a date range through which they are effective.

Important: Sterling Commerce 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:

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 Table 3–7 for field
value descriptions.
4. Choose .

106 Configuration Guide

 Defining Sourcing and Scheduling Rules

Table 3–21 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 Select this option to apply the distribution rule to a
At This Source specific 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.
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.

3.5.8.3 Deleting Advanced Distribution Details

To delete a advanced distribution details:
1. In the Distribution Group Details window, choose the Advanced tab.
2. From the Distribution table, select the applicable distribution details
and choose .

Configuring Cross-Application Order Promising Components 107

Defining Sourcing and Scheduling Rules

3.5.8.4 Deleting a Distribution Group

To delete a distribution group:
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 .

3.5.9 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):
Q
Fulfillment Type
Q
Order Sourcing Classification
Q
Seller organization
Q
Item ID
Q
Primary Item Classification
Q
Secondary Item Classification
Q
Tertiary Item Classification
Q
Geographical region of the ship to location

Note: When a node is passed on an order line, the

system uses that node regardless of the sourcing rules you
may have configured.

You can use the Sourcing Rules branch for:

Q
Creating a Product Item Sourcing Rule
Q
Modifying a Product Item Sourcing Rule
Q
Deleting a Product Item Sourcing Rule

108 Configuration Guide

 Defining Sourcing and Scheduling Rules

3.5.9.1 Creating a Product Item Sourcing Rule

To create a sourcing rule:
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 3–22 for
field value descriptions.
4. Choose .

Configuring Cross-Application Order Promising Components 109

Defining Sourcing and Scheduling Rules

110 Configuration Guide

 Defining Sourcing and Scheduling Rules

Table 3–22 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 Section 3.5.1,
"Defining Fulfillment Types".
Order Sourcing Select the applicable order sourcing classification if
Classification you want to associate this sourcing rule with a
particular order sourcing classification. For more
information about configuring order sourcing
classifications, see Section 3.5.3, "Defining Order
Sourcing Classifications".
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 Section 3.5.4,
"Defining Sourcing Region Selection".

Configuring Cross-Application Order Promising Components 111

Defining Sourcing and Scheduling Rules

Table 3–22 Sourcing Rule for Product Being Shipped Window

Field Description
This Node Select Node and select the applicable node if you want
this sourcing rule to be used when products are
shipped to this node.
Nodes of Type Select Nodes of Type and select the applicable node
types available if you want this sourcing rule to be
used when products are shipped to a specific node
type.
Any Address Select Any Address and if this sourcing rule can be
used when products are shipped to any node.
Sourced From List
The system tries to source the product from the node/distribution group with
the highest sequence (lowest number). If the sourcing template contains a
distribution group or a set of nodes, the final node selection is optimized based
on the parameters configured in your scheduling rule associated with a given
order. For more information about scheduling rules, see Section 3.5.5, "Defining
Scheduling Rules".
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
Section 3.5.14, "Defining Sourcing Template Details".

3.5.9.2 Modifying a Product Item Sourcing Rule

To modify a sourcing rule:
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 3–22 for
field value descriptions.

112 Configuration Guide

 Defining Sourcing and Scheduling Rules

4. Choose .

3.5.9.3 Deleting a Product Item Sourcing Rule

To delete a sourcing rule:
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 .

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

Note: When a node is passed on an order line, the

system uses that node regardless of the sourcing rules you
may have configured.

You can use the Sourcing Rules branch for:

Q
Creating a Delivery Service Item Sourcing Rule
Q
Modifying a Delivery Service Sourcing Rule
Q
Deleting a Delivery Service Sourcing Rule

3.5.10.1 Creating a Delivery Service Item Sourcing Rule

To create a sourcing rule:
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.

Configuring Cross-Application Order Promising Components 113

Defining Sourcing and Scheduling Rules

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

114 Configuration Guide

 Defining Sourcing and Scheduling Rules

Table 3–23 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 Section 3.5.1,
"Defining Fulfillment Types".
Order Sourcing Select the applicable order sourcing classification if
Classification you want to associate this sourcing rule with a
particular order sourcing classification. For more
information about configuring order sourcing
classifications, see Section 3.5.3, "Defining Order
Sourcing Classifications".
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 Section 3.5.4, "Defining Sourcing Region
Selection".
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.

Configuring Cross-Application Order Promising Components 115

Defining Sourcing and Scheduling Rules

Table 3–23 Sourcing Rule for Product Being Delivered Window

Field Description
Procure/Transfer to Check this box if the node handles transfer orders
this Node when and/or procurement purchase orders. For more
inventory is not information about transfer orders and procurement
available. purchase orders, see Section 3.4.2, "Defining a Node’s
Relationships" and Section 3.5.13, "Defining
Procurement Rules".
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 Section 3.5.5, "Defining
Scheduling Rules".
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
Section 3.5.14, "Defining Sourcing Template Details".

3.5.10.2 Modifying a Delivery Service Sourcing Rule

To modify a sourcing rule:
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 3–23 for
field value descriptions.
4. Choose .

116 Configuration Guide

 Defining Sourcing and Scheduling Rules

3.5.10.3 Deleting a Delivery Service Sourcing Rule

To delete a sourcing rule:
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 .

3.5.11 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.
You can use the Distribution Rules branch for:
Q
Creating a Distribution Group
Q
Deleting a Distribution Group

3.5.11.1 Creating a Distribution Group

To create a distribution group:
1. From the tree in the application rules side panel, choose Cross
Application > Order Promising > Sourcing And Scheduling > Provided
Services > Distribution Rules. The Distribution Rules window displays
in the work area.
2. Choose . The Distribution Group Detail window displays.

Configuring Cross-Application Order Promising Components 117

Defining Sourcing and Scheduling Rules

3. In Distribution Group, enter the name of the distribution rule.

4. In Description, enter a brief description of the distribution rule.
5. Choose .
You can use the Distribution Group Details window for:
Q
Adding Nodes/External Organizations to a Distribution Group
Q
Modifying a Distribution Group’s Node/External Organization
Q
Deleting a Distribution Group’s Node/External Organization

3.5.11.1.1 Adding Nodes/External Organizations to a

Distribution Group
To add a node/external organization to a distribution group:
1. In the Distribution Group Details window, choose the Distribution
Detail tab.
2. Choose . The Distribution Details pop-up window displays.

118 Configuration Guide

 Defining Sourcing and Scheduling Rules

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

Table 3–24 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.

3.5.11.1.2 Modifying a Distribution Group’s Node/External

Organization
To modify a distribution group’s node/external organization:
1. In the Distribution Group Details window, choose the Distribution
Detail tab.
2. Select the applicable distribution detail and choose . The
Distribution Details pop-up window displays.

Configuring Cross-Application Order Promising Components 119

Defining Sourcing and Scheduling Rules

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

3.5.11.1.3 Deleting a Distribution Group’s Node/External

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

3.5.11.2 Deleting a Distribution Group

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

3.5.12 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:
Q
Fulfillment type
Q
Order sourcing classification
Q
Seller organization
Q
Item ID
Q
Geographical region of the location where the service is to be
provided
Q
Node where the service is to be provided

120 Configuration Guide

 Defining Sourcing and Scheduling Rules

Note: When a node is passed on an order line, the

system uses that node regardless of the sourcing rules you
may have configured.

You can use the Sourcing Rules branch for:

Q
Creating a Provided Service Item Sourcing Rule
Q
Modifying a Provided Service Sourcing Rule
Q
Deleting a Provided Service Sourcing Rule

3.5.12.1 Creating a Provided Service Item Sourcing Rule

To create a sourcing rule:
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 3–25 for
field value descriptions.
4. Choose .

Configuring Cross-Application Order Promising Components 121

Defining Sourcing and Scheduling Rules

Table 3–25 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 Section 3.5.1,
"Defining Fulfillment Types".
Order Sourcing Select the applicable order sourcing classification if
Classification you want to associate this sourcing rule with a
particular order sourcing classification. For more
information about configuring order sourcing
classifications, see Section 3.5.3, "Defining Order
Sourcing Classifications".
When Seller organization is

122 Configuration Guide

 Defining Sourcing and Scheduling Rules

Table 3–25 Sourcing Rule for Provided Service

Field Description
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 Section 3.5.4, "Defining Sourcing Region
Selection".
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 Section 3.5.5, "Defining
Scheduling Rules".
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.

Configuring Cross-Application Order Promising Components 123

Defining Sourcing and Scheduling Rules

Table 3–25 Sourcing Rule for Provided Service

Field Description
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
Section 3.5.14, "Defining Sourcing Template Details".

3.5.12.2 Modifying a Provided Service Sourcing Rule

To modify a sourcing rule:
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 3–25 for
field value descriptions.
4. Choose .

3.5.12.3 Deleting a Provided Service Sourcing Rule

To delete a sourcing rule:
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 .

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

124 Configuration Guide

 Defining Sourcing and Scheduling Rules

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 Section 3.4.2,
"Defining a Node’s Relationships".
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.
You can use the Procurement branch for:
Q
Creating a Sourcing Rule for Procurement
Q
Modifying a Sourcing Rule for Procurement
Q
Deleting a Product Procurement Rule
Q
Creating a Procurement Distribution Group
Q
Modifying a Procurement Distribution Group
Q
Deleting a Procurement Distribution Group

3.5.13.1 Creating a Sourcing Rule for Procurement

To create product procurement sourcing rules:
1. From the tree in the application rules side panel, choose Cross
Application > Order Promising > Sourcing And Scheduling >
Procurement > Sourcing Rules. The Procurement - Sourcing Rule
Search window displays in the work area.
2. Choose . The Sourcing Rules for Procurement window displays.
3. Enter information into the applicable fields. Refer to Table 3–26 for
field value descriptions.

Configuring Cross-Application Order Promising Components 125

Defining Sourcing and Scheduling Rules

Table 3–26 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 Section 3.5.1,
"Defining Fulfillment Types".
Order Sourcing Select the applicable order sourcing classification if
Classification you want to associate this sourcing rule with a
particular order sourcing classification. For more
information about configuring order sourcing
classifications, see Section 3.5.3, "Defining Order
Sourcing Classifications".
And Product characteristics are
Item ID Select Item ID and enter the item you want the node
to be able to procure.

126 Configuration Guide

 Defining Sourcing and Scheduling Rules

Table 3–26 Sourcing Rules for Procurement Window

Field Description
All Items Select All Items if you want the node to be able to
procure any item.
And Procuring To
This Node Select Node and select the applicable node if you want
this sourcing rule to be used when products are
shipped to this node.
The Nodes of Type Select Nodes of Type and select the applicable node
types available if you want this sourcing rule to be
used when products are shipped to a specific node
type.
Any Node Select Any Node and if this sourcing rule can be used
when products are shipped to any node.
Sourced From List
The system tries to source the product from the node/distribution group with
the highest sequence (lowest number). If the sourcing template contains a
distribution group or a set of nodes, the final node selection is optimized based
on the parameters configured in your scheduling rule associated with a given
order. For more information about scheduling rules, see Section 3.5.5, "Defining
Scheduling Rules".
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
Section 3.5.14, "Defining Sourcing Template Details".

4. Choose .

3.5.13.2 Modifying a Sourcing Rule for Procurement

To modify a sourcing rule for procurement:
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.

Configuring Cross-Application Order Promising Components 127

Defining Sourcing and Scheduling Rules

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 3–26 for
field value descriptions.
4. Choose .

3.5.13.3 Deleting a Product Procurement Rule

To delete a sourcing rule for procurement:
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 .

3.5.13.4 Creating a Procurement Distribution Group

To create a distribution group:
1. From the tree in the application rules side panel, choose Cross
Application > Order Promising > Sourcing And Scheduling >
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 3–27 for
field value descriptions.

128 Configuration Guide

 Defining Sourcing and Scheduling Rules

Table 3–27 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 .

3.5.13.5 Modifying a Procurement Distribution Group

To modify a distribution group:
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 3–27 for
field value descriptions.
4. Choose .

3.5.13.6 Deleting a Procurement Distribution Group

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

Configuring Cross-Application Order Promising Components 129

Defining Sourcing and Scheduling Rules

3.5.14 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 Selling and Fulfillment
Foundation: Javadocs.
From the Sourcing Rule window, you can:
Q
Applying a Sourcing Template to a Sourcing Rule
Q
Modifying a Sourcing Template for a Sourcing Rule
Q
Removing a Sourcing Template from a Sourcing Rule

3.5.14.1 Applying a Sourcing Template to a Sourcing Rule

To apply a sourcing template to a sourcing rule:
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 3–28 for
field value descriptions.
3. Choose .

130 Configuration Guide

 Defining Sourcing and Scheduling Rules

Figure 3–4 Sourced From Details Window

Table 3–28 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.
Procure/Transfer to Check this box if the node handles transfer orders or
this Node when procurement purchase orders. For more information
inventory is not about transfer orders and procurement purchase
available orders, see Section 3.4.2, "Defining a Node’s
Relationships" and Section 3.5.13, "Defining
Procurement Rules".
Substitution Is Allowed Check this box if substitution of product items within
an order is allowed.

Configuring Cross-Application Order Promising Components 131

Defining Sourcing and Scheduling Rules

Table 3–28 Sourced From Details Pop-Up Window

Field Description
Work Order Creation Is Check this box if you want to use Work Orders to
Allowed support compliance services at the node(s). Work
Orders describe the service activities to customize
items based on a buyer’s requests.
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
available in the next made available in the specified number of days.
<number of days>
Enter the number of day(s) in the text box indicating
day(s)
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 Rule Sourcing Rule Inventory Window.
Inventory Window

Note: The Sourced From Details window is applicable for

Product Sourcing only.

3.5.14.2 Modifying a Sourcing Template for a Sourcing Rule

To modify a sourcing template for a sourcing rule:
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 3–28 for
field value descriptions.
3. Choose .

3.5.14.3 Removing a Sourcing Template from a Sourcing Rule

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 .

132 Configuration Guide

 4
Configuring Cross-Application Service
Execution Components

You can use the Service Execution branch for:

Q
Configuring Service Supervisors
Q
Configuring Questions

4.1 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 Selling and
Fulfillment Foundation: Application Platform Configuration
Guide.

Configuring Cross-Application Service Execution Components 133

Configuring Service Supervisors

You can use the Service Supervisors branch for:

Q
Defining a Service Supervisor for a Node
Q
Modifying a Service Supervisor for a Node
Q
Deleting a Service Supervisor for a Node

4.1.1 Defining a Service Supervisor for a Node

To define a service supervisor for a node:
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 4–1 for field
value descriptions.
4. Choose .

134 Configuration Guide

 Configuring Service Supervisors

Table 4–1 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.

4.1.2 Modifying a Service Supervisor for a Node

To modify a service supervisor for a node:
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 4–1 for field
value descriptions.
4. Choose .

4.1.3 Deleting a Service Supervisor for a Node

To delete a service supervisor for a node:
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.

Configuring Cross-Application Service Execution Components 135

Configuring Questions

3. Select the row which contains the seller organization and supervisor
ID that you want to delete and choose .
4. Choose .

4.2 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.
You can use the Questions branch for:
Q
Defining Address Question Groups
Q
Modifying Address Question Groups
Q
Deleting Address Question Groups
Q
Defining Address Questions
Q
Modifying Address Questions
Q
Deleting Address Questions
Q
Defining Capacity Impact
Q
Modifying Capacity Impact
Q
Deleting Capacity Impact
Q
Rearranging Address Question Entities
Q
Defining Permit Question Groups
Q
Modifying Permit Question Groups
Q
Deleting Permit Question Groups
Q
Defining Permit Questions
Q
Modifying Permit Questions
Q
Deleting Permit Questions
Q
Rearranging Permit Questionnaire Entities

136 Configuration Guide

 Configuring Questions

4.2.1 Defining Address Question Groups

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 4–2 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.

Configuring Cross-Application Service Execution Components 137

Configuring Questions

3. Enter information in the applicable fields. See Table 4–5 for field
value descriptions.
4. Choose .

Note: Identifiers are unique across Question IDs and

Question Group IDs.

4.2.2 Modifying Address Question Groups

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

4.2.3 Deleting Address Question Groups

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 .

4.2.4 Defining Address Questions

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

138 Configuration Guide

 Configuring Questions

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 4–3 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.

Configuring Cross-Application Service Execution Components 139

Configuring Questions

Table 4–3 Question Details

Fields
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 4–6 for field
value descriptions.
4. Choose .

4.2.5 Modifying Address Questions

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

4.2.6 Deleting Address Questions

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 .

140 Configuration Guide

 Configuring Questions

4.2.7 Defining Capacity Impact

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

Configuring Cross-Application Service Execution Components 141

Configuring Questions

Table 4–4 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 If available, enter the value you want to multiply the
Multiplier 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 4–4 for field
value descriptions.
4. Choose .

4.2.8 Modifying Capacity Impact

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

142 Configuration Guide

 Configuring Questions

4.2.9 Deleting Capacity Impact

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 .

4.2.10 Rearranging Address Question 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:
Q
Questions Groups - these can be arranged on the questionnaire
tree at the root level.
Q
Questions - these can be arranged within a question group, in and
out of question groups, and up and down levels.
Q
Answer Options - these can be arranged within a question.
Using the drag and drop functionality, you can:
Q
Move questions in and out of question groups
Q
Change a follow-up question into a stand-alone question by dropping
onto a question group or the root of the tree
Q
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.

Configuring Cross-Application Service Execution Components 143

Configuring Questions

4.2.11 Defining Permit Question Groups

1. From the tree in the application rules side panel, choose Cross
Application > Service Execution > Questions. The Questions window
displays in the work area. Select the Permit Questions tab to view the
Permit Questions window.

2. Choose . The Question Group Details pop-up window displays.

Table 4–5 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.

144 Configuration Guide

 Configuring Questions

3. Enter information in the applicable fields. Refer to Table 4–5 for field
value descriptions.
4. Click .

Note: Identifiers are unique across Question IDs and

Question Group IDs.

4.2.12 Modifying Permit Question Groups

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

4.2.13 Deleting Permit Question Groups

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 .

4.2.14 Defining Permit Questions

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

Configuring Cross-Application Service Execution Components 145

Configuring Questions

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 4–6 Question Details

Fields
Question ID Enter the unique question ID.
Question Text Enter the question text as you want the question to
appear in the UI.
Data Type Select the data type for the answers. The data type
you select governs the possible display control type
options:
Text - Textbox, Text Area, Dropdown, Radio Button
Integer - Textbox
Decimal - Textbox
Boolean - Checkbox
Display Control Type Select how you want the answer options to appear in
the UI. The display control types available depend on
the Data Type you have selected.
Answer Options - the following fields appear when you have chosen
Dropdown or Radio Button as the desired display control type.

146 Configuration Guide

 Configuring Questions

Table 4–6 Question Details

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

4.2.15 Modifying Permit Questions

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

4.2.16 Deleting Permit Questions

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 .

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

Configuring Cross-Application Service Execution Components 147

Configuring Questions

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:
Q
Questions Groups - these can be arranged on the questionnaire
tree at the root level.
Q
Questions - these can be arranged within a question group, in and
out of question groups, and up and down levels.
Q
Answer Options - these can be arranged within a question.
Using the drag and drop functionality, you can:
Q
Move questions in and out of question groups
Q
Change a follow-up question into a stand-alone question by dropping
onto a question group or the root of the tree
Q
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.

148 Configuration Guide

 5
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:
Q
Defining Logistics Attributes
Q
Defining Delivery Codes
Q
Defining Shipment Modes
Q
Defining Outbound Constraints

5.1 Defining Logistics Attributes

You can define rules and common codes associated logistics of shipping
an order.
You can use the Logistics Attributes branch for:
Q
Defining Freight Terms
Q
Defining Shipment Modes
Q
Defining Carrier Modification Reasons
Q
Defining Additional Logistic Rules

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

Configuring Cross-Application Logistics Components 149

Defining Logistics Attributes

The default freight terms of Selling and Fulfillment Foundation are:

Q
Cost Insurance and Freight (CIF) - The freight cost is completely paid
by either the Seller, the Enterprise, or the Hub.
Q
Cost and Freight (CFR) - The freight cost is paid by the Buyer and
either the Seller, the Enterprise, or the Hub.
Q
Free On Board (FOB) - The freight cost is paid by the Buyer.
You can use the Freight Terms tab for:
Q
Creating a Freight Term
Q
Modifying a Freight Term
Q
Deleting a Freight Term

5.1.1.1 Creating a Freight Term

To create a freight term:
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 5–1 for field
value descriptions.
5. Enter Choose .

150 Configuration Guide

 Defining Logistics Attributes

Table 5–1 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 Both the Buyer and the Enterprise can establish
Routing Guide routing 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
Selling and Fulfillment Foundation: Product Concepts
Guide for more information about these shipping
concepts.
First Buyer then Select to use any shipping rules established by the
Enterprise buyer first. Enterprise rules are applied if no applicable
Buyer rule exists.

Configuring Cross-Application Logistics Components 151

Defining Logistics Attributes

Table 5–1 Freight Terms Details

Field Description
First Enterprise then Select to use any shipping rules established by the
Buyer 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.

5.1.1.2 Modifying a Freight Term

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

5.1.1.3 Deleting a Freight Term

To delete a freight term:
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 .

152 Configuration Guide

 Defining Logistics Attributes

5.1.2 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 Selling and Fulfillment
Foundation is:
Q
Requested Change
You can use the Modify Carrier Reason tab for:
Q
Creating a Carrier Modification Reason
Q
Modifying a Carrier Modification Reason
Q
Deleting a Carrier Modification Reason

5.1.2.1 Creating a Carrier Modification Reason

To create a carrier modification reason:
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.

Configuring Cross-Application Logistics Components 153

Defining Logistics Attributes

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 .

5.1.2.2 Modifying a Carrier Modification Reason

To modify a carrier modification reason:
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 .

5.1.2.3 Deleting a Carrier Modification Reason

To delete a carrier modification reason:
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 .

154 Configuration Guide

 Defining Logistics Attributes

5.1.3 Defining Additional Logistic Rules

You can define additional rules that pertain to an order document type.
To define additional logistic rules:
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 5–2 for field
value descriptions.
4. Choose .

Table 5–2 Other Rules Tab

Field Description
Advance Transit Time Calculation
Use Advanced Transit Select this field if advance transit time calculation is
Time Calculation required 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
Carrier Service calculations to be based on the carrier and carrier
service being used for an order.

Configuring Cross-Application Logistics Components 155

Defining Logistics Attributes

Table 5–2 Other Rules Tab

Field Description
Based on Carrier Select Based on Carrier Service if you want transit
Service time calculations to be based on the specific carrier
service being used for an order.
Delivery Lead Time Enter the default delivery lead time.
(Days)
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:
Q
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.
Q
If the ship date is provided but the delivery date is
not, the delivery date is defaulted to ship date +
delivery lead time.
Q
If the delivery date is provided but the ship date is
not, the ship date is defaulted to delivery date -
delivery lead time.
Q
If both the ship date and delivery date are
provided, this rule is not applied.
Round Up Transit Time If selected, transit time calculations are not specific
To Nearest Day down to 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 Select the carrier service you want to use to compute
for Transfer the 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 appropriate section
in this guide.

156 Configuration Guide

 Defining Delivery Codes

5.2 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 Selling and Fulfillment Foundation are:
Q
ENTERPRISE
Q
MARKETPLACE
Q
SUPPLIER
You can use the Delivery Codes branch for:
Q
Creating a Delivery Code
Q
Modifying a Delivery Code
Q
Deleting a Delivery Code

5.2.1 Creating a Delivery Code

To create a delivery code:
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.

Configuring Cross-Application Logistics Components 157

Defining Shipment Modes

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 .

5.2.2 Modifying a Delivery Code

To modify a delivery code:
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 .

5.2.3 Deleting a Delivery Code

To delete a delivery code:
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 .

5.3 Defining Shipment Modes

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

158 Configuration Guide

 Defining Shipment Modes

The default shipment modes of Selling and Fulfillment Foundation are:

Q
TL - Truckload
Q
LTL - Less-Than Truckload
Q
PARCEL
You can use the Shipment Modes tab for:
Q
Creating a Shipment Mode
Q
Modifying a Shipment Mode
Q
Deleting a Shipment Mode

5.3.1 Creating a Shipment Mode

To create a shipment mode:
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 .

Configuring Cross-Application Logistics Components 159

Defining Outbound Constraints

5.3.2 Modifying a Shipment Mode

To modify a shipment mode:
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.
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 .

5.3.3 Deleting a Shipment Mode

To delete a shipment mode:
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 .

5.4 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:
Q
Creating a Routing Guide
Q
Modifying a Routing Guide
Q
Deleting a Routing Guide

Note: the Outbound Constraints node does not apply to

Reverse Logistics or Supply Collaboration.

160 Configuration Guide

 Defining Outbound Constraints

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

Configuring Cross-Application Logistics Components 161

Defining Outbound Constraints

Table 5–3 Outbound Constraint Window

Field Description
Do not mix in a If any of the following are selected, separate
shipment shipments must be create for items that have different
values for these attributes.
For example, if Department Code is selected, items
that are for different departments can not be included
in the same shipment.
Buyer Mark For The buyer mark for node id.
Node Id
Customer PO # Customer’s Purchase Order number.
Department Code The department for which the item is intended.
Gift Flag The gift flag.
Level of Service The level of service on the order.
Mark For Person for whom this shipment is marked for
Order # The order number.
Order Type The order type.
Transportation
optimization
Economic shipping Economic Shipping Parameters (ESP) are used in
parameters maintained shipping 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.

162 Configuration Guide

 Defining Outbound Constraints

Table 5–3 Outbound Constraint Window

Field Description
Delay shipment by not Enter the number of days this shipment can be
more than __ Days delayed 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 Enter a weight.
weight threshold of
Consolidate up to Enter a volume
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
Selling and Fulfillment Foundation to determine how
shipments should be routed. See Section 5.4.1,
"Creating a Routing Guide".
In addition to the routing guide maintained here by
the enterprise, there may be a routing guide for the
buyer organization.
For more information about using both buyer and
enterprise routing guides, see Section 5.1.1.1,
"Creating a Freight Term".
Maintained Externally Select this to indicate that an external routing system
is used. The routing guides maintained in 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.

5.4.1 Creating a Routing Guide

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.

Configuring Cross-Application Logistics Components 163

Defining Outbound Constraints

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:
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 5–4 for field
value descriptions.
4. Choose .

Figure 5–1 Routing Guide Details Window

Table 5–4 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.

164 Configuration Guide

 Defining Outbound Constraints

Table 5–4 Routing Guide Details Window

Field Description
Supersedes Routing Tracking information. For example, if a minor revision
Guide # is made to routing guide "1234", you might create a
routing guide "1234-A", and enter that it supersedes
routing guide "1234". This field is for informational
purposes and is not used to determine the effective
routing guide.
Effective Date The start date for applying the routing information in
this routing guide. You can use the effective date and
expiration date to apply routing guidelines for
particular periods of time.
Expiration Date The end date for applying the routing information in
this routing guide.
Apply this Routing Guide when
Freight Terms Apply this routing guide when this condition is met.
Select is, is in, or is not. Use:
Q
is to specify a single Freight Term.
Q
is in to specify a group of Freight Terms, one of
which must be matched.
Q
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.
Note: This field displays when valid item
classifications have been set up for Routing Guide.

5.4.2 Modifying a Routing Guide

To modify a routing guide:
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
.

Configuring Cross-Application Logistics Components 165

Defining Outbound Constraints

3. The Routing Guide Details window displays in the work area.

4. Enter information in the applicable fields. Refer to Table 5–4 for field
value descriptions.
5. Choose .

5.4.2.1 Creating a Routing Guide Line

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, country, etc.).
To create a routing guide line:
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.

166 Configuration Guide

 Defining Outbound Constraints

Figure 5–2 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 5–5 for field
value descriptions.
5. Choose .

Configuring Cross-Application Logistics Components 167

Defining Outbound Constraints

Figure 5–3 Routing Guide Line Details Window

168 Configuration Guide

 Defining Outbound Constraints

Table 5–5 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:
Q
is to specify that a single value must be matched
Q
is in to specify a group of values, one of which must be matched.
Q
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
node, select the then enter one or more of the following conditions.
following attribute(s)
Country Select the country 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 Select this option if not shipping to a node within a
node and region, specific region and then select one or more of the
select the following following conditions.
attribute(s)
Country Select the country 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).

Configuring Cross-Application Logistics Components 169

Defining Outbound Constraints

Table 5–5 Routing Guide Line Details

Store# Select the store number(s).
And weight is in the You can match weight. For example, if you want
range: 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
range: packages 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 Number of containers.
in the range:
From Enter the minimum value.
To Enter the maximum value.
And if requested
carrier service code is
Carrier Service Code Select a carrier service code.
For more information about defining carrier services, see Section 5.4.2.1.1,
"Defining Carrier Services".
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.

170 Configuration Guide

 Defining Outbound Constraints

Table 5–5 Routing Guide Line Details

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.

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.

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

Configuring Cross-Application Logistics Components 171

Defining Outbound Constraints

You can use the Carrier Services panel for:

Q
Creating a Carrier Service
Q
Modifying a Carrier Service
Q
Deleting a Carrier Service

Creating a Carrier Service

To create a carrier service:
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 5–6 for field
value descriptions.
3. Choose .

172 Configuration Guide

 Defining Outbound Constraints

Table 5–6 Carrier Services

Field Description
Priority Enter a number to give this rule a relative importance.
When a shipment is compared to the routing guide
lines, there may be two carrier services that could be
used. This priority serves as a tie breaker. The carrier
service with the lowest number is used.
Carrier/Service Select the carrier or service code that is desired.
Break Bulk Node Select the break bulk node that is close to the buyer.
Contact Address This is used to specify the address information for the
carrier service's contact person. Click to change
the contact Address.

Modifying a Carrier Service

To modify a carrier service:
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 5–6
for field value descriptions.
3. Choose .

Deleting a Carrier Service

To modify a carrier service:
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 .

Configuring Cross-Application Logistics Components 173

Defining Outbound Constraints

5.4.2.2 Modifying a Routing Guide Line

To modify a routing guide line:
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 Table 5–5
for field value descriptions.
4. Choose .

5.4.2.3 Deleting a Routing Guide Line

To delete a Routing Guide Line:
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 .

5.4.3 Deleting a Routing Guide

To delete a routing guide:
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 .

174 Configuration Guide

 6
Configuring Cross-Application Payment
Components

You can configure the components used in 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:
Q
Defining Payment Types
Q
Defining Payment Rules

6.1 System Payment Processing Rules

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.

Configuring Cross-Application Payment Components 175

System Payment Processing Rules

To configure payment processing rules:

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 6–1 for field
value descriptions.

Table 6–1 System Payment Processing Rules Window

Field Description
Payment Rule
Use Enterprise of an Check this box to enable Payment Processing
Order (Instead of the Rules to be configured at the enterprise level.
Seller Organization) to
Determine Payment Note: This rule is only supported when using a
Processing Rules compatible PCA and not by the Console alone.

Draft Order
Enable Draft Order Check this box to enable payment processing for draft
Payment Processing orders.
This option is on by default.
Ignore Charge Request Check this box to ignore charge requests when
on Draft Order calculating the 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.

176 Configuration Guide

 Defining Payment Types

3. Choose .

6.2 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 Selling and Fulfillment Foundation are:
Q
CHECK
Q
CREDIT_CARD
Q
CUSTOMER_ACCOUNT
Q
OTHER
You can use the Payment Types branch for:
Q
Creating a Payment Type
Q
Modifying a Payment Type
Q
Deleting a Payment Type

6.2.1 Creating a Payment Type

To create a payment type:
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 6–2 for field
value descriptions.
4. Choose .

Configuring Cross-Application Payment Components 177

Defining Payment Types

Table 6–2 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

178 Configuration Guide

 Defining Payment Types

Table 6–2 Payment Type Details Pop-Up Window

Field Description
Charge Sequence Enter the preferred charge sequence for the payment
type, 0 being highest.
When defining payment types you can set the default
order in which payment types are charged. For
example, if the Seller organization uses gift certificates
and prefers to collect against the gift certificate and
then collect any remaining amount against a credit
card, you may configure a payment type of Gift
Certificate to have a charge sequence of 1 and a
payment type of Credit Card to have a charge
sequence of 2. For more information about charge
sequencing, see the Selling and Fulfillment
Foundation: Product Concepts Guide.
Charge Instead of Select this field if you want to create a charge request
Authorize for this 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 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.

Configuring Cross-Application Payment Components 179

Defining Payment Types

Table 6–2 Payment Type Details Pop-Up Window

Field Description
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,
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 Selling and Fulfillment
Foundation: Product Concepts Guide.
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.
Note: This flag is only applicable to Sales Order
document types.
Note: If the charge is not created from an
authorization, it is not taken into consideration for
consolidation.

180 Configuration Guide

 Defining Payment Types

Table 6–2 Payment Type Details Pop-Up Window

Field Description
Consolidation Window If you selected Charge Consolidation Allowed, enter
(hrs) the timeframe (in hours) for charges to be
consolidated within.
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 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 Select this field to allow refunds to the same payment
Payment Method method.
Refund To New Select this field to allow refunds to a new payment
Payment Method method.

Configuring Cross-Application Payment Components 181

Defining Payment Types

Table 6–2 Payment Type Details Pop-Up Window

Field Description
Refund To New If you selected ‘Refund To New Payment Method’
Payment Method of above, use this field to select a new payment type to
Payment Type use.
Only payment types in the STORED_VALUE_CARD or
OTHER payment type group are available.
Note: 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.
Note: 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, 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
Constraints has a 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 Choose ’Greater Than’ or ’Less Than’ from the
is 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
Type is valid.
Create Refund Select this option to create a refund fulfillment order
Fulfillment Order Using instead of creating a new payment method.
ItemID From the drop down menu select the Item ID of the
item to fulfill the refund.

182 Configuration Guide

 Defining Payment Types

Table 6–2 Payment Type Details Pop-Up Window

Field Description
UOM When you select the Item ID, the corresponding UOM
is populated.
Create Refund Select this option to create a refund payment and
Payment and Charge charge request when refunding to a new payment
Request method.
Create Refund Select this option to not create a refund charge
Payment and Wait for request. This also raises the Incomplete Payment
Payment Information Information event, if it is enabled.

6.2.2 Modifying a Payment Type

To modify a payment type:
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 6–2 for field
value descriptions.
4. Choose .

Configuring Cross-Application Payment Components 183

Defining Payment Rules

6.2.3 Deleting a Payment Type

To delete a payment type:
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 .

6.3 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:
Q
Creating a Payment Rule
Q
Modifying a Payment Rule
Q
Deleting a Payment Rule

6.3.1 Creating a Payment Rule

To create a payment rule:
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 6–3 for field
value descriptions.
4. Choose .

184 Configuration Guide

 Defining Payment Rules

Table 6–3 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.
Note: The PUBLISH_INVOICE_DETAIL event must be
configured and the Send Invoice time-triggered
transaction must be run for an invoice to be published.

Configuring Cross-Application Payment Components 185

Defining Payment Rules

Table 6–3 Payment Rule Pop-Up Window

Field Description
Collect Externally If checked, all the invoice details are published to an
Through Accounts external accounts receivable system. Any collections
Receivable performed outside of Selling and Fulfillment
Foundation need not be reported.
If unchecked, Selling and Fulfillment Foundation
handles all financial collections, provided you have
programmed the user exits to do so.
Note: 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 Select Deferred Credit On Return Required if an event
Return Required should be raised with the cancelled amount that was
not refunded when part of a pre-collected order is
cancelled.
Allow Immediate Select Allow Immediate Refund From Hold Amount if
Refund From Hold you want to instantly refund the credit amount from
Amount the pre-collected hold amount to the customer.
Note: 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 Select Ignore Payment Status For Purge if you want to
For Purge purge orders regardless of the payment status of the
orders.
Note: 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.

186 Configuration Guide

 Defining Payment Rules

Table 6–3 Payment Rule Pop-Up Window

Field Description
Customer Account Select Customer Account Maintained Internally if the
Maintained Internally payment processing for an account is handled from
within 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
Reauthorize on reauthorized each time the previous authorization
Expiration expires.
This rule is the default if Authorization Required is
enabled.
Use Charge Select Use Charge Transaction Request For
Transaction Request Authorization to trigger authorizations by charge
For Authorization transaction request identifiers instead of the order’s
book amount. Charge transaction request identifiers
represent an entity or group of entities in an order.
This is not supported if settlement is required.
Note: Authorize Before Scheduling And Reauthorize
On Expiration must be selected for Use Charge
Transaction Request For Authorization to be enabled.
Authorize Before Select this button if you want authorization to take
Scheduling and Delay place 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 For Release Date that you want an authorization for
Products product items to take place.
Hours Before Expected Enter the number of hours before Expected
Appointment Start Appointment Start Date that you want an
Date For Services authorization for provided and delivery services to
take place.

Configuring Cross-Application Payment Components 187

Defining Payment Rules

Table 6–3 Payment Rule Pop-Up Window

Field Description
Delay Authorization Select this button if you want authorization to take
Until place only before the Expected Release Date/Expected
Appointment Date.
Hours Before Expected Enter the number of hours before the Expected
Release Date For Release Date that you want an authorization for
Products product items to take place.
Hours Before Expected Enter the number of hours before Expected
Appointment Start Appointment Start Date that you want an
Date For Services authorization for provided and delivery services to
take place.

To further explain the business impact of authorization options,

Table 6–4, "Standard and Delayed Reauthorization", 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 6–4 Standard and Delayed Reauthorization

Configuration Before Order is Before Order is <n> Hours
Options Scheduled Scheduled and Each Before
Time Authorization Release
Expires
Authorize
Before
Scheduling and
Reauthorize on AUTH AUTH...AUTH...AUTH... AUTH
Expiration
(standard)

188 Configuration Guide

 Defining Payment Rules

Table 6–4 Standard and Delayed Reauthorization

Configuration Before Order is Before Order is <n> Hours
Options Scheduled Scheduled and Each Before
Time Authorization Release
Expires
Authorize
Before
Scheduling and
Delay
Reauthorization AUTH AUTH
Until <n> Hours
Before Ship
Date

Delay
Authorization
Until <n> Hours
Before Ship AUTH
Date

6.3.2 Modifying a Payment Rule

To modify a payment rule:
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 6–3 for field
value descriptions.
4. Choose .

Configuring Cross-Application Payment Components 189

Defining Payment Rules

6.3.3 Deleting a Payment Rule

To delete a payment rule:
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 .

190 Configuration Guide

 7
Configuring Cross-Application Pricing
Components

Note: For the Selling and Fulfillment Foundation Release

9.0:
Q
The pricing functionality described in Section 7.1,
"Legacy Pricing Service", has been deprecated.
Q
The new pricing functionality for the Selling and
Fulfillment Foundation, Release 9.0 is described in
Section 7.2, "Pricing Service".
See the Business Center: Pricing Administration Guide
and the Selling and Fulfillment Foundation: Pricing
Concepts Guide for information about these new
features.

7.1 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
Selling and Fulfillment Foundation. From the tree in the Distributed Order

Configuring Cross-Application Pricing Components 191

Legacy Pricing Service

Management application rules side panel, choose Cross Application >

Financials. You can use the Financials branch for:
Q
Defining Pricing by Region
Q
Defining Price Programs and Price Lists

7.1.1 Defining Pricing by Region

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 Selling and
Fulfillment Foundation: Application Platform Configuration Guide.
To define pricing by region:
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 7–1 for field
value descriptions.
3. Choose .

192 Configuration Guide

 Legacy Pricing Service

Table 7–1 Region Usage For Pricing Pop-Up Window

Field Description
Schema for Product Select the region schema you want to use for the
being shipped organization’s product item pricing.
Schema for Product Select the region schema you want to use for the
being 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.

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

Configuring Cross-Application Pricing Components 193

Legacy Pricing Service

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.

Important: 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 Selling and Fulfillment Foundation: Application Platform
Configuration Guide.

Use the Price Programs and Price Lists branches for:

Q
Creating a Price List
Q
Adding Items to a Price List
Q
Modifying an Item Price List
Q
Deleting an Item Price List
Q
Modifying a Price List
Q
Deleting a Price List
Q
Creating a Price Program
Q
Modifying a Price Program
Q
Deleting a Price Program

194 Configuration Guide

 Legacy Pricing Service

Q
Adding a New Price List to a Price Program
Q
Modifying a Price List
Q
Deleting a Price List in a Price Program

7.1.2.1 Creating a Price List

To create a price list:
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 7–2 for field
values.
4. Choose .

Configuring Cross-Application Pricing Components 195

Legacy Pricing Service

Table 7–2 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 Select Delivery Service Price List if you want to create
List a price list for delivery services.
Provided Service Price Select Provided Service Price List if you want to create
List a price list for provided services.

You can use the Price List Details window for:

Q
Adding Items to a Price List
Q
Modifying an Item Price List
Q
Deleting an Item Price List

Adding Items to a Price List

To add items to a price list:
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 7–3 for field
value descriptions.
3. Choose .

196 Configuration Guide

 Legacy Pricing Service

Configuring Cross-Application Pricing Components 197

Legacy Pricing Service

Modifying an Item Price List

Table 7–3 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
Range Once the item is created choose to add item price
set details.

Choose to modify a detail.

Choose to delete a detail.

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 Section 7.1.1, "Defining
Pricing by Region".
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:

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

198 Configuration Guide

 Legacy Pricing Service

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

Deleting an Item Price List

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

7.1.2.2 Modifying a Price List

To modify a price list:
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 .

7.1.2.3 Deleting a Price List

To delete a price list:
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 .

Configuring Cross-Application Pricing Components 199

Legacy Pricing Service

7.1.2.4 Creating a Price Program

To create a price program:
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 .

200 Configuration Guide

 Legacy Pricing Service

You can use the Price Program Details window for:

Q
Adding a New Price List to a Price Program
Q
Deleting a Price List in a Price Program

Adding a New Price List to a Price Program

To add a new price list to a price program:
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

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

Configuring Cross-Application Pricing Components 201

Pricing Service

7.1.2.5 Modifying a Price Program

To modify a price program:
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 .

7.1.2.6 Deleting a Price Program

To delete a price program:
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 .

7.2 Pricing Service

You can configure the Pricing Service that is being used throughout
Selling and Fulfillment Foundation. From the tree in the Distributed Order
Management application rules side panel, choose Cross Application >
Financials. You can use the Financials branch for:
Q
Defining Region Schema for Selling
Q
Defining Pricing Organization Rules
Q
Defining Pricing Enterprise Rules

Note: For information about how to configure prices, see

Business Center: Pricing Administration Guide.

202 Configuration Guide

 Pricing Service

7.2.1 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
Section 8.1, "Defining Region Usage for Selling".

7.2.2 Defining Pricing Organization Rules

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:
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 7–4 for field
value descriptions.

Configuring Cross-Application Pricing Components 203

Pricing Service

3. Choose .

204 Configuration Guide

 Pricing Service

Table 7–4 Pricing Organization Rules: Sales Order Window

Field Description
Run promotions pricing rules Select this check box if you want to run
(Item quantity rule) in item quantity pricing rules during the
getItemPrice API 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 distribute item-level pricing rule or coupon
same item adjustments across order lines that contain
the same item.
Unit price precision Calculated prices are rounded to a fixed
number of decimal places.
Enter the number of decimal places to be
applied to unit prices. By default, unit price
precision is six decimal places.
Sterling Distributed Order Management
supports a maximum of six decimal places.
Total price precision Calculated prices are rounded to a fixed
number of decimal places.
Enter the number of decimal places to be
applied to total prices. By default, total
price precision is two decimal places.
Sterling Distributed Order Management
supports a maximum of two decimal
places.
Rules For 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.

Configuring Cross-Application Pricing Components 205

Pricing Service

Table 7–4 Pricing Organization Rules: Sales Order Window

Field Description
Maintain Effective Dates On Price Select this check box if you want to display
List Lines the 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 Select this check box if you want the ability
List Lines to 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 Select the charge category to use for
Quantity 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 Select the charge category to use for
Total applying surcharges for the Ship Order
Total pricing rule.
Charge Category For Shipping Select the charge category to use for
Surcharge applying surcharges for the Shipping
Surcharge pricing rule.
Charge Category To Be Used For Applying Discount For Each Pricing Rule Type
Charge Category For Combination Select the charge category to use for
applying discounts for the Combination
pricing rule.

206 Configuration Guide

 Pricing Service

Table 7–4 Pricing Organization Rules: Sales Order Window

Field Description
Charge Category For Item Select the charge category to use for
Quantity 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 Select the charge category to use for
Total applying discounts for the Ship Order Total
pricing rule.
Charge Category For Shipping Select the charge category to use for
Surcharge applying 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 Select the charge category to use for
Total 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 Select the charge category to use for
Quantity applying discount coupons for the Item
Quantity pricing rule.

7.2.3 Defining Pricing Enterprise Rules

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:
1. From the tree in the application rules side panel, choose Cross
Application > Financials > Pricing Enterprise Rules. The Pricing
Enterprise Rules window displays.

Configuring Cross-Application Pricing Components 207

Pricing Service

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

Table 7–5 Pricing Enterprise Rules Window

Field Description
Use The Price List Select this check box if you want to use the price list
Assigned To The directly assigned to the customer or, if this price list is
Closest Customer In not available, use the price list assigned to the closest
The Hierarchy 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 To The Exact assigned to the exact region or, if this price list is not
Or Closest Region In available, use the price list assigned to the closest
The Region Hierarchy region in the region 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
Assignments Of A Price assigned to a customer, if it exists, rather than the
List If Direct price list assigned to customer attributes.
Assignments 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.

208 Configuration Guide

 8
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. You can use the Customer branch for:
Q
Defining Region Usage for Selling
Q
Defining Customer Rules
Q
Defining Customer Definitions
Q
Defining Contact Types
Q
Defining Customer Entitlements

8.1 Defining Region Usage for Selling

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.

Configuring Cross-Application Customer Components 209

Defining Region Usage for Selling

For more information about region schemas, see the Selling and
Fulfillment Foundation: Application Platform Configuration Guide.
To define a region usage for selling:
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
Section 7.1.1, "Defining Pricing by Region".

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 8–1
for the field value description.

Table 8–1 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 8–2 for field
value descriptions.

210 Configuration Guide

 Defining Customer Rules

5. Choose .

Table 8–2 Region Schema Details Pop-Up Window

Field Description
Region Schema Name Enter the name of the region schema.
Country Enter a country code.

To search for a country code, choose . In the

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

8.2 Defining Customer Rules

You can use the Customer Rules branch for:
Q
Defining Customer Classifications
Q
Defining Additional Customer Rules

Configuring Cross-Application Customer Components 211

Defining Customer Rules

8.2.1 Defining Customer Classifications

You can configure the customer classification codes to associate with a
customer identification master. For more information about creating a
customer identification master, see Section 8.3, "Defining Customer
Definitions".
You can use the Customer Classification branch for:
Q
Creating a Customer Classification
Q
Modifying a Customer Classification
Q
Deleting a Customer Classification

8.2.1.1 Creating a Customer Classification

To create a customer classification:
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.

212 Configuration Guide

 Defining Customer Rules

7. Click .

8.2.1.2 Modifying a Customer Classification

To modify a customer classification:
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 .

8.2.1.3 Deleting a Customer Classification

To delete a customer classification:
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 .

8.2.2 Defining Additional Customer Rules

To define additional customer rules:
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.

Configuring Cross-Application Customer Components 213

Defining Customer Definitions

3. In the Service Slot Group Used By Customer For Slot Preference 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. Click .

8.3 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 Selling and Fulfillment Foundation.

214 Configuration Guide

 Defining Customer Definitions

You can use the Customer Definition branch for:

Q
Creating a Customer Definition
Q
Modifying a Customer Definition
Q
Deleting a Customer Definition

8.3.1 Creating a Customer Definition

To create a customer definition:
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.

Configuring Cross-Application Customer Components 215

Defining Customer Definitions

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

216 Configuration Guide

 Defining Customer Definitions

Table 8–3 Customer Pop-Up Window

Field Description
This Customer Is a Select this if the customer with whom you trade
Business 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 Select this if the customer with whom you trade
Consumer 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 Choose this and select the applicable Buyer if you
Organization want to associate the customer ID with an existing
Buyer organization.
Create A New Choose this if you want to create a new organization
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 When creating a new organization, choose this if the
Also a Ship To organization also functions as a receiving node.
DUNS Number If you chose Create Buyer Organization, enter the
Buyer’s DUNS number.
Account Number With If you chose Create Buyer Organization, enter the
Hub Buyer’s account number with the Hub organization.
Locale If you chose Create Buyer Organization, select the
Buyer’s locale.
Identifies This Enter the customer assigned Vendor Identifier with
Enterprise As which the customer identifies this Enterprise.
Send Functional Check this box if a functional acknowledgment must
Acknowledgement be sent to the customer.

Configuring Cross-Application Customer Components 217

Defining Customer Definitions

Table 8–3 Customer Pop-Up Window

Field Description
Functional Enter the number of hours taken by the supplier to
Acknowledgement send the functional acknowledgement.
Time (Hrs)
Send Commitment Check this box if a commitment must be sent to the
customer.
Commitment Time Enter the number of hours taken by the supplier to
(Hrs) send the commitment.
Send ASN Check this box if an Advanced Shipment Notice (ASN)
must be sent to the customer.
Consumer Address Details
Address Enter the consumer’s name and shipping address
here.
Contact Info Enter the consumer’s telephone, cell phone, fax
number, and e-mail address.

8.3.2 Modifying a Customer Definition

To modify a customer definition:
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.
You can use the customer window for:
Q
Defining the Customer’s Primary Information
Q
Defining the Customer’s Service Preferences
Q
Defining a Customer’s Scheduling Preferences

218 Configuration Guide

 Defining Customer Definitions

8.3.2.1 Defining the Customer’s Primary Information

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

8.3.2.1.1 If the Customer Is a Consumer

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

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

Configuring Cross-Application Customer Components 219

Defining Customer Definitions

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.

8.3.2.2 Defining the Customer’s Service Preferences

Customers defined in Selling and Fulfillment Foundation can specify slot
preferences for deliveries.

220 Configuration Guide

 Defining Customer Definitions

Table 8–4 Service Preferences Tab

Field Description
Consider Supplemental Check this if you want to consider supplemental
Capacity While capacity by default when planning an appointment for
Planning Appointment this customer.
By Default
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 Check this if only the slots specified in the Slot
Used Preferences table can be used when planning an
appointment for this customer.
Customer Prefers Check this if the slots specified in the Slot Preferences
Specific Slots (Other table preferred slot table
Slots Can Be Used)
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.

Configuring Cross-Application Customer Components 221

Defining Customer Definitions

8.3.2.3 Answering a Customer’s Address Questions

Answering address questions for a customer populates answers for
address questions the next time this customer places an order. From the
Service Preferences tab, select the Address Questions tab. If configured,
the address questions configured for the Enterprise appear.

8.3.2.4 Defining a Customer’s Scheduling Preferences

You can define scheduling constraints for a specific customer by
specifying these scheduling preferences. Refer to Table 8–5 for more
information.

Table 8–5 Scheduling Preferences Tab

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 Check this box to ensure that order lines are shipped
Node from a single node. This is disabled if the Ship from
Single Node checkbox is checked.
Ship Complete Check this box to ensure that orders are shipped
complete. This automatically checks the Line Ship
Complete checkbox.

222 Configuration Guide

 Defining Customer Definitions

Table 8–5 Scheduling Preferences Tab

Field Description
Line Ship Complete Check this box to ensure that order lines are shipped
complete. This is disabled if the Ship Complete
checkbox is checked.
Inventory Controls
Cancel Order For Check this box to cancel the backordered quantity in
Inventory Shortage the event of inventory shortage.
Allow Item Check this box to allow item substitution if inventory
Substitution If for the selected item is not available.
Inventory Is Not
Available
Sourcing Controls
Allow Scheduling Check this box to allow scheduling against the node
Against The Node That that requires a drop-shipped chained order to be
Requires Drop Ship created.
Chained Order
Creation

Note: Constraints passed at the order level override

customer scheduling preferences.

8.3.2.5 Defining Customer Contacts

You can define multiple contacts for each customer. These contacts
represent individuals at a customer location. Please refer to Table 8–6 for
more information.

Table 8–6 Customer Contacts Tab

Field Definition
Customer Contact ID The ID of the customer contact.
Last Name The contact’s last name.

Configuring Cross-Application Customer Components 223

Defining Customer Definitions

Table 8–6 Customer Contacts Tab

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

8.3.2.5.1 Defining Customer Contact Information

To define customer contact information:
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.
4. Enter information in the applicable fields. Refer to Table 8–7 for field
values.
5. Choose OK.

224 Configuration Guide

 Defining Customer Definitions

Table 8–7 Customer Contact Info

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.

Configuring Cross-Application Customer Components 225

Defining Customer Definitions

Table 8–7 Customer Contact Info

Field Description
Phone
Day Time Phone Enter the contact’s day time phone number.
Evening Phone Enter the contact’s evening phone number.
Cell Phone Enter the contact’s cellular phone number.
Fax Enter the contact’s fax number.
Email Enter the contact’s email address.
User ID Enter the contact’s user ID.
Date Of Birth Enter the contact’s date of birth.
Spouse Date Of Birth Enter the contact’s spouse’s date of birth.
Wedding Anniversary Enter the contact’s wedding anniversary.
Customer Contact ID Enter the contact’s customer contact ID.

8.3.2.5.2 Defining Limits for Customer Contacts

To define limits for customer contacts:
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 Table 8–8 for field
value descriptions.
5. Choose OK.

226 Configuration Guide

 Defining Customer Definitions

Table 8–8 Limits

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 to the applicable fields. For more
information about defining the currency, see
Section 3.5.6.1, "Currency Details".
Approver User ID Enter the user ID of the primary approver.
Approver Proxy Enter the proxy for the approver.

8.3.2.5.3 Defining Additional Contact Addresses

1. From the Customer Definition screen, select the Contacts tab. The
Customer Contact Info screen displays.
2. Choose to add an additional customer contact information. The
Customer Contact Info screen displays.
3. Select the Additional Addresses tab.

Configuring Cross-Application Customer Components 227

Defining Customer Definitions

4. Refer to Step 2 in section Section 8.3.2.6, "Defining Additional

Addresses" for information about defining additional addresses.

8.3.2.6 Defining Additional Addresses

You can define multiple additional or alternative addresses for a customer
or contact. See Table 8–9 for field value descriptions.

Table 8–9 Additional Addresses Tab

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:

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 Table 8–10 for field
values.
4. Choose to enter the additional address.
5. Choose OK.

228 Configuration Guide

 Defining Customer Definitions

Table 8–10 Defining an Additional Address

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.

Configuring Cross-Application Customer Components 229

Defining Contact Types

Table 8–10 Defining an Additional Address

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

8.3.3 Deleting a Customer Definition

To delete a customer definition:
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 .

8.4 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, see
Section 8.3, "Defining Customer Definitions".
You can use the Contact Types branch for:
Q
Creating a Contact Type
Q
Modifying a Contact Type
Q
Deleting a Contact Type

8.4.1 Creating a Contact Type

To create a contact type:
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.

230 Configuration Guide

 Defining Contact Types

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 .

8.4.2 Modifying a Contact Type

To modify a contact type:
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 .

Configuring Cross-Application Customer Components 231

Defining Customer Entitlements

8.4.3 Deleting a Contact Type

To delete a contact type:
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 .

8.5 Defining Customer Entitlements

You can define a customer entitlement strategy for the enterprise by
specifying rules for enforcing customer entitlements.
To define a customer entitlement strategy:
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 Table 8–11 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 .

232 Configuration Guide

 Defining Customer Entitlements

Table 8–11 Customer Entitlement Strategy

Field Description
Enforce Customer Select the type of customer entitlement strategy you
Entitlement Based On want to use for enforcing customer entitlements:
You can choose from the following options:
Q
No Item Entitlement - Customers can access all
items regardless of customer entitlements and
pricelists.
Q
Item Entitlement Rules Assigned to Customer -
Customers can access only the items that are
assigned to the customer in customer
entitlements.
Q
Pricelists Assigned to Customer - Customers can
access only the items that are assigned to the
customer in pricelists.
Q
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.

Configuring Cross-Application Customer Components 233

Defining Customer Entitlements

234 Configuration Guide

 9
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 for
Q
Defining Order Types
Q
Defining Order Sources
Q
Defining External References for the Order Level
Q
Defining External References for the Order Line Level
Q
Defining Order Address Types
Q
Defining Line Types
Q
Defining Other Attributes

9.1 Defining Order Types

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:
Q
Creating an Order Type
Q
Modifying an Order Type
Q
Deleting an Order Type

Configuring a Document’s Attributes 235

Defining Order Types

9.1.1 Creating an Order Type

To create an order type:
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.

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 .

9.1.2 Modifying an Order Type

To modify a order type:
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.

236 Configuration Guide

 Defining Order Sources

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 .

9.1.3 Deleting an Order Type

To delete a order type:
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 .

9.2 Defining Order Sources

You can define codes for order sources that appear on a document type.
This code has no application logic associated with it and can be set up as
per your business practices.
You can use the Order Sources tab for:
Q
Creating an Order Source
Q
Modifying an Order Source
Q
Deleting an Order Source

9.2.1 Creating an Order Source

To create an order source:
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.

Configuring a Document’s Attributes 237

Defining Order Sources

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 .

9.2.2 Modifying an Order Source

To modify a order source:
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 .

238 Configuration Guide

 Defining External References for the Order Level

9.2.3 Deleting an Order Source

To delete a order source:
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 .

9.3 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 for:
Q
Creating an External Reference for the Order Header Level
Q
Modifying an External Reference for the Order Header Level
Q
Deleting an External Reference for the Order Header Level

9.3.1 Creating an External Reference for the Order Header

Level
To create an order reference for the order level:
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.

Configuring a Document’s Attributes 239

Defining External References for the Order Level

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 .

9.3.2 Modifying an External Reference for the Order

Header Level
To modify an external reference for the order level:
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 .

240 Configuration Guide

 Defining External References for the Order Line Level

9.3.3 Deleting an External Reference for the Order Header

Level
To delete an external reference for the order level:
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 .

9.4 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 for:
Q
Creating an External Reference for the Order Line Level
Q
Modifying an External Reference for the Order Line Level
Q
Deleting an External Reference for the Order Line Level

9.4.1 Creating an External Reference for the Order Line

Level
To create an order reference for the order line level:
1. From the tree in the application rules side panel, choose Document
Specific > (Document Type) > Order Attributes. The Order Attributes
window displays in the work area.
2. Choose the Order References tab.
3. From the Order Line External References list choose . The External
Reference Details pop-up window displays.

Configuring a Document’s Attributes 241

Defining External References for the Order Line Level

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 .

9.4.2 Modifying an External Reference for the Order Line

Level
To modify an external reference for the order line level:
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 .

242 Configuration Guide

 Defining Order Address Types

9.4.3 Deleting an External Reference for the Order Line

Level
To delete an external reference for the order level:
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 .

9.5 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 for:
Q
Creating an Order Address Type
Q
Modifying an Order Address Type
Q
Deleting an Order Address Type

9.5.1 Creating an Order Address Type

To create an order address type:
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.

Configuring a Document’s Attributes 243

Defining Order Address Types

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 .

9.5.2 Modifying an Order Address Type

To modify a order address type:
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.
6. Choose .

244 Configuration Guide

 Defining Line Types

9.5.3 Deleting an Order Address Type

To delete a order address type:
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 .

9.6 Defining Line Types

You can define codes and for line types that appear on a document type.
You can use the Line Types tab for:
Q
Creating a Line Type
Q
Modifying a Line Type
Q
Deleting a Line Type

9.6.1 Creating a Line Type

To create a line type:
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 .

Configuring a Document’s Attributes 245

Defining Line Types

9.6.2 Modifying a Line Type

To modify a line type:
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 .

9.6.3 Deleting a Line Type

To delete a line type:
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 .

246 Configuration Guide

 Defining Other Attributes

9.7 Defining Other Attributes

You can define other attributes that appear on the document type.
You can use the Others tab for:
Q
Generating a Prime Line Number for a New Line from a
Pre-Configured Number

9.7.1 Generating a Prime Line Number for a New Line

from a Pre-Configured Number
Generating a prime line number for a new line from a pre-configured
number prevents conflicts between prime line numbers in Selling and
Fulfillment Foundation and in an external system when order
synchronization occurs.
To specify a pre-configured starting number:
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 .

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

Configuring a Document’s Attributes 247

Defining Other Attributes

248 Configuration Guide

 10
Configuring a Document’s Order Validation

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:
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 10–1 for
field value descriptions.
3. Choose .

Configuring a Document’s Order Validation 249

250 Configuration Guide
Table 10–1 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:
Q
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.
Q
Same As Enterprise - The system validates the
Seller on the order is the Enterprise.
Q
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 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.

Configuring a Document’s Order Validation 251

 Table 10–1 Order Validation Pop-Up Window
Field Description
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:
Q
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.
Q
Same As Enterprise - The system validates the
Buyer on the order is the Enterprise.
Q
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 Selling and
Fulfillment Foundation: Application Platform
Configuration Guide.
Q
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
Customer ID to validate that the customer ID on an order is defined
for the Enterprise.
Validate Vendor ID Select Validate Vendor ID if you want to validate that
the vendor ID on an order is defined for the
Enterprise.
Validate Item Select Validate Item if you want to validate that the
product items on the order belong to the Enterprises
catalog. Service items, on the other hand, always
need to exist within Selling and Fulfillment Foundation.

252 Configuration Guide

 11
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 Selling and Fulfillment Foundation are:
Q
PICK
Q
PACK
Q
SHIP
Q
GIFT
Q
ORDERING
Q
OTHER
You can use the Instruction Types branch for:
Q
Creating an Instruction Type
Q
Modifying an Instruction Type
Q
Deleting an Instruction Type

11.1 Creating an Instruction Type

To create an instruction type:
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.

Configuring a Document’s Instruction Types 253

Modifying an Instruction Type

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 .

11.2 Modifying an Instruction Type

To modify an instruction type:
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.

254 Configuration Guide

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

11.3 Deleting an Instruction Type

To delete an instruction type:
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 .

Configuring a Document’s Instruction Types 255

Deleting an Instruction Type

256 Configuration Guide

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

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

Q
Creating a Modification Reason
Q
Modifying a Modification Reason
Q
Deleting a Modification Reason

12.1 Creating a Modification Reason

To create a modification reason:
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.

Configuring a Document’s Modification Reasons 257

Creating a Modification Reason

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 Selling and Fulfillment
Foundation: Javadocs.

Note: If this modification reason is used for a

modification which does not reduce quantity, this flag is
not applicable.

Note: This field does not exist for Load Modification

Reasons.

7. Choose .

258 Configuration Guide

 Modifying a Modification Reason

12.2 Modifying a Modification Reason

To modify a modification reason:
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 Selling and Fulfillment
Foundation: Javadocs.

Note: If this modification reason is used for a

modification which does not reduce quantity, this flag is
not applicable.

Note: This field does not exist for Load Modification

Reasons.

6. Choose .

Configuring a Document’s Modification Reasons 259

Deleting a Modification Reason

12.3 Deleting a Modification Reason

To delete a modification reason:
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 .

260 Configuration Guide

 13
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 Selling and Fulfillment Foundation is:
Q
No Stock
You can use the Backorder Reasons branch for:
Q
Creating a Backorder Reason
Q
Modifying a Backorder Reason
Q
Deleting a Backorder Reason

13.1 Creating a Backorder Reason

To create a backorder reason:
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.

Configuring a Document’s Backorder Reasons 261

Modifying a Backorder Reason

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 .

13.2 Modifying a Backorder Reason

To modify a backorder reason:
1. From the tree in the application rules side panel, choose Document
Specific > (Document Type) > Backorder Reasons. The Backorder
Reasons window displays in the work area.
2. Select the applicable backorder reason and choose . The 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 .

262 Configuration Guide

 Deleting a Backorder Reason

13.3 Deleting a Backorder Reason

To delete a backorder reason:
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 .

Configuring a Document’s Backorder Reasons 263

Deleting a Backorder Reason

264 Configuration Guide

 14
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:
Q
Creating a Note Reason
Q
Modifying a Note Reason
Q
Deleting a Note Reason

14.1 Creating a Note Reason

To create a note reason:
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.

Configuring a Document’s Note Reasons 265

Creating a New Note Reason Based on an Existing One

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 .

14.2 Modifying a Note Reason

To modify a note reason:
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 .

14.3 Creating a New Note Reason Based on an

Existing One
To create a new note reason based on an existing one:
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 .

266 Configuration Guide

 Deleting a Note Reason

14.4 Deleting a Note Reason

To delete a note reason:
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.

Configuring a Document’s Note Reasons 267

Deleting a Note Reason

268 Configuration Guide

 15
Configuring a Quote Document’s Approval
Rule Violation Reason

You can define reason codes to explain why an approval rule has been
violated.
You can use the Approval Rule Violation Reasons branch in the
Distributed Order Management tree structure for:
Q
Creating an Approval Rule Violation Reason
Q
Modifying an Approval Rule Violation Reason
Q
Creating a New Approval Rule Violation Reason Based on an Existing
One
Q
Deleting an Approval Rule Violation Reason

15.1 Creating an Approval Rule Violation Reason

To create an approval rule violation reason:
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.

Configuring a Quote Document’s Approval Rule Violation Reason 269

Modifying an Approval Rule Violation Reason

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 .

15.2 Modifying an Approval Rule Violation

Reason
To modify an approval rule violation reason:
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. 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 .

270 Configuration Guide

 Deleting an Approval Rule Violation Reason

15.3 Creating a New Approval Rule Violation

Reason Based on an Existing One
To create a new approval rule violation reason based on an existing one:
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 .

15.4 Deleting an Approval Rule Violation Reason

To delete an approval rule violation reason:
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.

Configuring a Quote Document’s Approval Rule Violation Reason 271

Deleting an Approval Rule Violation Reason

272 Configuration Guide

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

16.1 Defining a Line Relationship Type

To create a line relationship type:
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.

Configuring a Document’s Line Relationship Type 273

Modifying a Line Relationship Type

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 .

16.2 Modifying a Line Relationship Type

To modify a line relationship type:
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.
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 .

274 Configuration Guide

 Creating a New Line Relationship Type Based on an Existing One

16.3 Creating a New Line Relationship Type

Based on an Existing One
To create a new line relationship type based on an exiting one.
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 .

16.3.1 Deleting a Line Relationship Type

To delete a line relationship type:
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.

Configuring a Document’s Line Relationship Type 275

Creating a New Line Relationship Type Based on an Existing One

276 Configuration Guide

 17
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:
Q
Creating a Lead Origin
Q
Modifying a Lead Origin
Q
Creating a New Lead Origin Based on an Existing One
Q
Deleting a Lead Origin

17.1 Creating a Lead Origin

To create a lead origin:
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.

Configuring an Opportunity Document’s Lead Origin 277

Modifying a Lead Origin

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 .

17.2 Modifying a Lead Origin

To modify a lead origin:
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 .

278 Configuration Guide

 Deleting a Lead Origin

17.3 Creating a New Lead Origin Based on an

Existing One
To create a new lead origin based on an existing one:
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 .

17.4 Deleting a Lead Origin

To delete a lead origin:
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.

Configuring an Opportunity Document’s Lead Origin 279

Deleting a Lead Origin

280 Configuration Guide

 18
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:
Q
Creating a Lost Reason
Q
Modifying a Lost Reason
Q
Creating a New Lost Reason Based on an Existing One
Q
Deleting a Lost Reason

18.1 Creating a Lost Reason

To create a lost reason:
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.

Configuring an Opportunity Document’s Lost Reason 281

Modifying a Lost Reason

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 .

18.2 Modifying a Lost Reason

To modify a lost reason:
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 .

282 Configuration Guide

 Deleting a Lost Reason

18.3 Creating a New Lost Reason Based on an

Existing One
To create a new lost reason based on an existing one:
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 .

18.4 Deleting a Lost Reason

To delete a lost reason:
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.

Configuring an Opportunity Document’s Lost Reason 283

Deleting a Lost Reason

284 Configuration Guide

 19
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:
Q
Fulfillment
Q
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:
Q
Fulfillment
Q
Inbound Logistics
If you are using the Reverse Logistics module, you can configure
modification components at the following process type levels:
Q
Fulfillment
Q
Logistics
Q
Receipt

Configuring a Document’s Modification Components 285

Defining Modification Rules

You can use the Order Modification branch for:

Q
Defining Modification Rules
Q
Defining Custom Modification Types
Q
Defining Modifications Impacting Pricing

19.1 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. Selling and Fulfillment Foundation supports
modification through the Console and APIs. It is critical for you to decide
which modifications are allowed for each modification type, modification
level, and status combination.

Important: 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 sales order 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. Selling and Fulfillment Foundation provides the ability to
perform modifications on specific attributes. An example of a
modification type is adding an order line to an order.
Modification level indicates the level at which a particular modification
type is carried out. These include the following levels:
Q
Header
Q
Line
Q
Release
Q
Release Line
Q
Negotiation

286 Configuration Guide

 Defining Modification Rules

Q
Negotiation Line
Q
Shipment
Q
Receipt
For a complete list of the system modification types and their
modification levels, see Appendix B, "Order Modification Types".
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.

Configuring a Document’s Modification Components 287

Defining Modification Rules

The following table defines the different settings you can apply to
modifications:

Table 19–1 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.
There are several scenarios to consider for the Allow, Disallow, and Ignore
settings:
Q
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.
Q
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.
Q
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.

288 Configuration Guide

 Defining Modification Rules

Note: 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 Selling and Fulfillment Foundation: Application Platform
Configuration Guide.

19.1.1 Changing Modification Rules

To change modification rules:
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.

Configuring a Document’s Modification Components 289

Defining Custom Modification Types

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 19–1 for field value
descriptions.

19.2 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

290 Configuration Guide

 Defining Custom Modification Types

the custom modification type for a given status. For more information
about modification types and rules see Section 19.1, "Defining
Modification Rules".
You can use the Order Modification Types branch for:
Q
Creating a Custom Modification Type
Q
Modifying a Custom Modification Type
Q
Deleting a Custom Modification Type

19.2.1 Creating a Custom Modification Type

To create a custom modification type:
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 19–2 for field value descriptions.
3. Choose . A pop-up warning you to sign out of the application for
changes to take place displays.

Configuring a Document’s Modification Components 291

Defining Custom Modification Types

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

292 Configuration Guide

 Defining Custom Modification Types

Table 19–2 Custom Modification Window

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 .

19.2.2 Modifying a Custom Modification Type

To modify a custom modification type:
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 19–2 for field
value descriptions.
4. Choose .

19.2.3 Deleting a Custom Modification Type

To delete a custom modification type:
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 .

Configuring a Document’s Modification Components 293

Defining Modifications Requiring Auditing

19.3 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 Selling and Fulfillment Foundation: Javadocs.

19.3.1 Adding/Removing a Modification Type for

Modifications Impacting Pricing
To specify whether a modification type has pricing impact:
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 .

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

294 Configuration Guide

 Defining Modifications Requiring Auditing

2. From the Modifications Requiring Auditing window, choose .

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

Configuring a Document’s Modification Components 295

Defining Modifications Requiring Auditing

296 Configuration Guide

 20
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 Selling and Fulfillment Foundation.
The following process types are defined in Selling and Fulfillment
Foundation for the order document types:
Q
Order Fulfillment
Q
Order Negotiation
Q
Outbound Shipment
You can configure the rules and components specific to an order
document’s fulfillment process type.
You can use process type configuration for:
Q
Defining Hold Types
Q
Defining Order Tags
Q
Defining Fulfillment Rules
Q
Defining Approval Plans for Quotes
Q
Defining Process Type Details
Q
Process Type Pipeline Configuration
Q
Defining Transaction Rules
Q
Defining Status Inventory Types

Configuring an Order Document’s Fulfillment-Specific Components 297

Defining Hold Types

Q
Defining Quote Rules
Q
Defining Monitoring Components
Q
Defining Monitoring Events
Q
Defining Transaction Dependencies

20.1 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 Selling and Fulfillment Foundation:
Application Platform Configuration Guide.
You can use the Hold Types branch in the Applications Manager for:
Q
Creating a Hold Type
Q
Creating an Order Line Level Hold Type
Q
Deleting a Hold Type

20.1.1 Creating a Hold Type

Hold types can be created at either the order or order line level.
Selecting Hold Types from the application rules side panel displays the
Order Hold Types screen.

298 Configuration Guide

 Defining Hold Types

Figure 20–1 Order Hold Types Screen

This screen provides a list of previously created holds and their

associated level.

Configuring an Order Document’s Fulfillment-Specific Components 299

Defining Hold Types

20.1.1.1 Creating an Order Level Hold Type

To create an order level hold type:
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 20–1, Table 20–2 and Table 20–3.
6. Click .

300 Configuration Guide

 Defining Hold Types

Table 20–1 Hold Type Screen, Hold Creation tab

Field Description
Hold Created Automatically
On Draft Order Check this option to apply this hold type to all orders
Creation during draft order creation.
On Draft Order Check this option to apply this hold type to all orders
Confirmation during draft order confirmation.
On Order Creation Check this option to apply this hold type to all orders
during order creation.

Configuring an Order Document’s Fulfillment-Specific Components 301

Defining Hold Types

Table 20–1 Hold Type Screen, Hold Creation tab

Field Description
On Resolution Of The Check this option to apply this hold type during the
Hold Type resolution of another hold type. From the drop-down
list, select the hold type that, upon resolution, triggers
this hold type.
Note: 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
Selling and Fulfillment Foundation does not warn you
against.
When The Following Modification types that automatically apply this hold
Modifications Are type to an order.
Performed
Click to modify the list. In the subsequent pop-up
window:
Q
Use the right arrow to move the available
modification types that you wish to associate with
this hold type to the subscribed list.
Q
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 Select this radio button if the above conditions should
Satisfying The only be checked for orders satisfying a certain
Following Condition condition. Click to build or modify the condition
that is evaluated. For more information about using
the condition builder, see the 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 Selling and Fulfillment
Foundation: Extending the Condition Builder Guide .
Note: You can only select this option after the created
hold has been saved

302 Configuration Guide

 Defining Hold Types

Table 20–1 Hold Type Screen, Hold Creation tab

Field Description
Hold Created Manually
By Any User Select this radio button if all user groups can apply
this hold to an order.
By Users Who Belong Select this radio button if only users belonging to
To The Following certain user groups can apply this hold to an order.
Groups
Click to modify the list of user groups. In the
subsequent pop-up window:
Q
Use the right arrow to move the available user
groups that you wish to associate with this hold
type to the subscribed list.
Q
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.

Configuring an Order Document’s Fulfillment-Specific Components 303

Defining Hold Types

Table 20–2 Hold Type Screen, Hold Resolution tab

Field Description
Hold Resolved Automatically
The Following From the drop-down list, select the time-triggered
Time-Triggered transaction that will process the created holds.
Transaction Will
Process Created Holds
The Following From the drop-down list, select the time-triggered
Time-Triggered transaction that will process the rejected holds.
Transaction 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

304 Configuration Guide

 Defining Hold Types

Table 20–2 Hold Type Screen, Hold Resolution tab

Field Description
Any User Can Process Select this radio button if all user groups can process
This Hold this hold.
Users Belonging To The Select this radio button if only users belonging to
Following User Groups certain user groups can process this hold.
Can Process This Hold
Click to modify the list. In the subsequent pop-up
window:
Q
Use the right arrow to move the available user
groups that you wish to associate with this hold
type to the subscribed list.
Q
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.

Configuring an Order Document’s Fulfillment-Specific Components 305

Defining Hold Types

Table 20–3 Hold Type Screen, Hold Effects tab

Fields Description
The Following Transactions that are disallowed when this hold type is
Transactions Will Be applied to an order.
Stopped From
Processing Orders On Click to modify the list. In the subsequent pop-up
This Hold window:
Q
Use the right arrow to move the available
transactions that you wish to associate with this
hold type to the subscribed list.
Q
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
Modifications Are Not type is applied to an order.
Allowed For Orders On
This Hold Click to modify the list. In the subsequent pop-up
window:
Q
Use the right arrow to move the available
modification types that you wish to associate with
this hold type to the subscribed list.
Q
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.

20.1.1.2 Creating an Order Line Level Hold Type

To create an order line level hold type:
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 20–4, Table 20–5 and Table 20–6.

306 Configuration Guide

 Defining Hold Types

6. Click .

Table 20–4 Hold Type Screen, Hold Creation tab

Field Description
Hold Created Automatically
On Draft Order Check this option to apply this hold type to all lines on
Creation With Lines Or an order upon entering Draft Order Created status or
Adding Lines To Draft when a line is added to an order that is already in
Order 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 creation or addition to an order.
Order

Configuring an Order Document’s Fulfillment-Specific Components 307

Defining Hold Types

Table 20–4 Hold Type Screen, Hold Creation tab

Field Description
On Resolution Of The Check this option to apply this hold type during the
Hold Type resolution of another hold type. From the drop-down
list, select the hold type that, upon resolution, triggers
this hold type.
Note: 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
Selling and Fulfillment Foundation does not warn you
against.
When The Following Modification types that automatically apply this hold
Modifications Are type to an order.
Performed
Click to modify the list. In the subsequent pop-up
window:
Q
Use the right arrow to move the available
modification types that you wish to associate with
this hold type to the subscribed list.
Q
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
Satisfying The only be checked for order lines satisfying a certain
Following Condition condition. Click to build or modify the condition
that is evaluated. For more information about using
the condition builder, see the 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 Selling and Fulfillment
Foundation: Extending the Condition Builder Guide .
Note: You can only select this option after the created
hold has been saved.

308 Configuration Guide

 Defining Hold Types

Table 20–4 Hold Type Screen, Hold Creation tab

Field Description
Hold Created Manually
By Any User Select this radio button if all user groups can apply
this hold to an order.
By Users Who Belong Select this radio button if only users belonging to
To The Following certain user groups may apply this hold to an order.
Groups
Click to modify the list. In the subsequent pop-up
window:
Q
Use the right arrow to move the available user
groups that you wish to associate with this hold
type to the subscribed list.
Q
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.

Configuring an Order Document’s Fulfillment-Specific Components 309

Defining Hold Types

Table 20–5 Hold Type Screen, Hold Resolution tab

Field Description
Hold Resolved Automatically
The Following From the drop-down list, select the time-triggered
Time-Triggered transaction that will process the created holds.
Transaction Will
Process Created Holds
The Following From the drop-down list, select the time-triggered
Time-Triggered transaction that will process the rejected holds.
Transaction 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

310 Configuration Guide

 Defining Hold Types

Table 20–5 Hold Type Screen, Hold Resolution tab

Field Description
Any User Can Process Select this radio button if all user groups can process
This Hold this hold.
Users Belonging To The Select this radio button if only users belonging to
Following Groups Can certain user groups can process this hold.
Process This Hold
Click to modify the list. In the subsequent pop-up
window:
Q
Use the right arrow to move the available user
groups that you wish to associate with this hold
type to the subscribed list.
Q
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.

Configuring an Order Document’s Fulfillment-Specific Components 311

Defining Hold Types

Table 20–6 Hold Type Screen, Hold Effects tab

Fields Description
The Following Transactions that are disallowed when this hold type is
Transactions Will Be is applied to an order.
Stopped From
Processing Orders On Click to modify the list. In the subsequent pop-up
This Hold window:
Q
Use the right arrow to move the available
transactions that you wish to associate with this
hold type to the subscribed list.
Q
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
Modifications Are Not type is applied to an order.
Allowed For Orders On
This Hold Click to modify the list. In the subsequent pop-up
window:
Q
Use the right arrow to move the available
modification types that you wish to associate with
this hold type to the subscribed list.
Q
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.

20.1.2 Modifying a Hold Type

To modify a hold type:
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. Select the applicable hold type and click . The Hold Type pop-up
window displays. Enter information in the applicable fields. For field
value descriptions, see Table 20–1, Table 20–2 and Table 20–3 (for
Order Level Holds) or Table 20–4, Table 20–5, and Table 20–6 (for
Order Line Level Holds).

312 Configuration Guide

 Defining Order Tags

3. Click .

20.1.3 Deleting a Hold Type

To delete a hold type:
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. Select the applicable hold type and click .

20.2 Defining Order Tags

Order Tags enable the system to coordinate which order features are
available across multiple versions of PCAs when they are installed on
Selling and Fulfillment Foundation. This version awareness makes it
possible to schedule an order in one version of the Sterling Call Center
and 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:
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.

Configuring an Order Document’s Fulfillment-Specific Components 313

Defining Order Tags

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.

Table 20–7 contains field definitions.

Table 20–7 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 Selling and
Fulfillment Foundation: Application Platform
Configuration Guide for more information.)
Description Enter a description of this tag determination.

314 Configuration Guide

 Defining Order Tags

Table 20–7 Order Tag Detail window

Field Description
Create Order Tags When the Following Criterion Is Met
For Orders Satisfying
The Following Order If you click this check box, click to open the
Condition Condition Detail pop-up window and define the
Condition ID, Name, Group, and Value under which the
tag will be applied to an order that satisfies these
conditions.
For Orders Satisfying
The Following Order If you click this check box, click to open the
Line Condition Condition Detail pop-up window and define the
Condition ID, Name, Group, and Value under which the
tag will be applied to an order when an order line
satisfies these conditions.
When The Following
Modifications Are If you click this check box, click to open the
Performed Modification Type List pop-up window and enable
available Modification Types that define when this
condition will be applied to an order.

Following is an example of the Condition Detail pop-up window, followed

by Table 20–8, which describes the field definitions.

Configuring an Order Document’s Fulfillment-Specific Components 315

Defining Order Tags

Table 20–8 Condition Detail pop-up window

Condition Name Enter the name of the condition for this order tag to
be applied to the order.
Condition ID Enter the ID for this condition.
Condition Value This field contains information you enter in the
General Condition Builder. Click to display the
General Condition Builder.
The 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 20–9, which describes its fields.

316 Configuration Guide

 Defining Order Tags

Table 20–9 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 .

Configuring an Order Document’s Fulfillment-Specific Components 317

Defining Fulfillment Rules

20.2.1 Modifying an Order Tag

To modify an Order Tag:
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 20–7.
3. Click .

20.2.2 Deleting an Order Tag

To delete an Order Tag:
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 .

20.3 Defining Fulfillment Rules

You can define generic rules that Selling and Fulfillment Foundation uses
at order fulfillment time. These can affect order controls and
reservations.
To define fulfillment rules:
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 20–10 for
field value descriptions.
3. Click .

318 Configuration Guide

 Defining Fulfillment Rules

Table 20–10 Order Fulfillment window

Field Description
Order Controls
A line can be fulfilled Check this box if you want any quantity of an order
from a single node line to be shipped from the same ship node. Checking
only this enables the three checkboxes below to be
checked.
For lines with a firm pre-defined ship node:
When the line is Check this box if you want Selling and Fulfillment
partially backordered Foundation to automatically split partially backordered
or unscheduled, split it or unscheduled lines into two separate lines. This
into two separate lines allows the user to manually assign a new ship node for
so that a different ship the backordered portion of the line, so that the entire
node can be selected original order line may be shipped.
for the new line

Configuring an Order Document’s Fulfillment-Specific Components 319

Defining Fulfillment Rules

Table 20–10 Order Fulfillment window

Field Description
For lines without a firm pre-defined ship node:
When the line is Check this box if you want Selling and Fulfillment
partially backordered Foundation to automatically split partially backordered
or unscheduled, split it or unscheduled lines into two separate lines. This
into two separate lines allows the backordered portion of the line to be
so that the sourcing scheduled and potentially find a new ship node so that
logic can determine an the entire original order line may be shipped.
alternate ship node for
the new line
When a complete line Check this box if you want Selling and Fulfillment
is backordered, Foundation to automatically select the ship node that
backorder against the is highest in the sourcing priority, even if that ship
highest priority ship node is different from the ship node specified on the
node regardless of the order line in the event of a backorder of the complete
ship node present on order line.
the line.
When reserving or Check this box if you want Selling and Fulfillment
scheduling a product Foundation to use the node specified on the work
line, use node from the order when reserving or scheduling a product line, if
work order no ship node has been specified on the order line, or if
the node is non-firm. If a ship node is specified on the
order line, 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 Selling and Fulfillment
product line that is Foundation to allow order lines with delivery method
part of a work order, set to Delivery to be scheduled when an appointment
before appointment is has not yet been taken on the associated service work
taken. 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 Selling and Fulfillment
complete quantity of Foundation to try to promise the complete quantity of
an order line. an 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 Selling and Fulfillment Foundation reserves
quantity three of that order line.

320 Configuration Guide

 Defining Approval Plans for Quotes

Table 20–10 Order Fulfillment window

Field Description
Reservation is Check this box if you want Selling and Fulfillment
mandatory for the Foundation to always try to use reserved inventory for
complete quantity of the complete quantity of an order line. If it is not
an order line. possible, an error is thrown.
Inventory reservations Check this box if you want to allow orders to be
created for a specific promised against inventory that is reserved for a date
date are valid for all anterior to the requested ship date.
orders with the same
For example, if an order is placed with a requested
or future ship date.
ship date that is three days in the future, and if
reserved inventory is available two days in the future,
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 Check this box if you do not want Selling and
validation of Fulfillment Foundation to check for reservations for
reservations on order existing reserved quantity when a modification is
line modifications. 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, 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.

20.4 Defining Approval Plans for Quotes

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

Configuring an Order Document’s Fulfillment-Specific Components 321

Defining Approval Plans for Quotes

2. Enter information in the applicable fields. For field value descriptions,

refer to Table 20–11.

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

322 Configuration Guide

 Process Type Pipeline Configuration

3. Click .

20.5 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 Selling
and Fulfillment Foundation: Application Platform Configuration Guide.

20.6 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:
Q
Pipelines
Q
Transactions
Q
Statuses
Q
Conditions
Q
Actions
Q
Services
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 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

Configuring an Order Document’s Fulfillment-Specific Components 323

Process Type Pipeline Configuration

organization may also specify unique processes for each participating

Enterprise.

20.6.1 Defining Pipeline Determination

Pipeline determination is used to set up conditions that affect which
pipeline is used during the start of the business process workflow. For
example, an organization deals with sales orders that sometimes contain
hazardous materials. They have two separate pipelines, one in which
orders with order lines without any hazardous materials go through and
one in which orders with order lines containing hazardous materials must
go through for inspection before continuing through the order process.
The organization uses pipeline determination to set up a condition that
determines whether or not order lines contain hazardous materials and
sends the order line down the correct pipeline.
When you expand the Pipeline Determination branch, the components
displayed depends on what role you are logged in as. If you are logged in
as a Hub role, the Hub Rule displays. If you are logged in as an
Enterprise role, both the Hub Rule and My Rule components display.
Double-click on the applicable node to display the pipeline determination
rules.

Note: If you are logged in as an Enterprise role, the Hub

Rule screen is grayed out and cannot be modified.

Drag conditions and pipelines into the work area to construct pipeline
determination rules. A single pipeline or condition must be the root.
Conditions cannot link back to an earlier component in the chain and a
pipeline cannot be linked to twice.

Note: When configuring pipeline determination for an

order document type pipeline, please note that pipeline
determination is only considered when adding a line or
creating an order. When changes are made to draft orders
pipeline determination does not occur.

324 Configuration Guide

 Process Type Pipeline Configuration

20.6.1.1 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 Appendix C,
"Condition Builder Attributes".

20.6.2 Pipelines
For more information about configuring pipelines, see the Selling and
Fulfillment Foundation: Application Platform Configuration Guide.
To view the order fulfillment pipeline details:
1. From the tree in the application rules side panel, choose Document
Specific > (Document Type) > Fulfillment > Fulfillment Process
Model. The Order Fulfillment window displays.

Configuring an Order Document’s Fulfillment-Specific Components 325

Process Type Pipeline Configuration

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

20.6.3 Transactions
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 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 Selling and Fulfillment
Foundation: Application Platform Configuration Guide.

326 Configuration Guide

 Process Type Pipeline Configuration

To view the transaction details for an order fulfillment pipeline:

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

Configuring an Order Document’s Fulfillment-Specific Components 327

Process Type Pipeline Configuration

Table 20–12 Order Fulfillment Pipeline - Transactions Tab Window

Field Description
Chained Order Create This transaction represents a point in the pipeline
where a chained order is created.
Change Order This transaction represents any modifications that may
be made to an order.
Change Order Release This transaction represents any modifications that may
be made to an order release.
Change Schedule This transaction represents any modifications that may
be made to the scheduling determinations for an order
or order line.
Change Status This transaction represents any modifications that may
be made involving an order or order line’s status.
Close Order This transaction represents an order being closed and
archived in the system.
Confirm Draft Order This transaction represents a draft order is manually
confirmed and considered an actual order in the
system.
Consolidate To This transaction the process of finding a shipment into
Shipment 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 This transaction represents the advanced set of
Monitor 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 This transaction represents the process of creating a
Shipment shipment.
Order Monitor This transaction represents the basic set of parameters
used to monitor orders in the system.

328 Configuration Guide

 Process Type Pipeline Configuration

Table 20–12 Order Fulfillment Pipeline - Transactions Tab Window

Field Description
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.
Remove Order From This transaction represents the process of removing an
Shipment order from an existing shipment. This transaction
internally invokes the confirmShipment API. See the
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.

Configuring an Order Document’s Fulfillment-Specific Components 329

Process Type Pipeline Configuration

Table 20–12 Order Fulfillment Pipeline - Transactions Tab Window

Field Description
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 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 Selling and Fulfillment Foundation:
Javadocs for more information.
Start Negotiation - This transaction represents the process of initiating
Order the negotiation process with the Buyer on an order.
Synchronize Task This transaction represents the process of
Queue 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
Listener order completion.

20.6.4 Statuses
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 Selling and Fulfillment
Foundation: Application Platform Configuration Guide.

330 Configuration Guide

 Process Type Pipeline Configuration

To view the status details of an order fulfillment pipeline:

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 Statuses tab window displays.
For more information about creating and modifying statuses, see the
Selling and Fulfillment Foundation: Application Platform Configuration
Guide.

Configuring an Order Document’s Fulfillment-Specific Components 331

Process Type Pipeline Configuration

Table 20–13 Order Fulfillment Pipeline - Statuses Tab Window

Field Description
Draft Order Created This indicates that a draft order has been created.
Created This indicates that an order has been created.
Reserved This indicates the order has been created, but it is not
ready to schedule yet.
Being Negotiated This indicates that the order is undergoing the
negotiation process with the Buyer on the order.
Accepted This indicates that an order has been manually
accepted.
Backordered This indicates that an order is backordered until
sufficient inventory is available.
Unscheduled This indicates that the order has been removed from
Scheduled status and any inventory that has been
reserved for the order at the scheduled node(s) is
canceled.
Backordered From This indicates that the order has been created and
Node 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 This indicates that the wave has been printed for
Order Creation picking.
Chained Order Created This indicates that a chained order must be created
and sent to the applicable node.
Procurement PO This indicates that a procurement purchase order has
Created been created.
Procurement PO This indicates that a procurement purchase order has
Shipped been shipped.
Procurement TO This indicates that a procurement transfer order has
Created been created.
Procurement TO This indicates that a procurement transfer order has
Shipped been shipped.
Work Order Created This indicates that a work order has been created.

332 Configuration Guide

 Process Type Pipeline Configuration

Table 20–13 Order Fulfillment Pipeline - Statuses Tab Window

Field Description
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 This indicates that the order must interface with the
Interface 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.
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.

20.6.5 Conditions
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 Selling and Fulfillment
Foundation. You can use these attributes in any combination or you can

Configuring an Order Document’s Fulfillment-Specific Components 333

Process Type Pipeline Configuration

create conditions that run the appropriate application logic for specific
circumstances.
For more information about conditions, see the Selling and Fulfillment
Foundation: Application Platform Configuration Guide.
To view the condition details of an order fulfillment pipeline:
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.
For more information about creating and modifying conditions, see the
Selling and Fulfillment Foundation: Application Platform Configuration
Guide.

334 Configuration Guide

 Defining Transaction Rules

Table 20–14 Order Fulfillment Pipeline - Conditions Tab Window

Field Description
Conditions Displays conditions that are specific to the order
fulfillment pipeline, if any.

20.6.6 Actions
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 Selling and Fulfillment
Foundation: Application Platform Configuration Guide.
To view the action details of an order fulfillment pipeline:
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.
For more information about creating and modifying actions, see the
Selling and Fulfillment Foundation: Application Platform Configuration
Guide.

20.7 Defining Transaction Rules

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 Section 20.7.1, "Defining Transaction Rules for
Quotes".

Configuring an Order Document’s Fulfillment-Specific Components 335

Defining Transaction Rules

To define additional transaction rules:

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 20–15 for
field value descriptions.
3. Choose .

336 Configuration Guide

 Defining Transaction Rules

Table 20–15 Transactions Rules Window

Field Description
Ship Advice
Include Price When selected, the system sends down price
Information in information on the order as a part of the ship advice
Instruction instructions.
This is a DCS-specific parameter. Key price-related
elements from 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 When selected, items are canceled or backordered in
Inventory Shortage case of inventory shortage.
Order Monitor
Order Monitor Relog Enter the number of hours after which the order
Interval monitor 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 Enter the number of hours after which the Negotiation
Relog 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 Enter the number of hours based on which the
for Auto-Cancellation auto-cancel date is set on the order.
After

Configuring an Order Document’s Fulfillment-Specific Components 337

Defining Transaction Rules

Table 20–15 Transactions Rules Window

Field Description
Reship Order
Minimum Reship Enter the minimum number of days allowed to pass
Window 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 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 Selling and Fulfillment
Foundation: Application Platform Configuration Guide.
Cancellation of Order Lines with Work Orders
Allow Cancellation An order may have generated a work order to
Even If Work Order customize the item for the customer. In some
Cannot Be Cancelled scenarios, the work order 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.

338 Configuration Guide

 Defining Transaction Rules

Table 20–15 Transactions Rules Window

Field Description
Synchronize Dates
Synchronize Dates Check this box to synchronize the requested dates and
Between Master Order the expected ship dates for the Order, Order Header,
Dates And Dates On Order Line, and Order Line Schedules.
Order Line And
The requested dates synchronize with the requested
Schedules
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
Expected Dates When dates on the order line to be synchronized with the
Requested Dates On expected dates on the order line schedule.
The Order Are
Note: The dates are synchronized only during the line
Changed
creation.
Note: Scheduling should not be used on orders which
have expected and requested dates that are not
synchronized.
Pickup Order Lines
Compute Expected Check this box to recompute the expected ship date of
Dates When Requested an item when a customer chooses to pick up either a
Dates On The Pickup portion of an order or the complete order at a later
Order Lines Are date.
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
Confirm Draft Order the 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
Delivery Service Line is cancelled, the association with the delivery line is
kept.

Configuring an Order Document’s Fulfillment-Specific Components 339

Defining Transaction Rules

Table 20–15 Transactions Rules Window

Field Description
Remove Association To When selected, if the last product line on a work order
Delivery Service Line is cancelled, the association with the delivery line is
removed.
Order Approval
Hold Type To Be Select the hold type you want to be applied when an
Applied When Order order requires approval.
Needs 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 resolved automatically when an order is changed and
On Order Change the conditions necessary to require approval are no
longer met.
Customer Contact Status
Hold Type To Be Select the hold type you want to be applied on an
Applied To An Order order when a customer contact is on hold.
When Customer
Contact Is On Hold
Pending Order Changes
Pending Order Enter the number of hours after which the pending
Changes Will Expire In changes on the order will expire.
Hold To Be Applied Select the hold type you want to be applied on an
When Order Has order that has pending changes.
Pending Changes

20.7.1 Defining Transaction Rules for Quotes

You can define additional rules for quotes, as follows:
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 20–16 for
field value descriptions.

340 Configuration Guide

 Defining Transaction Rules

3. Choose .

Table 20–16 Transaction Rules Window for Quotes

Field Description
Order Monitor
Order Monitor Relog Enter the number of hours after which the order
Interval monitor 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
Expected Dates When dates on the order line to be synchronized with the
Requested Dates On expected dates on the order line schedule.
The Order Are
Note: The dates are synchronized only during the line
Changed
creation.
Order Approval
Hold Type To Be Select the hold type you want to be applied when an
Applied When Order order requires approval.
Needs Approval
Note: The hold is triggered internally by the system,
and therefore, should not be set to automatically apply
in the hold configuration.

Configuring an Order Document’s Fulfillment-Specific Components 341

Defining Status Inventory Types

20.8 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 20–17 Sample Status Inventory Type Records

Buyer Seller
Supply Demand Seller Supply Increment
Status Type Type Type Seller Supply
1100 Purchase Open Order Onhand N
Order Placed
3200 Purchase Released Onhand N
Order
Released
3700 Intransit Y

When an order with a line item quantity of 10 is created in Created

(1100) status, the Purchase Order Placed supply record is updated with a
quantity of 10. A Open Order demand type with a quantity of 10 is
created for the Seller.
In this example, if a quantity of 3 is moved into Released (3200) status,
the Purchase Order Placed supply record is decreased by 3 and a new
supply record with a quantity of 3 is created for the Purchase Order
Released supply type. The Open Order demand record is also decreased
by 3 and a new demand record is with a quantity of 3 is created for the
Released demand type.
When the order moves from Released (3200) status to Shipped (3700)
status, the Buyer’s supply is decreased for the Purchase Order Released
supply type and increased for Intransit. The Seller’s demand is decreased

342 Configuration Guide

 Defining Status Inventory Types

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 20–18 for assistance.

Configuring an Order Document’s Fulfillment-Specific Components 343

Defining Status Inventory Types

Table 20–18 Status Inventory Types Window

Field Description
Orders Without Select the Orders Without Chaining tab to view the
Chaining/Orders With status inventory types for orders that flow through
Chained the process type pipeline without having any
Children/Procurement associated chained orders.
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.

You can use the Status Inventory Types branch for:

Q
Creating a Status Inventory Type
Q
Modifying a Status Inventory Type
Q
Deleting a Status Inventory Type

20.8.1 Creating a Status Inventory Type

To to create a status inventory type:
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 20–19 for
field value descriptions.
3. Choose .

344 Configuration Guide

 Defining Status Inventory Types

Table 20–19 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 WMS, 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.

Configuring an Order Document’s Fulfillment-Specific Components 345

Defining Quote Rules

20.8.2 Modifying a Status Inventory Type

To modify a status inventory type:
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 20–19 for
field value descriptions.
3. Choose .

20.8.3 Deleting a Status Inventory Type

To delete a status inventory type, locate the applicable status inventory
type in the Status Inventory Types window and choose .

Note: Default status inventory types which are originally

shipped with Selling and Fulfillment Foundation cannot be
deleted.

20.9 Defining Quote Rules

You can define additional rules that are specific to the Quote document
type.
To define additional quote rules:
1. From the tree in the application rules side panel, choose Document
Specific > Quote > Fulfillment > Quote Rules. The Quote Rules
window displays.
2. Enter information in the applicable fields. Refer to Table 20–20 for
field value descriptions.
3. Choose .

346 Configuration Guide

 Defining Monitoring Components

Table 20–20 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.
(Number Of Days) However, 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.

20.10 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 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.
You can use the Monitoring window for:
Q
Defining Date Types

Configuring an Order Document’s Fulfillment-Specific Components 347

Defining Monitoring Components

Q
Defining Milestones

20.10.1 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.
You can use the Date Types tab for:
Q
Creating a Date Type
Q
Modifying a Date Type
Q
Deleting a Date Type

20.10.1.1 Creating a Date Type

To create a date type:
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 20–21 for
field value descriptions.
4. Choose .

Figure 20–2 Date Type Details

348 Configuration Guide

 Defining Monitoring Components

Table 20–21 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.

20.10.1.2 Modifying a Date Type

To modify a date type:
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 20–21 for
field value descriptions.
4. Choose .

20.10.1.3 Deleting a Date Type

To delete a date type:

Note: The following system dates cannot be deleted:

Q
Delivery Date
Q
Order Date
Q
Ship Date
Q
Next Iteration Date

1. In the Monitoring window, choose the Date Types tab.

Configuring an Order Document’s Fulfillment-Specific Components 349

Defining Monitoring Components

2. From the Date Types list, locate the applicable date type and choose
.

20.10.2 Defining Milestones

You can configure applicable statuses in a process type to be milestones.
A milestone is a type of date that 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.

Note: A milestone can be reached whenever there is a

change in an order line. 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.

You can use the Milestones tab for:

Q
Creating a Milestone
Q
Modifying a Milestone
Q
Deleting a Milestone

350 Configuration Guide

 Defining Monitoring Components

20.10.2.1 Creating a Milestone

To create a milestone:
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 20–22 for
field value descriptions.
4. Choose .

Table 20–22 Milestone Details

Field Description
Date Type Enter the name of the milestone being created.
Note: You cannot use date types you have created on
the date type tab. You must create a unique name for
the milestone.
Description Enter a brief description of the milestone.
Requested Select this field to indicate if the milestone represents
a date requested by a Buyer, user, etc.
Expected Select this field to indicate if the milestone represents
a date the system expects or has calculated something
to occur.
Actual This field is not applicable for milestones.
Committed Select this field to indicate if there is a committed date
available for this date type.

Configuring an Order Document’s Fulfillment-Specific Components 351

Defining Monitoring Components

20.10.2.1.1 Creating a Status Milestone

To create a Status Milestone:
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 20–23 for
field value descriptions.
4. Choose .

Table 20–23 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.

352 Configuration Guide

 Defining Monitoring Components

Table 20–23 Status Milestone Details

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.

20.10.2.2 Modifying a Milestone

Important: 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:
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 20–22 for
field value descriptions.
4. Choose .

20.10.2.3 Deleting a Milestone

To delete a milestone:
1. From the Monitoring window, choose the Milestones tab.
2. From the Milestones list, locate the applicable milestone and choose
.

Configuring an Order Document’s Fulfillment-Specific Components 353

Defining Monitoring Events

20.11 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".
You can use the Monitor Events tab for:
Q
Creating an Event Rule
Q
Modifying an Event
Q
Deleting an Event

20.11.1 Creating an Event Rule

To create an event rule:
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 20–24 for
field value descriptions.
4. Choose .

354 Configuration Guide

 Defining Monitoring Events

Table 20–24 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
Alerts every 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.

Configuring an Order Document’s Fulfillment-Specific Components 355

Defining Monitoring Events

Table 20–24 Monitor Event Details Pop-Up Window

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

356 Configuration Guide

 Defining Monitoring Events

Table 20–24 Monitor Event Details Pop-Up Window

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

20.11.2 Modifying an Event

To modify an event rule:
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 20–24 for
field value descriptions.
4. Choose .

20.11.3 Deleting an Event

To delete an event rule:
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 .

Configuring an Order Document’s Fulfillment-Specific Components 357

Defining Transaction Dependencies

20.12 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:
1. Transaction completion of certain lines, such as the account activation
being completed before the modem could be shipped.
2. Specific dates, such as not to ship the modem until 5 days before the
activation date.

Note: The above mentioned rules, do not apply for all

types of order lines. Bundle order fulfillment cannot be
configured with the transaction or date-type dependency
because the order lines can have interdependencies such
that a bundle parent line cannot move forward in the
pipeline until all the child lines are fulfilled.

You can configure transaction dependencies in groups, with one

dependency group being active at a time. The dependencies are
configured at an enterprise, document type, or process type level and
are applied while processing the order. If necessary, the enterprise level
inheritance can be used.
The dependencies are configured in two steps:
1. 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.
2. Once the rules are defined, you can configure additional constraints
based on either of the dependency types:
– Transaction Based

358 Configuration Guide

 Defining Transaction Dependencies

– 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:
Q
The dependency rules specified by a transaction is independent of the
pipeline or the order.
Q
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.
You can use the Transaction Dependencies branch for:
Q
Defining a Default Dependency Group
Q
Creating a Transaction Dependency Group
Q
Creating a Dependency Rule Constraint
Q
Modifying a Transaction Dependency Group
Q
Deleting a Transaction Dependency Group

20.12.1 Defining a Default Dependency Group

To define a Default Dependency Group:
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 20–25 for field value descriptions.
3. Choose .

Configuring an Order Document’s Fulfillment-Specific Components 359

Defining Transaction Dependencies

Table 20–25 Transaction Dependency Window

Field Description
Default Dependency Select the default transaction dependency group to
Group use.
Transaction Dependency Groups
For more information about creating a transaction dependency group, see
Section 20.12.2, "Creating a Transaction Dependency Group".
Group The name of the transaction dependency group.
Group Description The description of the transaction dependency group.

20.12.2 Creating a Transaction Dependency Group

To create a Transaction Dependency Group:
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 20–26 for
field value descriptions.

360 Configuration Guide

 Defining Transaction Dependencies

4. Choose .
5. After saving the transaction dependency group, you can add
transaction dependency rules to the group. For more information
refer to Section 20.12.2.1, "Creating a Transaction Dependency Rule".

Table 20–26 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
Section 20.12.2.1, "Creating a Transaction Dependency Rule".
Transaction The name of the transaction dependency rule.
Dependency Name
Transaction Name The transaction allowed to run based on this
transaction dependency.

Configuring an Order Document’s Fulfillment-Specific Components 361

Defining Transaction Dependencies

20.12.2.1 Creating a Transaction Dependency Rule

To create a transaction dependency rule:
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 20–27
for field value descriptions.
3. Choose .

362 Configuration Guide

 Defining Transaction Dependencies

Table 20–27 Transaction Dependency Rule Detail Window

Field Description
Dependency Enter the name for this transaction dependency.
Apply Dependency To From the drop-down list, select the criterion you want
Any Order Line Having to use 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 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
Following Conditions this transaction dependency rule.
Are Met
Dependency Rule Constraints
The dependency constraints are populated based on the created rule. For
information about creating the dependency rule constraints, see
Section 20.12.2.1.1, "Creating a Dependency Rule Constraint".

Configuring an Order Document’s Fulfillment-Specific Components 363

Defining Transaction Dependencies

20.12.2.1.1 Creating a Dependency Rule Constraint

To create a dependency constraint rule:
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 20–28
for field value descriptions.
3. Choose OK.

Table 20–28 Constraint Detail Window

Field Description
Transaction Based Choose this option if this dependency is transaction
Dependencies based, 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
Dependencies based, and 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.

364 Configuration Guide

 Defining Transaction Dependencies

20.12.2.1.2 Modifying a Dependency Rule Constraint

To modify a dependency rule constraint:
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 20–28
for field value descriptions.
3. Choose .

20.12.2.1.3 Deleting a Dependency Rule Constraint

To delete a dependency rule constraint:
1. From the Transaction Dependency Rule Detail window, select the
constraint type you wish to delete.
2. Choose .

20.12.2.2 Modifying a Transaction Dependency Rule

To modify a transaction dependency rule:
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 20–27
for field value descriptions.
3. Choose OK.

20.12.2.3 Deleting a Transaction Dependency Rule

To delete a transaction dependency rule:
1. From the Transaction Dependency Group Details window, select
the transaction dependency rule you wish to delete.
2. Choose .

Configuring an Order Document’s Fulfillment-Specific Components 365

Defining Transaction Dependencies

20.12.3 Modifying a Transaction Dependency Group

To modify a transaction dependency group:
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 20–26 for
field value descriptions.
4. Choose .

20.12.4 Deleting a Transaction Dependency Group

To delete a transaction dependency group:
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 .

366 Configuration Guide

 21
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.
You can use process type configuration for:
Q
Defining Process Type Details
Q
Configuring Process Type Pipelines
Q
Configuring Purge Criteria

21.1 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 Selling
and Fulfillment Foundation: Application Platform Configuration Guide.

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

Configuring an Opportunity Document’s Fulfillment-Specific Components 367

Configuring Process Type Pipelines

Repositories
A repository is a logical collection of entities that define the business
process workflow.
The following entities are included in a repository:
Q
Pipelines
Q
Transactions
Q
Statuses
Q
Conditions
Q
Actions
Q
Services
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 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.

21.2.1 Pipelines
For more information about configuring pipelines, see the Selling and
Fulfillment Foundation: Application Platform Configuration Guide.

368 Configuration Guide

 Configuring Process Type Pipelines

To view the Opportunity Fulfillment pipeline details:

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.

Configuring an Opportunity Document’s Fulfillment-Specific Components 369

Configuring Process Type Pipelines

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

21.2.2 Transactions
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 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 Selling and Fulfillment
Foundation: Application Platform Configuration Guide.
To view the transaction details pertaining to an Opportunity Fulfillment
pipeline:
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 .

370 Configuration Guide

 Configuring Process Type Pipelines

The Transactions tab window, containing the information described in

Table 21–1, is displayed.

Table 21–1 Opportunity Fulfillment Pipeline - Transactions Tab Window

Field Description
Change Opportunity This transaction represents any modifications that may
be made to an opportunity.
Change Opportunity This transaction represents any modifications that may
Status 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.

Configuring an Opportunity Document’s Fulfillment-Specific Components 371

Configuring Process Type Pipelines

Table 21–1 Opportunity Fulfillment Pipeline - Transactions Tab Window

Field Description
Purge Opportunity This transaction represents an opportunity that can be
purged and moved from the tables into the history
tables.
Purge Opportunity This transaction represents the process of purging
History opportunities from the history tables and removing
them from the system.

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

21.2.3 Statuses
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 Selling and Fulfillment
Foundation: Application Platform Configuration Guide.
To view the status details of an Opportunity Fulfillment pipeline:
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 21–2, is displayed.

372 Configuration Guide

 Configuring Process Type Pipelines

Table 21–2 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.

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

Configuring an Opportunity Document’s Fulfillment-Specific Components 373

Configuring Process Type Pipelines

21.2.4 Conditions
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 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 Selling and Fulfillment
Foundation: Application Platform Configuration Guide.
To view the condition details of an Opportunity Fulfillment pipeline:
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, containing the information described in
Table 21–3, is displayed.

Table 21–3 Opportunity Fulfillment Pipeline - Conditions Tab Window

Field Description
New Condition Group Displays conditions that are specific to the Opportunity
Fulfillment pipeline.

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

374 Configuration Guide

 Configuring Purge Criteria

21.2.5 Actions
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 Selling and Fulfillment
Foundation: Application Platform Configuration Guide.
To view the action details of an Opportunity Fulfillment pipeline:
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.
For more information about creating and modifying actions, see the
Selling and Fulfillment Foundation: Application Platform Configuration
Guide.

21.3 Configuring Purge Criteria

You can define the parameters used when purging the records pertaining
to an Opportunity from the system.
For more information about Purge Criteria, see Chapter 24, "Configuring
a Document’s Purge Criteria".

Configuring an Opportunity Document’s Fulfillment-Specific Components 375

Configuring Purge Criteria

376 Configuration Guide

 22
Configuring an Order Document’s
Shipment-Specific Components

Important: 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 Selling and Fulfillment Foundation.
The following process types are defined in Selling and Fulfillment
Foundation for the order document types:
Q
Fulfillment
Q
Negotiation
Q
Shipment
Q
Receipt
You can configure the rules and components specific to an order
document’s shipment process type.
You can use process type configuration for:
Q
Defining Hold Types
Q
Defining Process Type Details

Configuring an Order Document’s Shipment-Specific Components 377

Process Type Pipeline Configuration

Q
Process Type Pipeline Configuration
Q
Defining Monitoring Components
Q
Defining Monitoring Events
Q
Defining Shipment Preferences

22.1 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 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 Logistics Management: Configuration Guide.

22.2 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 Selling
and Fulfillment Foundation: Application Platform Configuration Guide.

22.3 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

378 Configuration Guide

 Process Type Pipeline Configuration

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:
Q
Pipelines
Q
Transactions
Q
Statuses
Q
Conditions
Q
Actions
Q
Services
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 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.

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

Configuring an Order Document’s Shipment-Specific Components 379

Process Type Pipeline Configuration

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.

22.3.2 Pipelines
For more information about configuring pipelines, see the Selling and
Fulfillment Foundation: Application Platform Configuration Guide.
To view the outbound shipment pipeline details:
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.

380 Configuration Guide

 Process Type Pipeline Configuration

2. In the Outbound Shipment window, choose Outbound Shipment

Repository > Pipelines > Outbound Shipment.
3. The Pipeline Detail: Outbound Shipment (Outbound Shipment)
window displays.
For more information about creating and modifying a pipeline, see the
Selling and Fulfillment Foundation: Application Platform Configuration
Guide.

Configuring an Order Document’s Shipment-Specific Components 381

Process Type Pipeline Configuration

22.3.3 Transactions
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 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 Selling and Fulfillment
Foundation: Application Platform Configuration Guide.

382 Configuration Guide

 Process Type Pipeline Configuration

To view the transaction details for an outbound shipment pipeline:

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

Configuring an Order Document’s Shipment-Specific Components 383

Process Type Pipeline Configuration

Table 22–1 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 This transaction represents any modifications that may
Status be made involving an order or order line’s status.
Close Shipment This transaction represents a shipment being closed
and archived in the system.
Confirm Shipment This transaction represents a shipment is manually
confirmed and shipped.
Create And Confirm This transaction represents the process of creating a
Shipment shipment and shipping it.
Create Shipment This transaction represents the creation of a shipment
in the system.
Create Shipment This transaction represents the creation of a shipment
Invoice 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 This transaction represents the completion of the
Complete 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.

384 Configuration Guide

 Process Type Pipeline Configuration

Table 22–1 Outbound Shipment Pipeline - Transactions Tab Window

Field Description
Purge Shipment This transaction represents the process of purging
History shipments from the history tables and removing them
from the system.
Receipt Closure This listener transaction monitors the receipt pipeline
Listener 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 This transaction represents the process of synching
Queue the order fulfillment task queue.
Undo Pack Shipment This transaction indicates that a shipment that has
Complete moved through the Pack Shipment Complete
transaction is undone.
Unpack Shipment This transaction represents the process of unpacking a
shipment that has already been packed.

22.3.4 Statuses
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 Selling and Fulfillment
Foundation: Application Platform Configuration Guide.

Configuring an Order Document’s Shipment-Specific Components 385

Process Type Pipeline Configuration

To view the status details of an outbound shipment pipeline:

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

386 Configuration Guide

 Process Type Pipeline Configuration

Table 22–2 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 Indicates that the shipment has been released from
Hold 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 Selling and Fulfillment Foundation:
Application Platform Configuration Guide.
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 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 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.

Configuring an Order Document’s Shipment-Specific Components 387

Process Type Pipeline Configuration

Table 22–2 Outbound Shipment Pipeline - Statuses Tab Window

Field Description
Shipment Invoiced This indicates that an invoice has been created for the
shipment.
Shipment Cancelled This indicates that the shipment has been cancelled.

22.3.5 Conditions
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 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 Selling and Fulfillment
Foundation: Application Platform Configuration Guide.
To view the condition details of an outbound shipment pipeline:
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.
For more information about creating and modifying conditions, see the
Selling and Fulfillment Foundation: Application Platform Configuration
Guide.

388 Configuration Guide

 Process Type Pipeline Configuration

Table 22–3 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 Selling and Fulfillment Foundation:
Application Platform Configuration Guide.

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

Configuring an Order Document’s Shipment-Specific Components 389

Defining Monitoring Components

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 Selling and Fulfillment
Foundation: Application Platform Configuration Guide.
To view the action details of an outbound shipment pipeline:
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.
For more information about creating and modifying actions, see the
Selling and Fulfillment Foundation: Application Platform Configuration
Guide.

22.4 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 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.
You can use the Monitoring window for:
Q
Defining Date Types
Q
Defining Milestones

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

390 Configuration Guide

 Defining Monitoring Components

You can use the Date Types tab for:

Q
Creating a Date Type
Q
Modifying a Date Type
Q
Deleting a Date Type

22.4.1.1 Creating a Date Type

To create a date type:
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 22–4 for field
value descriptions.
4. Choose .

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

Configuring an Order Document’s Shipment-Specific Components 391

Defining Monitoring Components

Table 22–4 Date Type Details Window

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

22.4.1.2 Modifying a Date Type

To modify a date type:
5. In the Monitoring window, choose the Date Types tab.
6. From the Date Types list, locate the applicable date type and choose
. The Date Type Details window displays.
7. Enter information in the applicable fields. Refer to Table 22–4 for field
value descriptions.
8. Choose .

22.4.1.3 Deleting a Date Type

To delete a date type:

Note: The following system dates cannot be deleted:

Q
Delivery Date
Q
Ship Date

1. In the Monitoring window, choose the Date Types tab.

2. From the Date Types list, locate the applicable date type and choose
.

22.4.2 Defining Milestones

You can configure applicable statuses in a process type to be milestones.
A milestone is a type of date that Selling and Fulfillment Foundation
automatically determines when an order moves from one status to
another. A milestone represents a significant point in the processing

392 Configuration Guide

 Defining Monitoring Components

lifecycle that can be used as a criterion for monitoring. Milestones can be

defined at the order, order line, and order release.

Note: A milestone can be reached whenever there is a

change in an order line. 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.

You can use the Milestones tab for:

Q
Creating a Milestone
Q
Modifying a Milestone
Q
Deleting a Milestone

22.4.2.1 Creating a Milestone

To create a milestone:
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 22–5 for field
value descriptions.
4. Choose .

Configuring an Order Document’s Shipment-Specific Components 393

Defining Monitoring Components

Table 22–5 Milestone Details

Field Description
Date Type Enter the name of the milestone being created.
Note: You cannot use date types you have created on
the date type tab. You must create a unique name for
the milestone.
Description Enter a brief description of the milestone.
Requested Select this field to indicate if the milestone represents
a date requested by a Buyer, user, etc.
Expected Select this field to indicate if the milestone represents
a date the system expects or has calculated something
to occur.
Actual This field is not applicable for milestones.
Milestone Statuses You can add statuses to associate with the milestone

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

394 Configuration Guide

 Defining Monitoring Components

Table 22–5 Milestone Details

Field Description
Level Select Order to indicate this status must be reached at
the order header level.
Select Order Line to indicate that this status must be
reached at the order line level.
Select Order Release to indicate that this status must
be reached at the order release level.
Quantity Type Select Initial to indicate that the milestone is met
when any quantity at the above selected level moves
into the status.
Select Complete to indicate that the milestone is met
when all quantity at the above selected level moves
into the status.

22.4.2.2 Modifying a Milestone

Important: 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:
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 22–5 for field
value descriptions.
4. Choose .

22.4.2.3 Deleting a Milestone

To delete a milestone:
1. From the Monitoring window, choose the Milestones tab.
2. From the Milestones list, locate the applicable milestone and choose
.

Configuring an Order Document’s Shipment-Specific Components 395

Defining Monitoring Events

22.5 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".
You can use the Monitor Events tab for:
Q
Creating an Event Rule
Q
Modifying an Event
Q
Deleting an Event

22.5.1 Creating an Event Rule

To create an event rule:
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 22–6 for field
value descriptions.
4. Choose .

396 Configuration Guide

 Defining Monitoring Events

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

Configuring an Order Document’s Shipment-Specific Components 397

Defining Monitoring Events

Table 22–6 Monitor Event Details Pop-Up Window

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

Note: In most cases the attributes that identify an event

should be a subset of the attributes that specify event
aggregation.

22.5.2 Modifying an Event

To modify an event rule:
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 22–6 for field
value descriptions.
4. Choose .

398 Configuration Guide

 Defining Shipment Preferences

22.5.3 Deleting an Event

To delete an event rule:
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 .

22.6 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.
Shipment Preferences are divided into two sets:
Q
Over Shipping Preferences
Q
Transaction Rules

22.6.1 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:
Q
Line Type
Q
Seller Organization Code
Q
CustomerVendor Classification/BuyerSeller Organization Code
Q
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.
You can use the Shipping Preference branch for:
Q
Creating a Shipment Preference
Q
Modifying a Shipment Preference
Q
Deleting a Shipment Preference

Configuring an Order Document’s Shipment-Specific Components 399

Defining Shipment Preferences

22.6.1.1 Creating a Shipment Preference

To create a shipment preference:
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.
4. Enter information into the applicable fields. Refer to Table 22–7 for
field value descriptions.
5. Choose .

400 Configuration Guide

 Defining Shipment Preferences

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

Configuring an Order Document’s Shipment-Specific Components 401

Defining Shipment Preferences

22.6.1.2 Modifying a Shipment Preference

To modify a shipment preference:
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 . The Shipping
Preference Details pop-up window displays.
5. Enter information into the applicable fields. Refer to Table 22–7 for
field value descriptions.
6. Choose .

22.6.1.3 Deleting a Shipment Preference

To delete a shipment preference:
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 .

22.6.2 Transaction Rules

Transaction Rules define whether the system allows the creation of
shipments without an existing order information on the system.
To define transaction rules:
1. From the tree in the application rules side panel, choose Document
Specific > (Document Type) > Outbound Logistics > Shipping
Preference. The Shipping Preferences window displays.

402 Configuration Guide

 Defining Shipment Preferences

2. In the Shipping Preferences window, choose the Transaction Rules

tab.
3. Enter information in the applicable field. Refer to Table 22–8 for field
value descriptions.
4. Choose .

Figure 22–1 Transaction Rules, Shipping Preference

Table 22–8 Transaction Rules Tab

Field Description
Order Available On Select the appropriate option from the drop-down list
System to ensure that the shipments are either created
against existing orders or not. Options are:
Q
May Be - Select this option if the orders might be
available on the system.
Q
No - Select this option if the orders are not
available on the system.
Q
Yes - Select this option if the orders are available
on the system.

Configuring an Order Document’s Shipment-Specific Components 403

Defining Shipment Preferences

404 Configuration Guide

 23
Configuring a Document’s Financial
Components

You can define rules and common codes as they pertain to payments and
charges for a given order document.
You can use the Financial Attributes branch for:
Q
Defining Payment Terms
Q
Defining Charge Definitions
Q
Defining Tax Names
Q
Defining Additional Payment Rules

23.1 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.
You can use the Payment Terms tab for:
Q
Creating a Payment Term
Q
Modifying a Payment Term
Q
Deleting a Payment Term

23.1.1 Creating a Payment Term

To create a payment term:
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.

Configuring a Document’s Financial Components 405

Defining Payment Terms

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 .

23.1.2 Modifying a Payment Term

To modify a payment term:
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 .

406 Configuration Guide

 Defining Charge Definitions

23.1.3 Deleting a Payment Term

To delete a payment term:
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 .

23.2 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
Section 23.4, "Defining Additional Payment Rules".
The default charge definitions of Selling and Fulfillment Foundation are:
Q
Shipping
Q
Handling
Q
Personalization
Q
Discount

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

Use the Charge Definitions tab for:

Q
Creating a Charge Category
Q
Modifying a Charge Category
Q
Adding a Charge Name Associated with a Charge Category
Q
Modifying a Charge Name Associated with a Charge Category

Configuring a Document’s Financial Components 407

Defining Charge Definitions

Q
Deleting a Charge Name Associated with a Charge Category
Q
Deleting a Charge Category

23.2.1 Creating a Charge Category

To create a charge category:
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 Charge Definitions tab.
3. Choose . The Charge Category Details window displays.

4. In Charge Category, enter the name of the charge category.

408 Configuration Guide

 Defining Charge Definitions

5. In Description, enter a brief description of the charge category.

6. Select Billable if the charge is billable. Non-billable charges are not
considered in order totals, but do appear in invoices.
7. Select Is Fee (or Discount if applied to a pickup request) if the charge
you are creating is a discount charge type.
8. Select Consider For Profit Margin Total if the category should be used
for profit margin calculation.
9. Choose .
You can use the Charge Category Details window for:
Q
Adding a Charge Name Associated with a Charge Category
Q
Modifying a Charge Name Associated with a Charge Category
Q
Deleting a Charge Name Associated with a Charge Category

23.2.1.1 Adding a Charge Name Associated with a Charge

Category
Charge names are names of the actual charges included in the charge
definition.

Note: Sterling Commerce recommends that you clearly

specify between order charges and discount charges when
naming a charge. In the Application Consoles both order
charges and discount charges appear on the same screens
and drop-down menu. There is no way for the user to
distinguish which is an order charge and which is a
discount charge other than its naming convention.

To add a charge name to a charge category:

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

Configuring a Document’s Financial Components 409

Defining Charge Definitions

2. In Charge Name, enter the charge name.

3. In Description, enter a brief description of the charge name.
4. Choose .

Note: Charge names cannot be localized. For more

information about localization, see the Selling and
Fulfillment Foundation: Localization Guide.

Note: When you create a charge name, ensure that you

define the same charge name for other document types
that you are going to price, such as quotes, returns, and
so forth.

23.2.1.2 Modifying a Charge Name Associated with a Charge

Category
To modify a charge category’s charge name:
1. In the Charge Category Details window, select the applicable charge
name and choose . The Charge Name Details pop-up window
displays.

410 Configuration Guide

 Defining Charge Definitions

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

3. Choose .

23.2.1.3 Deleting a Charge Name Associated with a Charge

Category
To delete a charge category’s charge name select the applicable charge
name in the Charge Category Details window and choose .

23.2.2 Modifying a Charge Category

To modify a charge category:
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 Charge Definitions tab.
3. Select the applicable charge category and choose . The Charge
Category Details window displays.
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 Total if the category should be used
for profit margin calculation.
8. Choose .

23.2.3 Deleting a Charge Category

To delete a charge definition:
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 Charge Definitions tab.
3. Select the applicable charge category and choose .

Configuring a Document’s Financial Components 411

Defining Tax Names

23.3 Defining Tax Names

You can define common codes for tax names. Tax names are any
specific taxes that may pertain to orders and invoices.
Selling and Fulfillment Foundation understands three different types of
taxes: a tax against a price, against a charge, or a flat tax.
Q
A tax against a price is an additional cost for a percentage of the
price of the order line.
Q
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.
Q
A flat tax is a fixed tax applied on an order, independently of any
charge, or price.
You can use the Tax Names tab for:
Q
Creating a Tax Name
Q
Modifying a Tax Name
Q
Deleting a Tax Name

23.3.1 Creating a Tax Name

To create a tax name:
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.

412 Configuration Guide

 Defining Tax Names

4. In Tax Name, enter the name of the tax name.

5. In Short Description, enter a brief description of the tax name.
6. In Long Description, enter a more detailed description of the tax
name.
7. Choose .

23.3.2 Modifying a Tax Name

To modify a tax name:
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 .

Configuring a Document’s Financial Components 413

Defining Additional Payment Rules

23.3.3 Deleting a Tax Name

To delete a tax name:
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 .

23.4 Defining Additional Payment Rules

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 Section 23.4.1, "Defining Additional Payment Rules for
Quotes".

To define additional payment rules:

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.

414 Configuration Guide

 Defining Additional Payment Rules

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

Table 23–1 Payment Rules

Field Description
Hold Order For Check this box if you want to hold the order for
Authorization authorization purposes.
Use Same Check this box if you want to use the same
Authorization Multiple authorization for multiple transactions.
Times
Allow Refund To Check this box if you want to allow refunds to exceed
Exceed Charged the amount charged.
Amount
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 Check this box if you want to be able to create an
Order or Shipment informational invoice before an order or a shipment.

Configuring a Document’s Financial Components 415

Defining Additional Payment Rules

Field Description
Apply Price Change To Check this box to apply the price changes to the
Invoiced Quantity invoiced quantity. If this box is unchecked, then price
change after invoicing is not applied to the order.
Do Not Allow Debit And Check this box to ensure that positive and negative
Credit Invoices To transactions are not able to negate each other.
Settle Each Other
Invoice Open Header Check this box if you want all open header charges
Charges/Taxes On and taxes to be invoiced when an order is moved to
Invoice Complete the Invoice Complete status.
Allow Refunding of When "Do Not Allow Debit And Credit Invoices To
Negative Debts Before Settle Each Other" is checked, this rule determines
Sufficient Collection whether the credit memo should refund immediately
Has Occurred or wait until there are sufficient credits to refund on
the order. This applies only to sales orders.
Disassociate Payment Check this box if you do not want to transfer the fund
Processing of between a return order and an advanced pre-paid
Advanced Pre-Paid exchange order.
Exchange Order from
When a return order is invoiced with this check box
Return Order
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 Check this box if you want invoiced orders to remain in
Payment Status Over INVOICED status when asynchronous payment
REQUEST_CHARGE For requests are made on the orders. If the box is
Asynchronous unchecked, orders move to REQUESTED_CHARGE
Processing status, which indicates there is a pending charge on
the orders. By default, this option is enabled.

416 Configuration Guide

 Defining Additional Payment Rules

Field Description
Expiration for Enter the number of days before the authorization
Authorization Days expires at which a reauthorization request is
automatically created by the Payment Collection
time-triggered transaction. For example, if an order
expires on 4/15, and the fixed number of days is 4,
then the reauthorization request is created on 4/11.
Hold To Be Applied Due Create or choose the hold type to be applied for cases
To Insufficient Funds in which a customer account contains insufficient
In Customer Account funds to complete a transaction.
Note: The hold is triggered internally by the system,
and therefore, should not be set to automatically apply
in the hold configuration.
Charge Name for Select the charge name that represents the shipping
Shipping charge on an order, as described in Section 23.2.1,
"Creating a Charge Category".
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 Check this box to create a shipment invoice for the
Component 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.
Use Order Date Enable this radio button if you want pricing to be
based on the order date.

23.4.1 Defining Additional Payment Rules for Quotes

You can set up payment rules for the Quote document type.
To define additional payment rules:
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.

Configuring a Document’s Financial Components 417

Defining Receiving Discrepancy Reasons

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

Table 23–2 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 Select the charge name that represents the shipping
Shipping charge on a quote, as described in Section 23.2.1,
"Creating a Charge Category".

23.5 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:
Q
Over Receipt - Occurs when a receiving node receives additional
quantity compared to the expected quantity.
Q
Under Receipt - Occurs when a receiving node receives less than the
expected quantity for the receipt.
Q
Damaged Receipt - Occurs when the receiving disposition code
indicates that a damaged product has been received.

418 Configuration Guide

 Defining Receiving Discrepancy Reasons

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

You can use the Receiving Discrepancy Reasons branch for:

Q
Creating a Receiving Discrepancy Reason
Q
Modifying a Receiving Discrepancy Reason
Q
Deleting a Receiving Discrepancy Reason

23.5.1 Creating a Receiving Discrepancy Reason

To create a receiving discrepancy reason:
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 23–3 for
field value descriptions.
4. Choose .

Configuring a Document’s Financial Components 419

Defining Receiving Discrepancy Reasons

Table 23–3 Receiving Discrepancy Reason Details

Field Description
Discrepancy Reason Enter the name of the discrepancy reason code as you
Code 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.

420 Configuration Guide

 Defining Receiving Discrepancy Reasons

Table 23–3 Receiving Discrepancy Reason Details

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

23.5.2 Modifying a Receiving Discrepancy Reason

To modify a receiving discrepancy reason:
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 23–3 for
field value descriptions.
4. Choose .

Configuring a Document’s Financial Components 421

Defining Receiving Discrepancy Reasons

23.5.3 Deleting a Receiving Discrepancy Reason

To delete a receiving discrepancy reason:
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 .

422 Configuration Guide

 24
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 24–1 lists the purge rules provided for order document types in
Selling and Fulfillment Foundation.

Table 24–1 Order Document Type Purge Rules

Default
Retention
Rule Description Days
PRG_SHIP_STATS Purges shipment statistics 30
and archives them in the
history tables.
STATUSAUDITPRG Purges order age alerts (if 30
you 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 30
information and archives it in
the history tables.
NEGOTIATIONHISTPRG Purges negotiation 30
information from the
negotiation history tables.

Configuring a Document’s Purge Criteria 423

 Table 24–1 Order Document Type Purge Rules
Default
Retention
Rule Description Days
RECEIPTPRG Purges receipt information 30
and archives it in the history
tables.
RECEIPTHISTPRG Purges receipt information 30
from the receipt history
tables.
ORDERHISTPRG Purges order information 30
from the order history
tables.
ORDERPRG Purges order information and 30
archives it in the history
tables.
ORDER_RELEASE_STATUS_ Purges order release status 30
PURGE records with a quantity of 0.
PICKLISTPRG Purges pick list information. 30
SHIPMENTHISTPRG Purges shipment information 30
from the shipment history
tables.
SHIPMENTPRG Purges shipment information 30
and archives it in the history
tables.
DRAFTORDERNOLINEPRG Purges draft orders that do 30
not have any order lines.
DRAFTORDERNOLINEHISTPRG Purges draft orders without 30
any order lines from the
history table.
DRAFTORDERHISTPRG Purges draft order 30
information from the draft
order history tables.
DRAFTORDERPRG Purges draft order 30
information and archives it in
the history tables.

424 Configuration Guide

 Modifying an Order Document Type’s Purge Criteria Rule

Table 24–2 lists the purge rules provided for the opportunity document
type in Selling and Fulfillment Foundation.
Table 24–2 Opportunity Document Type Purge Rules
Default
Retention
Rule Description Days
OPPORTUNITYPRG Purges opportunity information and 30
archives it in the history tables.
OPPORTUNITYHISTPRG Purges opportunity information from the 30
opportunity history tables.

24.1 Modifying an Order Document Type’s Purge

Criteria Rule
To modify an order document type’s purge criteria rule:
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 24–3, "Purge
Criteria Details Pop-up Window" for field value descriptions.
3. Choose .

Configuring a Document’s Purge Criteria 425

Modifying an Order Document Type’s Purge Criteria Rule

Table 24–3 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
Selling and Fulfillment Foundation: Properties Guide.
For more information about using variables for the log
file directory, see the Selling and Fulfillment
Foundation: Extending the Condition Builder Guide .
For information about filename limitations related to
internationalization, see the Selling and Fulfillment
Foundation: Localization Guide.

426 Configuration Guide

 Modifying an Order Document Type’s Purge Criteria Rule

Table 24–3 Purge Criteria Details Pop-up Window

Field Description
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
appropriate section in this guide.
Additional Retention Enter the additional number of days (apart from the
Days 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.

The following example provides an use-case of the line type purge in an

order placement scenario:

Example 24–1 Line Type Purge

An order is placed with the following 4 order lines:
Q
Order Line 1 - Television
Q
Order Line 2 - 2 year Television service plan with Line Type as 2YR_
WARRANTY. Therefore, the additional retention days are 721.
Q
Order Line 3 - Stereo

Configuring a Document’s Purge Criteria 427

Modifying an Order Document Type’s Purge Criteria Rule

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

428 Configuration Guide

 25
Configuring Value-Added Services

Enterprises provide services along with the products they sell to their
customers. Some examples of services provided include:
Q
Annual maintenance contract.
Q
Installing a customer's home theater system.
Q
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.
Use Value Added Services for:
Q
Defining Value-Added Services Modification Reasons
Q
Defining Value-Added Services Cancellation Reasons
Q
Defining Value-Added Services Appointment Failure Reasons
Q
Defining Value-Added Services Note Reasons
Q
Defining Value-Added Services Instruction Types
Q
Defining Value-Added Services Rules
Q
Defining Value-Added Services Modification Rules
Q
Defining Value-Added Services Hold Types
Q
Defining Value-Added Services Process Types
Q
Defining Value-Added Services Process Model

Configuring Value-Added Services 429

Defining Value-Added Services Modification Reasons

Q
Defining Value-Added Services Monitoring
Q
Viewing Value-Added Services Purge Criteria

25.1 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.
You can use the Modification Reasons branch for:
Q
Creating a Modification Reason
Q
Modifying a Modification Reason
Q
Deleting a Modification Reason

25.1.1 Creating a Modification Reason

To create a modification reason:
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.

430 Configuration Guide

 Defining Value-Added Services Modification Reasons

6. In Long Description, enter a more detailed description of the

modification reason.
7. Choose .

25.1.2 Modifying a Modification Reason

To modify a modification reason:
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. 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 .

25.1.3 Creating a New Modification Reason Based on an

Existing One
To create a new modification reason based on an existing one:
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 .

Configuring Value-Added Services 431

Defining Value-Added Services Cancellation Reasons

25.1.4 Deleting a Modification Reason

To delete a modification reason:
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.

25.2 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.
You can use the Cancellation Reasons branch for:
Q
Creating a Cancellation Reason
Q
Modifying a Cancellation Reason
Q
Deleting a Cancellation Reason

25.2.1 Creating a Cancellation Reason

To create a cancellation reason:
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.

432 Configuration Guide

 Defining Value-Added Services Cancellation Reasons

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 .

25.2.2 Modifying a Cancellation Reason

To modify a cancellation reason:
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.

Configuring Value-Added Services 433

Defining Value-Added Services Cancellation Reasons

5. In Long Description, enter a more detailed description of the

cancellation reason.
6. Choose .

25.2.3 Creating a New Cancellation Reason Based on an

Existing One
To create a new cancellation reason based on an existing one:
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 .

25.2.4 Deleting a Cancellation Reason

To delete a cancellation reason:
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.

434 Configuration Guide

 Defining Value-Added Services Appointment Failure Reasons

25.3 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.
You can use the Appointment Failure Reasons branch for:
Q
Creating a Appointment Failure Reason
Q
Modifying an Appointment Failure Reason
Q
Deleting an Appointment Failure Reason

25.3.1 Creating a Appointment Failure Reason

To create a appointment failure reason:
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.

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 .

Configuring Value-Added Services 435

Defining Value-Added Services Appointment Failure Reasons

25.3.2 Modifying an Appointment Failure Reason

To modify a Appointment Failure reason:
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 .

25.3.3 Creating a New Appointment Failure Reason

Based on an Existing One
To create a new Appointment Failure reason based on an existing one:
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. Enter information in the applicable fields.
5. Choose .

436 Configuration Guide

 Defining Value-Added Services Note Reasons

25.3.4 Deleting an Appointment Failure Reason

To delete a Appointment Failure reason:
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.

25.4 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.
You can use the Note Reasons branch for:
Q
Creating a Note Reason
Q
Modifying a Note Reason
Q
Deleting a Note Reason

25.4.1 Creating a Note Reason

To create a note reason:
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 > Note
Reasons. The Note Reasons window displays in the work area.
3. Choose . The Note Reason Details window displays.

Configuring Value-Added Services 437

Defining Value-Added Services Note Reasons

4. In Note Reason, enter the note reason as you want it to appear

throughout the system.
5. In Short Description, enter a brief description of the note reason.
6. In Long Description, enter a more detailed description of the note
reason.
7. Choose .

25.4.2 Modifying a Note Reason

To modify a note reason:
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 > Note
Reasons. The Note Reasons window displays in the work area.
3. Select the applicable appointment failure reason and choose . The
Note Reason Details window displays.
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 .

438 Configuration Guide

 Defining Value-Added Services Instruction Types

25.4.3 Creating a New Note Reason Based on an Existing

One
To create a new note reason based on an existing one:
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 > Note
Reasons. The Note Reasons window displays in the work area.
3. Select the applicable note reason and choose . The Note Reason
Details window displays.
4. Enter information in the applicable fields.
5. Choose .

25.4.4 Deleting a Note Reason

To delete a note reason:
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 > Note
Reasons. The Note Reasons window displays in the work area.
3. Select the applicable appointment failure reason and choose . The
Confirmation window displays.
4. Choose OK.

25.5 Defining Value-Added Services Instruction

Types
You can define the common codes used when adding special instructions
to an work order document.
You can use the Instruction Types branch for:
Q
Creating an Instruction Type
Q
Modifying an Instruction Type

Configuring Value-Added Services 439

Defining Value-Added Services Instruction Types

Q
Deleting an Instruction Type

25.5.1 Creating an Instruction Type

To create an instruction type:
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 .

25.5.2 Modifying an Instruction Type

To modify an instruction type:
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

440 Configuration Guide

 Defining Value-Added Services Rules

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 .

25.5.3 Deleting an Instruction Type

To delete an instruction type:
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 .

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

25.6.1 Setting Up Value-Added Services Pre-Call Rules

To set up Value-Added Services pre-call rules:
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.

Configuring Value-Added Services 441

Defining Value-Added Services Rules

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

25.6.2 Setting Up Value-Added Services Other Rules

To set up Value-Added Services other rules:
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.

442 Configuration Guide

 Defining Value-Added Services Rules

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.
If the product line is removed from the work order, the
association to the corresponding delivery service will also
be removed.
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

Configuring Value-Added Services 443

Defining Value-Added Services Modification Rules

product line that requires delivery and that has already been
scheduled after taking an appointment, to an earlier date.
6. Choose .

25.7 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. Selling and Fulfillment Foundation supports
modification through the 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.

Important: Contemplate business and system integration

implications before allowing a modification that is
disallowed as part of the system defaults.

25.7.1 Setting Up Value-Added Services Modification Rules

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

444 Configuration Guide

 Defining Value-Added Services Modification Rules

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:
Q
to allow modification
Q
to disallow modification
Q
to ignore modification
5. Refer to the following table for settings definition you can apply to
modifications:

Table 25–1 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.

Configuring Value-Added Services 445

Defining Value-Added Services Hold Types

Table 25–1 Value-Added Services Rule Modifications

Field Description
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:
Q
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.
Q
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.
Q
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.

25.8 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 Selling and Fulfillment Foundation: Application
Platform Configuration Guide.
You can use the Hold Types branch for:
Q
Creating a Hold Type
Q
Modifying a Hold Type

446 Configuration Guide

 Defining Value-Added Services Hold Types

Q
Deleting a Hold Type

25.8.1 Creating a Hold Type

To create a hold type:
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 25–2, Table 25–3 and Table 25–4 for field value descriptions.
3. Click .

Configuring Value-Added Services 447

Defining Value-Added Services Hold Types

Table 25–2 Hold Type window, Hold Creation tab

Field Description
Hold Created Automatically
On Work Order Check this to apply this hold type to all work orders on
Creation work order creation.

448 Configuration Guide

 Defining Value-Added Services Hold Types

Table 25–2 Hold Type window, Hold Creation tab

Field Description
On Resolution Of Hold Check this to apply this hold type on resolution of
Type another hold type. Select from the drop-down list the
hold type that, upon resolution, triggers this hold type.
Note: 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 Selling and
Fulfillment Foundation does not warn you against.
When The Following Modification types that automatically apply this hold
Modifications Are type to a work order.
Performed
Click to modify the list. In the subsequent pop-up
window:
Q
Use the right arrow to move the available
modification types that you wish to associate with
this hold type to the subscribed list.
Q
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
Satisfying Following only be checked for work orders satisfying a certain
Condition condition. Click to build or modify the condition for
evaluation. For more information about using the
condition builder, see the Selling and Fulfillment
Foundation: Application Platform Configuration Guide.
The available attributes for this condition can be
extended. For more information, refer to the Selling
and Fulfillment Foundation: Extending the Condition
Builder Guide .
Note: This option is only selectable once the created
hold has been saved.
Hold Created Manually

Configuring Value-Added Services 449

Defining Value-Added Services Hold Types

Table 25–2 Hold Type window, Hold Creation tab

Field Description
By All Users Select this radio button if all user groups can apply
this hold to a work order.
By Users Who Belong Select this radio button if only users belonging to
To The Following User certain user groups may apply this hold to a work
Groups order.

Click to modify the list. In the subsequent pop-up

window:
Q
Use the right arrow to move the available user
groups that you wish to associate with this hold
type to the subscribed list.
Q
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 25–3 Hold Type window, Hold Resolution tab

Field Description
Hold Resolved Automatically
The Following From the drop-down list, select the time-triggered
Time-Triggered transaction that will process created holds.
Transaction Will
Process Created Holds
The Following from the drop-down list, select the time-triggered
Time-Triggered transaction that will process rejected holds.
Transaction Will
Process Rejected Holds
Hold Resolved Manually

450 Configuration Guide

 Defining Value-Added Services Hold Types

Table 25–3 Hold Type window, Hold Resolution tab

Field Description
By All Users Select this radio butting if all user groups may process
this hold.
By All Users Who Select this radio button if only users belonging to
Belong To The certain user groups may process this hold.
Following Groups
Click to modify the list. In the subsequent pop-up
window:
Q
Use the right arrow to move the available user
groups that you wish to associate with this hold
type to the subscribed list.
Q
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.

Configuring Value-Added Services 451

Defining Value-Added Services Hold Types

Table 25–4 Hold Type window, Hold Effects tab

Fields Description
The Following Transactions that are disallowed when this hold type is
Transactions Will Be applied to a work order.
Stopped From
Processing Work Click to modify the list. In the subsequent pop-up
Orders window:
Q
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
Modifications Are Not is applied to a work order.
Allowed For Work
Orders On This Hold Click to modify the list. In the subsequent pop-up
window:
Q
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.

25.8.2 Modifying a Hold Type

1. From the tree in the application rules side panel, choose VAS > VAS
Process > Hold Types. The Hold Types window displays in the work
area.
2. Select the applicable hold type and click . The Hold Type pop-up
window displays. Enter information in the applicable fields. Refer to
Table 25–2, Table 25–3 and Table 25–4 for field value descriptions.
3. Click .

452 Configuration Guide

 Defining Value-Added Services Process Types

25.8.3 Deleting a Hold Type

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 .

25.9 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:
Q
Pipelines
Q
Transactions
Q
Statuses
Q
Conditions
Q
Actions
Q
Service Definitions

25.9.1 Viewing Value-Added Services Process Type Details

To view Value-Added Services process type details:
1. From the menu bar, choose Applications > Distributed Order
Management. The Distributed Order Management tree displays in the
side panel.

Configuring Value-Added Services 453

Defining Value-Added Services Process Model

2. From the Distributed Order Management tree, choose VAS > VAS
Process > VAS Process Type Details. The Process Type Details window
displays in the work area.

3. In Process Type, VAS is automatically populated by the system.

4. In Process Type Name, the name of the process type displays, which
is editable.
5. In Description, a brief description of the process type displays, which
is editable.

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

25.10.1 Pipeline Determination

Pipeline determination is used to set up conditions that affect which
pipeline is used during the start of the business process workflow.

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

454 Configuration Guide

 Defining Value-Added Services Process Model

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.

25.10.1.2 Condition Variables for Pipeline Determination

When using conditions for pipeline determination, the following condition
variables can be used:
Q
Enterprise Code
Q
Node
Q
Provider Organization
Q
Service Item ID

25.10.2 Pipelines
To view Value-Added Services pipeline details:
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.

Configuring Value-Added Services 455

Defining Value-Added Services Process Model

For more information about creating, modifying, deleting, and monitoring

rules, see the Selling and Fulfillment Foundation: Application Platform
Configuration Guide.

25.10.3 Transactions
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 Selling and Fulfillment Foundation. Base transactions are
predefined transactions that contain information about how the

456 Configuration Guide

 Defining Value-Added Services Process Model

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:
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.
For more information about creating, modifying, or deleting transactions,
see the Selling and Fulfillment Foundation: Application Platform
Configuration Guide.

Configuring Value-Added Services 457

Defining Value-Added Services Process Model

Table 25–5 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 This transaction indicates the change in status of a
Status 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 This transaction indicates the purge of the work order
History history for VAS.
Release Work Order The transaction indicates the release of a work order
created for VAS.
Synchronize Task The transaction indicates synchronization of task
Queue queue for work orders created for VAS.
Work Order Monitor This transaction indicates monitoring of work orders
created for VAS.

25.10.4 Statuses
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:
1. From the menu bar, choose Applications > Distributed Order
Management. The Distributed Order Management tree displays in the
side panel.

458 Configuration Guide

 Defining Value-Added Services Process Model

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.
For more information about creating, modifying, or deleting statuses, see
the Selling and Fulfillment Foundation: Application Platform Configuration
Guide.

Table 25–6 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.

Configuring Value-Added Services 459

Defining Value-Added Services Process Model

Table 25–6 Statuses Tab Window

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.

25.10.5 Conditions
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 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:
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.
For more information about creating, modifying, or deleting conditions,
see the Selling and Fulfillment Foundation: Application Platform
Configuration Guide.

460 Configuration Guide

 Defining Value-Added Services Process Model

Table 25–7 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.

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

Configuring Value-Added Services 461

Defining Value-Added Services Process Model

To view the action details of a Value-Added Services pipeline:

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

462 Configuration Guide

 Defining Value-Added Services Process Model

Table 25–8 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.

25.10.7 Service Definitions

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:
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.
For more information about creating, modifying, or deleting service
conditions, see the Selling and Fulfillment Foundation: Application
Platform Configuration Guide.

Configuring Value-Added Services 463

Defining Value-Added Services Monitoring

Table 25–9 Service Conditions Tab Window

Field Description
Service Definitions Displays service definitions that are specific to the VAS
pipeline.

25.11 Defining Value-Added Services Monitoring

Use Value-Added Services Monitoring to view Date Types and configure
Monitoring Events.

25.11.1 Viewing Value-Added Services Date Types

You can view Value-Added Services date types.
To view date types:
1. From the menu bar, choose Applications > Distributed Order
Management. The Distributed Order Management tree displays in the
side panel.

464 Configuration Guide

 Defining Value-Added Services Monitoring

2. From the Distributed Order Management tree, choose VAS > VAS
Process > VAS Monitoring. The Monitoring: Work Order window
displays. Choose the Date Types tab.

Table 25–10 Monitoring: Work Order - Date Types

Field Description
Date Type The name of VAS date type.
Description The date type description.
Requested Indicates if the date type is requested by a user.
Expected Indicates if the date type represents a date the system
expects or has calculated something to occur.
Actual Indicate if the date type represents the actual date.

Configuring Value-Added Services 465

Defining Value-Added Services Monitoring

25.11.2 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".
You can use the Event Monitoring tab for:
Q
Creating an Event Rule
Q
Modifying an Event
Q
Creating a New Event
Q
Deleting an Event

Table 25–11 View Events

Field Description
Event ID The event ID.
Description A brief description of the event.

25.11.2.1 Creating an Event Rule

To create an event rule:
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.

466 Configuration Guide

 Defining Value-Added Services Monitoring

Figure 25–1 Monitor Event Details

4. Enter information in the applicable fields. Refer to Table 25–12 for

field value descriptions.
5. Choose .

Table 25–12 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
Alerts every time an alert condition is detected on an order.
To trigger an alert only once when the alert condition
is met, uncheck this flag.

Configuring Value-Added Services 467

Defining Value-Added Services Monitoring

Table 25–12 Event Monitoring

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

25.11.2.2 Modifying an Event

To modify an event rule:
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. Enter information in the applicable fields. Refer to Table 25–12 for
field value descriptions.
5. Choose .

25.11.2.3 Creating a New Event

To create a new event rule:
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.

468 Configuration Guide

 Viewing Value-Added Services Purge Criteria

3. In the Monitor Events window, choose . The Monitor Event Details

window displays.
4. Choose .

25.11.2.4 Deleting an Event

To delete an event:
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.

25.12 Viewing Value-Added Services Purge

Criteria
Transactional data collected by Selling and Fulfillment Foundation during
the execution are periodically removed from the 'live' transactional
tables. It is common to retain work order related information for
extended period of time. There are history tables provided for relevant
transactional tables to move data from the day-to-day 'live' tables to a
historical table. Purges are the process by which old data is removed
from the system database. Purges minimize the number of unused
database records to increase search efficiency and reduce the size of the
required physical disk.
To view purge criteria:
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.

Configuring Value-Added Services 469

Viewing Value-Added Services Purge Criteria

Table 25–13 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.

470 Configuration Guide

 A
Time-Triggered Transaction Reference

Selling and Fulfillment Foundation provides a collection of time-triggered

transactions, which are utilities that perform a variety of individual
functions, automatically and at specific time intervals.
Time-triggered transactions perform repetitive actions on a scheduled
basis, typically performing database updates, raising events, or calling
APIs. One type of transaction, monitors, are designed to watch for
processes or circumstances that are out of bounds and then raise alerts.
Often, but not always, they retrieve tasks from the task queue or work
from the pipeline.
Some transactions enable you to collect statistical data regarding the
application’s health. This data is collected periodically, using the value
specified for the yantra.statistics.persist.interval attribute in the
yfs.properties file. By default, statistics collection set to on. To override
this property, add an entry in the <INSTALL_DIR>/properties/customer_
overrides.properties file. For additional information about overriding
properties using the customer_overrides.properties file, see the
Selling and Fulfillment Foundation: Properties Guide.
For more information about statistics persistence, see the 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 appendix 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

Time-Triggered Transaction Reference 471

 Return Order. Therefore, in order to be able to configure Purge Return,
you should look for the PURGE transaction ID in this appendix, which is
Order Purge.
Selling and Fulfillment Foundation provides the following types of
time-triggered transactions:
Q
Business Process Time-Triggered Transactions - responsible for
processing
Q
Time-Triggered Purge Transactions - clear out data that may be
discarded after having been processed
Q
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.
Q
Monitors - watch and send alerts for processing delays and exceptions
Selling and Fulfillment Foundation tracks the following statistics for each
time-triggered transaction:
Q
ExecuteMessageCreated - The number of jobs added to the JMS
queue in a given time interval.
Q
ExecuteMessageSuccess - The number of jobs that were run
successfully in a given time interval.
Q
ExecuteMessageError - The number of jobs that failed to run in a
given time interval.
Q
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.0 for time-triggered transactions, monitors, and
integration and application servers may change with the
next release of Selling and Fulfillment Foundation.

472 Configuration Guide

 Running Time-Triggered Transactions

A.1 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 Selling
and Fulfillment Foundation: Installation Guide. For more information
about fine-tuning system performance while running them concurrently,
see the Selling and Fulfillment Foundation: Performance Management
Guide.

A.1.1 Steps to Complete Before Scheduling Time-Triggered

Transactions
Before running and scheduling a time-triggered transaction, ensure that
you have completed the following:
1. Configure a JMS Connection Factory to correlate with the QCF name
configured for the time-triggered transaction. The Selling and
Fulfillment Foundation factory defaults include the AGENT_QCF as the
JMS Connection Factory. For more information about configuring JMS,
see the documentation for your specific application server.
2. Configure JMS Server Destinations to correlate with the group or
individual name of the time-triggered transaction. The Selling and
Fulfillment Foundation factory defaults include the
DefaultAgentQueue as the server destination.

Note: Do not put a dot (.) in the name of a JMS Server

Destination, for example,’A.0001’. If you do, Selling and
Fulfillment Foundation is unable to communicate with it.

3. Using the Applications Manager, configure each time-triggered

transaction required for your business process as described in the
section entitled "Defining Transactions" in the 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.

Time-Triggered Transaction Reference 473

Configuring Communication Between an Agent and a JMS Server

A.2 Configuring Communication Between an

Agent and a JMS Server
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:
Q
If an initial context factory code for your JMS system is not provided
with the application, you must create one. See See “Create an Initial
Context Factory Code” on page A-475. for the list of codes that are
provided.
Q
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 Section A.2.3,
"Define the Transaction Information".
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.

A.2.1 Prerequisites
Before starting, complete these tasks for your JMS Server. See your JMS
Server documentation for more information about performing these
tasks.
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:
– JNDI name for each queue
– JNDI QCF lookup
– JMS location - the provider URL for the JMS server
Once you have completed the preceding tasks, complete the next two
procedures in the order shown. These are both done in the application.

474 Configuration Guide

 Configuring Communication Between an Agent and a JMS Server

A.2.2 Create an Initial Context Factory Code

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:
Q
IBM WebSphere MQ (for MQSeries accessed through a IBM
WebSphere Internet Inter-ORB Protocol URL)
Q
File (for MQSeries accessed through a file URL, as with Oracle
WebLogic)
Q
Oracle WebLogic (for WebLogic JMS)
Q
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:
1. Open the Configurator. 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 Section A.2.3, "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.
For more information about ICFs, see Creating an Initial Context Factory
Code.

Time-Triggered Transaction Reference 475

Configuring Communication Between an Agent and a JMS Server

A.2.3 Define the Transaction Information

For the JMS server to communicate with the application, there must be a
time-triggered transaction configured with the JMS server and ICF
information.
1. Open the Configurator. 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 Section A.2.1, "Prerequisites".
10. Enter the desired number of threads the agent should run
(recommended not to exceed 5 threads - if more than 5 are needed,
start another agent in its own JVM).
11. Select the Initial Context Factory code you created. See
Section A.2.2, "Create an Initial Context Factory Code".
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 Section A.2.1, "Prerequisites".
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).

476 Configuration Guide

 Business Process Time-Triggered Transactions

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.
For additional information about defining transactions and about this
procedure, see the sections, Defining Transactions and Specifying a
Transaction as Time-Triggered in the Selling and Fulfillment Foundation:
Application Platform Configuration Guide.

A.3 Business Process Time-Triggered

Transactions
This section provides an alphabetical list of all business process
transactions.

Note: Some of the statistics collected and tracked in

Release 9.0 for time-triggered transactions, monitors, and
integration and application servers may change with the
next release of Selling and Fulfillment Foundation.

Note: All Business Process Time-Triggered Transactions

have a CollectPendingJobs criteria parameter. If this
parameter is set to N, the agent does not collect
information about the pending jobs pertaining to this
monitor. This pending job information is used for
monitoring the monitor in the System Management
Console.
By default, CollectPendingJobs is set to Y. It can be
helpful to set it to N if one particular time-triggered
transaction is performing a significant amount of
getPendingJobs queries, and the overhead cost is too
high.

Time-Triggered Transaction Reference 477

Business Process Time-Triggered Transactions

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

Attributes
Following are the attributes for this time-triggered transaction:

Table A–1 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 A–2 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 Optional. Number of records to retrieve and
To Buffer process at one 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.

478 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–2 Asynchronous Request Processor Parameters

Parameter Description
Maximum Error Maximum number of times the record is
Count 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 Time in minutes after which the transaction will
In Minutes be reprocessed - after it has been processed and
has thrown an exception.
ColonyID Required in a multischema deployment where the
YFS_ASYNC_REQ table may exist in multiple
schemas. Runs the agent for the colony.

Statistics Tracked
None

Pending Job Count

None

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

Table A–3 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

Time-Triggered Transaction Reference 479

Business Process Time-Triggered Transactions

A.3.2 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 Selling and Fulfillment Foundation: Extending the
Database Guide.
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 A–4 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

480 Configuration Guide

 Business Process Time-Triggered Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–5 Case Insensitive Data Loader Criteria Parameters

Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one time.
Q
If left blank or the number specified is less
than 10000, it defaults to 5000.
Q
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.

Time-Triggered Transaction Reference 481

Business Process Time-Triggered Transactions

Pending Job Count

None.

Events Raised
None.

A.3.3 Change Load Status

This transaction is equivalent to the changeLoadStatus() API. For
detailed information about this transaction, see the 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.

Note: This transaction should be configured to work from

the task queue.

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

Table A–6 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()

482 Configuration Guide

 Business Process Time-Triggered Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–7 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 Optional. Number of records to retrieve and
To Buffer process at one 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 A–8 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 Selling and Fulfillment Foundation:
Javadocs.

Time-Triggered Transaction Reference 483

Business Process Time-Triggered Transactions

A.3.4 Change Shipment Status

This transaction is equivalent to the changeShipmentStatus() API. For
detailed information about this transaction, see the Selling and
Fulfillment Foundation: Javadocs.
To be configured as part of your shipment processing pipeline, this
transaction can be used whenever an automatic change in the status of a
shipment is required. For example, this automatic change could
represent exporting shipment information to a warehouse management
system or to transmit an Advance Shipping Notice to the buyer.

Note: This transaction should be configured to work from

the task queue.

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

Table A–9 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

484 Configuration Guide

 Business Process Time-Triggered Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–10 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 Optional. Number of records to retrieve and
To Buffer process at one 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 A–11 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 Selling and Fulfillment Foundation:
Javadocs.

Time-Triggered Transaction Reference 485

Business Process Time-Triggered Transactions

A.3.5 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 Section A.4.3.5, "Delivery Plan Purge").
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 A–12 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 A–13 Close Delivery Plan Criteria Parameters

Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.

486 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–13 Close Delivery Plan Criteria Parameters

Parameter Description
Number of Records Optional. Number of records to retrieve and
To Buffer process at one 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 A–14 Close Delivery Plan Statistics

Statistic Name Description
NumDeliveryPlansClosed Number of delivery plans closed.

Pending Job Count

For this transaction the pending job count is the number of records
available to be processed by the transaction with the AVAILABLE_DATE
value less than or equal to (<=) the current date value in the YFS_Task_
Q table.

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

Table A–15 Events Raised by Close Delivery Plan Transaction

Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS delivery_ YDM_CLOSE_ Yes
plan_dbd.txt DELIVERY_
PLAN.ON_
SUCCESS.xml

However, note that the template name would read <TransactionId>.ON_

SUCCESS.xml. The XML and DTD depicted above represent the output
that the abstract transaction CLOSE_DELIVERY_PLAN transaction is
capable of generating.

Time-Triggered Transaction Reference 487

Business Process Time-Triggered Transactions

A.3.6 Close Load

To boost system performance, this transaction serves as a temporary
purge until the Load Purge deletes load-related data (see
Section A.4.3.13, "Load Purge").
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.

Note: 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 A–16 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

488 Configuration Guide

 Business Process Time-Triggered Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–17 Close Load Parameters

Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Next Task Queue Optional. Specifies in hours how long a failed
Interval 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 A–18 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 A–19 Events Raised by the Close Load Transaction

Template
Transaction/Event Data Published Support?
ON_SUCCESS YDM_CLOSE_LOAD_PLAN.ON_ Yes
SUCCESS.xml

Time-Triggered Transaction Reference 489

Business Process Time-Triggered Transactions

However, note that the template name would read <TransactionId>.ON_

SUCCESS.xml. The XML and DTD represent the output of the abstract
transaction CLOSE_LOAD transaction.

A.3.7 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.
Q
Online mode: In the online mode, the close manifest transaction
runs as usual, confirming all shipments in the manifest and then
closing the manifest.
Q
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 Selling and Fulfillment
Foundation: Properties Guide.
The default out-of-the-box shipped property causes the Close Manifest
transaction to run in online mode.

Note: In instances where the Close Manifest transaction

is run in offline mode, ensure that all Agent Criteria
defined for the transaction are configured properly.

490 Configuration Guide

 Business Process Time-Triggered Transactions

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

Table A–20 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 A–21 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 Optional. Number of records to retrieve and
To Buffer process at one 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 WMS time-triggered transactions
that only perform their tasks on the nodes with a
matching node transactional velocity value.
Valid values are: LOW, HIGH, and any additional
values defined by the Hub from Application
Platform > System Administration > Agent
Criteria Groups.
ShipNode Optional. Ship node for which the Close Manifest
needs to be run. If not passed, then all ship
nodes are monitored.
ColonyID Required in a multischema deployment where a
table may exist in multiple schemas. Runs the
agent for the colony.

Time-Triggered Transaction Reference 491

Business Process Time-Triggered Transactions

Statistics Tracked
The following are statistics are tracked for this transaction:

Table A–22 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 A–23 Events Raised by the Close Manifest Transaction

Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS manifest_ YDM_CLOSE_ Yes
dbd.txt MANIFEST.ON_
SUCCESS.xml

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

492 Configuration Guide

 Business Process Time-Triggered Transactions

Note: The Close Order agent must be configured along

with the Purge transaction in the pipeline.

Note: The Close Order agent must be run before running

the Monitor agent in order to avoid alerts getting raised for
cancelled orders.

Note: 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 A–24 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

Time-Triggered Transaction Reference 493

Business Process Time-Triggered Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–25 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Next Task Queue Optional. Specifies in hours how long a failed
Interval 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 A–26 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.

494 Configuration Guide

 Business Process Time-Triggered Transactions

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

Table A–27 Events Raised by the Close Order Transaction

Transaction/Event Data Published Template Support?
ON_SUCCESS YFS_CLOSE_ORDER.ON_ Yes
SUCCESS.xml

A.3.9 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 A–28 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, Sales Order Receipt)
Abstract Transaction No
APIs Called None
User Exits Called None

Time-Triggered Transaction Reference 495

Business Process Time-Triggered Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–29 Close Receipts Criteria Parameters

Parameter Description
Action Triggers the transaction. If left blank, it defaults
to Get, the only valid value.
Number of Records Number of records to retrieve and process at one
To Buffer time. If left 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 WMS time-triggered transactions
that only perform their tasks on the nodes with a
matching node transactional velocity value.
Valid values are: LOW, HIGH, and any additional
values defined by the Hub from Application
Platform > System Administration > Agent
Criteria Groups.
ColonyID Required in a multischema deployment where a
table may exist in multiple schemas. Runs the
agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–30 Close Receipts Statistics

Statistic Name Description
NumReceiptsClosed Number of receipts closed.

496 Configuration Guide

 Business Process Time-Triggered Transactions

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 A–31 Events Raised by the Close Receipts Transaction

Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS receipt_ YFS_RECEIPT_ Yes
dbd.txt COMPLETE.ON_
SUCCESS.xml

Troubleshooting Tip: 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:
Q
Manually create move requests for receipts that you
already received. For more information about creating
move requests, refer to the Sterling Warehouse
Management System: User Guide.
Q
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.

A.3.10 Close Shipment

To boost system performance, this transaction serves as a temporary
purge until the Shipment Purge deletes all shipment-related data (see
Section A.4.3.33, "Shipment Purge").
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

Time-Triggered Transaction Reference 497

Business Process Time-Triggered Transactions

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.

Note: 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 A–32 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 A–33 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.

498 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–33 Close Shipment Criteria Parameters

Parameter Description
Next Task Queue Optional. Specifies in hours how long a failed
Interval 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 A–34 Close Shipment Statistics

Statistic Name Description
NumShipmentsClosed Number of shipments closed.

Pending Job Count

For this transaction the pending job count is the number of records
available to be processed by the transaction with the AVAILABLE_DATE
value less than or equal to (<=) the current date value in the YFS_Task_
Q table.

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

Table A–35 Events Raised by the Close Shipment Transaction

Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS shipment_ YDM_CLOSE_ Yes
dbd.txt SHIPMENT.ON_
SUCCESS.xml

Time-Triggered Transaction Reference 499

Business Process Time-Triggered Transactions

A.3.11 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 A–36 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 A–37 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 Optional. Number of records to retrieve and
To Buffer process at one 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.

500 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–37 Collect Shipment Statistics Criteria Parameters

Parameter Description
AgentCriteriaGroup Optional. Used to classify nodes. This value can
be accepted by WMS time-triggered transactions
that only perform their tasks on the nodes with a
matching node transactional velocity value.
Valid values are: LOW, HIGH, and any additional
values defined by the Hub from Application
Platform > System Administration > Agent
Criteria Groups.
ColonyID Required in a multischema deployment where a
table may exist in multiple schemas. Runs the
agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–38 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 A–39 Events Raised by the Collect Shipment Statistics Transaction

Template
Transaction/Event Data Published Support?
ON_SUCCESS YDM_COLLECT_ No
STATISTICS.ON_
SUCCESS.xml

Time-Triggered Transaction Reference 501

Business Process Time-Triggered Transactions

A.3.12 Consolidate Additional Inventory

The Consolidate Additional Inventory time-triggered transaction
consolidates supply and demand from the YFS_INVENTORY_SUPPLY_
ADDNL and YFS_INVENTORY_DEMAND_ADDNL tables. Consolidation is
performed by summing up the quantities of additional supply and
demand in the YFS_INVENTORY_SUPPLY and YFS_INVENTORY_DEMAND
tables.
If no matching supply or demand is found, a new supply or demand is
created with the sum quantity of the changes in the YFS_INVENTORY_
SUPPLY_ADDNL and YFS_INVENTORY_DEMAND_ADDNL tables. After the
changes are applied, the records in the YFS_INVENTORY_SUPPLY_ADDNL
and YFS_INVENTORY_DEMAND_ADDNL tables that were used in the
consolidation process, are deleted.

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

Table A–40 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

502 Configuration Guide

 Business Process Time-Triggered Transactions

Criteria Parameters
The following are the parameters for this transaction:
Table A–41 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 Optional. Number of inventory item records
To Buffer (whose 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 A–42 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.

Time-Triggered Transaction Reference 503

Business Process Time-Triggered Transactions

Events Raised
None.

A.3.13 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:
Q
Shipment Created
Q
ESP Check Required
Q
On ESP Hold
Q
Released from ESP Hold
Q
Released For Routing
Q
Awaiting Routing
Q
Shipment Routing
Q
Sent To Node
Q
Shipment Being Picked

504 Configuration Guide

 Business Process Time-Triggered Transactions

Troubleshooting Tip: 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.

For more information, see the details provided under the

createShipment(), changeShipment(), and releaseOrder() APIs in the
Selling and Fulfillment Foundation: Javadocs.

Note: This transaction is a part of the Order Fulfillment

pipeline. In addition, it should be configured to work from
the task queue.

Note: Order releases with GIFT_FLAG set to Y are never

consolidated with any other release.

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

Table A–43 Consolidate to Shipment Attributes

Attribute Value
Base Transaction ID CONSOLIDATE_TO_SHIPMENT
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No

Time-Triggered Transaction Reference 505

Business Process Time-Triggered Transactions

Table A–43 Consolidate to Shipment Attributes

Attribute Value
APIs Called createShipment() and changeShipment()
User Exits Q
It calls beforeConsolidateToShipment in
com.yantra.ydm.japi.ue.
Q
YDMBeforeConsolidateToShipment for each
release before it begins processing.
Q
After it finds the shipments, it calls
determineShipmentToConsolidateWith in
com.yantra.ydm.japi.ue.YDMDetermineShipm
entToConsolidateWith. For more information,
see the Selling and Fulfillment Foundation:
Javadocs.

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–44 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Next Task Queue Optional. Specifies in hours how long a failed
Interval 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.

506 Configuration Guide

 Business Process Time-Triggered Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–45 Consolidate to Shipment Statistics

Statistic Name Description
NumOrderReleasesConsolida Number of order releases consolidated.
ted

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 A–46 Events Raised by the Consolidate to Shipment Transaction

Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS shipment_ YDM_ Yes
dbd.txt CONSOLIDATE_TO_
SHIPMENT.ON_
SUCCESS.xml

Note: This transaction also raises events as specified under the

createShipment() and changeShipment() APIs in the Selling and
Fulfillment Foundation: Javadocs.
However, note that the template name would read <TransactionId>.ON_
SUCCESS.xml.The XML and DTD depicted above represent the output
that the abstract transaction CONSOLIDATE_TO_SHIPMENT transaction is
capable of generating.

Time-Triggered Transaction Reference 507

Business Process Time-Triggered Transactions

A.3.14 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 Selling and Fulfillment Foundation database or from an external
source.
The Create Catalog Index transaction can be configured to perform the
following tasks:
Q
Run either a scheduled index build or user-initiated index build
Q
Build either a full or incremental index file
Q
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 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:
Q
Queries the Selling and Fulfillment Foundation database or an
external source for data about the item.
Q
Uses information from the XML configuration file and extension file to
determine the data that be retrieved from the query.
Q
Retrieves relevant data from the Selling and Fulfillment Foundation
database.

508 Configuration Guide

 Business Process Time-Triggered Transactions

Q
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:
Q
Build the index on a shared, central disk that is accessible from all
servers.
Q
Advantages:
– Centralized control of shared index
– No file transfer issues because the index is not copied across
multiple servers
Q
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
Q
Build and push a copy of the index and all the files under the index
path folder 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.
Q
Advantage:
– No central point of failure
Q
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 Selling and Fulfillment
Foundation: Properties Guide for information about enabling different
properties for individual processes.

Time-Triggered Transaction Reference 509

Business Process Time-Triggered Transactions

For more information about building and searching catalog indexes, see
the Catalog Management: Concepts Guide.

Attributes
Table A–47 displays the attributes for the Create Catalog Index
transaction.

Table A–47 Create Catalog Index

Attribute Value
Base Transaction ID Create_Catalog_Index
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YCMParseAssetUE
YCMGetAdditionalCatalogIndexInformationUE

Criteria Parameters
Table A–48 displays the criteria parameters for the Create Catalog Index
transaction.

510 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–48 Create Catalog Index

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.
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,
Selling and Fulfillment Foundation processes only
3 messages at a time. For more information
about fine-tuning system performance, see the
Selling and Fulfillment Foundation: Performance
Management Guide.
Incremental Build Y or N.
Y to rebuild the existing index file. If you specify
Y, Selling and Fulfillment Foundation rebuilds the
index based on the last successful index build.
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.

Time-Triggered Transaction Reference 511

Business Process Time-Triggered Transactions

Table A–48 Create Catalog Index

Parameter Description
Auto Insert Search Y or N. Optional.
Index 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 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 Business
Center.
After a scheduled or user-initiated build runs, the
user can activate the index from the 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.

512 Configuration Guide

 Business Process Time-Triggered Transactions

Statistics Tracked
Table A–49 shows the statistics that are tracked for the Create Catalog
Index transaction.

Table A–49 Create Catalog Index

Statistic Name Description
SearchIndicesBuilt Number of search indices that have been
built.

Pending Job Count

None.

Events Raised
None.

A.3.15 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 Selling
and Fulfillment Foundation: Javadocs.
This transaction should be invoked after order scheduling.

Time-Triggered Transaction Reference 513

Business Process Time-Triggered Transactions

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

Table A–50 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 A–51 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Next Task Queue Optional. Specifies in hours how long a failed
Interval 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.

514 Configuration Guide

 Business Process Time-Triggered Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–52 Create Chained Order Statistics

Statistic Name Description
NumOrdersProcessed Number of orders processed for creating
chained order.
NumOrdersCreated Number of chained orders created.

Note: 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 Selling and Fulfillment Foundation:
Javadocs.

A.3.16 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
Selling and Fulfillment Foundation: Javadocs.

Time-Triggered Transaction Reference 515

Business Process Time-Triggered Transactions

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

Table A–53 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()

Note: The TransactionKey posted in the task queue object

must be an instance of the Abstract Transaction DERIVED_
ORDER_CREATE for the ProcessType associated with the
Order. Otherwise, an exception is thrown.

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–54 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Next Task Queue Optional. Specifies in hours how long a failed
Interval 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.

516 Configuration Guide

 Business Process Time-Triggered Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–55 Create Derived Order Statistics

Statistic Name Description
NumOrdersProcesse Number of orders processed.
d
NumOrdersCreated Number of derived orders created.

Note: 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 Selling and Fulfillment Foundation:
Javadocs.

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

Time-Triggered Transaction Reference 517

Business Process Time-Triggered Transactions

Note: 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 Section A.3.18, "Create Shipment Invoice".

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

Table A–56 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 A–57 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 Optional. Number of records to retrieve and
To Buffer process at one 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.

518 Configuration Guide

 Business Process Time-Triggered Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–58 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 Selling and Fulfillment Foundation:
Javadocs.

A.3.18 Create Shipment Invoice

Invoicing is mandatory if an order requires payment processing.
Invoicing occurs if the following conditions are met:
Q
Invoicing is enabled at the document parameter level.
Q
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.

Time-Triggered Transaction Reference 519

Business Process Time-Triggered Transactions

Note: 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 Section A.3.17, "Create Order
Invoice".

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

Table A–59 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 A–60 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 Optional. Number of records to retrieve and
To Buffer process at one 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.

520 Configuration Guide

 Business Process Time-Triggered Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–61 Create Shipment Invoice Statistics

Statistic Name Description
NumShipmentInvoicesCreate Number of shipment invoices created.
d

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 Selling and Fulfillment Foundation:
Javadocs.

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

Time-Triggered Transaction Reference 521

Business Process Time-Triggered Transactions

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

Table A–62 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 A–63 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 Optional. Number of records to retrieve and
to Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Next Task Queue Optional. Specifies in hours how long a failed task
Interval 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.

522 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–63 ESP Evaluator Criteria Parameters

Parameter Description
AgentCriteriaGroup Optional. Used to classify nodes. This value can
be accepted by WMS 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 A–64 Events Raised by ESP Evaluator Transaction

Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS shipment_ ESP_ Yes
dbd.txt EVALUATOR.ON_
SUCCESS.xml

Time-Triggered Transaction Reference 523

Business Process Time-Triggered Transactions

A.3.20 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:
Q
IBA_RUN_REQUIRED = "Y"
Q
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 Selling and Fulfillment Foundation:
Application Platform Configuration Guide. This rule is used to indicate
the interval that the Item Based Allocation agent should not
reprocess the triggers in the YFS_IBA_TRIGGER table, which were
processed earlier. This prevents the IBA agent from over-processing
the item and node combination in the given time interval to avoid any
high loads on the system.
Q
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.
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.

524 Configuration Guide

 Business Process Time-Triggered Transactions

Note: The following configuration is required for the Item

Based Allocation process:
Q
The Use Item Based Allocation rule needs to be
enabled.
Q
Item and node need to have Item Based Allocation
Allowed enabled.
Q
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 Selling and Fulfillment
Foundation: Javadocs.

Note: 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 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:
Q
PROCESSING_BY_AGENT = “Y”. This indicates that an instance of the
agent is currently processing this trigger.
Q
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.
Selling and Fulfillment Foundation treats the PROCESSING_BY_
AGENT flag as “N” regardless of the actual value when current
timestamp is after this timestamp.
Q
IBA_RUN_REQUIRED = ”N”. This resets the IBA_RUN_REQUIRED flag
back to “N”.

Time-Triggered Transaction Reference 525

Business Process Time-Triggered Transactions

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:
Q
Demands of chained orders
Q
Demands of orders with chained order already created
Q
Demands of orders with procurement node but chained order creation
is not yet created
Q
Demands of orders without procurement node
Q
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 Global Inventory Visibility:
Configuration Guide.

Obtaining a List of Available Supplies for Allocation

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 Global Inventory Visibility: Configuration Guide.

Note: Allocated demands should be matched with the

same supplies as "Demand to look for during release".

526 Configuration Guide

 Business Process Time-Triggered Transactions

Matching Demands Against Supplies in FIFO

(First-In-First-Out) Order
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:
Q
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).
Q
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).
Q
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.
Q
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.
Q
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.
Q
Demands from inventory reservations in the order of ship date.
Notice that different types of demands are given different priorities based
on their significance. The demands of chained orders or orders related to
chained orders are treated with a higher priority than the demands of
normal orders. Furthermore, the demands with a ship date within the
advanced notification time window also have a higher priority than the
demands with a date outside of the advanced notification time window.

Time-Triggered Transaction Reference 527

Business Process Time-Triggered Transactions

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:
Q
IBA_REQUIRED = "N"
Q
LAST_IBA_PROCESSED_TS = current timestamp.
Q
PROCESS_OVER_BY_TS = current timestamp.
Q
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 A–65 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

528 Configuration Guide

 Business Process Time-Triggered Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–66 Item Based Allocation Criteria Parameters

Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
InventoryOrganizati The inventory organization code of the inventory
onCode items which 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.

Time-Triggered Transaction Reference 529

Business Process Time-Triggered Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–67 Item Based Allocation Statistics

Statistic Name Description
NumOrdersProcessed Number of orders processed by the Item
Based Allocation agent.
NumOrdersRequiredResched Number of orders required rescheduling
ule 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 Selling and Fulfillment Foundation: Javadocs.

A.3.21 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 A–68 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

530 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–68 Mark Load As Trailer Loaded Attributes

Attribute Value
APIs Called None
User Exits Called None

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–69 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 Optional. Number of records to retrieve and
To Buffer process at one 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 A–70 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.

Time-Triggered Transaction Reference 531

Business Process Time-Triggered Transactions

Events Raised
None.

A.3.22 Match Inventory

Match Inventory processes all pending records in the YFS_INVENTORY_
SHIPMENT table. Pending records have a smaller number in POSTED_
QUANTITY than in QUANTITY.
Each pending record is matched against the receipt records in YFS_
INVENTORY_RECEIPT table by applying the inventory cost determination
logic. The unit cost at which the sales and receipt data are matched is
also posted in YFS_INVENTORY_MATCH table.
Use this transaction if any of the configured ship nodes maintain
inventory cost.

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

Table A–71 Match Inventory Attributes

Attribute Value
Base Transaction ID INVENTORY_MATCH
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

532 Configuration Guide

 Business Process Time-Triggered Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–72 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 Optional. Number of records to retrieve
Buffer 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 A–73 Match Inventory Statistics

Statistic Name Description
NumInventoryShipmentsProc Number of inventory shipments
essed processed.
NumInventoryMatchesInsert Number of inventory matches inserted.
ed

Time-Triggered Transaction Reference 533

Business Process Time-Triggered Transactions

Pending Job Count

For this transaction the pending job count is the number of distinct
inventory items that exist in the YFS_INVENTORY_SHIPMENT table where
the QUANTITY value is not equal to the POSTED_QUANTITY value.

Events Raised
None.

A.3.23 Payment Collection

This transaction requests credit validation for orders that are pending
authorization or charging.
Use this transaction for creating authorization and charge requests.

Note: 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
Section A.3.24, "Payment Execution".

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

Table A–74 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()

534 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–75 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 A–76 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
EnterpriseCode Optional. The enterprise for which the transaction
needs to be run. If left blank, orders for all
enterprises are processed. If specified, only
orders for that enterprise are processed.
ColonyID Required in a multischema deployment where a
table may exist in multiple schemas. Runs the
agent for the colony.

Time-Triggered Transaction Reference 535

Business Process Time-Triggered Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–77 Payment Collection Statistics

Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumChargeReqsCreated Number of charge requests created.
NumAuthorizationReqsCreate Number of authorization requests
d 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:
Q
AWAIT_PAY_INFO
Q
AWAIT_AUTH
Q
REQUESTED_AUTH
Q
REQUEST_CHARGE
Q
AUTHORIZED, INVOICED
Q
PAID
Q
RELEASE_HOLD
Q
FAILED_AUTH
Q
FAILED_CHARGE
Q
VERIFY
Q
FAILED

536 Configuration Guide

 Business Process Time-Triggered Transactions

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

Table A–78 Events Raised by the Payment Collection Transaction

Template
Transaction/Event Key Data Data Published Support?
INCOMPLETE_ modifyOrde YFS_PAYMENT_ Yes
PAYMENT_ r_dbd.txt COLLECTON.INCOMPLE
INFORMATION TE_PAYMENT_
INFORMATION.xml
PAYMENT_STATUS YFS_ YFS_PAYMENT_ Yes
PAYMENT_ COLLECTION.PAYMENT
COLLECTIO _STATUS.xml
N.PAYMENT
_STATUS_
dtd.txt
REQUEST_ YFS_PAYMENT_ Yes
PAYMENT_STATUS COLLECTION.REQUEST
_PAYMENT_STATUS.xml
ON_LIABILITY_ modifyOrde YFS_PAYMENT_ Yes
TRANSFER r_dbd.txt COLLECTION.ON_
LIABILITY_
TRANSFER.xml
ON_INVOICE_ order_ YFS_CREATE_ORDER_ Yes
COLLECTION dbd/txt INVOICE.ON_INVOICE_
COLLECTION.xml

A.3.24 Payment Execution

This transaction processes all requests that are pending authorization
and charging.

Note: Use this time-triggered transaction for processing

all authorization and charge requests.
This transaction requires interfacing with a product that
provides financial services.

Time-Triggered Transaction Reference 537

Business Process Time-Triggered Transactions

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

Table A–79 Payment Execution Attributes for Sales Orders

Attribute Value
Base Transaction ID PAYMENT_EXECUTION
Base Document Type Order
Base Process Type Order Fulfillment
Abstract Transaction No
APIs Called executeCollection()
User Exits Called collectionCreditCard, collectionOthers,
collectionCustomerAcct

Table A–80 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

538 Configuration Guide

 Business Process Time-Triggered Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–81 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
ChargeType Type of credit card process. Valid values are:
Q
AUTHORIZATION - Validates the credit card
account
Q
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 A–82 Payment Execution Statistics

Statistic Name Description
NumAuthTransProcessed Number of authorization transaction
processed.
NumAuthTransSuccessfullyProces Number of successful returns from
sed user exit for authorization
transaction processed.
NumChargeTransProcessed Number of charge transaction
processed.
NumChargeTransSuccessfullyProc Number of successful returns from
essed user exit for charge transaction
processed.

Time-Triggered Transaction Reference 539

Business Process Time-Triggered Transactions

Table A–82 Payment Execution Statistics

Statistic Name Description
NumCollectionValidations Number of successful returns from
the invoked validate collection user
exits.
NumCreditCardCollections Number of credit card collections.
NumCustomerAccountCollections Number of successful returns from
the customer account collection user
exits.
NumOtherCollections Number of successful returns from
the other collection user exits.

Pending Job Count

For this transaction the pending job count is the number of open charge
and authorization transactions.

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

Table A–83 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 Selling and Fulfillment Foundation:
Javadocs.

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

540 Configuration Guide

 Business Process Time-Triggered Transactions

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 A–84 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 A–85 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 Optional. Number of records to retrieve and
To Buffer 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_MATCH table may exist in
multiple schemas. Runs the agent for the colony.

Time-Triggered Transaction Reference 541

Business Process Time-Triggered Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–86 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 A–87 Events Raised by the Post Inventory Match Transaction

Template
Transaction/Event Key Data Data Published Support?
POST_INVENTORY_MATCH POST_ YFS_ No
INVENTORY_ postInventoryMa
MATCH_ tch_output.xml
dbd.txt

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

542 Configuration Guide

 Business Process Time-Triggered Transactions

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 Selling and Fulfillment Foundation: Javadocs.

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

Table A–88 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 A–89 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.

Time-Triggered Transaction Reference 543

Business Process Time-Triggered Transactions

Table A–89 Process Order Hold Type Parameters

Parameter Description
Next Task Queue Optional. Specifies in hours how long a failed task
Interval 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 A–90 Events Raised by Process Order Hold Type Transaction

Transaction/Ev Raised Data Template
ent when... Key Data Published Support?
ON_SUCCESS On success modifyOrde YFS_ORDER_ Yes *
r_dbd.txt CHANGE.ON
_
SUCCESS.xm
l
ON_HOLD_ The status of modifyOrde YFS_ON_ Yes
TYPE_STATUS_ a hold type is r_dbd.txt HOLD_TYPE_
CHANGE changed. STATUS_
CHANGE.xml

544 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–90 Events Raised by Process Order Hold Type Transaction

Transaction/Ev Raised Data Template
ent when... Key Data Published Support?
ON_ORDER_ The status of modifyOrde YFS_ON_ Yes
LINE_HOLD_ a hold type is r_dbd.txt ORDER_
TYPE_STATUS_ changed. LINE_HOLD_
CHANGE TYPE_
STATUS_
CHANGE.xml
* Note: Some of the elements and attributes are not template-driven.
Refer to the xml for element level details.

A.3.27 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 A–91 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

Time-Triggered Transaction Reference 545

Business Process Time-Triggered Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–92 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Next Task Queue Optional. Specifies in hours how long a failed task
Interval 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

546 Configuration Guide

 Business Process Time-Triggered Transactions

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

Table A–93 Events Raised by Process Work Order Hold Type Transaction
Transaction/Ev Raised Data Template
ent when... Key Data Published Support?
ON_SUCCESS On success workOrder_ VAS_ Yes *
dbd.txt MODIFY_
WORK_
ORDER.ON_
SUCCESS.xm
l
ON_HOLD_ The status of workOrder_ VAS_ON_ Yes
TYPE_STATUS_ a hold type is dbd.txt HOLD_TYPE_
CHANGE changed. STATUS_
CHANGE.xml
* Note: Some of the elements and attributes are not template driven.
Refer to the xml for elements level details.

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

Note: This transaction needs to be run after negotiation is

completed.

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

Table A–94 Publish Negotiation Results Attributes

Attribute Value
Base Transaction ID PUBLISH_ORD_NEGOTIATION
Base Document Type Order
Base Process Type Order Negotiation

Time-Triggered Transaction Reference 547

Business Process Time-Triggered Transactions

Table A–94 Publish Negotiation Results Attributes

Attribute Value
Abstract Transaction No
APIs Called None

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–95 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Next Task Queue Optional. Specifies in hours how long a failed
Interval 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 A–96 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

548 Configuration Guide

 Business Process Time-Triggered Transactions

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 A–97 Events Raised by Publish Negotiation Results Transaction

Base Raised Data Template
Transaction when... Key Data Published Support?
PUBLISH_ On success Negotiation YCP_ Yes *
ORD_ _dbd.txt getNegotiatio
NEGOTIATION/ nDetails_
ON_SUCCESS output.xml
RECEIVE_ On success, Number of receiveOrder No
ORD_ when concurrent Negotiation_
NEGOTIATION/ DocumentTyp time-trigger dbd.txt
ON_SUCCESS e is 0001, ed
EntityType is transactions
ORDER. running.
* Note: Template used for this event is the same template used by the
getNegotiationDetails() API to form the output XML.

A.3.29 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 Selling and Fulfillment Foundation: Javadocs.

Important: Sterling Commerce recommends that if you

run the combined ‘Schedule and Release’ agent, you do
not also run the individual Schedule or the individual
Release agents.

Time-Triggered Transaction Reference 549

Business Process Time-Triggered Transactions

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

Table A–98 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 A–99 Release Criteria Parameters

Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one 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:
Q
Y - Releases line quantities regardless of
release date criteria
Q
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:
Q
Y - Default value. Inventory needs to be
checked.
Q
N - Inventory does not need to be checked.

550 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–99 Release Criteria Parameters

Parameter Description
Next Task Queue Optional. Specifies in hours how long a failed
Interval 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 A–100 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.
NumOrdersCannotBeProcess Number of orders did not attempt to
edFailures release because of cannot be processed
failures.
NumOrdersProcessed Number of orders processed.
NumOrdersReleased Number of orders released.
NumOrdersBackordered Number of orders backordered.
NumOrderLinesReleased Number of order lines released.
NumOrderLinesBackordered Number of order lines backordered.
NumReleasesCreated Number of order releases created.
NumOrdersCannotBeProcess Number of orders that were not released
edFailures due to process failure.

Note: If the release process results in splitting of an order line,

NumOrderLinesReleased, NumOrderLinesBackordered, and
NumOfReleasesCreated may result in more than one count.

Time-Triggered Transaction Reference 551

Business Process Time-Triggered Transactions

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, [DOM71-06]if tasks on hold are not ready to be
processed.[/DOM71-06]

Events Raised

This transaction raises events as specified under the releaseOrder() API

in the Selling and Fulfillment Foundation: Javadocs.

A.3.30 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:
Q
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.
Q
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.

552 Configuration Guide

 Business Process Time-Triggered Transactions

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

Table A–101 Route Shipment

Attribute Value
Base Transaction ID ROUTE_SHIPMENT.0001
Base Document Type Order
Base Process Type ORDER_DELIVERY
Abstract Transaction No
APIs Called None
User Exits Called com.yantra.ydm.japi.ue.YDMOverrideDetermi
neRoutingUE
com.yantra.ydm.japi.ue.YDMBeforeDetermine
RoutingUE

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–102 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Next Task Queue Optional. Specifies in hours how long a failed task
Interval should be suspended before it is considered for
reprocessing. Defaults to 5 hours.

Time-Triggered Transaction Reference 553

Business Process Time-Triggered Transactions

Table A–102 Route Shipment Criteria Parameters

Parameter Description
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 A–103 Route Shipment Statistics

Statistic Name Description
NumRouted Number of shipments routed.

Pending Job Count

For this transaction the pending job count is the number of records
representing the unheld orders that are available to be processed by the
transaction with the AVAILABLE_DATE value less than or equal to (<=)
the current date value in the YFS_Task_Q table.

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

Table A–104 Events Raised by the Route Shipment Transaction

Template
Transaction/Event Key Data Data Published Support?
ON_SUCCESS shipment_ YDM_ROUTE_ Yes
dbd.txt SHIPMENT.ON_
SUCCESS.xml
ON_FAILURE shipment_ YDM_ROUTE_ Yes
dbd.txt SHIPMENT.ON_
FAILURE.xml

554 Configuration Guide

 Business Process Time-Triggered Transactions

However, note that the template name would read <TransactionId>.ON_

SUCCESS.xml. The XML and DTD depicted above represent the output
that the abstract transaction ROUTE_SHIPMENT transaction is capable of
generating.

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

Important: It is recommended not to 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 A–105 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 A–106 Schedule Criteria Parameters

Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.

Time-Triggered Transaction Reference 555

Business Process Time-Triggered Transactions

Table A–106 Schedule Criteria Parameters

Parameter Description
OptimizationType Optional. Determines the optimization rules to
apply to the scheduling process. Valid values are:
Q
01 - Optimize on date (Default)
Q
02 - Optimize on ship node priority
Q
03 - Optimize on number of shipments
OrderFilter Optional. Determines the types of orders to filter.
Possible values are:
Q
A - All orders (Default)
Q
B - Backorders only
Q
N - New orders only
ScheduleAndRelease Optional. Notify the schedule process to release
all releasable line quantities. Valid values are:
Q
Y - Releases successfully scheduled line
quantities.
Q
N - Default value. Only schedules line
quantities.
Note: 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:
Q
Y - Releases line quantities regardless of
release date criteria.
Q
N - Releases lines quantities only after
release date criteria have been met. Default.
Next Task Queue Not used. This agent updates a failed task so
Interval 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.

556 Configuration Guide

 Business Process Time-Triggered Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–107 Schedule Statistics

Statistic Name Description
NumFutureDateFailures Number of orders that Selling and
Fulfillment Foundation did not attempt to
schedule because of future date failures.
Failures can be caused by any of the
following:
Q
If the OrderFilter is “B” (Backorders
Only) and there are no backordered
or unscheduled lines.
Q
If the OrderFilter is “N” (New orders
Only) and there are some
backordered or unscheduled lines.
Q
If order has order lines within only
backordered or unscheduled status
and the status modify timestamp is
after the current time - the back
order wait period specified in the
scheduling rule.
NumOrdersAttempted Number of orders attempted to
schedule. This statistic does not include
the values for NumFutureDateFailures
and
NumOrdersCannotBeProcessedFailures
statistics.
NumOrderLinesReleased Number of order lines that have been
released.

Time-Triggered Transaction Reference 557

Business Process Time-Triggered Transactions

Table A–107 Schedule Statistics

Statistic Name Description
NumOrdersCannotBeProcess Number of orders that Selling and
edFailures Fulfillment Foundation did not attempt to
schedule because of cannot be
processed failures.
Failures can be caused by any of the
following:
Q
The result of the
YFSCheckOrderBeforeProcessingUE
user exit returns as false.
Q
The Order has the HoldFlag attribute
set to ‘Y’.
Q
The Order has the SaleVoided
attribute set to ‘Y’.
Q
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.
Note: This includes scheduled lines in
any status except BACKORDER.
NumOrdersProcOrdersCreate Number of procurement orders created.
d
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.

558 Configuration Guide

 Business Process Time-Triggered Transactions

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, [DOM71-06]if tasks on
hold are not ready to be processed.[/DOM71-06]

Events Raised
This transaction raises events as specified under the scheduleOrder()
API in the Selling and Fulfillment Foundation: Javadocs.

Providing Oracle Hints

You can provide Oracle Hints to increase the performance of the
scheduleOrder agent. The two hints that can be provided for each criteria
ID of the scheduleOrder agent are the Outer Hint and the Inner Hint. The
Outer Hint is always used for the YFS_TASK_Q table. The Inner Hint is
used for the YFS_ORDER_HEADER table only if the earlier hold
functionality is used; otherwise, the Inner Hint is used for the YFS_
ORDER_RELEASE_STATUS table.
Insert the following entries in the yfs.properties file in order to enable
Oracle Hints:
1. Edit the <INSTALL_DIR>/properties/yfs.properties file.
2. Insert yfs.<agent_criteria_id>.getjobs.hint.outer=/*+
parallel(YFS_TASK_Q 8) full(yfs_task_q) */
Insert yfs.<agent_criteria_id>.getjobs.hint.inner=/*+ NL_SJ
*/

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

Time-Triggered Transaction Reference 559

Business Process Time-Triggered Transactions

an event for an invoice based on the following configuration at the

following times in the order lifecycle:
Q
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.
Q
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.

Note: 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 A–108 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()

560 Configuration Guide

 Business Process Time-Triggered Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–109 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 Optional. Number of records to retrieve and
To Buffer process at one 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 A–110 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 A–111 Events Raised by the Send Invoice Transaction

Template
Transaction/Event Key Data Data Published Support?
PUBLISH_INVOICE_ modifyOrder_ YFS_ Yes
DETAIL dbd.txt and getOrderInvoiceDet
sendInvoice_ ails_output.xml
dbd.txt

Time-Triggered Transaction Reference 561

Business Process Time-Triggered Transactions

Additional events may be raised by the getOrderInvoiceDetails() API.

For detailed information about the events, see the details provided under
this API in the Selling and Fulfillment Foundation: Javadocs.

A.3.33 Send Item Changes

In integrated environments, this transaction publishes item data changes
that are directed to an external system.
When item changes occur in Selling and Fulfillment Foundation, they
need to be communicated to the external system.
The business process may require the synchronization of items all at
once in a batch. For example, at the end of each business day, the
sendItemChanges agent can be configured to synchronize items based
on the synchronization logic. This transaction retrieves all items that are
not logical kit or dynamic physical kit items and whose SyncTS is null or
MaxModifyTS is greater than the SyncTS.

Note: 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
Selling and Fulfillment Foundation: Integration Guide.

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

Table A–112 Send Item Changes Attributes

Attribute Value
Base Transaction ID SEND_ITEM_CHANGES
Base Document Type None
Base Process Type General

562 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–112 Send Item Changes Attributes

Attribute Value
Abstract Transaction No
APIs Called None

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–113 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 Optional. Number of records to retrieve and
To Buffer process at one 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.

Time-Triggered Transaction Reference 563

Business Process Time-Triggered Transactions

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

Table A–114 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

A.3.34 Send Customer Changes

In integrated environments, this transaction publishes customer data
changes that are directed to an external system.
When customer changes occur in 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 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.

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

564 Configuration Guide

 Business Process Time-Triggered Transactions

For more information about how this integration is implemented, see the
Selling and Fulfillment Foundation: Integration Guide.

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

Table A–115 Send Customer Changes Attributes

Attribute Value
Base Transaction ID SEND_CUSTOMER_CHANGES
Base Document Type None
Base Process Type General
Abstract Transaction No
APIs Called None

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–116 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 Optional. Number of records to retrieve and
To Buffer process at one 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.

Time-Triggered Transaction Reference 565

Business Process Time-Triggered Transactions

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 A–117 Events Raised by the Send Customer Changes Transaction

Template
Transaction/Event Key Data Data Published Support?
SEND_CUSTOMER_ None YSC_SEND_ Yes
CHANGES.ON_ CUSTOMER_
SUCCESS CHANGES.ON_
SUCCESS.XML

A.3.35 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 Selling and Fulfillment Foundation: Javadocs.
If an order needs to be communicated to a third party, use this
transaction.

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

566 Configuration Guide

 Business Process Time-Triggered Transactions

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

Table A–118 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 A–119 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Next Task Queue Optional. Specifies in hours how long a failed
Interval 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

Time-Triggered Transaction Reference 567

Business Process Time-Triggered Transactions

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 Selling and Fulfillment Foundation: Javadocs.

A.3.36 Send Release

The Send Release Agent dispatches releases to ship nodes.

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

Table A–120 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 A–121 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.

568 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–121 Send Release Criteria Parameters

Parameter Description
Next Task Queue Optional. Specifies in hours how long a failed task
Interval 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 A–122 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 A–123 Events Raised by the Send Release Transaction

Transaction/Event Data Published
PUBLISH_SHIP_ADVICE YFS_publishShipAdvice_output.xml

Time-Triggered Transaction Reference 569

Business Process Time-Triggered Transactions

A.3.37 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 A–124 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 A–125 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Next Task Queue Optional. Specifies in hours how long a failed task
Interval should be suspended before it is considered for
reprocessing. Defaults to 5 hours.

570 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–125 Start Order Negotiation Criteria Parameters

Parameter Description
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 A–126 Start Order Negotiation Statistics

Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumNegotiationsCreated Number of negotiations created.

Pending Job Count

For this transaction the pending job count is the number of records
available to be processed by the transaction with the AVAILABLE_DATE
value less than or equal to (<=) the current date value in the YFS_Task_
Q table.

Events Raised
This transaction raises events as specified under the
createNegotiation() API in the Selling and Fulfillment Foundation:
Javadocs.

A.3.38 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
Selling and Fulfillment Foundation.
For more information about upgrading to multischema mode, see the
Platform Enterprise Onboarding for Multi-Tenancy Guide.

Time-Triggered Transaction Reference 571

Business Process Time-Triggered Transactions

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

Table A–127 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 A–128 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 Optional. Number of records to retrieve and
to Buffer process at one 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 Selling and Fulfillment
Foundation installation so that it populates the
PLT_COLONY_MAP table. After this, you can run
the agent on another ColonyID.
InsertDefaultMappin If set to Y, users for which the colony cannot be
gs determined will be mapped to the colony for
which the Colony Map Synchronizer agent is run.

Statistics Tracked
None.

572 Configuration Guide

 Business Process Time-Triggered Transactions

Pending Job Count

None.

Events Raised
None.

Tables Purged
None.

A.3.39 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:
Q
ADDRESS_LINE6
Q
CITY
Q
STATE
Q
SHORT_ZIP_CODE
Q
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 A–129 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

Time-Triggered Transaction Reference 573

Business Process Time-Triggered Transactions

Table A–129 Update Best Match Region Attributes

Attribute Value
APIs Called None
User Exits Called YSCGetShortZipCode UE

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–130 Update Best Match Region Criteria Parameters

Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one 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.

574 Configuration Guide

 Business Process Time-Triggered Transactions

Table A–130 Update Best Match Region Criteria Parameters

Parameter Description
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:
Q
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.
Q
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,
MatchKey LastRegionBestMatchKey determines the first
region best match key to update. If no key is
specified, the value defaults to Null.

Statistics Tracked
None.

Pending Job Count

None.

Events Raised
None.

Tables Purged
None.

Time-Triggered Transaction Reference 575

Business Process Time-Triggered Transactions

A.3.40 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 A–131 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 A–132 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 Optional. Number of records to retrieve and
To Buffer process at one 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.

576 Configuration Guide

 Time-Triggered Purge Transactions

Statistics Tracked
None
Pending Job Count
None
Events Raised
None

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

Note: In some cases, a purge may look at another field

other than the table’s timestamp. These are pointed out in
the documentation.

Note: When an entity is being purged, the related or

dependent information that is present in other tables
should be taken into consideration for purging along with
it. For example, if a sales order with live shipments is
being purged, any cross reference to that order is not
accurate in the Order Shipment Console.

Note: Some of the statistics collected and tracked in

Release 9.0 for time-triggered transactions, monitors, and
integration and application servers may change with the
next release of Selling and Fulfillment Foundation.

Time-Triggered Transaction Reference 577

Time-Triggered Purge Transactions

Note: All Time-Triggered Purge Transactions have a

CollectPendingJobs criteria parameter. If this parameter
is set to N, the agent does not collect information on the
pending jobs for that time-triggered transaction. This
pending job information is used for monitoring the monitor
in the System Management Console.
By default, CollectPendingJobs is set to Y. It can be
helpful to set it to N if one particular time-triggered
transaction is performing a significant amount of
getPendingJobs queries, and the overhead cost is too
high.

A.4.1 Purge Strategy

The following recommendations should be taken into consideration when
planning a purge strategy for each purge transaction:
Q
Test purges by setting Live to ’N’.
Q
Turn on logging to test what is purged.
Q
Set up purge traces in the System Management Console and analyze
the information.

A.4.2 Configuring Purge Transaction Log Files

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

578 Configuration Guide

 Time-Triggered Purge Transactions

A.4.3 Available Purges

This section contains details of all purge transactions in alphabetical
order. The time-triggered purge transactions are:
Q
Access Token Purge
Q
Capacity Purge
Q
Draft Order History Purge
Q
Draft Order Purge
Q
Delivery Plan Purge
Q
Export Table Purge
Q
Import Table Purge
Q
Inventory Audit Purge
Q
Inventory Purge
Q
Inventory Supply Temp Purge
Q
Item Audit Purge
Q
Load History Purge
Q
Load Purge
Q
Negotiation History Purge
Q
Negotiation Purge
Q
Opportunity History Purge
Q
Opportunity Purge
Q
Order History Purge
Q
Order Purge
Q
Order Release Status Purge
Q
Order Status Audit Purge
Q
Organization Audit Purge
Q
Person Info Purge
Q
Person Info History Purge
Q
Picklist Purge

Time-Triggered Transaction Reference 579

Time-Triggered Purge Transactions

Q
Price List Purge
Q
Purge Catalog Mass Audits
Q
Receipt History Purge
Q
Receipt Purge
Q
Reprocess Error Purge
Q
Reservation Purge
Q
Shipment History Purge
Q
Shipment Purge
Q
Shipment Statistics Purge
Q
User Activity Purge
Q
User Activity Audit Purge
Q
Work Order History Purge
Q
Work Order Purge
Q
YFS Audit Purge
Q
YFSInventoryOwnershipAudit Purge
Q
Password Reset Request Purge
Q
User Login Failure Purge

A.4.3.1 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:
Q
The access token is expired or is in inactive state.
Q
The last modified date is earlier than or equal to the current date
minus the purge criteria’s retention days.

580 Configuration Guide

 Time-Triggered Purge Transactions

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

Table A–133 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 A–134 Access Token Purge Criteria Parameters

Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
CollectPendingJobs If this parameter is set to N, the agent does not
collect information on the pending jobs for this
monitor. This pending job information is used for
monitoring the monitor in the .
Number of Records Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.

Time-Triggered Transaction Reference 581

Time-Triggered Purge Transactions

Table A–134 Access Token Purge Criteria Parameters

Parameter Description
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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 A–135 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

582 Configuration Guide

 Time-Triggered Purge Transactions

A.4.3.2 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:
Q
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.
Q
All resource pool overridden capacity with the capacity date earlier
than or equal to the current date minus the purge criteria’s retention
days.
Q
All resource pool capacity consumption with consumption date less
than or equal to the current date minus the purge criteria’s retention
days.
Q
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).
Q
All resource pool capacity consumption details where expiration date
has passed and reservation Id is not blank.

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

Table A–136 Capacity Purge Attributes

Attribute Value
Base Transaction ID CAPACITYPRG
Base Document Type General
Base Process Type General
Abstract Transaction No

Time-Triggered Transaction Reference 583

Time-Triggered Purge Transactions

Table A–136 Capacity Purge Attributes

Attribute Value
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters
The following are the criteria parameters for this transaction:
Table A–137 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as
0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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.

584 Configuration Guide

 Time-Triggered Purge Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–138 Capacity Purge Statistics

Statistic Name Description
NumStdCapacityPeriodsPurg Number of standard capacity periods
ed purged.
NumCapacityOverridesPurge Number of capacity overrides purged.
d
NumCapacityConsumptionsP Number of capacity consumptions
urged purged.

Pending Job Count

For this transaction the pending job count is the total number of records
that can be purged from the YFS_RES_POOL_STD_CAPCTY_PERD, YFS_
RES_POOL_CAPCTY_OVERRIDE, YFS_RES_POOL_CONSMPTN_DTLS and
YFS_RES_POOL_CAPCTY_CONSMPTN tables.

Events Raised
None.

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)

Time-Triggered Transaction Reference 585

Time-Triggered Purge Transactions

A.4.3.3 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:
Q
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 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 Section A.4.3.4, "Draft Order Purge".

Note: 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 Section A.4.3.19,
"Order Purge" for more information.

586 Configuration Guide

 Time-Triggered Purge Transactions

Criteria Parameters
The following are the criteria parameters for defining a draft order history
transaction:

Table A–139 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 Optional. Number of records to retrieve and
To Buffer process at one 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:
Q
Y - Default value. Removes qualifying records
from the history tables that are listed in
Tables Purged.
Q
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

Time-Triggered Transaction Reference 587

Time-Triggered Purge Transactions

YFS_ANSWER_TRAN_H
YFS_CHARGE_TRAN_DIST_H
YFS_CHARGE_TRANSACTION_H
YFS_CREDIT_CARD_TRANSACTION_H
YFS_ENTITY_ADDRESS_H
YFS_HEADER_CHARGES_H
YFS_INSTRUCTION_DETAIL_H
YFS_INVOICE_COLLECTION_H
YFS_LINE_CHARGES_H
YFS_NOTES_H
YFS_ORDER_AUDIT_DETAIL_H
YFS_ORDER_AUDIT_H
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

588 Configuration Guide

 Time-Triggered Purge Transactions

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

A.4.3.4 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
Section A.4.3.3, "Draft Order History Purge".

NOTE: 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
Section A.4.3.19, "Order Purge" 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:
Q
Draft order flag is set to Y.
Q
Modifyts is set for the retention date.

Time-Triggered Transaction Reference 589

Time-Triggered Purge Transactions

After the draft orders are picked up, each draft order is validated for
purging based on the following conditions:
Q
No eligible order release status records (records with a status larger
than zero) exist for the order.
Q
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:
Q
Contains the Draft Created (1000) status, and all the extended Draft
Created statuses.
Q
Does not have an order release status record that does not meet the
retention days.
Q
The order's last modification should be before the lead time (in days)
setup.
Q
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.
Q
In the case of an order line reservation, the draft order cannot be
purged.
Q
If the Draft Order Payment Processing flag is set to N, the draft
orders are purged.
Q
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.
Q
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.

590 Configuration Guide

 Time-Triggered Purge Transactions

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

Table A–140 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Next Task Queue Optional. Specifies (in hours) how long a failed
Interval 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.
Note: 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:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged, to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.

Time-Triggered Transaction Reference 591

Time-Triggered Purge Transactions

Table A–140 Draft Order Purge Criteria Parameters

Parameter Description
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
YFS_INSTRUCTION_DETAIL
YFS_INVOICE_COLLECTION
YFS_LINE_CHARGES
YFS_MONITOR_ALERT
YFS_NOTES
YFS_ORDER_AUDIT

592 Configuration Guide

 Time-Triggered Purge Transactions

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
YFS_PROMOTION
YFS_PROMOTION_AWARD
YFS_RECEIVING_DISCREPANCY
YFS_RECEIVING_DISCREPANCY_DTL
YFS_REFERENCE_TABLE
YFS_TAX_BREAKUP

Time-Triggered Transaction Reference 593

Time-Triggered Purge Transactions

A.4.3.5 Delivery Plan Purge

This purge deletes delivery plans after they have completed their typical
life-cycle. 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:
Q
The delivery plan should be in the "Closed" status.
Q
The delivery plan should not be associated with any load or shipment.
Q
All orders associated with the delivery plan should be purged.
Q
The last modification performed on the delivery plan should fall
before the lead time (in days) setup.

594 Configuration Guide

 Time-Triggered Purge Transactions

Note: All the loads and shipments that are associated

with the delivery plans should have been purged before
running this purge agent.

Attributes
The following are the attributes for this time-triggered transaction:
Table A–141 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

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–142 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 Optional. Number of records to retrieve and
To Buffer process at one 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.

Time-Triggered Transaction Reference 595

Time-Triggered Purge Transactions

Table A–142 Delivery Plan Purge Criteria Parameters

Parameter Description
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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:
Q
Y - Default value. Records are deleted in
batches.
Q
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.

596 Configuration Guide

 Time-Triggered Purge Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–143 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.

Events Raised
None.

Tables Purged
YFS_DELIVERY_PLAN

A.4.3.6 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:
Q
YFS_EXPORT records should be marked as processed (Status = 10).
Q
The last modified time should fall before the lead time (in days)
setup.

Note: 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).

Any enterprise using the ConsoleConsole must schedule purge

transactions.

Time-Triggered Transaction Reference 597

Time-Triggered Purge Transactions

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

Table A–144 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 A–145 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as
0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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:
Q
Y - Records are deleted in batches.
Q
N - Default value. Records are deleted one by
one.

598 Configuration Guide

 Time-Triggered Purge Transactions

Table A–145 Export Table Purge Criteria Parameters

Parameter Description
PurgeCode Required. Cannot be modified. Used for internal
calculations, such as determining retention days.
Corresponds with the PurgeCode used in
Business Rules Purge Criteria.
CollectPendingJobs If this parameter is set to "N", the agent does
not collect information on the pending jobs for
this monitor. This pending job information is used
for monitoring the monitor in the System
Management Console.
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 A–146 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

A.4.3.7 Import Table Purge

This purge removes import table data from the system. This reduces the
load on frequently accessed tables.

Time-Triggered Transaction Reference 599

Time-Triggered Purge Transactions

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:
Q
YFS_IMPORT records should be marked as processed (Status = "10").
Q
The "last modified time" should fall before the lead time (in days)
setup.

Note: 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).

Any enterprise using the Console must schedule purge transactions.

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

Table A–147 Import Table Purge Attributes

Attribute Value
Base Transaction ID IMPORTTBLPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

600 Configuration Guide

 Time-Triggered Purge Transactions

The following are the criteria parameters for this transaction:

Table A–148 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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:
Q
Y - Records are deleted in batches.
Q
N - Default value. Records are deleted one by
one.
PurgeCode Required. Cannot be modified. Used for internal
calculations, such as determining retention days.
Corresponds with the PurgeCode used in
Business Rules Purge Criteria.
CollectPendingJobs If this parameter is set to "N", the agent does
not collect information on the pending jobs for
this monitor. This pending job information is used
for monitoring the monitor in the System
Management Console.
ColonyID Required in a multi schema deployment where
the YFS_IMPORT table may exist in multiple
schemas. Runs the agent for the colony.

Time-Triggered Transaction Reference 601

Time-Triggered Purge Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–149 Import Table Purge Statistics

Statistic Name Description
NumImportsPurged Number of import tables purged.

Pending Job Count

For this transaction the pending job count is the number of records that
can be purged from the YFS_Import table.

Events Raised
None.

Tables Purged
YFS_IMPORT

A.4.3.8 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:
Q
The inventory audit record's last modification is earlier than the
current timestamp minus the retention days.

602 Configuration Guide

 Time-Triggered Purge Transactions

Note: Number of threads for this purge’s agent criteria

details must be set to 1. For more information about agent
criteria, see the Selling and Fulfillment Foundation:
Application Platform Configuration Guide.

Important: The Inventory Audit purge does not purge

any records under 60 days old, even if configured to do so.

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

Table A–150 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 A–151 Inventory Audit Purge Criteria Parameters
Parameter Description
Action Required. Triggers the transaction. If left blank, it
defaults to Get, the only valid value.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one 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.

Time-Triggered Transaction Reference 603

Time-Triggered Purge Transactions

Table A–151 Inventory Audit Purge Criteria Parameters

Parameter Description
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Table
Purged to the corresponding history tables.
Q
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 A–152 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

604 Configuration Guide

 Time-Triggered Purge Transactions

A.4.3.9 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:
Q
Supply record has the same availability type as the node. For
example, TRACK or INFINITE.
Q
Supply record has 0 quantity.
Q
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:
Q
Demand record has 0 quantity or lesser.
Q
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:
Q
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.

Time-Triggered Transaction Reference 605

Time-Triggered Purge Transactions

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

Table A–153 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 A–154 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as
0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.

606 Configuration Guide

 Time-Triggered Purge Transactions

Table A–154 Inventory Purge Criteria Parameters

Parameter Description
PurgeCode Required. Cannot be modified. Used for internal
calculations, such as determining retention days.
Corresponds with the PurgeCode used in
Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a
table may exist in multiple schemas. Runs the
agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–155 Inventory Purge Statistics

Statistic Name Description
NumInventoryDemandsPurg Number of inventory demands purged.
ed
NumInventoryNodeControlsP Number of inventory node controls
urged purged.
NumInventoryReservationsP Number of inventory reservations
urged purged.
NumInventoryTagsPurged Number of inventory tags purged.
NumItemBasedAllocationTrig Number of item based allocation triggers
gersPurged 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.

Time-Triggered Transaction Reference 607

Time-Triggered Purge Transactions

Tables Purged
YFS_IBA_TRIGGER
YFS_INVENTORY_DEMAND
YFS_INVENTORY_TAG
YFS_INVENTORY_RESERVATION
YFS_INVENTORY_SUPPLY
YFS_INVENTORY_NODE_CONTROL

A.4.3.10 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 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 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 A–156 Inventory Supply Temp Purge Attributes

Attribute Value
Base Transaction ID SUPPLYTEMPPRG
Base Document Type General
Base Process Type General

608 Configuration Guide

 Time-Triggered Purge Transactions

Table A–156 Inventory Supply Temp Purge Attributes

Attribute Value
Abstract Transaction No
APIs Called None
User Exits Called None

Criteria Parameters
The following are the criteria parameters for this transaction:
Table A–157 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as
0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.
EnterpriseCode Optional. The inventory organization for which
the Inventory Supply Temp Purge needs to be
run. If not passed, then all enterprises are
monitored.organization.
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.

Time-Triggered Transaction Reference 609

Time-Triggered Purge Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–158 Inventory Supply Temp Purge Statistics

Statistic Name Description
NumInventorySupplyTempsP Number of entries in the YFS_
urged 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

A.4.3.11 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:
Q
YFS_AUDIT records that have ‘modifyts’ greater than the retention
days specified and the records have the table name as 'YFS_ITEM'.
Q
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.

610 Configuration Guide

 Time-Triggered Purge Transactions

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

Table A–159 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 A–160 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as
0 (zero), this value defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Production mode. Deletes
records from the regular tables.
Q
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.

Time-Triggered Transaction Reference 611

Time-Triggered Purge Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–161 Item Audit Purge Statistics

Statistic Name Description
NumItemAuditRecor Number of item audit records purged.
dsPurged

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

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

612 Configuration Guide

 Time-Triggered 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:
Q
The last modification made to the load is before the lead time (in
days) setup.

Note: Before you run this transaction, ensure to purge

loads and move them to history tables. For more
information about purging loads, see Section A.4.3.13,
"Load Purge".

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

Table A–162 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 A–163 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as
0 (zero), it defaults to 5000.

Time-Triggered Transaction Reference 613

Time-Triggered Purge Transactions

Table A–163 Load History Purge Criteria Parameters

Parameter Description
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:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.
Purge Code Required. Cannot be modified. Used for internal
calculations, such as determining retention days.
Corresponds with the PurgeCode used in
Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a
table may exist in multiple schemas. Runs the
agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–164 Load History Purge Statistics

Statistic Name Description
NumLoadHistoriesPu Number of load histories purged.
rged
NumLoadShipmentHi Number of load shipment histories purged.
storiesPurged

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.

614 Configuration Guide

 Time-Triggered Purge Transactions

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

A.4.3.13 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:
Q
The Load’s last modification should fall before the lead time (in days)
setup.

Time-Triggered Transaction Reference 615

Time-Triggered Purge Transactions

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

Table A–165 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 A–166 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 Optional. Number of records to retrieve and
To Buffer process at one 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:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.

616 Configuration Guide

 Time-Triggered Purge Transactions

Table A–166 Load Purge Criteria Parameters

Parameter Description
PurgeCode Required. Cannot be modified. Used for internal
calculations, such as determining retention days.
Corresponds with the PurgeCode used in
Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a
table may exist in multiple schemas. Runs the
agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–167 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)

Time-Triggered Transaction Reference 617

Time-Triggered Purge Transactions

YFS_LOAD_STATUS_AUDIT
YFS_LOADED_CONTAINER
YFS_SHIPMENT_CONTAINER
YFS_CONTAINER_ACTIVITY

A.4.3.14 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:
Q
The last modified date of the negotiation exceeds the retention day
period.
Any enterprise using the Console must schedule purge transactions.

Attributes
The following are the attributes for this time-triggered transaction:
Table A–168 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

618 Configuration Guide

 Time-Triggered Purge Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–169 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 Optional. Number of records to retrieve and
To Buffer process at one 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:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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 A–170 Negotiation History Purge Statistics
Statistic Name Description
NumNegotiationHistoriesPurg Number of negotiation histories purged.
ed

Time-Triggered Transaction Reference 619

Time-Triggered Purge Transactions

Pending Job Count

For this transaction, the pending job count is the number of records that
can be purged from the YFS_Negotiation_Hdr_H table.

Events Raised
None.

Tables Purged
YFS_AUDIT
YFS_NEGOTIATION_HDR_H
YFS_NEGOTIATION_LINE_H
YFS_RESPONSE_H
YFS_RESPONSE_HDR_H
YFS_RESPONSE_LINE_H
YFS_RESPONSE_LINE_DTL_H

A.4.3.15 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:
Q
The last modification performed on the negotiation falls before the
lead time (in days) setup.
Q
The negotiation is in pickable status.
Any enterprise using the Console must schedule purge transactions.

620 Configuration Guide

 Time-Triggered Purge Transactions

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

Table A–171 Negotiation Purge Attributes

Attribute Value
Base Transaction ID ORD_NEGOTIATION_PURGE
Base Document Type Order
Base Process Type Order Negotiation
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–172 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 Optional. Number of records to retrieve and
To Buffer process at one 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:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.

Time-Triggered Transaction Reference 621

Time-Triggered Purge Transactions

Table A–172 Negotiation Purge Criteria Parameters

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.
Next Task Queue Optional. Specifies in hours how long a failed task
Interval 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 A–173 Negotiation Purge Statistics

Statistic Name Description
NumOrderNegotiationsPurge Number of order negotiations purged.
d

Pending Job Count

For this transaction, the pending job count is the number of records
available to be processed by the transaction with the AVAILABLE_DATE
value less than or equal to (<=) the current date value in the YFS_Task_
Q table.

Events Raised
None

Tables Purged
YFS_AUDIT
YFS_NEGOTIATION_HDR
YFS_NEGOTIATION_LINE
YFS_RESPONSE

622 Configuration Guide

 Time-Triggered Purge Transactions

YFS_RESPONSE_HDR
YFS_RESPONSE_LINE
YFS_RESPONSE_LINE_DTL

A.4.3.16 Opportunity History Purge

This transaction deletes tasks previously archived by the Opportunity
Purge. See Section A.4.3.17, "Opportunity Purge".
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:
Q
The last modified date of the opportunity should exceed the retention
day period.
Q
The quote history is purged.

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

Table A–174 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

Time-Triggered Transaction Reference 623

Time-Triggered Purge Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–175 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.
Q
Y - Default value. Removes qualifying records
from the history tables listed under Tables
Purged.
Q
N- Test mode. Determines the rows that are
removed without actually removing them.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Opportunity
History Purge needs to be run. If not passed,
then all enterprises are monitored.
Note: 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.

624 Configuration Guide

 Time-Triggered Purge Transactions

Statistics Tracked
The following statistics are tracked for this transaction:
Table A–176 Opportunity History Purge Statistics
Statistic Name Description
NumOpportunityHistor Number of opportunity histories purged.
yPurged

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

A.4.3.17 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:
Q
The last modified date of the opportunity should exceed the retention
day period.
Q
The quote associated with the opportunity should be purged.
Q
The opportunity should be in pickable status by the purge
transaction.

Time-Triggered Transaction Reference 625

Time-Triggered Purge Transactions

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

Table A–177 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 A–178 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.
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.

626 Configuration Guide

 Time-Triggered Purge Transactions

Table A–178 Opportunity Purge Criteria Parameters

Parameter Description
EnterpriseCode Optional. Enterprise for which the Opportunity
Purge needs to be run. If not passed, then all
enterprises are monitored.
Note: 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 A–179 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

Time-Triggered Transaction Reference 627

Time-Triggered Purge Transactions

A.4.3.18 Order History Purge

This purge deletes data from history tables after it completes its typical
lifecycle. 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 is picked up for history purge:
Q
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 Distributed Order Management: Configuration Guide.

Note: The order should have been purged and moved into
the history tables before you can run this transaction. See
Section A.4.3.19, "Order Purge".

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

Table A–180 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

628 Configuration Guide

 Time-Triggered Purge Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–181 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 Optional. Number of records to retrieve and
To Buffer process at one 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:
Q
Y - Default value. Removes qualifying records
from the history tables listed under Tables
Purged.
Q
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 A–182 Order History Purge Statistics

Statistic Name Description
NumOrderHistoriesPurged Number of order histories purged.

Time-Triggered Transaction Reference 629

Time-Triggered Purge Transactions

Pending Job Count

For this transaction, the pending job count is the number of records that
can be purged from the YFS_Order_HEADER_H table.

Events Raised
None.

Tables Purged
YFS_ANSWER_SET_TRAN_H
YFS_ANSWER_TRAN_H
YFS_CHARGE_TRAN_DIST_H
YFS_CHARGE_TRAN_REQUEST_H
YFS_CHARGE_TRAN_RQ_MAP_H
YFS_CHARGE_TRANSACTION_H
YFS_CREDIT_CARD_TRANSACTION_H
YFS_ENTITY_ADDRESS_H
YFS_HEADER_CHARGES_H
YFS_INSTRUCTION_DETAIL_H
YFS_INVOICE_COLLECTION_H
YFS_LINE_CHARGES_H
YFS_NOTES_H
YFS_ORDER_AUDIT_DETAIL_H
YFS_ORDER_AUDIT_H
YFS_ORDER_AUDIT_LEVEL_H
YFS_ORDER_DATE_H
YFS_ORDER_HEADER_H
YFS_ORDER_HOLD_TYPE_H
YFS_ORDER_HOLD_TYPE_LOG_H
YFS_ORDER_INVOICE_DETAIL_H

630 Configuration Guide

 Time-Triggered Purge Transactions

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
YIC_BOM_HEADER_H
YIC_BOM_LINE_H
YIC_BOM_MESSAGE_H
YIC_BOM_PROP_H

A.4.3.19 Order Purge

This purge archives data into history tables after it completes its typical
lifecycle. To purge orders from history tables, see Section A.4.3.18,
"Order History Purge". 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.

Time-Triggered Transaction Reference 631

Time-Triggered Purge Transactions

Note: This transaction depends on all lines of an order

being in a status pickable by the Purge transaction.

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

The following statuses are available for configuration to be picked up by

Order Purge:
Q
Draft Created (1000) and all extended Draft Created Statuses.
Q
Created (1100) and all extended Created statuses. These statuses
are available only for document types Sales Order, Purchase Order
and Transfer Order.
Q
Released (3200) and all extended Released statuses.
Q
Shipped (3700) and all extended Shipped statuses.
Q
Completed (3700) and all extended Completed statuses. These
statuses are available only for the document type Master Order.
Q
Received (3900) and all extended Received statuses.
Q
Cancelled (9000) and all extended Cancelled statuses.
Q
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:
Q
All open child orders (derived, chained, return, exchange,
procurement, or refund fulfillment) for the order must already be
purged.
Q
No pending transfer-out charges to another order exceeding the
transfer-ins.
Q
No pending adjustment invoices.

632 Configuration Guide

 Time-Triggered Purge Transactions

An order is purged immediately if it meets the above three criteria and is

completely cancelled with payment collection complete.

Note: In order for the purge agent to pick up a cancelled

order, the payment status of the order must be one of the
following:
Q
Paid
Q
Not Applicable

If an order does not meet any of the above criteria, continue checking for
the criteria given below:
Q
No order release status record that does not meet the retention days.
Q
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 Cancelled or Not
Applicable.
– It must not have any unpurged negotiations.
Q
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.
Q
The order's last modification should fall before the lead time (in days)
setup.
Q
Any enterprise using the Console must schedule purge transactions.
Q
The order must not have a undelivered service line.

Time-Triggered Transaction Reference 633

Time-Triggered Purge Transactions

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

Note: With no change to status inventory type, a sales

order 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 sales order is tracking inventory. This prevents the
purging of the order relating to the pending supply for the
Buyer tracking inventory.
To purge such orders, the status inventory type for the
Shipped or extended Shipped status should be configured
such that the Buyer Supply Type is ONHAND for the status
inventory type.
When the purge agent is run, the draft order without lines
are purged to the order history table. Once the purge
history agent is run, the draft orders without lines gets
deleted permanently.

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

Table A–183 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

634 Configuration Guide

 Time-Triggered Purge Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–184 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Next Task Queue Optional. Specifies in hours how long a failed task
Interval 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.
Note: 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:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.

Time-Triggered Transaction Reference 635

Time-Triggered Purge Transactions

Table A–184 Order Purge Criteria Parameters

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:
Q
DRAFTORDERHISTPRG to purge draft order
information from the order history tables.
Q
DRAFTORDERNOLINEHISTPRG to purge draft
orders without order lines from the order
history tables.
Q
DRAFTORDERNOLINEPRG to purge draft
orders that have no order lines.
Q
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 Section A.4.3.20,
"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
The following statistics are tracked for this transaction:

Table A–185 Order Purge Statistics

Statistic Name Description
NumOrdersProcessed Number of order processed.
NumOrdersPurged Number of orders purged.

636 Configuration Guide

 Time-Triggered Purge Transactions

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

Time-Triggered Transaction Reference 637

Time-Triggered Purge Transactions

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

638 Configuration Guide

 Time-Triggered Purge Transactions

YIC_BOM_PROP

A.4.3.20 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:
Q
All conditions for Order Purge have been met. See Section A.4.3.19,
"Order Purge" for information about conditions for Order Purge.
Q
Order release records have 0 quantity.
Q
AdditionalPurgeCode in the Order Purge criteria is set to ORDER_
RELEASE_STATUS_PURGE.
Q
The order has been modified within the Order Purge lead days
AdditionalPurgeCode.

Criteria Parameters
The following are the criteria parameters for Order Release Status Purge:

Table A–186 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.

Time-Triggered Transaction Reference 639

Time-Triggered Purge Transactions

Table A–186 Order Release Status Purge Criteria Parameters

Parameter Description
Next Task Queue Optional. Specifies in hours how long a failed task
Interval 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.
Note: 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:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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.

640 Configuration Guide

 Time-Triggered Purge Transactions

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

A.4.3.21 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:
Q
The last modified time falls before the lead time (in days) setup.
Any enterprise using the Console must schedule purge transactions.

Note: This transaction needs to be run after negotiation is

completed.

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

Table A–187 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

Time-Triggered Transaction Reference 641

Time-Triggered Purge Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:
Table A–188 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 Optional. Number of records to retrieve and
To Buffer process at one 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:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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.

642 Configuration Guide

 Time-Triggered Purge Transactions

Statistics Tracked
The following statistics are tracked for this transaction:
Table A–189 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

A.4.3.22 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:
Q
The YFS_AUDIT records that have ‘modifyts’ greater than the
retention days specified and the records have the table name as
'YFS_ORGANIZATION'.
Q
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.

Time-Triggered Transaction Reference 643

Time-Triggered Purge Transactions

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

Table A–190 Organization Audit Purge Attributes

Attribute Value
Base Transaction ID YFS_ORGANIZATION_AUDIT_PURGE
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–191 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as
0 (zero), this value defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Production mode. Deletes
records from the regular tables.
Q
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.

644 Configuration Guide

 Time-Triggered Purge Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–192 Organization Audit Purge Statistics

Statistic Name Description
NumOrganizationAu Number of organization audit records purged.
ditRecordsPurged

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

A.4.3.23 Person Info Purge

This purge gets a list of dates with the person info record count and sorts
them by date in ascending order. Then, based on the specified number of
records to buffer and the modify timestamp, it purges the applicable
records and places them in the YFS_PERSON_INFO_H table.

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

Table A–193 PersonInfo Purge Attributes

Attribute Value
Base Transaction ID PERSONINFOPRG
Base Document Type General
Base Process Type General
Abstract Transaction No

Time-Triggered Transaction Reference 645

Time-Triggered Purge Transactions

Table A–193 PersonInfo Purge Attributes

Attribute Value
APIs Called None
User Exits Called None

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–194 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 Optional. Number of records to retrieve and
To Buffer process at one time.
Q
If left blank or the number specified is less
than 10000, it defaults to 10000.
Q
If the number specified is greater than
10000, then that value is used.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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.

646 Configuration Guide

 Time-Triggered Purge Transactions

Table A–194 PersonInfo Purge Criteria Parameters

Parameter Description
EnterpriseCode Optional. Enterprise for which the PersonInfo
Purge needs to be run. If not passed, then all
enterprises are monitored.
TableType Required in a multi schema deployment when
YFS_Person_Info table may exist in multiple
schemas.
Valid Values: CONFIGURATION, TRANSACTION,
MASTER.
If set to CONFIGURATION, purge runs for the
YFS_Person_Info records associated with tables
that have TableType as CONFIGURATION; for
example, YFS_Organization, YFS_Ship_Node, and
so forth.
If set to TRANSACTION, purge runs for the YFS_
Person_Info records associated with tables that
have TableType as TRANSACTION; for example,
YFS_Order_Header, YFS_Shipment, and so forth.
Note that purge would run for all TableTypes that
exist in the same schema as the one passed. For
example, if set to TRANSACTION, purge would
also run for YFS_Person_Info records associated
with tables that have TableType as MASTER, since
they reside in the same schema.
ColonyID Required in a multi schema deployment where
the YFS_PERSON_INFO table may exist in
multiple schemas. Runs the agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:
If it is left blank or any number less than 10,000 is specified, then it
defaults to 10,000. But if any number > 10,000 is specified, then that
value would be used.

Time-Triggered Transaction Reference 647

Time-Triggered Purge Transactions

Table A–195 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

A.4.3.24 Person Info History Purge

This purge deletes records from the YFS_PERSON_INFO_H table based
on the purge criteria.

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

Table A–196 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

648 Configuration Guide

 Time-Triggered Purge Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–197 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 Optional. Number of records to retrieve and
To Buffer process at one time.
Q
If left blank or the number specified is less
than 10000, it defaults to 10000.
Q
If the number specified is greater than
10000, then that value is used.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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.

Time-Triggered Transaction Reference 649

Time-Triggered Purge Transactions

Table A–197 PersonInfo History Purge Criteria Parameters

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 A–198 PersonInfo History Purge Statistics

Statistic Name Description
NumPersonInfoHIstoryRecor Number of person info history records
dsPurged 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.

650 Configuration Guide

 Time-Triggered Purge Transactions

Events Raised
None.

Tables Purged
YFS_PERSON_INFO_H

A.4.3.25 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.
You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a picklist is picked up for purge:
Q
The picklist should exist for more than the specified retention period.
Q
The picklist should not be associated with any shipment.

Note: 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 A–199 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

Time-Triggered Transaction Reference 651

Time-Triggered Purge Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–200 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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.

652 Configuration Guide

 Time-Triggered Purge Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–201 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

A.4.3.26 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:
Q
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 A–202 Price List Purge Attributes

Attribute Value
Base Transaction ID PRICELISTPRG
Base Document Type General
Base Process Type General

Time-Triggered Transaction Reference 653

Time-Triggered Purge Transactions

Table A–202 Price List Purge Attributes

Attribute Value
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters
The following are the criteria parameters for this transaction:
Table A–203 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as
0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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.

654 Configuration Guide

 Time-Triggered Purge Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–204 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

A.4.3.27 Purge Catalog Mass Audits

This purge removes old audit records from the YFS_CATALOG_MASS_
AUDIT table. This table contains data about changes to the catalog due
to assignment of attributes and attribute values to categories and items.
It also contains information about inherited attributes and attribute
values. The purge transaction finds mass audit records that have not
been modified in a specified number of days and removes those records
from the database.

Time-Triggered Transaction Reference 655

Time-Triggered Purge Transactions

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

Table A–205 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 A–206 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as
0 (zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.

656 Configuration Guide

 Time-Triggered Purge Transactions

Table A–206 Purge Catalog Mass Audits Criteria Parameters

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 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 A–207 Purge Catalog Mass Audits Statistics

Statistic Name Description
NumCatalogMassAuditsPurged Number of mass audit records purged.

Pending Job Count

For this transaction the pending job count is the total number of records
that can be purged from the YFS_CATALOG_MASS_AUDIT table.

Events Raised
None.

Tables Purged
The YFS_CATALOG_MASS_AUDIT table is purged when MODIFYTS <
(CurrentDate - LeadDays)

A.4.3.28 Receipt History Purge

This transaction deletes receipts previously archived by the Receipt
Purge. See Section A.4.3.29, "Receipt Purge".
Any enterprise using the Console must schedule purge transactions.

Time-Triggered Transaction Reference 657

Time-Triggered 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:
Q
The last modified date of the receipt should exceed the retention day
period.
Q
The shipment associated with the receipt should be purged from the
history table.

Note: 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 A–208 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 A–209 Receipt History Purge Criteria Parameters

Parameter Description
Action Required. Triggers the transaction.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.

658 Configuration Guide

 Time-Triggered Purge Transactions

Table A–209 Receipt History Purge Criteria Parameters

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:
Q
Y - Default value. Removes qualifying records
from the history tables listed under Tables
Purged.
Q
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 A–210 Receipt History Purge Statistics

Statistic Name Description
NumReceiptLineHistoriesPurg Number of receipt line histories purged.
ed
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.

Time-Triggered Transaction Reference 659

Time-Triggered Purge Transactions

Tables Purged
YFS_RECEIPT_HEADER_H
YFS_RECEIPT_LINE_H
YFS_RECEIPT_STATUS_AUDIT_H
YFS_INSTRUCTION_DETAIL_H

A.4.3.29 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 Section A.4.3.28, "Receipt History Purge". It also
archives and purges the receipt's child tables.
This is a pipeline transaction and works from a task queue.
Any enterprise using the Console must schedule purge transactions.
You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a receipt is picked up for purge:
Q
The last modified date of the receipt should exceed the retention day
period.
Q
The shipment associated with the receipt should be purged.
Q
The receipt should be in pickable status for the purge transaction.
Q
The value of the OpenReceiptFlag field should be set to "N".
Q
The receipt should not have pending inspections.
Q
There is no inventory in the warehouse for the receipt.

Note: To purge a receipt, ensure that the receipts are

closed and Shipments are purged.

660 Configuration Guide

 Time-Triggered Purge Transactions

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

Table A–211 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 A–212 Receipt Purge Criteria Parameters

Parameter Description
Action Required. Triggers the transaction.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one 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:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.

Time-Triggered Transaction Reference 661

Time-Triggered Purge Transactions

Table A–212 Receipt Purge Criteria Parameters

Parameter Description
PurgeCode Required. Cannot be modified. Used for internal
calculations, such as determining retention days.
Corresponds with the PurgeCode used in
Business Rules Purge Criteria.
ColonyID Required in a multi schema deployment where a
table may exist in multiple schemas. Runs the
agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–213 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

662 Configuration Guide

 Time-Triggered Purge Transactions

A.4.3.30 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:
Q
YFS_REPROCESS_ERROR records with State = Fixed or Ignored is
processed.
Q
The last modified time is earlier than the lead time (in days) setup.

Note: This purge only reads the rules defined by the hub.
Enterprise overridden rules are not considered.

Any enterprise using the ConsoleConsole must schedule purge

transactions.

Time-Triggered Transaction Reference 663

Time-Triggered Purge Transactions

Attributes
The following are the attributes for this time-triggered transaction:
Table A–214 Reprocess Error Purge Attributes
Attribute Value
Base Transaction ID REPROCESSPRG
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–215 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.

664 Configuration Guide

 Time-Triggered Purge Transactions

Table A–215 Reprocess Error Purge Criteria Parameters

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 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 A–216 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

A.4.3.31 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:
Q
EXPIRATION_DATE is earlier than the current date or quantity is less
than or equal to 0

Time-Triggered Transaction Reference 665

Time-Triggered Purge Transactions

Any enterprise using the Console must schedule purge transactions.

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

Table A–217 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 A–218 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.

666 Configuration Guide

 Time-Triggered Purge Transactions

Table A–218 Reservation Purge Criteria Parameters

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 YFS_INVENTORY_RESERVATION table may
exist in multiple schemas. Runs the agent for the
colony.

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–219 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

A.4.3.32 Shipment History Purge

This transaction deletes shipments previously archived by the Shipment
Purge. See Section A.4.3.33, "Shipment Purge".
Any enterprise using the Console must schedule purge transactions.

Time-Triggered Transaction Reference 667

Time-Triggered 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:
Q
The last modification performed on the shipment falls before the lead
time (in days) setup.

Note: Orders related to the shipments should have been

purged by order purge. Shipments should have been
closed by the Close Shipment transaction. See
Section A.3.10, "Close Shipment".

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

Table A–220 Shipment History Purge Attributes

Attribute Value
Base Transaction ID SHIPMENTHISTPRG
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–221 Shipment History Purge Criteria Parameters

Parameter Description
Action Required. Triggers the transaction.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.

668 Configuration Guide

 Time-Triggered Purge Transactions

Table A–221 Shipment History Purge Criteria Parameters

Parameter Description
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:
Q
Y - Default value. Removes qualifying records
from the history tables listed under Tables
Purged.
Q
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 A–222 Shipment History Purge Statistics

Statistic Name Description
NumShipmentHistoriesPurge Number of shipment histories purged.
d
NumShipmentLineHistoriesP Number of shipment line histories
urged 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.

Time-Triggered Transaction Reference 669

Time-Triggered Purge Transactions

Tables Purged
YFS_ADDITIONAL_ATTRIBUTE_H
YFS_ADDITIONAL_DATE_H
YFS_AUDIT
YFS_CONTAINER_DETAILS_H
YFS_CONTAINER_STS_AUDIT_H
YFS_INSTRUCTION_DETAIL_H
YFS_SHIPMENT_CONTAINER_H
YFS_SHIPMENT_H
YFS_SHIPMENT_LINE_H
YFS_SHIPMENT_LINE_REQ_TAG_H
YFS_SHIPMENT_STATUS_AUDIT_H
YFS_SHIPMENT_TAG_SERIAL_H
YFS_CONTAINER_ACTIVITY_H

A.4.3.33 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 Section A.4.3.32, "Shipment History Purge". 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.

670 Configuration Guide

 Time-Triggered Purge Transactions

Note: Orders related to the shipments should have been

purged by order purge. Shipments should have been
closed by the Close Shipment transaction. See
Section A.3.10, "Close Shipment".

You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a shipment is picked up for purge:
Q
The last modification performed on the shipment should fall before
the lead time (in days) setup.
Q
The value of the ShipmentClosedFlag field should be set to "Y".
Q
The order record should already be purged for all shipment lines.

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

Table A–223 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

Time-Triggered Transaction Reference 671

Time-Triggered Purge Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–224 Shipment Purge Criteria Parameters

Parameter Description
Action Required. Triggers the transaction.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Number of Days To Optional. Maximum number of days before the
Execute lead days the 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:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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.

672 Configuration Guide

 Time-Triggered Purge Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–225 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
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

Time-Triggered Transaction Reference 673

Time-Triggered Purge Transactions

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

A.4.3.34 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:
Q
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 A–226 Shipment Statistics Purge Attributes

Attribute Value
Base Transaction ID PRG_SHIP_STATS
Base Document Type Order
Base Process Type Order Delivery
Abstract Transaction No
APIs Called None
User Exits Called YFSBeforePurgeUE

674 Configuration Guide

 Time-Triggered Purge Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–227 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 Optional. Number of records to retrieve and
To Buffer process at one 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:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
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 A–228 Shipment Statistics Purge Statistics

Parameter Description
NumShipmentStatisticsPurge Number of shipment statistics purged.
d

Time-Triggered Transaction Reference 675

Time-Triggered Purge Transactions

Pending Job Count

For this transaction, the pending job count is the number of records that
can be purged from the YFS_SHIPMENT_STATISTICS table.

Events Raised
None.

Tables Purged
YFS_SHIPMENT_STATISTICS

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

676 Configuration Guide

 Time-Triggered Purge Transactions

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

Table A–229 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 A–230 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:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under to the
corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.
CollectPendingJobs If this parameter is set to "N", the agent does
not collect information on the pending jobs for
this monitor. This pending job information is used
for monitoring the monitor in the System
Management Console.
Number of Records Required. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as
0 (zero), it defaults to 100.

Time-Triggered Transaction Reference 677

Time-Triggered Purge Transactions

Table A–230 User Activity Purge Parameters

Parameter Description
BatchDelete Required. The method by which all records are
deleted from the table. Valid values are:
Q
Y - Default value. Records are deleted in
batches.
Q
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 A–231 Statistics Purge Statistics
Statistic Name Description
NumStatisticsPurged Number of statistics purged

Pending Job Count

None.

Events Raised
None.

Tables Purged
YFS_USER_ACTIVITY

A.4.3.36 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).

678 Configuration Guide

 Time-Triggered Purge Transactions

The following limitation is assumed when purging records:

Q
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 A–232 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 A–233 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.

Time-Triggered Transaction Reference 679

Time-Triggered Purge Transactions

Table A–233 User Activity Audit Purge Criteria Parameters

Parameter Description
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under to the
corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.
CollectPendingJobs If this parameter is set to "N", the agent does not
collect information on the pending jobs for this
monitor. This pending job information is used for
monitoring the monitor in the System
Management Console.
Number of Records Required. Number of records to retrieve and
To Buffer process at one 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:
Q
Y - Default value. Records are deleted in
batches.
Q
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 A–234 Statistics Purge Statistics

Statistic Name Description
NumStatisticsPurged Number of statistics purged

Pending Job Count

None.

680 Configuration Guide

 Time-Triggered Purge Transactions

Events Raised
None.

Tables Purged
YFS_USR_ACT_AUDIT

A.4.3.37 Work Order History Purge

This transaction deletes tasks previously archived by the Work Order
Purge. See Section A.4.3.38, "Work Order Purge".
You can use purge codes pseudo-logic to analyze purges. If the following
condition is met, a work order that is previously purged by the work
order purge agent is picked up for history purge:
Q
The last modified date of the work order should exceed the retention
day period.

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

Table A–235 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

Time-Triggered Transaction Reference 681

Time-Triggered Purge Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–236 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.
Q
Y - Default value. Removes qualifying records
from the history tables listed under Tables
Purged.
Q
N- Test mode. Determines the rows that are
removed without actually removing them.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one 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 WMS 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.

682 Configuration Guide

 Time-Triggered Purge Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–237 Work Order History Purge Statistics

Statistic Name Description
NumWorkOrderHistoriesPurg Number of work order histories purged.
ed

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

Time-Triggered Transaction Reference 683

Time-Triggered Purge Transactions

A.4.3.38 Work Order Purge

This time-triggered transaction purges all the work orders for a period
greater than the retention days specified in the Work Order Purge criteria
and those, which are either in the status of cancelled or completed.
You can use purge codes pseudo-logic to analyze purges. If the following
conditions are met, a work order is picked up for purge:
Q
The last modified date of the work order should exceed the retention
day period.
Q
The order associated with the work order should be purged.
Q
The work order should be in pickable status by the purge transaction.

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

Table A–238 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

684 Configuration Guide

 Time-Triggered Purge Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–239 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.
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one 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 WMS 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.

Time-Triggered Transaction Reference 685

Time-Triggered Purge Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–240 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

686 Configuration Guide

 Time-Triggered Purge Transactions

A.4.3.39 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:
Q
YFS_AUDIT records that have ‘modifyts’ greater than the retention
days specified and the value of table name matches in the YFS_
AUDIT table.
Q
The last modified time is before the lead time (in days) setup.

Note: 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 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 A–241 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

Time-Triggered Transaction Reference 687

Time-Triggered Purge Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–242 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as
0 (zero), this value defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Production mode. Deletes
records from the regular tables.
Q
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.

688 Configuration Guide

 Time-Triggered Purge Transactions

Table A–242 YFS Audit Purge Criteria Parameters

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 A–243 YFS Audit Purge Statistics

Statistic Name Description
NumAuditRecordsPur Number of audit records purged.
ged

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.

Time-Triggered Transaction Reference 689

Time-Triggered Purge Transactions

Events Raised
None.

Tables Purged
YFS_AUDIT, YFS_AUDIT_HEADER

A.4.3.40 YFSInventoryOwnershipAudit Purge

This transaction purges all the records from YFS_INV_OWN_TRANSFER_
RCD prior to the lead days specified in criteria parameters.

Attributes
Following are the attributes for this time-triggered transaction:

Table A–244 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 A–245 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as
0 (zero), this value defaults to 5000.

690 Configuration Guide

 Time-Triggered Purge Transactions

Table A–245 YFSInventoryOwnership Purge Criteria Parameters

Parameter Description
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:
Q
Y - Default value. Production mode. Deletes
records from the regular tables.
Q
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

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

Time-Triggered Transaction Reference 691

Time-Triggered Purge Transactions

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

Table A–246 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 A–247 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.

692 Configuration Guide

 Time-Triggered Purge Transactions

Table A–247 Password Reset Request Purge Criteria Parameters

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_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 A–248 Password Reset Request Purge Statistics

Statistic Name Description
NumPasswordRequestPurged Number of password requests purged.

Pending Job Count

For this transaction, the pending job count is the number of records that
can be purged from the PLT_PWD_REQ table.

Events Raised
None.

Tables Purged
PLT_PWD_REQ

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

Time-Triggered Transaction Reference 693

Time-Triggered Purge Transactions

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

Table A–249 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 A–250 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
Live Optional. Mode in which to run. Valid values are:
Q
Y - Default value. Moves qualifying records
from the regular tables listed under Tables
Purged to the corresponding history tables.
Q
N - Test mode. Determines the rows that are
moved to history tables without actually
moving them.

694 Configuration Guide

 Task Queue Syncher Time-Triggered Transactions

Table A–250 User Login Failure Purge Criteria Parameters

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 A–251 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

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

Time-Triggered Transaction Reference 695

Task Queue Syncher Time-Triggered Transactions

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.
The available task queue synchers are:
Q
Load Execution Task Queue Syncher
Q
Order Delivery Task Queue Syncher
Q
Order Fulfillment Task Queue Syncher
Q
Order Negotiation Task Queue Syncher
Q
Quote Fulfillment Task Queue Syncher

Note: Some of the statistics collected and tracked in

Release 9.0 for time-triggered transactions, monitors, and
integration and application servers may change with the
next release.

A.5.1 Load Execution Task Queue Syncher

This transaction synchronizes the task queue for the load execution
process type.
You can use the following pseudo-logic to analyze this time-triggered
transaction. If the following conditions are met, a task queue for the load
execution process type is synchronized:
Q
LOAD_CLOSED_FLAG of Load should not be 'Y'.
Q
Load should be in a status that is pickable by a transaction in the
pipeline.
Q
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.

696 Configuration Guide

 Task Queue Syncher Time-Triggered Transactions

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

Table A–252 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 A–253 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 Optional. Number of records to retrieve and
To Buffer process at one 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 A–254 Load Execution Task Queue Syncher Statistics

Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Time-Triggered Transaction Reference 697

Task Queue Syncher Time-Triggered Transactions

Events Raised
None.

A.5.2 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 A–255 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 A–256 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 Optional. Number of records to retrieve and
To Buffer process at one 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.

698 Configuration Guide

 Task Queue Syncher Time-Triggered Transactions

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–257 Order Delivery Task Queue Syncher Statistics

Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised
None.

A.5.3 Order Fulfillment Task Queue Syncher

This transaction synchronizes the order fulfillment process type.

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

Table A–258 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

Time-Triggered Transaction Reference 699

Task Queue Syncher Time-Triggered Transactions

Criteria Parameters
The following are the criteria parameters for this transaction:

Table A–259 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 Optional. Number of records to retrieve and
To Buffer process at one 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 A–260 Order Fulfillment Task Queue Syncher Statistics

Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised
None.

700 Configuration Guide

 Task Queue Syncher Time-Triggered Transactions

A.5.4 Order Negotiation Task Queue Syncher

This transaction synchronizes the order negotiation process type.

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

Table A–261 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 A–262 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 Optional. Number of records to retrieve and
To Buffer process at one 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 A–263 Order Negotiation Task Queue Syncher Statistics

Statistic Name Description
NumTasksCreated Number of tasks created.

Time-Triggered Transaction Reference 701

Task Queue Syncher Time-Triggered Transactions

Pending Job Count

None.

Events Raised
None.

A.5.5 Quote Fulfillment Task Queue Syncher

This transaction synchronizes the quote fulfillment process type.

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

Table A–264 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 A–265 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 Optional. Number of records to retrieve and
To Buffer process at one 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.

702 Configuration Guide

 Monitors

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–266 Quote Fulfillment Task Queue Syncher Statistics

Statistic Name Description
NumTasksCreated Number of tasks created.

Pending Job Count

None.

Events Raised
None.

A.6 Monitors
Monitors are transactions that watch for processes or circumstances that
are out of bounds and then raise alerts.

Note: Some of the statistics collected and tracked in

Release 9.0 for time-triggered transactions, monitors, and
integration and application servers may change with the
next release of Selling and Fulfillment Foundation.

Note: All Monitors have a CollectPendingJobs criteria

parameter. If this parameter is set to N, the agent does not
collect information on the pending jobs for that monitor.
This pending job information is used for monitoring the
monitor in the System Management Console. By default,
CollectPendingJobs is set to Y. It can be helpful to set it to
N if one monitor is performing a significant amount of
getPendingJobs queries and the overhead cost is too high.

Time-Triggered Transaction Reference 703

Monitors

A.6.1 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 A–267 Availability Monitor Attributes

Attribute Value
Base Transaction ID ATP_MONITOR
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

704 Configuration Guide

 Monitors

Criteria Parameters
The following are the criteria parameters for this monitor:

Table A–268 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:
Q
1 - current inventory
Q
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.
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.

Time-Triggered Transaction Reference 705

Monitors

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.

A.6.2 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:
Q
If an exception has not been assigned to a user by a certain time
Q
If an exception has not been resolved by a certain time
Q
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 A–269 Exception Monitor Attributes

Attribute Value
Base Transaction ID EXCEPTION_MONITOR
Base Document Type General
Base Process Type General
Abstract Transaction No
APIs Called None

706 Configuration Guide

 Monitors

Criteria Parameters
The following are the criteria parameters for this monitor:

Table A–270 Exception Monitor Criteria Parameters

Parameter Description
Action Required. Triggers the transaction.
Number of Records Optional. Number of records to retrieve and
To Buffer process at one 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 A–271 Exception Monitor Statistics

Statistic Name Description
NumInboxProcessed Number of alerts processed.
NumExceededQueueSizeAler Number of actions raised when the
ts number of unresolved alerts exceeds the
queue’s maximum active size.

Time-Triggered Transaction Reference 707

Monitors

Table A–271 Exception Monitor Statistics

Statistic Name Description
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.

A.6.3 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 Global Inventory Visibility:
Configuration Guide.

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

Table A–272 Inventory Monitor Attributes

Attribute Value
Base Transaction ID INVENTORY_MONITOR
Base Document Type General
Base Process Type General

708 Configuration Guide

 Monitors

Table A–272 Inventory Monitor Attributes

Attribute Value
Abstract Transaction No
APIs Called checkAvailability()

Criteria Parameters
The following are the criteria parameters for this monitor:

Table A–273 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 Selling and
Fulfillment Foundation: Installation Guide

Time-Triggered Transaction Reference 709

Monitors

Table A–273 Inventory Monitor Criteria Parameters

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.

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

710 Configuration Guide

 Monitors

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

Table A–274 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

Criteria Parameters
The following are the criteria parameters for this monitor:

Table A–275 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 Optional. Number of records to retrieve and
To Buffer process at one 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.

Time-Triggered Transaction Reference 711

Monitors

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–276 Negotiation Monitor Statistics

Statistic Name Description
NumNegotiationsProcessed Number of negotiations processed.
NumNegotiationsRequiringAl Number of negotiations which have at
ert 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

A.6.5 Enhanced Order Monitor

The enhanced order monitor enables you to monitor the following
situations:
Q
Milestone x has not been reached y hours before a given date type.
Q
Milestone x has not been reached within y hours of a given date type.
Q
Milestone x has not been reached within y hours of milestone z.
Q
Milestone x has been reached y hours before a given date type.
Q
Milestone x has been reached within y hours of a given date type.
Q
Milestone x has been reached within y hours after milestone z.
Q
The order has been in status x for y hours.
Q
Date type x is y hours before date type z.
Q
Date type x is y hours after date type z.
Q
The order has been in hold type x for y hours.
Q
The order has been in hold type x for y hours before date type z.

712 Configuration Guide

 Monitors

The order monitor can be configured to monitor the following system

date types for Sales Order and Purchase Order document types:
Q
Actual Order Date - Read from the ORDER_DATE column of the YFS_
ORDER_HEADER table.
Q
Actual Next Iteration Date - Read from the NEXT_ITER_DATE column
of the YFS_ORDER_HEADER table.
Q
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.
Q
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.
Q
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.
Q
Requested Delivery Date - If there is a release, read from the REQ_
DELIVERY_DATE column of the YFS_ORDER_RELEASE table.
Q
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.
Q
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.

Note: 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 Supply Collaboration: Configuration Guide, the

Time-Triggered Transaction Reference 713

Monitors

appropriate section in this guide, and the Sterling Reverse Logistics:

Configuration Guide.

Important: 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
Section A.3.8, "Close Order".

Note: The same relog interval is used for all document

types.

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

Table A–277 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 A–278 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.

714 Configuration Guide

 Monitors

Table A–278 Enhanced Order Monitor Criteria Parameters

Parameter Description
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 A–279 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

Table A–280 Events Raised by the Enhanced Order Monitor Transaction

Template
Transaction/Event Key Data Data Published* Support?
ON_AUTO_CANCEL ORDER_ YFS_ORDER_MONITOR_ Yes
MONITOR EX.ON_AUTO_CANCEL.html
_dbd.txt
* These files are located in the following directory:
<INSTALL_DIR>/xapidocs/api_javadocs/XSD/HTML

Time-Triggered Transaction Reference 715

Monitors

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

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.

Note: Note: If the default monitor template is used, the

MonitorConsolidation-> Order->OrderStatuses->
OrderStatus->MonitorRule element is ignored and is not
passed into the condition.

A.6.6 Enhanced Quote Monitor

The enhanced quote monitor enables you to monitor the following
situations:
Q
Milestone x has not been reached y hours before a given date type.
Q
Milestone x has not been reached within y hours of a given date type.
Q
Milestone x has not been reached within y hours of milestone z.
Q
Milestone x has been reached y hours before a given date type.
Q
Milestone x has been reached within y hours of a given date type.

716 Configuration Guide

 Monitors

Q
Milestone x has been reached within y hours after milestone z.
Q
The order has been in status x for y hours.
Q
Date type x is y hours before date type z.
Q
Date type x is y hours after date type z.
The quote monitor can be configured to monitor the following system
date types:
Q
Actual Expiration Date - Read frm the EXPIRATION_DATE column of
the YFS_ORDER_HEADER table.
For more information about milestones, date types, and monitoring rules,
refer to the appropriate section in this guide.

Important: 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
Section A.3.8, "Close Order".

Note: The same relog interval is used for all document

types.

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

Table A–281 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

Time-Triggered Transaction Reference 717

Monitors

Criteria Parameters
The following are the criteria parameters for this monitor:

Table A–282 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 Optional. Number of records to retrieve and
To Buffer process at one 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 A–283 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.

718 Configuration Guide

 Monitors

Events Raised
No events are raised. Individual actions associated with the monitoring
rule are run.
The data published is ORDER_MONITOR_EX.0015.xml.

Monitor Rule’s Condition Template

If a monitor rule contains a condition, the <INSTALL_
DIR>/repository/xapi/template/source/smcfs/monitor/ORDER_
MONITOR_EX_CONDITION.xml template file is used to obtain both the order
details and the evaluating monitor rule details. See the provided
<INSTALL_
DIR>/repository/xapi/template/source/smcfs/monitor/ORDER_
MONITOR_EX_CONDITION.xml.sample file for more details.
If the <INSTALL_
DIR>/repository/xapi/template/source/smcfs/monitor/ORDER_
MONITOR_EX_CONDITION.xml template file does not exist, the
MonitorConsolidation->Order element of the default monitor template,
the <INSTALL_
DIR>/repository/xapi/template/source/smcfs/monitor/ORDER_
MONITOR_EX.xml file, is used.

Note: Note: If the default monitor template is used, the

MonitorConsolidation-> Order->OrderStatuses->
OrderStatus->MonitorRule element is ignored and is not
passed into the condition.

A.6.7 Enhanced Return Monitor

The enhanced return monitor allows you to monitor the following
situations:
Q
Milestone x has not been reached y hours before a given date type.
Q
Milestone x has not been reached within y hours of a given date type.
Q
Milestone x has not been reached within y hours of milestone z.
Q
Milestone x has been reached y hours before a given date type.
Q
Milestone x has been reached within y hours of a given date type.
Q
Milestone x has been reached within y hours after milestone z.

Time-Triggered Transaction Reference 719

Monitors

Q
The order has been in status x for y hours.
Q
Date type x is y hours before date type z.
Q
Date type x is y hours after date type z.
The enhanced return monitor can be configured to monitor the following
system date types:
Q
Actual Order Date - Read from the ORDER_DATE column of the YFS_
ORDER_HEADER table
Q
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.
Q
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.
Q
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.
Q
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.
Q
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.
Q
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.

720 Configuration Guide

 Monitors

Note: 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 Supply Collaboration: Configuration Guide, the
appropriate section in this guide, and the Sterling Reverse Logistics:
Configuration Guide.

Important: 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
Section A.3.8, "Close Order".

Note: The same relog interval is used for all document

types.

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

Table A–284 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

Time-Triggered Transaction Reference 721

Monitors

Criteria Parameters
The following are the criteria parameters for this monitor:

Table A–285 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 Optional. Number of records to retrieve and
To Buffer process at one 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.
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 A–286 Enhanced Order Monitor Statistics

Statistic Name Description
NumOrdersProcessed Number of orders processed.
NumAlertsRaised Number of alerts raised.

722 Configuration Guide

 Monitors

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.

Note: If the default monitor template is used, the

MonitorConsolidation-> Order->OrderStatuses->
OrderStatus->MonitorRule element is ignored and is not
passed into the condition.

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

Time-Triggered Transaction Reference 723

Monitors

It can be run in three modes:

Q
Activity Based: Raises the event in real time every time an item goes
above or below one of the thresholds.
Q
Quick Sync: Re-sends the most recently published inventory
availability information.
Q
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 Global Inventory
Visibility: Configuration Guide.
Inventory available at the current date is considered as on-hand. The
processing time in the ATP rules must be set to at least 1 day, or else
past due supply is included as part of on-hand inventory. For more
information about configuring ATP Rules, see the Sterling 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.
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 Global Inventory
Visibility: Configuration Guide.
Inventory items without an Availability Monitor rule, or with a rule that is
disabled, is unable to be processed by this time-triggered transaction.

724 Configuration Guide

 Monitors

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 Global Inventory Visibility:
Configuration Guide and the 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.

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

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

Table A–287 Real-time Availability Monitor Attributes

Attribute Value
Base Transaction ID REALTIME_ATP_MONITOR
Base Document Type General
Base Process Type General

Time-Triggered Transaction Reference 725

Monitors

Table A–287 Real-time Availability Monitor Attributes

Attribute Value
Abstract Transaction No
APIs Called FindInventory

Criteria Parameters
The following are the criteria parameters for this monitor:

Table A–288 Real-time Availability Monitor Criteria Parameters

Parameter Description
Action Required. Triggers the transaction. If left
blank, it defaults to Get, the only valid
value.
Number of Records To Buffer Optional. Number of records to retrieve
and process at one time. If left blank or
specified as 0 (zero), it defaults to 5000.
InventoryOrganizationCode Inventory organization code to use when
MonitorOption is passed as 3. The
inventory organization has to be an
enterprise.
If this is not passed, the monitor runs for
all inventory organizations.
MonitorOption 1 - Activity Based (Monitor based on
distinct inventory items in YFS_
INVENTORY_ACTIVITY table).
2 – Quick Sync (Re-raise event to publish
information from the YFS_INVENTORY_
ALERT 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.

726 Configuration Guide

 Monitors

Table A–288 Real-time Availability Monitor Criteria Parameters

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

Time-Triggered Transaction Reference 727

Monitors

Table A–288 Real-time Availability Monitor Criteria Parameters

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.
RaiseEventsOnAllAvailability When set to Y, REALTIME_AVAILABILITY_
Changes 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.

728 Configuration Guide

 Monitors

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

Table A–289 Events Raised by the Realtime Availability Monitor

Transaction
Template
Transaction/Event Key Data Data Published* Support?
REALTIME_ None YFS_REALTIME_ATP_ Yes
AVAILABILITY_ MONITOR.REALTIME_
CHANGE AVAILABILITY_
CHANGE.html
* These files are located in the following directory:
<INSTALL_DIR>/xapidocs/api_javadocs/XSD/HTML

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

A.6.9 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:
Q
If the Shipment has been in a status for more than a specified
amount of time.
Q
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

Time-Triggered Transaction Reference 729

Monitors

Q
If the Shipment has been in a hold type for a specified amount of
time.
Q
If the Shipment has been in a hold type for n hours before a specified
date.
Monitoring rules can be configured for shipment's origin and destination
points.
Monitoring rules cannot be configured for a shipment's intermediate
pickup and drop off points. A shipment has intermediate pickup or drop
off only if it has multiple pickup or drop off points. For example, a
shipment has more than one loads carrying it. The shipment status on
first load deposit, second load deposit, and so forth cannot be monitored.
Once the last load deposits the shipment at its destination, then the
shipment status can be marked and monitored.
This is not a pipeline transaction. It also does not work from the task
queue.
For more information about milestones, date types, and monitoring rules,
see the Sterling Supply Collaboration: Configuration Guide, the
appropriate section in this guide, and the Sterling Reverse Logistics:
Configuration Guide.

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

Table A–290 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

730 Configuration Guide

 Monitors

Criteria Parameters
The following are the criteria parameters for this monitor:

Table A–291 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 Optional. Number of records to retrieve and
To Buffer process at one time. If left blank or specified as 0
(zero), it defaults to 5000.
EnterpriseCode Optional. Enterprise for which the Shipment
Monitor needs to be run. If not passed, then all
enterprises are monitored.
CollectPendingJobs If this parameter is set to N, the agent does not
collect information on the pending jobs for this
monitor. This pending job information is used for
monitoring the monitor in the System
Management Console.
ColonyID Required in a multi schema deployment where a
table may exist in multiple schemas. Runs the
agent for the colony.

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–292 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.

Time-Triggered Transaction Reference 731

Monitors

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.

Note: If the default monitor template is used, the

MonitorConsolidation->Shipment->MonitorRule element is
ignored and is not passed into the condition.

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

732 Configuration Guide

 Monitors

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

Table A–293 Work Order Monitor Attributes

Attribute Value
Base Transaction ID WORK_ORDER_MONITOR
Base Document Type Work Order
Base Process Type VAS Process
Abstract Transaction No

Criteria Parameters
The following are the criteria parameters for this monitor:

Table A–294 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
Buffer process at one 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.

Time-Triggered Transaction Reference 733

Monitors

Statistics Tracked
The following statistics are tracked for this transaction:

Table A–295 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/WOR
K_ORDER_MONITOR_CONDITION.xml template file is used to obtain the
work order details and the evaluating monitor rule details. See the
provided <INSTALL_
DIR>/repository/xapi/template/source/smcfs/monitor/WORK_ORDER_
MONITOR_CONDITION.xml.sample file for more details.
If the <INSTALL_
DIR>/repository/xapi/template/source/smcfs/monitor/WORK_ORDER_
MONITOR_CONDITION.xml template file does not exist, the
MonitorConsolidation->WorkOrder element of the default monitor
template, the <INSTALL_
DIR>/repository/xapi/template/source/smcfs/monitor/WORK_ORDER_
MONITOR.xml file, is used.

Note: If the default monitor template is used, the

MonitorConsolidation->WorkOrder->->MonitorRule
element is ignored and is not passed into the condition.

734 Configuration Guide

 B
Order Modification Types

The following are the default order modification types and their
associated modification levels:

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Ad An instruction can be added Header
to an order document’s
Line
header, line, or shipment.
Shipment
For example, you may want
to add an instruction Receipt
stating that a line item
needs to be gift wrapped.
Add Line A line can be added to an Header
order document’s header,
Release
release, negotiation, or
shipment. Negotiation
Important: When adding a Shipment
line to an order, the Add
Line modification type does
not get 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.

Order Modification Types 735

Order Modification Types

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Add Quantity Additional quantity can be Line
added to an order
Release Line
document’s line or release
line.
Add/Remove Additional A date type used for Shipment
Date shipment monitoring (such
as, Ship Date) can either be
added to or removed from
an order document’s
shipment.
For example, you may want
to add an additional
delivery date used by your
organization to monitor
shipments.
Add/Remove Charge A charge can either be Shipment
added 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 Line
With Product Line of a product order line is
delivery, the product line
can be associated to a
delivery line to indicate how
the product line is
delivered.

736 Configuration Guide

 Order Modification Types

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Associate Product Line When the delivery method Line
With Delivery Line of a 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
Selling and Fulfillment
Foundation: Javadocs.
Backorder An order document’s line, Line
release, or release line can
Release
be backordered.
Release Line
For example, if an order is
released to a node and the
node does not have enough
quantity to fulfill the order,
they can backorder the
release.
Cancel An order document’s Header
header, line, release, or
Line
release line can be
manually cancelled from Release
the Application Consoles.
Release Line

Order Modification Types 737

Order Modification Types

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Change Additional A modification can be made Header
Address to the fields of any
Line
additional addresses that
may have been configured
for an order document’s
header or line.
Change Appointment Appointments can be taken Line
and changed for delivery
and provided service order
lines.
Change Bill To A modification can be made Header
to any bill to address field
Release
associated with an order
document’s header or
release.

738 Configuration Guide

 Order Modification Types

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Change Bundle The existing bundle Line
Definition definition 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.

Order Modification Types 739

Order Modification Types

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Change Carrier A modification can be made Header
to the Carrier/Service or
Line
Carrier field associated with
an order document’s Release
header, line, or 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 A modification can be made Header
Account No to the Carrier Account #
Line
field associated with an
order document’s header, Release
line, or release.
Change Carrier Service A modification can be made Header
Code to the Carrier/Service field
Line
associated with an order
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.

740 Configuration Guide

 Order Modification Types

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Change Cost A adjustment can be made Release
to the Unit Cost field
Release Line
associated with an order
document’s release or
release line.
Change Currency The currency associated Header
with an order document’s
header can be changed.
Upon a change to the
currency, Selling and
Fulfillment Foundation
automatically re-prices the
order. However, pre-existing
charges and taxes have to
be converted manually.
Change Custom Date A modification can be made Header
to the date type fields used
Line
for order monitoring
associated with an order Release
document’s header, line, or
release.
The following custom date
fields can be modified when
this modification type is
allowed:
Q
Requested
Q
Expected
Q
Actual
For example, if there is a
delay in a release’s
processing, you can change
the expected delivery date.

Order Modification Types 741

Order Modification Types

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Change Delivery Code A modification can be made Header
to the Delivery Code field
Line
associated with an order
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 A product order line Line
Method indicates how the product
id sent to its final
destination. It can be
changed to SHIP, DELIVER,
or PICKUP.
Change Expiration A modification can be made Negotiation
Date to the expiration date
associated with an order
document’s negotiation.
Change Freight Terms A modification can be made Header
to the Freight Terms field
Line
associated with an order
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).

742 Configuration Guide

 Order Modification Types

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Change Instruction A modification can be made Header
to an instruction associated
Line
with an order document’s
header, line, or shipment. Shipment
The following instruction Receipt
fields can be modified when
this modification type is
allowed:
Q
Instruction Type
Q
Text
Q
URL
Change Item A modification can be made Line
Description to the Description field of
an item associated with an
order document’s line.
Change Iteration A modification can be made Header
to the iteration fields
Line
associated with an order
document’s 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 Header
to the fields of the mark for
Line
address associated with an
order document’s header, Release
line, or release.
Change Order Name A modification can be made Header
to the Order Name field
associated with an order
document’s header.

Order Modification Types 743

Order Modification Types

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Change Other A modification can be made Header
Attributes to fields that do not have
Line
system or user-defined
modification types Release
associated with them.
Negotiation
Negotiation Line
Shipment
Change Other Not used in this version. Shipment
Relationships
Change Payment A modification can be made Header
Method to the Payment Type field
Release
associated with an order
document’s header or
release.
For example, you can
change an order’s payment
type from Check to Credit
Card.
Change Payment Rule The Payment Rule field Header
ID 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 The Payment Status field Header
Status 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.

744 Configuration Guide

 Order Modification Types

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Change Receiving The Receiving Node field Line
Node 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 Header
to the name/value pair in
Line
the YFS_REFERENCE_TABLE
using APIs.
Change Requested A modification can be made Header
Ship Date to the Requested Ship Date
Line
associated with an order
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 Header
to schedule attributes, such
Line
as expected ship date,
expected delivery date, and Release
lot number, associated with
Release Line
an order document’s
header, line, release, or
release line.

Order Modification Types 745

Order Modification Types

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Change Schedule Rule A modification can be made Header
ID to 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 Header
associated with an order
Line
document’s header or line
can be changed.
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 Header
to the fields of a ship to
Line
address associated with an
order document’s header, Release
line, or release.
Change Status The order status (such as, Header
Created) associated with an
Line
order document’s header,
line, release, release line, Release
or negotiation can be
Release Line
changed.
Negotiation
Note: Only order statuses
existing in process type
repositories are affected by
this modification type.
Actions performed against
order documents, such as
putting an order on hold or
canceling an order, are not
impacted.

746 Configuration Guide

 Order Modification Types

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Change Tax A modification can be made Header
to the Tax Amount
Line
associated with an order
document’s header or line.
Delete Shipment An order document’s Shipment
shipment can be deleted.
Hold An order document’s Header
header or release can be
Release
manually put on hold.
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.
Include In Load An order document’s Shipment
shipment can be included in
a load document.
Include Shipment in An order document’s Shipment
Delivery Plan shipment can be included in
a delivery plan.
Pack Shipment An order document’s Shipment
shipment can be packed.
Price Program The price program Header
associated 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 Line
From Product Line removed from product
Association order lines.

Order Modification Types 747

Order Modification Types

Table B–1 Order Document Modification Types

Modification Types Description Modification Levels
Remove Line A line can be removed from Header
an order document’s
Line
header, line, and shipment.
Shipment
Remove Option Options can be removed Line
from delivery and provided
services.
Remove Product Line Product lines can be Line
From Delivery Line removed from delivery
Association lines.
Remove Product Line Product lines can be Line
From Service Line removed from provided
Association service order lines.
Remove Service Line Provided service lines can Line
From Product Line be removed from product
Association order lines.
Remove Shipment An order document’s Shipment
From Delivery Plan shipment can be removed
from a delivery plan.
Short An order document’s Header
header, line, release,
Line
release line, and receipt can
be shorted. This occurs Release
when there is a shortage in
Release Line
the expected quantity.
Receipt
Split Line An order document’s line or Line
release line can be split into
Release Line
multiple lines.
Unpack Shipment An order document’s Shipment
shipment can be unpacked.

748 Configuration Guide

 Order Modification Types

Table B–1 Order Document Modification Types

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
header or line can be
Line
unscheduled from a
scheduled node. This
cancels any inventory that
has been reserved for the
order at the scheduled
node.

Order Modification Types 749

Order Modification Types

750 Configuration Guide

 C
Condition Builder Attributes

Statements in the condition builder are built using attributes that are
defined throughout the Applications Manager. This appendix describes all
of those attributes for each process type.
Click one of the links below to be taken to the appropriate condition
builder attributes description.

Sales Order
Q
Order Fulfillment
Q
Order Negotiation
Q
Outbound Shipment
Q
Sales Order Receipt

Planned Order
Q
Planned Order Execution
Q
Planned Order Negotiation

Return Order
Q
Reverse Logistics
Q
Return Shipment
Q
Return Receipt

Template Order
Q
Template Order

Condition Builder Attributes 751

 Purchase Order
Q
Purchase Order Execution
Q
Purchase Order Negotiation
Q
Inbound Shipment
Q
Purchase Order Receipt

Transfer Order
Q
Transfer Order Execution
Q
Transfer Order Delivery
Q
Transfer Order Receipt

Master Order
Q
Master Order Fulfillment

Quote
Q
Quote Fulfillment

Load
Q
Load Execution

General
Q
General
Q
WMS Putaway
Q
WMS Layout Definition
Q
WMS Inventory
Q
Trailer Loading
Q
Task Execution
Q
Move Request Execution
Q
Manifesting
Q
Over Pack Build

752 Configuration Guide

 Sales Order

Count
Q
Count Execution

Container
Q
Pack Process

Wave
Q
Outbound Picking

Work Order
Q
VAS Process

Opportunity
Q
Opportunity Fulfillment

Item-Based Allocation (IBA)

Q
Item-Based Allocation (IBA) Order

C.1 Sales Order

C.1.1 Order Fulfillment

Table C–1 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.

Condition Builder Attributes 753

Sales Order

Table C–1 Order Fulfillment Condition Builder Attributes

Attribute Description
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. 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. 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 The code of the organization that is buying the
Code 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 The code of the organization that is selling the
Code goods or services.
Ship Node The node that ships the shipment for the order.
Ship Node Interface The interface type of the ship node on the order
Type (External Application, Console, Sterling WMS, or
WMS 6.2).
Ship To ID The ID of the ship to address for the order.

754 Configuration Guide

 Sales Order

Table C–1 Order Fulfillment Condition Builder Attributes

Attribute Description
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 The flag indicating whether the order was
Backorder intentionally dropped into backordered status at
order creation.
Is Firm Predefined The flag indicating whether the node on the
Node order is a firm predefined node.
Order Sourcing The order sourcing classification of the order.
Classification
Reservation The flag indicating whether the reservation is
Mandatory 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.

Condition Builder Attributes 755

Sales Order

Table C–1 Order Fulfillment Condition Builder Attributes

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
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

C.1.2 Order Negotiation

Table C–2 Order Negotiation Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise on the order.
Initiator The code of the organization that initiates the
Organization Code negotiation.
Negotiator The code of the organization that can accept,
Organization Code counter-offer, or reject the initiator’s offer.
Negotiation Pipeline The key of the negotiation pipeline this order is
Key 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.

756 Configuration Guide

 Sales Order

Table C–2 Order Negotiation Condition Builder Attributes

Attribute Description
Payment Terms The payment terms for this order.
{Enter Your Own A customizable condition builder attribute. For
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

C.1.3 Outbound Shipment

Table C–3 Outbound Shipment Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise on the outbound
shipment.
Buyer Organization The code of the organization that is buying the
Code goods or services.
Seller Organization The code of the organization that is selling the
Code goods or services.
Ship Node The node that ships this shipment.
Ship Node Interface The interface type of the ship node on the order
Type (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 The flag indicating whether these materials are
Flag hazardous.

Condition Builder Attributes 757

Sales Order

Table C–3 Outbound Shipment Condition Builder Attributes

Attribute Description
ESP Check Required The flag indicating whether an Economic
Shipping Parameters check is required at
shipment consolidation time.
Is Appointment The flag indicating whether an appointment is
Required required for a service execution.
Routing Guide The flag indicating whether a routing guide is
Maintained maintained for this shipment.
Carrier The carrier for the shipment.
Real-time The flag indicating whether the node this
Integration with shipment is shipping from is integrating with the
WMS 6.2 Sterling WMS. 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 The country 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.

758 Configuration Guide

 Planned Order

Table C–3 Outbound Shipment Condition Builder Attributes

Attribute Description
Shipment Type Indicates a set of shipments that are of the same
nature.
{Enter Your Own A customizable condition builder attribute. For
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

C.1.4 Sales Order Receipt

The Sales Order Receipt condition builder attributes are identical to the
Return Receipt attributes.

C.2 Planned Order

C.2.1 Planned Order Execution

The Planned Order Execution condition builder attributes are identical to
the Order Fulfillment attributes.

C.2.2 Planned Order Negotiation

The Planned Order Negotiation condition builder attributes are identical
to the Order Negotiation attributes.

Condition Builder Attributes 759

Return Order

C.3 Return Order

C.3.1 Reverse Logistics

Table C–4 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. 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. 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.

760 Configuration Guide

 Return Order

Table C–4 Return Fulfillment Condition Builder Attributes

Attribute Description
Buyer Organization The code of the organization that is buying the
Code goods or services.
Enterprise Code The code of the enterprise on the return.
Receiving Node The node that receives the shipment for the
return.
Seller Organization The code of the organization that is selling the
Code goods or services.
Ship Node The node that be ships the shipment for the
return.
Ship Node Interface The interface type of the ship node on the return
Type (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 The flag indicating whether the return was
Backorder intentionally dropped into backordered status at
return creation.
Is Firm Predefined The flag indicating whether the node on the
Node return is a firm predefined node.
Order Sourcing The order sourcing classification of the return.
Classification
Reservation The flag indicating whether the reservation is
Mandatory mandatory.

Condition Builder Attributes 761

Return Order

Table C–4 Return Fulfillment Condition Builder Attributes

Attribute Description
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
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

C.3.2 Return Shipment

The Return Shipment condition builder attributes are identical to the
Outbound Shipment attributes.

C.3.3 Return Receipt

Table C–5 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 The code of the organization that is selling the
Code goods or services.
Ship Node The node where the shipment was shipped out
of.

762 Configuration Guide

 Template Order

Table C–5 Return Receipt Condition Builder Attributes

Attribute Description
Buyer Organization The code of the organization that is buying the
Code goods or services.
Receiving Node The node where the shipment was received.
Receiving Node The interface type of the receiving node on the
Interface Type order (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 The flag indicating whether there are hazardous
Material materials that are being received.
Is Inspection The flag indicating whether there is an inspection
Pending pending on this return.
Is Receiving Node The flag indicating whether the receiving node is
Integrated Real Time integrating with WMS 6.2, or with another WMS
system.
{Enter Your Own A customizable condition builder attribute. For
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

C.4 Template Order

The Template Order condition builder attributes are identical to the Order
Fulfillment attributes.

Condition Builder Attributes 763

Purchase Order

C.5 Purchase Order

C.5.1 Purchase Order Execution

Table C–6 Purchase Order Execution Condition Builder Attributes
Attribute Description
Order Attributes
Condition Variable 1 A variable that can be used for condition
building. This is an existing field in the YFS_
ORDER_LINE database table, and can be used to
create conditions without extending the
database.
Condition Variable 2 A variable that can be used for condition
building. This is an existing field in the YFS_
ORDER_LINE database table, and can be used to
create conditions without extending the
database.
Delivery Method The delivery method of the inbound order
(shipment, pickup or delivery).
Disposition Code The disposition code of the item.
Line Type The type of the inbound order line. 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. 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

764 Configuration Guide

 Purchase Order

Table C–6 Purchase Order Execution Condition Builder Attributes

Attribute Description
Bill To ID The ID of the bill to address for the inbound
order.
Buyer Organization The code of the organization that is buying the
Code 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 The code of the organization that is selling the
Code goods or services.
Ship Node The node that ships the shipment for the
inbound order.
Ship Node Interface The interface type of the ship node on the
Type 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 The flag indicating whether the inbound order
Backorder was intentionally dropped into backordered
status at inbound order creation.
Is Firm Predefined The flag indicating whether the node on the
Node inbound order is a firm predefined node.

Condition Builder Attributes 765

Purchase Order

Table C–6 Purchase Order Execution Condition Builder Attributes

Attribute Description
Order Sourcing The order sourcing classification of the inbound
Classification order.
Reservation The flag indicating whether the reservation is
Mandatory 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
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

C.5.2 Purchase Order Negotiation

Table C–7 Purchase Order Negotiation Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise on the inbound order.
Initiator The code of the organization that initiates the
Organization Code negotiation.
Negotiator The code of the organization that can accept,
Organization Code counter-offer, or reject the initiator’s offer.
Negotiation Pipeline The key of the negotiation pipeline this inbound
Key order is going through.

766 Configuration Guide

 Purchase Order

Table C–7 Purchase Order Negotiation Condition Builder Attributes

Attribute Description
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
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

C.5.3 Inbound Shipment

The Inbound Shipment condition builder attributes are identical to the
Outbound Shipment attributes.

C.5.4 Purchase Order Receipt

The Purchase Order Receipt condition builder attributes are identical to
the Return Receipt attributes.

Condition Builder Attributes 767

Master Order

C.6 Transfer Order

C.6.1 Transfer Order Execution

The Transfer Order Execution condition builder attributes are identical to
the Order Fulfillment attributes.

C.6.2 Transfer Order Delivery

The Transfer Order Delivery condition builder attributes are identical to
the Outbound Shipment attributes.

C.6.3 Transfer Order Receipt

The Transfer Order Receipt condition builder attributes are identical to
the Return Receipt attributes.

C.7 Master Order

C.7.1 Master Order Fulfillment

Table C–8 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).

768 Configuration Guide

 Master Order

Table C–8 Master Order Fulfillment Condition Builder Attributes

Attribute Description
Disposition Code The disposition code of the item. This field is only
applicable for Reverse Logistics and Supply
Collaboration.
Line Type The type of the order line. 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. 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 The code of the organization that is buying the
Code 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 The code of the organization that is selling the
Code goods or services.
Ship Node The node that ships the shipment for the order.
Ship Node Interface The interface type of the ship node on the order
Type (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

Condition Builder Attributes 769

Master Order

Table C–8 Master Order Fulfillment Condition Builder Attributes

Attribute Description
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 The flag indicating whether the order was
Backorder intentionally dropped into backordered status at
order creation.
Is Firm Predefined The flag indicating whether the node on the
Node order is a firm predefined node.
Order Sourcing The order sourcing classification of the order.
Classification
Reservation The flag indicating whether the reservation is
Mandatory 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
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

770 Configuration Guide

 Load Execution

C.8 Quote

C.8.1 Quote Fulfillment

The Quote Fulfillment condition builder attributes are identical to the
Order Fulfillment condition builder attributes.

C.9 Load Execution

Table C–9 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 The code of the organization that owns the load
Code 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.

Condition Builder Attributes 771

General

Table C–9 Load Execution Condition Builder Attributes

Attribute Description
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
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

C.10 General
Table C–10 General Condition Builder Attributes
Attribute Description
Enterprise Code The code of the enterprise.
Organization Code The code of the organization.
Provider The code of the organization that provides the
Organization Code service.
Ship Node The node that ships this shipment.
Supply Type The supply type associated with the inventory
status. Typical values are Onhand, Held, etc.
Item ID The ID of the item on the order line.
Unit Of Measure The unit of measure of the item.
Product Class The inventory classification of an item based on
the product's characteristics. Typical values are
FQ - First Quality, SQ - Second Quality, etc.

772 Configuration Guide

 General

Table C–10 General Condition Builder Attributes

Attribute Description
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
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

Condition Builder Attributes 773

Over Pack Build

C.11 WMS Putaway

The WMS Putaway condition builder attributes are identical to the
General attributes.

C.12 WMS Layout Definition

The WMS Layout Definition condition builder attributes are identical to
the General attributes.

C.13 WMS Inventory

The WMS Layout Inventory condition builder attributes are identical to
the General attributes.

C.14 Trailer Loading

The Trailer Loading condition builder attributes are identical to the
General attributes.

C.15 Task Execution

The Task Execution condition builder attributes are identical to the
General attributes.

C.16 Move Request Execution

The Move Request Execution condition builder attributes are identical to
the General attributes.

C.17 Manifesting
The Manifesting condition builder attributes are identical to the General
attributes.

C.18 Over Pack Build

The Over Pack Build condition builder attributes are identical to the
General attributes.

774 Configuration Guide

 Count Execution

C.19 Count Execution

Table C–11 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 The name of the count program for which the
Name count request is created.
Node Key The node where the count request is processed.
Zone ID The zone where the count must be performed.
Location Size Code The capacity of the location where the count
must be performed.
Is LPN Level The flag indicating whether the count tasks are
be performed at the LPN level.
Is Case Level The flag indicating whether the count tasks are
be performed at the case level.
Is Pallet Level The flag indicating whether the count tasks are
be performed at the pallet level.
Is Item Level The flag indicating whether the count tasks are
be performed at the item level.
Is Resolvable The flag indicating whether variance can be
resolved for this count result.
Product Class The inventory classification of an item based on
the product's characteristics. Typical values are
FQ - First Quality, SQ - Second Quality, etc.
Unit Of Measure The unit of measure of the item that was
counted.
Item Classification 1 The first item classification attribute for
determining the Count Strategy.
Item Classification 2 The second item classification attribute for
determining the Count Strategy.

Condition Builder Attributes 775

Pack Process

Table C–11 Count Execution Condition Builder Attributes

Attribute Description
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 The flag indicating whether the count request
Variance 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
Quantity and system quantity.
Variance Value The difference in cost/value (+/-) between the
count result and system quantity.
Absolute Variance The absolute difference in cost/value between
Value the count result and system quantity.
Has Variance With The flag indicating whether the variance between
Previous Count the current count result and previous count
results displays.
{Enter Your Own A customizable condition builder attribute. For
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

C.20 Pack Process

Table C–12 Pack Process Condition Builder Attributes
Attribute Description
Node Attributes
Ship Node The node that ships this shipment.

776 Configuration Guide

 Pack Process

Table C–12 Pack Process Condition Builder Attributes

Attribute Description
Receiving Node The node that receives this shipment.
Ship from Ship Node The interface type of the ship node from which
Interface Type the shipment is shipped (External Application,
Console, Sterling WMS, or WMS 6.2).
Ship from Supplier The code of the supplier that is shipping the
Code shipment.
Ship from DCM The flag indicating whether the node from which
Integration Real the shipment is shipped uses WMS 6.2.
Time
Ship from Country The code of the country from which the shipment
is being shipped.
Ship to Ship Node The interface type of the ship node to which the
Interface Type shipment is shipped (External Application,
Console, Sterling WMS, or WMS 6.2).
Ship to Supplier The code of the supplier to whom the shipment is
Code being shipped.
Ship to DCM The flag indicating whether the node to which
Integration Real the shipment is shipped uses WMS 6.2.
Time
Ship to Country The code of the country to which the shipment is
being shipped.
Organization Attributes
Enterprise Code The code of the enterprise that owns the
shipment.
Buyer Organization The code of the organization that is buying the
Code goods or services.
Seller Organization The code of the organization that is selling the
Code 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.

Condition Builder Attributes 777

Pack Process

Table C–12 Pack Process Condition Builder Attributes

Attribute Description
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 The number of containers in the shipment.
Count
Shipment The flag indicating the containerization state of
Containerized Flag the shipment. The values are: 01 - not
containerized, 02 - containerization in progress
and 03 - containerization completed.
Container Attributes
Is Shipment The flag indicating whether the container belongs
Container 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 The flag indicating whether the inventory
LPN container has been converted to a shipment
container.
Is Serial Capture The flag indicating whether the serial capture is
Pending pending for the container.
Is Pack Process The flag indicating whether any more pack
Complete activities are pending for the container.
Is Product Placing The flag indicating whether placing the product
Complete into the container according to the system’s
suggestion has been completed.
Requires VAS The flag indicating whether the container
requires value added services.

778 Configuration Guide

 Outbound Picking

Table C–12 Pack Process Condition Builder Attributes

Attribute Description
Has Child Containers The flag indicating whether a container is a
parent container having other containers.
Number of Items The number of items contained in the container.
Container Type The attribute that specifies whether a shipment
container is a case or pallet.
{Enter Your Own A customizable condition builder attribute. For
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

C.21 Outbound Picking

Table C–13 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
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

Condition Builder Attributes 779

VAS Process

C.22 VAS Process

Table C–14 VAS Process Condition Builder Attributes

Attribute Description
Enterprise Code The code of the enterprise that owns the item or
license plate.
Provider The code of the organization that provides the
Organization Code service.
Node Key The node, where the work orders are run.
Purpose The purpose for the work order (ORDER / STOCK
/ SHIP)
Service Item Group The code of the service item group
Code (KIT/DKIT/COMPL/INVC/PS)
Service Item ID The identifier for the service Item.
Segment Type The type of segment. This may be MTO (made to
order) or MTC (made to customer).
Segment The segment to which the inventory involved in
the work order belongs.
Has Components The flag indicating whether the work order has
component items.
Status The status of the work order.
Pre Call Status The flag indicating the status of the pre-call
process.
Appt Status The status of the appointment. This is in sync
with the service order line. The appointment
status is used in case of provided service work
order.
Number Of Attempts The number of attempts made to run the work
order.
Number Of Hours The number of hours left before the appointment
until Appointment for the service item.
Number Of Hours The number of hours after the last appointment
After Appointment for the service item.

780 Configuration Guide

 VAS Process

Table C–14 VAS Process Condition Builder Attributes

Attribute Description
Number Of Hours The number of hours after the last attempt to
After Last Execution run the service.
Last Execution The flag indicating whether the last attempt to
Success run the service was successful or not.
Open Work Order The flag indicating whether the execution of the
Flag work order has ended or not.
{Enter Your Own A customizable condition builder attribute. For
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

Condition Builder Attributes 781

Opportunity

C.23 Opportunity

C.23.1 Opportunity Fulfillment

Table C–15 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 The code of the organization that may buy the goods
Code or services.
Enterprise Code The code of the enterprise for the opportunity.
Owner User ID The user ID of the opportunity owner.
Co-Owner User ID The user ID of the opportunity co-owner.
Customer Contact ID The ID of the customer contact for the opportunity.
Team Code The code of the team that manages the opportunity.
{Enter Your Own A customizable condition builder attribute. For
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

782 Configuration Guide

 Item-Based Allocation (IBA) Order

C.24 Item-Based Allocation (IBA) Order

Table C–16 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.
Selling and Fulfillment Foundation 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.

Condition Builder Attributes 783

Item-Based Allocation (IBA) Order

Table C–16 IBA Attributes

Attribute Description
Ship To ID The ship-to identifier. If a customer definition
representing the buyer organization exists within
Selling and Fulfillment Foundation, 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.
Buyer Organization The code of the organization that is buying the
Code goods or services.
Seller Organization The code of the organization that is selling the
Code 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
Attribute} more information about customizing this field,
see the Selling and Fulfillment Foundation:
Extending the Condition Builder Guide .
Note: This field is limited only to unexposed key
attributes that are pre-defined by Selling and
Fulfillment Foundation as opposed to any XML
attribute that you can enter.

784 Configuration Guide

 Index

A lookup functionality, 28
on-line help, 34
additional logistic rules special characters, 35
defining, 155 troubleshooting, 34
Additional Optimization Criteria, 90 users, 31
address question groups layout, 10
deleting, 138 starting, 9
modifying, 138 work area, 23
address questions Apply Future Safety Factor To Future Inventory
capacity impact Availability flag, 88
capacity impact multiplier, 141 Apply On Hand Safety Factor To On Hand Inventory
defining, 141 Availability flag, 88
deleting, 143 approval plans for quotes, configuring, 321
fixed capacity impact, 141 approval rule violation reasons for quotes, 269
modifying, 142 ATP Rule, 57
defining, 138 authorization reversal, 179
deleting, 140 Available field, 317
modifying, 140
rearranging, 143
See also questions
B
address questions groups backorder reasons, 6, 261, 262, 263
defining, 137 Break Bulk Node field, 170
Allow Item Substitution If Inventory Is Not Available building
flag, 223 catalog index, 508
Allow Reservation During Scheduling field, 89 business models, 2
Allow Scheduling Against The Node That Requires marketplaces, 3
Drop Ship Chained Order Creation flag, 223 multi-divisional corporations, 2
answer options, 139 third-party logistics, 2
application rules side panel, 12 business rules, 3
Applications Manager
actions, 28
document types, 29 C
entering dates/times, 34
calendars, 61
lists, 31

785
Cancel Order For Inventory Shortage flag, 223 modifying, 366
Cancel Order for Inventory Shortage flag, 87 default distribution rule, 79
carrier modification reasons Default Supervisor field, 135
creating, 153 Delay Procurements To be Consolidated With
defining, 153 Shipments Against Future Coming
deleting, 154 Inventory., 91
modifying, 154 Delay Shipment Against Current Inventory To Be
Carrier Service Code field, 170 Consolidated With Shipments Against Future
Carrier/Service field, 170 Coming Inventory, 90
catalog delivery codes
index building, 508 creating, 157
chained orders, 63 defining, 157
definition, 124 deleting, 158
charge categories, 408, 411 modifying, 158
charge definitions, 407 delivery locations, 79
charge names, 409, 410, 411 delivery service items
common codes, 253 sourcing rules, 113
condition builder, 751 to 780 Description field, 97
configuration screens display control types, 139
accessing, 13 distributed order management configuration, 3
Configure Outbound Constraints field, 95 distribution groups, 79, 102
Consider Buyer’s Routing Guide field, 151 advanced distribution details, 106
Consolidator field, 169, 171 deleting, 107
Convert Node Priority into Cost field, 96 creating, 103, 117
Country field, 169 creating for procurement, 128
Currency field, 97 defining for product items, 102
Customer Components, 209 defining for provided service items, 117
customer components deleting, 108, 120
address questions, 222 deleting for procurement, 129
contact types, 230, 232 modifying for procurement, 129
definitions, 214 to 230 nodes
primary information, 219 adding, 104, 118
rules, 211 to 213 deleting, 105, 120
classifications, 212 to 213 modifying, 105, 119
service preferences, 220 sourcing, 104
customer identification master, 212 Do not mix in Shipment flag, 162
customers, 5 Do Not Recompute Expected Dates When
scheduling preferences, 222 Requested Dates On The Order Are Changed
field, 339, 341
document types, 425
D
date based dependency, 359 E
default dependency group
defining, 359 environment variable
deleting, 366 INSTALL_DIR, xlv

786 Configuration Guide

 INSTALL_DIR_OLD, xlvi Line Ship from Single Node flag, 87, 222
Euro Member field, 97 logistics, 5
Expiration Date field, 97 configuring components, 149
external organizations, 102 defining attributes, 149
lost reasons, 281 to 283
F
M
financial components, 405
financials, 5 Master Order
freight terms Next iteration date, 349
creating, 150 Master order
defining, 149 Next iteration date, 349
deleting, 152 Maximum no. of days order can be scheduled before
modifying, 152 its ship date field, 88
From field, 170 Maximum no. of days order can be
From Node field, 55, 65 shipped/delivered beyond its requested date
fulfillment types, 75, 78, 111 field, 88
creating, 57, 75 Maximum no. of days to search service availability
deleting, 59, 77 for field, 89
modifying, 58, 76 modification components, 285 to 293
rules, 285 to 289
types, 290 to 293
I
modification reasons, 6, 257 to 260
Ignore Fill Quantity (Ship Complete) field, 89 creating, 257
index deleting, 260
catalog search, 508 modifying, 259
inheritance, 78
determining, 14 N
INSTALL_DIR, xlv
INSTALL_DIR_OLD, xlvi Next iteration date, 349
instruction types, 6, 253 to 255 Node field, 171
creating, 253 Node Priority Cost Factor field, 96
deleting, 255 nodes, 63, 78, 79, 102
modifying, 254 note reasons, 265 to 267
inventory availability safety factors, 88
item classifications, 124
O
item level controls
defining, 56 order attributes, 5
item substitution, 62 external references
order level, 239, 240, 241
L order line level, 241, 242, 243
line types, 245, 246
lead origins, 269 to ??, 277 to 279 order address types, 243, 244, 245
Line Ship Complete flag, 87, 223 other attributes, 247

787
 generating prime line numbers, 247 process type configuration, 6
order promising procurement
configuring, 37 distribution groups, 128
nodes sourcing rules, 125
defining promising information, 59 procurement orders, 59, 124
order sources, 237, 238, 239 procurement rules
order sourcing classification defining, 124
defining, 80 product items
definition, 80 sourcing rules, 108
order sourcing classifications, 111 provided service items
creating, 80 distribution groups, 117
deleting, 82 sourcing rules, 120
modifying, 81 provided service locations, 80
order types, 235, 236, 237, 273, 274, 275 purchase orders
order validations, 6, 249 to 252 definition, 125
buyer validation, 252 Purge Code field, 426
seller validation, 233, 251 purge criteria, 7, 423 to 426
organization levels, 14 rules, 423
rules, 17
organization rules, 17
Q
loading another organization’s rules, 21
overriding, 18 questions
outbound constraints configuring, 136
defining, 160 definition, 136
Override Freight Terms field, 171 quote approval plans, configuring, 321
Override Ship To field, 171 quote rules, configuring, 346

P R
payment rules, 414 Receipt Processing Time for Forwarding
payment terms, 405, 406, 407 (Hours), 63
permit question groups Receipt Processing Time (Hours) field, 63
defining, 144 receiving discrepancy reasons, 418 to 422
deleting, 145 region schemas
modifying, 145 definition, 82
permit questions Delivery Region Schema, 82
defining, 145 Provided Service Region Schema, 82
deleting, 147 Shipped Product Region Schema, 82
modifying, 147 Reserve Bundle Out of Ratio field, 89
rearranging, 147 Retention Days field, 426
See also questions reverse authorization, 179
Postfix Symbol field, 97 Rollback Segment field, 426
Prefix Symbol field, 97 routing guide lines
Pricing organization, 14, 17 creating, 166
Priority field, 170 definition, 166

788 Configuration Guide

 deleting, 174 creating for procurement, 125
modifying, 174 creating for product item, 109
routing guides, 163 creating for provided service items, 121
creating, 163 default distribution rule, 79
deleting, 174 defining basic configuration, 77
modifying, 165 defining for delivery service items, 113
defining for product items, 108
defining for provided service items, 120
S
deleting for delivery service items, 117
scheduling preferences deleting for procurement, 128
customers, 222 deleting for product items, 113
scheduling rules, 74 deleting for provided service items, 124
constraints, 86 modifying for delivery service items, 116
creating, 85 modifying for procurement, 127
default rule, 84 modifying for product items, 112
defining, 83 modifying for provided service items, 124
deleting, 92 sourcing setup, 4
inventory controls, 87 State field, 169
lead times, 88 Store# field, 170, 171
modifying, 92 Subscribed field, 317
optimize on, 89 Synchronize Dates Between Master Order Dates
primary information, 86 And Dates On Order Line And Schedules
priority, 89 field, 339
retry intervals, 86
scheduling algorithm, 84 T
service execution
configuring components, 133 tax names, 412, 413, 414
service supervisors To field, 170
configuring, 133 To Node field, 55, 65
default, 133 transaction based dependency, 358
defining, 134 transaction dependencies
deleting, 135 configuring, 358
modifying, 135 transaction dependency
Ship Complete flag, 86, 222 configuring groups, 358
Ship from Single Node flag, 87, 222 creating rules, 362
ship node determination, 102 sequencing, 358
shipment modes types
creating, 159 date based, 359
defining, 158 transaction based, 358
deleting, 160 transaction dependency rule
modifying, 160 creating, 362
sourcing region selection creating constraints, 364
defining, 82 transaction dependency rule constraints, 364
sourcing rules, 74, 78, 79 Transfer Cost Factor Currency field, 95
creating for delivery service items, 113 Transfer Cost Factor __ Per __ Per __ for External

789
 Transfers field, 95
Transfer Cost Factor __ Per __ Per __ for Internal
Transfers field, 95
transfer orders
definition, 63, 125
transfer schedules, 63
creating for nodes, 64
deleting for nodes, 66
modifying for nodes, 66
transportation optimization, 162

U
Use Advanced Transit Time Calculation flag, 155
Use End Of Shift Time flag, 62
Use Handling Cost flag, 95
Use Item Cost flag, 94
Use Landed Cost flag, 94

V
Validate Charge Name flag, 415, 418
Validate Customer ID flag, 252
Validate Item flag, 252
Validate Vendor ID flag, 252

W
When Optimizing On Cost, Combine
Shipments., 90
work orders, 62
workflows, 3

Z
Zip Code field, 169

790 Configuration Guide