xCBL 4.0 XML Document Descriptions
xCBL 4.0 contains 44 documents. Some documents from xCBL 3.5 have not been brought
forward and some documents are new. xCBL 4.0 utilizes multiple namespaces where each
namespace represents a functional area. The documents are listed below by functional
area and namespace. To view the description of an xCBL 4.0 document, simply click on
the link.
Functional area: | core |
Namespace: | rrn:org.xcbl:schemas/xcbl/v4_0/core/core.xsd |
Documents: | none |
Description: | This is the core library for xCBL 4.0. It contains components used several times in other namespaces. |
|
|
|
|
|
|
|
|
Functional area: | messagemanagement |
Namespace: | rrn:org.xcbl:schemas/xcbl/v4_0/messagemanagement/v1_0/messagemanagement.xsd |
Documents: |
MessageAcknowledgement
ApplicationResponse
ErrorResponse
|
Description: | The messagemanagement namespace contains the xCBL documents that are associated with generic xCBL document processing. This includes any documents that are to be used for general acknowledgement, response, and error communication.
|
|
Functional area: | applicationintegration |
Namespace: | rrn:org.xcbl:schemas/xcbl/v4_0/applicationintegration/v1_0/applicationintegration.xsd |
Documents: |
Requisition
AccountCheck
GetOrder
GetERPData
GetERPDataResponse
|
Description: | The applicationintegration namespace contains the xCBL documents used to interface with backend ERP systems.
|
|
Functional area: | catalog |
Namespace: | rrn:org.xcbl:schemas/xcbl/v4_0/catalog/v1_0/catalog.xsd |
Documents: |
ProductCatalog
|
Description: | The catalog namespace contains the xCBL documents that are associated with catalog content creation, processing, and inquiries.
|
|
Functional area: | statisticsandforecasting |
Namespace: | rrn:org.xcbl:schemas/xcbl/v4_0/statisticsandforecasting/v1_0/statisticsandforecasting.xsd |
Documents: |
TimeSeries
TimeSeriesResponse
TimeSeriesRequest
|
Description: | The statisticsandforecasting namespace contains the xCBL documents that are used to provide statistical data and forecasting data for products over a specified time periods
|
|
| |
Individual Document Descriptions
Application Integration
[^]AccountCheck:A message used to check account information between a procurement system and an enterprise resource planning system (ERP) or other type of internal system. The message includes account information as well as line item data for validation by the ERP system. The message is usually issued prior to creation of a Requisition.
[^]GetERPData: A message to request synchronization of data with an enterprise resource planning system (ERP) or other type of internal system. The message specifies specific data requested from the external system
[^]GetERPDataResponse: A message sent in response to the GetERPData request containing the set of data requested.
[^]GetOrder: A message typically sent to an internal or external system to request information about nee Purchase Orders.
[^]Requisition: A message to request the purchase of goods and or services. The goods and services specified in the message can be from multiple suppliers. The message can be sent to a procurement system from an internal or external system or it can be sent from a procurement system to an internal system to data versification and synchronization.
Catalog Content
[^]ProductCatalog: Covers the pricing and product descriptions for catalog content, and has a self-describing set of extensions for further characterizing products and services offered. May be used to transfer self-configured product characteristics as well.
Financial Management
[^]Invoice: A message sent from the seller to the buyer notifying the buyer that payment is due for the goods or services detailed in the invoice supplied under conditions agreed between the buyer and the seller. An invoice may refer to goods, items or services related to one or more orders. An invoice may contain references to payment terms and transport.
[^]InvoiceResponse: A message sent from the buyer to the seller notifying the seller that a previously sent Invoice has been accepted or rejected. This document can also respond with changes to the Invoice
[^]PaymentRequest: A message to arrange for payment of a specified value amount to a beneficiary in settlement of a business transaction. The payer can initiate a Payment Request to instruct its financial institution to debit its' account by the specified amount to be paid to the beneficiary for goods and services rendered. The Payment Request can reference multiple documents and consolidated payment is supported. The payer can send multiple payment requests in a single payment request document. From the information in this document the financial institution will have all the details necessary to debit the payer's account and process the payment to the specified supplier's bank.
[^]PaymentRequestAcknowledgment: A message sent to the payer by the financial institution to acknowledge receipt of a Payment Request document and also to inform of any errors in the business data.
[^]RemittanceAdvice: A message sent from the payer to the beneficiary to serve as notice that the payment process has begun.
[^]FXRateRequest: A message to enable payers to retrieve a foreign exchange quote from a financial institution needed to complete a payment request for goods or services.
[^]FXRateResponse: A message to enable a financial institution to provide a foreign exchange rate quote in response to a foreign exchange rate request.
[^]PaymentStatusRequest: A message to enable payers to query the status of a previously submitted payment to/from a financial institution.
[^]PaymentStatusResponse: A message to enable the financial institution to send the information on the status of a payment to the payer.
Material Management
[^]AdvanceShipmentNotice: A Message sent from the seller to the buyer to advise of the dispatch of goods. The shipment can be for planning or serve as a notice of a shipment in progress. Therefore it is not necessary for a supplier to provide a preliminary notice of shipment, nor is it necessary for a supplier to send an actual note of shipment. Actual tracking of freight will initially be handled by the shipper directly and not via the ASN.
[^]GoodsReceipt: A message initiated by the party, which received the goods. In most cases this is the buyer, but can also be a third party. The GoodsReceipt can be used to provide customary and established business and industry practice relative to the notification of receipt or formal acceptance of goods and services. The message is used to report the physical receipt of goods. It allows for the reporting of discrepancies in products, quantities, terms, packages, etc. It should not be used to convey inventory positions- this will be handled in a separate xCBL document. The GoodsReceipt is often sent when there is a discrepancy between the material being received and the information that was transmitted in the AdvanceShipmentNotice (ASN). The GoodsReceipt can also be used as a credit memo in a 'pay on ASN relationship.' In this scenario the GoodsReceipt is used as a reference for payment, as in an Evaluated Receipt Settlement (ERS).
[^]PlanningSchedule: A message sent the buyer to the seller. The document consists of the notification of a forecast to be sent from the buyer to the seller. The document outlines the requirements regarding the details for short-term delivery and/or medium to long scheduling for products. The scheduling can be used to authorize manufacturing and/or the provision of materials. This is based on the terms and conditions defined in a purchasing agreement commonly outlined by a contract or order. The Planning Schedule defined here will not be designed to support release capability. This document will serve solely as a materials requirement schedule.
[^]PlanningScheduleResponse: A message sent to the buyer by the seller to acknowledge receipt of a PlanningSchedule document and also to inform of any errors or changes in the business data.
[^]ShippingSchedule: A message from a buyer to a seller containing the notification of short-term shipping requirements in reference to an existing planning schedule or purchasing agreement. The document provides specific details relating to the required products, quantities, delivery points and requested delivery dates. The Shipping Schedule document supersedes certain shipping and delivery information transmitted in a previous planning schedule, but does not replace it. Shipping Schedules are usually stated in daily, weekly or monthly buckets (depending upon the industry) and are used to refine planning schedules in support of a just-in-time planning environment. This provides a mechanism to issue precise shipping schedule requirements on a more frequent basis than with the issuance of a planning schedule. The Shipping Schedule also provides the ability for a customer location to issue shipping requirements independent of other customer locations when planning schedules are issued by a consolidated scheduling organization.
[^]ShippingScheduleResponse: A message sent to the buyer by the seller to acknowledge receipt of a ShippingSchedule document and also to inform of any errors or changes in the business data.
[^]InventoryReport: A message used to communicate information regarding current inventory levels for raw materials, manufactured goods, or any other type of stockable materials.
Message Management
[^]MessageAcknowledgement: A message sent from one Connector to another Connector. The message is sent from the Business Document receiving Connector to the Business Document sending Connector and only indicates that the Business Document was successfully received. The use of the message is optional since some Connectors may or may not report protocol level errors.
[^]ApplicationResponse: A message used by one Application (the receiver of a Business Document) to indicate to another Application (the sender of the Business Document) a business response to the received document. The document can report content errors in a document, acknowledge the receipt or successful processing of a document or can be used in those cases where a business response is needed. The ApplicationResponse document is only to be used when a specific response document does not exist for a Business Document.
[^]ErrorResponse: This document is used to communicate that a system level error was encountered relative to the transmission of an xCBL document. This document is typically created by the Platform Infrastructure and sent to the application that was the original sender of the document. The document provides information on the system level error that occurred. The application should be designed to process this document. This document is typically not part of any choreography between the sending application and the receiving application. An application should always use the response documents for the original document or the ApplicationResponse document to communicate any error conditions.
Pre Order Management
[^]AvailabilityCheckRequest: A document used to request the availability of a specified list of items from a single supplier. AvailabilityCheckResult: Response to the availability check query indicating available quantities and other information for the request line items.
[^]AvailabilityCheckResult: Response to the availability check query indicating available quantities and other information for the request line items.
[^]AvailabilityToPromise: A document for querying availability and/or ability to commit to specific line items. The request is used to determine when, where and how many of the requested goods the supplier can supply.
[^]AvailabilityToPromiseResponse: Application-level response to the AvailabilityToPromise indicating what goods can be committed in response to the original request.
[^]PriceCheckRequest: Document for requesting the price of a list of items offered for sale.
[^]PriceCheckResult: The application response, containing pricing information.
[^]RequestForQuotation: A message sent from the buyer to the seller requesting a quotation on goods or services. The requests are based on pre-agreed terms and conditions or the terms can be stated in the message. Delivery information can also be specified within the RequestForQuotation. This message functions on a point-to-point basis where one message is sent to one recipient.
[^]Quote: A message sent from the seller to the buyer in response to a RequestForQuotation giving details of the number, price and delivery availability of the quoted goods or services. This message can form the basis of a purchase order for the buyer if appropriate.
Order Management
[^]Order: A message sent from buyer to seller for the ordering of goods or services. The Order document is suited for use as a standing order, a stand-alone order, or most other typical order functions within MRO and direct goods. An Order may refer to goods or services and can provide information such as delivery schedules and pricing.
[^]OrderRequest: A message sent from the seller to the buyer; requesting an Order from the buying application. This document is typically used by configurators on a supplier's website. The document contains ordering information that is a result of a buyer's inquiry to purchase. There is not a response to the OrderRequest as the OrderRequest results in the creation of an Order. Any changes to the OrderRequest will be represented in the Order.
[^]OrderResponse: The message used to acknowledge application receipt of an Order, or to indicate changes to the Order received. This message can also be used to respond to and acknowledge a ChangeOrder.
[^]ChangeOrder: A message sent from the buyer to the seller to indicate changes to an Order. Buyers may change an order for various reasons such as changing the ordered items, quantity, delivery date, ship-to address, etc. Sellers can accept or reject the change order using the order response document.
[^]OrderConfirmation: A message sent by the seller to the buyer to provide a confirmation on goods or services in a previously received order or orders. The OrderConfirmation can provide more specific information than was included in the Order on the specific goods and services. Multiple OrderConfirmation documents are possible for a single order and the OrderConfirmation document can be used for multiple Order documents. This document is to be sent once the services are complete.
[^]OrderConfirmationResponse: A message sent from a buyer to a seller to confirm receipt of the OrderConfirmation. The OrderConfirmationResponse accepts or rejects the previously sent OrderConfirmation
[^]OrderStatusRequest: A synchronous message sent to by the buyer to the seller requesting the status of the order. More than one order can be queried, and particular line items within an order can queried. The document allows the sender to query the status of whole orders and parts of orders in one message.
[^]OrderStatusResult: A message sent by the seller to the buyer in response to the OrderStatusRequest. The result can give information on the order status, the shipping status and the payment status of the order.
[^]RequestForQuotation: A message sent from the buyer to the seller requesting a quotation on goods or services. The requests are based on pre-agreed terms and conditions or the terms can be stated in the message. Delivery information can also be specified within the RequestForQuotation. This message functions on a point-to-point basis where one message is sent to one recipient.
[^]Quote: A message sent from the seller to the buyer in response to a RequestForQuotation giving details of the number, price and delivery availability of the quoted goods or services. This message can form the basis of a purchase order for the buyer if appropriate.
Statistics and Forecasting
[^]TimeSeriesRequest: A message used to request statistical information. The response to this document is the TimeSeries. TimeSeries is a forecasting document that can be used to process data based on variable characteristics. Data is collected over a period of time, and time slices can be presented as a historical account or a planned forecast.
[^]TimeSeries: A message used to communicate statistical information. Generally, this is applied to forecasting requirements and can be used to process data based on variable characteristics. Data is collected over a period of time, and time slices can be presented as a historical account or a planned forecast. This document can be used as a response to the TimeSeriesRequest.
[^]TimeSeriesResponse: A message used as an application-level acknowledgement and to acknowledge receipt of the TimeSeries document.
|
![[]](/images/x-join.gif){kind=small}
