xCBL 4.0

Invoice 4.0.1.0
Recommended Use

Version 1.1
March 28, 2003

Table of ContentsPurpose
Invoice
Specifying Invoice Types
Specifying Invoice References
Header Level References
Line Level References
Specifying Currency Information
Invoice Currency vs. Payment Currency
Tax Accounting Currency
Invoice Currency Total Value
Payment Currency Total Value
Unit Price Currency
Specifying Details of an Item
Line Item Identification
Part Numbers
Dimensions of the Item
Specifying Sub Lines
Identification of Line Item Type
Referencing a Parent Item
Recommended Best Practices
Specifying Quantities
Total Quantity
Exception Quantities
Other Quantities
Specifying Invoice Dates
Invoice Issue Date
Tax Point Date
Header Level Invoice Dates
Line Level Invoice Dates
Specifying Pricing
Simple Pricing
Price Basis Quantity
Tiered Pricing
Recommended Best Practices
Specifying Tax Information
Taxes, Allowances and Charges
Tax IDs
Specifying Payment Instructions
Payment Terms
Discounts
Payment Method
Specifying Totals
Non-MonetaryValue Totals
Handling Gross & Net Values
Handling Discount Totals
Handling Tax Totals
Line Item Totals
Specifying Custom Fields
Country Specific Requirements
Name Value Set

Purpose

The purpose of this document is to provide details about the recommended use of the Invoice document for xCBL 3.5.  This does not cover the use of every single element, nor does it explicitly state all the mandatory elements for a given scenario.  It is merely meant to give a general guideline for the use of the xCBL 3.5 Invoice document.

Invoice

The Invoice is a dynamic document that can be used to specify a detailed listing of goods or services rendered.  The Invoice document serves as an itemized bill from a supplier to a buyer.  The level of detail required for implementation of this document will be dictated by the trading partner business requirements.  When implementing the Invoice document, it is important to understand the “triggering point” of the document.  An invoice can be invoked at various points during the business cycle (i.e., after purchase order create, after shipment processing, at goods receipt, etc.).  This will influence the type of data that is referenced and required on the Invoice document.  The Invoice can be a simple document that specifies the billing requirements for a single order.  It can also be a consolidated document that specifies billing information for multiple orders. 

Specifying Invoice Types

There are many different forms of an invoice and it is important to communicate what type of invoice will be used between trading partners.  The type of invoice used will determine the functionality of the invoice.  Whether it is a pro-forma invoice, credit memo, or consolidated invoice will dictate what type of data will be sent and which fields on the Invoice document are used.  This information can be specified in Invoice/
InvoiceHeader/InvoiceType.

Specifying Invoice References

An invoice will usually be generated as a result of a previous transaction.  Hence, it is very important for audit and reconciliation purposes to be able to link all previous transactions that resulted in the triggering of the Invoice document.  

Header Level References
At the header level, the reference information is specified in Invoice/InvoiceHeader/
InvoiceReferences.  InvoiceReferences has explicit containers to store purchase order reference, ASN reference, contract reference, etc.  The type of reference specified is determined by the trading partner business requirements.  The InvoiceReferences structure may occur 0..n times.  Therefore, customers who are supporting consolidated invoicing can specify all relevant reference documents that are associated with the invoice.     

Line Level References
A line item contains an optional InvoiceReferences structure so that a link to previous transactions can be specified at this level.  The structure is found in Invoice/
InvoiceDetail/ListOfInvoiceItemDetail/InvoiceItemDetail/InvoiceBaseItemDetail/
LineItemReferences.  It is common to use this line level reference for consolidated invoices since each invoice line item can be originated from different documents.  This can also be used to reference existing contracts or catalogs from which this item originated.  Providing this information will facilitate the reconciliation and line item matching process of the invoice to the originating purchasing document.  
Specifying Currency Information

Invoice Currency vs. Payment Currency 
In most cases, the currency specified on the purchase order should be the same as the currency specified on the invoice and payment document.  There are some business processes where this is not the case.  To assist in the audit and reconciliation process for these types of invoices, users can explicitly specify the invoice currency and payment currency within the Invoice document.  This is done respectively in //InvoiceHeader/
InvoiceCurrency and //InvoiceHeader/PaymentCurrency.  If necessary, the rate of exchange information can also be provided in //InvoiceHeader/
ListOfRateOfExchangeDetail.  As with all xCBL documents, the currency data specified at the header level serves as a default value for the entire document unless it is explicitly overridden at the line level.  

Tax Accounting Currency
For cross-border trade, a trading partner may invoice in a currency that differs from the currency that they pay tax in.  For these cases, the tax accounting currency can be specified in Invoice/InvoiceHeader/TaxAccountingCurrency.  Usage of this structure is optional and will be determined based on trading partner business requirements.

Invoice Currency Total Value
In general, the currency at the header level serves as the default currency for the entire Invoice document.  In some cases, the business process may require that the currency information be specified at the line item level.  This may be due to legacy requirements or to the fact that the currency stated at the line level differs from the header level currency.  At the item level, the invoice currency information can be specified in //InvoiceDetail/ListOfInvoiceItemDetail/InvoiceItemDetail/InvoicePricingDetail/
PaymentCurrencyTotalValue//Currency.  Please note that this currency declaration is valid only for the line item in which it is specified. 

Payment Currency Total Value
If a line item payment currency differs from the line item invoice currency, then the details will be specified in the PaymentCurrencyTotalValue structure using  //InvoiceDetail/ListOfInvoiceItemDetail/InvoiceItemDetail/InvoicePricingDetail/
PaymentCurrencyTotalValue//Currency.  This line level currency value is optional but if provided, will override the PaymentCurrency value stated at the header level.  This is valid only for the particular line item specifying this currency information.  

Unit Price Currency
In addition to these currency value specifications, there is also an optional Currency structure in association with the UnitPrice.  This is found in //InvoicePricingDetail/
PricingDetail/ListOfPrice/Price/UnitPrice/Currency.  This value is not required and as a default is assumed to be equivalent to the //InvoiceHeader/.  If the invoicing currency differs from the order currency, then the //UnitPrice/Currency element could be used to specify the originating order currency if needed.  In this case, the //ListOfPrice/Price/
PricingType/PricingTypeCoded should be set to ‘OriginalPurchaseOrderPrice’.

Specifying Details of an Item

The following specifies how the recommended xCBL line numbering and part number identification is to be handled.  Within the Invoice, this can be found in //InvoiceDetail/
ListOfInvoiceItemDetail/InvoiceItemDetail/InvoiceBaseItemDetail.  Please note that many of the xCBL documents use BaseItemDetail and hence there will be many similarities in how this structure is used.         

Line Item Identification
A line item is uniquely identified within the Invoice document with the //InvoiceBaseItemDetail/LineItemNum element.  LineItemNum is the only required element within InvoiceBaseItemDetail for the Invoice.  The BuyerLineItemNum is mandatory and in most cases will match the BuyerLineItemNum value that was assigned in the preceding Order document.  It is noted that the Invoice document originates from the supplier’s system.  Hence, it was an oversight to have the “BuyerLineItemNum” be mandatory for this document.  As a general rule, the mandatory field BuyerLineItemNum serves as the primary line item identifier.  If this happens to be the seller’s line item number, then map the seller’s line item number to the BuyerLineItemNum field.  Please note that there is also an optional SellerLineItemNum field which may be used if the primary line item identifier differs from the seller’s line item identifier.  

Part Numbers
The //BaseItemDetail/ItemIdentifiers element is used to provide the identification of the item being invoiced.  Typically, the //ItemIdentifiers/PartNumbers/SellerPartNumber should be sufficient to identify the item being invoiced, although other identifiers of the item can also be specified.  If substitute items are allowed for this item, they should be identified in the //ItemIdentifiers/PartNumbers/SubstitutePartNumbers/
element.  It is also important to note that //ItemIdentifiers/
Service should be set to “true” if the item being invoiced is a service item.

Dimensions of the Item
An item’s dimensions should be specified using the //BaseItemDetail/ListOfDimension element.  Although a part number may imply the dimensions of the item, in some cases it may be necessary to explicitly specify the dimensions of the item.  This information is optional for an Invoice document.  

Specifying Sub Lines

Sub line items are handled in the xCBL 3.5 Invoice by specifying parent/child relationships.  Sub line items are typically used for grouping the components of an item, but could also be used for other grouping purposes, such as the grouping of a collection of services.  Specifying sub lines in an xCBL 3.5 Invoice document involves the identification of the type of line item along with a reference to the parent item.  Usage of sub line items is optional and is dependent on the business practices of the trading partners.    

Identification of Line Item Type
The type of line item is specified by the //BaseItemDetail/LineItemType/
LineItemTypeCoded element.  There are three possible line items.  The first type of line item to note is a textual item (LineItemTypeCoded = “TextItem”).  Although this does not necessarily apply to sub line items, it is important to note that this is a possible type of line item.  These line items are used to communicate textual information, and should not have any pricing, quantity, or delivery information associated with them, although these text items may be associated with actual items.  The next type of line item is a component group item (LineItemTypeCoded = “ComponentGroup”).  These items are made up of other items, i.e. they are parent items.  The final line item type is a regular line item.  These are typical line items that are not made up of other items, although they may be components of another item.

Referencing a Parent Item
If an item has components, it is noted with the line item type of “ComponentGroup”.  The components of this line item reference the parent using the //BaseItemDetail/
ParentItemNumber/ element.  For instance, if a computer is being invoiced, and its components (such as the CPU, keyboard, and monitor) are also to be specified in the Invoice, then the components would contain the computer’s line item number in their respective //ParentItemNumber/LineItemNumberReference elements.  It is important to note that these components all have unique line item numbers, and would have line item types of “Item”, unless of course these items too were made up of other items.

Recommended Best Practices
When specifying components of an item, the following practices should be kept in mind.  If a price is specified at both the component group, and the individual component level, the sum of the individual components should equal the total price of the component group.  The following scenario provides an example of this:

4 sets of silverware are being ordered at $30 per set (for a total of $120). If each set is made up of 4 knives, 4 spoons, and 4 forks, then the prices of the components might be $2.50 each.  That is to say that $2.50/fork x 4 forks + $2.50/spoon x 4 spoons + $2.50/knife x 4 knives = $30/set x 4 sets = $120 total.  

In addition, quantities should be multiplied down from the parent item, to determine the actual amount of the component that has been ordered.  For instance, in the silverware example above, 16 forks, 16 spoons, and 16 knives are being ordered (that is to say 4 sets x 4 forks / set = 16 forks, and so on).

Specifying Quantities

The xCBL Invoice contains different structures to specify quantity information:

Total Quantity
The total quantity of the item being invoiced is specified in the //InvoiceBaseItemDetail/BaseItemDetail/InvoicedTotalQuantity/Quantity element.  In general, the total quantity multiplied by the unit price should equal the PaymentCurrencyTotalValue/
MonetaryAmount.  This is may not always be the case if the invoicing currency is different from the order currency.  It is recommended that the units of measure for the TotalQuantity and the units of measure for the UnitPrice be the same.  This is not a hard requirement, but it simplifies the processing of the data by the receiving application.  For information regarding the handling of quantities of sub line items, please see the “Specifying Sub Lines” section above.  

Exception Quantities
The total quantity invoiced may differ from the total quantity ordered or total quantity received.  This information can be specified using the structure found in //InvoiceItemDetail/InvoiceBaseItemDetail/ExceptionQuantities.  Here is where one     would specify the differences between quantity ordered and quantity shipped.  There are also structures to explicitly specify the damaged quantities, unusable quantities, and returned quantities.  Usage of the ExceptionQuantities structure is optional but in certain cases, may prove to be helpful. 

Other Quantities
It may be necessary to communicate other quantities associated with an invoicing item.  Most of these will be specified using the //InvoiceItemDetail/InvoiceBaseItemDetail/
BaseItemDetail/ListOfQuantityCoded element.  In some cases, if the DeliveryDetail structure is not used in the Invoice document but the trading partner still wishes to specify delivery quantities, then this information can be conveyed here

Specifying Invoice Dates

Invoice documents are time sensitive hence it is often necessary to specify various date values to establish important time references:

Invoice Issue Date
The create date of an Invoice document is used in many business processes as a starting counter for various payment terms and for applying discounts.  This field is mandatory and is specified in the Invoice/InvoiceHeader/InvoiceIssueDate field.  

Tax Point Date
The TaxPointDate, defined in Invoice/InvoiceHeader/TaxPointDate, is the used to specify the ‘time of supply’.  This is the date or time that the supply of goods or services is treated as actually taking place.  The tax point date is used to ensure that the proper sales tax rate is applied.  In the case of services, the tax point will be the date that the service to be performed is completed.  If an invoice is processed before the goods or services are delivered or completed, then the tax point date is equal to the date that the invoice is issued.  Similarly, if a payment is received before the goods or services are delivered or completed, then the tax point date is equal to the date that the payment is received.  Hence, this optional structure should be specified if the tax point date differs from the InvoiceIssueDate value.  Usage of this structure will be determined by the business requirements of the trading partners.

Header Level Invoice Dates
At the header level of the Invoice document, there is an element found in //InvoiceHeader/InvoiceDates that can be used to specify important dates.  The most common element used here would be InvoiceDueDate, which will specify the date that payment is due.  Expected and actual ship dates, goods receipt date, tax period and invoicing period can also be explicitly declared within the InvoiceDates structure.  There is also a ListOfOtherInvoiceDate structure which can be used to specify any important dates that are not explicitly declared in the Invoice document.  As a general rule, all information specified in the header level of the document serves as default information for the entire document unless overridden at the line item level.

Line Level Invoice Dates
The date structure defined above in the “Header Level Invoice Dates” section can be overridden at the line level via the LineItemDates structure found in //InvoiceDetail/ListOfInvoiceItemDetail/InvoiceItemDetail.  Which date fields are specified at this level is dependent on the business processes of the trading partners.  

Specifying Pricing

Pricing information within the xCBL 3.5 Invoice can range from very simple, to more complex pricing schemes.  In general, the xCBL recommended pricing detail usage does not vary between the Invoice and Order document.  The pricing detail for the Invoice document can be found in //InvoiceDetail/ListOfInvoiceItemDetail/InvoiceItemDetail/
InvoicePricingDetail/PricingDetail.

Simple Pricing
To specify a basic price for an item, only one //PricingDetail/ListOfPrice/Price element should be used.  Within this element, the price is specified in the //Price/UnitPrice/
UnitPriceValue element.  The units of measure that the price applies to are specified by the //UnitPrice/UnitOfMeasurement element.  An example of this would be to say that the unit price for an item is $3 per item where: 

//UnitPrice/UnitPrice/Value = 3
//UnitPrice/UnitOfMeasurement/UOMCoded = “EA”  

Note that the currency of the unit price is optional, but should be specified if it differs from the default currency set at the header level of the document.  Please refer to the UnitPrice Currency section above.

Price Basis Quantity
In some cases, the pricing may be expressed in terms other than per 1 unit of measure.  For instance, one might want to say that the unit price for paint is $5 per 2 gallons.  In this case, the monetary amount of the price is still specified using the //Price/UnitPrice/UnitPriceValue element, but now, the number of units and the units of measure are expressed using the //Price/PriceBasisQuantity/Quantity element.  In this case:
//PriceBasisQuantity/Quantity/QuantityValue = 2 //PriceBasisQuantity/Quantity/UnitOfMeasurement/UOMCoded = “A76” (gallon)

Tiered Pricing
Either of the pricing schemes above may apply to a range of quantities for the product ordered.  For instance, the paint may be $5 per 2 gallons for the first 100 gallons ordered, but the price may drop of to $4 per 2 gallons for anything over 100 gallons.  In this case, multiple //PricingDetail/ListOfPrice/Price elements should be used, one for each pricing level.  The first level would be expressed the same as the Price Basis Quantity example, only now, the //Price/PriceQuantityRange/Quantity element would also be used.  In this case: 
//PriceQuantityRange/Quantity/QuantityValue = 100 //PriceQuantityRange/Quantity/QuantityValue@SignificanceCoded = “LessThanOrEqualTo” //PriceQuantityRange/Quantity/UnitOfMeasurement/UOMCoded = “A76”

For the next level, the price would be expressed the same way, only with:

//Price/UnitPrice/UnitPriceValue = 4
//PriceQuantityRange/Quantity/QuantityValue = 100 //PriceQuantityRange/Quantity/QuantityValue@SignificanceCoded = “GreaterThan”

Recommended Best Practices
Only one unit of measure should be specified for a given price.  That is to say, that when a price basis quantity is specified, the units of measure in the UnitPrice element should not be used.  When specifying units of measure for a unit price, or for a price basis quantity, it is strongly recommended that this be done in the same units of measure that the item is being ordered in.  This allows for straightforward calculation of total prices.  However, if this is not possible, the //Price/CalculatedPriceBasisQuantity/Quantity element should be used to express the price in terms of the units of measure that the line item is being ordered in.  The following example shows how the CalculatedPriceBasisQuantity element would be used:

Paint is being ordered in cans (each).  
The //BaseItemDetail/ListOfDimension element should specify the volume of the can (4 gallons for this example).  
If the price is specified as $5 / 2 gallons;

//Price/UnitPrice/UnitPriceValue = 5
//PriceBasisQuantity/Quantity/QuantityValue = 2 //PriceBasisQuantity/Quantity/UnitOfMeasurement/UOMCoded = “A76” (gallon)

then the calculated price basis quantity would be 0.5 cans (each):

(4 gallons / can) x (1 / 2 gallons) = (2 / cans) = 0.5 cans

This would be represented by:

//Price/UnitPrice/UnitPriceValue = 5
//Price/CalculatedPriceBasisQuantity/Quantity/QuantityValue = 0.5
//Price/CalculatedPriceBasisQuantity/Quantity/UnitOfMeasurement/UOMCoded = “EA” (each)

Thus the unit price can be calculated as $5 / 0.5 can or $10 / can.  This price when multiplied by the total quantity ordered would yield the total price for the line item.

Specifying Tax Information

Taxes, Allowances and Charges
The overall tax information for the invoice is specified at the header level in //InvoiceHeader/InvoiceTaxReference.  This is intended to serve as the default tax information for the entire invoice.  Taxes that apply to the pricing of an item are specified in the //PricingDetail/Tax element.  At the header level, the overall allowance and charge information for the invoice is specified in //InvoiceHeader/InvoiceAllowancesOrCharges.  Allowances or charges for the item should be expressed in the //PricingDetail/
ItemAllowancesOrCharges/ListOfAllowOrCharge element.  

Tax IDs
Explicit tax identification information can be specified for the Buyer, Seller, and RemitTo parties.  This is found in the Invoice/InvoiceHeader/InvoiceParty structure respectively in the BuyerTaxInformation, SellerTaxInformation, and RemitToTaxInformation structures.  If it is necessary to specify tax identification information for any additional parties not listed above, then it is recommended to map this information in the Party element using the //ListOfIdentifier/Identifier/Ident field where the //ListOfIdentifier/Identifier/Agency field is used to specify the organization that assigns the tax identification numbers.  For example, there is not an explicit BillToTaxInformation structure within InvoiceParties.  Hence, the tax ID of the BillTo should be mapped into //InvoiceParty/BillToParty/Party/ListOfIdentifier/Identifier/Ident.         

Specifying Payment Instructions

Payment instructions are a crucial part of invoicing.  This information is not always required in the Invoice document since it is oftentimes stated elsewhere.  In many cases, the payment instructions related information is outlined in a partner agreement or contract before trading partners begin to transact.  This information may also be explicitly outlined in the original Order document and may not need to be reiterated on the Invoice.  In other cases, the trading partners have this type of information stored at the master data level where terms and discounts are associated with particular customers

Payment Terms
The payment terms are specified using //InvoiceHeader/InvoicePaymentInstructions/
PaymentTerms.  A trading partner may have multiple payment terms hence this structure may be repeated as needed.  All payment terms are specified at the header level of the Invoice and hence will apply to the entire document.

Discounts
There are two methods for specifying discount detail within the Invoice document.  To avoid confusion, it is recommended that the //InvoiceHeader/InvoicePaymentInstructions/
PaymentTerms/PaymentTerm/PaymentTermDetails/Discounts structure is used to specify all discount information at the header level.  In general, it is recommended to avoid using the //InvoicePaymentInstructions/PaymentTerms/Discounts structure.

Payment Method
The method of payment for the Invoice can be specified by using the //InvoiceHeader/
InvoicePaymentInstructions/PaymentMethod structure.  The means by which the funds should be transferred is specified in the //PaymentMethod/PaymentMeanCoded field.  If a bank transfer is to take place, then the banking and account details for both the “transfer to” and “transfer from” accounts can be specified respectively in //PaymentMethod/FITransfer/ToFITransfert and //PaymentMethod/FITransfer/FromFITransfer.  If the funds are to be transferred via a payment system such as SWIFT or ACH, then this should be specified using //PaymentMethod/PaymentSystemCoded.  

Specifying Totals

In general, all invoice total values can be specified in the InvoiceTotals structure found in the Invoice/InvoiceSummary section.  InvoiceTotals represents the total values of the invoice and should be summations of all the line item totals.  Please note that all total values are specified in terms of MonetaryValue.  

Non-MonetaryValue Totals
xCBL does not currently support other data types within the InvoiceTotals section (i.e., totals declaration in text format).  Hence if there is a business requirement to specify invoice totals in a format other than MonetaryValue, then it is recommended that Invoice/InvoiceHeader/ListOfStructuredNote/StructuredNote be used for these purposes.  The total value should be placed in GeneralNote and a description of the value should be placed in NoteID.
example:
<StructuredNote>
<GeneralNote>TwoHundredDollarsAndFiftyCents</GeneralNote>
			<NoteID>TotalNetValueInTextFormat</NoteID> 
		</StructuredNote>

Handling Gross & Net Values
The most common elements used are the NetValue and GrossValue fields.  The GrossValue represents the summation of all the line items before any deductions and charges are applied.  The NetValue holds the total amount to be paid on the Invoice by the stated InvoiceDueDate.  This is the gross value less deductions and charges. 

Handling Discount Totals
The total discount amount that could apply to this Invoice is specified in the TotalDiscount element found in //InvoiceSummary/InvoiceTotals.   The total amount due (NetValue) on an invoice less the discount amount can be specified in the TotalAmountMinusDiscount element.

Handling Tax Totals
The TaxableValue is the total value of the invoice that is taxable.  This may not necessarily be the same as the NetValue since some invoiced items may not be taxable.  This is stated in terms of the invoice currency and is specified in //InvoiceSummary/InvoiceTotals/
TaxableValue.  The TaxableValueInTaxAccountingCurrency is the total taxable amount stated in terms of the TaxAccountingCurrency.  This is specified in //InvoiceSummary/
InvoiceTotals/TaxableValueInTaxAccountingCurrency.  The total of all tax levied on the Invoice including all rates and tax regimes, is specified in //InvoiceSummary/
InvoiceTotals/TotalTaxAmount.     

Line Item Totals
The total amount for a given line item is specified in //InvoiceDetail/
ListOfInvoiceItemDetail/InvoiceItemDetail/InvoicePricingDetail/PaymentCurrencyTotalValue/ /MonetaryAmount.  It is recommended that the value be equal to the TotalQuantity multiplied by the UnitPrice of the item along with any taxes, allowances, or charges calculated appropriately into the amount.  Please note that this should all be specified in the invoicing currency.  If there is a requirement to specify additional line item totals, then it is suggested that the //InvoicePricingDetail/PricingDetail/LineItemTotal structure be used.  This could possibly contain the line item “gross value” which is the value of the TotalQuantity multiplied by the UnitPrice.  It could also contain the total amount for a given line item in terms of the originating order currency, in the case where the invoicing currency differs from the originating order currency.  In general, usage of the line item total values will depend on the business requirements of the trading partners involved.  It is important that these details be communicated and agreed upon between trading partners.

Specifying Custom Fields

Legal requirements for Invoices vary from country to country.  Some companies and industries have a stricter set of requirements for their invoicing structure than others. Therefore, xCBL has designated some generic user defined fields for this type of information.  Please note that if these fields do not meet the trading partner’s Invoice requirements, then the follow up plan would be to use the ListOfStructuredNote element. 

Country Specific Requirements
The structure found in Invoice/InvoiceHeader/CountrySpecificRequirements is intended for information that is legally required by a country on an invoice.  Within this structure, a user would specify the country for which the information is required in //CountrySpecificRequirements/OtherCountryRequirments/CountryRequirement/
Country.  The details of the required data is declared in //CountrySpecificRequirements/
OtherCountryRequirments/CountryRequirement/ListOfSpecificRequirment.  The type of requirement, a reference to the requirement, and additional details can be provided within this structure.

Name Value Set
If trading partners require data not explicitly defined within the Invoice document, then it may be possible to use the generic data structure provided in Invoice/InvoiceHeader/
ListOfNameValueSet.  This structure is basically a set of name value pairs.  The usage of these elements must be determined and agreed upon between the trading partners.  If there is just a single user defined value to specify, then it may be best to use the ListOfStructureNote element.  The ListOfNameValueSet is designed to specify a group of values.    
	example:
		<NameValueSet>
<SetName>InternalCompanyCodesToBePrintd</SetName>
			<ListOfNameValuePair>
<NameValuePair>
<Name> PlantCode</Name>
					<Value>ABC</Value>
				</NameValuePair>
<NameValuePair>
<Name> RegulationCode </Name>
					<Value>123-ABC</Value>
				</NameValuePair>
<NameValuePair>
<Name> InternalReference </Name>
					<Value>XYZ</Value>
				</NameValuePair>
			</ListOfNameValuePair>
		</NameValueSet>