This document describes the changes between minor versions of cXML. For the changes between major versions, see the cXML User's Guide.
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 Ariba CSN or AM-NE, 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. At the moment this
request is rarely used within the Ariba infrastructure. Currently, it is primarily used by
Ariba CSN for service partners and might in the future be relevant for Marketplace
participants.
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