Acknowledge
|
The Acknowledge verb is used to acknowledge the application receipt of a PROCESS request. This function conveys the result of the original request. An example of this is ACKNOWLEDGE PO, where a PROCESS PO has been issued and the corresponding business application acknowledges the receipt of the PO and responds with an acceptance or a counter offer.
|
Add
|
The Add verb is used to initiate the adding of a document or data entity to another business application. ADD is used when the sender of the BOD is not the owner of the data, but is sending a request for the document to be created on by the system that is the owner of the data.
|
Allocate
|
The Allocate verb is used to describe specific processing in a more fine grained manner beyond add, change or delete processing. An example of this is the allocating of costs from one business application or entity to another. The business oriented word is used instead of the data processing term for the sake of clarity.
|
Cancel
|
The CANCEL verb is used when the sender of the BOD is not the owner of the data, but is sending a request for the document to be canceled.An example is the CANCEL PO where the business implications must be calculated and a simple data processing term such as delete can not fully convey the business meaning and required processing associated with the meaning.
|
Change
|
The CHANGE verb is used when the sender of the BOD is not the owner of the data, but is sending a request for the document to be changed.An example of this is CHANGE REQUISITN, where the original document needs to be changed based on a specific business event.
|
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.
|
Create
|
The Create verb is used to describe specific processing in a more fine grained manner beyond add, change or delete processing. This is generally used when the processing is initiating the building of a document, rather than moving a document from one system to another. Examples of this include CREATE PRODORDER and CREATE BOM.
In these cases, the documents have not been constructed and need to be. This differs from the ADD PO or ADD REQUISITN processing as those requests refer to a document that has already been established and the document is being communicated to another business application.
|
Get
|
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.
|
GetList
|
The purpose of the GetList verb is to enable a business software component to request summary information for one or more occurrences of a specific noun from another business software component.
The GetList may be paired with most of the nouns in the OAGIS specification.The response to this request is a BOD using the List verb. The GetList is designed to retrieve multiple occurrences of data such as all of the sales orders or all of the purchase orders within a requested range. It does not require an exact match of the key fields in order to retrieve information. It may use a range selection criteria with a "from" and "to" selection capability. This behavior is quite different from the Get verb, which is designed to retrieve a specific noun using a specific key field.The GetList verb also enables the retrieval of information across several documents by using selection fields. An example of this could be requesting all sales order lines for a specific item. This type of functionality is limited to the capabilities of the responding application and needs to be determined during the implementation project. More details on this capability will be described below.
GetList attributes:
o maxitems attribute is a number that indicates the number of maximum items to be returned.
o rssave attribute is a Boolean flag that indicates whether the result set should be saved on the sending system if maxitems is exceeded.
o rsstart attribute is a number of the starting record for the next section of the result set. If it is omitted, it is to be assumed the first of the maxitems.
o rsref attribute is a string that represents the implementation-specific result set identifier for subsequent requests.
Selection Criteria:
There are two types of selection capabilities enabled by the BODs that use the GetList verb.
1) Field-Based Selection
Allows the requesting system to ask for information that matches the data provided. It also allows the requestor to indicate the information that to be returned by specifying the ReturnCriteria indicated on the GetList Verb.
2) Range Selection
Allows the requesting system to provide a range of values for known data. This is accomplished by providing two occurances of the Noun. The first occurance indicates the "From" the second occurance indicates the "To" occurance. Again the requestor can indicate the information that to be returned by specifying the ReturnCriteria indicated on the GetList Verb.
|
Issue
|
This verb is used to describe specific processing in a more fine grained manner beyond add, change or delete processing. An example is the issue of material from inventory. The business use of the word is used instead of the data processing term for the sake of clarity.
|
List
|
The purpose of the LIST verb is to enable a business software component to respond to a GETLIST request or to proactively send a listing of summary information containing many instances of occurrences of data for a noun to one or more other business software components.The results of a LIST may then be used as is, or they may be used to select a specific instance of a document or entity in order to issue a detail GET request.Although BODs based on this verb do not commonly cause updates to occur, there may be times when the component receiving the LIST decides to use the information it receives to update. This is entirely the decision of the receiving software component and is not forbidden.The behavior of the LIST verb is quite straight forward with a few exceptions. The LIST response to any GETLIST request needs to read the request carefully to ensure the response is returning the requested Data Types. The LIST needs to ensure the response to the GETLIST does not exceed the maxItems value.The LIST needs to find the specific Field Identifiers that are used for the Field-Based Selection or Range-Based Selection and process them accordingly.
The attributes associated with the LIST BODs are as follows:
o rsstart attribute is a number that idicates the starting record for the section of the resulting set returned in the list message. This value should always match the rsstart value in the originating GetList BOD.
o rscount attribute is a number that indicates the number of records returned in the message. The subsequent request for additional records should have a rsstart value of rscount + 1.
o rstotal attribute is a number that indicates the total number of records in the result set.
o rscomplete attribute is a Boolean that indicates that the list provided exhaust the possible values.
o rsref attribute is a string that represents the implementation-specific result set identifier for subsequent requests.
|
Load
|
This verb is used to initiate the adding of a document or data entity to another business application. Generally this verb is used when maintenance to the document will then pass to the receiving application permanently. An example of this is Load Payable or Load Receivable, where once the request is processed, the sending application has no direct control over the document or entity again.
|
Post
|
The POST verb is used to describe specific processing in a more fine grained manner beyond add, change or delete processing. An example is POST JOURNAL, where information is posted to a general ledger set of financial records. The business use of the word is used instead of the data processing term for the sake of clarity.
|
Process
|
The Process verb is used to request processing of the associated noun by the receiving application or business to party. In a typical external exchange scenario a Process BOD is considered to be a legally binding message. For example, if a customer sends a ProcessPurchaseOrder BOD to a supplier and the supplier acknowlegdes with a positive AcknowledgePurchaseOrder, then the customer is obligated to fullfil the agreement, unless of course other BODs are allowed to cancel or change the original order.
|
Receive
|
The Receive verb is used to describe specific processing in a more fine grained manner beyond add, change or delete processing. An example is ReceivePurchaseOrder, where a Purchase Order that has been issued and processed has shipments received against it. The use of the data processing term, change, is not specific enough in the business context.
|
Respond
|
The Respond verb is used to communicate relative to another document. It may be used to communicate agreement, questions, answers to a question, or disagreement with the related document. An example is the RequestForQuote and Quote document pair. An RequestForQuote is issued to a set of business partners. If one of the partners needs clarification on an item, a RespondRequestForQuote is sent to the originating partner.
|
Show
|
The Show verb is used when sending the information about a specific instance of a business document or entity. The Show verb may be used to respond to a Get request or it can be used in a publish scenario, where it pushes information to other applications based on a business event.Although BODs based on this verb do not commonly cause updates to occur, there may be times when the component receiving the Show decides to use the information it receives to update. This is entirely the decision of the receiving software component and is not forbidden.The behavior of the Show verb is quite straight forward with one exception. The Show response to any Get request needs to read the request carefully to ensure the response is returning the requested Data Types.
|
Sync
|
The Sync verb is used when the owner of the data is passing or publishing that information or change in information to other software components. This is to be used when the receiver of the SyncBOD does not own the data. This verb is commonly used when mass changes are necessary or when a publish and subscribe mechanism is used in the integration architecture.The purposes of this verb include application integrity and ease of data entry for the business user by enabling a single point of input.
|
Update
|
The Update verb is used to describe specific processing in a more fine-grained manner beyond add, change or delete processing. An example is the update of inspection information from one business application to another. The event is not adding a document, or changing fields per se, it is communicating the occurrence of an event as well as the corresponding data that accompanies the event.
|
BillOfMaterial
|
When included in a hierarchy, the Components are position dependent for their meaning and applicability to the Bill of Material.
The Bill of Material structure is broken down into three classifications or ways to represent the Item. An Item may be included by itself as in the first sub-grouping, or an Item may be represented as part of a set of options or as an option within a class of options.
An example of an option would be CD-ROM for a laptop computer. Then each of the types of CD-ROM’s for the option would be a separate Item.
An example of an option class would be memory for a laptop. The options could then be 128, 256, or 512 megabytes of RAM. Each of these options would then have separate Item identifiers for memory modules that makes up the appropriate amount of memory. For 256 megabytes of RAM, this could be two 128 megabyte memory modules or one 256 megabyte.
|
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.
|
ChartOfAccounts
|
Chart of Accounts represents the accounting structure of a business. Each account represents a financial aspect of a business, such as its Accounts Payable, or the value of its inventory, or its office supply expenses. Typically, each account consists of a character string representing various elements such as major account code and department code.
|
Consumption
|
The process whereby a certain amount or quantity of inventory, resources or product is utilized which likely lead to the need for some form of replenishment.
|
CostingActivity
|
For Dual Cycle accounting applications, ACTIVITY is used to communicate the details of the activities in the Manufacturing Application that caused the entries in the Journal
|
Credit
|
Credit represents customer credit information, and is used in the context of credit checking new sales orders.
|
CreditStatus
|
CreditStatus represents the credit approval status of a customer or a specific customer order.
|
DeliveryReceipt
|
Represents a transaction for the receiving of goods or services. It may be used to indicate receipt of goods in conjunction with a purchase order system.
The DELIVERY document contains CHARGE and DISTRIBUTN elements at various levels to support the assessment of receiving service or compliance penalty charges. Several large retailers that demand receiving efficiency commonly assess penalty charges for supplier deliveries that are not compliant with the retailer’s policies. Charges may be incurred for deliveries, ship units or items that contain discrepancies from what was ordered or electronically manifested, for improper labeling of items and ship units and the incorrect packing or loading of ship units.
|
DispatchList
|
A dispatch list shows the manufacturing or production supervisor or foreman a prioritized detail status of orders and operations scheduled or in-process at a specific work center.
|
ElectronicCatalog
|
ElectronicCatalog is a list of items or commodities. The items may be arranged according to a classification scheme. The catalog can identify the classification scheme it uses, and the classifications and features that are defined within that scheme. Within the catalog, each item can be classified into one oe more categories , and the specifications of each item can be identified. A catalog has at least one publisher and one or many suppliers for the items in the catalog.
|
EmployeeTime
|
Refers to time sheet information for an employee. This information may be collected in an external source, and then transferred to a HRMS or Payroll application.
|
EmployeeWorkSchedule
|
Represents data related to the planned work hours for an employee. A work schedule typically includes relatively static employee information, such as employee ID and name. It will also include schedule-specific information such as dates and amount of time to be worked.
|
EngineeringChangeDocument
|
An EngineeringChangeDocument can be used to request a change to an manufactured item. This document allows the Change to progress through the different states from being a request and going through the review process to becoming an approved EngineeringChangeOrder.
|
ExchangeRate
|
Information that applies to the exchange rate ratio.
|
Field
|
Field represents any element of user data that is to be synchronized across databases. The specific field name and value are specified in the Business Object Document.
|
Inspection
|
Reports the inspection of items identifies the source document
|
InventoryBalance
|
Includes all stocked items and primarily represents the quantities of each item by location. Other item-by-location information, such as serial numbers or lot numbers, can also be included. The use of this noun does not include basic item master data that is independent of location, such as item description and dimensions.
|
InventoryCount
|
InventoryCount represents the results of a physical inventory or cycle count of the actual on-hand quantities of each item in each location. Compare to the noun InventoryBalance, which represents system-maintained on-hand quantities.
|
InventoryIssue
|
The InventoryIssue can be used to request an application to process an issue or request information about an issue
|
InventoryMovement
|
Allows organizations to do quantity movement between locations, whether they are located in the same plant or across the country, or between countries.
|
InventoryReceipt
|
The Inventory Receipt is intended for use in Unplanned Receipt Scenarios
|
Invoice
|
The Invoice is use to invoice the customer.
|
ItemCrossReference
|
Item Cross References describe both alternate and related items. Alternate items could specify items that have alternative universal identifiers such as EAN, UPC, or party specific identifiers such as supplier part number or customer part number. Related items could be spares, accessories or substitutes. Substitute items could be items that were validated by a development department for use as a substitute for the regular item.
|
ItemMaster
|
Represents any unique purchased part or manufactured product. Item, as used here, refers to the basic information about an item, including its attributes, cost, and locations. It does not include item quantities. Compare to the noun InventoryBalance, which includes all quantities and other location-specific information.
Item is used as the Item Master.
|
JournalEntry
|
A journal represents a change in the balances of a business’s financial accounts. Many tasks or transactions throughout an enterprise will result in the creation of a journal. Some examples are creating a customer invoice, paying a vendor, transferring inventory, or paying employees. A journal consists of a header with general information, and two or more lines specifying what accounts will be affected. A journal typically includes balanced debit and credit lines.
|
LedgerActual
|
Ledger Actual represents actual amounts by account within ledger within company or business area. Actual amounts may be generated in a source application and then loaded to a specific ledger within the enterprise general ledger or budget application.
|
LedgerBudget
|
Ledger Budget represents budget amounts by account within ledger within company or business area. Budget amounts may be generated in a source application and then loaded to a specific ledger within the enterprise general ledger or budget application.
|
MaintenanceOrder
|
A Maintenance Order is an order for a machine, building, tooling or fixed asset to be repaired or for preventitive maintenance to be performed.
|
MatchDocument
|
Identifies an internal document containing matching information. Essential it holds cross reference information among the customer Purchase Order and the Suppier Invoice. It supports N-way matching.
|
MatchFailure
|
Match Fail represents notification that purchasing lines have failed in matching to a supplier invoice. The matching of a purchase order to an invoice is used to determine the amount paid to the vendor
|
Party
|
Allows the communication of party information between business applications with in a given integration. These Parties may play different roles witin an integration from Supplier, Customer, to Carrier and many more.
|
Payable
|
Payable is a transaction that represents an invoice from a supplier. A payable is an open item, approved and ready for payment, in the Accounts Payable ledger. In some systems it may be called a voucher. Compare to PurchaseLedgerInvoice, which represents a not yet approved supplier invoice.
|
PickList
|
Picking List is a document that lists material to be retrieved (“picked”) from various locations in a warehouse in order to fill a production order, sales order, or shipping order. A picking list includes general identifying information (header information), as well as line item details. Depending on the verb used, PickList may refer to header information only, or both header and detail information.
|
PlanningSchedule
|
Indicates a demand forecast sent from a customer to a supplier, or a supply schedule sent from a supplier to a customer.
|
PriceList
|
Defines a list of items with their base price, price breaks, discounts and qualifiers. For each item, price breaks can be defined, above which certain discounts or overriding prices might apply. Price breaks can be defined in volume or in dollar amount. Price list qualifiers specify for which catalog, customer and/or effective dates this price list applies.
|
ProductAvailability
|
Product Availability represents information on the availability of a specified item at a specified inventory location for a specified date. Product availability is typically needed in the processing of customer sales orders. It is used in this context as the object of an inquiry function.
|
ProductionOrder
|
Production Order is a document requesting the manufacture of a specified product and quantity.
|
ProductRequirement
|
Product Requirement is a request to reserve or allocate a specified quantity of a specified item. Typically, this requirement would be received by an inventory or production system.
|
ProjectAccounting
|
This is used to enable all relevant sub-systems that submit single sided transactions to send information to a Project Accounting Application. This would include, but not necessarily be limited to: Accounts Payable, Accounts Receivable, Budget, Order Management, Purchasing, Time and Labor, Travel and Expense.
ProjectAccounting is a synonym for Project, and the LoadProjectAccounting BOD has the effect of populating the Project's TotalCost field or the ProjectActivities' Cost fields.
|
PurchaseLedgerInvoice
|
A PurchaseLedgerInvoice represents a not yet approved for payment purchase ledger invoice or debit memo. A PurchaseLedgerInvoice uses an InvoiceReference to reference the original suppliers invoice.
|
PurchaseOrder
|
The purpose of the PurchaseOrder Business Object Document is to communicate an order to purchase goods from a buyer to a supplier. The PurchaseOrder carries information to and from the buyer and supplier. The PurchaseOrder is a legally binding document once both Parties agree to the contents and the specified terms and conditions of the order.
The Process PurchaseOrder sends the electronic form of a purchase order document from a customer to a supplier in order to purchase n-number of Lines each of which containes an Ordered Item.
|
Quote
|
Is a document describing the prices of goods or services provided by a vendor. The Quote includes the terms of the purchase, delivery proposals, identification of goods or services ordered, as well as their quantities.The Quote noun is used in conjunction with the RFQ noun to form a Business-to-Business negotiation dialogue concerning the goods or services specified.
|
Receivable
|
Receivable is a transaction representing an invoice, credit memo or debit memo to a customer. A receivable is an open (unpaid) item in the Accounts Receivable ledger.
|
RequestForQuote
|
Is a document describing goods or services desired from a vendor. The RFQ includes the terms of the purchase, delivery requirements, identification of goods or services ordered, as well as their quantities.The RFQ noun is used in conjunction with the Quote noun to form a Business-to-Business negotiation dialogue concerning the goods or services specified.
|
Requisition
|
Is a request for the purchase of goods or services. Typically, a requisition leads to the creation of a purchase order to a specific supplier.
|
ResourceAllocation
|
Identifies the resources that are need for a prodiuction order and indicates where they are to be assigned.
|
Routing
|
Routing is the description of all of the resources, steps, and activities associated with a path or routing associated with a manufacturing or production process. Typically, a routing contains people, machines, tooling, operations, and steps.
|
SalesOrder
|
The SalesOrder is a order or customer order, it is a step beyond a PurchaseOrder in that the receiving entity of the order also communicates SalesInformoration about the Order along with the Order itself. The SalesOrder is intended to be used when a order needs to be communicated between business applications and the PurchaseOrder terms and conditions and quantities have been agreed to. This agreement may occur in an electronic or by other means.
|
SequenceSchedule
|
A ShipTo Partner is required to represent the business partner that the goods or services are shipped to.
Optionally, partner types SoldTo, BillTo and ShipFrom, and Supplier can be used.
|
Shipment
|
A Shipment document identifies and describes a specific collection of goods to be transported by a carrier and delivered to one or more business partner destinations. A Shipment document represents the extent and content of "transportation work" to be done by the carrier. For transportation efficiency, a shipment document typically consolidates deliveries to multiple destinations within a certain geographic region and may provide carrier routing instructions to each delivery stop.
|
ShipmentSchedule
|
Commonly, the ship schedule is generated by a material planning application and transmitted to an order or material planning application.
|
UnitOfMeasureGroup
|
Unit-of-Measure Group is a set of related Units-of-Measure (UOMs). A UOMGROUP is typically defined by inventory control systems and assigned to many different ITEMs that otherwise share common handling, packaging or other physical inventory attributes.
|
WIPConfirm
|
Work-in-Progress confirmation represents confirmation of the movement of WIP materials. The noun refers to general information about the entire WIP transaction, as well as line item detail about the specific WIP operation or routing step. This may apply to the movement of raw materials or finished products.
|
WIPMerge
|
WIPMerge is used to notify a Manufacturing Application of the creation of a single production lot from multiple production lots of a product being made on a production order.
|
WIPMove
|
WIPMOVE is used to communicate which processing step the product is coming from and which step it is being moved to, along with the quantity moving and the time this event occurred.
|
WIPRecover
|
WIPRecover is used to notify a Manufacturing Application of the creation of usable production materials from material previously considered unsuitable for production use. This is most often likely to represent a return to production of scrap material.
|
WIPSplit
|
WIPSplit is used to notify a Manufacturing Application of the creation of multiple production lots from a single production lot of a product being made on a production order.
|
WIPStatus
|
WIPSTATUS is used to notify a Manufacturing Application of the progress of a production order at a point in time.
|
AcknowledgeDeliveryReceipt
|
The AcknowledgeDeliveryReceipt may be used to notify the shipping business partner that the shipment has been received by the customer or consignee destination, and alert them to any discovered discrepancies. The acknowledgement may contain the full detail of the receipt as created by the receiving party or just the discrepancies and other exception conditions.
The AcknowledgeDeliveryReceipt BOD supports receipt acknowledgements at either the line item level and/or the ship unit level. Intermediate transportation/logistics providers or freight forwarding partners can use this document to acknowledge the receipt of entire shipping units without detailing the corresponding contents.
|
AcknowledgePurchaseOrder
|
The purpose of the ACKNOWLDGE PO Business Object Document is to acknowledge receipt of the Purchase Order and to reflect any changes.
Commonly, the acknowledgment is generated by an order management application and transmitted to a purchasing or procurement application.
|
AddPurchaseOrder
|
The purpose of the ADD PO Business Service Request is to communicate from one business application to one or more other business applications that a Purchase Order has been added or needs to be added, depending on the business case.
There are many possible business applications in several environments that may use this capabilit
|
AddQuote
|
The purpose of the AddQuote is to communicate from one business application to one or more other business applications that additional data related to a quote has been added or needs to be added, depending on the business case.
|
AddRequestForQuote
|
The purpose of the AddRequestForQuote is to communicate from one business application to one or more other business applications that additional data related to a Request for Quote has been added or needs to be added, depending on the business case
|
AddRequisition
|
The purpose of the AddRequisition is to send demand for goods or services to another business application for consideration of buying or in some way obtaining the requested items.
|
AddSalesOrder
|
The purpose of the Add Salesorder is to communicate from one business application to one or more other business applications that a Sales Order has been added or needs to be added, depending on the business case.
This BOD commonly causes updates to occur.
|
AllocateCostingActivity
|
The purpose of the AllocateCostingActivity BOD is to enable the update of Activityinformation from a production or manufacturing application to a costing application. This is necessary for applications that are based on a Dual Cycle Accounting model. This Dual Cycle Accounting model does not capture the details of the Activities that caused entries to be made in the general ledger application, but instead captures them in a separate overall costing application.
This BOD commonly causes updates to occur and may be used as part of a large integration scenario or as a single tool for updating data.
For Single Cycle accounting systems, the PostJournalEntry BOD will be used to ensure that the costing information flows from the Manufacturing Application to the Financial Application.
In most cases either PostJournal or AllocateActivity will be used when the Financial applications are included with Logistics, but both Business Service Requests will not be used in the same integration scenario.
|
CancelMaintenanceOrder
|
The purpose of the CamcelMaintenanceOrder is to publish to a business application or system the need to cancel a Maintenance Order or one or more of it's operations.
One possible scenario is the cancellation of Maintenance Order from field devices, service trucks, production system, etc.
|
CancelProductionOrder
|
The purpose of the CancelProductionOrder is to notify a Manufacturing Application of the need to cancel a previous order to make a product in a specific quantity, for a specific need by date. This BOD may be used to cancel an entire Production Order, or a specific line on the production order.
Processing Note:
This cancel must refer to the original document and/or item ordered. To cancel the entire order, include only the Header information for the instance of the Production Order you wish to cancel. To cancel a line or several lines, each line to be cancelled must be included in the request.
|
CancelProductRequirement
|
The purpose of the CancelProductRequirement is to communicate from one business application to one or more other business applications that a previously requested item is no longer required.
Processing Note: This cancel must refer to the original item requested. To cancel the item(s), each item to be cancelled must be included.
|
CancelPurchaseOrder
|
The purpose of the Cancel PurchaseOrder is to communicate from one business application to one or more other business applications that a previous Purchase Order or Purchase Order line is no longer needed.
Processing Note: This cancel must refer to the original document and/or item ordered. To cancel the entire order, include only the Purchase Order Header information for the instance of the Purchase Order you wish to cancel. To cancel a line or several lines, each line to be cancelled must be included.
This BOD commonly causes updates to occur and may be used as part of a larger integration scenario or as a single tool for communicating demand.
|
CancelQuote
|
The purpose of the CancelQuote is to publish to a business application or system the need to cancel an entire Quote or one or more of its line items.
|
CancelRequestForQuote
|
The purpose of the CancelRequestForQuote is to publish to a business application or system the need to cancel an entire Request for Quote or one or more of its line items.
|
CancelRequisition
|
The purpose of the CancelRequisition is to communicate from one business application to one or more other business applications that a previous requisition or requisition line item is no longer needed.
|
CancelSalesOrder
|
The purpose of the Cancel SalesOrder is to communicate from one business application to one or more other business applications that a previous Sales Order, line, or schedule is no longer needed.
Processing Note: This cancel must refer to the original document, item, and schedule. To cancel the entire order, include only the Salesorder Header information for the instance of the Salesorder you wish to cancel. To cancel a SalesOrder Line or SalesOrder Schedule, each line or schedule to be cancelled must be included in the occurrence of the BOD with the Corresponding LineNumber. If a schedule is to be cancelled, the line that the schedule refers to MUST be included or the schedule can not be found.
|
ChangeCreditStatus
|
The purpose of the ChangeCreditStatus is to notify the customer order management application that the overall credit status of a trading partner has changed or status on specific order(s) are to be changed.
|
ChangePurchaseOrder
|
The purpose of the Change Purchaseorder is to request another business application to make changes to an existing Purchase Order. This change must refer to the original document and/or item ordered. The change processing assumes replacement of fields sent, with the exception the identifying fields of the Purchase Order.
If any of these key fields require changing, (i.e. the PurchaseOrder Document Id or a LineNumber) that constitutes a cancellation of the request and/or the addition of another Purchase Order.
|
ChangeQuote
|
The purpose of the ChangeQuote is to request that another business application component make changes to an existing Quote
|
ChangeRequestForQuote
|
The purpose of the ChangeRequestForQuote is to request that another business application component make changes to an existing Request for Quote.
|
ChangeRequisition
|
The purpose of the ChangeRequisition is to communicate changes to an existing request for goods or services. This change must refer to the original document and/or item requested. The change processing assumes replacement of fields sent, with the exception of: the key fields for the Order and Line.
If any of the Field Identifiers above require changing, that constitutes a cancellation of the request and/or the addition of another Requisition.
|
ChangeSalesOrder
|
The purpose of the Change SalesOrder is to request that another business application component make changes to an existing Sales Order.
Processing Note: This change must refer to the original document and/or item ordered. The change processing assumes replacement of fields sent, with the exception of the fields that uniquely identify the document and/or it's line, schedule or subline. These include the DocumentId and the LineNumber for the Line, SubLine, and Schedule.
If any of the Field Identifiers above require changing, that constitutes a cancellation of the request and/or the addition of another Sales Order.
This BOD commonly causes updates to occur
|
ConfirmBOD
|
Replacement for ConfirmBOD. This BOD reports on the outcome of processing a BOD. Only one BODOutcome noun will be returned, corresponding to a previously transmitted BOD that was earmarked for returning outcome notification. Summaary BOD-level outcome is reported in the Header, with noun-specific errors or warnings reported for each noun instance that accompanied the original BOD.
|
ConfirmEngineeringChangeDocument
|
The purpose of the ConfirmEngineeringChangeDocument to communicate to a business application module or system that the synchronization of a specified engineering change document has been completed successfully.
This BOD may be necessary to address the Make to Order, Assemble to Order, or Mixed Mode business ordering scenarios in a Order Management to Manufacturing application integration scenario.
There are many possible business applications in several environments that may use this capability. For example, a PDM, MRP, Inventory, or Manufacturing business application could use this to communicate the requirement to Synchronize a Engineering Change Document.
|
ConfirmInventoryIssue
|
The purpose of the ConfirmInventoryIssue is to notify a Manufacturing Application of the issue of required material to a production order for making a product. This BOD is also used to notify a Manufacturing Application of the return of material from a production order back into inventory. The business environments most likely to require this capability are any type of manufacturing scenario.
This BOD communicates what the item is that is being issued, where it is being issued from, which processing operation it is being issued to, what quantity was issued, and at what time this event occurred. In the case of a return, this BOD communicates what the item is that is being returned, which processing operation it is being returned from, which inventory location it is being returned to, the quantity being returned, and the time at which this event occurred.
|
CreateMaintenanceOrder
|
The purpose of the CreateMaintenanceOrder is to publish to a business application component or system the need to create or update a Maintenance Order.
One possible scenario is the synchronization of Maintenance Order between field devices, service trucks, etc. with a CMMS system.
|
CreateProductionOrder
|
The purpose of the CreateProductionOrder is to notify a Manufacturing Application of the need to make a product in a specific quantity, for a specific need by date. The business environments most likely to require this capability are an Engineer to Order or a Configure to Order manufacturing scenario.
This BOD communicates what the product configuration is and what choices have been made from the configuration
|
CreateRequisition
|
The purpose of the CreateRequisition is to notify another business application of the need to order parts in a specific quantity, for a specific need by date.
|
GetBillOfMaterial
|
The purpose of the GetBillOfMaterial is to enable an application to request specific Item Bill of Material information from another business application module. The response to the GetBillOfMaterial is the ShowBillOfMaterial.
There are many possible business applications in several environments that may use this capability. For example, an MRP, Inventory, or Manufacturing business application could use this to communicate Item Bill of Material information.
|
GetConsumption
|
The most common use of the GetConsumption is to request a buyer's usage information about an item or product for the supplier of such item or product. This BOD will not create or update either buyer's or supplier's inventory records. The receiver of the request is responsible to make effective use of this information.
The BOD can be used in the following ways:
(1) for a supplier of goods to request from the buyer, the consumptn status of goods
(2) for a vendor to request from the retailer if retail sales of goods have been made; and
(3) for inventory systems to request consumptn status from plant data collection and warehouse management systems.
This is an outline of the business flow that this BOD supports:
(1) Overall purchase, replenishment or vendor managed inventory agreement is in place and/or a Get Consumptn message is sent by the supplier.
(2) Show Consumptn Message is returned the to supplier, distributor or third party logistics provider, that material has been consumed. This is done in response to events such as these (and/or the Get message), depending on implementation context:
· Material is replenished to line side at manufacturing facitliy.
· Material is assembled into final product.
· Material is purchased and removed from facility by customer.
(3) Supplier, distributor, third party logistics provider replenishes material, using information provided in the Show Consumptn message, the demand and shipment forecasts, and the terms of the overall purchase or vendor managed inventory agreement.
|
GetCredit
|
The purpose of the GetCredit is for the order management application to request credit data for a trading partner from the credit management function. The GetCredit does not imply any update, it is only an inquiry function. The ShowCredit discussed in the next chapter will be the response back to the order management application.
Discussed in a later chapter is the UpdateCredit. The UpdateCredit may be used in both directions between the order management and the accounts receivable application. Its purpose is to keep order, shipment and open item amounts current. Finally, the ChangeCreditStatus is used to update the order management application with any changes in business status for a particular trading partner.
|
GetDeliveryReceipt
|
The GetDeliveryReceipt may be used to request information about a specific expected (unreceived) or previously received goods delivery. The response to the GetDeliveryReceipt request is ShowDeliveryReceipt.
For expected deliveries, the ShowDeliveryReceipt document content may act as a receiving template or checklist to identify the quantity and shipping configuration of the expected goods. The ShowDeliveryReceipt supports describing shipment content at either the line item level and/or the ship unit level. Intermediate transportation/logistics providers or freight forwarding partners can use this document to acknowledge the receipt of entire shipping units without detailing the corresponding contents.
|
GetDispatchList
|
The purpose of the GetDispatchList is to enable a business application module to request this information from another business application. The reply to this BOD is the ShowDispatchList.
|
GetElectronicCatalog
|
The purpose of the GetElectronicCatalog is to enable a business application module or system to request catalog information.
The Catalog information that is requested by the GetElectronicCatalog may include
· Item Identifiers
· Specifications
· Pricing Information agreed on either
· Purchase Agreements
· Price Lists
· Availability and Delivery Information
· Related Items and accessories
There are many possible business applications in several environments that may use this capability. Some examples of usage scenarios are:
· Manufacturer exchanging catalogs with distributors/ suppliers/e-marketplaces
· Distributors/ Suppliers/ e-marketplaces exchanging catalogs with Buyers or other trading partners
It may also be necessary to support Component Supplier Management (CSM) scenarios. In this scenario a company will provide a service of sourcing and codifying the products of many companies and publishing a consolidated catalog.
The Catalog exchange scenario can be implemented either as a simple scenario using a single BOD, or in the case or large catalogs involving complex pricing scenarios or partner specific details, as multiple BODs.
|
GetEngineeringChangeDocument
|
The purpose of the Get EngineeringChangeDocument is to communicate to a business application module or system the need to request a Show EngineeringChangeDocument for the Engineering Change Document specified in the Message.
This BOD may be necessary to address the Make to Order, Assemble to Order, or Mixed Mode business ordering scenarios in a Order Management to Manufacturing application integration scenario.
There are many possible business applications in several environments that may use this capability. For example, a PDM, MRP, Inventory, or Manufacturing business application could use this to communicate the requirement to synchronize a Engineering Change Document.
|
GetInventoryCount
|
The purpose of the GetInventoryCount is to request an occurrences of a Inventory Count information from an ERP system. This count may be a cycle count or a physical count. This BOD may also apply to planned or unplanned inventory counts.
|
GetInventoryIssue
|
The purpose of the GetInventoryIssue is to request inventory issue information against an order, from an ERP system into a PDC system to confirm the InventoryIssue transaction (BOD).
|
GetInvoice
|
The purpose of the GetInvoice is to enable a request of an invoice. This BOD may be used as a request by a Customer to its Supplier. The SHowInvoice BOD would be the expected response.
|
GetItemCrossReference
|
The purpose of the GetItemCrossReference is to enable a business application module or system to request information concerning an Item cross-reference. Cross-references may be to other item identifiers to the same form fit and function, as well as references to item identifiers of other items (form fit and function). In this document item relationships is used to refer to where the "to item" identifier, identifies a different form, fit and function to the "from item" identifier. It should be noted that the item identifier that is "Primary" in one system may be a secondary identifier in another system.
For example, in the Application Integration space, the manufacturing system may regard the "Item Number" as the primary identifier. The Order Management System may regard the Catalog number as the primary identifier. A company that manufacture hand held multi-meters may identify a given item in manufacturing with a 12 digit numeric code, 5432 123 12345. The marketing and sales department may refer to the same item by it’s catalog number of FL 30/4.
In the Business to Business case a supplier of hand held multi-meters may market their products through a catalog provider. The supplier has an item identifier with a corresponding party specific cross reference to the catalog providers identifier for the same item. The catalog provider has a item identifier for hand held multi-meters and a corresponding party specific cross reference to the suppliers item number.
This BOD may be necessary to address Manufacturers, Distributor Resellers business ordering scenarios in a Order Management to Manufacturing application integration scenario. It may also be necessary to address Component Supplier Management scenarios.
There are many possible business applications in several environments that may use this capability. For example, a PDM, MRP, Inventory, or Manufacturing business application could use this to communicate the requirement to synchronize an Item cross-reference. Item cross-references may be specific to a given party. Examples may include, (but are not limited to):
· Customers
· Suppliers
· Manufacturers
· Carriers
· Standards Associations
Party specific cross-references include:
· Customer Part Number
· Supplier Part Number
· Manufacturers Part Number
Cross-reference types may also be universal. Universal item cross-reference types may include, (but are not limited to)
· Universal Packaging Code (UPC)
· European Article Number (EAN)
· Harmonized Schedule B number
· GTIN Number
· ISBN Number for Books
The BOD may be used to relate item identifiers for item identifiers that identify different items (form fit and function). The Relationship types may also be universal. Universal item relationship types may include, (but are not limited to)
· Accessories
· Spares
· Consumables
An example of this in a business to business context might be a customer letting a supplier know the valid substitutes that a supplier may supply to fulfill an order for a specific item number. An example of this in a application integration context might be between a Product Data Management (PDM) system and an Order Management system for accessories that may be offered to a customer with the sales of a major item. For example, if a designers of a video camera, have designed it to work with the following accessories;
· tripod,
· extended life battery pack
· external microphone
· Head Cleaner
The video camera may be designed to have the following spares replaced by the consumer
· Lens Cover
· Strap
· Handle
The video camera may need the following consumable items on a recurring basis
· Video Cassettes
· Batteries
· Lens Cleaners
the relationship between these items and the video camera may need to represented to the Customer in Web Based ordering or Customer Service Rep (CSR), in desk based order entry.
|
GetItemMaster
|
The purpose of the GetItemMaster is to enable a business application module to request information concerning a specific ITEM from another business application. The reply to this BOD is the ShowItemMaster.
There are many possible business applications in several environments that may use this capability. For example, an MRP, Inventory, or Manufacturing business application could use this to request item information.
|
GetLedgerActual
|
The purpose of the GetLedgerActual is to enable an enterprise application to request detailed accounting ledger actual data.
|
GetListBillOfMaterial
|
The purpose of the GetListBillOfMaterial is to enable an application or component to request a summary list of Bill of Material information from another business application or component. The response to the GetListBillOfMaterial is the ListBillOfMaterial
The GwtListBillOfMaterial also enables the retrieval of information across several documents by using selection fields. An example of this could be requesting all Bills of Material for a specific ITEM. This type of functionality is limited to the capabilities of the responding application and needs to be determined during the implementation project.
There are many possible business applications in several environments that may use this capability. For example, an MRP, Inventory, or Manufacturing business application could use this to communicate Item Bill of Material information.
|
GetListDeliveryReceipt
|
The GetListDeliveryReceipt may be used to request information about a set of expected (unreceived) or previously received goods deliveries meeting certain selection criteria. The response to the GetListDeliveryReceipt request is ListDeliveryReceipt.
|
GetListInventoryCount
|
The purpose of the GetListInventoryCount is to to enable a business application to request several occurrences of summary Inventory Count information from an ERP system. This count may be a cycle count or a physical count. This BOD may also apply to planned or unplanned inventory counts.
|
GetListItemMaster
|
The purpose of the GetlistItemMaster is to enable a business application module to request summary information concerning an ItemMaster or ITEMs from another business application.
This type of functionality is limited to the capabilities of the responding application and needs to be determined during the implementation project.
The response to this request is the ListItemMaster. This BOD does not usually cause updates to occur.
|
GetListLedgerActual
|
The purpose of the GetListLedgerActual is to request information containing summary information for one or more ledgers.. The response to this request is ListLedgerActual.
|
GetListMaintenanceOrder
|
The purpose of the GETLIST MAINTORDER Business Object Document is to enable a business application module to request information containing summary information for one or more MAINTORDER. The response to this request is the LIST.
The GetListMaintenanceOrder enables the retrieval of information across several documents by using selection fields. An example of this could be requesting all Resource Component occurrences for a specific MaintenanceOperation. This type of functionality is limited to the capabilities of the responding application and needs to be determined during the implementation project.
|
GetListPickList
|
The purpose of the GetListPickList is to enable a business application to request summary information for one or more Picking Lists from an ERP system. If a List of documents is requested, that list will be used so a selection and Get request of a specific picking list can be made, if necessary.
|
GetListProductionOrder
|
The purpose of the GetListProductionOrder is to enable an business software component to request summary Production Order information from another business application module.
The response to this request is the ListProductionOrder.
The GetListProductionOrder also enables the retrieval of information across several documents by using selection fields. An example of this could be requesting all ProductionOrder Lines for a specific Item. This type of functionality is limited to the capabilities of the responding application and needs to be determined during the implementation project.
|
GetListPurchaseOrder
|
The purpose of the GetList PurchaseOrder is to enable a business application to request information containing summary information for one or more Purchase Orders from another business application.
The GetList PurchaseOrder also enables the retrieval of information across several documents by using selection fields. An example of this could be requesting all PurchaseOrder Lines for a specific ItemId. This type of functionality is limited to the capabilities of the responding application and needs to be determined during the implementation project.
This BOD does not usually cause updates to occur. It may be used as part of a large integration scenario or as a single tool for requesting information on existing demands for goods or services. Examples include:
1. A Plant Data Collection application could use this BOD to request information from a Purchasing application.
2. A MRP, Inventory or Manufacturing business application could use this to obtain order information.
|
GetListQuote
|
The purpose of the GetlistQuote is to enable a business application module to request information containing summary information for one or more Quotes. The response to this request is List Quote.
The GetlistQuote also enables the retrieval of information across several documents by using selection fields. An example of this could be requesting all SalesInformation Component occurrences for a specific Quote Line. This type of functionality is limited to the capabilities of the responding application and needs to be determined during the implementation project.
|
GetListRequestForQuote
|
The purpose of the GetllistRequestForQuote is to enable a business application module to request information containing summary information for one or more Request for Quotes. The response to this request is ListRequestForQuote.
The GetllistRequestForQuote also enables the retrieval of information across several documents by using selection fields.
|
GetListRequisition
|
The purpose of the GetlistRequisition is to enable a business application to request summary information for one or more requisitions from another business application.
The GetlistRequisition also enables the retrieval of information across several documents by using selection fields. An example of this could be requesting all Requisition Lines for a specific OrderItem. This type of functionality will be limited to the capabilities of the responding application and needs to be determined during the implementation project
|
GetListRouting
|
The purpose of the GetListRouting is to communicate to a business application component or module a request for a summary list of a Routing structure or structures to be returned in a ListRouting.
|
GetListSalesOrder
|
The purpose of the GetList SalesOrder is to enable a business application module to request information containing summary information for one or more SalesOrder from another business application.
The response to this request is the List SalesOrder.
The GetList SalesOrder also enables the retrieval of information across several documents by using selection fields. An example of this could be requesting all SalesOrder Lines for a specific ITEM. This type of functionality is limited to the capabilities of the responding application and needs to be determined during the implementation project.
This BOD does not usually cause updates to occur. It may be used as part of a large integration scenario or as a single tool for requesting information on existing demands for goods or services.
For example, a Sales Automation application may use this BOD to ask for information from a Customer Order application.
|
GetListUnitOfMeasureGroup
|
The purpose of the GetListUnitOfMeasure is to communicate to a business application component or module a request for a summary list of a UnitOfMeasure Groups to be returned in a ListUnitOfMeasure.
There are many possible business applications in several environments that may use this capability. For example, an MRP, Inventory, or Manufacturing business application could use this to request alternate UOM information for one or more items.
|
GetMaintenanceOrder
|
The purpose of the GetMaintenanceOrder is to enable a business applications module to request this information from another business application. The response to this BOD is the ShowMaintenanceOrder.
|
GetMatchDocument
|
The purpose of the GetMatchDocument is to enable a business application module to request information concerning invoice matching from another business application. The reply to this BOD is the ShowMatchDocument.
This BOD does not usually cause updates to occur. There are several possible business applications in several environments that may use this capability. The description and the pictures below visualize the possible use of this BOD.
In certain application suites, purchase order and invoice matching functionality exists in the purchasing application, while in other suites this functionality exists in the accounts payable application.
The invoice matching process may include several document types, including the following:
Two way match - Purchase Order and the Invoice
Three way match - Purchase Order, Invoice, and the Receipt
Four way match – Purchase Order, Invoice, Receipt, and Inspection results
Note: For the four way match, it is assumed that inspection results have been updated on the Purchase Order for visibility in matching.
When matching takes place in the purchasing application, the purchasing application may have to request the accounts payable application to provide the supplier invoice to which purchasing transactions (purchase orders, goods receiving notes and inspection tickets) are to be matched. This is the generally the situation when the invoice is initially entered into the accounts payable application.
Note that in some situations, accounts payable will send invoices to the purchasing application unsolicited. In others, invoices are entered directly into the purchase order application or are created by the purchase order application when using evaluated receipt settlement (ERS) and in this instance, it is not necessary to perform the separate integration described in these chapters.
When matching takes place in the accounts payable application, the purchasing application must inform the accounts payable application of the purchasing transactions (purchase orders, goods receiving notes and inspection tickets) to which the invoice (in accounts payable) is to be matched. Alternatively, the accounts payable application can request the information.
The purpose of the GetMatchDocument is to enable both the accounts payable application and the purchasing application to request the transactions that are required to be matched. In both cases, the receiving application will use the ShowMatchDocument to return the requested information.
|
GetParty
|
The purpose of the GetParty is to facilitate keeping party information synchronized that exists on separate data bases. The GetParty allows a business application to request information about a given party. The ShowParty is the response to this request providing the specific information requested.
|
GetPersonnel
|
The purpose of the GetPersonnel is to request Personnel data for a worker.
|
GetPickList
|
The purpose of the GetPickList is to enable a request for the retrieval of a single Picking List from an ERP system. The reply to this request is the ShowPickList.
Individual lines from a Picking List are not selectable with this BOD. Only the complete document is selected and returned.
|
GetPlanningSchedule
|
Since collaboration between a customer and a supplier can potentially go through several rounds of negotiations, both parties can use the same BOD to communicate their current demand or supply schedule in response to what they received from the other party. Either party can indicate detailed exception descriptions along with reason code and action code to the other party why the original demand/supply requirements need to be adjusted using the optional Data Type PlanningScheduleException.
The purpose of the GetPlanningSchedule is to enable a business applications module to request this Planning Schedule information from another business application. The response to this BOD is ShowPlanningSchedule.
|
GetPriceList
|
The purpose of the GetPriceList is to enable a business application module or system to request information concerning new or existing product price lists.
This BOD may be necessary to address the Make to Order, Assemble to Order, or Mixed Mode business ordering scenarios in an Order Management to Manufacturing application integration scenario.
There are many possible business applications in several environments that may use this capability. For example, a Manufacturing, distributor or reseller business application could use this to communicate the price change or request a price list.
It may also be necessary to support Component Supplier Management (CSM) scenarios. In this scenario a company will provide a service of sourcing and codifying the products of many companies and publishing a consolidated catalog. A customer purchases the product from the Catalog provider. They have the capability to do comparison shopping from the catalog. Supplier Certification may be provided by the Catalog provider.
This definition of price list is intended to support simple pricing scenario, especially pricing that may accompany a published price list. It is not intended to support complex pricing environments that may be needed to support features such as;
· Deals and Promotions
· Coupons and Sales Incentives
· Rebates and Accruals
This functionality will be addressed in a subsequent release. It is a working assumption that the representation of complex qualifications, coupons and sales incentives are rarely communicated between systems.
|
GetProductAvailability
|
The purpose of the GetProductAvailability is to enable requests of product availability data by an Order Management business application to an Available to Promise (ATP) or Production business application. The business process scenario is the Order Management application interacting with the Available to Promise or Production application in order to determine availability of a product for the customer.
This scenario is commonly referred to as Make to Order or Build to Order.
The response to this request is the ShowProductAvailability.
|
GetProductionOrder
|
The purpose of the GetProductionOrder is to enable an business application module to request specific Production Order information from another business application module. The reply to this is the ShowProductionOrder.
|
GetPurchaseOrder
|
The purpose of the Get PurchaseOrder is to enable a business application module to request information concerning a specific purchase order from another business application. The reply to this BOD is the Show PurchaseOrder.
There are several environments that may use this capability. For example, an MRP application may use this BOD to ask for information from a Order Management application, or a Plant Data Collection application may also use this BOD to request information from a Order Management application. This may als happen across business parties.
This BOD does not usually cause updates to occur.
|
GetQuote
|
The purpose of the GetQuote is to enable a business applications module to request this Quote information from another business application. The response to this BOD is ShowQuote.
|
GetRequestForQuote
|
The purpose of the GetRequestForQuote document is to enable a business applications module to request Request for Quote information from another business application. The response to this BOD is SHOWRequestForQuote.
|
GetRequisition
|
The purpose of the GetRequisition is to enable a business application to request information concerning a specific requisition from another business application. The reply to this BOD is the ShowRequisition.
|
GetRouting
|
The purpose of the GetRouting is to communicate to a business application module or system a request for an existing Routing structure to be returned in a ShowRouting.
|
GetSalesOrder
|
The purpose of the Get SalesOrder is to enable a business application module to request information concerning a specific sales order from another business application. The reply to this BOD is the Show SalesOrder.
There are several possible business applications in several environments that may use this capability. For example, a Sales Automation application may use this BOD to ask for information from a Customer Order application.
|
GetSequenceSchedule
|
Commonly, the sequence schedule is generated by a work in process application and transmitted to an order or material planning application.
The purpose of the GetSequenceSchedule is to enable a business applications module to request this SequenceSchedule information from another business application. The response to this BOD is ShowSequenceSchedule.
|
GetShipmentSchedule
|
Commonly, the ship schedule is generated by a material planning application and transmitted to an order or material planning application.
The purpose of the GetShipmentSchedule is to enable a business applications module to request this ShipmentSchedule information from another business application. The response to this BOD is ShowShipmentSchedule.
|
GetUnitOfMeasureGroup
|
The purpose of the GetUnitOfMeasureGroup is to communicate to a business application component or module a request for an existingUnitOfMeasureGroup to be returned in a ShowUnitOfMeasureGroup.
There are many possible business applications in several environments that may use this capability. For example, an MRP, Inventory, or Manufacturing business application could use this to request alternate UOM information for one or more items.
|
GetWIPConfirm
|
The purpose of the GetWIPConfirm is to enable the requesting of data necessary to perform a confirmation of the movement of WIP (Work in Progress).
|
GetWIPStatus
|
The purpose of the GetWIPStatus is to notify a Manufacturing Application of the progress of a production order at a point in time. The business environments most likely to require this capability are any type of manufacturing scenario where BODs for individual manufacturing transactions and events are not utilized.
This BOD communicates what quantities of end product reside at which processing steps along with the time this snapshot view was taken. The response to this BOD is ShowWIPStatus.
|
IssueInventoryMovement
|
The purpose of the IssueInventoryMovement is to give the organization the ability to do a quantity movement of materials from one organizational unit to another organizational unit.
|
ListBillOfMaterial
|
The purpose of the ListBillOfMaterial is to communicate one or more summary listings of BOM information to another business application component. This may be the result of a GetList request or it may be initiated by some other business event.
|
ListDeliveryReceipt
|
The ListDeliveryReceipt document may be used to obtain limited information listing about a expected (unreceived) or previously received goods deliveries that match certain selection criteria in a GetListDeliveryReceipt request.
Additional information about a specific DeliveryReceipt may be obtained through ShowDeliveryReceipt by using the listing information to populate a GetDeliveryReceipt request.
|
ListInventoryCount
|
The purpose of the ListInventoryCount is the response to the GetListInventoryCount request for several occurrences of summary Inventory Count information from an ERP system. This count may be a cycle count or a physical count. This BOD may also apply to planned or unplanned inventory counts.
|
ListItemMaster
|
The purpose of the ListItemMaster is to enable a business application module to respond to a GetlistItemMaster request or to proactively send a listing of summary information about ITEMs to one or more other applications.
There are many possible business applications in several environments that may use this capability. For example, a MRP, Inventory, or Manufacturing business application could use this to request item information. The picture below visualizes a possible use of this BOD.
|
ListLedgerActual
|
The purpose of the ListLedgerActual is to publish one or more summary listings of ledger information. This may be in response to a GetListLedgerActual request or to published proactively as a listing of summary ledger information for a business event.
|
ListMaintenanceOrder
|
The purpose of the ListMaintenanceOrder is to publish one or more summary listings of Maintenance Order information to other business application component. This may be in response to a GetListMaintenanceOrder request or to proactively publish a listing of summary Maintenance Order information for a business event.
When a receiving application receives this BOD, the information can be used as is or it may be used to initiate a selection of a specific Maintenance Order through the GetMaintenanceOrder request. The processing is designed to provide multiple occurrences of summary data.
|
ListPickList
|
The purpose of the ListPickList is to provide a list of Picking Lists from an ERP system to another application. This BOD may be initiated in response to a GetListPickList request or upon some business event.
When a receiving application receives this BOD, the information can be used as is or it may be used to initiate a selection of a specific PickList through the GetPickList request. The processing is designed to provide multiple occurrences of summary data. This BOD will not usually cause updates to occur.
|
ListProductionOrder
|
The purpose of the ListProductionOrder is to enable an business software component to respond to a GetListProductionOrder request or to proactively send a listing of summary information about Production Orders to another business software component
|
ListPurchaseOrder
|
The purpose of the List PurchaseOrder is to send information relative to demand for goods or services to another business application. This may be in response to a GetList PurchaseOrder request, or it may be a notification vehicle, initiated upon an event in a business application.
The LIST verb describes the behavior of supplying one or several documents in a summary format to the requesting business application. These listings of information may be supplied for Purchase Orders, PO Lines, or PO Sub-Lines.
This BOD usually does not cause updates to occur and may be used as part of a larger integration scenario or as a single tool for communicating demand. There are many possible business applications in several environments that may use this capability.
For example:
1. A PO application could use this BOD to send information to a Plant Data Collection application.
3. A MRP, Inventory or Manufacturing business application could use this to obtain order information.
|
ListQuote
|
The purpose of the List Quote is to publish one or more summary listings of Quote information to other business application component. This may be in response to a GetlistQuote request or to proactively publish a listing of summary Quote information for a business event.
|
ListRequestForQuote
|
The purpose of the ListRequestForQuote is to publish one or more summary listings of Request for Quote information to other business application component. This may be in response to a GetListRequestForQuote request or to proactively publish a listing of summary Request for Quote information for a business event.
|
ListRequisition
|
The purpose of the ListRequisition is to send information relative to demand for goods or services to another business application. This may be in response to a GetlistRequisition request, or it may be a notification vehicle, initiated upon an event in a business application.
The List verb describes the behavior of supplying one or several documents in a summary format to the requesting business application. These listings of information may be supplied for requisition documents, or requisition lines and/or requisition sub lines.
|
ListRouting
|
The purpose of the ListRouting is to communicate one or more summary listings of Routing information to another business application component. This may be the result of a GetList request or it may be initiated by some other business event.
|
ListSalesOrder
|
The purpose of the List SalesOrder is to enable a business application module to respond to a GetList SalesOrder request or to proactively send a listing of summary information about sales orders to one or more other applications.
This BOD does not usually cause updates to occur. It may be used as part of a large integration scenario or as a single tool for sending information concerning existing demands for goods or services.
For example, a Customer Order application may use this BOD to respond to a request for information from a Sales Automation application.
|
ListUnitOfMeasureGroup
|
The purpose of the ListUnitOfMeasureGroup is to supply Unit-of-Measure Group summary information to another business application module. This may be the result of a GetListUnitOfMeasureGroup request or some initiated by some other business event.
When a receiving application receives this BOD, the information can be used as is or it may be used to initiate a selection of a specific UnitOfMeasureGroup through the GetUnitOfMeasureGroup request. The processing is designed to provide multiple occurrences of summary data.
This BOD usually does not cause updates to occur.
There are many possible business applications in several environments that may use this capability. For example, an MRP, Inventory, or Manufacturing business application could use this to request alternate UOM information for one or more items.
|
LoadLedgerBudget
|
The purpose of the LoadLedgerBudget is to transmit budget amounts from all possible source applications throughout an enterprise to a general ledger or budget application.
|
LoadMatchDocument
|
In certain application suites, purchase order / invoice matching functionality exists in the purchasing application, while in other suites this functionality exists in the accounts payable application.
The invoice matching process may include several document types, including the following:
Two way match - Purchase Order and the Invoice
Three way match - Purchase Order, Invoice, and the Receipt
Four way match - Purchase Order, Invoice, Receipt, and Inspection results
For the four way match, it is assumed that inspection results have been updated on the Purchase Order for visibility in matching.
When matching takes place in the purchasing application, the accounts payable application may have to inform the purchasing application of the supplier invoice to which purchasing transactions (purchase orders, goods receiving notes and inspection tickets) are to be matched if the invoice is initially entered into the accounts payable application. Note that in some situations, invoices are entered directly into the purchase order application or are created by the purchase order application when using evaluated receipt settlement (ERS) and in this instance, it is not necessary to perform the separate integration described in these chapters.
When matching takes place in the accounts payable application, the purchasing application must inform the accounts payable application of the purchasing transactions (purchase orders, goods receiving notes and inspection tickets) to which the invoice (in accounts payable) is to be matched.
These integration scenarios have been developed for document matching to occur at the line level within the PuchaseOrder document and the Invoice document. This may be a one to one relationship, or it may be a many to one relationship from Invoice to PuchaseOrder or from the PuchaseOrder to the Invoice. Charges not associated with a specific Invoice line match be matched individually.
The LoadMatchDocument is for use both by the accounts payable application and the purchasing application in exchanging the transactions that are required to be matched.
Discussed in a later chapter are the UpdateMatchDocument. The purpose of UpdateMatchDocument is for the accounts payable application to send successful matching notification or a match fail.notification to a purchasing application.
|
LoadPayable
|
The purpose of the LoadPayable is to transmit data to create a payable open item in a payables application from the purchasing information generated in a purchasing application. The LoadPayable may also update the General Ledger, depending on the specific architecture of the financial applications.
The scope of the LoadPayable indicates that the supplier’s invoice is ready to be paid and has already been approved before the information moves to the accounts payable application. An approved invoice is also known as the voucher. OAGIS will define the scenario of invoices that get matched within the accounts payable application in a separate Business Service Request later.
Some financial applications have the general ledger and accounts payable databases tightly integrated where updates to the accounts payable application are automatically reflected in the general ledger balances.
The LoadPayable will transmit all information needed for both the accounts payable and the general ledger.
Other applications allow the general ledger balances to be updated separately from the accounts payable. The second model illustrates that the combination of the LoadPayable and PostJournalEntry will accomplish this scenario.
|
LoadProjectAccounting
|
The purpose of the LoadProjectAccounting is to enable all relevant sub-systems that submit single sided transactions to send information to a Project Accounting Application. This would include, but not necessarily be limited to:
· Accounts Payable
· Accounts Receivable
· Budget
· Order Management
· Purchasing
· Time and Labor
· Travel and Expense
The LoadProjectAccounting will cause common data to be loaded in a project accounting application.
|
LoadPurchaseLedgerInvoice
|
In certain application suites, purchase order / invoice matching functionality exists in the purchasing application, while in other suites this functionality exists in the accounts payable application.
The invoice matching process may include several document types, including the following:
· Two way match - Purchase Order and the Invoice
· Three way match - Purchase Order, Invoice, and the Receipt
· Four way match – Purchase Order, Invoice, Receipt, and Inspection results
Note: For the four way match, it is assumed that inspection results have been updated on the Purchase Order for visibility in matching.
When matching takes place in the purchasing application, the accounts payable application may have to inform the purchasing application of the unapproved supplier invoice to which purchasing transactions (purchase orders, goods receiving notes and inspection tickets) are to be matched if the invoice is initially entered into the accounts payable application. Note that in some situations, invoices are entered directly into the purchase order application or are created by the purchase order application when using evaluated receipt settlement (ERS) and in this instance, it is not necessary to perform the separate integration described in these chapters.
The purpose of the LoadPurchaseLedgerInvoice is to transmit data to create an unapproved open item in either a payables application or a purchasing application.
The scope of the LoadPurchaseLedgerInvoice indicates that the supplier’s invoice has not yet been approved and the invoice is to be used as part of the invoice matching process.
OAGIS has already defined the scenario for invoices that are approved for payment in a separate BOD namely LoadPayable.
|
LoadReceivable
|
The purpose of the LoadReceiveable is to transmit data to create a receivable open item in a receivable application from the billing information generated in an order management application. The LoadReceiveable may also update the General Ledger, depending on the specific architecture of the accounting application.
The scope of the LoadReceiveable is to create a BOD to recognize customer obligation (accounts receivable asset). Specific transactions include:
1. Sales Invoice
2. Credit Memo
3. Debit Memo
4. Charge Back
The LoadReceiveable may also be used for transaction that do not originate from an order management application.
The following two models illustrate that the LoadReceiveable may, in some cases, be adequate to update the financial applications, i.e., Receivables and General Ledger, and in other cases, will also require the PostJournal Business Object Document (BOD) to assure the General Ledger account balances are updated.
In the model above, the receivable application is a sub-ledger of the general ledger. Updates to G/L balances occur via the receivables module, therefore the Load Receivable contains both receivable and general ledger transaction information.
This other model illustrates the environment that sometime exists when General Ledger updates occur directly from the Order Management application. The reconciliation between the receivable and general ledger is a function within the financial applications and not of the integration space. This model allows the G/L balances to be updated in either detail or summarized form.
The scope of the role of the receivable application includes functions such as:
· Allowing Cash Application
· Dunning
· Dispute management
|
PostJournalEntry
|
The purpose of the PostJournal is to transmit data necessary to create a journal entry from any sub ledger business application to a general ledger application.
Many applications in the enterprise environment create data that cause changes in the account balances of a
general ledger application. Some components that have activity which will be reflected in a general ledger
application are:
1. Benefits
2. Costing
3. Human Resources
4. Inventory Control
5. Manufacturing
6. Payroll
7. Production
8. Treasury
By no means is this a complete list of all the components that create activity which generate a journal entry.
Many tasks that occur within the enterprise applications cause the creation of a General Ledger journal entry.
Tasks relate directly to the Component. For example, the adjustment of inventory value is a task that occurs within
the Inventory Control Component. Some of the tasks that would be catalysts for changes in a general ledger include:
1. Receiving Inventory
2. Issuing Inventory
3. Transferring Inventory
4. Adjusting Inventory Value
5. Adjusting Inventory Count
6. Calculating Material Variances
7. Calculating Labor Variances
8. Calculating Overhead Variances
|
ProcessInventoryIssue
|
The purpose of the ProcessInventoryIssue is to reflect an unplanned issue of an item to a miscellaneous location.
Possible reasons for this include:
1. Somebody broke the material,
2. The material is defective and needs replacing,
3. The material is used up and needs replenishment.
|
ProcessInventoryReceipt
|
The purpose of the ProcessInventoryTransfer is to give the organization the ability to do a quantity movement of materials from one organizational unit to another organizational unit.
|
ProcessInvoice
|
The purpose of the ProcessInvoice is to transmit an invoice from a supplier to a customer. Indicating that the receiver of the Invoice is to Process the Invoice for payment.
|
ProcessPurchaseOrder
|
The purpose of the Process PurchaseOrder Business Object Document is to transmit a purchase order to a supplier’s order management application.
|
ProcessResourceAllocation
|
The purpose of the ProcessResourceAllocation is to notify a Manufacturing Application of the use of required labor or machine time on a production order making a product. The business environments most likely to require this capability are any type of manufacturing scenario.
This BOD communicates what machine was utilized or which person performed the work and their labor skill class, along with the amount of time worked and at what time this event occurred.
|
ProcessWIPMerge
|
The purpose of the ProcessWIPMerge BOD is to notify a Manufacturing Application of the creation of a single production lot from multiple production lots of a product being made on a production order. The business environment most likely to require this capability is a lot based discrete manufacturing scenario.
This BOD communicates the originating lots, the resulting lot, lot quantities, and the processing step at which this event occurred, along with the time at which this event occurred.
|
ProcessWIPMove
|
The purpose of the ProcessWIPMove is to notify a Manufacturing Application of the progression through the production processing steps or operations of a product being made on a production order. The business environments most likely to require this capability are any type of manufacturing scenario.
This BOD communicates which processing step the product is coming from and which step it is being moved to, along with the quantity moving and the time this event occurred.
This BOD assumes that the applications involved in this business scenario will have already synchronized the production item and its BOM/Routing information.
|
ProcessWIPRecover
|
The purpose of the ProcessWIPRecover is to notify a Manufacturing Application of the creation of usable production materials from material previously considered to be unsuitable for production use. This is most often likely to represent a return to production of scrap material. The business environments most likely to require this capability are any type of manufacturing scenario.
This BOD communicates what is being recovered, the quantity being recovered, and the processing step at which the recovered material is to re-enter the production process, along with the time at which this event occurred.
|
ProcessWIPSplit
|
The purpose of the ProcessWIPSplit is to notify a Manufacturing Application of the creation of multiple production lots from a single production lot of a product being made on a production order. The business environment most likely to require this capability is a lot based discrete manufacturing scenario.
This BOD communicates the originating lot, the resulting lots, their quantities, and the processing step at which this event occurred, along with the time at which this event occurred.
|
ReceiveDeliveryReceipt
|
The ReceiveDeliveryReceipt may be used to update the receiver’s internal receiving and order management business applications to indicate that the requested material has arrived, including any unexpected quantity, condition or other exception discrepancies.
The ReceiveDeliveryReceipt supports receiving at either the line item level and/or the ship unit level. Intermediate transportation/logistics providers or freight forwarding partners can use this document to acknowledge the receipt of entire shipping units without detailing the corresponding contents.
|
ReceiveInventoryMovement
|
The purpose of the ReceiveInventoryMovement is to give the organization the ability to do a quantity movement of materials from one organizational unit to another organizational unit.
|
ReceiveProductionOrder
|
The environment for this BOD can be within the enterprise or outside the enterprise. The purpose of the ReceiveProductionOrder is to supply information which the ERP system requires to do receipt posting against a Production Order.
|
ReceivePurchaseOrder
|
The purpose of the Receive PurchaseOrder is to supply the information that a business application module requires to do receipt posting to against a Purchase Order. There are several possible business applications in several environments that may use this capability.
This BOD may be used individually, or as part of a larger interface scenario.
|
RespondQuote
|
The purpose of the RespondQuote is to communicate from one business application to one or more other business applications that a additional data related to a quote has been added or needs to be added, depending on the business case.
|
RespondRequestForQuote
|
The purpose of the RespondRequestForQuote is to communicate from one business application to one or more other business applications that additional data related to a Request for Quote is available.
|
ShowBillOfMaterial
|
The purpose of the ShowBillOfMaterial is to supply Item Bill of Material information to another business application module. This BOD may also be initiated by the sending system upon some event occurring.
There are many possible business applications in several environments that may use this capability. For example, an MRP, Inventory, or Manufacturing business application could use this to communicate Item Bill of Material information.
|
ShowConsumption
|
The most common use of the ShowConsumption is to share a buyer's usage information about an item or product with the supplier of such item or product. This BOD will not create or update either buyer's or supplier's inventory records. The receiver of the request is responsible to make effective use of this information.
The BOD can be used in the following ways:
(1) for a buyer of goods to inform the supplier that goods have been consumed, and replenishment will likely be required;
(2) for a retailer to inform the vendor that retail sales of goods have been made; and
(3) for plant data collection systems and warehouse management systems to inform inventory systems that goods have been consumed and inventory records should be adjusted accordingly.
This is an outline of the business flow that this BOD supports:
(1) Overall purchase, replenishment or vendor managed inventory agreement is in place.
(2) Message is sent to supplier, distributor or third party logistics provider, that material has been consumed. This is done in response to events such as these, depending on implementation context:
· Material is replenished to line side at manufacturing facitliy.
· Material is assembled into final product.
· Material is purchased and removed from facility by customer.
(3) Supplier, distributor, third party logistics provider replenishes material, using information provided in the ShowConsumption message, the demand and shipment forecasts, and the terms of the overall purchase or vendor managed inventory agreement.
|
ShowCredit
|
The purpose of the ShowCredit is to provide credit information concerning a trading partner. The ShowCredit is the reply required by the GetCredit BOD. This BOD type may also be used as an information mechanism that is triggered by a business event and not a GET request.
|
ShowDeliveryReceipt
|
The ShowDeliveryReceipt may be used to obtain information about a specific expected (unreceived) or previously received goods delivery. The ShowDeliveryReceipt may be issued in response to a GetDeliveryReceipt request, or emitted asynchronously for notification upon some business event.
For expected deliveries, the ShowDeliveryReceipt document content may act as a receiving template or checklist to identify the quantity and shipping configuration of the expected goods. In this manner the ShowDeliveryReceipt may be considered logically equivalent to the Advance Ship Notice information in a ShowShipment document. This similarity is by design, as the receiver’s ShowDeliveryReceipt may be directly derived from shipper’s ShowShipment content after the receiver’s business logic has appropriately validated the Advance Ship Notification information.
The ShowDeliveryReceipt supports describing shipment content at either the line item level and/or the ship unit level. Intermediate transportation/logistics providers or freight forwarding partners can use this document to acknowledge the receipt of entire shipping units without detailing the corresponding contents.
|
ShowDispatchList
|
The purpose of the ShowDispatchList is to communicate to a business application module or system the sending systems representation of dispatch list (finite schedule) information. This request may be used as a response to a GetDispatchList request or as a push notification of an event.
|
ShowElectronicCatalog
|
The purpose of the ShowElectronicCatalog is to supply a business application module or system with requested catalog information.
In communicating Catalog information, the ShowElectronicCatalogmay cause other information to be coordinated including, but not limited to
· Item Identifiers
· Specifications
· Pricing Information agreed on either
· Purchase Agreements
· Price Lists
· Availability and Delivery Information
· Related Items and accessories
There are many possible business applications in several environments that may use this capability. Some examples of usage scenarios are:
· Manufacturer exchanging catalogs with distributors/ suppliers/ e-marketplaces
· Distributors/ Suppliers/ e-marketplaces exchanging catalogs with Buyers or other trading partners
It may also be necessary to support Component Supplier Management (CSM) scenarios. In this scenario a company will provide a service of sourcing and codifying the products of many companies and publishing a consolidated catalog.
|
ShowEngineeringChangeDocument
|
The purpose of the ShowEngineeringChangeDocument is to communicate to a business application module or system the sending systems representation of a specified Engineering Change Order. This request may be used as a response to a Get request or as a push notification of an event.
This BOD may be necessary to address the Make to Order, Assemble to Order, or Mixed Mode business ordering scenarios in a Order Management to Manufacturing application integration scenario.
There are many possible business applications in several environments that may use this capability. For example, a PDM, MRP, Inventory, or Manufacturing business application could use this to communicate the requirement to synchronize a Engineering Change Document.
|
ShowInventoryCount
|
The purpose of the ShowInventoryCount is to response to the Get request an occurrences of a Inventory Count information from an ERP system. This count may be a cycle count or a physical count. This BOD may also apply to planned or unplanned inventory counts.
|
ShowInventoryIssue
|
The purpose of the ShowInventoryIssue is to supply inventory issue information against an order, from an ERP system into a PDC system to confirm the InventoryIssue transaction (BOD).
|
ShowInvoice
|
The purpose of the ShowInvoice is to transmit an invoice from a supplier to a customer. This BOD may be used as a response to a GetInvoice request or as a push notification of an event
|
ShowItemCrossReference
|
The purpose of the ShowItemCrossReference is to supply a business application module or system with information concerning an Item cross-reference. Cross-references may be to other item identifiers to the same form fit and function, as well as references to item identifiers of other items (form fit and function). In this document item relationships is used to refer to where the “to item” identifier, identifies a different form, fit and function to the “from item” identifier. It should be noted that the item identifier that is “Primary” in one system may be a secondary identifier in another system.
For example, in the Application Integration space, the manufacturing system may regard the “item Number” as the primary identifier. The Order Management System may regard the Catalog number as the primary identifier. A company that manufacture hand held multi-meters may identify a given item in manufacturing with a 12 digit numeric code, 5432 123 12345. The marketing and sales department may refer to the same item by it’s catalog number of FL 30/4.
In the Business to Business case a supplier of hand held multi-meters may market their products through a catalog provider. The supplier has an item identifier with a corresponding party specific cross reference to the catalog providers identifier for the same item. The catalog provider has a item identifier for hand held multi-meters and a corresponding party specific cross reference to the suppliers item number.
This BOD may be necessary to address Manufacturers, Distributor Resellers business ordering scenarios in a Order Management to Manufacturing application integration scenario. It may also be necessary to address Component Supplier Management scenarios.
There are many possible business applications in several environments that may use this capability. For example, a PDM, MRP, Inventory, or Manufacturing business application could use this to communicate the requirement to synchronize an Item cross-reference. Item cross references may be specific to a given party. Examples may include, (but are not limited to):
· Customers
· Suppliers
· Manufacturers
· Carriers
· Standards Associations
Party specific Cross References include:
· Customer Part Number
· Supplier Part Number
· Manufacturers Part Number
Cross Reference types may also be universal. Universal item cross reference types may include, (but are not limited to)
· Universal Packaging Code (UPC)
· European Article Number (EAN)
· Harmonized Schedule B number
· GTIN Number
· ISBN Number for Books
The BOD may be used to relate item identifiers for item identifiers that identify different items (form fit and function). The Relationship types may also be universal. Universal item relationship types may include, (but are not limited to)
· Accessories
· Spares
· Consumables
An example of this in a business to business context might be a customer letting a supplier know the valid substitutes that a supplier may supply to fulfill an order for a specific item number. An example of this in a application integration context might be between a Product Data Management (PDM) system and an Order Management system for accessories that may be offered to a customer with the sales of a major item. For example, if a designers of a video camera, have designed it to work with the following accessories;
· tripod,
· extended life battery pack
· external microphone
· Head Cleaner
The video camera may be designed to have the following spares replaced by the consumer
· Lens Cover
· Strap
· Handle
The video camera may need the following consumable items on a recurring basis
· Video Cassettes
· Batteries
· Lens Cleaners
the relationship between these items and the video camera may need to represented to the Customer in Web Based ordering or Customer Service Rep (CSR), in desk based order entry.
|
ShowItemMaster
|
The purpose of the ShowItemMaster is to supply ITEM Information to another business application module. This request may be used as a response to a GetItemMaster request or as the result of some other business event. This BOD does not usually cause updates to occur.
There are many possible business applications in several environments that may use this capability. For example, an MRP, Inventory, or Manufacturing business application could use this to request item information.
|
ShowLedgerActual
|
The purpose of the ShowLedgerActual is to communicate to an enterprise application the sending systems representation of ledger information specifically requested. This may be in response to a GetLedgerActual request or to proactively publish a listing of ledger information for a business event.
|
ShowMaintenanceOrder
|
The purpose of the ShowMaintenanceOrder is to communicate to a business application module or system the sending systems representation of maintenance order information. This request may be used as a response to a GetMaintenanceOrder request or as a push notification of an event.
|
ShowMatchDocument
|
In certain application suites, purchase order / invoice matching functionality exists in the purchasing application, while in other suites this functionality exists in the accounts payable application.
The invoice matching process may include several document types, including the following:
Two way match - Purchase Order and the Invoice
Three way match - Purchase Order, Invoice, and the Receipt
Four way match - Purchase Order, Invoice, Receipt, and Inspection results
For the four way match, it is assumed that inspection results have been updated on the Purchase Order for visibility in matching.
When matching takes place in the purchasing application, the accounts payable application may have to inform the purchasing application of the supplier invoice to which purchasing transactions (purchase orders, goods receiving notes and inspection tickets) are to be matched if the invoice is initially entered into the accounts payable application. Note that in some situations, invoices are entered directly into the purchase order application or are created by the purchase order application when using evaluated receipt settlement (ERS) and in this instance, it is not necessary to perform the separate integration described in these chapters.
When matching takes place in the accounts payable application, the purchasing application must inform the accounts payable application of the purchasing transactions (purchase orders, goods receiving notes and inspection tickets) to which the invoice (in accounts payable) is to be matched.
These integration scenarios have been developed for document matching to occur at the line level within the PurchaseOrder document and the Invoice document. This may be a one to one relationship, or it may be a many to one relationship from Invoice to PurchaseOrder or from the PurchaseOrder to the Invoice. Charges not associated with a specific Invoice line match be matched individually.
The purpose of the ShowMatchDocument is to enable the accounts payable application and the purchasing application to exchange information required either by request or initiated by some business event.
|
ShowPersonnel
|
The purpose of the ShowPersonnel is to provide Personnel data for a worker to a requesting business application. This BOD may be in response to a GetPersonnel request, or it may be triggered by a business event.
|
ShowPickList
|
The purpose of the ShowPickList is to show the details of an individual Picking List from an ERP system. This BOD may be sent in response to a GetPickList or it may be initiated upon some business event.
|
ShowPlanningSchedule
|
Since collaboration between a customer and a supplier can potentially go through several rounds of negotiations, both parties can use the same BOD to communicate their current demand or supply schedule in response to what they received from the other party. Either party can indicate detailed exception descriptions along with reason code and action code to the other party why the original demand/supply requirements need to be adjusted using the optional Data Type PlanningScheduleException.
Customers can use this PlanningSchedule to communicate demand requirement in three different ways. It can be as specific as the Item level or at the Commodity code level, which is higher than item. Furthermore, it can be required simply by functional specification via feature identifiers and values using the optional component FeatureValues.
The purpose of the ShowPlanningSchedule is to communicate to a business application module or system the sending systems representation of PlanningSchedule information. This request may be used as a response to a GetPlanningSchedule request or as a push notification of an event.
|
ShowPriceList
|
The purpose of the ShowPriceList is to supply a business application module or system with information concerning new or existing product price lists.
This BOD may be necessary to address the Make to Order, Assemble to Order, or Mixed Mode business ordering scenarios in a Order Management to Manufacturing application integration scenario.
There are many possible business applications in several environments that may use this capability. For example, a Manufacturing, distributor or reseller business application could use this to communicate the price change or request a price list.
It may also be necessary to support Component Supplier Management (CSM) scenarios. In this scenario a company will provide a service of sourcing and codifying the products of many companies and publishing a consolidated catalog. A customer purchases the product from the Catalog provider. They have the capability to do comparison shopping from the catalog. Supplier Certification may be provided by the Catalog provider.
This definition of price list is intended to support simple pricing scenario, especially pricing that may accompany a published price list. It is not intended to support complex pricing environments that may be needed to support features such as;
· Deals and Promotions
· Coupons and Sales Incentives
· Rebates and Accruals
This functionality will be addressed in a subsequent release. It is a working assumption that the representation of complex qualifications, coupons and sales incentives are rarely communicated between systems.
|
ShowProductAvailability
|
The purpose of the ShowProductAvailability is to respond to a GetProductAvailability request or to initiate the passing of product availability data from a Production or Available to Promise (ATP) business application to an Order Management business application.
The business process scenario is the Order Management application interacting with the Available to Promise or Production application in order to determine availability of a product for the customer.
This scenario is commonly referred to as Make to Order or Build to Order.
|
ShowProductionOrder
|
The purpose of the ShowProductionOrder is to supply Production Order information to another business application module.
|
ShowPurchaseOrder
|
The purpose of the Show PurchaseOrder is to supply Purchase Order Information to another business application module. This request may be used as a response to a Get PurchaseOrder request or as a push notification of an event.
There are many possible business applications in several environments that may use this capability. Examples include:
1. A Order Management application could use this BOD to send information to a Plant Data Collection application.
2. An MRP, Inventory or Manufacturing business application could use this to obtain order information.
3. The Order Management application can notify the MRP/Inventory application when a vendor gives or changes a promise day.
|
ShowQuote
|
The purpose of the ShowQuote is to communicate to a business application module or system the sending systems representation of Quote information. This request may be used as a response to a GetQuote request.
|
ShowRequestForQuote
|
The purpose of the ShowRequestForQuote is to communicate to a business application module or system the sending systems representation of Request for Quote information. This request may be used as a response to a GetRequestForQuote request.
|
ShowRequisition
|
The purpose of the ShowRequisition is to send information relative to demand for goods or services to another business application. This may be in response to a GetRequisition request, or it may be a notification vehicle, initiated upon an event in a business application.
|
ShowRouting
|
The purpose of the ShowRouting is to communicate to a business application module or system the relevant information about a specific Routing. The Show Routing is in response to a GetRouting request.
|
ShowSalesOrder
|
The purpose of the Show SalesOrder is to supply Sales Order Information to another business application module. This request may be used as a response to a Get Salesorder request or as a push notification of an event. This BOD does not usually cause updates to occur.
|
ShowSequenceSchedule
|
Commonly, the sequence schedule is generated by a work in process application and transmitted to an order or material planning application.
The purpose of the ShowSequenceSchedule is to communicate to a business application module or system the sending systems representation of SequenceSchedule information. This request may be used as a response to a GetSequenceSchedule request or as a push notification of an event.
|
ShowShipment
|
A Shipment is a business document that details the intent to transport a specific quantity of material goods from a supplier to a single customer business partner destination. The Shipment has been modeled after similar proprietary documents on popular business software packages (SAP's Delivery Note, Oracle Applications' Delivery document, etc.)
A Shipment is typically derived from the shipping schedule associated with a customer's purchase or sales order, once overall demand and various other business factors which prioritize the availability of the supplier's goods inventory have been evaluated.
The Shipment document is designed to have a dynamic structure and content. Initial shipment planning information can be updated and significant detail (actual picked inventory attributes, ship unit packaging, etc.) may be added during the execution phase of the supplier's order fulfillment and shipping business processes.
The final form of the Shipment document can provide detail about the carrier and level of service used to transport the material, the exact quantity and attributes of the material shipped, and how that material is physically packaged and identified for transport.
To aid the customer's planning and receiving business processes, the supplier may transmit the final Shipment document to customer in advance so that they can prepare for carrier arrival and then efficiently accept and utilize the ordered material. In this use case, the Shipment document may function as a traditional Advance Ship Notice (ASN).
A ShipUnit is a data element that identifies and describes a specific collection of goods inventory that is packaged by a supplier for carrier transportation to a customer business partner destination.
A ShipUnit is generally the smallest "thing" that can be individually moved and tracked throughout a carrier's transportation network. The physical size, inventory, content and internal nested container complexity within a ShipUnit is arbitrary. The ShipUnit component was specifically designed to be transportation mode independent. It may be used to represent any uniquely identifiable and trackable assembly, container or vessel including, but not limited to: a parcel express package; a pallet of identical or mixed items; a truck trailer, rail car or an ocean cargo container.
This BOD does not usually cause updates to occur.
Shipment Characteristics
A Shipment document does not necessarily have a one-to-one relationship with any customer purchase/sales order document, line item or line item schedule. For shipping efficiency, a Shipment document may consolidate inventory shipment requests from a variety of different orders that have the same ultimate physical destination. In fact, there may be no customer sale at all, as when the supplier is simply transferring inventory from one warehouse site to another within their enterprise to maintain optimum stocking levels.
A Shipment typically involves a minimum of three business partner entities: Supplier, Carrier, and Customer in the most common business transaction scenario. However these partner titles are more useful as descriptions of the basic roles in the Shipment process. The actual number and relationship of the potential business partners/parties involved in the transaction is intended to be flexible in usage to accommodate agents working on behalf of partners and unique or complex scenarios.
The ShipUnit component identify and describe the physical shipping container(s) and internal packaging structure of the delivered goods. ShipUnit component are typically constructed to describe the result of an inventory picking and packing operation.
The ShipUnit structure complements the line-item oriented summary information provided in the Shipment's ShipItem and InventoryDetail component with detailed information to accurately describe complex shipping unit assemblies and item packaging. This robust level of detail is often demanded by customers to improve the efficiency of their receiving operations. If the supplier provides trustworthy ship unit packaging information in advance, the customer does not have to spend valuable receiving personnel time breaking down the containers to inspect and tally each inventory item.
The general industry trend toward smaller just-in-time deliveries of only the required amount of goods, customer-imposed packaging configurations and requirements, and suppliers performing value-added light assembly customization at the time of shipment is driving the need for more detailed information about the product as it is actually delivered.
|
ShowShipmentSchedule
|
Commonly, the ship schedule is generated by a material planning application and transmitted to an order or material planning application.
The purpose of the ShowShipmentSchedule is to communicate to a business application module or system the sending systems representation of ShipmentSchedule information. This request may be used as a response to a GetShipmentSchedule request or as a push notification of an event.
|
ShowUnitOfMeasureGroup
|
The purpose of the ShowUnitOfMeasureGroup is to supply Unit-of-Measure Group relationship information to another business application module. This request may be issued as a response to a GetUnitOfMeasureGroup request or as the result of some other business event.
There are many possible business applications in several environments that may use this capability. For example, an MRP, Inventory, or Manufacturing business application could use this to request alternate UOM information for one or more items.
|
ShowWIPConfirm
|
The purpose of the ShowWIPConfirm is to respond to a request for the data necessary to perform a confirmation of the movement of WIP (Work in Progress).
|
ShowWIPStatus
|
The purpose of the ShowWIPStatus is to notify a Manufacturing Application of the progress of a production order at a point in time. The business environments most likely to require this capability are any type of manufacturing scenario where BODs for individual manufacturing transactions and events are not utilized.
This BOD communicates what quantities of end product reside at which processing steps along with the time this snapshot view was taken.
|
SyncBillOfMaterial
|
The purpose of the SynBillOfMaterial is to communicate to a business application module or system the need to initiate the creation of a Bill of Material structure.
This BOD may be necessary to address the Make to Order, Assemble to Order, or Mixed Mode business ordering scenarios in a Order Management to Manufacturing application integration scenario.
There are many possible business applications in several environments that may use this capability. For example, an MRP, Inventory, or Manufacturing business application could use this to communicate the requirement to synchronize a Bill of Material.
|
SyncChartOfAccounts
|
The purpose of the SyncChartOfAccounts is to distribute general ledger chart of accounts code identifiers to other applications to store for validation purposes.
|
SyncDispatchList
|
The purpose of the SyncDispatchList is to synchronize dispatch list (finite schedule) information.
|
SyncEmployeeWorkSchedule
|
The purpose of the SyncEmployeeWorkSchedule is to enable the synchronization of Employee Work Schedule data that exists on separate data bases. The SyncEmployeeWorkSchedule allows the adding of new Employee Work Schedules as well as the modification of previously established Employee Work Schedules.
|
SyncEngineeringChangeDocument
|
The purpose of the SyncEngineeringChangeDocument is to communicate to a business application module or system the need to initiate the creation of an Engineering Change Document.
This BOD may be necessary to address the Make to Order, Assemble to Order, or Mixed Mode business ordering scenarios in a Order Management to Manufacturing application integration scenario.
There are many possible business applications in several environments that may use this capability. For example, a PDM, MRP, Inventory, or Manufacturing business application could use this to communicate the requirement to synchronize a Engineering Change Document.
|
SyncExchangeRate
|
The purpose of the SyncExchangeRate is to enable the passing of updates of currency exchange rates to other applications that have exchange rate tables.
|
SyncField
|
The purpose of the SyncField is to enable the validation of data that exists on separate application’s data bases. This BOD can cause on-line validation to occur or may be a single tool for synchronizing data.
|
SyncInventoryBalance
|
The purpose of the SyncInventoryBalance is to enable the synchronization of InventoryBalance data that exists on separate Item Master databases. This data is not the master data that describes the attributes of the item such as dimensions, weight, or unit of measure.
This is data that describes the ITEM as it exists at a specific location.
The primary focus of this BOD is to synchronize the quantity of an item by stocking location.
|
SyncInvoice
|
The purpose of the SyncInvoice is to transmit an invoice from a supplier to a customer. This information is passed in order to keep the customer updated on the number of Invoices they have.
|
SyncItemCrossReference
|
The purpose of the SyncItemCrossReference is to communicate to a business application module or system the need to synchronize an Item cross-reference. Cross-references may be to other item identifiers to the same form fit and function, as well as references to item identifiers of other items (form fit and function). In this document item relationships is used to refer to where the “to item” identifier, identifies a different form, fit and function to the “from item” identifier. It should be noted that the item identifier that is “Primary” in one system may be a secondary identifier in another system.
For example, in the Application Integration space, the manufacturing system may regard the “item Number” as the primary identifier. The Order Management System may regard the Catalog number as the primary identifier. A company that manufacture hand held multi-meters may identify a given item in manufacturing with a 12 digit numeric code, 5432 123 12345. The marketing and sales department may refer to the same item by it’s catalog number of FL 30/4.
In the Business to Business case a supplier of hand held multi-meters may market their products through a catalog provider. The supplier has an item identifier with a corresponding party specific cross reference to the catalog providers identifier for the same item. The catalog provider has a item identifier for hand held multi-meters and a corresponding party specific cross reference to the suppliers item number.
This BOD may be necessary to address Manufacturers, Distributor Resellers business ordering scenarios in a Order Management to Manufacturing application integration scenario. It may also be necessary to address Component Supplier Management scenarios.
There are many possible business applications in several environments that may use this capability. For example, a PDM, MRP, Inventory, or Manufacturing business application could use this to communicate the requirement to synchronize an Item cross-reference. Item cross-references may be specific to a given party. Examples may include, (but are not limited to):
· Customers
· Suppliers
· Manufacturers
· Carriers
· Standards Associations
Party specific Cross References include:
· Customer Part Number
· Supplier Part Number
· Manufacturers Part Number
Cross-reference types may also be universal. Universal item cross-reference types may include, (but are not limited to)
· Universal Packaging Code (UPC)
· European Article Number (EAN)
· Harmonized Schedule B number
· GTIN Number
· ISBN Number for Books
The BOD may be used to relate item identifiers for item identifiers that identify different items (form fit and function). The Relationship types may also be universal. Universal item relationship types may include, (but are not limited to)
· Accessories
· Spares
· Consumables
An example of this in a business to business context might be a customer letting a supplier know the valid substitutes that a supplier may supply to fulfill an order for a specific item number. An example of this in a application integration context might be between a Product Data Management (PDM) system and an Order Management system for accessories that may be offered to a customer with the sales of a major item. For example, if a designers of a video camera, have designed it to work with the following accessories;
· tripod,
· extended life battery pack
· external microphone
· Head Cleaner
The video camera may be designed to have the following spares replaced by the consumer
· Lens Cover
· Strap
· Handle
The video camera may need the following consumable items on a recurring basis
· Video Cassettes
· Batteries
· Lens Cleaners
The relationship between these items and the video camera may need to represented to the Customer in Web Based ordering or Customer Service Rep (CSR), in desk based order entry.
|
SyncItemMaster
|
The purpose of the SyncItemMaster is to supply Item information for goods or services to another business application module. This BOD may also be initiated by the sending system upon some event occurring.
This BOD is not for synchronizing ITEM quantities at each inventory location. The SyncInventoryBalance Business Object Document is used for this purpose.
There are many possible business applications in several environments that may use this capability. For example, a MRP, Inventory, or Manufacturing business application could use this to communicate item information.
This BOD can be used to synchronize items used in finished goods, raw materials, work-in-process or components in a bill of materials.
|
SyncLocation
|
The purpose of the Sync Location is to enable a mechanism to ensure that the physical location identifiers are synchronized between the business applications that require this to communicate clearly. This is particularly critical when only the codes that identify locations are used. Without the meaning of the codes clearly communicated, the integration is not effective. This BOD enables the Location codes to be synchronized among business applications.
This BOD may also be initiated by the sending system upon some event occurring.
There are many possible business applications in several environments that may use this capability. For example, a MRP, Inventory, or Manufacturing business application could use this to communicate Location information.
|
SyncMaintenanceOrder
|
The purpose of the SyncMaintenanceOrder is to ensure that all business software components in a specific integration instance have the current Maintenance Order information. This BOD is commonly used to publish the need to create or update a Maintenance Order in a publish and subscribe integration environment.
One possible scenario is the synchronization of Maintenance Order between field devices, service trucks, etc. with a CMMS system.
|
SyncParty
|
The purpose of the SyncParty is to facilitate keeping party information synchronized that exists on separate data bases. The SyncParty allows the adding of new party and the modification of previously established parties.
|
SyncPersonnel
|
The purpose of the SyncPersonnel is to enable the synchronization of employee data that exists on separate data bases between manufacturing and human resource applications. The SyncPersonnel allows the adding of new employees and their relevant data as well as the modification of previously established employees.
The SyncPersonnel is used to facilitate the maintenance of human resource data in a manufacturing work force planning module. This enables the workforce planning module to use current personnel information when creating finite production schedules. The SyncPersonnel can also be used by a project accounting application or a work order management application to assign qualified personnel or to perform resource planning.
|
SyncPlanningSchedule
|
Since collaboration between a customer and a supplier can potentially go through several rounds of negotiations, both parties can use the same BOD to communicate their current demand or supply schedule in response to what they received from the other party. Either party can indicate detailed exception descriptions along with reason code and action code to the other party why the original demand/supply requirements need to be adjusted using the optional component PlanningScheduleException
.
The purpose of the SyncPlanningSchedule is to communicate requirement information (part number, quantity, etc.) between a customer and their supplier on a regular basis, for example daily, weekly etc, or for a user-defined time bucket type definition (Component FexibileBucket) that is sent as part of this PlanningSchedule.
SyncPlanningSchedule allows the adding of new requirements and the modification of previously established requirements.
Customers can use this PlanningSchedule to communicate demand requirement in three different ways. It can be as specific as the Item level or at the Commodity code level, which is higher than item. Furthermore, it can be required simply by functional specification via feature identifiers and values using the optional component FeatureValue.
|
SyncPriceList
|
The purpose of the SyncPriceList is to communicate to a business application module or system the need to initiate the creation of product price list information as well as update existing price lists.
This BOD may be necessary to address the Make to Order, Assemble to Order, or Mixed Mode business ordering scenarios in a Order Management to Manufacturing application integration scenario.
There are many possible business applications in several environments that may use this capability. For example, a Manufacturing, distributor or reseller business application could use this to communicate the price change or request a price list.
It may also be necessary to support Component Supplier Management (CSM) scenarios. In this scenario a company will provide a service of sourcing and codifying the products of many companies and publishing a consolidated catalog. A customer purchases the product from the Catalog provider. They have the capability to do comparison shopping from the catalog. Supplier Certification may be provided by the Catalog provider.
This definition of price list is intended to support simple pricing scenario, especially pricing that may accompany a published price list. It is not intended to support complex pricing environments that may be needed to support features such as;
· Deals and Promotions
· Coupons and Sales Incentives
· Rebates and Accruals
This functionality will be addressed in a subsequent release. It is a working assumption that the representation of complex qualifications, coupons and sales incentives are rarely communicated between systems.
|
SyncProductionOrder
|
The purpose of the SyncProductionOrder is to ensure that all business software components in a specific integration instance have the current Production Order information. This BOD is commonly used in a publish and subscribe integration environment.
This BOD commonly causes updates to occur.
|
SyncProject
|
The purpose of the SyncProject is to enable all relevant sub-systems that submit transactions to the project accounting application to maintain valid values for the key project fields. The target applications for this update would include, but not necessarily be limited to:
· Accounts Payable
· Accounts Receivable
· Budget
· Order Management
· Purchasing
· Time and Labor
· Travel and Expense
|
SyncPurchaseOrder
|
The purpose of the Sync PurchaseOrder is to facilitate keeping purchase order information synchronized on separate data bases throughout an enterprise. The Sync PurchaseOrder allows the adding of new purchase orders and the modification of previously established purchase orders.
|
SyncQuote
|
The purpose of the SyncQuote is to ensure that all business software components in a specific integration instance have the current Quote information. This BOD is commonly used to publish the need to create or update a Quote in a publish and subscribe integration environment.
|
SyncRequestForQuote
|
The purpose of the SyncRequestForQuote is to ensure that all business software components in a specific integration instance have the current Request for Quote information. This BOD is commonly used to publish the need to create or update a Request for Quote in a publish and subscribe integration environment.
|
SyncRouting
|
The purpose of the SyncRouting is to communicate to a business application component or system the need to create a new Routing or to update an existing Routing structure.
This BOD may be necessary to address the Make to Order, Assemble to Order, and Finished Goods business ordering scenarios in a Logistics to Manufacturing application integration scenario.
|
SyncSalesOrder
|
The purpose of the Sync SalesOrder is to facilitate keeping sales or customer order information synchronized on separate data bases throughout an enterprise. The Sync SalesOrder allows the adding of new sales orders and the modification of previously established sales orders.
This BOD commonly causes updates to occur.
|
SyncSequenceSchedule
|
The purpose of the SyncSequenceSchedule is to enable the exchange of sequence schedule information authorizing a sequenced shipment of parts for specific trading partners and addresses.
Commonly, the sequence schedule is generated by a work in process application and transmitted to an order or material planning application.
|
SyncShipmentSchedule
|
The purpose of the SyncShipmentSchedule is to enable the exchange of shipment schedule information, authorizing a shipment quantity and date for specific trading partners and addresses.
Commonly, the ship schedule is generated by a material planning application and transmitted to an order or material planning application.
|
SyncUnitOfMeasureGroup
|
The purpose of the SyncUnitOfMeasureGroup is to supply a set of Unit-Of-Measure relationships to another business application module.
This BOD addresses the need for applications to exchange item-independent alternative UOM information beyond the stocking UOM. See the Item UOM Integration Scenario for more detailed information.
|
UpdateCredit
|
The purpose of the UpdateCredit is to update the Credit Management functionality within the customer order management or the accounts receivable application. The UpdateCredit will also transmit changes in the accounts receivable open item balances to the credit management function of the customer order management application.
|
UpdateDeliveryReceipt
|
The UpdateDeliveryReceipt may be used to update the receiver’s internal receiving and order management business applications to indicate that the requested material has arrived, including any unexpected quantity, condition or other exception discrepancies.
There are many other possible business applications in several environments that may use this capability. For example:
1. A Purchasing application may use this BOD to notify an Accounts Payable application of a specific delivery. This will enable the Accounts Payable application to accurately calculate the amount it needs to pay a business partner.
2. A Purchasing application could use this to notify a MRP, Inventory, or Manufacturing business application that a delivery has occurred and the goods are available for use or inspection, etc.
3. An MRP/Inventory system could use this BSR to communicate changes on a physical receipt in inventory to the Purchasing system.
The UpdateDeliveryReceipt supports receipts at either the line item level and/or the ship unit level. Intermediate transportation/logistics providers or freight forwarding partners can use this document to acknowledge the receipt of entire shipping units without detailing the corresponding contents.
|
UpdateDispatchList
|
The purpose of the UpdateDispatchList is to synchronize dispatch list (finite schedule) information.
|
UpdateEmployeeTime
|
The purpose of the UpdateEmployeeTime is to update work time information for an employee from a data collection application to an ERP Human Resource application.
|
UpdateInspection
|
The purpose of the UpdateInspection is to supply Inspection information for goods or services to another business application module. This BOD may is initiated by the sending system upon some event occurring. There are many possible business applications in several environments that may use this capability.
For example;
1. A PurchaseOrder application could use this to send information to a Plant Data Collection application, or vice versa.
2. An MRP, Inventory, Purchasing or Manufacturing business application could use this to communicate inspection information.
3. A Laboratory Information System could send quality information to an Inventory application,
4. A Quality Control application could send information to an MRP, Inventory, or Purchasing application.
|
UpdateInventoryBalance
|
The purpose of the ChangeInventoryBalance is to enable the communication of a Change in the InventoryBalance data that exists on separate Inventory databases.
This data is not the master data that describes the attributes of the item such as dimensions, weight, or unit of measure.
This is data that describes the ITEM as it exists at a specific location. It is
|
UpdateInventoryCount
|
The purpose of the UpdateInventoryCount is to transmit an inventory count to ERP from the actual physical inventory location. This count may be a cycle count or a physical count. This BOD may also apply to planned or unplanned inventory counts.
|
UpdateMaintenanceOrder
|
The purpose of the UpdateMaintenanceOrder is to publish to a business application component or system the need to create or update a Maintenance Order.
One possible scenario is the synchronization of Maintenance Order between field devices, service trucks, etc. with a CMMS system.
|
UpdateMatchDocument
|
In certain application suites, purchase order / invoice matching functionality exists in the purchasing application, while in other suites this functionality exists in the accounts payable application.
The invoice matching process may include several document types, including the following:
Two way match - Purchase Order and the Invoice
Three way match - Purchase Order, Invoice, and the Receipt
Four way match - Purchase Order, Invoice, Receipt, and Inspection results
For the four way match, it is assumed that inspection results have been updated on the Purchase Order for visibility in matching.
When matching takes place in the purchasing application, the accounts payable application may have to inform the purchasing application of the supplier invoice to which purchasing transactions (purchase orders, goods receiving notes and inspection tickets) are to be matched if the invoice is initially entered into the accounts payable application. Note that in some situations, invoices are entered directly into the purchase order application or are created by the purchase order application when using evaluated receipt settlement (ERS) and in this instance, it is not necessary to perform the separate integration described in these chapters.
When matching takes place in the accounts payable application, the purchasing application must inform the accounts payable application of the purchasing transactions (purchase orders, goods receiving notes and inspection tickets) to which the invoice (in accounts payable) is to be matched.
These integration scenarios have been developed for document matching to occur at the line level within the PuchaseOrder document and the Invoice document. This may be a one to one relationship, or it may be a many to one relationship from Invoice to PuchaseOrder or from the PuchaseOrder to the Invoice. Charges not associated with a specific Invoice line match be matched individually.
The LoadMatchDocument is for use both by the accounts payable application and the purchasing application in exchanging the transactions that are required to be matched.
The purpose of UpdateMatchDocument is for the accounts payable application to send successful matching notification or a match fail.notification to a purchasing application.
|
UpdateMatchFailure
|
In certain application suites, purchase order / invoice matching functionality exists in the purchasing application, while in other suites this functionality exists in the accounts payable application.
The invoice matching process may include several document types, including the following:
· Two way match - Purchase Order and the Invoice
· Three way match - Purchase Order, Invoice, and the Receipt
· Four way match – Purchase Order, Invoice, Receipt, and Inspection results
Note: For the four way match, it is assumed that inspection results have been updated on the Purchase Order for visibility in matching.
When matching takes place in the purchasing application, the accounts payable application may have to inform the purchasing application of the supplier invoice to which purchasing transactions (purchase orders, goods receiving notes and inspection tickets) are to be matched if the invoice is initially entered into the accounts payable application. Note that in some situations, invoices are entered directly into the purchase order application or are created by the purchase order application when using evaluated receipt settlement (ERS) and in this instance, it is not necessary to perform the separate integration described in these chapters.
When matching takes place in the accounts payable application, the purchasing application must inform the accounts payable application of the purchasing transactions (purchase orders, goods receiving notes and inspection tickets) to which the invoice (in accounts payable) is to be matched.
These integration scenarios have been developed for document matching to occur at the line level within the PO document and the Invoice document. This may be a one to one relationship, or it may be a many to one relationship from Invoice to PO or from the PO to the Invoice. Charges not associated with a specific Invoice line match be matched individually.
The purpose of the UpdateMatchFailure is to notify the purchasing application of a matching failure such as a tolerance failure. The UpdateMatchOk is used for the accounts payable application to send successful matching notification to a purchasing application.
The LoadMatchDocument is discussed in another chapter. The LoadMatchDocument is used to keep invoice, purchase order, goods receipt note and inspection ticket information current.
In the model below, invoice matching functionality exists in the accounts payable application, the invoice is entered into accounts payable, and purchasing publishes matching document information to which accounts payable subscribes.
|
UpdatePickList
|
The purpose of the UpdatePickList is to update the details of an individual Picking List from a plant level to an ERP system. This BOD will usually cause updates to occur.
|
UpdateProductRequirement
|
The purpose of the UpdateProductRequirement is to enable a business application such as Order Management to reserve a quantity of goods or services for a specific date and time. The business process scenario is the Order Management application interacting with the Available to Promise or Production application in order to determine availability of a product for the customer.
This scenario is commonly referred to as Make to Order or Build to Order.
The UpdateProductRequirement accomplishes this task in a two step process within this one request:
1. First the receiving business application checks to see if an item is available in sufficient quantity by a specific date and time.
2. The receiving business application then reserves that quantity of inventory for that specific date and time combination if the product is available.
If the product requested is not available,
The responding application may send one of two responses:
1. A ConfirmBOD to confirm the denial of the request.
2. A ShowProductAvailability to communicate an alternative product availability. This may be OrderItem, Date, or Quantity, or a combination of these. This may also be accompanied with a message in the Note field Identifier stating that this is an alternative.
If the product requested is available:
The responding application may send a ConfirmBOD to confirm the execution of the request.
This BOD will likely cause updates to occur.
This BOD may be used individually, or as part of a larger interface scenario. The GetProductAvailability and ShowProductAvailability may be used before an UpdateProductRequirement, but they are not required.
|
UpdateWIPConfirm
|
The purpose of the UpdateWIPConfirm is to confirm receipt of WIP (Work in Process) materials.
|