This document describes the changes between minor versions of cXML. For the changes between major versions, see the cXML User's Guide.
Type definitions are a new document type used to describe supplemental catalog
attributes and parametric data fields for catalogs. The new Type
element replaces the deprecated SearchGroup element.
Type definitions provide a richer and more general framework for defining parametric
types, and they allow the definition and standardization of parametric types
from type provider organizations independent of catalog index data in
which SearchGroup elements resided.
The SearchGroupData and SearchDataElement elements
continue to specify the actual parametric data for a given catalog item. SearchGroupData
must reference a defined type, and SearchDataElement specifies
data for each type attribute within that type.
The TypeDefinition document is defined in a new cXML DTD named
Catalog.dtd.
The Index element has a new attribute named loadmode,
which can be set to either "Full" or "Incremental"
to indicate whether the catalog should be loaded into the target application
as a complete catalog or an incremental change.
Previously, all cXML catalogs were incremental.
The ItemOut element in purchase orders has a new attribute named
isAdHoc, which indicates that the item is a non-catalog (ad-hoc)
item.
Non-catalog items are items entered manually by requisitioners, not items selected from electronic catalogs. Often, these items do not have part numbers. Non-catalog orders usually require special validation and processing.
Users enter non-catalog items to purchase products and services on an ad-hoc basis or because they could not find them in electronic catalogs.
If isAdHoc="yes" exists for some items and not for others,
the requisition should be broken into two requisitions: one for catalog items
and one for non-catalog items. Suppliers will then be able to automatically
process as many requisition items as possible, instead of having to manually
process both catalog and non-catalog items.
Suppliers can now issue ConfirmationRequest documents to indicate
that items are back ordered.
The new type="backordered" attribute value can be used
in either ConfirmationHeader for the entire order or in ConfirmationStatus
for individual line items.
The Contract element for defining contract pricing is deprecated.
It is no longer needed, because MasterAgreementRequest documents
can handle most of the requirements of contract pricing.
The SearchGroup element for defining parametric data categories
is deprecated. It is no longer needed, because the new TypeDefinition
element defines parametric data categories.
Note that catalogs continue to use the SearchGroupData element
to populate parametric data.
The InvoiceDetail transaction is now fully described in Chapter 9, "Invoices" in the cXML User's Guide.
The version attribute of the cXML wrapper element
has been deprecated. This attribute is not needed, because applications can
detect the cXML version from the system identifier in the DOCTYPE declaration.
StatusUpdateRequest documents can contain a new element named
InvoiceStatus. Buying organizations can now use these documents
to update the status of invoices on commerce network hubs, which can forward
them to suppliers. Invoice status can be reconciled, rejected,
or paid.
The new InvoiceStatus element can contain a new PartialAmount
element, which specifies the amount paid against the InvoiceDetailRequest.
If this element exists, the buying organization does not pay the full amount
specified within the InvoiceDetailRequest.
The Profile transaction can now return multiple variations of a single transaction type. Previously, if a cXML server supported multiple variations of a transaction, there was no standard for distinguishing them.
For example, a marketplace might provide two services within the ProviderSetupRequest
transaction: signin and console. The ProfileResponse
document can now specify the location of each variation:
<Transaction requestName="ProviderSetupRequest">
<URL>http://service.hub.com/signin</URL>
<Option name="service">signin</Option>
</Transaction>
<Transaction requestName="ProviderSetupRequest">
<URL>http://service.hub.com/console</URL>
<Option name="service">console</Option>
</Transaction>
To enable easier data translation between EDI and cXML documents, there are
new values for the Contact role attribute and the IdReference
domain attribute.
IdReference within InvoicePartner has a new Contact
role: issuerOfInvoice. The from role has
been deprecated.InvoiceDetailShipping has a new Contact role:
carrierCorporate.Contact element has new roles: supplierCorporate
and buyerCorporate. In addition, the general Contact
roles from and to have been reserved for possible
use in the future.
The InvoiceDetail transaction was added to support detailed invoicing. This transaction enables suppliers to invoice buying organizations through network commerce hubs for the entirety or portion of single or multiple orders. This transaction introduces the InvoiceDetailRequest document and uses a standard cXML Response document.
Use this transaction to inform buying organizations of invoice details, including order references, line item references, partners involved, accounting and financing, discount terms, shipping and special handling, applicable taxes, deposit and payment, and contact and remittance information. Use InvoiceDetail to send an invoice for any portion of all or selected line items from single or multiple orders. You can also use InvoiceDetail to send a credit or debit memo, or a duplicate copy of invoices sent earlier.
This attribute supports address codes for relationships that require id references.
Tax element can contain repeatable TaxDetail elements. TaxDetail
provides information regarding taxable amount, tax amount, tax location, tax
purpose, tax category, tax rate, whether the tax is VAT recoverable, and textual
description.
Provides the capability of negotiating and creating Master Agreements with suppliers and creating Release Orders from these Master Agreements. Master Agreement documents can be routed from a procurement application to a supplier via a network hub.
type attribute - Whether this document refers to a 'value'
or 'quantity' Master AgreementagreementDate attribute - Date the Master Agreement becomes
available for orderingexpirationDate attribute - Date the Master Agreement expires
and is no longer available for orderingMaxAmount element - Maximum amount for all line items on the
Master AgreementMinAmount element - Committed amount for all line items on
the Master AgreementMaxAmount element - Maximum amount for this line itemMinAmount element - Committed amount for this line itemmaxQuantity - Maximum quantity for this line itemminQuantity - Committed quantity for this line itemorderType indicates whether the Order Request is a Release Order
from an existing Master Agreement contract. The default is regular.
agreementID identifies the associated agreement corresponding
to the Release Order.
agreementPayloadID specifies the PayloadID of the referenced Master
Agreement.
Identifies the corresponding item on a particular Master Agreement.
When initiating a PunchOut session for sourcing an item rather than extending a catalog search to the PunchOut site, some additions to the PunchOutSetupRequest and related documents improve the application integrations. These additions should be used only when the originating application is sure the destination supports them. They are not completely compatible with existing PunchOut destinations.
The operation attribute of the PunchOutSetupRequest now has an additional option in its enumeration. This allows a procurement application to begin a PunchOut session with reference to information present in the ItemOut element list rather than the SelectedItem element. Otherwise, the new operation is very similar to a "create" operation.
This new element may be used instead of a single SupplierID in the ItemOut element. SupplierList element defines a list of suppliers that might be associated with a sourced item. The ItemOut elements may specify a list of suppliers that could be involved in the sourcing process. The Supplier List needs the name and the list of SupplierIDs for that particular supplier.
Transfers information for the update of a given RFQ transaction, including the type of update. The content of the element can be a textual description of the update, such as the actual status update string used in the UI for display.
Specifies whether the quote is still pending or final. This is a replacement for various hacks used to prevent submission of requisitions that include unfinished quotes. If set, the application should return for updates prior to allowing submission.
The datatypes of the ProfileResponse attributes as expressed in the a-type fixed attribute of that element were incorrect in the 1.2.004 DTD. This was a regression of the defect mentioned below as fixed in 1.2.003.
Indicates that a node would like the ItemDetails element returned in a later PunchOut (edit or inspect) operation. Without this, most procurement applications today default to sending only limited identification information such as the SupplierID, Path and ItemID elements.
This is an extension to the Path Routing feature mentioned in the 1.2.003 notes below.
A new message option for use within the GetPendingResponse. Indicates new information is available at the target site.
Identifies a subscription or any available data.
This optional element allows more detailed information if the original document
is a ConfirmationRequest with type="RequestToPay".
The lastRefresh attribute indicates when the server's profile
cache last changed. When an application receives a ProfileResponse
from a profile caching entity such as a network commerce hub, it will know the
age of the data in the cache.
Path Routing enables documents to be routed by and copied to intermediary systems such as direct and indirect marketplaces, and commerce service providers. In complex relationships between buyers and suppliers, documents might be routed through several intermediary systems before they reach the end node.
Added an optional Path element to the Header and Item level of
cXML documents.
Changed
a-dtype NMTOKENS #FIXED 'effectiveDate dateTime'
to
a-dtype NMTOKENS #FIXED 'effectiveDate dateTime.tz'
The cXML Catalog Upload transaction enables suppliers to programmatically upload
and publish catalogs to a network hub. It can be used to automatically distribute
updated catalogs whenever the pricing or availability of products or services
changes. The Catalog Upload transaction consists of two cXML documents: CatalogUploadRequest
and generic Response. CatalogUploadRequest was added
to cXML.dtd.
The Catalog Upload transaction supports both CIF and cXML catalogs.
ProviderSetupRequest, ProviderSetupResponse, and
ProviderDoneMessage were added to the cXML.dtd. Provider
PunchOut enables an application to punch out to a provider’s application
that supplies some service to the originating application, such as credit card
validation, single login, or self registration.
Moved common PunchOut related element definitions to Base.mod
from other modules thereby reordering the definitions within cXML.dtd
and Fulfill.dtd.
Reordering of cXML.dtd places the contents of Entities.mod
and Profile.mod slightly later in the concatenation.
Added CopyRequest transaction.
Reordering of the content models for elements used within the ConfirmationRequest
and ShipNoticeRequest documents places lower-level lists at the end of each.
For example, the ConfirmationStatus list moves to the end of
the ConfirmationItem element. The content of ShipNoticePortion
has also changed.
New comments for many elements in ConfirmationRequest about defaulting
and overriding behavior when a later document arrives with line-level rather
than header-level data, or visa versa. Specifically describes which elements
and attributes in the ConfirmationHeader apply to an entire
order rather than this specific confirmation.
Added requestToPay option in the enumeration for the type
attributes of the ConfirmationHeader and ConfirmationStatus
elements. This addition enables support for a scaled-down Invoice capability.
The PunchoutDetail element can now contain an Extrinsic
list. This is used in a IndexItemPunchout (also correct with that
capitalization) element in a static catalogue.
Released a draft version of Fulfill.dtd containing ConfirmationRequest
and ShipNoticeRequest.
The CopyRequest element enables copying and forwarding of messages
to new recipients, similar to forwarding an e-mail messages. To accomplish
this, a new message is created and sent that includes the original message.
It is primarily used by commerce network hubs and marketplace hosts.
Better explanations of the country-related elements and attributes have been
added to the CountryCode element, and the isoCountryCode
attribute on the Address, Country, and CountryCode
elements.
The data type of the of the Contact element's optional role
attribute has been changed from an enumeration containing endUser,
administrator, purchasingAgent, technicalSupport,
customerService, and sales, to a string with the same
allowed values. This change enables the usage of the Contact element
to be more easily expanded.
An optional lastChangedTimestamp attribute has been added to the
Identity element. This attribute enables automatic synchronization
of data between systems.
An optional domain attribute has been added to the InternalID
element and provides scoping for this subscription catalogue identifier. The
default domain value is "NetworkSubscription".
An optional DocumentReference element has been added to the
OrderRequestHeader element. DocumentReference provides explicit
links between an update or delete action and the most recent OrderRequest
for the same order. DocumentReference contains the payloadID
of the most recent OrderRequest document in the list, not always
the original OrderRequest (with type set to "new").
DocumentReference and StatusUpdateRequest have been
moved to new locations within the cxml.dtd file. The constituent
file status.mod no longer exists.
The cXML version string (for example, 1.1.008) is now stored in a single-parameter
entity named cxml.version. You can use this new entity to keep
the version number consistent throughout cXML documents. For example,
<!DOCTYPE cXML SYSTEM "http://xml.cXML.org/schemas/cXML/1.1.008/cXML.dtd">
<cXML version="&cxml.version;" payloadID="992662" xml:lang="en-US" timestamp="2000-03-12T18:39:09-08:00">
Using this technique is not recommended when interacting with non-validating
XML parsers. Non-validating parsers will have no version information as they
load the cXML document, and will behave as if the version attribute
were absent.
cXML 1.1 followed a general XML recommendation to redefine five entities (lt, gt, amp, apos, and quot) for interoperability with SGML parsers. However, it was found that these redefinitions cause some XML parsers to complain.
These redefinitions are now conditionalized for better compatibility with XML
parsers. In the future, commerce network platforms might have an option for
setting the XML flag SGML-help to trigger these redefinitions for
interoperability with SGML parsers.
The definitions of the %cxml.messages, %cxml.requests,
and %cxml.responses entities have been moved to a separate module
(Entities.mod) for improved maintainability. By moving these definitions
to Entities.mod, they appear together within the .dtd, separate
from their uses in the Message, Request, and Response
elements.
The copyright notice in the .dtd and .mod files has been replaced by a reference to the license agreement on www.cXML.org:
For cXML license agreement information, please see
http://www.cxml.org/home/license.asp
The top-level cXML element has a new declaration:
Old element type declaration:
<!ELEMENT cXML ((Header, Message) | (Header, Request) | (Response))>New declaration:
<!ELEMENT cXML ((Header, (Message | Request)) | Response)>
The new declaration uses a deterministic grammar that is compatible with more XML parsers.
The proposed element name OrderReference was changed to DocumentReference
so that it is more generic.
The data types of the following attributes have been changed from NMTOKEN to CDATA so that they can contain less restrictive data:
isoCountryCode
currency
alternateCurrency
xml:lang