Implementation Guideline
Confirm BOD
Repository Version Rev4.5.4
Copyright © 2007 STAR – Standards for Technology in Automotive Retail. All rights reserved
Implementation Guideline
Confirm BOD
Repository Version Rev4.5.4
Copyright © 2007 STAR – Standards for Technology in Automotive Retail. All rights reserved
This document is a guideline on how to use the Confirm Business Object Document (BOD). The Confirm BOD has been defined in the context of STAR for the Automotive Retail Industry. The ConfirmBOD reports on the outcome of processing a BOD. Only one BODOutcome will be returned, corresponding to a previously transmitted BOD that was earmarked for returning an outcome notification.
The Confirm BOD Implementation Guidelines provide detailed information regarding the structure and meaning of the Confirm BOD and corresponds directly to the Confirm BOD schema. In addition to structure and meaning, the Implementation Guidelines identify various business rules for specific fields/components that due to their nature, i.e. field interdependence, are not possible to express using schema. Please note that although these business rules are not included in the schema, they MUST be followed to be STAR compliant. Therefore, the Confirm BOD Implementation Guidelines must be used in concert with the Confirm BOD schema during development and should NOT be considered a supplement or substitution to the schema. For more information regarding STAR XML data compliance, please review the STAR Data Compliance Guidelines document located on the STAR Web site.
For a copy of the corresponding Confirm BOD schema, please download the appropriate STAR schema repository from the XML portion of the STAR website (www.starstandard.org). Prior to downloading the schema, users are encouraged to download the STAR XML Reference/Implementation document also located on the XML portion of the STAR website. This document provides an overview of the STAR BOD development methodology, how to download and read STAR schema, and various frequently asked questions related to the implementation of STAR BODs.
STAR has followed the Open Application Group's BOD methodology to develop the Confirm BOD. Where possible STAR has mapped to existing OAGI Confirm BOD fields and components.
For more information on the Open Applications Group's BODs and related documentation please refer to the Open Applications Group's website at www.openapplications.org.
STAR uses the same Noun in the schema for all the Noun/Verb combinations of the Confirm BOD. Please refer to each Noun/Verb combination within this document to understand the requirements for each specific BOD. Although the Noun will always have every field defined for the Noun in the schema, each Noun/Verb combination may not use all of the fields. If a field is not used by a BOD, it will not be shown in the detail within this document.
The ConfirmBOD Binary Collaboration starts with the request of for Confirmation from the Initiator of the original BOD. In response, a ConfirmBOD is sent to report on the outcome of processing the original BOD. This process occurs on demand as is needed. Note: This scenario is an example of how the ConfirmBOD can be used. Implementations may vary.
The ConfirmBOD is used to respond to a request to confirm the receipt of information by a receiving system. The ConfirmBOD indicates whether or not the receiving system was able to process the original message. In order to process the original message successfully, the receiving system must be able to successfully process every line of code necessary to complete the original message. This processing includes all units of work from parsing the message to processing the message through a backend legacy system.
The request for confirmation is set by the sending application in the verb field of the BOD. All STAR BODs require one Verb element that can be found in the DataArea of the BOD. The Verb indicates the action to be performed on the Noun.
All Verb elements contain a confirm attribute. The confirm attribute has three
possible settings:
1. Always - The ConfirmBOD should always be sent.
2. Never - The ConfirmBOD should never be sent.
3. OnChange - The ConfirmBOD should be sent on change (i.e., only
be sent when there are errors).
In order for a ConfirmBOD to be sent, the Sender of the original message must select one of the three confirm attribute values. If the Sender does not elect to receive a Confirm, a ConfirmBOD should not be sent. This is because the Sender, not expecting the ConfirmBOD, would have no way of handling the BOD. For simplicity, STAR suggests as a best practice that the OnChange attribute be used when requesting a ConfirmBOD.
The ConfirmBOD covers syntactical as well as business content-related errors that are not specific to a particular BOD. If an error code is defined in the ConfirmBOD as well as a response-type message (e.g., AcknowledgePartsOrder) it is recommended that the ConfirmBOD be used for implementation consistency. The ConfirmBOD may also be used to indicate that the receiver of the original message was not able to generate a successful response message. Example scenarios include the receiver is not able to properly validate the outbound message, the outbound message could not be properly compressed, etc. In scenarios such as these, the ConfirmBOD would be sent to the original sender indicating the failure on the part of the receiving system to generate a valid response. For the sender's reference, the ConfirmBOD would contain the original ApplicationArea of the original message sent.
The relationship diagram identifies all of the various components or building blocks of information used in the Confirm BOD BOD. This diagram visually depicts the relationships of the components using symbolic indentation and their occurrence in the BOD. Note: That this is an approximation of the Components, and may not reflect the exact implementation. Also, some fields are displayed in the diagram. This diagram should only be used as a starting point and not an absolute reference.
| Target Namespace | http://www.starstandards.org/STAR |
|---|---|
| Element and Attribute Namespaces |
|
| Documentation | This schema is made available under an Eclipse Public Licenses 1.0. This license may be found in the STAR/License directory as well as the STAR BOD Guidelines. More information at: http://www.starstandard.org/. |
| Prefix | Namespace |
|---|---|
| Default namespace | http://www.starstandards.org/STAR |
| xml | http://www.w3.org/XML/1998/namespace |
| xsd | http://www.w3.org/2001/XMLSchema |
| Name | ApplicationArea |
|---|---|
| Type | ApplicationArea |
| Nillable | no |
| Abstract | no |
| Documentation | Provides the information that an application may need to know in order to communicate in an integration of two or more business applications. The ApplicationArea is used at the applications layer of communication. While the integration frameworks web services and middleware provide the communication layer that OAGIS operates on top of. More information at: http://www.openapplications.org/oagis. Provides the information that an application may need to know in order to communicate in an integration of two or more business applications. The ApplicationArea is used at the applications layer of communication. While the integration frameworks web services and middleware provide the communication layer that OAGIS operates on top of. More information at: http://www.openapplications.org/oagis. |
|
| Name | BOD |
|---|---|
| Type | BOD |
| Nillable | no |
| Abstract | no |
| Documentation | The outcome of processing a specific BOD. Describes overall/summary outcome, plus the outcome of processing each noun of the BOD. Includes noun-specific error and/or warning messaages encountered during processing. May include summary and/or roll-up messages at the BOD level. More information at: http://www.openapplications.org/oagis. |
|
| Name | BODFailure |
|---|---|
| Type | ProcessingFailure |
| Nillable | no |
| Abstract | no |
| Documentation | The processing of the BOD has failed. Provides a list of error and warning messages that explain the failure. Specific outcomes of processing each noun are reported in each of the NounOutcome elements. More information at: http://www.starstandards.org. |
|
| Name | BODOutcomeValue |
|---|---|
| Type | OutcomeValue |
| Nillable | no |
| Abstract | yes |
| Documentation | The possible BOD-level outcomes; an extensible list. More information at: http://www.starstandards.org. |
|
| Name | BODPartialSuccess |
|---|---|
| Type | ProcessingFailure |
| Nillable | no |
| Abstract | no |
| Documentation | The processing of at least one noun in the BOD has failed. Error and warning messages may explain the failure. Specific outcomes of processing each noun are reported in each of the NounOutcome elements. More information at: http://www.starstandards.org. |
|
| Name | BODSuccess |
|---|---|
| Type | ProcessingSuccess |
| Nillable | no |
| Abstract | no |
| Documentation | The processing of the BOD was a success. Possible, non-fatal warning messages may appear here. Specific outcomes of processing each noun are reported in each of the NounOutcome elements. More information at: http://www.openapplications.org/oagis. |
|
| Name | Confirm |
|---|---|
| Type | Confirm |
| Nillable | no |
| Abstract | no |
| Documentation | The Confirm verb is used to respond to a request to confirm the receipt of information by the receiving system. The request for confirmation is set by the sending application in the ApplicationArea\Sender\Confirmation field of the original BOD. The Confirm conveys the result of the original request i.e. whether or not the message was understood and was successfully processed. An example of this is Confirm BOD. More information at: http://www.openapplications.org/oagis. |
| Name | ConfirmBOD |
|---|---|
| Type | ConfirmBOD |
| Nillable | no |
| Abstract | no |
| Name | ErrorMessage |
|---|---|
| Type | ErrorMessage |
| Nillable | no |
| Abstract | no |
| Documentation | Error message encountered during processing. More information at: http://www.starstandards.org. |
| Name | Header |
|---|---|
| Type | BODHeader |
| Nillable | no |
| Abstract | no |
| Documentation | Information about the BOD that was processed, including identifying information and a summary-level indication of the outcome of processing the BOD. More information at: http://www.openapplications.org/oagis. |
|
| Name | Noun |
|---|---|
| Type | Noun |
| Nillable | no |
| Abstract | yes |
|
| Name | NounFailure |
|---|---|
| Type | ProcessingFailure |
| Nillable | yes |
| Abstract | no |
| Documentation | Indicates that the processing of this noun has failed, and provides error and warning messages that arose during the processing of the noun. More information at: http://www.starstandards.org. |
| Business Rule: | If this component is used, either the ErrorMessage or the WarningMessage component must be used. |
| Name | NounOutcome |
|---|---|
| Type | NounOutcome |
| Nillable | no |
| Abstract | no |
| Documentation | Each NounOutcome captures the outcome of processing each noun of the BOD. More information at: http://www.starstandards.org. |
|
| Name | NounOutcomeValue |
|---|---|
| Type | OutcomeValue |
| Nillable | no |
| Abstract | yes |
| Documentation | The specific outcome of processing the noun, with supporting detail. More information at: http://www.starstandards.org. |
|
| Name | NounSuccess |
|---|---|
| Type | ProcessingSuccess |
| Nillable | yes |
| Abstract | no |
| Documentation | Indicates that the processing of this noun has succeeded; may provide non-fatal warning messages that arose during the processing of the noun. More information at: http://www.starstandards.org. |
| Business Rule: | If this component is used, either the WarningMessage or the SuccessMessage component must be used. |
| Name | SuccessMessage |
|---|---|
| Type | SuccessMessage |
| Nillable | no |
| Abstract | no |
| Documentation | Message indicating a success. More information at: http://www.starstandard.org. |
|
| Name | Verb |
|---|---|
| Type | Verb |
| Nillable | no |
| Abstract | yes |
| Name | WarningMessage |
|---|---|
| Type | WarningMessage |
| Nillable | no |
| Abstract | no |
| Documentation | Non-fatal warning message encountered during processing. More information at: http://www.starstandards.org. |
| Super-types: | None |
|---|---|
| Sub-types: | None |
| Name | ApplicationArea |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| Sender | Identifies characteristics and control identifiers that relate to the application that created the Business Object Document. The sender area can indicate the logical location of the application and/or database server, the application, and the task that was processing to create the BOD. | Required | |
| CreationDateTime | is the date time stamp that the given instance of the Business Object Document was created. This date must not be modified during the life of the Business Object Document. | Required |
DateTime fields must be formatted as XML Schema
Datetimes in UTC/GMT format without offsets.
Example: 2003-11-05T13:15:30Z
|
| Signature | If the BOD is to be signed the signature element is included, otherwise it is not. Signature supports any digital signature that maybe used by an implementation of OAGIS. The qualifyingAgency identifies the agency that provided the format for the signature. This element supports any digital signature specification that is available today and in the future. This is accomplished by not actually defining the content but by allowing the implementation to specify the digital signature to be used via an external XML Schema namespace declaration. The Signature element is defined to have any content from any other namespace. This allows the user to carry a digital signature in the xml instance of a BOD. The choice of which digital signature to use is left up to the user and their integration needs. | Optional | |
| BODId | The BODId provides a place to carry a Globally Unique Identifier (GUID) that will make each Business Object Document instance uniquely identifiable. This is a critical success factor to enable software developers to use the Globally Unique Identifier (GUID) to build the following services or capabilities: 1. Legally binding transactions, 2. Transaction logging, 3. Exception handling, 4. Re-sending, 5. Reporting, 6. Confirmations, 7. Security. | Optional | |
| Destination | Information related to the receiver of the BOD | Required |
| Super-types: | Noun < BOD (by extension) |
|---|---|
| Sub-types: | None |
| Name | BOD |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| Noun | Required | ||
| Header | Information about the BOD that was processed, including identifying information and a summary-level indication of the outcome of processing the BOD. | Required | |
| NounOutcome | Each NounOutcome captures the outcome of processing each noun of the BOD. | Optional |
| Super-types: | HeaderBase < BODHeader (by extension) |
|---|---|
| Sub-types: | None |
| Name | BODHeader |
|---|---|
| Abstract | no |
| Documentation | Information about the BOD that was processed, including identifying information and a summary-level indication of the outcome of processing the BOD. More information at: http://www.starstandards.org. |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| DocumentDateTime | Is the date and time the document was last created. This is not the date and time that the BOD message instance was created. | Optional | |
| SecondaryPassword | Secondary password used to validate access to the dealer information | Optional | |
| SecondaryDealerNumber | Identifies secondary dealer number if different than primary "Dealer Number" | Optional | |
| OriginalApplicationArea | A copy of the ApplicationArea for the original BOD that was processed. Present either as additional reference information, or for use in identifying the BOD in situations where a BODReference is not known. | Required | |
| OriginalBODReference | Reference to the original BOD that was processed. | Optional | (INACTIVE) |
| BODOutcomeValue | The possible BOD-level outcomes; an extensible list. | Optional |
| Super-types: | None |
|---|---|
| Sub-types: |
|
| Name | BusinessObjectDocument |
|---|---|
| Abstract | no |
| Attribute | Description | Requirement | Business Rules |
|---|---|---|---|
| revision | This should contain the STAR repository version in the following recommended format. 4.2.1_M20080416. Where the first part indicates the version of the STAR repository and anything after the _ indicates the Milestone build that is being used. If referring to an official published version then only the STAR Repository version is required. | Optional | |
| release | Indicates the OAGIS release that this BOD belongs. | Optional | |
| environment | Indicates whether this BOD is being sent in a "Test" or a "Production" mode. If the BOD is being sent in a test mode, it's information should not affect the business operation. However, if the BOD is sent in "Production" mode it is assumed that all test has been complete and the contents of the BOD are to affect the operation of the receiving business application(s). | Optional | |
| lang | Indicates the language that the contents of the BOD is in unless otherwise stated. | Optional | |
| bodVersion | Deprecated as of STAR 4.2.2. It is recommended to use the revision attribute to identify the repository and the noun. May be removed in a new major version of the STAR repository. | Optional |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| ApplicationArea | Provides the information that an application may need to know in order to communicate in an integration of two or more business applications. The ApplicationArea is used at the applications layer of communication. While the integration frameworks web services and middleware provide the communication layer that OAGIS operates on top of. | Required |
| Super-types: | Verb < Confirm (by extension) |
|---|---|
| Sub-types: | None |
| Name | Confirm |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| Verb | Required |
| Super-types: | BusinessObjectDocument < ConfirmBOD (by extension) |
|---|---|
| Sub-types: | None |
| Name | ConfirmBOD |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| ApplicationArea | Provides the information that an application may need to know in order to communicate in an integration of two or more business applications. The ApplicationArea is used at the applications layer of communication. While the integration frameworks web services and middleware provide the communication layer that OAGIS operates on top of. | Required | |
| DataArea | Required |
| Super-types: | None |
|---|---|
| Sub-types: | None |
| Name | ConfirmBODDataArea |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| Confirm | The Confirm verb is used to respond to a request to confirm the receipt of information by the receiving system. The request for confirmation is set by the sending application in the ApplicationArea\Sender\Confirmation field of the original BOD. The Confirm conveys the result of the original request i.e. whether or not the message was understood and was successfully processed. An example of this is Confirm BOD. | Required | |
| BOD | The outcome of processing a specific BOD. Describes overall/summary outcome, plus the outcome of processing each noun of the BOD. Includes noun-specific error and/or warning messaages encountered during processing. May include summary and/or roll-up messages at the BOD level. | Required |
| Super-types: | xsd:string < Description (by extension) |
|---|---|
| Sub-types: | None |
| Name | Description |
|---|---|
| Abstract | no |
| Documentation | Description More information at: http://www.starstandard.org. |
| Attribute | Description | Requirement | Business Rules |
|---|---|---|---|
| language | The ISO language code that the description is written. | Optional |
| Super-types: | None |
|---|---|
| Sub-types: | None |
| Name | Destination |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| DestinationNameCode | Code for destination of file (i.e.Short Manufacturer or DSP code) | Optional |
Must use a valid code from the ShortMfg/RSP list on
http://www.starstandards.org
|
| DestinationURI | Physical address of the destination | Optional | |
| DestinationSoftwareCode | Additional information about the destination application | Optional | |
| DestinationSoftware | For which software destination file is intended (may not be known). | Optional | |
| DealerNumber | Target Dealer Code receiving information | Optional | |
| StoreNumber | Dealer code store number (DMS assigned) | Optional | |
| AreaNumber | Dealer code area number (DMS vendor assigned) | Optional | |
| DealerCountry | Target Dealer country location | Optional | |
| PartyId | The Party Id field uniquely identifies the Receiver of the message. This element can be used for parties within the Automotive Community as well as external parties. Party Id is not intended as a replacement for the Dealer Number. Suggested formats for OEMs or other large institutions include: DUNs Number, ShortMfgCode + DUNs, or ShortMfgCode. The suggested format for Dealers is: ShortMfgCode+Dealer Number. | Optional | |
| LocationId | The Location Id field uniquely identifies the location of the Receiver of a message. This Id may be aligned with a physical address or data centers. This field provides an additional level of granularity beyond the usage of the Party Id for additional routing and deliver of data. | Optional | |
| ServiceId | The Service Id field identifies the particular service to which a message is being sent, e.g., an inventory service. | Optional |
| Super-types: | xsd:string < Id (by extension) < DocumentId (by extension) |
|---|---|
| Sub-types: | None |
| Name | DocumentId |
|---|---|
| Abstract | no |
| Documentation | Is the identifier for the document. More information at: http://www.starstandard.org. |
| Super-types: | None |
|---|---|
| Sub-types: |
|
| Name | DocumentReference |
|---|---|
| Abstract | no |
| Documentation | Identifies another document within the scope of the OAGIS specification, such as a PurchaseOrder or Invoice that maybe associated with a particular Business Object Document. More information at: http://www.starstandard.org. |
| Field/Component | Description | Requirement | Business Rules |
|---|
| Super-types: | ProcessingOutcomeMessage < ErrorMessage (by extension) |
|---|---|
| Sub-types: | None |
| Name | ErrorMessage |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| ProcessingOutcomeMessage | Required | ||
| ErrorType | Optional | ||
| ReferenceName | Optional | ||
| ReferenceValue | Optional |
| Super-types: | DocumentReference < GenericDocumentReference (by extension) |
|---|---|
| Sub-types: | None |
| Name | GenericDocumentReference |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| DocumentReference | Identifies another document within the scope of the OAGIS specification, such as a PurchaseOrder or Invoice that maybe associated with a particular Business Object Document. | Required | |
| DocumentId | Optional | ||
| DocumentDateTime | The Datetime of the referenced document. | Optional |
| Super-types: | None |
|---|---|
| Sub-types: |
|
| Name | HeaderBase |
|---|---|
| Abstract | no |
| Documentation | Used on all STAR BODs More information at: http://www.starstandard.org. |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| DocumentDateTime | Is the date and time the document was last created. This is not the date and time that the BOD message instance was created. | Optional | |
| SecondaryPassword | Secondary password used to validate access to the dealer information | Optional | |
| SecondaryDealerNumber | Identifies secondary dealer number if different than primary "Dealer Number" | Optional |
| Super-types: | xsd:string < Id (by extension) |
|---|---|
| Sub-types: | None |
| Name | Id |
|---|---|
| Abstract | no |
| Documentation | Party Identification number More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < Id (by extension) < LocationId (by extension) |
|---|---|
| Sub-types: | None |
| Name | LocationId |
|---|---|
| Abstract | no |
| Documentation | Code identifying a physical location More information at: http://www.starstandard.org. |
| Super-types: | None |
|---|---|
| Sub-types: |
|
| Name | Noun |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|
| Super-types: | None |
|---|---|
| Sub-types: | None |
| Name | NounOutcome |
|---|---|
| Abstract | no |
| Documentation | Each NounOutcome captures the outcome of processing each noun of the BOD. More information at: http://www.starstandards.org. |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| DocumentId | Optional | ||
| NounOutcomeValue | The specific outcome of processing the noun, with supporting detail. | Optional | |
| DocumentDateTime | The date and time the document was last created. This is not the date and time that the BOD message instance was created. | Optional |
| Super-types: | None |
|---|---|
| Sub-types: |
|
| Name | OutcomeValue |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|
| Super-types: | xsd:string < Id (by extension) < PartyId (by extension) |
|---|---|
| Sub-types: | None |
| Name | PartyId |
|---|---|
| Abstract | no |
| Documentation | Party Identification Number More information at: http://www.starstandard.org. |
| Super-types: | OutcomeValue < ProcessingFailure (by extension) |
|---|---|
| Sub-types: | None |
| Name | ProcessingFailure |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| OutcomeValue | Required | ||
| ErrorMessage | Error message encountered during processing. | Optional | |
| WarningMessage | Non-fatal warning message encountered during processing. | Optional |
| Super-types: | None |
|---|---|
| Sub-types: |
|
| Name | ProcessingOutcomeMessage |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| ApplicationReasonCode | Required | ||
| Description | Required | ||
| MessageReasonCode | Required | ||
| Description | Optional | ||
| MessageReasonCode | Optional |
| Super-types: | OutcomeValue < ProcessingSuccess (by extension) |
|---|---|
| Sub-types: | None |
| Name | ProcessingSuccess |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| OutcomeValue | Required | ||
| WarningMessage | Non-fatal warning message encountered during processing. | Optional | |
| SuccessMessage | Message indicating a success. | Optional |
| Super-types: | xsd:string < Description (by extension) < ReferenceName (by extension) |
|---|---|
| Sub-types: | None |
| Name | ReferenceName |
|---|---|
| Abstract | no |
| Documentation | The name of the field/tag that references/idenitifies the key data elements the senders request/response bod. More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < Id (by extension) < SecondaryDealerNumber (by extension) |
|---|---|
| Sub-types: | None |
| Name | SecondaryDealerNumber |
|---|---|
| Abstract | no |
| Documentation | Identifies secondary dealer number if different than primary "Dealer Number" More information at: http://www.starstandard.org. |
| Super-types: | SenderBase < Sender (by extension) |
|---|---|
| Sub-types: | None |
| Name | Sender |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| LogicalId | Provides the logical location of the server and applications from which the Business Object Document originated. It can be used to establish a logical to physical mapping, however its use is optional. Each system or combination of systems should maintain an external central reference table containing the logical names or logical addresses of the application systems in the integration configuration. This enables the logical names to be mapped to the physical network addresses of the resources needed on the network. Note: The technical implementation of this Domain Naming Service is not dictated by this specification. This logical to physical mapping may be done at execution time by the application itself or by a middleware transport mechanism, depending on the integration architecture used. This provides for a simple but effective directory access capability while maintaining application independence from the physical location of those resources on the network | Optional | |
| Component | Provides a finer level of control than Logical Identifier and represents the business application that issued the Business Object Document. Its use is optional. For STAR's use this is the DCS Software code name | Required | |
| Task | Describes the business event that initiated the need for the Business Object Document to be created. For STAR, the task is defined in the Implementation Guidelines for each BOD. It is usually a short description of the BOD. Ex: SalesLead, CreditDecision, etc. | Required | |
| ReferenceId | Enables the sending application to indicate the instance identifier of the event or task that caused the BOD to be created. This is used to correlate a response BOD to an originating BOD | Optional | |
| AuthorizationId | Identifyies the authorization level of the user or application that is sending the Business Object Document Message. This authorization level being recognized be the receiving system indicates what can be done on the receiving system. For STAR, this is the User ID. | Optional | |
| CreatorNameCode | DCS Software Creator Code | Required | |
| SenderNameCode | Additional information about the sending platform (i.e., Short MFG or DSP code). | Required |
Must use a valid code from the ShortMfg/RSP list on
http://www.starstandards.org
|
| SenderURI | Physical address of the sender | Optional | |
| DealerNumber | Dealer Code of source of information | Optional | |
| StoreNumber | Dealer code store number (DMS assigned) | Optional | |
| AreaNumber | Dealer code area number (DMS vendor assigned) | Optional | |
| DealerCountry | Source Dealer country location | Optional | |
| Language | This code is used to define the language of the data used in this transaction | Optional | |
| DeliverPendingMailInd | Indicates if the user requests to receive pending mail that has been stored and has yet not been delivered yet. By selecting 0, the user will only receive the response for the current transaction the user is performing. | Optional | |
| Password | Token for application specific authentication. Used to authenticate dealership/users through application specific security | Optional | |
| SystemVersion | The sender's software version number. | Optional | |
| PartyId | The Party Id field uniquely identifies the Sender of the message. This element can be used for parties within the Automotive Community as well as external parties. Party Id is not intended as a replacement for the Dealer Number. Suggested formats for OEMs or other large institutions include: DUNs Number, ShortMfgCode + DUNs, or ShortMfgCode. The suggested format for Dealers is: ShortMfgCode+Dealer Number. | Optional | |
| LocationId | The Location Id field uniquely identifies the location of the Sender of a message. This Id may be aligned with a physical address or data centers. This field provides an additional level of granularity beyond the usage of the Party Id for additional routing and deliver of data. | Optional | |
| ServiceId | The Service Id field identifies the particular service from which a message is being sent, e.g., an inventory service. | Optional |
| Super-types: | None |
|---|---|
| Sub-types: |
|
| Name | SenderBase |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| LogicalId | Provides the logical location of the server and applications from which the Business Object Document originated. It can be used to establish a logical to physical mapping, however its use is optional. Each system or combination of systems should maintain an external central reference table containing the logical names or logical addresses of the application systems in the integration configuration. This enables the logical names to be mapped to the physical network addresses of the resources needed on the network. Note: The technical implementation of this Domain Naming Service is not dictated by this specification. This logical to physical mapping may be done at execution time by the application itself or by a middleware transport mechanism, depending on the integration architecture used. This provides for a simple but effective directory access capability while maintaining application independence from the physical location of those resources on the network | Optional | |
| Component | Provides a finer level of control than Logical Identifier and represents the business application that issued the Business Object Document. Its use is optional. For STAR's use this is the DCS Software code name | Required | |
| Task | Describes the business event that initiated the need for the Business Object Document to be created. For STAR, the task is defined in the Implementation Guidelines for each BOD. It is usually a short description of the BOD. Ex: SalesLead, CreditDecision, etc. | Required | |
| ReferenceId | Enables the sending application to indicate the instance identifier of the event or task that caused the BOD to be created. This is used to correlate a response BOD to an originating BOD | Optional | |
| AuthorizationId | Identifyies the authorization level of the user or application that is sending the Business Object Document Message. This authorization level being recognized be the receiving system indicates what can be done on the receiving system. For STAR, this is the User ID. | Optional |
| Super-types: | xsd:string < Id (by extension) < ServiceId (by extension) |
|---|---|
| Sub-types: | None |
| Name | ServiceId |
|---|---|
| Abstract | no |
| Documentation | The Service Id field identifies the particular service to or from which a message is being sent, e.g., an inventory service. More information at: http://www.starstandard.org. |
| Super-types: | None |
|---|---|
| Sub-types: | None |
| Name | Signature |
|---|---|
| Abstract | no |
| Attribute | Description | Requirement | Business Rules |
|---|---|---|---|
| qualifyingAgency | Optional |
| Field/Component | Description | Requirement | Business Rules |
|---|
| Super-types: | ProcessingOutcomeMessage < SuccessMessage (by extension) |
|---|---|
| Sub-types: | None |
| Name | SuccessMessage |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| ProcessingOutcomeMessage | Required |
| Super-types: | None |
|---|---|
| Sub-types: |
|
| Name | Verb |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|
| Super-types: | ProcessingOutcomeMessage < WarningMessage (by extension) |
|---|---|
| Sub-types: | None |
| Name | WarningMessage |
|---|---|
| Abstract | no |
| Field/Component | Description | Requirement | Business Rules |
|---|---|---|---|
| ProcessingOutcomeMessage | Required |
| Super-types: | xsd:string < Code (by restriction) < ApplicationReasonCode (by restriction) |
|---|---|
| Sub-types: | None |
| Name | ApplicationReasonCode |
|---|---|
| Documentation | A software application specific reason code. Used for indicating numeric or text encoded error, success, and warning messages. More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < Code (by restriction) |
|---|---|
| Sub-types: |
|
| Name | Code |
|---|---|
| Documentation | Unique code name More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < Country (by restriction) |
|---|---|
| Sub-types: | None |
| Name | Country |
|---|---|
| Documentation | Country in which the Address is in. Conforms to ISO 3166-2. AF -AFGHANISTAN AL -ALBANIA DZ -ALGERIA AS -AMERICAN SAMOA AD -ANDORRA AO -ANGOLA AI -ANGUILLA AQ -ANTARCTICA AG -ANTIGUA AND BARBUDA AR -ARGENTINA AM -ARMENIA AW -ARUBA AU -AUSTRALIA AT -AUSTRIA AZ -AZERBAIJAN BS -BAHAMAS BH -BAHRAIN BD -BANGLADESH BB -BARBADOS BY -BELARUS BE -BELGIUM BZ -BELIZE BJ -BENIN BM -BERMUDA BT -BHUTAN BO -BOLIVIA BA -BOSNIA AND HERZEGOVINA BW -BOTSWANA BV -BOUVET ISLAND BR -BRAZIL IO-BRITISH INDIAN OCEAN TERRITORY BN -BRUNEI DARUSSALAM BG -BULGARIA BF -BURKINA FASO BI -BURUNDI KH -CAMBODIA CM -CAMEROON CA -CANADA CV -CAPE VERDE KY -CAYMAN ISLANDS CF -CENTRAL AFRICAN REPUBLIC TD -CHAD CL -CHILE CN -CHINA CX -CHRISTMAS ISLAND CC -COCOS (KEELING) ISLANDS CO -COLOMBIA KM -COMOROS CG -CONGO CD -CONGO, THE DEMOCRATIC REPUBLIC OF THE CK -COOK ISLANDS CR -COSTA RICA CI -CÔTE D'IVOIRE HR -CROATIA CU -CUBA CY -CYPRUS CZ -CZECH REPUBLIC DK -DENMARK DJ -DJIBOUTI DM -DOMINICA DO -DOMINICAN REPUBLIC EC -ECUADOR EG -EGYPT SV -EL SALVADOR GQ -EQUATORIAL GUINEA ER -ERITREA EE -ESTONIA ET -ETHIOPIA FK -FALKLAND ISLANDS (MALVINAS) FO -FAROE ISLANDS FJ -FIJI FI -FINLAND FR -FRANCE GF -FRENCH GUIANA PF -FRENCH POLYNESIA TF -FRENCH SOUTHERN TERRITORIES GA -GABON GM -GAMBIA GE -GEORGIA DE -GERMANY GH -GHANA GI -GIBRALTAR GR -GREECE GL -GREENLAND GD -GRENADA GP -GUADELOUPE GU -GUAM GT -GUATEMALA GN -GUINEA GW -GUINEA-BISSAU GY -GUYANA HT -HAITI HM -HEARD ISLAND AND MCDONALD ISLANDS VA -HOLY SEE (VATICAN CITY STATE) HN -HONDURAS HK -HONG KONG HU -HUNGARY IS -ICELAND IN -INDIA ID -INDONESIA IR -IRAN, ISLAMIC REPUBLIC OF IQ -IRAQ IE -IRELAND IL -ISRAEL IT -ITALY JM -JAMAICA JP -JAPAN JO -JORDAN KZ -KAZAKHSTAN KE -KENYA KI -KIRIBATI KP -KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF KR -KOREA, REPUBLIC OF KW -KUWAIT KG -KYRGYZSTAN LA -LAO PEOPLE'S DEMOCRATIC REPUBLIC LV -LATVIA LB -LEBANON LS -LESOTHO LR -LIBERIA LY -LIBYAN ARAB JAMAHIRIYA LI -LIECHTENSTEIN LT -LITHUANIA LU -LUXEMBOURG MO -MACAO MK -MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF MG -MADAGASCAR MW -MALAWI MY -MALAYSIA MV -MALDIVES ML -MALI MT -MALTA MH -MARSHALL ISLANDS MQ -MARTINIQUE MR -MAURITANIA MU -MAURITIUS YT -MAYOTTE MX -MEXICO FM -MICRONESIA, FEDERATED STATES OF MD -MOLDOVA, REPUBLIC OF MC -MONACO MN -MONGOLIA MS -MONTSERRAT MA -MOROCCO MZ -MOZAMBIQUE MM -MYANMAR NA -NAMIBIA NR -NAURU NP -NEPAL NL -NETHERLANDS AN -NETHERLANDS ANTILLES NC -NEW CALEDONIA NZ -NEW ZEALAND NI -NICARAGUA NE -NIGER NG -NIGERIA NU -NIUE NF -NORFOLK ISLAND MP -NORTHERN MARIANA ISLANDS NO -NORWAY OM -OMAN PK -PAKISTAN PW -PALAU PS -PALESTINIAN TERRITORY, OCCUPIED PA -PANAMA PG -PAPUA NEW GUINEA PY -PARAGUAY PE -PERU PH -PHILIPPINES PN -PITCAIRN PL -POLAND PT -PORTUGAL PR -PUERTO RICO QA -QATAR RE -RÉUNION RO -ROMANIA RU -RUSSIAN FEDERATION RW -RWANDA SH -SAINT HELENA KN -SAINT KITTS AND NEVIS LC -SAINT LUCIA PM -SAINT PIERRE AND MIQUELON VC -SAINT VINCENT AND THE GRENADINES WS -SAMOA SM -SAN MARINO ST -SAO TOME AND PRINCIPE SA -SAUDI ARABIA SN -SENEGAL CS -SERBIA AND MONTENEGRO SC -SEYCHELLES SL -SIERRA LEONE SG -SINGAPORE SK -SLOVAKIA SI -SLOVENIA SB -SOLOMON ISLANDS SO -SOMALIA ZA -SOUTH AFRICA GS -SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS ES -SPAIN LK -SRI LANKA SD -SUDAN SR -SURINAME SJ -SVALBARD AND JAN MAYEN SZ -SWAZILAND SE -SWEDEN CH -SWITZERLAND SY -SYRIAN ARAB REPUBLIC TW -TAIWAN, PROVINCE OF CHINA TJ -TAJIKISTAN TZ -TANZANIA, UNITED REPUBLIC OF TH -THAILAND TL -TIMOR-LESTE TG - TOGO TK -TOKELAU TO -TONGA TT -TRINIDAD AND TOBAGO TN -TUNISIA TR -TURKEY TM -TURKMENISTAN TC -TURKS AND CAICOS ISLANDS TV -TUVALU UG -UGANDA UA -UKRAINE AE -UNITED ARAB EMIRATES GB -UNITED KINGDOM US -UNITED STATES UM -UNITED STATES MINOR OUTLYING ISLANDS UY -URUGUAY UZ -UZBEKISTAN VU -VANUATU VE -VENEZUELA VN -VIET NAM VG -VIRGIN ISLANDS, BRITISH VI -VIRGIN ISLANDS, U.S. WF -WALLIS AND FUTUNA EH -WESTERN SAHARA YE -YEMEN ZM -ZAMBIA ZW -ZIMBABWE More information at: http://www.starstandard.org. |
| Code Value | Description |
|---|---|
| US | |
| AF | |
| AL | |
| DZ | |
| AS | |
| AD | |
| AO | |
| AI | |
| AQ | |
| AG | |
| AR | |
| AM | |
| AW | |
| AU | |
| AT | |
| AZ | |
| BS | |
| BH | |
| BD | |
| BB | |
| BY | |
| BE | |
| BZ | |
| BJ | |
| BM | |
| BT | |
| BO | |
| BA | |
| BW | |
| BV | |
| BR | |
| IO | |
| BN | |
| BG | |
| BF | |
| BI | |
| KH | |
| CM | |
| CA | |
| CV | |
| KY | |
| CF | |
| TD | |
| CL | |
| CN | |
| CX | |
| CC | |
| CO | |
| KM | |
| CG | |
| CD | |
| CK | |
| CR | |
| CI | |
| HR | |
| CU | |
| CY | |
| CZ | |
| DK | |
| DJ | |
| DM | |
| DO | |
| EC | |
| EG | |
| SV | |
| GQ | |
| ER | |
| EE | |
| ET | |
| FK | |
| FO | |
| FJ | |
| FI | |
| FR | |
| GF | |
| PF | |
| TF | |
| GA | |
| GM | |
| GE | |
| DE | |
| GH | |
| GI | |
| GR | |
| GL | |
| GD | |
| GP | |
| GU | |
| GT | |
| GN | |
| GW | |
| GY | |
| HT | |
| HM | |
| VA | |
| HN | |
| HK | |
| HU | |
| IS | |
| IN | |
| ID | |
| IR | |
| IQ | |
| IE | |
| IL | |
| IT | |
| JM | |
| JP | |
| JO | |
| KZ | |
| KE | |
| KI | |
| KP | |
| KR | |
| KW | |
| KG | |
| LA | |
| LV | |
| LB | |
| LS | |
| LR | |
| LY | |
| LI | |
| LT | |
| LU | |
| MO | |
| MK | |
| MG | |
| MW | |
| MY | |
| MV | |
| ML | |
| MT | |
| MH | |
| MQ | |
| MR | |
| MU | |
| YT | |
| MX | |
| FM | |
| MD | |
| MC | |
| MN | |
| MS | |
| MA | |
| MZ | |
| MM | |
| NA | |
| NR | |
| NP | |
| NL | |
| AN | |
| NC | |
| NZ | |
| NI | |
| NE | |
| NG | |
| NU | |
| NF | |
| MP | |
| NO | |
| OM | |
| PK | |
| PW | |
| PS | |
| PA | |
| PG | |
| PY | |
| PE | |
| PH | |
| PN | |
| PL | |
| PT | |
| PR | |
| QA | |
| RE | |
| RO | |
| RU | |
| RW | |
| SH | |
| KN | |
| LC | |
| PM | |
| VC | |
| WS | |
| SM | |
| ST | |
| SA | |
| SN | |
| CS | |
| SC | |
| SL | |
| SG | |
| SK | |
| SI | |
| SB | |
| SO | |
| ZA | |
| GS | |
| ES | |
| LK | |
| SD | |
| SR | |
| SJ | |
| SZ | |
| SE | |
| CH | |
| SY | |
| TW | |
| TJ | |
| TZ | |
| TH | |
| TL | |
| TG | |
| TK | |
| TO | |
| TT | |
| TN | |
| TR | |
| TM | |
| TC | |
| TV | |
| UG | |
| UA | |
| AE | |
| GB | |
| UM | |
| UY | |
| UZ | |
| VU | |
| VE | |
| VN | |
| VG | |
| VI | |
| WF | |
| EH | |
| YE | |
| ZM | |
| ZW |
| Super-types: | xsd:dateTime < DateTime (by restriction) |
|---|---|
| Sub-types: |
|
| Name | DateTime |
|---|---|
| Documentation | Date and time conforms to ISO 8601format rules without offset EX:2003-11-05T13:15:30Z More information at: http://www.starstandard.org. |
| Super-types: | xsd:dateTime < DateTime (by restriction) < DocumentDateTime (by restriction) |
|---|---|
| Sub-types: | None |
| Name | DocumentDateTime |
|---|---|
| Documentation | Is the date and time the document was last created. This is not the date and time that the BOD message instance was created. More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < Type (by restriction) < ErrorType (by restriction) |
|---|---|
| Sub-types: | None |
| Name | ErrorType |
|---|---|
| Documentation | Defines the type of error that occurred. More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < Indicator (by restriction) |
|---|---|
| Sub-types: | None |
| Name | Indicator |
|---|---|
| Documentation | 0 = No, 1 = Yes More information at: http://www.starstandard.org. |
| Code Value | Description |
|---|---|
| 0 | |
| 1 |
| Super-types: | xsd:string < Language (by restriction) |
|---|---|
| Sub-types: | None |
| Name | Language |
|---|---|
| Documentation | Language conforms to ISO 639-2 rules. Note the format for this field is language-Country (see Country data type for the list of countries with definitions). AA "Afar", AB "Abkhazian", AF "Afrikaans", AM "Amharic", AR "Arabic", AS "Assamese", AY "Aymara", AZ "Azerbaijani", BA "Bashkir", BE "Byelorussian", BG "Bulgarian", BH "Bihari", BI "Bislama", BN "Bengali" "Bangla", BO "Tibetan", BR "Breton", CA "Catalan", CO "Corsican", CS "Czech", CY "Welsh", DA "Danish", DE "German", DZ "Bhutani", EL "Greek", EN "English" "American", ES "Spanish", ET "Estonian", EU "Basque", FA "Persian", FI "Finnish", FJ "Fiji", FO "Faeroese", FR "French", FY "Frisian", GA "Irish", GD "Gaelic" "Scots Gaelic", GL "Galician", GN "Guarani", GU "Gujarati", HA "Hausa", HI "Hindi", HR "Croatian", HU "Hungarian", HY "Armenian", IK "Inupiak", IN "Indonesian", IS "Icelandic", IT "Italian", IW "Hebrew", JA "Japanese", JI "Yiddish", JW "Javanese", KA "Georgian", KK "Kazakh", KL "Greenlandic", KM "Cambodian", KN "Kannada", KO "Korean", KS "Kashmiri", KU "Kurdish", KY "Kirghiz", LA "Latin", LN "Lingala", LO "Laothian", LT "Lithuanian", LV "Latvian" "Lettish", MG "Malagasy". MI "Maori", MK "Macedonian", ML "Malayalam", MN "Mongolian", MO "Moldavian", MR "Marathi", MS "Malay", MT "Maltese", MY "Burmese", NA "Nauru", NE "Nepali", NL "Dutch", NO "Norwegian", OC "Occitan", OM "Oromo" "Afan", OR "Oriya", PA "Punjabi", PL "Polish", PS "Pashto" "Pushto", PT "Portuguese", QU "Quechua", RM "Rhaeto-Romance", RN "Kirundi", RO "Romanian", RU "Russian", RW "Kinyarwanda", SA "Sanskrit", SD "Sindhi", SG "Sangro", SH "Serbo-Croatian", SI "Singhalese", SK "Slovak", SL "Slovenian", SM "Samoan", SN "Shona", SO "Somali", SQ "Albanian", SR "Serbian", SS "Siswati", ST "Sesotho", SU "Sudanese", SV "Swedish", SW "Swahili", TA "Tamil", TE "Tegulu", TG "Tajik", TH "Thai", TI "Tigrinya", TK "Turkmen", TL "Tagalog", TN "Setswana", TO "Tonga", TR "Turkish", TS "Tsonga", TT "Tatar", TW "Twi", UK "Ukrainian", UR "Urdu", UZ "Uzbek", VI "Vietnamese", WO "Wolof", XH "Xhosa", YO "Yoruba", ZH "Chinese", ZU "Zulu" More information at: http://www.starstandard.org. |
| Code Value | Description |
|---|---|
| en-US | |
| en-CA | |
| aa-ET | |
| ab-GE | |
| af-ZA | |
| am- ET | |
| ar-SA | |
| as-IN | |
| ay-BO | |
| az-AZ | |
| ba-RU | |
| be-BY | |
| bg-BG | |
| bh-IN | |
| bi-VU | |
| bn-BD | |
| bo-BT | |
| br-FR | |
| ca-ES | |
| co-FR | |
| cs-CZ | |
| cy-GB | |
| da-DE | |
| de-DE | |
| dz-BT | |
| el-GR | |
| es-ES | |
| et-EE | |
| eu-ES | |
| fa-AF | |
| fi-FI | |
| fj-FJ | |
| fo-FO | |
| fr-CA | |
| fr-FR | |
| fy-NL | |
| ga-IE | |
| gd-GB | |
| gl-ES | |
| gn-PY | |
| gu-IN | |
| ha-NG | |
| hi-IN | |
| hr-HR | |
| hu-HU | |
| hy-AM | |
| ik-GL | |
| in-ID | |
| is-IS | |
| it-IT | |
| iw-IL | |
| ja-JP | |
| ji-IL | |
| jw-ID | |
| ka-GE | |
| kk-KZ | |
| kl-GL | |
| km-KH | |
| kn-IN | |
| ko-KP | |
| ko-KR | |
| ks-IN | |
| ku-IQ | |
| ky-CN | |
| la-VA | |
| ln-CD | |
| lo-LA | |
| lt-LT | |
| lv-LV | |
| mg-MG | |
| mi-NZ | |
| mk-MK | |
| ml-IN | |
| mn-MN | |
| mo-MO | |
| mr-IN | |
| ms-MY | |
| mt-MH | |
| my-MM | |
| na-NR | |
| ne-NP | |
| nl-NL | |
| no-NO | |
| oc-FR | |
| om- ET | |
| or-IN | |
| pa-IN | |
| pl-PL | |
| ps-PK | |
| pt-PT | |
| qu-PE | |
| rm-CH | |
| rn-BI | |
| ro-RO | |
| ru-RU | |
| rw-RW | |
| sa-IN | |
| sd-PK | |
| sg-CF | |
| sh-HR | |
| si-LK | |
| sk-SK | |
| sl-SI | |
| sm-WS | |
| sn-ZW | |
| so-SO | |
| sq-AL | |
| sr-CS | |
| ss-ZA | |
| st-ZA | |
| su-SD | |
| sv-SE | |
| sw-TL | |
| ta-IN | |
| te-IN | |
| tg-TJ | |
| th-TH | |
| ti-ET | |
| tk-TM | |
| tl-PH | |
| tn-ZA | |
| to-TO | |
| tr-TR | |
| ts-ZA | |
| tt-RU | |
| tw-GH | |
| uk-UA | |
| ur-PK | |
| uz-UZ | |
| vi-VN | |
| wo-SN | |
| xh-ZA | |
| yo-NG | |
| zh-CN | |
| zu-ZA |
| Super-types: | xsd:string < MessageReasonCode (by restriction) |
|---|---|
| Sub-types: | None |
| Name | MessageReasonCode |
|---|---|
| Documentation | Code indicating reason for message. More information at: http://www.starstandard.org. |
| Code Value | Description |
|---|---|
| Success | The operation completed successfully. This does not necessarily mean that the BOD was processed. Instead it means that the client's role is done and that it won't receive any error messages later. Type of Response Code: Success. |
| Accepted | The BOD was received, validated, and accepted. However, it may not have yet been processed. The client should expect to receive a response once process is complete. If no response will be generated, use the "Success" code instead. This is typically used for batch processing. Type of Response Code: Success. |
| Received | The BOD was received. However, it has not yet been validated or processed yet. The client may receive a response or a ConfirmBOD at a later time. Type of Response Code: Success. |
| Other | Other |
| Duplicate Document | This code refers to a document that already exists. This may happen for a BOD such as ProcessPartsOrder where the document identifiers to another existing parts order from the same dealer. Type of Response Code: Error, Warning. |
| Invalid Required Value | One or more required data elements have invalid values. Type of Response Code: Error. |
| Invalid Optional Value | One or more optional data elements have invalid values. Type of Response Code: Warning. |
| Already Performed | This code refers to an operation that has already been performed on a document. This may happen for a BOD such as CancelPartsOrder where the document identifier refer to a parts order that has already been cancelled. Type of Response Code: Error. |
| Cannot Perform | This code refers to an operation that cannot be performed such as Change or Cancel based on the receiver's business rules and the condition of the document. For example, the part order has already been shipped therefore the order cannot be cancelled. Type of Response Code: Error. |
| Required Field Missing | This occurs when one or more required fields are missing. Type of Response Code: Error. |
| Optional Field Missing | This occurs when one or more optional fields are missing. Type of Response Code: Warning. |
| Not Permitted | This code occurs when the client attempts to perform an operation that is not permitted. An example of when this may occur is if the dealer attempts to order a part when their account is placed on hold. This is to be used for authorization errors. Type of Response Code: Error. |
| Server Error | An error (e.g. database server is down) on the server prevented the execution of the BOD. The client will have to resend the BOD at a later time. Type of Response Code: Error. |
| BOD Not Supported | The received BOD or BOD version is not supported b the receiver. Type of Response Code: Error. |
| Invalid Structure | The structure of the BOD is not valid. For example, the BOD failed schema validation. Type of Response Code: Error. |
| Super-types: | xsd:string < Note (by restriction) |
|---|---|
| Sub-types: |
|
| Name | Note |
|---|---|
| Documentation | A free form note. More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < Text (by restriction) < Reference (by restriction) |
|---|---|
| Sub-types: | None |
| Name | Reference |
|---|---|
| Documentation | Reference notation More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < ReferenceNumber (by restriction) |
|---|---|
| Sub-types: |
|
| Name | ReferenceNumber |
|---|---|
| Documentation | Reference number More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < Note (by restriction) < ReferenceValue (by restriction) |
|---|---|
| Sub-types: | None |
| Name | ReferenceValue |
|---|---|
| Documentation | The value associated with a field. More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < Note (by restriction) < SecondaryPassword (by restriction) |
|---|---|
| Sub-types: | None |
| Name | SecondaryPassword |
|---|---|
| Documentation | Secondary password used to validate access to the dealer information More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < Code (by restriction) < ShortMfg (by restriction) |
|---|---|
| Sub-types: | None |
| Name | ShortMfg |
|---|---|
| Documentation | Short Manfacturer or RSP Codes More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < ReferenceNumber (by restriction) < SystemVersion (by restriction) |
|---|---|
| Sub-types: | None |
| Name | SystemVersion |
|---|---|
| Documentation | The sender's software version number . More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < Text (by restriction) |
|---|---|
| Sub-types: |
|
| Name | Text |
|---|---|
| Documentation | Indicates generic text type More information at: http://www.starstandard.org. |
| Super-types: | xsd:string < Type (by restriction) |
|---|---|
| Sub-types: |
|
| Name | Type |
|---|---|
| Documentation | Type More information at: http://www.starstandard.org. |
| Super-types: | xsd:anyURI < URI (by restriction) |
|---|---|
| Sub-types: | None |
| Name | URI |
|---|---|
| Documentation | URI More information at: http://www.starstandard.org. |
Copyright © 2007 STAR – Standards for Technology in Automotive Retail. All rights reserved
Generated by StarSchemaGuidelineGenerator based on xs3p. Last modified: