UNDT000007-SC2 SC Code List. Identifier The identification of a list of codes. Code List Identification Identifier string UNDT000007-SC3 SC Code List. Agency. Identifier An agency that maintains one or more lists of codes. Code List Agency Identifier string Defaults to the UN/EDIFACT data element 3055 code list. UNDT000007-SC4 SC Code List. Agency Name. Text The name of the agency that maintains the list of codes. Code List Agency Name Text string UNDT000007-SC5 SC Code List. Name. Text The name of a list of codes. Code List Name Text string UNDT000007-SC6 SC Code List. Version. Identifier The version of the list of codes. Code List Version Identifier string UNDT000007-SC7 SC Code. Name. Text The textual equivalent of the code content component. Code Name Text string UNDT000007-SC8 SC Language. Identifier The identifier of the language used in the code name. Language Identification Identifier string UNDT000007-SC9 SC Code List. Uniform Resource. Identifier The Uniform Resource Identifier that identifies where the code list is located. Code List Uniform Resource Identifier Identifier string UNDT000007-SC10 SC Code List Scheme. Uniform Resource. Identifier The Uniform Resource Identifier that identifies where the code list scheme is located. Code List Scheme Uniform Resource Identifier Identifier string The purpose of ReceiveLocationService is to enable a mechanism to ensure that the physical location owned by the business applications are validated, geocoded, and standardized by the location service providers. This BOD may also be initiated by the service provider in response to receiving a request for a particular service such as geocoding, address validation, etc. There are many possible business applications in several environments that may use this capability. For example, the customer management, the supplier management, or HRMS business applications could use this to communicate Location information to location service providers. Is where the information that the BOD message carries is provided, in this case ReceiveLocationService. The information consists of a Verb and one or more Nouns. The verb (Receive) indicates the action to be performed on the Noun (LocationService). Is the schema based inheritance for all BODs. The logical model would also include the DataArea. OAGIS Release this BOD Instances belongs or the OAGIS release that the derivative work is based on. Indicates the version of the given BOD defintion. 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). Indicates the language that the contents of the BOD is in unless otherwise stated. A Location Service provides communication between Business Applications and other applications that are considered authoritative data sources for validating, correcting, geocoding or enriching location information. A location service request can request multiple locations to be processed. Also each service request response can have multiple locations returned. ResultCode represents the overall response or result of the service request. MatchCode represents the response or result for each location in the service request. ReturnCriteria identifies the content that is to be returned, given query success. In essence, the expression here has the effect of filtering the part(s) of the found element(s) that are to be returned. ReturnCriteria plays no role in the query itself. That is handled as a match against the request BOD's noun exemplar. ReturnCriteria allows the sender of the BOD to indicate which information (down to the field level) is requested to be returned, given that the query has been successful in matching the exemplar to existing nouns. That is, in a GetListPurchaseOrder, if one or more PurchaseOrders with a TotalPrice = $1M were found, ReturnCriteria tells the BOD recipient which parts of the PurchaseOrder should be populated with content when the response (ShowPurchaseOrder) is formulated. The expressionLanguage indicates the expression language being used. In order for the ReturnCriteria expression to be evaluable by the BOD recipient, the recipient must be capable of processing and interpreting the specified expression language. XPath is the default, due to its ubiquity among XML processing technologies. LocationABIEType is logically derived from UN/CEFACT TBG17 ABIE LocationType as defined in the Reusable Aggregate Business Information Entity (RUABIE) XML Schema file. Identifies the sender of the given BOD instance Allows any digital Signatures to be added to the Instance of the BOD Instance in order to sign for any portion of the BOD content. QDT000000 QDT Description_ Text. Type 1.0 Text Description A free form note. The lang attribute identifies the language that the note is in. The author identifies the author of the note. The enrtyDate indicates the date the note was entered or last modified. The OAGIS CoordinateType allows the use of another coordinate system for the use within a warehousing and inventory environment and the geographic coordinat system. Address BaseType provides the information about the address or semantic address of an associated entity. QDT000000 QDT Response_ Code. Type 1.0 Code Response Contains the sequenced identifier for the associated component or noun. QDT000000 QDT Delivery Point_ Code. Type 1.0 A character string (letters, figures, or symbols) that for brevity and/or languange independence may be used to represent or replace a definitive value or text of an attribute together with relevant supplementary information. Code Delivery Point QDT000000 QDT Country Subdivision_ Code. Type 1.0 A character string (letters, figures, or symbols) that for brevity and/or languange independence may be used to represent or replace a definitive value or text of an attribute together with relevant supplementary information. Code Country Subdivision QDT000000 QDT Country_ Code. Type 1.0 Code Country StatusABIEType is logically derived from UN/CEFACT TBG17 ABIE StatusType as defined in the Reusable Aggregate Business Information Entity (RUABIE) XML Schema file. PreferenceABIEType is logically derived from UN/CEFACT TBG17 ABIE PreferenceType as defined in the Reusable Aggregate Business Information Entity (RUABIE) XML Schema file. Provides the structure to indicate a Date/Time period where the Time is provided with in the Start and Duration or EndDateTime. TimePeriodABIEType is logically derived from UN/CEFACT TBG17 ABIE PeriodType as defined in the Reusable Aggregate Business Information Entity (RUABIE) XML Schema file. The purpose of RequestLocationService is to enable a mechanism to ensure that the physical locations owned by the business applications are validated, geocoded, and standardized based on information returned by location service providers. This BOD may be initiated by the sending system upon some event occurring, such as receiving a request submitted by another system for certain location service. There are many possible business applications in several environments that may use this capability. For example, the customer management, the supplier management, or HRMS business applications could use this to receive processed location information from location service providers. The Get verb is to communicate to a business software component a request for an existing piece of information to be returned. The Get may be paired with most of the nouns defined in the OAGIS specification.The response to this request is the Show verb. The behavior of a BOD with a Get verb is quite predictable across most of the nouns it may be paired with.The Get is designed to retrieve a single piece of information by using that information's primary retrieval field, or key field. The Get verb is not used to request several documents at once. The GetList verb is designed to achieve that purpose and will be covered in more detail later.Selection Criteria:There are two types of selection capabilities for most BOD's that use the Get verb.1) The first selection capability is called Field-Based Selection. Within a Get-based Business Object Document, the first Data Type that occurs in a specific BOD structure is commonly used to provide the Field-Based Selection criteria. This is always defined within the specific BOD and is commonly the required fields for that specific Data type.The Field-Based Selection enables the requester to provide a value or values (in the case of multiple required Field Identifiers), in the required fields. Then the responding component uses those values to find and return the requested information to the originating business software component.2) The second type of selection capability for Get-based BODs is called Data Type Selection. Data Type selection enables the requester to identify which Data Types within the noun are requested to be returned in the response. The use of this capability is described for each corresponding Data Type for all BODs that use the Get verb. The Data Types are identified for retrieval within the Get instance of a BOD by including the name of the Data Type in the meta data but without any Field Identifiers or Segments identified within the Data Type. This will signify to the responding application that all of the data that corresponds to that Data Type is to be included in the response.If the Data Type is not requested, the Data Type identifier is not included in the Get request and this will signify to the responding component that the Data Type is not to be returned. 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. 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. The location of a thing, as captured by an address (or addresses), GPS Coordinates, and/or in relation to other locations. ResultCode represents the overall response or result of the service request. The resulting location(s) after processing. A Match Code is returned for each location that has been processed. 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. 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. 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. 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. Allows the user of OAGIS to extend the specification in order to provide additional information that is not captured in OAGIS. This is done by defining the additional information in XML Schema and referencing the new schema in the xml instance document throught the use of namespaces. Once this is done the additional information defined there can be carried in the BOD XML instance document. The Open Applications Group will make best efforts to quickly consider all proposed submissions.The USERAREA is always the last element in all components, except where the component has been extended inline. MatchCode represents the response or result for each location in the service request. Is the Identifiers of the given instance of an entity within the scope of the integration. The providedBy attribute identifies the party that provided or knows this party by the given identifier. Identifies the Name of the object in which associated. 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 Provides a finer level of control than Logical Identifier and represents the business application that issued the Business Object Document. Its use is optional. The Open Applications Group has not constructed the list of valid Component names. A suggestion for naming is to use the application component names used in the scenario diagrams in section two of OAGIS. Example Components may be Inventory, or Payroll. Describes the business event that initiated the need for the Business Object Document to be created. Its use is optional. Although the Task may differ depending on the specific implementation, it is important to enable drill back capability. Example Tasks may be Receipt or Adjustment. Enables the sending application to indicate the instance identifier of the event or task that caused the BOD to be created. This allows drill back from the BOD message into the sending application. The may be required in environments where an audit trail must be maintained for all transactions. Is an option controlled by the Sender business application. It is a request to the receiving application to send back a confirmation BOD to the sender. The confirmation Business Object Document may indicate the successful processing of the original Business Object Document or return error conditions if the original Business Object Document was unsuccessful. The confirmation request has the following valid values: Never - No confirmation Business Object Document requested OnError - OnError send back a confirmation Business Object Document only if an error has occurred Always - Always send a confirmation Business Object Document regardless 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(s). Is the value and unit of measure in the z-axis in a thrre dimensional system. Examples of this maybe the Altitude in the case of a map of the world, or the height or shelf in a rack system in the case of a manufacturing or warehouse facility. Is the system in which the userid applies. Format Code indicates the format of the address. Examples are US Military, US Formatted Address, European Formatted Address etc. There is no intent to decode the address formats - these are informational only. No list of valid values exists or is proposed here. The name of the person or organization that the associated entity is intended. The name that the associated entity is sent by. The Number of the building or house on the street that identifies where to deliver mail. For example, Building 300 on Standards Parkway The building or house name on the street that identifies where to deliver mail The Street Name where the building/ house is located Identifies the apartment number or office suite. The floor where the housename is located Identifies a Post Office Box number Identifies the Dock or the Mail Stop or Lane or any other specific Delivery Point. Qualifies the further division of the City, example a city may have many districts or Boroughs. The type attribute identifies the type of this entity e.g. City, Borough etc, and there is a pre-defined list of types supported, with the ability to add new ones as necessary Identifies the town or the city Qualifies the further division of the Country. These may be Districts, Regions, States, Provinces etc. A possible list of values is as specified in ISO 3166-2. The type attribute identifies the type of this e.g. District, Region etc, and there is a pre-defined list of types supported, with the ability to add new ones as necessary Country in which the Address is in. A possible list of values is as specified in ISO 3166-2. Postal Code of the Address. Indicates the status of the associated object by providing the Status Code along with a description and when the status is effective. An explicit period of time for the bucket. A value expressing the value of a Sequence. Indicates the time period in which the associated component is effective. Element for the communication of all codes. This is the DateTime the associated object is made effective Identifies the reason for an activity Start timestamp indicating the starting point of the event. Indicates the duration of time as represented by ISO 8601. Where the value space is a six dimensional space where the coordinates designate the Gregorian year, month, day, hour, minute, and second. The number of seconds can include decimal digits to arbitary pecision. Is the ending timestamp of the event. Common Free Form Text elements that occur together. Indicates the ID of the associated component or noun. QDT000000 QDT Month_ Date. Type 1.0 A particular point in the progression of time together with the relevant supplementary information. Provides the XML Schema simpleType that allows either just the Date or the Date and Time to be provided in the elements that are based on this type and/or types that use this as their base. Date Month