Implementation Guidelines
Message Type: XML
RosettaNet PIP 3A4: Submit Purchase Order
V02.00.00
Owner: EBIS
Guide Revision Number: 32
Last Revision Date: Sep 11, 2017
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 2 of 144
Table of Contents
Preface 13
Summary of Changes ..................................................................................................................... 13
Known Limitations .......................................................................................................................... 26
1 Introduction 27
1.1 Overview............................................................................................................................... 27
1.2 Audience .............................................................................................................................. 28
1.3 Scope ................................................................................................................................... 28
1.4 Prerequisites ......................................................................................................................... 28
2 Purchase Order Request: Process 29
3 Message Guideline (PIP 3A4 V02.00.00) 31
3.1 Guideline Annotations ........................................................................................................... 31
3.2 Service Header Part Message Guideline................................................................................ 31
3.2.1 Service Header Guideline for RNIF 1.1, RNIF 2.0 ......................................................... 32
4 Functionality 36
4.1 Participant Information .......................................................................................................... 36
4.2 Document Function Code ...................................................................................................... 37
4.3 Order Routing ....................................................................................................................... 37
4.4 Purchase Order Number ....................................................................................................... 38
4.5 Duplicate PO Number Check ................................................................................................. 38
4.6 Purchase Order Type ............................................................................................................ 39
4.7 Purchase Order Billing Information ........................................................................................ 41
4.8 Financing Terms.................................................................................................................... 43
4.9 Order Shipping Information ................................................................................................... 43
4.9.1 Request Ship Date ....................................................................................................... 43
4.9.2 Shipping Address ........................................................................................................ 43
4.10 Shipment Logistics ................................................................................................................ 49
4.10.1 Shipment Terms Values in 3A4 .................................................................................... 49
4.11 Shipment Routing Configuration Tool .................................................................................... 53
4.12 Shipping and Packaging Notes .............................................................................................. 54
4.13 Ship Set Number ................................................................................................................... 55
4.14 End User / Install Site ............................................................................................................ 55
4.14.1 Guidelines ................................................................................................................... 56
4.14.2 End Customer Notes.................................................................................................... 58
4.15 End User Vertical Market ....................................................................................................... 59
4.16 Product Line Number and Quantity ........................................................................................ 60
4.17 Product Line Reference ......................................................................................................... 60
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 3 of 144
5 Order Product 61
5.1 Product Number .................................................................................................................... 61
5.2 Configurable Products .......................................................................................................... 61
5.3 Non-Configurable (Spare and Software Upgrades) Products ................................................ 62
5.3.1 Included Sub-Products ................................................................................................ 62
5.3.2 Service Products ......................................................................................................... 62
5.3.3 FULFILLMENT RESTRICTIONS on SKUs ....................................................................... 63
5.3.4 Meraki SKUs ................................................................................................................ 63
5.4 Service Ordering – Product Link ............................................................................................ 64
5.5 Service for Products on the Same PO ................................................................................... 64
5.6 Service Ordering for Product(s) at Partner Site...................................................................... 66
5.7 Service Ordering ................................................................................................................... 68
5.7.1 Service Contract Information ....................................................................................... 68
5.7.2 Primary and Secondary Services (Technical) ............................................................... 70
5.7.3 Reseller Information ..................................................................................................... 71
5.8 Config Check ........................................................................................................................ 72
5.9 All or Nothing Rule ................................................................................................................ 73
5.10 Sample Orders ...................................................................................................................... 73
5.11 Deal ID Validations ................................................................................................................ 73
6 Special Cisco Programs 75
6.1 Channels Booking Neutrality ................................................................................................. 75
6.2 Managed Services Channels Program (MSCP) ...................................................................... 75
6.3 United States Government Orders ......................................................................................... 75
6.3.1 Government Eligibility Check ....................................................................................... 76
6.3.2 Trade Agreement Act (TAA) Orders ............................................................................ 76
6.4 Try and Buy (TAB) Program ................................................................................................... 77
6.5 Trade-In Migration Orders .................................................................................................... 78
6.6 eRate Orders......................................................................................................................... 78
6.7 Promotional Orders ............................................................................................................... 79
6.8 Advanced Services Fixed (AS-Fixed) Ordering ..................................................................... 79
6.9 UCSS and Term and Content Subscription Services Ordering ............................................... 80
6.10 Co-Terming .......................................................................................................................... 81
6.11 Donation Orders .................................................................................................................... 82
6.12 Country Enablement - Brazil .................................................................................................. 82
7 Special Cisco Ordering Functions 93
7.1 Zero Pricing .......................................................................................................................... 93
7.2 DotX and getLatest Function ................................................................................................. 93
7.3 KitRef .................................................................................................................................... 94
7.4 ConfigRef .............................................................................................................................. 96
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 4 of 144
7.5 Email Order Acknowledgments ............................................................................................. 99
7.6 Order Contacts ..................................................................................................................... 99
7.7 Order Reference ................................................................................................................. 100
7.8 Order Processing Notes ...................................................................................................... 101
7.9 Order Notes ........................................................................................................................ 101
7.10 SWIFT and eDelivery Products ............................................................................................ 101
7.11 Flexible Service Start Delay (FSSD) ..................................................................................... 102
7.12 Cisco Capital Pre-Owned Equipment Orders ...................................................................... 103
7.13 Cisco Software Simplification - Smart Software Licensing .................................................. 104
7.14 Ultimate Consignee Address and Consignee Type .............................................................. 106
7.15 Co-term of Initial Purchase SWSS Technical Service .......................................................... 110
8 Product and Order Price 113
8.1 Currency Code .................................................................................................................... 113
8.2 Price List Identifier .............................................................................................................. 113
8.3 Product Price ...................................................................................................................... 113
8.4 PO Amount ......................................................................................................................... 114
9 Tax Exemption 116
9.1 Tax Exempt Status .............................................................................................................. 116
9.1.1 Canadian Orders ....................................................................................................... 116
9.1.2 Australian Orders ....................................................................................................... 116
9.1.3 US Orders ................................................................................................................. 116
9.2 Taxability Derivation ............................................................................................................ 117
10 Integration with CCW Quoting and Configuration Solutions 119
10.1 Tier Partner Quoting and Ordering with a Deal Id – Punchout Flow ...................................... 119
10.1.1 Tier Partner Quoting and Ordering with Deal ID (Quick Quote) – Punch Out Flow ....... 119
10.1.2 Tier Partner Quoting and Ordering – Standalone Order (no Deal ID) – Punch Out Flow120
10.2 Procurement User Creates a Purchase Order in Partner’s Internal System .......................... 121
10.2.1 Product References ................................................................................................... 122
10.2.2 Configuration Check .................................................................................................. 123
10.2.3 Included Items ........................................................................................................... 123
11 Purchase Order Confirmation 124
12 Order Acknowledgement Email 129
12.1 Accept Scenarios ................................................................................................................ 129
12.2 Reject Scenarios ................................................................................................................. 129
Appendix A: Error Messages 131
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 5 of 144
Appendix B: Sample Output from Transfer Quote WS 132
Appendix C: Address Processing 133
Appendix D: Links and References 134
Appendix E: Glossary of Terms and Abbreviations 135
Appendix F: BLOCK SKUs 138
Appendix G: Redundancy and Default attributes 140
Appendix H: Accepted Diacritics 141
Appendix I: List of Operating Units 142
Appendix J: Products and Service ordering business rules for Cisco Brazil entity 143
Appendix K: Smart Software Licensing 144
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 6 of 144
Tables
Table 1: Change Log ........................................................................................................................ 13
Table 2: Cardinality Values and Color Codes .................................................................................... 31
Table 3: Service Header Guideline for RNIF V02.00.00 ..................................................................... 32
Table 4: Participant Information for PIP 3A4 V02.00.00 .................................................................... 36
Table 5: Document Function Code for PIP 3A4 ................................................................................. 37
Table 6: Order Routing ..................................................................................................................... 38
Table 7: Mandatory Information for PIP 3A4 V02.00.00 .................................................................... 38
Table 8: Duplicate PO Number Check ............................................................................................... 39
Table 9: Values Set for Cisco Order Reason – 3A4 XML .................................................................. 39
Table 10: PIP 3A4 V02.00.00 – Purchase Order Type ....................................................................... 40
Table 11: PIP 3A4 V02.00.00 – Purchase Order Billing Information ................................................... 41
Table 12: Financing Terms ............................................................................................................... 43
Table 13: Required, Optional, and Non Required Data for Shipping Address .................................... 44
Table 14: PIP 3A4 V02.00.00 - Line Level Requested Ship Date and Address ............................... 45
Table 15: Purchase Order Level Requested Ship Date and Address in PIP 3A4 V02.00.00 ............... 47
Table 16: Purchase Order Level in PIP 3A4 V02.00.00 ..................................................................... 50
Table 17: ProductLineItem in PIP 3A4 V02.00.00 ............................................................................. 52
Table 18: Purchase Order Level in PIP 3A4 V02.00.00 ..................................................................... 53
Table 19: ProductLineItem Level in V02.00.00 .................................................................................. 54
Table 20: PIP 3A4 V02.00.for Shipping and Packaging Notes ........................................................... 55
Table 21: Address Requirement Grid ................................................................................................ 56
Table 22: PIP 3A4 V02.00.00 ........................................................................................................... 57
Table 23: PIP 3A4 V02.00.00 - End User Vertical Market ................................................................. 59
Table 24: Values for Vertical Market ................................................................................................. 59
Table 25: PIP 3A4 V02.00.00 - Quantity ........................................................................................... 60
Table 26: PIP 3A4 Version 02.00.00 – Service Products ................................................................... 62
Table 27: PIP 3A4 Version 02.00.00 – Service for Products on the same Order ................................ 65
Table 28: PIP 3A4 Version 02.00.00 – Service Ordering for Products at Partner Site ....................... 67
Table 31: PIP 3A4 V02.00.00 – Deal ID Validations ........................................................................... 73
Table 34: PIP 3A4 Version 02.00.00 for TAA Orders ........................................................................ 77
Table 41: PIP 3A4 Version 02.00.00 for Donation Orders ................................................................. 82
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 7 of 144
Table 52: BLOCK SKUs .................................................................................................................. 138
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 8 of 144
Figures
Figure 1: High-Level General Sales Process Flow ............................................................................. 27
Figure 2: Service for Purchase Order Request Process ..................................................................... 30
Figure 3: Service for Products on the Same PO Order ...................................................................... 65
Figure 4: Procurement User Creates a Purchase Order in Partner’s Internal System ....................... 121
Figure 5: Partner Creates and Acquires Quote, Deal, and Configuration via the AcquireQuote or
TransferQuote Web Service and Punches Out to Configurations Web Services ....................... 121
Figure 6: Partner System Sends a 3A4 XML Order to NG00 ........................................................... 122
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 9 of 144
Revision History
Rev No. Revision
Date
Description Reason for Change Revised By
01 09/30/2011
Initiate CCW Implementation
Guide
Sept 2011 Purna Sharma
02 11/10/2011
Added Glossary of Terms,
Summary of Changes,
and details surrounding the
enablement of the newer
business models and
integration with CCW via
Acquire/Transfer Quote
WebService.
Internal review Bindu Thomas
03 11/14/2011
Incorporated feedback from
additional internal review
Internal review Bindu Thomas
04 11/22/2011
Modifications after review
by PS team
PS team review Bindu Thomas
05 11/28/2011
Adding clarifications
surrounding line numbering
PS team review Bindu Thomas
06 12/01/2011
Modifications to include
March 2012 Service Only,
AS-Fixed, UCSS and Term
and Content ordering
December 2011 Bindu Thomas
07 02/13/2012
Modified to include
clarification about Disti
Resale Kit Ref Orders with
Service Lines
Functionality clarification Bindu Thomas
08 02/27/2012
Clarifications surrounding
Service Only ordering
March 2012 Bindu Thomas
09 03/28/2012
Revisions based on
feedback during review with
support team and PSPM
team.
Added TAA related changes
Review Bindu Thomas
10 07/27/2012
Revisions based on
feedback
Zero price logic valid countries is
not limited to 4 countries
Shreyas
Manjunath
11 07/27/2012
Revisions to the error
messages table based on
feedback on Deal validation
error messages
Shreyas
Manjunath
12 08/27/2012 Taxability updates
CR December 2012- Taxability
verbiage changes and updates
Shreyas
Manjunath
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 10 of 144
Rev No. Revision
Date
Description Reason for Change Revised By
13 07/27/2012
Updates PDP values,
changes to proprietary
information text for
Configuration Path, Landing
Cost SKUs
Sept 2012
Shreyas
Manjunath
14 08/28/2012
Intended Business Use table
refreshed to reflect the
current derivation rules
Document updated
Shreyas
Manjunath
15 09/28/2012
DotX productID value start
with a “S”
DotX product IDs do not start
with “FR” and “FL”. Document
updated.
Shreyas
Manjunath
16 11/20/2012 September 2012 Release December 2012
Shreyas
Manjunath
17 12/17/2012 September 2012 Release December 2012
Shreyas
Manjunath
18
02/19/2013
and
03/04/2013
Documentation update
and
March 2013
Restructured focus to technical
and business audience
and
March 2013
Laura Stearns
and
Shreyas
Manjunath
19 09/25/2013 Documentation Update
Deal Validation Error message
updates/Format update for Deal
ID value
Analyst Team
20 01/21/2014 Documentation Update Added Q3FY14 and MR changes Analyst Team
21 02/13/2014 Documentation Update
Removed the sample error
message table as it was
redundant
Sanoj
Shivashankara
n
22 02/13/2014 Documentation Update
Update CE Brazil Product &
service ordering business rules
Update Contract Start date for
Initial purchase of services
Sanoj
Shivashankara
n/Tazin Nahid
23 03/20/2014 Documentation Update
Updated Fulfillment Restriction
Options for B2B XML & EDI
ordering
Sanoj
Shivashankara
n
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 11 of 144
Rev No. Revision
Date
Description Reason for Change Revised By
24 04/01/2014 Documentation Update Updated Global RNSD validation
Sanoj
Shivashankara
n
25 04/16/2014 Documentation Update
Updated FSSD Validation section
for additional order reject
scenario
Naveen Garg
26 05/15/2014 Documentation Update
Q4FY14 – CR72
:Technical
Service duration accepts up to 60
months
Sanoj
Shivashankara
n
27 08/09/2014 Documentation Update
Added guidelines for Q2FY15
changes
1) Smart Software Licensing
2) Ultimate Consignee
3) eDeliveryemail address
4) Refurbished / Pre-owned
SKUs
Sanoj
Shivashankara
n
28 08/04/2015 Documentation Update
Added guidelines for Q4Fy15
scope changes:
1) Co-term of Initial
Purchase SWSS Technical
Service (End date Alignment for
Technical Services)
Updated
a) “RoHS_Terms” name value
pair for Refurbished / Pre-
owned SKUs
b) Meraki Ordering validation
changes
Sanoj
Shivashankara
n
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 12 of 144
Rev No. Revision
Date
Description Reason for Change Revised By
29 11/20/2015 Documentation Update
Added guidelines for Q2FY15
scope changes:
1) Contract number.
2) Global Transportation
event code.
Updated:
a) Contract number value
‘New’ or ‘Use-
Existing’ to be derived
from profiles and
preferences if set up
when not sent in PO.
b) Global Transportation
event code updated to
accept additional LOVs’-
‘Dock’ & ‘Pick-up’.
Venkat
Maddukuri
30 02/22/2016
XaaS/On premise ordering
enablement
Updated information to submit a
new/change XaaS/on premise
offer order.
Venkat
Maddukuri
31 09/11/2017
Smart account defaulting
from quote.
Updated information on the
defaulting logic for smart account
from quote.
Venkat
Maddukuri
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 13 of 144
Preface
Submit Purchase Order is a process by which Cisco partners may submit purchase orders via B2B
interchange. The partner creates the PIP 3A4 Request in their purchasing system, then submits that
request to Cisco via an XML Gateway. Cisco processes the request and then sends a PIP 3A4
Confirmation to the partner. The partner processes the PO Confirmation.
In addition to purchase ordering, solutions are available for processes such as preparing and
managing configurations, quoting, and invoicing. B2B integrations help partners to:
Work in their own systems
Improve productivity
Lower costs and cycle time
Obtain critical and accurate business information faster and easier
Perform real-time business processing between the partner’s system and Cisco
Summary of Changes
Given below is a summary of the change history of the Cisco Commerce Workspace (CCW) platform
as it relates to Submit Purchase Orders. One previous version of CCW is provided for reference.
CCW provides one integrated, streamlined, and simplified commerce
experience that allows partners to register deals, configure and price
products, software and related service, and submit orders from a single
workspace.
Table 1: Change Log
Ref
No.
Description of Change
Location in the IG
Release
IG Version: 29.0
119
Defaulting smart account information from quote for Q1FY17
Section 7.13
Q1FY17
118
XaaS/On Premise ordering enablement via B2B for Q3FY16
Section 6.13
Q3FY16
118
Added additional LOVs (Dock, Pick-up) for
TransportEventCode
Section 4.9.2
Q2FY16
117
Added:
Contract ‘New’ or Use Existing’ to be defaulted from profiles
and preferences of the user if not sent in the PO request
Section 5.7.1
Q2FY16
116
Updated:
a) Changed the attribute “RoHS_Terms” for
Refurbished / Pre-owned SKUs
Section 7.12
Section 5.3.4
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 14 of 144
Ref
No.
Description of Change
Location in the IG
Release
b) Meraki Ordering validation changes for Enterprise
and Advanced Security licenses
Added: Changes in Purchase Order Request for below
Q4Fy15 ordering enhancement
a) Co-term of Initial Purchase SWSS Technical Service
(End date Alignment for Technical Services)
Section 7.15
115
Updated: Changed the content for SWIFT / eDelivery email
address
Added: Changes in Purchase Order request for below
Q2FY15 ordering enhancements
a) Refurbished / Pre-owned SKU ordering
b) Cisco Smart Software Licensing
c) Ultimate Consignee Address and Type
Section 7.10
Section 7.12
Section 7.13,
Appendix K
Section 7.14
Q2FY14
114
Added: Support for Technical Services (TSS) with duration
up to 60 months
Notes under section
5.7.1
Q4Fy14
113
Added: Additional scenario for FSSD Order Rejection
validation
Table under section
7.11
Q4FY14
112
Added: PO rejection for Global RNSD
Table 32 under
section 5.11
Q3FY14
PR2
111
Added: Fulfillment Restriction details for 3A4 Order
5.3.3
Q4FY14
110
Updated: Contract Start Date for Initial purchase of services
5.7.1
Not
Applicabl
e
109
Updated: CE Brazil – Product and Service ordering business
rules
Appendix J
Q4 FY14
108
Removed sample error message table as the validation
details are called out in the respective sections
Appendix A
Not
Applicabl
e
107
Added: CE Brazil -
As part of the Country Enablement
initiative, Cisco will enable Brazil place orders on the
to-be CE Brazil Business Operating Unit via B2B.
6.12
Q4FY14
106
Updated: Content on Order Ack Emails – Order ack emails will
include the Partner Name or CCO ID and any order notes, end
customer notes that is sent in on the PO.
12.1
Q4Fy14
105
Updated: Ordering services/subscriptions attached to
system included items- In case of ordering
services/subscriptions attached to system included items,
5.5
Q4FY14
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 15 of 144
Ref
No.
Description of Change
Location in the IG
Release
partners are expected to send the system included items along
with the associated services/subscriptions on the PO
104
Added: FlexibleServiceStartDelay - FSSD allows partners
to order Product + Service in CCW and automatically
delay service start up to 60 days after ship date.
7.11
Q4FY14
103
Updated: Deal ID validations – Deal ID validation
enhancements to reduce order booking cycle.
5.11
Q3Fy14
102
Updated:Rejection Email Addressee list –
In case of
rejections system will send out the rejection status email
to the email address(es) in OrderAck name-value pair
and/or email addresses of the DUNS setup in Cisco’s
B2B ordering system.
12.2
Q3FY14
101
Added: Reseller Information on PO –
Partners are expected
to send reseller information on the PO in the
SecondaryBuyer tags at header level. System will no
longer read reseller information from the freeform Text
name value pairs at header or line level.
5.7.3
Feb MR
99
Updated: LOV values for GlobalPurchaseOrderTypeCode –
Updated the valid values that system accepts in the
GlobalPurchaseOrderTypeCode to reflect RN
Compliance. Specifically, change to accept “Consigned
order”
4.6
Q3Fy14
98
Updated: Order Contact defaulting –
In case the order
contact information is not explicitly provided in the PO
(no order contact name-value pairs), system will default
the order contact information from the
fromRole/
PartnerRoleDescription/ContactInformation tags
7.6
Q3FY14
97
Updated: End User information on POA –
Partners will
receive the end user information on the POA in the
scenario when the end user is not specified on the PO
and has been picked from the deal.
11
Q3Fy14
96
Updated: Mandatory elements in addresses-
PO’s not
having mandatory elements in the addresses (End-user,
billTo, ShipTo, Reseller, Install site at header or line as
applicable) – will be rejected
4.14.1
Q3Fy14
95
Updated: Duration Defaulting for Services and Subscriptions
– In case of partners not specifying the Contract Duration
or Contract Start date and Contract End Date on the PO,
system defaults the duration based on the standard
duration that has been setup for the
service/subscription.
5.7.1
Q3Fy14
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 16 of 144
Ref
No.
Description of Change
Location in the IG
Release
94
Added: End Customer Notes -
Partners can send any notes
for their customers (for example – Customer PO Number)
at header and/or line level in name value pair
“EndCustomerNotes”.
4.14.2
Q3FY14
93
Added: Ordering Primary and Secondary Technical Services
- Secondary coverage is sold as a compliment to a primary
coverage when additional service is needed that is not
included in the primary service program. Ordering of these
Secondary services and the validations associated with
them.
5.7.2
Q3FY14
92
Updated: Price list mismatch error-
A PO having whole
sale price list and if the line monetary amount is not
matching system calculated Net Price for that line will
result in PO rejection.
8.3
Q3FY14
91
Added: Order Notes -
Partners can enter order notes on
the Purchase Order for their own references. Cisco
would not take any action on these but these can be
viewed on the Order View status screens.
7.9
Q3FY14
90
Updated: Deal Validation Error Messages/Warnings updated
based on the current implementation
Appendix A
Q2FY14
89 Updated: Deal ID format update
5.11
Q2FY14
88
Updated: End User information when picked up from Deal will
be sent back on the Purchase Order Confirmation
11
To be
updated
87
Updated: End User Address ID when on the PO, needs to be
numeric only
4.14
Q2FY14
86
Updated: Support enabled for multiple Serial Numbers on PO
for a service line
5.6
Q2FY14
85
Updated: Rules for mandatory address elements per country
for all address sections have been updated
Appendix C
Q2FY14
84
Updated: Support for service contract durations greater than 36
months is enabled on orders with Non stzndard deals or for
OSM/OEM users
5.7.1
Q1FY14
83
Updated: DotX recognized pattern is “x” instead of “X” or
“LATEST”
7.2
Q1FY14
82
Updated: The subject line of the email message regarding
acceptance contains web order ID and the po number
11
Q1FY14
81
Updated:
PO’s which have TAA+ SKU’s but if partners have not
indicated that the order be TAA compliant, then order is
rejected
6.3.2
Q1FY14
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 17 of 144
Ref
No.
Description of Change
Location in the IG
Release
80
Updated: Ship set number assignment is done internally during
order processing. In order for partners to request shipping all
items separately, they can either have
"GlobalSpecialFulfillmentRequestCode" as blank so it’s
taken from User profile ( it can get setup as Ship All
items Separately = 'Y') or the user can
also send GlobalSpecialFulfillmentRequestCode ='SHIP
PARTIAL - BALANCE BACK ORDER'
4.13
Q1Fy14
79
Updated: Contract start date is not defaulted with the
requested ship date for services. If no values are provided on
the PO, contract duration is defaulted.
Q1FY14
78
Updated: Purchase order confirmation emails going out – the
format of the accept email message contains a lot more detail
Section 11
July 2013
77
Updated: Known limitations for kitRef and ConfigRef – ZPL is
not supported on kitRef and ConfigRef orders
Section 7.3 and
section 7.4
July 2013
76
Updated: Shipping Information defaulting. When carrier
information and carrier account number is not provided on the
PO request, but the routing preference is Customer Routed,
then system defaults this information from the SRC tool for the
user profile. This derivation happens before the order is
imported into ERP but is not reflected on the POA. In case
these are not setup in the SRC tool, then system raises tasks to
reflect the same.
Section 4.11
June
2013
75
Updated: End User/install Site contact information. System
expects Contact Name, Address Line 1 and Country as
required attributes to create new contact. Depending upon the
country there may be other fields that the system expects like
City and/or state in order to create or validate contacts. If
contacts are not created/validated, system reports a warning
to the same effect
Section 4.14.1
June
2013
74
Added: Reseller BID information can be sent by partners at line
level or header level
Section 5.7.1
June
2013
73
Added: Meraki SKU ordering needs contact and address
information for processing without delays
Section 5.3.4
May 2013
72
Added: Partial Service Ordering enables distributors place
resale service orders even for products that have not yet been
shipped
Section 5.6
May 2013
71
Added: Delivery Options enables partners to send in requested
delivery option details on a purchase order
Section 4.10
May 2013
70 Added: Changes in relation to kitRef
Section 7.3
May 2013
69 Added: Changes in relation to ConfigRef
Section 7.4
May 2013
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 18 of 144
Ref
No.
Description of Change
Location in the IG
Release
68
Added: Purchase order confirmation header and line level
values sent back from system is detailed
Section 11
April
2013
67
Added: Product References format updated. Partners can now
send Redundancy and/or default flags as part of the
configuration Information at line level. System ignores values
send as selection sequence. System is also able to derive the
Redundancy and default flags, along with config path and
selection flags at line level based on the Cisco Product
Reference Code aka hash code.
Section 10.2.1
April
2013
66 Added: Order Reference is echoed back on a POA.
Section 7.6
April
2013
65
Added: On a POA, the po line ref at line level, in case of zero
priced system added SKU lines, is truncated to 6 characters to
be in line with RN standards
Section 7.1
April
2013
64
Added: Note – In case Contract duration is not provided on an
order for subscription SKU’s, systems defaults this attribute
internally. If a Contract start date is not provided for
subscription SKU’s then system defaults this from the
requested ship date at the corresponding line level or current
date (if requested ship date is unavailable).
Section 6.9
April
2013
63
Added: In case an invalid TAB deal is provided on a TAB
order, the system performs configuration validations, but
rejects the order
Section 6.4
April
2013
61
Added: Known system limitation around processing of multiple
serial numbers at line level.
Section 5.6
April
2013
60
Added: Accepted values in the
ProductIdentification/PartnerProductIdentification/GlobalPartne
rClassification at a line level
. On a POA, this value would be
“Manufacturer” for all lines
Section 5.3.2
April
2013
57
Added: Acceptable formats for billTo/contactName are
<firstName> <lastName> or <firstName>, <lastName>.
Sectio 4.7
April
2013
56
Added: Acceptable values on BID
(billTo/GlobalLocationIdentifier) and details around
invalid/missing values on BID
Section 4.7
April
2013
55
Added: Note: Any other values sent other than Contract (as
specified in the table that follows) will be ignored.
Section 5.11
March
2013
54
Added: Invalid value: 00000000Z. If provided, the system will
default to Submit Date +1
Tables 14 (Element
306) and 15 (Element
344) in Section 4.9.2,
Shipping Address
March
2013
53
Added:
Known Limitation
Section 5.6
March
2013
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 19 of 144
Ref
No.
Description of Change
Location in the IG
Release
The system cannot currently proceed with processing orders
with only service lines, but no serial number information/PAK
number information at line level.
52
Added:
Donation Orders
Donation orders are orders submitted as part of Cisco
Corporate Donation Program. This functionality allows
members of the Cisco Corporate Donation Program to submit
orders in CCW-B2B with the correct discount and removes the
manual processing that CPE had to do on all of these orders.
To derive an order intended for Donation purposes, the system
looks for a name value pair of Donations in the tag as
described in the table that follows. (See Section 6.11 to view
the table.) Note: Any other value sent as part of the name value
pair is ignored and the order is processed as normal.
Section 6.11
March
2013
51
Added: Donations (Element #304) column to Table 9: Values
Set for Cisco Order Reason – 3A4 XML.
Condensed view of the table follows:
Global PO Type Code
(Element #92)
Donations (Element
#304)
Evaluation
Not Considered
Sample
Not Considered
Service
Not Considered
Replenishment
Not Considered
Site
Not Considered
Consigned order
Not Considered
Standard Not Provided
Standard
Not Provided
Standard
Y
Section 4.6, Table 9
March
2013
50
Added: The use of ServiceFor (Element #304) tag has been
discontinued.
Partners will have to send Line ID and Parent Line
ID to indicate the service linkage.
Section 4.17
March
2013
49
Changed: Changed “Consiged Order” to “Consigned order” in
all instances of use in the Implementation Guidelines
Section 4.6, Table 9
and Table 10
Section 6.2
Section 9.2
, Table
545
March
2013
IG Version: 17.0 and Earlier
48
Changed: Character length to 120 characters in the
contactName.FreeFormText element of the Participant
Information section for PIP 3A4 V02.00.00.
Section 4.1 (Table 4,
Element 3)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 20 of 144
Ref
No.
Description of Change
Location in the IG
Release
47
Added: The GlobalPurchaseOrderTypeCode for MSCP orders
should be set to “Consigned order”. This is a change from
sending “Services” in this field as in Legacy.
Section 6.2
46
Added:
Validations:
For partners submitting government orders without the
intention that the order be TAA compliant, but have their
line items on the request specified as TAA compliant, line
item values will be ignored while fulfilling the order.
For partners submitting government orders with the
intention that the order be TAA compliant:
• If at line level none of the lines are specified as TAA
compliant then the order is rejected
• If at line level there is a mixture of TAA compliant
lines and some lines that are non TAA compliant - a
warning will be raised to that effect
• If SKU at line level is specified as non-TAA compliant,
however the SKU can only be fulfilled as TAA
compliant and there is no Exception process to fulfill
this SKU, then the partner can expect such SKUs as
TAA compliant in response.
• If SKU at line level is specified as non-TAA compliant,
however the SKU can be TAA compliant and there is
a Exception process to fulfill this SKU, then the
partner can expect such SKUs as non-TAA compliant
in the response.
Government TAB orders with preferential indicators(TAA-DX,
TAA-DO, Dx, DO) will result in warnings and these values will
be ignored.
Government TAB orders can be requested as TAA compliant.
Section 6.3.2
45
Added: If Cisco is unable to identify the covered product in
relation to the service lines, orders are rejected.
Section 5.4
44
Added: In this case, if partners have not provided line level
addresses, Cisco will make every effort to cascade this header
level ShipTo address to the line level shipTo address.
Added:
Known Limitation
The actual order ship-to date information is not known at the
time of PO Ack response. In light of not delaying the PO Ack
response to wait until full processing is done, Cisco will send
the PO Ack with no shipTo information at header level.
Section 4.9.2
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 21 of 144
Ref
No.
Description of Change
Location in the IG
Release
43
Added: Before placing an order with the Kit Ref function,
partners should create a ConfigSet using the Cisco
Configuration Web Service and name it with a Partner product
number, then:
1. Provide a kitReference Indicator flag on the product line
item with valid value to indicate that a Kit Ref ID/Name is
being used.
2. Provide the valid ConfigSet ID/Name as the Cisco part
number (in the Proprietary Product Identifier field) to be
ordered.
System does the following with these orders:
Retrieves the ConfigSet associated with the kitReference
(s) along with the line item price and line item quantity
Adjusts the retrieved quantity at line level in reference to
the specified kit Quantity
Section 7.3
42
To process orders with Promotion Codes - a Name value pair
of PromotionCode = <<value>> and is used; value is sent in tag
342 on the XML order.
Section 6.7
January
2013
41
Partners will send in ShipTo address free form text rather than
the ShipTo address ID.
Section 4.9.2
January
2013
40
When B2B XML orders have any of the BLOCK SKUs, the order
is rejected. For B2B EDI orders with the “BLOCK”, SKUs is a
new task (“Prevent Booking” task where the order imported to
ERP in “Entered” status) is raised explicitly for the Fulfillment
Restriction for the CPE team. CPE team will work with the Distis
to inform them of the Fulfillment restriction put in place for the
particular SKU: The SKU would need to be removed from the
Order before booking or the Disti can request that the CPE
team cancel the order. Please see
Appendix F for the list of
BLOCK SKUs.
Section 5.3.3
January
2013
39 SWIFT and eDelivery should have the order contact email ID.
Section 7.9 (As of
Version 18, the
Section is 7.8)
January
2013
38
Partners can send orders with multiple KitRefs, one in each line
item on the XML order. Each KitReference can be a KitRefName
or a KitRefID. Also, net KitAmounts associated with the
KitReferences will need to be sent for each of the
KitReferences.
Section 7.3
January
2013
37 Product ID for DotX starts with "S". Section 7.2
January
2013
36
Co-terming is available for Maintenance only, M-lines, that is,
for service or subscription lines where the product has been
previously ordered and shipped. Co-terming is for Service only
ordering.
Section 6.10
January
2013
35
A US government Disti Stocking order is rejected if DPAS value
is sent in as DX, DO, TAA-DX, or TAA-DO.
Section 6.3
January
2013
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 22 of 144
Ref
No.
Description of Change
Location in the IG
Release
34
Removed:
Tag 342 - proprietaryInformation.FreeFormText - IG states:
"ReferralReasonCode name value pair with reasons being -
"Service Sale pending in 30 Days"
"Service Sale pending in 90 days"
"Service Sold by other Partner or Cisco"
"Service Referral"
"Spares or Stocking Order"" (However, no such logic has
been implemented.)
Was Section 7.2 in
Version 15 of the
Implementation
Guide
January
2013
33
Added: If you are a Distributor and are ordering the service for
Resale, provide the Reseller Bill to Id and/or Address and/or
Reseller Contact Email Address
Section 5.7.1
January
2013
32
Removed: In Response, zero price line items are included with
Z prefixed with the major line number
Was Section 6.3.1 in
Version 15 of the
Implementation
Guidelines
January
2013
31
Added to 4. 16: Line ID and Parent Line ID will be used in the
configuration information tag as specified in section 5.5.
Removed from 4.16: "N.M format is the Cisco UI standard of
representing PO list of hardware or software item(s) in a point
decimal format. The relative configuration item appears as a
sub digit. For example: Hardware ‘X’ is bold count 1.0 and its
relative configuration items required will appear as sub counts
1.1, 1.2, 1.3 and so on in a set. However a new hardware or
software item in the PO will not follow the same string. It will
continue as 2.0, 2.1, 2.2 and so on. Only configuration items
will appear as a sub count under each bold count.
As a general convention, Line number for major lines is N.0,
where N is any integer. Line number for minor lines is N.M,
where N and M are integers. Product lines with the same N
value are grouped as one configuration.
There are line numbers in the format N.M.O for bundles that
have 2 tiers of options:
• 1.0 - Bundle Chassis X
• 1.1 - Option Card Y
• 1.1.1 - Memory for Option Card Z
The Line number displayed in the CCW UI may not match the
line numbers on the order.
Section 4.16
January
2013
30
Added: If partners do not provide shipping address at either
the Product Line level or the Purchase Order level, Cisco will
run defaulting rules as specified in the attached document to
make every effort to process the order. In case we are unable
to work throught any of the defaulting rules, Cisco will reject
the order.
Section 4.9.2
and
Appendix C
January
2013
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 23 of 144
Ref
No.
Description of Change
Location in the IG
Release
Added: Product Line file to Appendix C and referenced in the
text.
29
Added: Partner's GlobalLocationIdentifier (tag 29) /Cisco BID/
BillTo ID not on an order but partner has a default BID in its
Cisco Profile. In this case default BID is fetched from partner's
profile and order is processed however the order is rejected.
Section 4.7
January
2013
28
Added to 4.1 (tag 12): GlobalPartnerClassificationCode - Send
a value of "Buyer" for this field. All other values will be
ignored.
Removed: Send a value that describes what the customer’s
business relationship is to Cisco. Potential values include
“Distributor”, “Reseller” and “End User”. Please use the value
from the “Identification” section in the “Trading Partner Profile”
(set up in partner’s B2B Gateway server).
Section 4.1 (5.1.12 in
prior version)
January
2013
27
Removed: Penny to zero dollar reverse calculation logic is
already implemented
Preface (2.3.4 in
prior version)
January
2013
26
Added: TAB orders having CTMP quote number/Promo Code
but no Deal ID will result in an order rejection. Value for CTMP
Quote number is to be derived from the Quote UI and is
specified under TradeIn Quote Number.
Section 6.5
(7.6 in
prior version)
January
2013
Prior Versions of Implementation Guide
25
Penny to Zero Dollar conversion is in place. Because SAP
cannot handle zero priced items, in OCI the unit price for any
items whose price is zero is set to a penny. The old ordering
system then reverse calculates the price for any penny-valued
items to zero.
Septemb
er 2012
24
Enabling the ability to place orders with or without
CiscoProductReference, along with passing a combination of
Config Path, Selection Sequence, and Selection Flag on the
order. If CiscoProductReference is passed on the order, it
takes precedence over and ignores Config Path, selection
sequence, and selection flag values.
Septemb
er 2012
23
Enabling the ordering of Standalone Service, Freight Charges,
and Landing Cost SKUs
Septemb
er 2012
22
PAK delivery preference (PDP) values sent by partners are
validated against transaction level values and warnings are
raised when there is a mismatch. These validations will be
applicable to perpetual licenses for ATO Configurations and
Term and Content license subscription SKU (M:1 Option
selection for standalone lines)
Septemb
er 2012
21
Line level proprietaryInformation.FreeFormText field
“PartnerTAAFlag with possible values “Y/N” should be used to
indicate if the line item being ordered is TAA compliant.
May 2012
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 24 of 144
Ref
No.
Description of Change
Location in the IG
Release
Example:
[ProductLineItem.proprietaryInformation.FreeFormText]Partner
TAAFlag=Y
20
A Bill-To Contact email address must be specified for TAA
orders.
Example:
[PurchaseOrder.
billTo.PartnerRoleDescription.ContactInformation.EmailAddress
](Element #21)
May 2012
19
Service Only orders will no longer be identifiable by an order
type of ‘Maint_Only’. Service Only orders will have an order
type of ‘Standard’.
18
Partners can specify if they would like to receive subscriptions
as Single or Multiple PAK via the LicenseKeyRequested
attribute.
Example:
[ProductLineItem.proprietaryInformation.FreeFormText]License
KeysRequested=Single
17
As of March, 2012 release: Service Only orders must provide
Serial Numbers as a reference to the covered product. The
provision to provide Sales Order No. and Line No. as a covered
product reference will be enabled in a later release.
16
Orders for AS-Fixed SKUs should include install site address,
contact, and contact email information. See Section 6.10 AS-
Fixed Ordering for details.
15
The “PathHashCode” will now be referred to as the
“CiscoProductReference” code.
14
Removed references to SIS98 services.
13
References to the MOVE program have been replaced with
Shipping Routing and Configuration Tool.
12
References to “Integrated Configuration Tool”(ICT), “Multi Line
Configurator” (MLC), and “Dynamic Configuration Tool” have
been replaced with references to the new systems and
services used for like purposes: “Acquire Quote”, “Transfer
Quote”, “Config Web Services”, and “CCW Config UI”.
11
Details surrounding specification of the delivery preference for
SKUs are documented in Section 7.9 Swift and eDelivery
products.
10
UCS products come with OEM software. If the OEM software
was not ordered with the original UCS purchase, partners may
order it separately as a spare. When this spare is ordered,
partners are required to add a $0 minor line indicating
‘Acceptance of the Terms and Conditions’ under the OEM
Major line, to indicate that they are aware of the proper use of
the OEM software. If an OEM product is ordered as part of a
configuration, this $0 minor line would have been added by the
system when creating the configuration and therefore does not
need to be added separately.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 25 of 144
Ref
No.
Description of Change
Location in the IG
Release
9
Try and Buy (TAB) orders with a CTMP number or a Promo
Code but no Deal ID result in a rejection of the order.
8
The default trial period for Try and Buy orders without a Deal ID
will be 90 days. Telepresence products will have a trial period
of 120 days. The trial period for orders with a Deal ID are
obtained from the deal.
7
Contract Duration values must be provided in months.
System defaults the duration to 12 months if not provided on
the order.
Standard Duration values are 12, 24, and 36.
proprietaryInformation.FreeFormText (Element #304)
Example:
[ProductLineItem.proprietaryInformation.FreeFormText]Contrac
tDuration=12
6
When ordering configurations with both products and services,
partners should either include orders for all applicable services
for the product configuration on the same order OR not order
any of the applicable services. See
Section 5.9 All or Nothing
Rule for additional details.
5
A two digit country code should be provided for zero pricing.
Partners may no longer provide a zero price region name.
The two digit code will be provided, as before, via the
[PurchaseOrder.proprietaryInformation.FreeFormText] (Element
#342)
Example:
[ proprietaryInformation.FreeFormText]ZeroPriceCountry=JP
4
Taxability and Intended Use (Order Reason) related changes.
A GlobalPurchaseOrderTypeCode of “Standard” used to
convey both “Internal Use” & “Resale,” but going forward
Standard will only be for “Resale” and “Site” will be used for
“Internal Use”.
Additional details are in Section 4.6, Purchase Order type.
3
Discontinue use of the ServiceFor (Element #304) tag. Partners
should send the Line Id and Parent Line Id via the
ConfigurationInformation tag mentioned in No. 2 above.
Previous use was:
[ProductLineItem.proprietaryInformation.FreeFormText]Service
For=1.0
2
Line Id and Parent Line Id must be provided via the
ConfigurationInformation <name,value> pair within
proprietaryInformation.FreeFormText (Element #304)
Example:
[ProductLineItem.proprietaryInformation.FreeFormText]Configu
rationInformation=3716361399,0;2324567]
1
To send an order to the CCW platform, partners need to send
“OrderPlatform=CCW” in “Tag 342
proprietaryInformation.FreeFormText at the PurchaseOrder
level”. If “OrderPlatform=CCW” is not specified in Tag 342,
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 26 of 144
Ref
No.
Description of Change
Location in the IG
Release
then the order will be processed in the old environment.
[PurchaseOrder.proprietaryInformation.FreeFormText]OrderPlat
form=CCW
Known Limitations
Config Express functionality, a Service Provider feature is not yet available in the new system.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 27 of 144
1 Introduction
Cisco has prepared this document for implementing the Purchase Order message of RosettaNet PIP
3A4 V02.00.00.
RosettaNet is a globally supported standards organization that provides a
common language for e-business transactions and the foundation for
integrating critical processes among partners within the global supply chain.
RosettaNet Partner Interface Process (PIP) is a specialized system to system
XML based dialog that defines business processes between trading partners.
This implementation guide describes the details of various PIP elements and how those elements
should be used in an integration with Cisco.
The RosettaNet PIP 3A4 specifies the purchase order management process between trading
partners. The process includes the creation, change, acceptance, and cancellation of a purchase
order.
1.1 Overview
The interactions between the partner systems and Cisco are done by a request and response XML
interchange mechanism. After Cisco’s systems receive a PIP3A4 Purchase Order Request, the
request is validated as per business rules. If all validations pass, Cisco accepts the purchase order. If
there are any errors, the purchase order is rejected, with appropriate error messaging.
In the general sales process flow, partners submit purchase orders following preparing a
configuration and/or a quote.
Figure 1: High-Level General Sales Process Flow
The solution ensures data security by using digital certificate authentication,
and guarantees document delivery with the RosettaNet standard.
In addition to this document, the reader should also consult the following documents:
PurchaseOrderMessageGuideline of RosettaNet PIP 3A4
PurchaseOrderMessage DTD of RosettaNet PIP 3A4
Note: The above-mentioned documents can be accessed at http://www.rosettanet.org
.
Partner creates and
manages a
configuration.
A Quote may
be created and
approved.
A Purchase
Order Request
is submitted to
Cisco.
Partner’s order
moves to
Fulfillment and
Service phase.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 28 of 144
1.2 Audience
The intended audience for this document is business analysts, IT engineers, and technical architects
who are involved in the integration project. Other stakeholders who wish to understand business
and/or technical aspects of integration may also use the document as a reference.
1.3 Scope
The scope of this implementation guide is limited to the Purchase Order Request and Response
message. This guide is derived from the original specification (PIP 3A4 V02.00.00) as published by
the RosettaNet standards body.
This guide also retains all the elements of the DTD as published in the original document from
RosettaNet.
1.4 Prerequisites
It is assumed that the reader has some familiarity with Cisco’s CCW platform through either
formal or informal training and/or demonstration.
The credentials to access CCW and Cisco’s Submit Purchase Order infrastructure must have
been previously established. Please contact your Partner Solutions representative for assistance
if they are yet to be established.
Any firewall / security settings in the partner system have been configured to allow Cisco’s CCW
platform to post XML messages to the designated partner system.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 29 of 144
2 Purchase Order Request: Process
The processes described in this section are used by partners to submit a Purchase Order Request for
products, services, and software offered by Cisco.
Upon the submission of a Purchase Order Request to Cisco, the order is validated against business
logic, such as configuration validity. If errors are found, the order is rejected. The response message
from Cisco will include error messaging to help the partner address the problem.
Error severity management represents the success or failure to meet a
business rule validation. An order can be rejected, which results in an error.
An order can be accepted, but include a warning of tasks associated with the
order. Lastly, an order can be accepted and have no further action required of
the partner.
For examples of the request and response messages, see the Message Guideline section.
The process of sending and receiving an order in the form of PIP 3A4 is as follows:
1. The partner creates a PIP 3A4 PO Request in their purchasing system.
2. The partner submits the PO Request to Cisco via their XML gateway.
3. The Cisco XML gateway receives and acknowledges the PO Request.
4. The partner receives the PO Request via their XML gateway.
5. Cisco validates and processes the PO Request.
6. Cisco sends a PIP 3A4 PO Confirmation to the partner via Cisco XML gateway.
7. The partner receives the PO Confirmation via their XML gateway.
8. The partner processes the PO Confirmation.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 30 of 144
A graphical depiction of the purchase order request process follows.
Purchasing System
• Submit Purchase Order
Request (PIP 3A4)
• Receive Purchase
Order Confirmation (PIP
3A4)
XML Gateway
XML Gateway
RosettaNet PIP 3A4
XML
Confirmation
Order Orchestration
Solution
Purchase Order for
• Cisco configurable products
• Cisco non-configurable
products
• Included sub-products
• Service for any Cisco
serviceable products
Trading Partners Internet Cisco Systems
Request
Figure 2: Service for Purchase Order Request Process
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 31 of 144
3 Message Guideline (PIP 3A4 V02.00.00)
The request and response messages that partners send to and receive from Cisco include all of the
data elements and structure to facilitate the PO Submit process. This section describes in detail, the
correct way to structure a 3A4 PO Request document to ensure the order is processed correctly by
Cisco.
3.1 Guideline Annotations
The following guideline annotations apply when creating a request or interpreting a response:
Cardinality values indicate if a message element is required or optional, and specify its valid
instance count.
Color coding advises a partner if the code is used.
Table 2: Cardinality Values and Color Codes
Cardinality Value
Semantics
1 Mandatory, only one instance
1..n Mandatory, one or more instances
0..1 Optional, only one instance
0..n Optional, zero or more instances
Color Code Significance
Grey Shaded Not used
3.2 Service Header Part Message Guideline
This section refers to the RosettaNet Implementation Framework (RNIF) Core Specification that is the
packaging, routing, and transport of all PIP messages and business signals.
The Service Header provides the process context for automated message
processing.
The Service Header provides the process context for the message for automated computer
processing. Information in this header for Request Purchase Order includes:
Action Identity - used to reference a prior message tracking ID when the current message is a
response or reply process
From Role - the Global Partner Classification Code listed in the PIP
To Role
PIP Code – the PIP number
Version ID - the specific PIP version number
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 32 of 144
PIP Instance Identifier - the unique identifier for this individual PIP message
Indicator if the message includes an attachment
The table
that follows contains service header mapping for the PIP 3A4 based on RNIF V02.00.00,
which is included in all 3A4 PO Confirmation messages sent to partners.
3.2.1 Service Header Guideline for RNIF 1.1, RNIF 2.0
The service header provides the overhead data that is required to deliver the packet to its
destination.
The cardinality assigned to each Service Header Request indicates if the header request type is
mandatory or optional. For example, in a single envelope request, the header must include one
BusinessActivityIdentifier. This fact is evidenced by a cardinality value of 1. That same header can
optionally include one
domain.FreeFormText. This fact is evidenced by a cardinality value of 0..1.
Rows that are shaded grey denote elements not used by Cisco.
A partner includes elements from the table as part of their request to improve
the quality of the message exchange service between the partner and Cisco.
Table 3: Service Header Guideline for RNIF V02.00.00
No. Cardinality Header Element Mapping Notes Sample Values
Cisco
Default?
1
ServiceHeader
2
1
|-- ProcessControl
3 1 | |-- ActivityControl
4 1
| | |--
BusinessActivityIdentifier
Identifies
business action.
In this case,
business name of
PIP 3A4.
Y
5
1
| | |-- MessageControl
6 1
| | | |--
fromRole.GlobalPartnerRol
eClassificationCode
Role of Cisco
with respect to
3A4 transmission
Y
7 1
| | | |--
fromService.GlobalBusines
sServiceCode
Service code for
Cisco; specific to
3A4 messages
Y
8 0..1
| | | |--
inReplyTo.ActionControl
Not used
9 1 | | | | |-- ActionIdentity Not used
10 1
| | | | | |--
GlobalBusinessActionCode
Not used
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 33 of 144
No. Cardinality Header Element Mapping Notes Sample Values
Cisco
Default?
11 0..1
| | | | | |--
messageStandard.FreeFor
mText
Not used
12 0..1
| | | | | |--
standardVersion.VersionIde
ntifier
Not used
13 1
| | | | |--
messageTrackingID.Instanc
eIdentifier
Not used
14 1 | | | |-- Manifest
15
0..n
| | | | |-- Attachment
Not used
16 0..1
| | | | | |--
description.FreeFormText
Not used
17 1
| | | | | |--
GlobalMimeTypeQualifierC
ode
Not used
18 1
| | | | | |--
UniversalResourceIdentifier
Not used
19 1
| | | | |--
numberOfAttachments.Cou
ntableAmount
Number of
attachments in
message
1 0
20 1
| | | | |--
ServiceContentControl
21
1
| | | | | |-- Choice
22
| | | | | | |-- ActionIdentity
23 1
| | | | | | | |--
GlobalBusinessActionCode
Identifies
business action.
In this case,
business name of
PIP 3A4.
Y
24 0..1
| | | | | | | |--
messageStandard.FreeFor
mText
Not used
25 0..1
| | | | | | | |--
standardVersion.VersionIde
ntifier
Not used
26
1
| | | | | | |-- SignalIdentity
Not used
27 1
| | | | | | | |--
GlobalBusinessSignalCode
Not used
28 1
| | | | | | | |--
VersionIdentifier
Not used
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 34 of 144
No. Cardinality Header Element Mapping Notes Sample Values
Cisco
Default?
29 1
| | | |--
toRole.GlobalPartnerRoleCl
assificationCode
Gobally
recognized role
of message
receiving partner
Y
30 1
| | | |--
toService.GlobalBusinessS
erviceCode
Globally
recognized
service code of
message receiver
Y
31 1 | |-- GlobalUsageCode
Indicates if
message is for
test or production
Production
32 0..1
| |--
partnerDefinedPIPPayloadB
indingId.ProprietaryReferen
ceIdentifier
Not used
33 1
| |--
pipCode.GlobalProcessIndi
catorCode
Globally
recognized
RosettaNet PIP
number; specific
to this solution
3A4 Y
34 1
| |--
pipInstanceId.InstanceIdent
ifier
Unique identifier
used by Cisco to
track payload in
its end-to-end
generation
process. Unique
for each
message sent or
resent.
60a80a1-
121c4bb319c-
121c4bb33d773ca
bc
35 1
| |--
pipVersion.VersionIdentifier
Version of 3A4
standard
published by
RosettaNet
V02.00.00 Y
36 0..1
| |--
QualityOfServiceSpecificati
on
Not used
37 1..n
| | |--
QualityOfServiceElement
Not used
38 1
| | | |--
QualityOfServiceClassificati
onCode
Not used
39
1
| | | |-- Value
Not used
40
1
| |-- Choice
41
| | |--
KnownInitiatingPartner
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 35 of 144
No. Cardinality Header Element Mapping Notes Sample Values
Cisco
Default?
42 1
| | | |--
PartnerIdentification
43 0..1
| | | | |--
domain.FreeFormText
44 1
| | | | |--
GlobalBusinessIdentifier
Cisco DUNS
number.
A new Cisco
DUNS number
will be provided
to Pilot partners.
Order placed
using new DUNS
number will
automatically
route to new
application.
364132837 Y
45
0..1
| | | | |-- locationID.Value
Not used
46
| | |--
UnknownInitiatingPartner
Not used
47 1
| | | |--
PartnerIdentification
Not used
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 36 of 144
4 Functionality
This section explains Cisco’s PIP 3A4 specifications for Purchase Orders.
For validation and check failures that result in rejection of the PO request, refer to
Appendix A: Error
Messages.
4.1 Participant Information
All of the PIP elements in the table that follows are mandatory. This fact is evidenced by cardinality
values of 1. Please see the Cardinality Values and Color Codes table in Section 3.1
.
The partner should provide the participating partner information in the FromRole and ToRole
blocks in a PIP 3A4 Request when placing a Purchase Order to Cisco.
The partner should provide company (buyer) information in the FromRole field, and provide Cisco
(Seller) information in the ToRole field. Both are mandatory data in a PIP 3A4 message.
Table 4: Participant Information for PIP 3A4 V02.00.00
PIP 3A4 V02.00.00
No.
Cardinality
PIP Element
Notes
Field Length
0
1
Pip3A4PurchaseOrderRequest
Required tag
N/A
1 1
FromRole.PartnerRoleDescripti
on
Required tag N/A
2
1
|--ContactInformation
Required tag
N/A
3 1
| |--
contactName.FreeFormText
Name of person responsible for technical
support of B2B system for buyer.
Example:
Jerry Jones
CHAR(120)
4 1 | |--EmailAddress
Email address of person responsible for
technical support of B2B system for buyer.
Example: jerjones@company.com
CHAR(240)
6 1
| |--
telephoneNumber.Communicat
ionsNumber
Phone number of person responsible for
technical support of B2B system for buyer.
Example: + 1 408 853 5157
CHAR(30)
7 1
|--
GlobalPartnerRoleClassification
Code
Send the value “Buyer” N/A
8 1 |--PartnerDescription Required tag N/A
9
1
| |--BusinessDescription
Required tag
N/A
10 1 | | |--GlobalBusinessIdentifier
DUNS number of buyer
Example:
nnnnnnnnn
INTEGER(9)
11
1
| | |--GlobalSupplyChainCode
Send the value “Information Technology”
N/A
12 1
| |--
GlobalPartnerClassificationCod
e
Send the value "Buyer". All other values
ignored.
N/A
400
1
toRole.PartnerRoleDescription
Required tag
N/A
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 37 of 144
PIP 3A4 V02.00.00
No.
Cardinality
PIP Element
Notes
Field Length
406 1
|--
GlobalPartnerRoleClassification
Code
Send the value “Seller” N/A
407
1
|--PartnerDescription
Required tag
N/A
408
1
| |--Business Description
Required tag
N/A
409
1
| | |--GlobalBusinessIdentifier
Send Cisco’s DUNS number : “364132837”
CHAR(9)
410
1
| | |--GlobalSupplyChainCode
Send the value “Information Technology”
N/A
411 1
| |--
GlobalPartnerClassificationCod
e
Send the value “Manufacturer” N/A
4.2 Document Function Code
This is a mandatory data element in PIP 3A4, as evidenced by a cardinality value of 1. The partner
will insert the appropriate function code to indicate the purpose of sending a PIP 3A4 to the recipient.
Set GlobalDocumentFunctionCode to “Request” when this PIP 3A4 is to place a Purchase Order
to recipient.
Set GlobalDocumentFunctionCode to “Response” when this PIP 3A4 is to respond to a Purchase
Order request.
Table 5: Document Function Code for PIP 3A4
PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes Field Length
13 1
GlobalDocumentFunction
Code
Send the value “Request” N/A
4.3 Order Routing
To send an order to CCW, partners need to send “OrderPlatform=CCW” in “Tag 342
proprietaryInformation.FreeFormText at the PO level”.
If “OrderPlatform=CCW” is not specified in Tag 342, then the order will be processed in the old
system.
Order routing is optional and only one instance of order routing can be specified per configuration.
This fact is evidenced by a cardinality value of 0..1 in the table that follows.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 38 of 144
Table 6: Order Routing
No.
Cardinality
PIP Element Notes Field Length
342 0..1
|--
proprietaryInformation.FreeForm
Text
Used to send multiple Cisco proprietary
information in <name>=<value> format.
Please use ‘|’ as a delimiter for multiple
values, and there should be no
whitespace around the equal sign.
Name: OrderPlatform
Example: “OrderPlatform=CCW”
4.4 Purchase Order Number
The Purchase Order Number and its generation date timestamp are mandatory data elements for a
PIP 3A4 message. This fact is evidenced by the cardinality value of 1 that is specified for both
elements in the table that follows. In general, a Purchase Order Number must be unique for a billing
address. Duplicate Purchase Orders are allowed for blanket POs.
Cisco will return warning messages when it receives a duplicate Purchase Order Number. The
partner can have Cisco reject a Purchase Order with a number that was previously submitted to
Cisco. (See Section 4.5, Duplicate PO Number Check
).
Table 7: Mandatory Information for PIP 3A4 V02.00.00
No.
Cardi
nality
PIP Element Notes
Field
Length
398 1
ThisDocumentGenerationDateTime.Date
TimeStamp
Send in Zulu time format – date when
document was generated.
Example: “20040118T040520.792Z”
Zulu time
format
399 1
thisDocumentIdentifier.ProprietaryDocu
mentIdentifier
Enter Purchase Order Number.
Example: 12345757
CHAR(50)
4.5 Duplicate PO Number Check
With 3A4 XML orders, partners can have Cisco reject a PO if the PO number exists in Cisco’s
systems. Partners turn on the function by setting RejectDuplicatePO=Y, the value is ‘N’ by default.
There is no space around the equal sign. The Duplicate PO Number Check field is optional, as
evidenced by a cardinality value of 0..1 in the table that follows.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 39 of 144
Table 8: Duplicate PO Number Check
PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes Field Length
342
0..1
|--
proprietaryInformation.FreeFo
rmText
Used to send multiple Cisco
proprietary information in
<name>=<value> format. Use ‘|’
as a delimiter for multiple values,
and there should be no
whitespace around equal sign.
Name: RejectDuplicatePO
Value: Y or N
Example: RejectDuplicatePO=Y
4.6 Purchase Order Type
GlobalPurchaseOrderTypeCode is a mandatory element in PIP 3A4 (evidenced by a cardinality value
of 1..n). This element determines the Purchase Order Type.
The following rules govern the Order Type determination. The Order Type will be:
PROMOTIONAL - if there is a Promo Code on the order
TRADE IN - if there is a trade-in PromotionCode
GOVERNMENT - if either there is a DPAS code or VerticalMarket=Federal Government PIP
Element#304 for VerticalMarket attribute: proprietaryInformation.FreeFormTextStandard when
none of the above attributes are in the order
TRY AND BUY - if Cisco Program Value is TAB
MAINT_ONLY – if only service lines on the order
STANDARD
SAMPLE
Any of the order types can contain a Deal ID.
Cisco also maps the values into Cisco Order Reason (Intended Use). The following tables detail the
values set for Cisco Order Reason based on the values for the attributes on the 3A4 XML order.
Note: “Standard” is used to convey both “Internal Use” and “Resale,” but as of September 11,
2011, Standard is only for “Resale” and “Site” is for “Internal Use”.
Table 9: Values Set for Cisco Order Reason – 3A4 XML
Global PO Type Code
(Element #92)
End Customer
(Element #145)
Donations
(Element
#304)
Order Reason (Intended Use) – Derived by
Cisco on Basis on Values Provided in
GlobalPOTypeCode and End Customer
Evaluation Not Considered
Not
Considered
Lab
Sample Not Considered
Not
Considered
Lab
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 40 of 144
Global PO Type Code
(Element #92)
End Customer
(Element #145)
Donations
(Element
#304)
Order Reason (Intended Use) – Derived by
Cisco on Basis on Values Provided in
GlobalPOTypeCode and End Customer
Service Not Considered
Not
Considered
Service Provision Use
Replenishment Not Considered
Not
Considered
Stocking
Site Not Considered
Not
Considered
Internal Business Use
Consigned Order Not Considered
Not
Considered
Managed Services
Consigned order Not Considered
Not
Considered
Managed Services
Standard Not Provided
Not Provided
Stocking
Standard STOCK
Not Provided
Stocking
Standard
Any value other
than STOCK
Y
Resale
Table 10: PIP 3A4 V02.00.00 – Purchase Order Type
PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes Field Length
92 1..n |-- GlobalPurchaseOrderTypeCode
Valid Cisco
values:
Standard
Evaluation
Sample
Service
Site
Replenishm
ent
Consigned
Order
Consigned
order
392
0..1
| |-- TaxExemption
Tag
393 1 | | |-- GlobalTaxExemptionCode
Indicates if order
is for Resale.
Valid Cisco
values:
“Exempt –
for resale”
“Exempt –
not for
resale”
394 1
| | |--
taxExemptionCertificationIdentifier.Proprie
taryReferenceIdentifier
Send value “N/A”
as field is not
used by Cisco.
CHAR(255)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 41 of 144
4.7 Purchase Order Billing Information
Billing address, company name, and contact information are required on the 3A4 XML order.
The billing address submitted must be set up at Cisco and associated with the partner’s
GlobalLocationIdentifier. Cisco uses the value in GlobalLocationIdentifier to match the billing address
on the PO to one of the billing addresses at Cisco. Only orders with matching billing addresses are
accepted. If a billing address cannot be matched, Cisco rejects the order. The partner must correct
the error before resending the order.
Note: When a partner suggests a new billing address, the partner should call the respective Cisco
Customer Service Relationship Manager to setup the new billing address with the partner’s
GlobalLocationIdentifier.
Table 11: PIP 3A4 V02.00.00 – Purchase Order Billing Information
PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes
Field
Length
15
0..1
|--AccountDescription
Required tag
N/A
16 1
| |--
accountName.FreeFormText
Send Bill-To Company Name.
Example
:
“Routers Inc.”
18 0..1
| |--
billTo.PartnerRoleDescription
Required tag
19
1
| | | - ContactInformation
Required tag
20 0..1 | | | - contactName
contactName.freeFormText – send in Bill To
Contact Name Acceptable formats -
<firstname> <lastname> OR
<firstname>,<lastname>. For example – “John
Galt” OR “John, Galt”
21
0..1
| | | - EmailAddress
The billTo contact email address
22 0..1`
| | | -
facsimilieNumber.Communicati
onsNumber
facsimilieNumber.
CommunicationsNumber is an optional tag and
is not used by system.
Therefore, values sent here will be ignored.
Char (30)
23
0..1
| | | |--PhysicalAddress
Required tag
N/A
24 0..1
| | | | |--
addressLine1.FreeFormText
Street address of billing company. Not used
for order notes.
Example: “170 WEST TASMAN DRIVE”
CHAR(240)
27 0..1
| | | | |--
cityName.FreeFormText
City of street address of billing company.
Example: “San Jose”
CHAR(60)
28 0..1 | | | | |--GlobalCountryCode
ISO country code of street address of billing
company.
Example: “US”
CHAR(2)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 42 of 144
PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes
Field
Length
29 0..1
| | | | |--
GlobalLocationIdentifier
Partner’s GlobalLocationIdentifier:
Used to send Cisco BID ( Bill-To Identifier).
Cisco assigns a unique BID to each ordering
entity and is required in PIP 3A4 PO Request.
If no bid, Cisco performs does order
configuration validations with the default active
BID corresponding to the submitter cco profile,
if one is available, but order is rejected.
If numeric BID value is provided Cisco would
perform BID validation and user entitlement
checks and if they fail, Cisco would reject the
order.
Cisco bid is always numeric and any non-
numeric values coming in on bid on the
request
will result in the order being rejected upfront
without any configuration validations being
performed.
Partner may use their own BID that is mapped
to a BID Cisco assigns this would necessitate a
corresponding mapping in system. Please
check with Cisco rep for this mapping.
In case of Brazil orders, the derivation is
based on Partner BID + OperatingUnit
value that is sent on the PO by partners.
Example: 12357135
CHAR(20)
30 0..1 | | | | |--NationalPostalCode
Required only for US and Canada addresses.
If partner plans on using 10 digit code for
American addresses, omit hyphen “-“
character. Hyphen “-“ character is not
allowed. If valid BID provided, value is ignored.
CHAR(9)
32 0..1
| | | | |--
regionName.FreeFormText
Required only for US and Canada addresses.
Enter state or province of billing address.
Example: “NC” for North Carolina
CHAR(60)
33 0..1
| | | -
telephoneNumber.Communicat
ionsNumber
The billTo Contact communications telephone
number. Currently not used by system.
Therefore, values sent here will be ignored.
Char (30)
34 1
| | |--
GlobalPartnerRoleClassification
Code
Send the value “Buyer”. N/A
35
1
| | |--PartnerDescription
Required tag
N/A
36
1
| | | |--BusinessDescription
Required tag
N/A
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 43 of 144
PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes
Field
Length
37 0..1
| | | | |--
BusinessName.FreeFormText
Send the Bill-To Company Name.
Example: “Routers Inc.”
CHAR(50)
4.8 Financing Terms
The Payment Terms are agreed by the partner and Cisco and are set and stored with the Finance
Terms in the General Agreement. Providing this information is optional, as evidenced by a cardinality
value of 0..n in the table that follows.
Partners need to provide a value in the PIP due to cardinality rules. This fact is evidenced by a
cardinality value of 0..1, also in the table. Please send the value as “Mutually Defined/Determined
by TPA”.
Table 12: Financing Terms
No. Cardinality PIP Element Notes
Field
Length
78
0..n
|--FinancingTerms
Required tag
N/A
79 0..1
| |--
GlobalFinanceTermsCode
Send the value “Mutually Defined/Determined
by TPA”.
N/A
4.9 Order Shipping Information
4.9.1 Request Ship Date
Partners may request a ship date for the PO. If a requested ship date is not provided or has expired,
Cisco defaults the requested ship date to the current date + 1.
Cisco booking policy requires that all orders have a requested ship date within 90 days of the date of
submission. Orders with any lines having a requested ship date outside of 90 days of the submission
date are rejected.
Note: Though a requested ship date is not applicable to service orders, partners have to provide any
date value for the Product Line Item. Requested ship date is mandatory data according to PIP 3A4’s
requirements.
4.9.2 Shipping Address
A valid shipping address is required on the 3A4 XML Purchase Order. This fact is evidenced by
cardinality values of 1 in the table that follows. If partners do not provide a shipping address at either
the Product Line level or the Purchase Order level, Cisco will reject the Purchase Order.
A valid shipping address must contain at least address line 1, the city, and the country code. Postal
code (ZIP code) and state/province are required for American, Canadian, and European addresses.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 44 of 144
If all ordered lines are to ship to one address, they can provide the shipping address at the
PurchaseOrder level. In this case, if partners have not provided line level addresses, Cisco will make
every effort to cascade this header level ShipTo address to the line level shipTo address. Partners
will send in ShipTo address freeform text rather than the ShipTo address ID. We recommend that
partners not include a Ship To address ID, as this may result in delays in the order process.
If the partner submits data at the ProductLineItem level, Cisco will ship this line to the given address.
The line level addresses will override any order level addresses provided on the same 3A4 PO
request.
Cisco validates provided ship to and end user addresses against country postal guidelines for
completeness and validity. Addresses that do not conform to the below guidelines may cause the
submitted order to require manual review by Cisco’s order processing team. This can delay
subsequent order cycles.
Please ensure that you consider the following guidelines when developing your ship to and end user
address mapping:
Insert street address in line 1, unless additional department name or building information is
required for delivery.
If additional company department or building information needs to be included, please use
address line 1 (and 2 if necessary). Street address should be placed in the next address line.
Insert contact names and contact details in the relevant contact elements, not in the address line
fields.
Any additional delivery instructions should be inserted in the packing slip or carton notes fields.
More information on this can be found in Section 4.12, Shipping and Packaging Notes
.
PO Box references should not be used in ship to addresses.
RegionName (state/province) is mandatory for Japan, US, or Canadian addresses.
Known limitation
The actual order ship-to date information is not known at the time of the PO Ack response. To
avoid delaying the PO Ack response until full processing is done, Cisco will send the PO Ack with
no shipTo information at the header level.
The tables that follow provide required, optional, and non-required data for the Shipping Address.
Request Ship Date information is also captured.
Table 13: Required, Optional, and Non Required Data for Shipping Address
1
Country
ISO
Code
Ship to
Compan
y Name
Address
Line 1
Address
Line 2
Address
Line 3
City
State/
Province/
Region
Country
Postal
Code
Australia
AU
Street address is mandatory.
See above guidelines for
placement
O
Brazil
BR
O
Canada
CA
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 45 of 144
China
CN
O
France
FR
O
Germany DE
O
Italy
IT
O
Japan JP
UK
GB
O
USA
US
Other
Countries
-
O
() is a required data for a valid address; it is commonly used in that country.
(O) is a optional data for a valid address; it is not part of common address format for that country.
(N/A) data is not required for a valid address; it is not used in that country.
Refer to appendix C for complete list of such rules.
Note: customer name, country and address line 1 are mandatory
If partners do not provide shipping address at either the Product Line level or the Purchase Order
level, Cisco will run defaulting rules as specified in Appendix C: Address Processing
to make every
effort to process the order. If Cisco is unable to work through any of the defaulting rules, Cisco will
reject the order.
Canadian Tax Code is derived from the Ship To address by Tax Services and applied accordingly (if
the ship to address is in Canada) later in the process. This default applies regardless of whether the
partner has provided the code in the order XML.
Table 14: PIP 3A4 V02.00.00 - Line Level Requested Ship Date and Address
No.
Cardinality
PIP Element
Notes
Field Length
305 1
| |--
requestedEvent.TransportationEv
ent
Required tag N/A
306 1 | | |--DateStamp
The date a transportation event is
requested to occur.
Date in Zulu time format.
Example: “20031010T080034.345Z”
Invalid value: 00000000Z. If provided, the
system will default to Submit Date +1
Zulu time
format
307 1
| | |--
GlobalTransportEventCode
Send the values “Ship” “Dock” or “Pick-
up”
Ship: The event representing when the
product is requested to ship.
Dock: The event representing when the
product should arrive on the recipient's
dock.
Pickup: The event representing when the
product is scheduled to be picked up from
the shipper's dock.
N/A
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 46 of 144
No.
Cardinality
PIP Element
Notes
Field Length
If the sent values are not what is set-up by
Cisco
for the Customer. Cisco will override
the same with the value derived
314
0..1
| |--shipTo.PartnerDescription
Required tag
N/A
315
1
| | |--BusinessDescription
Required tag
N/A
316 0..1
| | | |--
businessName.FreeFormText
Ship-To customer name for this line.
Example: Global Router Systems, Inc.
CHAR(50)
323 1
| | |--
GlobalPartnerClassificationCode
Enter one of following:
“End User”
“Distributor”
“Reseller”
N/A
324 0..1 | | |--PhysicalAddress Required tag N/A
325 0..1
| | | |--
addressLine1.FreeFormText
Street address of Ship-To company.
In order to prevent CPE tasks, systems
expects the Name, addressLine1 and
Country for address creation or validation.
Field should not be used for order notes.
If additional department or building info
is required, place here. Move street
address to next addressline.
Example: “170 WEST TASMAN DRIVE”
CHAR(240)
326 0..1
| | | |--
addressLine2.FreeFormText
Street address of Ship-To company. If
additional department or building info is
required place here. Move street address
to the next addressline.
CHAR(240)
327 0..1
| | | |--
addressLine3.FreeFormText
Street address of Ship-To company (if not
already supplied in addressline 1 or 2.
CHAR(240)
328 0..1 | | | |--cityName.FreeFormText
City of street address of Ship-To
company.
Example: “San Jose”
CHAR(60)
329 0..1 | | | |--GlobalCountryCode
ISO country code of street address of the
ship-to company. UPPERCASE only.
Example: “US”
Depending on country, system may expect
other mandatory address elements like
City and/or State
CHAR(2)
330 0..1
| | | | --
GlobalLocationIdentifier
If partners provide a valid location
identifier, system uses this instead of the
address on the PO. However a known
system limitation is that an invalid ID on
this tag results in an order rejection
Char (13)
331 0..1 | | | |--NationalPostalCode
If partner plans to use 10 digit code for
American addresses, omit the hyphen “-“
character. Hyphen “-“ character not
allowed.
CHAR(9)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 47 of 144
No.
Cardinality
PIP Element
Notes
Field Length
332 0..1
| | | |--
postOfficeBoxIdentifier.FreeForm
Text
CHAR (9)
333 0..1
| | | |--
regionName.FreeFormText
Mandatory for Japan, US, and Canada
addresses. Enter state or province of
billing address.
Example: “CA” for California
CHAR(60)
Table 15: Purchase Order Level Requested Ship Date and Address in PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes Field Length
343 0..1
|--
requestedEvent.TransportationEve
nt
Required tag N/A
344 1 | |-- DateStamp
The date a transportation event is
requested to occur.
Date in Zulu time format.
Example: “20031010T080034.345Z”
Invalid value: 00000000Z. If provided, the
system will default to Submit Date +1
Zulu Time
Format
345 1 | |-- GlobalTransportEventCode
Send the values “Ship” “Dock” or “Pick-
up”
Ship: The event representing when the
product is requested to ship.
Dock: The event representing when the
product should arrive on the recipient's
dock.
Pickup: The event representing when the
product is scheduled to be picked up from
the shipper's dock.
If the sent values are not what is set-up by
Cisco for the Customer. Cisco will override
the same with the value derived
RosettaNet
Value.
370
0..1
|-- shipTo.PartnerDescription
Required tag
N/A
371 1 | |-- BusinessDescription Required tag N/A
372 0..1
| | |--
businessName.FreeFormText
Enter Ship-To customer name for this
product.
Example: Global Router Systems, Inc.
CHAR(50)
373
0..1
| | |-- GlobalBusinessIdentifier
Not Used by Cisco.
Char (13)
374 0..1 | |-- ContactInformation
Shipping contact. Optional information,
however it helps in processing partner’s
order if partner enters this data.
For Cisco to persist information - system
needs contact First Name, Contact Last
name and an email ID/Phone - only when
N/A
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 48 of 144
No. Cardinality PIP Element Notes Field Length
thess are provided will system be able to
persist shipping contact information
375 0..1 | | |-- contactName.FreeFormText
First and last name separated by a space.
Note: Only one name can be sent.
.
Example: “Tom Knupp”
CHAR(50)
376
0..1
| | |-- EmailAddress
CHAR(240)
377 0..1
| | |--
facsimileNumber.Communications
Number
CHAR(30)
378 0..1
| | |--
telephoneNumber.Communication
sNumber
CHAR(30)
379 1
| |--
GlobalPartnerClassificationCode
End User, Distributor, or any valid value.
Cisco does not use this field.
380
0..1
| |-- PhysicalAddress
Required tag
N/A
381 0..1
| | |--
addressLine1.FreeFormText
Street address of Ship-To company. Do
not use this field for order notes. If
additional department or building
information is required, please place
them in this field
. Move street address to
next addressline.
Example: “170 WEST TASMAN DRIVE”
CHAR(240)
382 0..1
| | |--
addressLine2.FreeFormText
Street address of Ship-To company. Do
not use this field for order notes. If
additional department or building
information is required, place them in
this field. Move street address to next
address line.
383 0..1
| | |--
addressLine3.FreeFormText
Street address of Ship-To company (if not
already supplied in addressline 1 or 2.
384 0..1 | | |-- cityName.FreeFormText
City of street address of ship-to company.
Example: “San Jose”
CHAR(60)
385 0..1 | | |-- GlobalCountryCode
ISO country code of street address of
ship-to company. UPPERCASE only.
Example: “US”
CHAR(2)
386 0..1 | | |-- GlobalLocationIdentifier
If partners provide a valid location
identifier, system uses this instead of the
address on the PO. However a known
system limitation is that an invalid ID on
this tag results in an order rejection
NUMBER
387 0..1 | | |-- NationalPostalCode
If partner plans on using 10 digit code for
American addresses, omit hyphen “-“.
Hyphen “-“character is not allowed.
CHAR(9)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 49 of 144
No. Cardinality PIP Element Notes Field Length
388 0..1
| | |--
postOfficeBoxIdentifier.FreeFormT
ext
CHAR (9)
389 0..1 | | |-- regionName.FreeFormText
Mandatory for Japan, US, and Canadian
addresses. State or province of billing
address.
Example: “CA” for California
CHAR(60)
4.10 Shipment Logistics
Cisco provides customers with the ability to specify shipment logistics information.
Cisco can specify their default routing preferences as part of the CCW workspace profile.
If shipment logistics are not provided in the order or CCW workspace profile, Cisco will ship the
order with “Cisco Routed” and “Standard” shipping service.
Shipping is not applicable to service products, so shipping logistic information is not required for
services.
Partners can specify either individual shipment terms values in 3A4 or specify values related to the
Cisco Shipment Routing Configuration Tool.
4.10.1 Shipment Terms Values in 3A4
If the partner submits the data at the ProductLineItem level, Cisco will set the values for this line only.
Line level data takes precedence over the header (Purchase Order) level data. The cardinality values
in the tables that follow indicate if the elements are required or optional. Delivery options - are order
attributes that provide more detailed shipping info to Logistics/MFG regarding how the
partner/customer wants their order to be handled. The following delivery options can be sent (as
name value pairs)
a. Authorized Receiving Party
b. Contact prior to delivery
c. Carrier will call
d. Specific delivery time
e. Inside delivery required
f. Preshipment Inspection Required
g. Remove packaging
h. Special transport required
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 50 of 144
Table 16: Purchase Order Level in PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes Field
Length
115
0..1
|-- OrderShippingInformation
Tag
116
0..1
||-- CarrierInformation
Tag
117 0..1
|||--
accountIdentifier.ProprietaryRefere
nceIdentifier
Freight Carrier account code. Required if
partners specify “Collect” or “Third party
pay” shipment terms below.
118 1 |||-- GlobalCarrierCode
Cisco’s carrier codes (contact your Cisco
B2B project manager or technical lead for
correct codes.)
119 0..1 ||-- GlobalFreeOnBoardCode
Point of responsibility for freight, for
example, “Origin” or “Destination”.
Note: Field not used at Cisco.
120 0..1 ||-- GlobalShipmentTermsCode
Cisco supports shipment terms that follow.
All other values ignored and defaults used.
Prepaid, but charged to customer
Prepaid (by seller)
Collect
Third party pay
Note: Field not used at Cisco.
121 0..1
||--
GlobalShippingServiceLevelCode
Required when using SCAC codes in
GlobalCarrierCode field (element 118).
Cisco maps combination of carrier code and
service level to a Cisco carrier code.
Note: Field not used at Cisco.
122 0..n
||--
GlobalSpecialFulfillmentRequestCo
de
Cisco supports RosettaNet fulfillment request
codes that follow. All other values are
ignored. Codes are case sensitive. The
codes and ship options are as follows:
GlobalSpecialFulfillment
RequestCode
Ship Options
Ship
Early
Ship
Partial
Ship as soon as possible
Yes
-
Ship partial - balance
back order
-
Yes
Ship Per Release No -
Ship Complete
-
No
Ship per schedule
No
No
If “Ship as soon as possible” is requested,
Cisco may ship before requested ship date.
Quantity for line remains same.
If “Ship partial – balance back order” is
requested, Cisco may ship a partial order.
Results in multiple ship sets.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 51 of 144
No. Cardinality PIP Element Notes Field
Length
If “Ship per schedule” is requested, Cisco
ships according to quantity and scheduled
ship date indicated on order line.
To set both Ship Early and Ship Partial to
‘Yes’, send both ‘Ship as soon as possible’
and ‘Ship partial - balance back order’.
For entering multiple values for above
combination, partners should send
GlobalSpecialFulfillmentRequestCode in
individual nodes in a 3A4 as shown in
example that follows:
<GlobalSpecialFulfillmentRequestCode>
Ship Partial - Balance Back
Order</GlobalSpecialFulfillmentReques
tCode>
<GlobalSpecialFulfillmentRequestCode>
Ship As Soon As
Possible</GlobalSpecialFulfillmentReq
uestCode>
Cisco can support special fulfillment requests
only at the order level. Any value supplied at
line level is ignored.
123 0..1
||--
packListRequirements.FreeFormTe
xt
Shipping and Packaging notes; notes display
on all packing slips and invoices
124
0..1
||-- SpecialHandlingInstruction
Tag
126 0..1
|||--
specialHandlingText.FreeFormText
A pipe delimeted string which can include
Carton notes, if value in element 125 is
“Attachment - Customer's Document”
Note: Actual Carton label can only
accommodate 80 characters including
spaces.
Delimited with pipes and
AuthorizedReceivingParty (Valid Values -
Yes
or No)
AuthorizedPartyInstructions (valid Values -
Text string of Upto 300 chars)
Certificate of Origin - (Valid Values - Yes or
No)
ContactPriorToDelivery - (Valid Values - Yes
or No)
ContactInstrctions - (Valid Values - Text
string of upto 300 chars)
CarrierWillCall - (Valid Values - Yes or No)
SpecificDeliveryTime - (Valid Values -
Yes or
No)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 52 of 144
No. Cardinality PIP Element Notes Field
Length
SpecificDeliveryTimeInstructions - (Valid
Value - text String upto 300 chars)
InsideDeliveryRequired - (Valid Values - Yes
or No)
InsideDeliveryInstructions - (Valid Values -
Text string of upto 300 chars)
Pre-shipmentInspectionRequired - (Valid
Values - Yes or No)
RemovePackaging - (Valid Values - Yes or
No)
SpecialTransportRequired - (Valid Values -
Yes or No)
SpecialTransportInstructions - (Valid Values
- Text string of upto 300 chars)
Table 17: ProductLineItem in PIP 3A4 V02.00.00
No. Cardinality
PIP Element Notes Field Length
19
3
0..1 ||-- OrderShippingInformation Tag
19
4
0..1 |||-- CarrierInformation Tag
19
5
0..1
||||--
accountIdentifier.ProprietaryRef
erenceIdentifier
Freight Carrier account code. Required
if partner specifies “Collect” or “Third
party pay” shipment terms below.
19
6
1 ||||-- GlobalCarrierCode
Cisco’s carrier codes (Please contact
your Cisco B2B project manager or
technical lead for the correct codes).
19
7
0..1 |||-- GlobalFreeOnBoardCode
Point of responsibility for freight.
Example: “Origin” or “Destination”.
Note: Field not used at Cisco.
19
8
0..1
|||--
GlobalShipmentTermsCode
Cisco supports shipment terms that
follow. All other values are ignored and
defaults are used.
Prepaid, but charged to customer
Prepaid (by seller)
Collect
Third party pay
Note: Field not used at Cisco.
19
9
0..1
|||--
GlobalShippingServiceLevelCod
e
Required when using SCAC codes in
GlobalCarrierCode field above. Cisco
maps combination of carrier code and
service level to a Cisco carrier code.
Note: Field not used at Cisco.
20
0
0..n
|||--
GlobalSpecialFulfillmentRequest
Code
Cisco can support a special fulfillment
request only at the order level. Any value
supplied at line level is ignored.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 53 of 144
No. Cardinality
PIP Element Notes Field Length
20
1
0..1
|||--
packListRequirements.FreeForm
Text
Shipping and Packaging notes; notes
display on all packing slips and invoices
20
2
0..1 |||-- SpecialHandlingInstruction Tag
20
3
0..n
||||--
GlobalSpecialHandlingCode
If value is “Attachment – Customer’s
Document”, value provided in element
204 is interpreted as carton notes
20
4
0..1
||||--
specialHandlingText.FreeFormT
ext
Carton notes, if value in element 203 is
“Attachment - Customer's Document”
4.11 Shipment Routing Configuration Tool
Another way to specify shipping instructions is to send values that comply with Cisco’s Shipment
Routing Configuration Tool. These values infer a shipment routing lane based on the ship-to location
and the shipment service level. Because this data is Cisco-specific, Cisco gives partners the ability to
provide this information in the proprietaryInformation.FreeFormText field. The optional status of
these fields are evidenced by cardinality values of 0..1 in the table that follows.
Routing Preference – This field allows the customer to specify who will be responsible for
providing the freight carrier for shipping products. Valid values are:
•
“Cisco Routed”
•
“Customer Routed”
The system will derive the freight carrier code and account number from the Shipment Routing
Configurator Tool (SRCT), if the RoutingPreference is ‘Customer Routed’ but no value is provided for
these fields on the 3A4 XML order. Derivation is performed by the system before the order is
imported into ERP, however this information is not reflected on the POA
In case these are not setup in
the SRC tool, then system raises tasks to reflect the same.
MoveServiceLevel – This field allows the customer to specify the service level for shipments.
Valid values are:
• “Standard”
• “Premium”
• “Express”, which delivers the fastest and is the most expensive service.
• “Deferred”
Table 18: Purchase Order Level in PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes Field Length
342
0..1
Used to send multiple Cisco proprietary
information in <name>=<value> format.
Use ‘|’ as a delimiter for multiple values;
no whitespace should be around equal
sign.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 54 of 144
No. Cardinality PIP Element Notes Field Length
|--
proprietaryInformation.FreeFormT
ext
Name: RoutingPreference
Name: MoveServiceLevel
Example:
RoutingPreference=Cisco Routed
MoveServiceLevel=Standard
Table 19: ProductLineItem Level in V02.00.00
No. Cardinality PIP Element Notes Field Length
304 0..1
||--
proprietaryInformation.FreeFormT
ext
Used to send multiple Cisco proprietary
information in <name>=<value> format.
Use ‘|’ as a delimiter for multiple values;
no whitespace should exist around equal
sign.
Name: RoutingPreference
Name: MoveServiceLevel
Example:
RoutingPreference=Cisco Routed
MoveServiceLevel=Standard
Note –
a) If Routing Option is "CISCO", the below attributes passed in the PO request will be not be
considered by Cisco Systems while capturing the order.
- Specific Delivery Time
- Authorized Receiving Party
- Carrier will call
- Remove packaging
- Contact prior to delivery
- Inside delivery required
b) If the Routing Option is "CISCO" or "SELF", the below Delivery Option Notes will be ignored by
Cisco Systems while capturing the Order.
- Remove Packaging
- Pre-Shipment Inspection
4.12 Shipping and Packaging Notes
Partners can provide the shipping and packaging notes that display on all packing slips and invoices.
Partners can also include text to display on the carton labels or carton notes, by using the below 3A4
PIP elements on both order level and line level. Information below is regarding line level shipping and
packing notes.
All three PIP elements are optional, as evidenced by cardinality values of 0..1 and 0..n in the fields of
the table that follows.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 55 of 144
Table 20: PIP 3A4 V02.00.for Shipping and Packaging Notes
No.
Cardinality
PIP Element
Notes
Field Length
123 0..1
| |--
packListRequirements.FreeFormT
ext
Shipping and Packaging notes; display
on all packing slips and invoices
CHAR(2000)
203 0..n ||||-- GlobalSpecialHandlingCode
If the value of field is sent as
“Attachment – Customer’s Document”,
value in element 204 is interpreted as
carton notes.
204 0..1
||||--
specialHandlingText.FreeFormTex
t
Carton notes, if value in element 203 is
“Attachment - Customer's Document”.
Note: Actual Carton label can only
accommodate 80 characters including
spaces.
4.13 Ship Set Number
A partner may request the way to group the product lines into a ship set. This shipSetNumber name
value pair is not read by the system. System assigns the ship set numbers internally, and In order to
ship all ATOs on different shipset - PO request would need to
have "GlobalSpecialFulfillmentRequestCode" as blank so its taken from User profile (if the user
profile value is set up as Ship All items Separately = 'Y') or the PO can also have
GlobalSpecialFulfillmentRequestCode ='SHIP PARTIAL - BALANCE BACK ORDER'
4.14 End User / Install Site
Partners should provide end user information if the Product Line Item is a hardware part, for example,
Cisco2501. End user information is required for all resale orders.
Partners should specify the install site information, that is, the location where the hardware part will
be serviced if the Product Line Item is a service part, for example, CON-SNT-2501. When partners
are ordering a new service on a 3A4-XML order, Cisco returns warnings and recommends the other
available service(s) in case the requested service is not available at the given install site.
Please contact your Cisco B2B project manager or technical lead for further information on address
validation and mapping.
If there are only service products in the PO (that is, a Service Only PO), Cisco rejects the PO when
the requested service level is not available at the given install site.
Cisco validates the provided ship to and end user addresses against country postal guidelines for
completeness and validity. Addresses that do not conform to the below guidelines may cause the
submitted order to require manual review by Cisco’s order processing Customer Service team. This
can delay subsequent order cycles.
Note – In the case of a resale order with deal ID but no end customer information sent in on the order
request, the end customer is picked from the deal and the Cisco Order Reason code is derived as
Resale.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 56 of 144
4.14.1 Guidelines
Please ensure you take the following guidelines into account when developing your ship to and end
user address mapping:
Insert street address in line 1, unless additional department name or building information is
required for delivery.
If additional company department or building information needs inclusion, please use address
line 1 (and 2, if necessary). Place the street address in the next address line.
Insert contact names and contact details in the relevant contact elements, not in the address line
fields.
Insert any additional delivery instructions in the packing slip or carton notes fields. For more
information, see Section 4.12, Shipping and Packaging Notes.
Do not use PO Box references in end user addresses.
RegionName (state/province) is mandatory for Japan, US, or Canada addresses.
The following Address-Requirement Grid summarizes the minimum address data requirement for
indicated country for a 3A4 XML order.
Table 21: Address Requirement Grid
2
Country
ISO
Code
End user
Compan
y Name
Address
Line 1
Address
Line 2
Address
Line 3
City
State/
Province/
Region
Country Postal Code
Australia
AU
Street address is mandatory.
See above guidelines for
placement.
O
Brazil
BR
O
Canada
CA
China
CN
O
France
FR
O
Germany
DE
O
Italy
IT
O
Japan
JP
UK
GB
O
USA
US
Other Countries
-
O
2
() is a required data for a valid address, it is commonly used in that country and will pass internal Cisco order validations
(O) is a optional data for a valid address, it is not part of common address format for that country.
(N/A) data is not required for a valid address; it is not used in that country.
Refer to appendix C for complete list of such rules.
Note: customer name, address line 1, and country are mandatory for performing address validation. System would reject the orders in case
these mandatory elements are not provided on the PO and there is no address ID is provided on the PO. This is applicable to shipping, billing,
reseller and end user/install site addresses.
Note – system has been enhanced to handle diacritics. Refer to Appendix H for more details on acceptable diacritics
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 57 of 144
Table 22: PIP 3A4 V02.00.00
No. Card
inality
PIP Element Notes
Field
Length
127
1..n
|--ProductLineItem
Required tag
N/A
140
0..n
| |--CustomerInformation
Required tag
N/A
142
1
| | |--GlobalCustomerTypeCode
Send the value “End Customer”.
N/A
143
1
| | |--PartnerDescription
Required tag
N/A
144
1
| | | |--BusinessDescription
Required tag
N/A
145 0..1
| | | | |--
businessName.FreeFormText
Send End Customer Company Name.
Example: “BigCompany Inc.”
CHAR(50)
150 1
| | | |--
GlobalPartnerClassificationCode
Send the value “End User”. N/A
151
0..1
| | | |--PhysicalAddress
Required tag
N/A
152 0..1
| | | | |--
addressLine1.FreeFormText
Street address of End Customer
company.
Example: “170 WEST TASMAN DRIVE”
Note: Field not used for order notes.In
order to prevent CPE tasks, systems
expects the Name, addressLine1 and
Country for address creation or
validation
CHAR(240)
153 0..1
| | | | |--
addressLine2.FreeFormText
Street address of End Customer
Company.
Example: “170 WEST TASMAN DRIVE”
Note: Field not used for order notes.
CHAR(240)
154 0..1
| | | | |--
addressLine3.FreeFormText
The street address of End Customer
company.
Example: “170 WEST TASMAN DRIVE”
Note
:
Field not used for order notes.
CHAR(240)
155 0..1 | | | | |--cityName.FreeFormText
The city of street address of End
Customer company.
Example: “San Jose”
CHAR(60)
156 0..1 | | | | |--GlobalCountryCode
ISO country code of street address of
End Customer Company. UPPERCASE
only.
Example: “US”
Depending on country, system may
expect other mandatory address elemen
ts
like City and/or State
CHAR(2)
157 0..1 | | | | |--GlobalLocationIdentifier
If partners provide a valid location
identifier, system uses this instead of
the address on the PO. However a
known system limitation is that an
CHAR (13)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 58 of 144
No. Card
inality
PIP Element Notes
Field
Length
invalid ID on this tag results in an order
rejection
. Only numeric values accepted
158 0..1 | | | | |--NationalPostalCode
If partners plan to use 10 digit code for
American addresses, omit hyphen “-“.
Hyphen “-“ character is not allowed.
CHAR(9)
160 0..1 | | | | |--regionName.FreeFormText
Mandatory for Japan, US and Canada
addresses. Enter state or province of
End Customer address.
Example: “NC” for North Carolina
CHAR(60)
4.14.2 End Customer Notes
Partners can send any notes for their customers (for example – Customer PO Number) at header
and/or line level in name value pair “EndCustomerNotes”. Cisco will not take any action on these
notes, but these will be echoed back on POA and order submit email notification at line level. These
customer notes will be printed on the shipping label and invoice in a future release.
No. Cardinality PIP Element Notes Field Length
304 0..1
| |--
proprietaryInformation.FreeFormTex
t
Used to send multiple Cisco
proprietary information in
<name>=<value> format. Use ‘|’ as a
delimiter for multiple values, and no
whitespace should exist around equal
sign.
Name: EndCustomerNotes
Example: EndCustomerNotes=
customer notes
String of 35
Char
342 0..1
| |--
proprietaryInformation.FreeFormTex
t
Used to send multiple Cisco
proprietary information in
<name>=<value> format. Use ‘|’ as a
delimiter for multiple values, and no
whitespace should exist around equal
sign.
Name: EndCustomerNotes
Example:
EndCustomerNotes=customer notes
String of 35
Char
Note – In case, there is a header level end Customer note and there are no line level end Customer
notes, then system would default the header level end Customer note to the lines.
Note – System would associate EndCustomerNotes with the EndCustomerAddress for the line. For
lines with same EndCustomerAddress, the EndCustomerNotes should be the same. System would
always pick the EndCustomerNote from the first line within this address group and replicate it to the
other lines of the group.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 59 of 144
4.15 End User Vertical Market
End User Vertical Market is intended for resellers to provide the vertical market they are selling into.
Note: To place a US government order, partners should either give VerticalMarket = Federal
Government and/or provide a DPAS code at header level (tag 342)
A warning is returned if the order contact email is missing on a government order.
The table that follows describes the PIP requirements for the end user vertical market for PIP 3A4,
V02.00.00. The cardinality value of 0..1 indicates that the PIP element is optional.
Table 23: PIP 3A4 V02.00.00 - End User Vertical Market
No. Cardinality PIP Element Notes Field Length
304 0..1
| |--
proprietaryInformation.FreeFormTex
t
Used to send multiple Cisco
proprietary information in
<name>=<value> format. Use ‘|’ as a
delimiter for multiple values, and no
whitespace should exist around equal
sign.
Name: VerticalMarket
Example:
VerticalMarket=Communications
The table that follows describes the values for the vertical market.
Table 24: Values for Vertical Market
Values for Vertical Market
ASP
Federal Government
Mining / Extraction
Aerospace
Finance
Multiservice and Remote Access
Agriculture
Food
Other
Automotive
Government
Pharmaceutical
Banking
Government (Not US
Federal)
Process Manufacturing
Business Services
Healthcare
Retail
Cable Companies
Home
Retail Banking
Central Government
ISP
Service
Chemicals / Petrochemicals
Industry
Service Provider
Communications
Institutions
Software Manufacturers
Construction
Insurance
Telco
Defense
Investment Banking
Telecom
Discrete Manufacturing
LAN Switching
Telecommunications
Education
Local Government
Transportation
Electronics and Technology
Manufacturing
Utilities
Energy
Media and Publishing
Wholesale
Entertainment, Leisure and Tourism
Military
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 60 of 144
4.16 Product Line Number and Quantity
Line number product on the order is used as the Purchase Order Line Reference Number.
Partners can use their purchasing system line number. This can be any unique number. Cisco will
reference this line number as the “PO Line Reference Number” in order status messages and
invoices.
Quantity is the product quantity ordered for a product line. Unit of measure is always ‘Each’ for
product and service items.
The table that follows advises that all of the PIP elements are mandatory. This fact is evidenced by
cardinality values of 1 for each PIP element.
Table 25: PIP 3A4 V02.00.00 - Quantity
No. Cardinality PIP Element Notes Field Length
167 1
| |--
GlobalProductUnitofMeasureCode
Send the value “Each”. N/A
189 1 | |--isDropShip.AffirmationIndicator
Although required by RosettaNet, Cisco
does not support this value. Send either
“yes” or “no”.
N/A
190 1 | |--LineNumber
Purchase Order Line Reference number
Example: “1”
CHAR(6)
Minimum
length is 1
CHAR
191
1
| |--OrderQuantity
Required tag
N/A
192 1
| | |--
requestedQuantity.ProductQuantity
Product quantity for this line
Example: “1”
NUMBER
4.17 Product Line Reference
Line ID and Parent Line ID are used to represent PO list of hardware or software item(s).
Line ID and Parent Line ID will be used in the configuration information tag as specified in
Section
10.2. 1, Product References.
Additionally, to indicate the hierarchy and service linkage information, partners have to send in the
Line ID and Parent Line ID obtained via Cisco Web Services as part of the ConfigurationInfo tag.
The use of ServiceFor (Element #304) tag has been discontinued. Partners will have to send Line ID
and Parent Line ID to indicate the service linkage.
Section 10.2. 1, Product References
on the same PO provides details on how the Line ID and Parent
Line ID should be provided on the order.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 61 of 144
5 Order Product
5.1 Product Number
Partners can order different types of Cisco products:
Configurable
Non configurable (for example, spares and software upgrades)
Included sub items by Enterprise product SKUs
New services for serviceable Cisco products by Enterprise service SKUs
If partners do not provide a valid Cisco part number, the order is rejected.
Note – As of March 2014, Cisco is enabling configuring, quoting and ordering of pre-owned
equipment in CCW UI, such SKU’s are not supported via B2B ordering mechanism.,
5.2 Configurable Products
Spare configurable items such as chassis parts and cards are configurable products, for example,
Cisco2501, RSP8, and VIP-50. A configurable part must have one major line and one or multiple
minor lines, for example, cable CAB-ACE.
The hierarchy of major and minor lines should be indicated by partners via the
ConfigurationInformation. Section 5.5, Service for Products on the Same PO Number
on the same PO
order provides details on how the Line ID and Parent Line ID should be configured on the order.
Products can be configured using the CCW Configuration UI. Only minors displayed by the Cisco
Configuration UI are valid minors. If partners need to order additional minor options that do not fit into
the major (for example, chassis) configurable line, then these additional minor options need to be
placed on a separate line as a spare item.
Cisco validates every configurable product in a PO. Cisco will reject orders with invalid
configuration(s) and return configuration error details.
The following scenarios are examples of invalid configurations:
Missing major line in a configuration - A PO contains minor lines; a PO does not contain a
major line number. This configuration is not valid because minor lines are provided without
providing the parent line. Order is rejected.
Non-service part is entered as a minor of a service part - For example, take an order with
major line as CON-SNT-2501 (a service part) and the minor line number is CAB-ACE (a power
cable). A hardware part cannot be entered as a minor of a service part.
Minor entered for a spare - For example, take an order where the major line number is CAB-
ACE= (cable), and the minor line is MEM-XP-1 (memory). This is not valid because a memory
cannot be a minor of a spare cable.
A minor that is no longer a member of a major product’s Bill of Materials – In this case, a
product’s Bill of Materials may change before submission of the order. For example, software
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 62 of 144
may become obsolete and removed from the Bill of Materials. Please validate the configurations
using a Cisco configuration tool or web service before submitting an order.
• If a product is configured in a significant time period before an order is placed, it is likely that
the production configuration has been updated and is causing configuration validation
failure.
5.3 Non-Configurable (Spare and Software Upgrades) Products
Spares (for example, Cable CAB-ACE=), and software upgrades are non-configurable items. For the
same part, minor lines (of a configuration) have a different part number than non-configurable items.
For example, CAB-ACE= is the part number for a spare, and CAB-ACE is part number for a sub-
item. A non-configurable item cannot have other sub-items and partners cannot send these options
as major line items.
Note: A flag published in the catalog using 2A1 Product Information Notification Message Guideline
indicates if a product can be ordered as a major line.
5.3.1 Included Sub-Products
Some sub-items are automatically included with certain configurations (that is, the items are added
at no cost). The Cisco Configuration Solutions show that these items are free (have no monetary
value) even though there may be a non-zero price in the price catalog.
Partners are not required to include zero price items of a configuration in the PO. Cisco will
automatically insert zero price items into a configuration in the PO (see Section 7.1, Zero Pricing
).
5.3.2 Service Products
Like configurable parts and spares, service products have part numbers and listprices. When
partners are ordering a new service contract with a new product, or ordering a new service contract
for a product that was previously ordered and delivered, partners need to include the service SKU for
each product that requires a service contract, including minor product lines.
This requirement is indicated by a cardinality value of 1 in the No. 209 row of the table that follows.
Table 26: PIP 3A4 Version 02.00.00 – Service Products
No.
Cardinality
PIP Element
Notes
Field
Length
205 1 | |--ProductIdentification Required tag N/A
207 0..n
| | |--
PartnerProductIdentification
Required tag N/A
208 1
| | | |--
GlobalPartnerClassificationCode
Any valid RN value. On the PO
response back, “Manufacturer” would
be sent back.
N/A
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 63 of 144
No. Cardinality PIP Element Notes Field
Length
209 1
| | | |--
ProprietaryProductIdentifier
Cisco part number
Example:
“Cisco2501”
“CAB-AC”
“CON-SNTE-2501”
CHAR(50)
Note – The valid Rn values for GlobalPartnerClassificationCode are -
PurchaseOrder.ProductLineItem.ProductIdentification.PartnerProductIdentification.GlobalPartnerClass
ificationCode. However, the valid RN values that can be sent in this field are "Manufacturer", "End User",
"Reseller", "Retailer", "Broker", "Carrier", "Shopper", "Financier", "Warehouser", “Distributor”, “Customs Broker”,
“Freight Forwarder”, “Distribution Center”, “End User Government”, “Contract Manufacturer”, “Forecast Reply
Recipient”, “Original Equipment Manufacturer”. Any other Invalid values will result in failure of order submission at
gateway.
Also, in case of multiple blocks of PartnerProductIdentification, the first available block with
GlobalPartnerClassificationCode = “Manufacturer” is used to map SKU/kitRef from the corresponding
ProprietaryProductIdentifier. If there are no blocks with GlobalPartnerClassificationCode= “Manufacturer, then
the first block’s ProprietaryProductIdentifier is used to map the SKU/kitRef being ordered
5.3.3 FULFILLMENT RESTRICTIONS on SKUs
When B2B XML orders contains SKU which is restricted from being fulfilled by Cisco, the order is
rejected. Below table has the fulfillment restriction values and the system behavior.
Flag Value Partner Distributor Direct Customer
YES Not allowed Allowed Not allowed
NO Allowed Allowed Allowed
BLOCK Not allowed Not allowed Not allowed
NO STOCK Allowed Allowed (Only for Orders
where Intended Use =
Resale)
Allowed
5.3.4 Meraki SKUs
Meraki SKUs can be ordered as non-configurable spares on B2B XML orders – that is the
parentLineID for the lines with these SKU is 0.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 64 of 144
• For Meraki SKU lines, the end customer addresses and contact – email and phone, shipTo
addresses and contact – email and phone, and billTo address and contact – email and phone,
are required fields. Not providing this information on a PO results in a delay in processing the
PO, if current addresses defaulting rules are unable to derive these addresses and contacts
systematically.
• Enabled Only for 1Tier Partners, Direct & Disti Drop ship . Disti Stocking will not be supported
and Meraki SKUs will not be published on WPL.
• There is no Service/Subscription attached to Meraki Products
• Requested Ship date would continue to be mandatory for all the Shipping group including
Shipping group that has Meraki Products , but Meraki will NOT be honoring the requested
ship date, will be fulfilled on an ASAP basis.
• Enterprise and Advanced Security Meraki licenses are not allowed on the same purchase
order. Any such purchase orders having both Enterprise and Advanced Security Meraki
licenses will be rejected. The Enterprise Meraki licenses and the Advanced Security Meraki
licenses have to be placed in separate purchase orders.
5.4 Service Ordering – Product Link
When a service contract is ordered for a Cisco product, partners should associate it with a Cisco
product they are ordering in the same Purchase Order or with a Cisco product at partner site (include
products that were ordered in another PO or are in transit from Cisco). Based on the type of service
partners are ordering and how their system is integrated to Cisco’s systems, they will provide the
linkage differently. If Cisco is unable to identify the covered product in relation to the service lines,
orders are rejected.
5.5 Service for Products on the Same PO
All partners must send in the Line ID and Parent Line ID attributes on the 3A4 XML order via the
ConfigurationInformation tag. For Services lines, the Parent Line ID will indicate the product for which
the service is being ordered.
If no Line ID or Parent Line ID is provided, the system will treat the line as a major line. If only a line ID
is provided, the system will treat it as a major line.
Unlinked Lines will have a Parent Line ID of ‘0’. A Best Guess Logic (BGL) is applied to determine the
best match for unlinked lines.
In case of ordering services/subscriptions attached to system included items, partners are expected to send the
system included items along with the associated services/subscriptions on the PO. In case such
services/subscriptions are on the PO without the covered product (system included items), system would
expand the PO with auto included items, as part of existing configuration validation process and will apply Best
Guess Logic (BGL) to try linking these service/subscriptions to those items
An example of the service follows:
3A4
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 65 of 144
SKU PO Line Ref
Config Info (lineID; parentLineID
along with other data not
depicted here)
Product
Cisco-2611XM A 10; 0;
Option- minor product
CAB-AC
B
21; 10
Service
CON-SNT-26XX C
30; 10,but for unlinked service
30; 0
Cisco-1801 D 40; 0
Figure 3: Service for Products on the Same PO Order
When partners use the AcquireQuote/Transfer Quote Web Service and Punch Out to the CCW
Configuration UI, the service linkage information (Line ID and Parent Line ID) is sent to them as part of
the TransferQuote output.
Partners will need to provide the LineId, ParentLineId, and CiscoProductReference returned by the
TransferQuote WebService in the ConfigurationInformation field data.
The Cisco Product Reference contains a database key that allows us to retrieve the path data from
the Configuration Set.
Table 27: PIP 3A4 Version 02.00.00 – Service for Products on the same Order
No. Cardinality PIP Element Notes Field Length
304 0..1
| |--
proprietaryInformation.FreeFormTe
xt
Used to send multiple Cisco proprietary
information in <name>=<value> format.
Use ‘|’ as a delimiter for multiple values,
and no whitespace should exist around
equal sign.
Name: ConfigurationInformation
Example:ConfigurationInformation=10,0;2
324567
Partners should map a service to hardware in the order as part of the 3A4 request. The mapping is
provided at the service product level and contains the Line ID of the product it covers. The Line ID
must be unique for each product in the 3A4 request.
Note: If the partner is ordering only Service Only type order, the partner needs to provide coverage
information via the Serial Number.
The LineID,parentLineID can be any number. LineID must be
unique.
ParentLineID of a major line will be 0.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 66 of 144
5.6 Service Ordering for Product(s) at Partner Site
Partners order without a Cisco Service Quote - Partners must provide reference information as
proof of purchase of the equipment. They can provide either the serial number of the equipment
or the PAK number for non-serialized parts, such as software.
• Serial Number – Partners can specify the serial number of the hardware product for which
they are buying a service contract. If service is ordered for a non-serialized part, the serial
number is not required. System also accepts one or more serial numbers for a given service
line.
In order to place orders with services whose associated products orders are not shipped as yet
(no serial/PAK numbers), certain distributors can place orders with such services by referencing
the coveredProductNumber name value pair at line level to indicate the associated covered
Product. Along with this, these certain distributors will need to send in at a header level tag 342,
a name value pair of serviceOrderType = PARTIAL, in order to indicate to the system that the
order contains service lines with partial information. Please contact B2B project manager to get
the list of distributors who are enabled to avail this ordering feature.
Note: A Cisco service product may service different Cisco products. If partners need to order
service for two different products that are serviced by the same service product, they should order
service on two separate lines and provide the service linkage for the respective product.
The optional nature of service ordering for products at a partner site is evidenced by the cardinality
value of 0..1 in the table that follows.
Known Limitation
The system cannot currently proceed with processing orders with only service lines, but no serial
number information/PAK number information at line level. Such orders will be rejected.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 67 of 144
Table 28: PIP 3A4 Version 02.00.00 – Service Ordering for Products at Partner Site
No. Cardinality PIP Element Notes Field Length
304 0..1
| |--
proprietaryInformation.FreeFormT
ext
Used to send multiple
Cisco proprietary
information in
<name>=<value> format.
Use ‘|’ as a delimiter for
multiple values, and no
whitespace should exist
around equal sign.
If there is more than one
serial number (like partners
are ordering service for
multiple quantity), provide
them in separate
name/value separated by
pipe.
Name: SerialNumber
Example:SerialNumber=43
434343434|SerialNumber=
123123123
Example:
coveredProductNumber=
Cisco1801
Maximum length of
a SN is 60
characters
342 0..1
| |--
proprietaryInformation.FreeFormT
ext
Used to send multiple
Cisco proprietary
information in
<name>=<value> format.
Use ‘|’ as a delimiter for
multiple values, and no
whitespace should exist
around equal sign.
Example –
serviceOrderType =
PARTIAL
The valid values for this
name value pair is
“PARTIAL” any other value
sent on this name value
pair is ignored.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 68 of 144
5.7 Service Ordering
5.7.1 Service Contract Information
Cisco Service Contract is created to manage services that Cisco provides to its partners.
Contract Number - When partners place a new service order, they can choose to have it
managed under an existing Cisco service contract. The Cisco contract should be provided as the
contract number value or the system would pick the value set up in the user’s profiles and
preferences. – Q2FY16 Change
• If a valid Contract Number is entered, the system will validate that the contract meets the
parameters below and if it does not, it will use logic for ‘USE_EXISTING’.
• BillTo Match
• Service Level that is the same or has a service level that is compatible, meaning multiple
service levels on a contract.
• Checks if contract has only a Single End User on contract.
• If you choose to have Cisco match to an already existing contract, state ‘USE_EXISTING’ as
the contract number value. Cisco will try to match to an already existing contract using the
below logic. If no matches can be made, a new contract will be created.
• BillTo Match
• Service Level that is the same or has a service level that is compatible, meaning multiple
service levels on a contract.
• Checks if contract has only a Single End User on contract.
• If you choose to have a new Cisco contract created for your new service, state ‘NEW’ as the
contract number value.
Contract Start Date - Provide a requested Contract start date for all service orders. This is not a
mandatory action to provide a contact start date for all service orders. Contract start date should
not be provided for Initial purchase of Services. The contract start date for the initial purchase
will be derived in ERP based on the Product Ship date.
Contract End Date - Provide a requested Contract end date for all service orders. This is not a
mandatory action to provide a contact start end for all service orders..
Contract Duration - Provide a requested service duration when you are ordering a new service
order. Cisco policy allows customer to order a service in duration of 12, 24, or 36 months.
The service duration defaults to the standard duration setup for the SKU on the PO in the system if
no duration or start date and end date is provided on the PO and there is no ConfigRef ID on the PO
In case of co-terming services, a contract start date and contract end date is needed. Not providing
a ContractStartDate, while co-terming services to a particular ContractEndDate will result in order
rejections.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 69 of 144
Note – Services can be ordered with service duration greater than 36 months only when there are
corresponding approved non-standard deals on the order or the orders are submitted by OSM/OEM
partners.
Technical Services (TSS) can be ordered with duration up to 60 months via B2B Stand Alone Orders
(no deal reference) or B2B Deal based orders.
Reseller BID or Address: If you are a Distributor and are ordering the service for Resale, provide
the Reseller Information. Please refer to section 5.7.3 for details.
Providing the Reseller BID for Disti Resale Order is strongly recommended. Reseller BID is the
preferred attribute over Reseller Address.
In case of service only ordering providing Reseller Information is required to process orders and get
contracts created without delays.
All of the preceding data elements are collected at the Product Line Item level, so the user can have
different values for different service lines in an order. Please note, Contract Start Date must be within
90 days of submission, and cannot occur before the submission date. If a Contract Start Date is
invalid, the 3A4 XML order will be accepted but a warning message will be returned to you in the
response.
Cisco Shared Support Program (CSPP) is a new program that will give partners one unified
experience across product and services with improved operational efficiencies, consistency, and
predictable rewards. Instead of having multiple service programs with different eligibility criteria,
metrics, and discounting, CSPP plans to align partner eligibility for all service families with the
certification / specialization or designation criteria that is specified within the WW Channels
programs.
Multinational Quote refers to a quote where the bill-to country and the install-at country differ.
Resellers may only BUY FROM the distributors allowed to sell into the reseller's territory. Distributors
may only SELL TO resellers within the distributor's contractual territory.
CSPP and MNQ eligibility checks are based on the Partner Type, Reseller BID, and Reseller Address.
The table that follows provides additional information about the Service Contract PIP element.
Table 29: PIP 3A4 Version 02.00.00 – Service Contract
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 70 of 144
No.
Cardinalit
y
PIP Element
Notes
Field Length
304 0..1
| |--
proprietaryInformation.FreeForm
Text
Used to send multiple Cisco proprietary
information in <name>=<value> format. Use
‘|’ as a delimiter for multiple values, and no
whitespace should exist around equal sign.
Values are:
Name: ContractDuration
Name: ContractNumber
Name: ContractStartDate
Name: ContractEndDate
Example: New Service Order with contract
ContractDuration=12|ContractNumber=1238
4636|ContractStartDate=20050112Z|
Example: New Service Order with existing
contract
ContractNumber=USE_EXISTING|ContractSta
rtDate=20050112Z|ContractEndDate=20120
112Z|
Example: New Service Order with new
contract
ContractDuration=12|ContractNumber=NEW|
ContractStartDate=20050112Z|
5.7.2 Primary and Secondary Services (Technical)
Secondary coverage is sold as a compliment to a primary coverage when additional service is
needed that is not included in the primary service program. This situation typically applies to
Collaborative and Partner branded services because in these selling models the Partner, or
combination of the Partner and Cisco, will deliver the primary service. Secondary coverage may be
needed in these situations because additional software services are not part of the primary offering.
For example, Intrusion Prevention Services (IPS) will not be included in Collaborative or Partner
branded services because it is Cisco intellectual property and must be Cisco Branded. If IPS is
needed in conjunction with a primary service, then IPS service can be ordered as secondary service
coverage, provided there is a compatible primary service level in place for the duration of the desired
secondary service contract.
This feature will enable partners to attach primary and secondary technical support in addition to
multiple software subscriptions, where applicable, for any given product configuration.
NOTE - Secondary service can only be purchased along with Primary together, across applicable
serviceable lines in a configuration
In case of purchase order having primary and secondary technical services, system would reject the
PO in the following scenarios:
• Primary service is is invalid or is not activePrimary coverage has expired or expiring before
start date of secondary services.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 71 of 144
• Secondary service start date is before the start date of primary service
• Secondary service end date is after the end date of primary service
Hierarchical structure for primary and secondary services on a PO –
• On PO both primary and secondary will be placed at the same hierarchical positions (both are
attached to the same product SKU). In the pre-ordering capabilities of CCW (Config, Catalog,
Quote, Build and Price), users will be able to distinguish between the primary and secondary
services via the service type attribute.
5.7.3 Reseller Information
Partner can send the reseller information at PO header level in the following section
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 72 of 144
Table 30: PIP 3A4 Version 02.00.00 – Reseller Information
No.
Cardinalit
y
PIP Element
Notes
Field
Length
348 0..1 |-- SecondaryBuyer
349 1 | |-- PartnerDescription
350 1 | | |-- BusinessDescription
351 0..1
| | | |--
businessName.FreeFormText
Reseller Business Name. Note the
Name, Addr line 1 and Country are
mandatory elements for performing
address validation. If SecondaryBuyer
tag is populated on the PO, system
rejects the PO, if any of these
mandatory elements are missing.
352 1 | | | |-- GlobalBusinessIdentifier
353 1 | | |-- ContactInformation
354 0..1
| | | |--
contactName.FreeFormText
Reseller Contact First Name, Reseller
Contact Last Name
355 0..1 | | | |-- EmailAddress Reseller Contact Email Address
357 0..1
| | | |--
telephoneNumber.CommunicationsNum
ber
Reseller Contact telephone number
358 1
| | |--
GlobalPartnerClassificationCode
Reseller
359 0..1 | | |-- PhysicalAddress
360 0..1
| | | |--
addressLine1.FreeFormText
Reseller Address Line 1
363 0..1 | | | |-- cityName.FreeFormText Reseller City
364 0..1 | | | |-- GlobalCountryCode Reseller Country
365 0..1 | | | |-- GlobalLocationIdentifier Reseller BID (Cisco BID)
366 0..1 | | | |-- NationalPostalCode Reseller Zip code
367 0..1 | | | |-- regionName.FreeFormText Reseller State
5.8 Config Check
If the configuration of the ordered Cisco product is invalid, the PO is rejected by Cisco.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 73 of 144
5.9 All or Nothing Rule
When ordering configurations with both products and services, partners should either:
Include orders for all applicable services for the product configuration on the same order
Not order any of the applicable services
Splitting of service orders for products within the same configuration is not allowed.
The following is a description of the goal of the “All or Nothing rule” for Technical Services in the
CCW Program:
Not allowing for “Partial Service” purchase in CCW
Irrespective of who is selling the service, Cisco wants to sell service on most (if not all) of the
lines. Business rules will check for both Technical Support and Application Software on lines.
When there is service on any line, all lines are required to have service.
5.10 Sample Orders
As of September 2011, Sample Orders are rejected with the error message: “Order type is not
handled in NextGen Order management.” if the value in PIP Element#342:
proprietaryInformation.FreeFormText CiscoProgram=Version Sample
5.11 Deal ID Validations
A Deal ID is a Cisco identification code used by Cisco’s Sales Department to identify sales quote(s)
that give partners special pricing. One or multiple quotes can belong to a Deal ID.
Partners can supply a Deal ID for a PO in the PurchaseOrder.DocumentReference.
ProprietaryDocumentIdentifier with the PurchaseOrder.DocumentReference.
GlobalDocumentReferenceTypeCode = “Contract”.
Note: A Deal ID ties an acquired discount (above and beyond a contractual discount) to a Sales
Deal. The order rejects if the Deal ID is deemed invalid.
Table 29: PIP 3A4 V02.00.00 – Deal ID Validations
The list of Deal ID validations are as listed in the table below
No.
Cardinality PIP Element Notes Field Length
74
0..n
|-- DocumentReference
Tag
75
0..1
| |-- DateTimeStamp
Not used
76 1
| |--
GlobalDocumentReferenceTypeCode
Send the value “Contract”.
RosettaNet
value
77
1
| |-- ProprietaryDocumentIdentifier
Deal ID (must be a numeric value)
CHAR(50)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 74 of 144
Table 32: Deal ID Validations
Scenario
Result
Status of deal is not “Approved” or “Ordered”
Order is rejected
Unrecognized deal ID on PO
Order is rejected
Intended Use derived from PO different than
Intended use on Deal
Order Processing delayed
Pricelist mismatch on RNSD deal and order
Order is rejected except for GLUS and GLOBAL
pricelist’s
Pricelist mismatch on other deals and order
Order Processing delayed
End User mismatch on deal and order
Order Processing delayed
Partner mismatch on deal and order
Order Processing delayed
Deal ID's try and buy enrollment check failed or
not complete
Order Processing delayed
Unrecognized Try and Buy Deal on Try and Buy PO
Order is rejected
The total extended net price on the Order is less
than the CBN Threshold.
Order Processing delayed
Invalid deal – Deal ID greater than 50 characters or
Alphanumeric (other than “NA” or “N/A”) deal ID
Order is rejected. If deal ID is “NA” or “N/A”,
system will ignore this value and treat this as a
standalone order. Order pricing would be done
at user’s contractual price.
“Global” RNSD deal ID on PO
Order is rejected. User can submit PO with only
“Local” RNSD deal ID.
Currently order is rejected if the PO is submitted
“Global” RNSD deal ID created post Q3 release
(03/09/2014). User can continue to submit PO
with “Global” RNSD deal ID which are created
prior to 03/09/2014 until further
communication.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 75 of 144
6 Special Cisco Programs
6.1 Channels Booking Neutrality
Channels Booking Neutrality (CBN) program ensures neutrality across the different Routes to Market.
CBN orders are associated with Deal ID. They are identified with a “DVAD” identifier in the Billing
address field. To qualify for a CBN discount the order must exceed the threshold check of $100K.
Identification of a CBN order is done by looking for existence of "DVAD" in the Billing Address
(Address Line 1, Address Line 2, and Address line 3) corresponding to the BID for a given order.
CBN Orders can be placed by Distributors only. Intended Use should be 'Resale' and a Deal ID must
be present on the CBN order.
6.2 Managed Services Channels Program (MSCP)
Managed Service Channels Program (MSCP) is a type of contractual discount. When a partner is
eligible for MSCP discounts, the greater of the contractual or MSCP discount is applied.
A partner is identified as a valid Managed Service partner only if the Authorization Code provided is
one of the following:
MSCP
LI
L2
L3
The GlobalPurchaseOrderTypeCode for these orders should be set to “Consigned order”. This is a
change from sending “Services” in this field as in Legacy.
6.3 United States Government Orders
When placing orders for the United States government, customers can set VerticalMarket=Federal
Government and/or specify the DPAS priority code. A US government Disti stocking order with DPAS
value as DX, DO, TAA-DX, or TAA-DO will be processed with a warning to reflect that stocking
orders cannot have preferential indicators.
This order must be shipping to a US address and a contact email address must be provided.
A US government order cannot be a Try and Buy or an eRate order. Cisco will reject those orders.
If a CTMP code is provided along with a DPAS code, Cisco will accept this as a Trade-in order
instead of a US government order.
Partners cannot order only service lines in a US government order. If there is no Cisco product in this
order, Cisco will accept it as a standard order and drop the DPAS value.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 76 of 144
6.3.1 Government Eligibility Check
Eligibility to place government orders is based on the billing country. All US government orders must
have a billing country of US.
A PO is rejected if the Billing country is not US or a Contact email address is missing on the order.
The table that follows indicates the optional nature of the Government Eligibility Check element. This
fact is evidenced by a cardinality value of 0..1,
Table 33: PIP 3A4 Version 02.00.00 - Government Check Eligibility
No. Cardinality
PIP Element Notes Field Length
342 0..1
|--
proprietaryInformation.FreeFormT
ext
Used to send multiple Cisco proprietary
information in <name>=<value> format. U
se
‘|’ as a delimiter for multiple values, and no
whitespace should exist around equal sign.
Name: DPAS
Example: DPAS=TAA
CHAR(8)
6.3.2 Trade Agreement Act (TAA) Orders
TAA orders are identified by one of the following header level DPAS rating values:
TAA
TAA-DX
TAA-DO
Additionally, the line level PartnerTAA flag should be used by partners to indicate if the major line
item being ordered is TAA compliant. If a mismatch exists between the header and line level TAA
flags on an order, that is, the DPAS rating value is a TAA compliant one, but the line level TAA flag is
“N”, the partners will receive an email message indicating the mismatch.
Validations:
For partners submitting government orders without the intention that the order be TAA
compliant, but have their line items on the request specified as TAA compliant, line item values
are ignored while fulfilling the order.
For partners submitting government orders with the intention that the order be TAA compliant:
• If at line level none of the lines are specified as TAA compliant, the order is rejected.
• If at line level there is a mixture of TAA compliant lines and some lines that are non TAA
compliant, a warning is raised to that effect.
• If SKU at line level is specified as non-TAA compliant, however the SKU can only be fulfilled
as TAA compliant and there is no exception process to fulfill this SKU, then the partner can
expect such SKUs as TAA compliant in response.
• If SKU at line level is specified as non-TAA compliant, however the SKU can be TAA
compliant and there is a exception process to fulfill this SKU, then the partner can expect
such SKUs as non-TAA compliant in the response.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 77 of 144
Government TAB orders with preferential indicators (TAA-DX, TAA-DO, Dx, DO) will result in
warnings and these values are ignored.
Government TAB orders can be requested as TAA compliant.
The optional nature of the TAA order is indicated by a cardinality value of 0..1 in the table that
follows.
Table 304: PIP 3A4 Version 02.00.00 for TAA Orders
No. Card PIP Element Notes Field Length
304 0..1
|--
proprietaryInformation.FreeFormText
Used to send multiple Cisco proprietary
information in <name>=<value> format. U
se
‘|’ as a delimiter for multiple values, and no
whitespace should exist around equal sign.
Name: PartnerTAA
Example: PartnerTAA=”Y”
CHAR(8)
Note: TAA+ SKU’s can be ordered on Federal orders where partners have indicated that order should
be TAA compliant itself. Else orders are rejected.
6.4 Try and Buy (TAB) Program
The Try and Buy program allows customers to try a product with the agreement to either:
Return the product within a specified time period (usually 30 days)
Accept the product and be invoiced for receipt of the product
When a Deal ID is present on a Try and Buy Order, the trial period is obtained from the Deal. When
Deal ID is not present on a TAB (Try and Buy) order, Trial Period is defaulted to 90 days. However,
the Telepresence Trial Period will default to 120 days.
To place a Try and Buy order, partners flag the order by inserting CiscoProgram=TAB in the product
line item proprietaryInformation.FreeFormText field.
The optional nature of the TAB order is indicated by a cardinality value of 0..1 in the table that
follows.
Table 35: PIP 3A4 Version 02.00.00 - Try and Buy Program
No. Card PIP Element Notes Field Length
342 0..1
|--
proprietaryInformation.FreeFormText
Used to send multiple Cisco proprietary
information in <name>=<value> format. U
se
‘|’ as a delimiter for multiple values, and no
whitespace should exist around equal sign.
Name: CiscoProgram
Example: “CiscoProgram=TAB”
Char(30)
TAB Order processing fails under following conditions:
If the order is an US government order or an eRate code is provided
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 78 of 144
If the order is for stocking purposes, that is, GlobalPurchaseOrderTypeCode is evaluation,
sample, or replenishment
If the order contains only services-lines
If no service to hardware product linkage could be established
If a contact email ID is not supplied in the ProprietaryInformation field
(PurchaseOrder.ContactInformation.EmailAddress=<name@company.com>)
Invalid TAB deal on a TAB order will result in an order rejection
6.5 Trade-In Migration Orders
The Cisco Trade-In Migration Program allows customers to trade in used Cisco equipment to obtain
a sales credit against a new product order. TAB orders having a trade in promotional code, but no
Deal ID will result in an order rejection. Value for CTMP Quote number is to be derived from the
Quote UI and is specified under TradeIn Quote Number.
Participation in CTMP is optional, as evidenced by a cardinality value of 0..1 in the table that follows.
Table 36: PIP 3A4 Version 02.00.00 - Trade-In Migration Orders
No.
Cardinality
PIP Element
Notes
Field Length
342 0..1
|--
proprietaryInformation.FreeFormT
ext
Used to send multiple Cisco proprietary
information in <name>=<value> format.
Use ‘|’ as a delimiter for multiple values,
and no whitespace should exist around
equal sign.
Name: CTMPQuote
Example: “CTMPQuote=<value>”
6.6 eRate Orders
With the eRate ordering program, partners may obtain government discounts for educational
programs. Partners need to provide the eRate number to product line item proprietary information.
Participation in eRate is optional, as evidenced by a cardinality value of 0..1 in the table that follows.
Table 37: PIP 3A4 Version 02.00.00 for eRate Orders
No.
Cardinalit
y
PIP Element
Notes
Field Length
342
0..1
|--
proprietaryInformation.FreeForm
Text
Used to send multiple Cisco proprietary
information in <name>=<value> format. U
se
‘|’ as a delimiter for multiple values, and no
whitespace should exist around equal sign.
Name: ErateNumber
Example: “ERateNumber=8398402”
CHAR(30)
An eRate order cannot be a US Government order or a TAB order. If a DPAS code and / or
CiscoProgram=TAB is given, Cisco rejects the order.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 79 of 144
An eRate order cannot be a service only order. If there are no Cisco products in this PO, Cisco
accepts this order; however, the given eRate code is dropped.
6.7 Promotional Orders
Promotion Orders are placed to qualify for a sales promotion. The customer is required to supply a
Promotion Code. Validation of special pricing occurs when the order is placed. Please get a
Promotion Code from your Cisco sales representative.
Participation in Promotional Orders is optional, as evidenced by a cardinality value of 0..1 in the table
that follows.
Table 38: PIP 3A4 Version 02.00.00 for Promotional Orders
No. Cardi
nality
PIP Element Notes Field Length
342 0..1
|-- proprietaryInformation.FreeFormText
Note: This is at the header level.
Used to send multiple Cisco
proprietary information in
<name>=<value> format. Use ‘|’ as
a delimiter for multiple values, and
no whitespace should exist around
equal sign.
To process orders with Promotion
Codes: Use Name value pair of
PromotionCode = <<value>>; send
in tag 342 on XML order.
6.8 Advanced Services Fixed (AS-Fixed) Ordering
Advanced Services Fixed (AS-Fixed) Ordering offers consulting services that are purchased directly
or via partners. Many of Cisco’s acquisitions have AS-Fixed offerings. This includes Tandberg,
Webex, and UCS to name a few. Participation in AS-Fixed is optional, as evidenced by a cardinality
value of 0..1 in the No. 169 row of the table that follows.
When ordering AS-Fixed services, partners must submit install site address information as detailed in
Section 4.14, End User/Install Site
.
When ordering these services, partners must also provide install site contact name and contact email
information.
Table 39: PIP 3A4 Version 02.00.00 for Advanced Services Fixed Ordering
No.
Cardinality
PIP Element
Notes
Field Length
169
0..1
| |-- installAt.PartnerDescription
Tag
N/A
170
1
| | |-- BusinessDescription
Tag
N/A
171
0..1
| | | |-- businessName.FreeFormText
Not Used
172
0..1
| | | |-- GlobalBusinessIdentifier
Not Used
173
0..1
| | |-- ContactInformation
Tag
N/A
174 0..1 | | | |-- contactName.FreeFormText
First and last name separated by a
space. Only one name can be sent.
CHAR(50)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 80 of 144
No.
Cardinality
PIP Element
Notes
Field Length
Example: “Tom Knupp”
175
0..1
| | | |-- EmailAddress
CHAR(240)
176 0..1
| | | |--
facsimileNumber.CommunicationsNu
mber
Not Used
177 0..1
| | | |--
telephoneNumber.CommunicationsN
umber
Not Used
178 1
| | |--
GlobalPartnerClassificationCode
Tag N/A
There are two separate categories of AS-Fixed namely Standard (ASF-STD) and AS-Fixed Group
(ASF-GROUP). The standard AS-Fixed SKUs only can be ordered in quantities of one. An AS-Fixed
standard SKU order with quantity greater than one will be rejected. AS-Fixed Group SKUs can be
ordered in quantities greater than one.
6.9 UCSS and Term and Content Subscription Services
Ordering
USCC and Terms and Content Subscription Services Ordering provide licensing for software and
subscription terms.
A brief explanation of terms relevant to the service follows.
Perpetual License for Software
Traditional Software Point Product Sale with a Perpetual License that does not expire and has infinite
life. Customer purchases the right to use a specific software license on a perpetual basis.
Example: IOS, Unity exchange, Call Manager
Upgrade Subscription
Provides the right to receive software version upgrades to a software product for a given term (for
example, 1 year, 3 year, 5 year)
Example: Unified Communications Software Subscription (UCSS) sold with Cisco Unified
Communication Products such as Unified Communications Manager, Unified Messaging, and Unified
Contact Center.
Term Subscription
Duration/Time-based license that expires at the end of specified time period or term. Use of the
product beyond the term is a violation of legal terms. User must either renew or purchase new
licenses to continue use.
Example: Future term based CUWL licensing, WebEx
Content Subscription
Provides data/content updates to maintain the functionality of a software product, such as signature
files.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 81 of 144
Example: IronPort email and Web Security, Adaptive Security Appliance (ASA), Intrusion Protection
System (IPS)
Partners can specify the PAK delivery quantity preference for the subscription SKUs via a new
attribute LicenseKeysRequested that can have values of “Single” or “Multiple”.
Participation in the service is optional, as evidenced by a cardinality value of 0..1 in the table that
follows.
Table40: ProductLineItem Level in V02.00.00
No.
Cardinality
PIP Element
Notes
Field Length
304 0..1
||--
proprietaryInformation.FreeFormT
ext
Used to send multiple Cisco proprietary
information in <name>=<value> format.
Use ‘|’ as a delimiter for multiple values,
and no whitespace should exist around
equal sign.
Name: LicenseKeysRequested
Example: LicenseKeysRequested=Single
Note – The contract start date, contract duration and contract end date are specified in the same
format as for Service SKU’s. However, for subscription, in case there is no duration specified on the
order request, then system defaults the duration and continues order processing. Also, if no start
date is provided on the order for subscription SKU’s then the associated line level requested ship
date will be used. If requested ship date is also not found, current date is used as the contract start
date.
Note- Subscription SKU’s are not allowed on Stocking orders.
6.10 Co-Terming
The presence of an end date on the order indicates that the partner wishes to co-terminate all
services and subscriptions on the order on the specified end date.
Co-terming is available for Maintenance only, M-lines, that is, for service or subscription lines where
the product has been previously ordered and shipped.
Co-terming is for service only ordering, for all services ordered as standalone along with products,
and for services ordered as standalone whose products have already procured.
The following is the logic for calculation of the List Price:
1. Calculate Service Duration in years.
a. ServiceDuration = (EndDate – StartDate + 1 – LeapDay)/365
b. LeapDay = Number of times Feb 29 falls between StartDate and EndDate
2. Find out SPA Duration Quantity for the line service level
a. DurationQty = 1 if Price in Price list is for 1 year
b. DurationQty = 2 if Price in pricelist is for 2 years and so on
3. Calculate Duration Factor
a. DurationFactor = ServiceDuration/DurationQty
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 82 of 144
4. Divide Price List List Price by Duration Factor to find prorated List Price
a. ListPrice = PriceListListPrice x DurationFactor
5. Round List Price using transaction currency rounding rules
a. If Transaction currency is JPY or KRW, round to 0 decimals
b. For all other currencies (USD/EUR/GBP, etc., round to two decimal places)
6.11 Donation Orders
Donation orders are orders submitted as part of Cisco Corporate Donation Program. This functionality
allows members of the Cisco Corporate Donation Program to submit orders in CCW-B2B with the
correct discount and also removes the manual processing that CPE had to do on all of these orders.
To derive an order that is intended for Donation purposes, the system looks for a name value pair of
Donations in the tag as described in the table that follows.
Note: Any other value sent as part of the name value pair is ignored and the order is processed as
normal.
The table that follows indicates the optional nature of participation in donation orders. This fact is
evidenced by a cardinality value of 0..1.
Table 311: PIP 3A4 Version 02.00.00 for Donation Orders
No. Card PIP Element Notes Field Length
342 0..1
|--
proprietaryInformation.FreeFormText
Used to send multiple Cisco proprietary
information in <name>=<value> format. U
se
‘|’ as a delimiter for multiple values, and no
whitespace should exist around equal sign.
Name: Donations
Example: Donations=Y
CHAR(8)
6.12 Country Enablement - Brazil
CE – Country Enablement program’s charter is to enable Cisco’s local presence in the respective countries. BRICM –
Brazil, Russia, India China, Mexico are the 5 countries where CE is driving to setup Cisco business entities in which is
necessary to adhere to the compliance / legal rules of thosecountries.
As part of the Country Enablement initiative, the CCW B2B orders for Brazil would be placed within the
Brazil business entity.
Also, in order to abide by any local legal and compliance requirements, certain business validations
have been enabled. Refer to Appendix J for the complete list of CE Brazil rules. Any validation
failures for these rules will result in PO rejection.
In case of Brazil orders, if partners are providing their local billing address ID (BID) and expecting
Cisco to derive the corresponding Cisco BID, they need to send Cisco’s business operating unit for
that transaction. Partners can find Cisco’s business operating unit for their billing address selected on
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 83 of 144
a quote or estimate in the B2B output mechanism (Punchout shopping cart transfer, file export
formats – CSV, TSV & XML, Acquire Quote web service and Get Estimate web service
Refer to Appendix I for list of current Cisco’s business operating units
Cisco BID is derived from the partner BID and operating unit value sent in on the PO. If no
OperatingUnit is sent on such orders, then system will map Cisco Inc. BID associated with Partner
BID.
Below is the placeholder for the new Name-Value pair on the PO for the Operating Unit.
Table 42: PIP 3A4 Version 02.00.00 – Operating Unit
No. Card PIP Element Notes
342 0..1
|--
proprietaryInformation.FreeFormText
Used to send multiple Cisco proprietary information in
<name>=<value> format. Use ‘|’ as a delimiter for
multiple values, and no whitespace should exist around
equal sign.
Name: OperatingUnit
Example: OperatingUnit= CISCO BRAZIL CA
OPERATING UNIT
In case of Brazil transactions, Cisco will derive taxability on the PO as per the below logic
Table43: PIP 3A4 Version 02.00.00 – Taxability for Brazil transactions
TaxExemptAffirmationIndicato
r on PO
GlobalTaxExemptionCode
on PO
Derived Taxability
N or Blank
NA
Internal Use
Y
Exempt For Resale
Resale
Y
Exempt
Not For Resale PO Rejection
Y
Blank
Internal Use
Y
Non Exempt
Not For
Resale
PO Rejected
Y
Non Exempt
For Resale PO Rejected
For Brazil orders, partners should send additional address related inscription information in the
following name values pairs at header and line level respectively. If the inscription details are not
present or incomplete for Brazil orders, there will be a delay in order booking.
Table44: PIP 3A4 Version 02.00.00 -Header level inscription address information for Brazil orders
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 84 of 144
No. Card PIP Element Notes Field Length / Data Constraints
342 0..1
|--
proprietaryInform
ation.FreeFormT
ext
Used to send multiple Cisco proprietary
information in <name>=<value> format.
Use ‘|’ as a delimiter for multiple values,
and no whitespace should exist around
equal sign.
Name –
ShipToLine4 (to indicate the
neighborhood)
ShipToInscriptionNumber (* This should
be the CNPJ number)
ShipToContributorClass
ShipToInscriptionNumber
Field Length : 150
Data Constraints : The format
supported is “00.000.000/0000-00”
ShipToContributorClass
Field Length : 150
Data Constraints : accepted values
are "CONTRIBUTOR" or "NON-
CONTRIBUTOR"
Table 45: PIP 3A4 Version 02.00.00 for line level inscription address information for Brazil orders
No. Card PIP Element Notes Field Length / Data Constraints
304 0..1
|--
proprietaryInform
ation.FreeFormT
ext
Used to send multiple Cisco proprietary
information in <name>=<value> format.
Use ‘|’ as a delimiter for multiple values,
and no whitespace should exist around
equal sign.
Name –
ShipToLine4 = <Neighborhood>
ShipToInscriptionNumber (* This should
be the CNPJ number)
ShipToContributorClass
EndUserLine4 = <Neighborhood>
EndUserInscriptionNumber
EndUserContributorClass
InscriptionNumber
Field Length : 150
Data Constraints : The format
supported is “00.000.000/0000-00”
ContributorClass
Field Length : 150
Data Constraints : accepted values
are "CONTRIBUTOR" or "NON-
CONTRIBUTOR"
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 85 of 144
6.13 XaaS / On Premise Orders
XaaS represents ― everything (Anything) as a service and leverages the business model of selling
software as a service. Cloud or Software as a Service is one of the annuity models within Cisco. Other
annuity models include service and software.
On-Premise initiative is to support a new subscription model, On Premise, allowing customers to buy
term subscriptions and perpetual licenses together as a single offer, with the flexibility of periodic and
recurring billing. This offer structure allows traditional licenses to leverage the subscription processes
offered by the Subscription Billing Platform (SBP).
By enabling this capability via CCW-B2B, customers can place XaaS/On-Premise orders with Cisco
via B2B.
XaaS/On-premise offers can be placed via CCW-B2B as a new order irrespective of the customer
ordering a new subscription or making a change on the already ordered subscription.
When ordering XaaS/On-Premise offers, partners must also provide all the required additional
attributes as below for new/change. Else orders will be rejected with an appropriate error message.
Rejection Scenarios for XaaS/On-Premise orders:
• Orders sent with flooring BID will be rejected.
• All XaaS/ on-premise offers are limited to quantity of ‘1’ ATO (Major Line) and if more than ‘1’
is sent in the PO order will be rejected.
• All XaaS/On-premise with any pricing discrepancies will be rejected (Unit net price and Ext net
price has to match with what is sent by pre-ordering tools).
• All XaaS/On-premise offers with rate table URL SKU will be rejected if the List Price version
or discount don’t match.
• BGL (Best guess Logic) is not supported for XaaS/On-Premise offers and all orders with at
least one XaaS SKU and path hash missing for any SKU in the PO request will be rejected.
• Service-to contact is mandatory for all XaaS/ On-premise orders with service-to address at
header/line level and if not present order will be rejected.
• All XaaS orders with TnC (Terms & Conditions) as ‘Null’ or ‘N’ will be rejected if not sent as ‘Y’.
• XaaS offers for which transaction id is mandatory and is sent by pre-ordering tools has to be
sent in the PO request or with a magic key sent by pre-ordering tools to retrieve the same, else
order will be rejected.
• Initial term, auto renewal term & billing model are mandatory for all XaaS/On Premise offers at
ATO level and if not sent in PO or invalid sent at line level for system to retrieve, the order will
be rejected.
• True-up term is mandatory for XaaS/on premise offers where true up SKU is included, or a
magic key has to be sent for system to retrieve, else order will be rejected.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 86 of 144
• Requested start date cannot be in the past or way beyond into the future, if the requested start
date don’t fall under the stipulated window set for the XaaS/on-premise offer, order will be
rejected.
• Change subscription orders always has to ordered with a valid change subscription deal id and
subscription id and can’t be ordered as standalone, else order will be rejected.
• Change subscription orders are limited to one configuration per order, else order will be
rejected.
Key callouts/ Assumptions/ constraints:
• Flooring Bill-to IDs’ can’t be used to place a XaaS order.
• All XaaS/on premise offers are net price protected, customers are highly encouraged to pass
unit net price to avoid any pricing discrepancies/ rejections.
• XaaS/on prem offers could be pay per use and price sent in the PO request may not match
with the invoice.
• XaaS/on premise offers with usage SKUs’ that has rate table URL are to be sent with price as
‘0’ and if any price is sent it will be dropped off and sent in the PO Ack as ‘0’.
• Service-to address is mandatory for all XaaS/on premise offers and if service-to address is not
sent at line/header level, then ship-to address at line/header level will be defaulted.
• Requested date if not sent will be defaulted to sysdate+3 (PST)
• For XaaS/on premise offers where provisioning information is required, an email will be sent to
provisioning info email sent in the PO (if not sent, order contact email will be defaulted) with a
link to punch out onto CCW to submit provisioning information. Orders will be kept on hold till
the required information is provided by the customer.
• Values sent in the PO request will take precedence over values in pre-ordering tools when
magic key is sent at line level.
• Smart account can be used for XaaS/on-premise skus’, if not the general defaulting of smart
account takes place.
6.13.1 New XaaS/On-Premise Offer
New XaaS/On-Premise offer can be placed via CCW-B2B and KitRef/ Estimate ref ordering is
supported. New XaaS/On-Premise offer can also be placed as a hybrid order with hardware/
services on the same PO request. New offers can be submitted without a deal id as standalone.
When ordering these offers, partners must also provide service-to address, contact details and
additional attributes required at header/line level as in the table below.
Purchase Order Header Level Service-To Address and Contact in PIP 3A4 V02.00.00
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 87 of 144
No. Cardinality PIP Element Notes Field Length
94
0..1
|-- installAt.PartnerDescription
Required tag
N/A
95
1
| |-- BusinessDescription
Required tag
N/A
96
0..1
| | |--
businessName.FreeFormText
Enter Service-To customer name for this
product.
Example: Global Router Systems, Inc.
CHAR(50)
97
0..1
| | |-- GlobalBusinessIdentifier
Not Used by Cisco.
Char (13)
98
0..1
| |-- ContactInformation
Service-to contact. Mandatory information,
For Cisco to persist information - system
needs contact First Name, Contact Last
name and an email ID/Phone - only when
thess are provided will system be able to
persist service-to contact information
N/A
99
0..1
| | |--
contactName.FreeFormText
First and last name separated by a space.
Note: Only one name can be sent.
.
Example: “Tom Knupp”
CHAR(50)
100 0..1 | | |-- EmailAddress CHAR(240)
101
0..1
| | |--
facsimileNumber.Communications
Number
CHAR(30)
102
0..1
| | |--
telephoneNumber.Communication
sNumber
CHAR(30)
103
1
| |--
GlobalPartnerClassificationCode
End User, Distributor, or any valid value.
Cisco does not use this field.
104
0..1
| |-- PhysicalAddress
Required tag
N/A
105
0..1
| | |--
addressLine1.FreeFormText
Street address of Service-To company.
Do not use this field for any notes. If
additional department or building
information is required, please place
them in this field
. Move street address to
next addressline.
Example: “170 WEST TASMAN DRIVE”
CHAR(240)
106
0..1
| | |--
addressLine2.FreeFormText
Street address of Service-To company.
Do not use this field for any notes. If
additional department or building
information is required, place them in
this field. Move street address to next
address line.
107
0..1
| | |--
addressLine3.FreeFormText
Street address of Service-To company (if
not already supplied in addressline 1 or 2.
108
0..1
| | |-- cityName.FreeFormText
City of street address of Service-to
company.
CHAR(60)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 88 of 144
No. Cardinality PIP Element Notes Field Length
Example: “San Jose”
109
0..1
| | |-- GlobalCountryCode
ISO country code of street address of
Service-to company. UPPERCASE only.
Example: “US”
CHAR(2)
110
0..1
| | |-- GlobalLocationIdentifier
If partners provide a valid location
identifier, system uses this instead of the
address on the PO. However a known
system limitation is that an invalid ID on
this tag results in an order rejection
NUMBER
111
0..1
| | |-- NationalPostalCode
If partner plans on using 10 digit code for
American addresses, omit hyphen “-“.
Hyphen “-“character is not allowed.
CHAR(9)
112 0..1 | | |--
postOfficeBoxIdentifier.FreeFormT
ext
CHAR (9)
113
0..1
| | |--
regionName.FreeFormText
Mandatory for Japan, US, and Canadian
addresses. State or province of billing
address.
Example: “CA” for California
CHAR(60)
Purchase Order Line Level Service-To Address and Contact in PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes Field Length
169 0..1 | |-- installAt.PartnerDescription
Required tag N/A
170
1
| | |-- BusinessDescription
Required tag
N/A
171
0..1
| | | |--
businessName.FreeFormText
Enter Service-To customer name for this
product.
Example: Global Router Systems, Inc.
CHAR(50)
172
0..1
| | | |--
GlobalBusinessIdentifier
Not Used by Cisco. Char (13)
173
0..1
| | |-- ContactInformation
Service-to contact. Mandatory information,
For Cisco to persist information - system
needs contact First Name, Contact Last
name and an email ID/Phone - only when
thess are provided will system be able to
persist service-to contact information
N/A
174
0..1
| | | |--
contactName.FreeFormText
First and last name separated by a space.
Note: Only one name can be sent.
.
Example: “Tom Knupp”
CHAR(50)
175
0..1
| | | |-- EmailAddress
CHAR(240)
176
0..1
| | | |--
facsimileNumber.Communications
Number
CHAR(30)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 89 of 144
No. Cardinality PIP Element Notes Field Length
177
0..1
| | | |--
telephoneNumber.Communication
sNumber
CHAR(30)
178
1
| | |--
GlobalPartnerClassificationCode
End User, Distributor, or any valid value.
Cisco does not use this field.
179
0..1
| | |-- PhysicalAddress
Required tag
N/A
180
0..1
| | | |--
addressLine1.FreeFormText
Street address of Service-To company.
Do not use this field for any notes. If
additional department or building
information is required, please place
them in this field
. Move street address to
next addressline.
Example: “170 WEST TASMAN DRIVE”
CHAR(240)
181
0..1
| | | |--
addressLine2.FreeFormText
Street address of Service-To company.
Do not use this field for any notes. If
additional department or building
information is required, place them in
this field. Move street address to next
address line.
182
0..1
| | | |--
addressLine3.FreeFormText
Street address of Service-To company (if
not already supplied in addressline 1 or 2.
183
0..1
| | | |--
cityName.FreeFormText
City of street address of Service-to
company.
Example: “San Jose”
CHAR(60)
184
0..1
| | | |-- GlobalCountryCode
ISO country code of street address of
Service-to company. UPPERCASE only.
Example: “US”
CHAR(2)
185
0..1
| | | |--
GlobalLocationIdentifier
If partners provide a valid location
identifier, system uses this instead of the
address on the PO. However a known
system limitation is that an invalid ID on
this tag results in an order rejection
NUMBER
186
0..1
| | | |-- NationalPostalCode
If partner plans on using 10 digit code for
American addresses, omit hyphen “-“.
Hyphen “-“character is not allowed.
CHAR(9)
187
0..1
| | | |--
postOfficeBoxIdentifier.FreeFormT
ext
CHAR (9)
188
0..1
| | | |--
regionName.FreeFormText
Mandatory for Japan, US, and Canadian
addresses. State or province of billing
address.
Example: “CA” for California
CHAR(60)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 90 of 144
Purchase Order Header Level XAAS specific attributes in PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes Field Length
342
0..1
|--
proprietaryInformation.FreeFormT
ext
XaaS Terms & Conditions:
Pip3A4PurchaseOrderRequest/PurchaseOr
der/proprietaryInformation/FreeFormText
@ 'XAASTNC'
All XaaS orders are to be sent with flag ‘Y’
,
else order will be rejected
N/A
342
0..1
|--
proprietaryInformation.FreeFormT
ext
Provisioning email:
Pip3A4PurchaseOrderRequest/PurchaseOr
der/proprietaryInformation/FreeFormText
@ 'PROVISIONINGEMAIL'
N/A
Purchase Order Line Level XAAS specific attributes in PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes Field Length
304
0..1
|--
proprietaryInformation.FreeFormT
ext
Requested start date:
Pip3A4PurchaseOrderRequest/PurchaseOrd
er/proprietaryInformation/FreeFormText
@‘ContractStartDate’
Note:
Same has to be sent in
‘requestedEvent.TransportationEvent.DateSt
amp’ with
‘requestedEvent.TransportationEvent.Global
TransportEventCode’ as ‘Ship’ as these are
mandated by Rosetta net standards. Only
date sent as the contract start date will be
considered.
N/A
304
0..1
|--
proprietaryInformation.FreeFormT
ext
Initial Term:
Pip3A4PurchaseOrderRequest/PurchaseOr
der/ProductLineItem/proprietaryInformatio
n/FreeFormText @ 'INITIALTERM'
|--
proprietaryInformation.FreeFormT
ext
Auto Renewal Term:
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 91 of 144
No. Cardinality PIP Element Notes Field Length
304
0..1
Pip3A4PurchaseOrderRequest/PurchaseOr
der/ProductLineItem/proprietaryInformatio
n/FreeFormText @ 'ARTERM'
304
0..1
|--
proprietaryInformation.FreeFormT
ext
Billing Model:
Pip3A4PurchaseOrderRequest/PurchaseOr
der/ProductLineItem/proprietaryInformatio
n/FreeFormText @ 'BILLINGMODEL'
304
0..1
|--
proprietaryInformation.FreeFormT
ext
True-up Term:
Pip3A4PurchaseOrderRequest/PurchaseOr
der/ProductLineItem/proprietaryInformatio
n/FreeFormText @ 'TUTERM'
Note:
Applicable only for true-up skus’
304
0..1
|--
proprietaryInformation.FreeFormT
ext
Transaction ID:
Pip3A4PurchaseOrderRequest/PurchaseOr
der/ProductLineItem/proprietaryInformatio
n/FreeFormText @ 'TRANSACTIONID'
304
0..1
|--
proprietaryInformation.FreeFormT
ext
List Price Version:
Pip3A4PurchaseOrderRequest/PurchaseOr
der/ProductLineItem/proprietaryInformatio
n/FreeFormText @ 'LPVERSION'
Note:
This is applicable for SKUs’ with rate table
URL.
304
0..1
|--
proprietaryInformation.FreeFormT
ext
Discount:
Pip3A4PurchaseOrderRequest/PurchaseOr
der/ProductLineItem/proprietaryInformatio
n/FreeFormText @ 'DISCOUNT'
Note:
This is applicable for SKUs’ with rate table
URL.
304
0..1
|--
proprietaryInformation.FreeFormT
ext
Magic Key:
Pip3A4PurchaseOrderRequest/PurchaseOr
der/ProductLineItem/proprietaryInformatio
n/FreeFormText @ 'MAGICKEY'
N/A
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 92 of 144
6.13.2 Change XaaS/On-Premise subscription Offer
Change XaaS/On-Premise subscription offer can be placed via CCW-B2B and KitRef/ Estimate ref
ordering is not supported. Change XaaS/On-Premise subscription offer cannot be hybrid order with
hardware/ services on the same PO request. All changes on XaaS/On Premise offer should come
with a valid deal id and subscription id.
In addition to the service-to address and XaaS attributes for new XaaS/on premise offer. The below
attributes at header level and line level for required for a change subscription order.
Purchase Order Header Level XAAS specific attributes in PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes Field Length
342
0..1
|--
proprietaryInformation.FreeFormT
ext
Provisioning info change:
Pip3A4PurchaseOrderRequest/PurchaseOr
der/ProductLineItem/proprietaryInformatio
n/FreeFormText @ 'PICHANGE'
This capability is not for Q3FY16 and will
be for future release
Note:
If provisioning questions change and
require additional information from
customers then an email will automatically
be sent irrespective of the flag sent as ‘N’
N/A
Purchase Order Line Level XAAS specific attributes in PIP 3A4 V02.00.00
No. Cardinality PIP Element Notes Field Length
304
0..1
|--
proprietaryInformation.FreeFormT
ext
Subscription ID:
Pip3A4PurchaseOrderRequest/PurchaseOrd
er/ProductLineItem/proprietaryInformation/Fr
eeFormText @ 'SUBSCRIPTIONID'
N/A
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 93 of 144
7 Special Cisco Ordering Functions
Note: All of these special order functions are applicable to 3A4 XML ordering.
7.1 Zero Pricing
Zero Pricing is an ordering program that allows customers to specify standard options such as power
cables or software to default for the hardware equipment (they are commonly called zero-priced
items because the cost of these parts is $0).
Although partners do not need to include zero-priced sub-items when placing an order, they still
need to provide chargeable minor items as part of the configuration.
Partners can specify either the country to default the zero-priced item, for example, an Australian
power cable. Not all configurable products are zero priced, so please read the error messages if
orders fail. Valid country codes include: US, GB, JP, AU, etc.
The country specific zero priced items are listed in the acceptance/confirmation with the PO line
reference = Z prefixed with the major line number. Since there is RN limitation on the number of
characters allowed in a PO Line ref (6 characters), any prefixes of “Z” which would result in length of
PO line ref greater than 6 characters, will be truncated.
The table that follows indicates the optional nature of participation in zero pricing. This fact is
evidenced by a cardinality value of 0..1.
Table 46: PIP 3A4 Version 02.00.00 for Zero Pricing
No. Cardinality PIP Element Notes
Field
Length
342
0..1
|--
proprietaryInformation.FreeFormTe
xt
Used to send multiple Cisco proprietary
information in <name>=<value> format. U
se
‘|’ as a delimiter for multiple values, and no
whitespace should exist around equal sign.
Name: ZeroPriceCountry
Example: ZeroPriceCountry=JP
7.2 DotX and getLatest Function
DotX logic is applicable to IOS software option items only. The DotX feature allows customers get the
latest version of software in their order.
Based on the product ID naming convention, use of this functionality may differ.
Case 1
• The Product ID starts with “S” and
• There is at least one hyphen ‘-‘ in the product number and
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 94 of 144
• The last (1
st
from right side) hyphen in the product number is immediately followed by ‘N.N.N’,
where N can be any number.
In this case, the partner indicates that he requires the latest version of these products by
replacing the last number with ’x’
For example:
• Submit ‘S16RC-12.0.x’ to receive the latest version of S16RC-12.0.22
Case 2
• The Product ID for DotX starts with “S” and
• There is at least one hyphen “-“ in the product number and
• The first hyphen in the product number is immediately followed by three digits
In this case, the partner indicates that she requires the latest version of these products by
replacing the numeric character(s) from fourth character after hyphen (hyphen is position zero)
with an “x”.
For example:
• Submit S16RB-121x to receive the latest version of S16RB-12108
• Submit S16RB-121xT to receive the latest version of S16RB-12105T
The following are the supported patterns
SKU Name Wildcard Format is DotX or not
*-NN-NNNx*
Yes
*-N.N.x* Yes
*-NN.x*
Not
*-NNN.x* Not
*-N.N.N.x* Not
*-N.Nx*
No
*-NNNx* Yes
7.3 KitRef
This functionality allows partners to order using their own product number. They can send orders for
either:
One-to-one part maps (cross reference)
One-to-many part maps (kit reference)
Before placing an order with the KitRef function, partners should create an Estimate using the
Estimate UI and name it with a Partner product number, then:
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 95 of 144
1. Provide a kitReference Indicator flag on the product line item with valid value to indicate that a Kit
Ref ID/Name is being used.
2. Provide the valid Estimate ID/Name as the Cisco part number (in the Proprietary Product Identifier
field) to be ordered.
System does the following with these orders:
Retrieves the Estimate associated with the kit reference (s) along with the line item price and
line item quantity
Adjusts the retrieved quantity at line level in reference to the specified kit Quantity
Reads and validates and deal provided on the order request
Validations on KitReference
1. A Estimate, previously validated and created, has to be provided on the ProductIdentifier tag. If
the partner uses an invalid Estimate ID/Name as the KitRef product, the order rejects.
2. Each such kitReference line should have a kitReference indicator (kitRefId/kitRefName). If not, the
line is treated as a SKU line and would result in an Unknown SKU error.
3. Only valid value for each of the kitReference indicators (kitRefId/KitRefName) is "Y". Any other
value will result in an order reject scenario. In case of a line not being a kitReference line,
kitReference Indicator name value pairs are not expected on the request.
Each kitReference line should have the monetaryAmount set to indicate the Net KitAmount.
These amounts will be validated at the kitLevel and also that total order level. If there is no
discrepancy on the system calculated price and the price on the purchase order (estimate price)
then the order is autobooked and no warnings/tasks are raised.
The Cisco product line item(s) from the Estimate is returned in the response/PO confirmation
message, along with the line item net prices. Response will not include kitAmounts provided on the
order, but will include the net price of each of the expanded line items of each of the kitReferences.
Warnings/errors at line level will be back for each of the line items associated with the Kit.
Response will include the same PO line references as on the request for each of the expanded line
items associated with the kit.
Known limitations on kit references:
ConfigRef and KitRef cannot be used together in a PO.
Disti Resale Kit Ref Orders with Service Lines will return a warning about a missing service
contract (reseller BID).
Partners cannot provide the Partner’s part number in the Proprietary Product Identifier element.
Mixed KitReference order (order with kitReferences as well as SKU lines)is not supported.
ZPL is not supported on kitRef orders and hence ZPL Country name value pair is not expected on
kitRef orders
The table that follows indicates the mandatory nature of providing Kit Ref. This fact is evidenced by a
cardinality value of 1 in the first table that follows.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 96 of 144
Table 47: PIP 3A4 Version 02.00.00 for Kit Reference
No. Cardinality PIP Element Notes
Field
Length
209 1
| | | |--
ProprietaryProductIdentifier
Cisco part number
Example: “Cisco2501” or “CAB-AC”.
Contains a ConfigSet Id/Name if KitRef
flag is
set in line level proprietary info element.
CHAR(50)
Table 48: PIP 3A4 Version 02.00.00 for Kit Reference Indicator
No. Cardinality PIP Element Notes
Field
Length
304 0..1
| |--
proprietaryInformation.FreeFormT
ext
Used to send multiple Cisco proprietary
information in <name>=<value> format. Use
‘|’ as a delimiter for multiple values, and no
whitespace should exist around equal sign.
Name: ‘kitRefId’ if a config set id is given in
element#209, ProprietaryProductIdentifier
Name: ‘kitRefName’ if a config set name is
given in element#209,
ProprietaryProductIdentifier
Example: kitRefId=Y
kitRefName=Y
7.4 ConfigRef
This optional feature (evidenced by a cardinality value of 0..1 in the table that follows) allows partners
to provide the major product item with a reference to a ConfigSet ID or Estimate ID on the PO. The
configuration provided by the partner on the 3A4 PO Request should include the major line and the
minor lines that have a dollar value associated with them. Based on the submitted Config Set
ID/Estimate ID, Cisco will expand the line to include the zero priced and included line items.
There can be only one ConfigSet ID or Esimate ID on a purchase order.
The expanded/newly created lines echo back in the 3A4 Confirmation message and contain the
same PO Line Reference Number that was provided on the major line.
To use the ConfigSet ID based Config Ref functionality, partners need to provide:
A ConfigRef ID on the applicable product line item
The major line and all minor lines that have a dollar value applicable to the ConfigRef ID
If the partner provides an invalid ConfigRef ID, the order rejects.
The following conditions define a valid ConfigRef ID:
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 97 of 144
The ConfigRef is an existing ConfigSet ID (that is, the ConfigSet was already created).
All minor lines that have a dollar value on the ConfigSet (for example, CS123456) have been
provided and all have the ConfigRefId in the proprietary information field.
PIP Element#304: proprietaryInformation.FreeFormText
The quantity on the PO could be a multiple of the quantities on the ConfigSet.
If two major lines within the ConfigSet have the same minor item, the PO should include these
minor items as separate lines with the corresponding quantity defined in the ConfigSet; no
collapsing of lines is allowed. If two major lines within the ConfigSet have the same minor item,
the PO should include these minor items as separate lines with the corresponding quantity
defined in the ConfigSet; no collapsing of lines is allowed.
The number of lines listed with a particular ConfigRef should correspond with the same number
of lines provided on the PO other than the non-configurable spare lines
If any of the above validations fail, the order rejects. The expanded lines display on the PO
Confirmation message.
Known Limitations
ConfigRef and KitRef cannot be used together in a PO.
When using ConfigRef function, Line Level Proprietary Information for all configurations of a
config set, such as MOVE values (except getLatestSoftware), will have the value submitted with
the first configuration of the config set.
ConfigRef function does not work for Bundled Products.
There can be only one ConfigRef ID in a PO.
There cannot be multiple lines in the PO referenced to different ConfigSet IDs.
In case of 0$ majors which have priced minor’s in the ConfigSet, it is expected for the PO to
have the 0$ priced major explicitly on the PO, else system is unable to expand to a valid
configuration
Line ID and Parent Line ID are required for ConfigRef processing for all the priced minors and any
0 pirced majors on the saved configuration
ZPL is not supported on configSet ID based configRef orders and hence ZPL Country name value
pair is not expected on configRef orders
To use the Estimate ID based Config Ref functionality, partners need to provide:
A Estimate ID on the applicable product line item
The major line(s) and all its corresponding minor lines that have a dollar value applicable to the
Estimate ID
The structure of the major and minor line items
If the partner provides an invalid ConfigRef ID, the order rejects.
The following conditions define a valid ConfigRef ID:
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 98 of 144
The ConfigRef is an existing Esimate ID (that is, the Estimate was already created).
• Estimate ID starts and ends with an alpha
All minor lines that have a dollar value on the Estimate (for example, CS123456) have been
provided and all have the Esimate ID in the proprietary information field.
PIP Element#304: proprietaryInformation.FreeFormText
The quantity on the PO could be a multiple of the quantities on the Estimate.
If two major lines within the Estimate have the same minor item, the PO should include these
minor items as separate lines with the corresponding quantity defined in the Estimate; no
collapsing of lines is allowed.
The number of lines listed with a particular Estimate should correspond with the same number of
lines provided on the PO other than the non-configurable spare lines.
If any of the above validations fail, the order rejects. The expanded lines display on the PO
Confirmation message.
For Estimate based ConfigRef orders with/without standard, RNSD Deal Id, if there are any price
discrepancy between the system calculated net price and net price on PO, system will retain
price on the order, however the order processing is delayed since a task is created for Cisco
Customer Service ops for follow up.
If there is no discrepancy on the system calculated price and the price on the purchase order
(estimate price) then the order is autobooked and no warnings/tasks are raised.
Known Limitations
ConfigRef and KitRef cannot be used together in a PO.
When using ConfigRef function, Line Level Proprietary Information for all configurations of a
config set, such as MOVE values (except getLatestSoftware), will have the value submitted with
the first configuration of the estimate.
There can be only one Estimate ID in a PO.
There is no support for non-configurable spares coming along with a Estimate ID based
ConfigRef order. Such orders will be rejected.
In case of 0$ majors which have priced minor’s in the Estimate, it is expected for the PO to have
in the 0$ priced major explicitly on the PO, else system is unable to expand to a valid
configuration
Line ID and Parent Line ID are required for ConfigRef processing for all the priced minors and any
0 pirced majors on the saved estimate
ZPL is not supported on Estimate ID based configRef orders and hence ZPL Country name value
pair is not expected on configRef orders
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 99 of 144
Table 49: PIP V02.00.00 – Config Ref
No.
Cardinality
PIP Element
Notes
Field Length
304
0..1
| |--
proprietaryInformation.FreeForm
Text
Used to send multiple Cisco proprietary
information in <name>=<value> format.
Please use ‘|’ as a delimiter for multiple
values, and there should be no whitespace
around equal sign.
Name: ConfigRefId
Value: <Config Set Id>
Example: ‘ConfigRefId=CS123456’
7.5 Email Order Acknowledgments
Partners can specify an email address to receive an order acknowledgment. The partner should
enter the full email name, for example, name@company.com.
The optional nature of providing an email order acknowledgment is specified in the table that follows.
This fact is evidenced by a cardinality value of 0..1.
Table 50: PIP V02.00.00 - Email Order Acknowledgments
No.
Cardinality
PIP Element
Notes
Field Length
342
0..1
|--
proprietaryInformation.FreeForm
Text
Used to send multiple Cisco proprietary
information in <name>=<value> format. Use
‘|’ as a delimiter for multiple values, and no
whitespace should exist around equal sign.
Separate multiple email addresses by comma.
Name: OrderAckEmail
Example: OrderAckEmail=abc@Cisco.com,
xyz@Cisco.com
7.6 Order Contacts
Partners can provide the contact person name, phone number and email address if CISCO needs to
contact you regarding this purchase order. Cisco’s communications regarding the PO, would be sent
out to this/these order contacts.
Table 51: PIP V02.00.00 – Order Contacts
No.
Cardinality
PIP Element
Notes
Field Length
342
0..1
|--
proprietaryInformation.FreeForm
Text
Used to send multiple Cisco proprietary
information in <name>=<value> format. Use
‘|’ as a delimiter for multiple values, and no
whitespace should exist around equal sign.
Contact Info
Name
CHAR(50)
Telephone
number
CHAR(30)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 100 of 144
No.
Cardinality
PIP Element
Notes
Field Length
Name:
PurchaseOrder.ContactInformation.contactNa
me
PurchaseOrder.ContactInformation.telephone
Number
PurchaseOrder.ContactInformation.facsimileN
umber
PurchaseOrder.ContactInformation.EmailAddr
ess
E.g.
PurchaseOrder.ContactInformation.contactName
=John
Brown|PurchaseOrder.ContactInformation.teleph
oneNumber=408-926-
8651|PurchaseOrder.ContactInformation.facsimil
eNumber=407-926-
8651|PurchaseOrder.ContactInformation.EmailA
ddress=JohnBrown@CISCO.com
Facsimile
number
CHAR(30)
Email
address
CHAR(240)
Note – In case, the ContactInformation name value pairs are missing on the PO, then system will pick
the order contact information from the FromRole tags on the PO at header level
(
fromRole/PartnerRoleDescription/ContactInformation/contactName/FreeFormText,
fromRole/PartnerRoleDescription/ContactInformation/EmailAddress,
fromRole/ PartnerRoleDescription/ContactInformation/facsimileNumber,
fromRole/PartnerRoleDescription/ContactInformation/telephoneNumber)
7.7 Order Reference
If partners want to specify an internal code to monitor their order, they can specify an Order
Reference code. This Order reference is echoed back in the 3A6 Order status message as well as on
the POA as a free form text name value pair at header level
Reference: The value found in 3A6 Version 2.0 and Version 2.02 is:
ProductLineItem.proprietaryInformation.FreeFormText,
‘Cookie=<Order Reference submitted in PIP 3A4>’
The optional nature of specifying order reference is evidenced by a cardinality value of 0..1 I in the
table that follows.
The value on a 3A4 Purchase order acknowledgement is at:
PurchaseOrderConfirmation.PurchaseOrder.proprietaryInformation (tag421)
Table52: PIP 3A4 V02.00.00 - Order Reference on Order Request
No. Cardinality PIP Element Notes Field Length
342
0..1
|--
proprietaryInformation.FreeFor
mText
Used to send multiple Cisco proprietary
information in <name>=<value> format. Use
‘|’ as a delimiter for multiple values, and no
whitespace should exist around equal sign.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 101 of 144
7.8 Order Processing Notes
Partners can enter order processing instructions for the customer service specialist.
The optional nature of specifying order processing notes is evidenced by a cardinality value of 0..1 I
in the table that follows.
Table53: Order Processing Notes - Purchase Order
No. Cardinality
PIP Element Notes Field Length
63
0..1
|-- comments.FreeFormText
Order processing notes
Char(2000)
Note: Customer Service processes order processing notes. If an Order Processing Note is attached
to an order, the order is placed on hold. The hold must be removed before the order can be
fulfilled. Holds can result in delays to order processing.
7.9 Order Notes
Partners can enter order notes on the Purchase Order for their own references. Cisco would not take
any action on these but these can be viewed on the Order View status screen.
The optional nature of specifying order notes is evidenced by a cardinality value of 0..1 I in the table
that follows.
Table 54: Order Processing Notes - Purchase Order
No. Cardinality
PIP Element Notes Field Length
63
0..1
|-- comments.FreeFormText
Key value pair for specifying Order Notes Text
OrderNotes=<Customer Order Notes>
Char(2000)
Note: Order Processing Notes and Order Notes are utilizing the same PIP element in PO. The
derivation logic would be as follows:
• System checks if the string “OrderNotes=” is present. If yes, then system will consider text after
the string as Order Notes and text before the string as Order Processing notes
If there is no string ‘OrderNotes=’ then system will consider all the text as Order Processing Notes.
7.10 SWIFT and eDelivery Products
Software Infrastructure and Fulfillment Technology (SWIFT) enables e-fulfillment capabilities for initial
purchase and support upgrades with a long-term focus on the enablement of electronic channel
fulfillment models.
When partners submit orders for a SWIFT or eDelivery product, they can provide one or more email
addresses (comma separated) used to receive a URL and a license key for the products. Partners
can provide the email address under the “eDeliveryemail” key/value pair at the Line level.
Name: OrderRef
Example: OrderRef=12345
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 102 of 144
If the SWIFT email address is not provided, the eDelivery Application has the logic to internally derive
the delivery email based on the company accounts set up.
The system shall identify the possible delivery types for an SKU being ordered and use the following
defaulting logic. Delivery Method is not a new attribute on the XML order.
If a SKUs only compatible delivery method is “Physical”, the delivery method defaults to physical.
(Covers Regular SKU Scenario)
If a SKUs only compatible delivery method is “Electronic”, the delivery method defaults to
electronic. (Covers L-SKU Scenario).
If a “Single SKU” can be ordered both electronically and physically, the delivery method is
retrieved from the partner’s profile (Covers the Single SKU Scenario). If a delivery preference is
not specified the order is rejected.
For SKUs that can be delivered electronically, the SKU is delivered at the email address specified
in the “eDeliveryemail” email address tag field.
The table that follows indicates the optional nature of SWIFT and eDelivery of products. This fact is
evidenced by a cardinality value of 0..1.
Table 55: PIP 3A4 V02.00.00 - Swift and eDelivery Products
No. Card
PIP Element Notes
Field
Length
304
0..1
|--
proprietaryInformation.FreeFormText
Multiple email ids can be provided by using
comma (“,”) as the delimiter.
Example:
eDeliveryemail=abc@company.com,xyz@co
mpany.com
150
7.11 Flexible Service Start Delay (FSSD)
FSSD allows partners to order Product + Service in CCW and automatically delay service start up to
60 days after ship date. FSSD is being released as Limited Availability which will allow Cisco to
evaluate business impact.
In order to indicate a delay period, partners can send in a new name value pair
<flexibleServiceStartDelay> will be sent for every service/subscription line at line level or kitRef Line.
For an initial purchase of service (both product & service on same PO or PO coming with Service
lines which are covering products that are not yet shipped), system does not expect the Service Start
Date to be present on the PO and if this is present, system will ignore it. Service Start Date in these
scenarios are based on Product shipment unless the user qualifies for FSSD and has provided the
value in the PO.
Table56: PIP 3A4 V02.00.00 – Flexible Service Start Delay
No. Card
PIP Element Notes
Field
Length
Used to send multiple Cisco proprietary
information in <name>=<value> format. Use
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 103 of 144
No. Card
PIP Element Notes
Field
Length
304
0..1
|--
proprietaryInformation.FreeFormText
‘|’ as a delimiter for multiple values, and no
whitespace should exist around equal sign.
Example: flexibleServiceStartDelay =
numeric
value 1-60
The following validations are enabled in regards to processing orders with line having FSSD –
Ineligibile Partner/Distributor placing orders
with FSSD(if the Service level Combination are
not valid for FSSD)
Order rejected
The FSSD delay for the Technical services and
subscriptions within a configuration should be
SAME,i.e only one unique value of FSSD should
be allowed per configuration/ATO. Orders with
different FSSD per configuration/ATO
Order rejected
FSSD is not applicable on service only orders or
partial service orders. FSSD on service only or
partial service orders
Order rejected
FSSD value must be numeric. PO line having
non-numeric FSSD value
Order rejected
7.12 Cisco Capital Pre-Owned Equipment Orders
Cisco Capital Pre-Owned Equipment is an ACT-approved initiative with the goal of integrating the
selling and fulfillment of Cisco pre-owned equipment into Cisco standard processes and tools. The
Cisco Capital Remarketing organization is responsible for the remanufacture, remarketing and resale
of Cisco Certified Refurbished Equipment.
The selling and fulfillment of Pre-Owned Equipment was outsourced to a 3rd party vendor ModusLink
until Q3 FY14 after which the Pre-sale and Ordering process was moved to Cisco Commerce
Workspace. The fulfillment, returns pick pack and shipment is still done via Modus Link.
Enabling B2B ordering for refurbished equipment will reduce manual data entry for these partners
who have previously submitted refurbished orders via fax or did manual data entry.
Partners must accept the RoHS Terms and Conditions while submitting the purchase order with
refurbished SKU(s). If the terms and conditions are not accepted, system would reject the order.
Partner need to pass value “Y” or “N” in the new “RoHS_Terms” Key/Value Pair. If the purchase
order has refurbished SKU(s) and value passed for this attribute is N or no value is passed for this
attribute, then order will be rejected.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 104 of 144
The table that follows indicates the optional nature of RoHS Terms and Conditions key/value pair.
This fact is evidenced by a cardinality value of 0..1.
Table 64: PIP 3A4 V02.00.00 – ROHS Terms key/value pair for refurbished SKU(s)
No. Card
PIP Element Notes
Field
Length
342
0..1
|--
proprietaryInformation.FreeFormText
Will be populated at Header level
"PurchaseOrder/proprietaryInformation/FreeFo
rmText/RoHS_Terms" Key/Value Pair
Name: RoHS_Terms
Example:
RoHS_Terms =Y
OR
RoHS_Terms =N
1
7.13 Cisco Software Simplification - Smart Software Licensing
In order to have one standard software license platform across Cisco, Smart Licensing is being
enabled via B2B as part of Q2FY15 release. Instead of using PAKs or License Files, Smart Licensing
establishes a pool of Software Licenses or Entitlements that can be used across the entire customer
in a flexible and automated manner. All Smart products will self-register themselves upon
installation/configuration, removing the need for any manual intervention on the part of the installer.
Licenses are not tied directly to specific installation. Smart Licenses can be managed in the Cisco
Smart Software Manager.
With the proposed Q2 solution, Partners will have to Enable Smart Account/Virtual Account
Assignment in B2B Orders.
Partners need to pass Holding Smart/Virtual Account and Customer Smart/Virtual Account in
separate fields at the order header level & Customer Smart/Virtual Account at the order line level.
New optional attributes to capture Smart Account details
• Header level Smart Account/Virtual Account information
o Holding Smart Account Domain ID
o Holding Virtual Account Name
o Customer Smart Account Domain ID
o Customer Virtual Account Name
• Major Line level Smart Account/Virtual Account information
o Customer Smart Account Domain ID
o Customer Virtual Account Name
If the partner does not pass any Smart / Virtual account details in the purchase order request, the
default Holding Account details set up for the partner in the user profile will be used while validating
the purchase order request.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 105 of 144
Post Q1FY17, smart account will be defaulted from quote line if a magic key is sent, else from the
quote header for quote/deal based orders if any available. If none then the default holding account
will be used.
Refer to Appendix K
for more details about the Smart & Virtual Accounts.
Manual Processing details in the event Smart/Holding Account is missing
B2B orders with Smart SKUs will be submitted as-is. There will be no way for a B2B user to
enter Smart Account information at the time of placing the order.
B2B order will be booked and processed
A daily report will be sent to an internal SWSC team listing all B2B orders to date that require
Smart Account assignment.
SWSC team will use CCW to create/assign a Smart Account to B2B orders.
Table 65: PIP 3A4 V02.00.00 – Header Level Smart Account key/value pair for Smart License
SKUs
No. Card
PIP Element Notes
Field
Length
342
0..1
|--
proprietaryInformation.FreeFormText
Holding Smart Account at Header Level
Will be populated at Header level
"PurchaseOrder/proprietaryInformation/FreeFo
rmText/HoldingSmartAccountDomainID"
Key/Value Pair.
Example:
HoldingSmartAccountDomainID = IBM.com
255
342
0..1
|--
proprietaryInformation.FreeFormText
Holding Virtual Account Name at Header Level
Will be populated at Header level
"PurchaseOrder/proprietaryInformation/FreeFo
rmText/HoldingVirtualAccountName"
Key/Value Pair.
Example:
HoldingVirtualAccountName = IBM.com Sales
Dept
255
342
0..1
|--
proprietaryInformation.FreeFormText
Customer Smart Account at Header Level
Will be populated at Header level
"PurchaseOrder/proprietaryInformation/FreeFo
rmText/ CustomerSmartAccountDomainID "
Key/Value Pair.
Example:
CustomerSmartAccountDomainID = BigU.edu
255
342
0..1
|--
proprietaryInformation.FreeFormText
Customer Virtual Account Name at Header
Level
Will be populated at Header level
"PurchaseOrder/proprietaryInformation/FreeFo
255
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 106 of 144
No. Card
PIP Element Notes
Field
Length
rmText/
CustomerVirtualAccountName "
Key/Value Pair.
Example:
CustomerVirtualAccountName = BigU.edu
Physics Dept
Table 66: PIP 3A4 V02.00.00 – Line Level Customer Smart Account key/value pair for Smart
License SKUs
No. Card
PIP Element Notes
Field
Length
304
0..1
|--
proprietaryInformation.FreeFormText
Customer Smart Account at Line Level
Will be populated at line level at Line level
"PurchaseOrder/ProductLineItem/proprietaryIn
formation/Freeformtext/CustomerSmartAccoun
tDomainID" Key/Value Pair.
Example:
CustomerSmartAccountDomainID = BigU.edu
255
304
0..1
|--
proprietaryInformation.FreeFormText
Customer Virtual Account Name at Line Level
Will be populated at Line level
"PurchaseOrder/ProductLineItem/proprietaryIn
formation/Freeformtext/CustomerVirtualAccoun
tName" Key/Value Pair.
Example:
CustomerVirtualAccountName = BigU.edu
Physics Dept
255
7.14 Ultimate Consignee Address and Consignee Type
This change is for urgent US federal compliance requirement, which will take effect Oct 2nd, 2014, to
capture the Ultimate Consignee address (existing Automated Export System [AES] filing requirement)
at order entry for all orders with at least one shippable goods line (physical shipment line) shipping
out of US. Consignee Address is required for each Ship to on an order.
Partners need to send the Ultimate Consignee Address and Consignee Type in the purchase order
request with at least one shippable goods line (physical shipment line).
NOTE: As of Q2Fy15 release, these are not mandatory to be passed on the purchase order request.
System will default Ship To address to Ultimate Consignee address and Consignee type as ‘Reseller’
if the purchase order request does not have these details.
In future release (TBD), business rules would be set up in the system to validate and mandate Ultimate
Consignee Address and Consignee Type while submitting purchase order requests. This IG will be
updated as and when these business rules are set up in the system.
Ultimate Consignee Address will be validated against Cisco Customer Registry. It will be handled like
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 107 of 144
any other address creation/validation through CPAM integration, especially during address creation.
Partner needs to pass one of the four valid Ultimate Consignee Type value (highlighted within the
quotes) in the purchase order request based on who will be the ultimate consignee of the order.
• “Direct Consumer” – If the Ultimate Consignee is a non-government institution, enterprise,
or company that will consume or use the exported good as a consumable, for its own internal
processes, as an input to the production.
• “Government Entity” – If the Ultimate Consignee is a government-owned or government-
controlled agency, institution, enterprise, or company.
• “Reseller” – If the Ultimate Consignee is a non-government reseller, retailer, wholesaler,
distributor, distribution center or trading company.
• “Other/Unknown” – If the Ultimate Consignee is an entity that does not fall under one of the
other three ultimate consignee types or whose type is not known at the time of export.
There will be delay in the order processing and booking for the below scenarios
1) If Ultimate Consignee Address is not valid
2) If Ultimate Consignee Type is not valid
3) If Ultimate Consignee Address is provided and Ultimate Consignee Type is not provided in
the purchase order request.
4) If Ultimate Consignee Type is provided and Ultimate Consignee Address is not provided in
the purchase order request.
Table 67: PIP 3A4 V02.00.00 – Line Level Ultimate Consignee Address and Type key/value pairs
No. Card
PIP Element Notes
Field
Length
304
0..1
|--
proprietaryInformation.FreeFormText
Ultimate Consignee Address elements: Below
Key/Value pairs are enabled at Line level.
"PurchaseOrder/ProductLineItem/proprietaryIn
formation/Freeformtext/UConsigneeName".
"PurchaseOrder/ProductLineItem/proprietaryIn
formation/Freeformtext/UConsigneeLine1".
"PurchaseOrder/ProductLineItem/proprietaryIn
formation/Freeformtext/UConsigneeLine2" –
Optional, this can be used for additional details
if not captured in UConsigneeLine1.
"PurchaseOrder/ProductLineItem/proprietaryIn
formation/Freeformtext/UConsigneeLine3" –
Optional, this can be used for additional details
if not captured in UConsigneeLine2.
"PurchaseOrder/ProductLineItem/proprietaryIn
formation/Freeformtext/UConsigneeCity".
"PurchaseOrder/ProductLineItem/proprietaryIn
formation/Freeformtext/UConsigneeState".
"PurchaseOrder/ProductLineItem/proprietaryIn
formation/Freeformtext/UConsigneeCountryC
ode
".
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 108 of 144
No. Card
PIP Element Notes
Field
Length
"PurchaseOrder/ProductLineItem/proprietaryIn
formation/Freeformtext/UConsigneeZipCode".
Example:
UConsigneeName=ABC Inc
|UConsigneeLine1=123 W TASMAN
DR|UConsigneeLine2=FIRST
FLOOR|UConsigneeLine3=Cubicle#123|UConsi
gneeCity=SAN
JOSE|UConsigneeState=CA|UConsigneeCount
ryCode=US|UConsigneeZipCode=95134
NOTE: Partner can pass the below key/value
pair if they know that the Ship To Address is
the Ultimate Consignee Address
UConsigneeName=Same_As_Ship_To
Based on this value in the purchase order
request, system will default the Ship To
address as the Ultimate Consignee Address. If
partner is using this input format, the Ultimate
Consignee Type still needs to be passed in the
purchase order request.
304
0..1
|--
proprietaryInformation.FreeFormText
Ultimate Consignee Type: Below Key/Value
pair is enabled at Line level.
"PurchaseOrder/ProductLineItem/proprietaryIn
formation/Freeformtext/UConsigneeType".
Example:
UConsigneeType=Direct Consumer
OR
UConsigneeType=Government Entity
OR
UConsigneeType=Reseller
OR
UConsigneeType=Other/Unknown
Table 68: PIP 3A4 V02.00.00 – Header Level Ultimate Consignee Address and Type key/value
pairs
No. Card
PIP Element Notes
Field
Length
342
0..1
|--
proprietaryInformation.FreeFormText
Ultimate Consignee Address and Type
elements: Below Key/Value pairs are enabled
at Header level.
"PurchaseOrder/proprietaryInformation/FreeFo
rmText/
UConsigneeName
".
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 109 of 144
No. Card
PIP Element Notes
Field
Length
"PurchaseOrder/proprietaryInformation/FreeFo
rmText/UConsigneeLine1".
"PurchaseOrder/proprietaryInformation/FreeFo
rmText/UConsigneeLine2" –
Optional, this can
be used for additional details if not captured in
UConsigneeLine1.
"PurchaseOrder/proprietaryInformation/FreeFo
rmText/UConsigneeLine3" –
Optional, this can
be used for additional details if not captured in
UConsigneeLine2.
"PurchaseOrder/proprietaryInformation/FreeFo
rmText/UConsigneeCity".
"PurchaseOrder/proprietaryInformation/FreeFo
rmText/UConsigneeState".
"PurchaseOrder/proprietaryInformation/FreeFo
rmText/UConsigneeCountryCode".
"PurchaseOrder/proprietaryInformation/FreeFo
rmText/UConsigneeZipCode".
Example:
UConsigneeName=ABC Inc
|UConsigneeLine1=123 W TASMAN
DR|UConsigneeLine2=FIRST
FLOOR|UConsigneeLine3=cubicle#123|UConsi
gneeCity=SAN
JOSE|UConsigneeState=CA|UConsigneeCount
ryCode=US|UConsigneeZipCode=95134
NOTE: Partner can pass the below key/value
pair if they know that the Ship To Address is
the Ultimate Consignee Address
UConsigneeName=Same_As_Ship_To
Based on this value in the purchase order
request, system will default the Ship To
address as the Ultimate Consignee Address. If
partner is using this input format, the Ultimate
Consignee Type still needs to be passed in the
purchase order request.
342
0..1
|--
proprietaryInformation.FreeFormText
Ultimate Consignee Type: Below Key/Value
pair is enabled at Line level.
"PurchaseOrder/proprietaryInformation/FreeFo
rmText/UConsigneeType".
Example:
UConsigneeType=Direct Consumer
OR
UConsigneeType= Government Entity
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 110 of 144
No. Card
PIP Element Notes
Field
Length
OR
UConsigneeType=Reseller
OR
UConsigneeType= Other/Unknown
7.15 Co-term of Initial Purchase SWSS Technical Service
In CCW, Co-terming functionality is currently supported for Software Content Subscriptions (T&C) at point of sale
and renewals. Some of the partners need a capability to co-term the service purchase of Technical Services during
initial purchase, and align the service end date to an existing Service Contract. Currently partners pass the duration
for the Technical Services during initial purchase.
With the roll out the SWSS (Software Support Service) End Date Alignment scope in Q4Fy15
Release, Partner would have the capability to pass Start Date + End Date or Start Date + Duration
combination for Initial Purchase Technical Services (certain End Date Alignment Eligible services)
along with the existing option of passing only the Duration. For the initial release, selective SWSS
GSPs will be qualified for “End Date alignment”. This should be extendable to additional services
(future release). Eligible Services for P-line End Date alignment will be identified by a SPA/Item
attribute “userSpecifiedStartDate” (values are “Y” or “N”).
Table 69: PIP 3A4 Version 02.00.00 – Service Start date, Service End date and Service Duration
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 111 of 144
No.
Cardinalit
y
PIP Element
Notes
Field Length
304
0..1
| |--
proprietaryInformation.FreeForm
Text
Used to send multiple Cisco proprietary
information in <name>=<value> format. Use
‘|’ as a delimiter for multiple values, and no
whitespace should exist around equal sign.
Values are:
Name: ContractDuration
Name: ContractNumber
Name: ContractStartDate
Name: ContractEndDate
Example: Order Service with existing
contract
ContractStartDate=20150712Z
|ContractEndDate=20170701Z|ContractNum
ber=12384636|
Example: Order Service with existing
contract
ContractNumber=12384636|ContractStartDa
te=20050112Z| ContractDuration=12|
Maximum Start Date: Upto 60 days from date of PO submission
Minimum Start Date: Current Date of PO submission + Product OffSet (for End date Alignment enabled
SWSS Technical Service SKUs). Product Offset value is currently set as 7 in ItemHub for all the End Date
Alignment enabled Technical Service SKUs.
Maximum End Date: 60 Months from Start Date minus 1 day
Duration: 1 day to 60 months (for End date Alignment enabled SWSS Technical Service SKUs)
If End Date is present for an initial purchase service, system will ignore the duration (if any) passed in the
PO request. System would calculate and store duration based on the Start Date and End Date.
If End Date is present without a Start Date for an initial purchase service, then the system should stamp
the Start Date as Current date of PO Submission + ProductOffSet. The “ProductOffSet” value would be set
up in
SPA/ItemHub for these SKUs with value = 7 which is to accommodate the Product Shipment time.
This “ProductOffSet” value will ensure that the Service would not be started prior to the Product
shipment. Any delay in the manufacturing / shipment of product would result in further delay of the
Actual Service Start Date.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 112 of 144
For the End Date Alignment eligible Initial Purchase technical service SKUs, if Partner has provided FSSD
value along with Start Date and/or End Date, then system will ignore the FSSD value.
The CCW Config service would validate the Start Date + End Date or Start Date + Duration value provided
for the SKUs and if the validation fails, the PO will be rejected with appropriate message.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 113 of 144
8 Product and Order Price
8.1 Currency Code
The currency code is the three-character ISO code for the global currency (for example, ‘USD’ for US
dollars).
With 3A4 XML orders, the currency of the given Price List Identifier determines the PO currency for
both PO amount and product price. See the subsection that follows.
8.2 Price List Identifier
Cisco assigns Price List to partners with which they can place orders. If the Price List sent in PIP 3A4
PO Request is not in the Partner’s Cisco Profile, entitlement will fail. The PO Request will reject and
an error will return in the 3A4 PO Confirmation.
Partners have to identify the price list used for an order. This allows Cisco to validate the prices.
Partners should contact their B2B Project manager for the Price List ID for the price lists they are
using.
The Price List Identifier can also be obtained from the output of the AcquireQuote Web Service.
Cisco rejects 3A4 XML orders if a price list id is missing or an invalid price list id is given.
Table 70: PIP 3A4 Version 02.00.00 for Price List Identifier
No. Cardinality PIP Element Notes Field Length
342 0..1
|--
proprietaryInformation.FreeFor
mText
Used to send multiple Cisco proprietary
information in <name>=<value> format.
Use ‘|’ as a delimiter for multiple values,
and no whitespace should exist around
equal sign.
Name: PriceListIdentifier
Example: PriceListIdentifier=GLUS
Char
8.3 Product Price
Set the MonetaryAmount field to the total extended price of the ProductLineItem. This is the total
price for the product line item, and includes the discount and the quantity.
Discounted Price = List Price * (1-Discount)
Monetary Amount = Discounted Price * Ordered Quantity
Note: The product list price is published in the catalog using the 2A1 Product Information
Notification Message Guideline. The following three values are required to look up a price in price
catalog:
PriceListIdentifier in [PurchaseOrder.proprietaryInformation.FreeFormText] – Cisco price list
identifier
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 114 of 144
Cisco Part Number in
ProductIdentification.PartnerProductIdentification.ProprietaryProductIdentifier – Cisco part
number. For example, Cisco2501
Product List Price in listPrice.FinancialAmount.MonetaryAmount
Note: The discount is not published in the price catalog. The partner’s Cisco account manager can
provide the partner with the discount information.
A PO having whole sale price list and if the line monetary amount is not matching system calculated
Net Price for that line will result in PO rejection.
The table that follows indicates the optional nature of ProductPrice. This fact is evidenced by a
cardinality value of 0..1.
Table 71: PIP 3A4 Version 02.00.00 - Product Price
No. Cardinality
PIP Element Notes Field Length
339 0..1
| |--
totalLineItemAmount.FinancialAmo
unt
Required Tag N/A
340 1 | | |--GlobalCurrencyCode
Enter three-character ISO code for
global currency. Although this is a
required RosettaNet field, Cisco does
not need this field to determine currency
of the order. Cisco uses Price List in
proprietaryInformation.FreeFormText to
determine currency.
Example: “USD” for US dollars.
N/A
341 1 | | |--MonetaryAmount
Enter total price for line.
Do not enter currency symbol (for
example, “$”) or thousands separator
(“,”).
Example: 12000.25
NUMBER
9(13)V9(5)
8.4 PO Amount
Partners are not required to send the PO Amount and discount information to Cisco for 3A4 XML
orders. Cisco calculates the PO Amount by adding all of the MonetaryAmounts for the product lines
for a 3A4-XML order.
If the price format is not valid, the order rejects. For example, if the price field contains non-numeric
characters such as abc.xx, the order rejects.
The table that follows indicates the optional nature of PO Amount. This fact is evidenced by a
cardinality value of 0..1.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 115 of 144
Table 72: PIP 3A4 Version 02.00.00 for PO Amount
No. Cardinality
PIP Element Notes Field Length
395 0..1
|--
totalAmount.FinancialAmount
Tag N/A
396 1 | |--GlobalCurrencyCode
Three-character ISO code for global
currency.
Example
:
“USD” for US dollars.
N/A
397 1 | |--MonetaryAmount
Total price for PO.
Do not enter currency symbol (for
example, “$”) or thousands separator (“,”).
Example: 12000.25
NUMBER
9(13)V9(5)
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 116 of 144
9 Tax Exemption
9.1 Tax Exempt Status
Partners should provide the tax exempt status for Australian, Canadian, and US 3A4 XML orders.
If the order is tax exempt, prior registration of the tax exemption certificate in Cisco’s ERP system is
expected. The billing customer and shipping address identifies the order as Australian, Canadian, or
from the US.
9.1.1 Canadian Orders
If isTaxExempt.AffirmationIndicator = ‘Yes”, then the order is NOT taxable.
If isTaxExempt.AffirmationIndicator = “NO”, then the Order is taxable.
Partner can provide the Canadian Tax code based on the shipping province specified in the shipping
address in ProprietaryInformation.
The table that follows indicates the optional nature of tax exemption for Candadian orders. This fact
is evidenced by a cardinality value of 0..1.
Table 73: PIP 3A4 Version 02.00.00 for Canadian Orders
No. Cardinality
PIP Element Notes Field Length
342 0..1
|--
proprietaryInformation.FreeForm
Text
Use ‘|’ as a delimiter for multiple values
and no whitespace should exist between
Name and Value.
Canadian Tax Code
<proprietaryInformation><FreeFormText>T
axCode=12345</proprietaryInformation></
FreeFormText>
If a null value is provided, a warning message is generated, and the order is considered as taxable.
If the tax code is not provided or is invalid, it defaults based on the shipping province provided. A
warning message is generated.
9.1.2 Australian Orders
Because all Australian orders are taxable, the partner must provide “No” to the
isTaxExempt.AffirmationIndicator.
9.1.3 US Orders
If isTaxExempt.AffirmationIndicator = “Yes”, then the order is NOT taxable.
Cisco will attempt to identify the tax exemption certificate number for the partner and apply the tax
exemption appropriately. If Cisco is unable to find the tax exemption information for the partner, a
warning message issues to the partner as part of the PO Acceptance document.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 117 of 144
If isTaxExempt.AffirmationIndicator = “No”, then the Order is taxable. Cisco will automatically apply
the appropriate taxes (based on the state specified in the shipping address).
If a null value is provided, a warning message generates as follows: “The order is considered as
taxable”.
The table that follows indicates the optional nature of tax exemption for orders shipped within the US.
This fact is evidenced by a cardinality value of 0..1.
Table 74: PIP 3A4 Version 02.00.00 for US Orders
No.
Cardinality
PIP Element
Notes
Field Length
390
0..1
|-- TaxExemptStatus
N/A
391 1
| |--
isTaxExempt.AffirmationIndicato
r
Indicates if order is taxable. Partner may
provide a value of “yes” or “no” (fully
spelled out).
Cisco looks at these field and
GlobalTaxExemptionCode to determine if
order should be taxed. For example, Cisco
does not add tax to “Resale” orders if a
valid resale certificate is on file with Cisco.
Predefined
Values
393 1 | | |-- GlobalTaxExemptionCode
Indicates if order type is ‘Resale’. Valid
Cisco values are:
“Exempt – for resale”
“Exempt – not for resale”
394 1
| | |--
taxExemptionCertificationIdentifi
er.ProprietaryReferenceIdentifie
r
CHAR(255)
9.2 Taxability Derivation
Cisco derives a taxability flag based on the values provided for GlobalPurchaseOrderTypeCode, Tax
Exemption Status, and Global Tax Exemption Code.
The following explains the derivation of the Taxability Flag.
Table 75: Derivation of the Taxability Flag
Tax Exempt
Affirmation
Indicator
Taxable Flag in
the Cart
Global Tax
Exemption
Code
Global PO
Type Code
Taxability Value
Tax
Handling
Flag
(same as
set for
CCW
orders)
Blank Yes
Necessarily
blank as per
DTD
Not
considered
Internal Use R
No Yes Not considered
Not
considered
Internal Use R
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 118 of 144
Tax Exempt
Affirmation
Indicator
Taxable Flag in
the Cart
Global Tax
Exemption
Code
Global PO
Type Code
Taxability Value
Tax
Handling
Flag
(same as
set for
CCW
orders)
Yes No
Exempt – Not
For Resale
Not
considered
State/Federal or
Direct Pay Permit
Exemptions
S or E
Yes No
Exempt – For
Resale
Not
considered
Resale S or E
Yes No
Not Exempt –
Not For Resale
Not
considered
Reject the order
Yes No
Not Exempt –
For Resale
Not
considered
Reject the order
Yes
No
Blank
Standard
Resale
S or E
Yes
No
Blank
Replenishment
Resale
S or E
Yes No Blank Service Internal Use R
Yes
No
Blank
Site
Internal Use
R
Yes No Blank
Consigned
order
Internal Use R
Yes
No
Blank
Evaluation
Internal Use
R
Yes
No
Blank
Sample
Internal Use
R
Note: A Tax Handling Flag is set downstream based on <Taxability> attribute.
When <Taxability> is “Internal Use”, there is no check for tax certification on file and the Tax
Handling Flag is set to “R”.
When <Taxability> is “Resale” or “State/Federal Exemption/Direct Pay”, a check is done to
ensure Tax Certification exists on file.
- If the certification exists, the Tax Handling Flag is set to “S” or “E”
- If the certification does not exist, the Customer Service task is raised.
Note – In case of Brazil orders, taxability derivation is changed as of Q4FY14. Please refer to section
6.12 for more details.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 119 of 144
10 Integration with CCW Quoting and
Configuration Solutions
The following process flow steps explain the three basic integration flows with CCW Quoting and
Configuration Solutions via Punchout.
10.1 Tier Partner Quoting and Ordering with a Deal Id – Punchout
Flow
1. Partner system receives the Cisco catalog (with Cisco products and services and associated List
Price information) through a bootstrap with Cisco.
2. Partner system engineer creates configuration in CCW UI.
3. Partner system engineer shares ConfigSet with the Cisco account manager.
4. Cisco account manager creates a Quote in CCW UI by importing the Shared ConfigSet.
5. Cisco account manager requests Non Standard discounts. The Quote is submitted for offline
approval.
6. Upon approval, the system notifies the partner contact of the DealId.
7. Partner contact provides the Deal ID to the partner procurement user.
8. Partner procurement user punches in to CCW quoting and acquires the Shared DealId/Quote ID.
9. Partner procurement user transfers the Quote (With Config and Pricing Details) to their system.
10. Partner systems internal approval workflow kicks off.
11. Upon approval, procurement user adds order specific details to the configuration and submits a
B2B 3A4 Order to Cisco. The order will include the Deal ID.
10.1.1 Tier Partner Quoting and Ordering with Deal ID (Quick Quote) –
Punch Out Flow
1. Partner system receives the Cisco catalog (with Cisco products and services and associated List
Price information) through a bootstrap with Cisco.
2. Partner system engineer creates configuration in the CCW UI.
3. Partner system engineer shares ConfigSet with Partner Procurement team.
4. Partner procurement user punches in to CCW Quoting and starts Quick Quote flow.
5. Partner procurement user enters all partner and end customer details on the Quote and imports
the BOM from the Shared ConfigSet.
6. Partner procurement user attaches service SKUs and after completing Quote info, submits the
quote for approval.
7. The Quote is automatically approved. Partner system engineer transfers the Quote details to their
system.
8. Partner systems internal approval workflow kicks off.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 120 of 144
9. Upon approval, procurement user adds order specific details to the configuration and submits a
B2B 3A4 XML Order to Cisco. The order will include the Deal ID.
10.1.2 Tier Partner Quoting and Ordering – Standalone Order (no Deal ID) –
Punch Out Flow
1. Partner system receives Cisco Catalog and pricing information through bootstrap with Cisco
products and services along with List Price.
2. Partner system engineer creates configuration in CCW UI.
3. Partner system engineer shares ConfigSet with Partner Procurement team.
4. Partner procurement user punches in to CCW Quoting and initiates Quick Quote Creation Flow.
5. Partner procurement user creates quote with only End Customer Country details and imports
BOM from the Shared ConfigSet.
6. Partner procurement user attaches service and system calculates Net Price per the partner’s
contractual discount.
7. Partner procurement user transfers the configuration and pricing details to their system.
8. No Deal ID transfers to the partner system. Only configuration with Contractual Discount Net Price
and other partner details transfer.
9. Partner procurement user submits B2B 3A4 order with this transferred information and after
adding other order specific details.
Partners will utilize the Cisco quoting and configuration web services to create their quotes and
configuration. Partners can punch out and access the Cisco Configuration UI via the Acquire Quote
Web Service.
The output will be transferred via a TransferCart(TransferQuote) and Save to Disk to the partner
systems.
The Deal ID, Line ID, Parent Line ID and CiscoProductReference and other information will be
obtainable as part of the output from the services.
The following process flow diagrams describe the process leading to the creation of a 3A4 XML
order.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 121 of 144
10.2 Procurement User Creates a Purchase Order in Partner’s
Internal System
Figure 4: Procurement User Creates a Purchase Order in Partner’s Internal System
Partner creates and acquires quote, deal, and configuration via the AcquireQuote or TransferQuote
Web Service and then punches out to the Configurations Web Services.
Figure 5: Partner Creates and Acquires Quote, Deal, and Configuration via the AcquireQuote or
TransferQuote Web Service and Punches Out to Configurations Web Services
DealId of approved quote should be referenced in the
purchase order. For “Not Submitted” transferred/
Acquired Quote (via WS), Procurement user would apply
Trade Ins.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 122 of 144
Figure 6: Partner System Sends a 3A4 XML Order to NG00
10.2.1 Product References
To view a sample output from the TransferQuote WebService, please refer to Appendix B: Sample
Output from TransferQuote WebService.
The LineId, Parent LineId, and CiscoProductReference fields are sent in the 3A4 XML
proprietaryInformation/FreeFormText tag at line level as a semicolon separated name=value pair with
the name as ConfigurationInformation, as in the example that follows.
Format - <FreeFormText>ConfigurationInformation=<LineID>;<Parent
LineID>;<Cisco Product reference Code>|*</FreeFormText>Example -
<FreeFormText>ConfigurationInformation=1.0;0; 716336378</FreeFormText>
With the introduction of CBOM WS – Configuration path (CP), selection flag (SF), redundancy flag
(RF) and default flag (DF) values are sent at a line level for each of the lines on the configuration.
These values can be sent on the order request, if or when the Cisco Product Reference is not
available. These values (CP, SF, RF, DF) can be sent in the proprietary information field in the below
format. Note these values can be preceded with CiscoProductReference in which case
CiscoProductReference takes priority and CP, SF, RF and DF on the order requestare ignored, since
system derives these values internally with the CiscoProductReferenceAppendix G provides more
information in regards to Redundancy and default flags
<FreeFormText>ConfigurationInformation=<LineID>;<Parent LineID>;<Cisco Product
reference Code>|*| ConfigurationPath= “<<Config Path value>>”; ;“<<Selection
Flag value>>”|*| RedundantFlag=SELECTED or REDUNDANT| DefaultFlag = Yes Or
No</FreeFormText>
Sample:
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 123 of 144
<FreeFormText>ConfigurationInformation= <line ID>;<Parent Line
ID>;|ConfigurationPath= “UNITY-MODEL:UNITY_USER_OPTIONS|UNITYU5-USR-DC”; “1”;
“USER”|</FreeFormText>
Combinations samples of how the ConfigurationInformation can be sent –
1. LineID;ParentLineId;CiscoProductReferenceCode
2. LineID;CiscoProductReferenceCode
3. With no ConfigrationInformation, in this case the system would always qualify this for
Best guess logic
Note – Numerics are expected in Line ID and Parent Line ID (decimal numbers included). However a
text string/alpha numeric string in line Id or parent line ID results in an error.
Note – Line Id and Parent Line ID are required on the PO for processing.
10.2.2 Configuration Check
When a PO is sent to Cisco, Cisco re-validates the configuration. Sometimes, configurations may no
longer be valid, even though they were created using Cisco Configuration Web Services. This can
happen for older configurations, because configuration rules change over time. When configurations
are rejected, partners should fix the configuration using the Cisco Configuration Web Services.
10.2.3 Included Items
Included items are options that are automatically included in the Bill of Materials for a configurable
part whether they were selected or not. A price of $0.00 must be sent for all items for which the
Configuration tool displays a zero price.
Note: Some of these products may have a non-zero price in the catalog.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 124 of 144
11 Purchase Order Confirmation
PIP 3A4 Purchase Order Confirmation Header level
No.
Cardinalit
y
Header Element Mapping Notes
Sample
Values
Lengt
h
3 1
fromRole.PartnerDescription.
ContactInformation.contactN
ame.FreeFromText
Name of the contact person
4 1
fromRole.PartnerDescription.
ContactInformation.EmailAdd
ress
Email address of the contact.
In the case of PO not having
this value is it defaulted to itds-
ebis-support@cisco.com
ic-
support@cisc
o.com
5 0..1
fromRole.PartnerDescription.
ContactInformation.facsimilie
Number.CommunicationsNu
mber
Fax number of the contact. Not
sent on POA
6 1
fromRole.PartnerDescription.
ContactInformation.telephone
Number.CommunicationsNu
mber
Telephone number of the
contact. In the case of PO not
having this value is it defaulted
to 18005536387
7 1
| | | |--
fromRole.GlobalPartnerRoleC
lassificationCode
Role of Cisco with respect to
3A4 transmission – “Seller”
10
fromRole.PartnerDescription.
BusinessDescription.GlobalB
usinessIdentifier
DUNS of the partner as on the
request
11
fromRole.PartnerDescription.
BusinessDescription.GlobalS
upplyChainCode
“Information Technology”
12
fromRole.PartnerDescription.
BusinessDescription.GlobalPa
rtnerClassificationCode
“Manufacturer”
13 1
GlobalDocumentFunctionCod
e
“Response”
14 1 || - PurchaseOrder tag
15 0..1 ||| - AccountDescription Tag – Not sent on POA
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 125 of 144
No.
Cardinalit
y
Header Element Mapping Notes
Sample
Values
Lengt
h
63 0..1 ||| - comments
If order is Submitted – then
"MPNUmber=” + Web Order ID
| followed by any warning
messages
Else "Warning Messages=" +
Header & Line warning
messages
92 0..n
||| -
GlobalPurchaseOrderAcknow
ldgementReasonCode
In case of “Reject” in the
GlobalPurchaseOrderStatusCo
de, there is one or more valid
RN values here.
Note- in case of only line level
errors, then a distinct list of
associated line level
acknowledgementReasoncode
s will be published here.
NOTE: If system could not fulfill
the request either due to
malformed PO request or
technical difficulty handling the
request, the PO request will be
rejected with value = “Invalid
ID”
94 1
||| -
GlobalPurchaseOrderStatusC
ode
“Accept” or “Reject”
95 1..n
||| -
GlobalPurchaseOrderTypeCo
de
Pip3A4PurchaseOrderRequest/
PurchaseOrder/GlobalPurchas
eOrderTypeCode from
Request
11
7
1
||| -
isDropShip.AffirmationIndicat
or
“Yes”
11
8
0..1
||| -
OrderShippingInformation
Tag
12
3
0..1
|||| -
GlobalShipmentTermsCode
Pip3A4PurchaseOrderRequest/
PurchaseOrder/OrderShippingI
nformation/GlobalShipmentTer
msCode from order request
42
1
0..1 ||| - proprietaryInformation
In case of “Reject”, header
error messages are | delimited
and sent here. OrderRef is sent
here which is a | delimited with
other values and is a name
value pair
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 126 of 144
PIP 3A4 Purchase Order Confirmation – Line level
No.
Cardina
lity
Header Element Mapping Notes
Sample
Values
Length
130
1..n
|| - ProductLineItem
tag
131 1
||| - buyerLineItem.LineNumber
Pip3A4PurchaseOrderRequ
est/PurchaseOrder/Product
LineItem/LineNumber
132 0..1
||| - CustomerInformation
This section will be
populated if end User was
missing on the PO and was
picked from the deal for
processing the order
133
0..1
|||| - GlobalCustomerTypeCode
End Customer
134
0..1
|||| - PartnerDescription
135 0..1
||||| -
BusinessDescription.businessName.Free
FormText
End Customer Name
136 0..1
||||| -
GlobalPartnerClassificationCode
End User
137 0..1
||||| - PhysicalAddress.
addressLine1.FreeFormText
Address Line 1
138 0..1
||||| - PhysicalAddress.
addressLine2.FreeFormText
Address Line 2
139 0..1
||||| - PhysicalAddress.
addressLine3.FreeFormText
Address Line 3
140 0..1
||||| - PhysicalAddress.
addressLine4.FreeFormText
Address Line 4
141 0..1
||||| - PhysicalAddress.
addressLine5.FreeFormText
Address Line 5
142 0..1
||||| - PhysicalAddress.
cityName.FreeFormText
City Name
143 0..1
||||| - PhysicalAddress.
GlobalCountryCode
ISO Country Code
144 0..1
||||| - PhysicalAddress.
NationalPostalCode
Zip Code
145 0..1
||||| - PhysicalAddress.
postOfficeBoxIdentifier.FreeFormText
PO Box Number
146 0..1
||||| - PhysicalAddress.
regionName.FreeFormText
State
171 1
||| -
GlobalProductUnitOfMeasureCode
“Each”
172 0..n ||| -
GlobalPurchaseOrderAcknowledgment
ReasonCode
In case of “Reject” at the
line level
GlobalPurchaseOrderStatus
Code, one of the valid RN
codes
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 127 of 144
No.
Cardina
lity
Header Element Mapping Notes
Sample
Values
Length
174 1 ||| -
GlobalPurchaseOrderStatusCode
“Accept” or “Reject” based
on line level errors present
or not
195 1
||| -
isDropShip.AffirmationIndicator
“Yes”
196 1
||| - LineNumber
Purchase order referenced
line number
198 1
||| -
OrderQuantity.requestedQuantity.Prod
uctQuantity
Product Quantity as on the
request
214 0..n
||| -
ProductIdentification.PartnerProductId
entification
Tag
215 1
||| -
ProductIdentification.PartnerProductId
entification.GlobalPartnerClassification
Code
“Manufacturer”
216 1
||| -
ProductIdentification.PartnerProductId
entification.ProprietaryProductIdentifier
PropreiteryProductIdentifier
from the request (SKU or
expanded confirguration in
case of kitRef)
217 0..1
||| -
ProductIdentification.PartnerProductId
entification.revisionIdentifier.FreeForm
Text
“1”
332 0..1
||| -
proprietaryInformation.FreeFormText
"GlobalPurchaseOrderAckn
owledgmentReasonText="
+ Error Description ( if error
exists at this line)|
EndCustomerNotes =
<customer note as persisted
on the order>. This section
will be populated if end
User was missing on the PO
and was picked from the
deal for processing the line
and the EndCustomerNote
was sent in the order at
header level.
333 1
||| -
requestedEvent.TransportationEvent
Tag
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 128 of 144
No.
Cardina
lity
Header Element Mapping Notes
Sample
Values
Length
334 1
||| -
requestedEvent.TransportationEvent.D
ateStamp
Requested Ship date of the
line item.
Note – if this is a minor line
item, requested ship date is
sent of its corresponding
major line item – except for
services of minors and
minors to minors for which
sysdate + 1 is sent as the
requestedShipDate
335 1
||| -
requestedEvent.TransportationEvent.Gl
obalTransportEventCode
“Ship” “Dock” or “Pick-up”
414 1
||| -
totalLineItemAmount.FinancialAmount
Tag
415 1
||| -
totalLineItemAmount.FinancialAmount.
GlobalCurrencyCode
CurrencyCode 3
416 1
||| -
totalLineItemAmount.FinancialAmount.
MonetaryAmount
Monetary amount 19
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 129 of 144
12 Order Acknowledgement Email
Purchase order confirmation email messages are sent out to the email ID on the OrderAck name
value pairs on the order request.
12.1 Accept Scenarios
In case of Accept these emails would contain details regarding the order, including the billing,
shipping, end user, deal and payment terms amongst others. Please contact your B2B project
manager for a sample of the email format.
The subject of the email would be the following format –
Accepted Cisco Order Submitted Notification for Web Order ID #XXXXXXXX : PO# YYYYYYY
From Q4Fy14, Partner Name or CCO Id would be sent in content of the Email. Also included in the
content will be any Order Note &/or End Customer Notes on the PO.
The email is addressed to
a) If PO has order acknowledgement email ID sent – then order accept are sent to the provided
email ID
b) If the name value pair is missing, order accept emails can still be sent, to the order email
setup in the CCW Workspace profile and preference Notification Tab
.
12.2 Reject Scenarios
In case of reject, the errors are communicated back in an email as well. Both header and line level
errors are sent back along with any warnings
The email is addressed to
a) If PO has order acknowledgement email ID sent – then order rejects are sent to the provided
email ID
b) If OrderAckEmail is sent on the PO, and there are more email addresses configured in the in
Cisco’s B2B ordering system setup for DUNS (E2E Tool - CiscoEmailAddress, ITEmailAddress
parameters), then system would send out rejection emails to both these.
c) If no name value pair is sent –
a. then system would send out rejection emails to the email addresses setup in Cisco’s
B2B ordering system setup for DUNS (E2E Tool - CiscoEmailAddress, ITEmailAddress
parameters)
The subject of reject emails will be in the following format –
“Rejected : Cisco Order Notification for PO# <PO Number>”
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 130 of 144
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 131 of 144
Appendix A: Error Messages
Error severity management: The success or failure to meet a business rule validation is handled in
one of the following three ways:
An “Error” is the failure to meet a business rule that prevents the submission of an order. The
order is rejected.
A “Warning” is the failure to meet a business rule that does not prevent the submission of an
order, but requires a task to be raised for further investigation by Customer Service before it can
be booked. The order is accepted.
An “Informational Message” is triggered by the success or failure to meet a business rule. This
does not prevent the submission or booking of the order. No action is required of the partner.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 132 of 144
Appendix B: Sample Output from Transfer
Quote WS
Sample Output from
Transfer Quote.pdf
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 135 of 144
Appendix E: Glossary of Terms and
Abbreviations
Table 63: Glossary of Terms and Abbreviations
Term/Acronym Definition
ACK
Cisco abbreviation used for Acknowledgement
AS
Advanced Services
AS4
Applicability Statement 4 - Conformance Profile of the ebMS 3.0
specification which represents an open standard for the secure and
payload-agnostic exchange of B2B documents using web services
AS-F
Advanced Services Fixed
ATO
Assemble to Order
BE GEO ID
Business Entity Geography ID
BE ID
Business Entity ID
BID
Billing Address Identifier
Blanket PO
Blanket PO is a purchasing term that describes when a buyer uses the
same Purchase Order Number for ordering product from one vendor.
New lines are added to the same PO when new products are needed.
BOD
Business Object Document: Standard message formats used by the OAGI
messaging standard
BOM
Bill of Materials
CCO User ID
Cisco Connection Online User ID (Cisco.com)
CCW
Cisco Commerce Workspace
ConfigSet
A reference for ConfigurationSet created in Cisco with one or more
Configurations
CSPP
Cisco Services Partner Program
CSR
Customer Service Representative
CTMP
Cisco Trade-In Migration Program
cXML
Commerce XML
Deal ID
Deal ID is used to tie an acquired discount (above and beyond a
contractual discount) to a Sales Deal. Invalid Deal ID or missing Deal ID
does not reject an order.
DPAS
Defense Priorities and allocation system: The DPAS system was created
by a federal law so that the President of the United States has
authorization to:
Require that contracts or orders relating to certain approved defense
or energy programs be accepted and performed on a preferential
basis over all other contracts and orders
Allocate materials and facilities in a manner that will promote
approved programs
DPDM
Direct Partner Discount Model – (New term substituting the earlier GTM –
go to Market)
DTD
Document Type Definition
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 136 of 144
Term/Acronym Definition
DUNS
Dunn & Bradstreet Universal Numbering System
DVAR
Direct Value Added Reseller
eBMS
eBusiness XML Messaging Service
EPIC
External Partner Integration Cloud
GTIN
Global Trading Item Name
ICT Integrated Configuration Tool
MLC
Multi Line Configuration tool
MOVE
MOVE was an internal Cisco project intended to simplify Logistics
shipping preferences. Because they require specific simplified carrier
and service level data, Cisco must accept those values instead of what
they normally provide. The program is designed as an opt-in or opt-out
program, where the customer can have Cisco select the carrier and
service level or self-select those values.
Non-SS
Non Shared Support
OAGI
Open Applications Group Integration at http://www.oagi.org
OCI
Open Catalog Interface
OEM
Original Equipment Manufacturer
PAK
Product Activation Key
PIP
Partner Interface Process: Standard message formats used by the
RosettaNet messaging standard
PO
Purchase Order
PriceListID Identifier of Cisco's price list
ProductId
Identifier of hardware or software products and service items offered by
Cisco
QuickQuote
Quote created with user's contractual discount. These quotes usually get
approved automatically after submission.
QuoteID
Identifier of the quote created in Cisco
RN RosettaNet at http://www.rosettanet.org
ROW
Rest of the world
SelectionFlag
Identifier of the selection of a product line item in a configuration. For
items selected by the user the value is"User". Items automatically added
by the configuration engine to complete the configuration are marked as
"System" selected.
SKU
Stock Keeping Unit
SNH
Serial Number Hierarchy
SO
Sales Order
SRCT
Shipment Routing Configuration Tool: This tool allows partners to specify
shipping and delivery options such as preferred carriers, freight terms, and
service levels. It replaces the MOVE program.
SWIFT
Software Infrastructure and Fulfillment Technology
TAA
Trade Agreement Act
TAB
Try and Buy
T&C
Term and Content
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 137 of 144
Term/Acronym Definition
TEP
Trade Exception Process
Theatre
APAC, EMEA, and the US are termed as Business Theatres.
UDDI
Universal Description, Discovery, and Integration
UNSPSC
United Nations Standard Products and Services Code
UCS
Unified Computing Service
UCSS Unified Communications Software Subscription
WS
Web Service
Zulu time format
yyyyMMdd'T'hhmmss.SSS'Z' time format suffixed by a “Z”
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 138 of 144
Appendix F: BLOCK SKUs
Table 32: BLOCK SKUs
PID
Fulfillment
Restriction
UCSC-DBUN-C200-102
BLOCK
R200-BUN-3 BLOCK
UCSC-DBUN-C200-101
BLOCK
UCSC-DBUN-C200-116
BLOCK
R200-BUN-1 BLOCK
UCSC-DBUN-C200-115
BLOCK
UCSC-DBUN-C210-105
BLOCK
R210-BUN-4 BLOCK
UCSC-DBUN-C210-103
BLOCK
UCSC-DBUN-C210-104 BLOCK
UCSC-DBUN-C210-117
BLOCK
UCSC-DBUN-C210-118
BLOCK
R210-BUN-1 BLOCK
UCSC-DBUN-C210-119
BLOCK
R200-BUN-2
BLOCK
R200-BUN-4 BLOCK
R210-BUN-2
BLOCK
R210-BUN-3 BLOCK
R210-BUN-5
BLOCK
R460-BUN-1
BLOCK
R460-BUN-2 BLOCK
R460-BUN-3
BLOCK
R210-STAND-CNFGW BLOCK
R200-STAND-CNFGW
BLOCK
R210-CNFG1-N
BLOCK
R210-SASXP-CNFGW BLOCK
R250-BUN-1
BLOCK
R250-BUN-2
BLOCK
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 139 of 144
PID
Fulfillment
Restriction
R250-STND-CNFGW
BLOCK
R250-STND-CNFGW-2
BLOCK
R250-PERF-CNFGW BLOCK
R250-PERF-CNFGW-2
BLOCK
R250-CNFG1-N BLOCK
R250-STND-BUNDLE
BLOCK
R250-STND-BUNDLE-2
BLOCK
UCSB-DBUN-B200-102 BLOCK
UCSB-DBUN-B200-103
BLOCK
UCSB-DBUN-B200-101
BLOCK
UCSB-DBUN-B230-106 BLOCK
UCSB-DBUN-B230-107
BLOCK
UCSB-DBUN-B230-108 BLOCK
UCSB-DBUN-B250-104
BLOCK
UCSB-DBUN-B250-105
BLOCK
B200M2-BUN1 BLOCK
B200M2-BUN2
BLOCK
B200M2-BUN3
BLOCK
B200M2-BUN4 BLOCK
B200M2-BUN5
BLOCK
B200M2-BUN6 BLOCK
B200M2-BUN7
BLOCK
B250M2-BUN1
BLOCK
B250M2-BUN2 BLOCK
B440M1-BUN1
BLOCK
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 140 of 144
Appendix G: Redundancy and Default attributes
Redundancy & Default are key attributes in Config/Quoting/Estimate/Order process and will impact
partner/subscriber systems if not maintained on configuration.
Redundancy indicates primary and redundant items in a configuration. When missing, configuration can be
validated but may fail while editing configuration on CCW Portal or in CORE services.
Without a default flag, a valid configuration may become invalid due to instance mismatch.
Redundancy and Default attributes do not exist in legacy systems. These are new attributes in CCW. In order to
enable partners to order valid configurations with redundant and default items, the following was changed –
a) Use the suffix in the Cisco Product Hash Code to denote the different possible combinations.
• Cisco Product Reference is sent back to partners on the configuration XML output
and hence can be sent on the order request.
o If Cisco Product Reference is on the order request, it takes precedence over
any CP, SF, RF or DF values sent. System derives these values internally.
a) Partners also have the ability to send CP, SF, RF and DF flags at line level (format described
in section 10.2.1). However in case of invalid values for redundancy and/or default flags on
the request, these values are ignored and not processed further.
b) In case of having (a) or (b) BGL will not be triggered.
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 141 of 144
Appendix H: Accepted Diacritics
System accepts a list of diacritics and processes the order as listed below –
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 142 of 144
Appendix I: List of Operating Units
NETHERLANDS OPERATING UNIT
CISCO UK HOME OPERATING UNIT
CISCO ITALY SRL OPERATING UNIT
CISCO AUSTRALIA OPERATING UNIT
CISCO JAPAN OPERATING UNIT
CISCO US OPERATING UNIT
CISCO CANADA OPERATING UNIT
CISCO BRAZIL CA OPERATING UNIT
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 143 of 144
Appendix J:
Products and Service ordering business rules
for Cisco Brazil entity
Product Ordering controls
1. All locally manufactured products can only be sold by Cisco Brazil entity
2. All non-locally manufactured products can be sold by Cisco Inc entity only and no other
business operating units can sell into Brazil.
3. For all preset product configurations sold by Cisco Brazil entity, the equivalent product
configurations should not be sold by Cisco Inc entity into Brazil.
4. All software and software subscriptions (excluding embedded software) will be sold by
Cisco Inc entity.
Service Ordering controls
1. All Standalone TS and AS(AS-T, AS-F & AS-S) with install site as Brazil can only be sold
by Cisco Brazil entity
2.
Attached Technical services to Non-Locally manufactured product can be sold by Cisco
Inc entity
Product Mfg
Service Type
Attached
with Product
Cisco Brazil
or Cisco Inc
Locally Mfg (Embedded
SW) TS Y Cisco Brazil
Non locally Mfg
(Embedded SW) TS Y Cisco Inc
Non locally Mfg or Locally
Mfg TS (standalone M lines) N Cisco Brazil
Advance Services. AS-Fixed (product in CCW) NA Cisco Brazil
SW (e-delivery products) NA NA Cisco Inc
SW Subscription Sales NA Y Cisco Inc
SW Subscription Sales NA N Cisco Inc
PIP 3A4: Submit Purchase Order Implementation Guidelines
Cisco Systems, Inc.
Page 144 of 144
Appendix K: Smart Software Licensing
What is Smart Account?
A Smart Account is an account created by the customer or partner, and it is where Smart
Licenses are deposited.
The unique identifier of the Smart Account is referred to as the “Account Domain Identifier”.
Example: “BigU.edu” or “IBM.com”
A Smart Account must be assigned to Provisioning Enabled items on an order prior to
submitting an order in CCW.
There are two types of Smart Accounts:
• Customer Smart Account
• Holding Smart Account
Smart Licenses can temporarily be stored in a Holding Account, but they cannot be activated
until they are placed in an End Customer’s Smart Account.
There cannot be a combination of Holding Account and End Customer Account on an order.
What is Virtual Account?
Virtual Account is a subset of a smart account
A Smart Account can have one or more Virtual Accounts. Virtual Accounts fall under Smart
Accounts and will be used by customers to internally organize licenses. (ex. “BigU.edu,
Physics Department” or “BigU.edu, Engineering Department”)
When a Smart Account is created, a corresponding, default Virtual Account is automatically
created at the same time.
Used by customers internally to organize licenses.
Example:
Customer Smart Account = BigU.edu (Umbrella account)
Virtual Account = BigU.edu Physics Dept (Department specific account)
