Managing Hazard Communications

This topic focuses on the processes required for collaborating with Oracle partners to manage hazard communications.

This chapter covers the following topics:

Managing Chemical Hazard Safety Documentation

To provide full compliance with international safety standards, Oracle offers a hazard communications open interface that lets companies use their existing hazard communication solution with the Oracle E-Business Suite. Several Oracle partners specialize in safety document authoring, management, and distribution to provide the tools, configurable business rules, and expertise on the most recent hazardous materials regulations.

Oracle provides the content for items and formulas. Oracle partners re-create the formula, evaluate its contents using sophisticated rules engines, and produce the Material Safety Data Sheet (MSDS) documentation that is:

Oracle helps companies meet safety compliance with "employee right to know" legislation about toxic chemicals in the workplace by ensuring that chemical hazards are properly evaluated, and that information concerning these hazards is transmitted to appropriate employees. Safety documents are included with production batches or any other processes where hazardous material storage and handling documentation is required. Oracle E-Records is used to upload files and send them to a set of defined approvers for an e-signature.

Oracle offers these business solutions to help manage chemical hazard safety documentation:

Understanding Chemical Hazard Regulations

Regulations governing chemical hazard communication are extensive. Hazard communication documentation is required by law in many nations. These requirements are supranational because they transcend governmental boundaries, authorities, and the interests of regulatory bodies.

Widely recognized chemical hazard regulations include:

Hazard communications are typically required by manufacturers in the chemicals, pharmaceutical, pulp and paper, textile, and food and beverage industries.

Producing Compliant Hazardous Material Documentation

Software tools and hazard communication vendor services help author, manage, and distribute safety documents, labels, and other regulated documents. Many of these are required under OSHA, EU Directives, and various regulatory bodies worldwide. This includes the shipment of hazardous materials, information provided to emergency response centers in their evaluation of personal injury resulting from exposure to a hazardous material, proper handling of hazardous material in the workplace, storage and cleanup of hazardous material spills, and audits by regulatory agencies.

Safety documents provide valuable details of material dangers, as well as proper storage, use and handling of a material. The document is prepared in accordance with OSHA Hazard Communications regulations in 29 CFR Part 1910.1200, European regulations in directive 91/155/EC, or Canadian regulations such as WHMIS.

Generating Safety Labels

Another important regulation from the OSHA Hazard Communications Standards (HCS) is the requirement for Employers to ensure that containers of hazardous chemicals have an appropriate warning label.

Much of the data necessary for generating these labels are available from Oracle, such as pertinent ingredients, chemical composition, hazardous materials properties and values. If this data is stored with the regulatory item, then custom reports are written to create the necessary labels. Oracle XML Publisher is one reporting option, although any report writer that can connect to the applications database suffices.

Alternatively, label design and printing facilities are available through partner applications that specialize in hazardous materials management and communication.

Producing New Product Safety Documentation

During the design and development of a new product, several safety-related documents can be required including:

When a formula is created for a new product, essential material safety information is exported to a partner application where these safety-related documents are created and printed.

Customer requirements mandate the limits of certain substances used in the product formulation. OPM Product Development offers tools that can help chemists and formulators reduce uncertainty about the composition of a formula. The Product Development Simulator lets you see the impact of different ingredients on total product output. The full formula explosion is evaluated for contributing substance quantities. You can substitute items, and you can run laboratory batch simulations using actual lots and quality results. In addition, the Optimizer enables you to specify product targets and find the best mix of ingredients based on the formulation entered.

Item Technical Data is used to track chemical composition of items and lots used as ingredients. Item Technical Data enable the Product Development Simulator to evaluate the hazardous material content in a product. A complete formula explosion is performed to examine formula contents at each level. All chemical attributes are reported based on the formula.

Creating and Distributing the Safety Data Sheet

A new safety data sheet is required when a new product is developed that contains hazardous material. A new safety data sheet version is required when hazard information for an existing product changes significantly such as through a new or updated formulation.

When either of these business events occurs in the OPM Product Development application, a workflow triggers to inform the Regulatory Document Manager, or other appropriate individual to generate a new or revised safety data sheet. The business event also exports XML data based on an industry standard safety data sheet Document Type Definition (DTD). The item, chemical information, and formula are available to any application for use as a basis for the new or revised safety data sheet. When an current safety document is available, its distribution is managed by Oracle or one of its partner applications, depending upon the implementation. Ideally, a safety data sheet for each ingredient or product that requires one is stored in the individual application. This safety data sheet becomes available to any business event that requires this safety data information.

Managing Changes to Product Formulations

Whenever a new ingredient is added to or substituted in a formula that contains a hazardous material, the composition of the finished product changes. Perform a formula analysis to evaluate the impact of the product change in the manufacturing process and quality testing. If the product composition changes, then a new or revised safety data sheet must be generated to reflect the new material composition, hazardous material distributors must send updated safety data sheet documentation immediately to material recipients.

Shipping and Transporting Hazardous Materials

Suppliers must send a properly completed safety data sheet at the first shipment of a hazardous material, or with a shipment that follows updating of the safety data sheet with new or significant hazard information.

Safety documents that are stored in the database are attached automatically to sales orders and shipments each time an item is ordered. This is accomplished by defining document attachment rules in Oracle Order Management, or by letting the application find an appropriate safety document that are attached to the shipment document set. An outbound message is sent to the Oracle partner application to determine whether a new or existing safety document must be associated to an order line. When a shipment is created for this item, the appropriate document is attached. Adding the Regulatory Shipping report to the Ship Confirm Document Set ensures that safety data sheets associated with the shipment are printed as a standard part of the Ship Confirm process.

An optional check of the dispatch history for each customer determines whether the customer already received the most recent safety data sheet. This avoids replicate communication of the same information.

Storing, Approving, and Accessing Safety Documentation

Material Safety Data Sheets, Technical Data sheets, Hazard Labels, Internal Plant Instructions, and similar documentation are an integral part of proper material handling processes including storage, production, and shipping of these materials. Oracle uses a 21 CFR Part 11-compliant file approval process that enables the upload of any type of file to the database, and routes it for e-signature approval to a configurable list of reviewers and approvers.

The application captures electronic signatures, enforces file version control, tracks an audit trail of the version history of the file, secures the file based on its status and associates multiple attributes to the file, including associating documents throughout the Oracle E-Business Suite.

Distributing Updated Safety Documentation

Manufacturers and distributors must provide an safety data sheet any time a significant change is made. If a document already exists and an updated document is created, then document distribution must be executed and a dispatch history recorded. This process is managed by a partner application.

Storing and Accessing Current Safety Data Sheets

Requirement: 29 CFR Part 1910.1200(b)(3)(ii) states that "Employers shall maintain any material safety data sheets that are received with incoming shipments of hazardous chemicals, and ensure that they are readily accessible during each workshift to laboratory employees when they are in their work areas."

Oracle provides a document repository for the storage of and rapid access to any documents received. Documents are associated with items, formulas, recipes, and batches, or they be cataloged in the document repository that provides a simple search mechanism for rapid retrieval and inspection.

Displaying Regulatory Items and Properties

The Regulatory Item navigator displays regulatory items with a list of their properties categorized and sorted by safety data sheet section. For example, when hydrochloric acid is defined as a regulatory item, its physical properties include its physical state, color, solubility, molecular weight, and specific gravity. The navigator has categories for volatility, ecological impact factors, and transportation requirements. These properties displayed in an expandable treelike framework. One or more inventory items are associated with a regulatory item to reduce setup time. This is helpful when several products all contain the same hazardous substance.

Processing New and Updated Safety Documentation

Creation or revision of formulas or items in the E-Business Suite database triggers a series of workflow-driven events that manage changes to hazard communication documentation.

Following summarizes the steps and presents an illustration of this process:

Formulas and items reside in the Oracle database.

  1. Changes to formula details such as products, recipe validity rules, and individual ingredient quantities, or changes to regulatory item properties trigger the Document Rebuild Required workflow.

  2. The Document Rebuild Required workflow generates a Regulatory Data Changed Notification for item or formula detail changes.

  3. Acceptance of the workflow notification sends the outbound GR: Document Rebuild Request message through the XML Gateway.

  4. The Oracle partner application receives the message and evaluates whether a new document or document rebuild is required.

  5. If either a new document or a document rebuild is required, then the partner application sends the inbound GR: Regulatory Item Information Request message through the XML Gateway using the Regulatory Item Information Request workflow.

  6. The XML Gateway receives this message and sends the outbound GR: Regulatory Item Information message that includes all necessary item and formula data.

  7. The Oracle partner evaluates the changes and generates any required updates to the documentation.

  8. If document approval is required, then the File Upload API triggers an optional Document Approval workflow.

  9. New or updated documents are uploaded to the Oracle database using the File Upload API.

  10. Approved documents are output as needed from the database. Optionally, they are distributed with shipping documents as described in "Attaching and Printing Regulatory Documents with Shipments." The Dispatch History is updated for each transaction.

This graphic summarizes the previous process:

the picture is described in the document text

Dispatching a Safety Document From an Oracle Partner

An Oracle partner can dispatch a safety document to a customer. This event writes a record to the Dispatch History table. The history is retained as a printable document.

Following summarizes the steps and presents an illustration of this process:

The Oracle partner dispatches a safety document.

  1. The dispatch event sends the GR: Document Dispatch message using the XML Gateway.

  2. New or updated documents are uploaded to the Oracle database using the File Upload API.

  3. The dispatch event is written to the Regulatory Document Dispatch History table where the document is available for viewing on the Dispatch History window.

  4. If document approval is required, then the File Upload API triggers an optional Document Approval workflow.

  5. Approved documents are output as needed from the database. Optionally, they are distributed with shipping documents as described in "Attaching and Printing Regulatory Documents with Shipments." The Dispatch History window is updated for each transaction.

This graphic summarizes the previous process:

the picture is described in the document text

Dispatching a Safety Document Internally

You can dispatch a safety document internally and send a dispatch message using the XML Gateway.

Following summarizes the steps of this process:

A safety document is dispatched internally by Running the Print Regulatory Item concurrent request with Create Dispatch History set to Yes. Manual creation of a record on the Document Dispatch History window.

The dispatch event sends the GR: Document Dispatch History outbound message using the XML Gateway.

Attaching and Printing Safety Documents with Shipments

The request for a safety shipping document print set initiates a series of events that generate and attach appropriate safety documentation to shipments.

Following summarizes the steps of this process:

A sales order is created with a regulatory item.

  1. The sales order is pick released.

  2. Choose Print Doc Set on the Shipping Transactions window. The Regulatory Document Print API is called as part of the document print request to:

    • Determine if a safety document must be attached to each regulatory item shipment line.

    • Print all documents attached to sales orders or shipment lines.

  3. View the Attachments window to display the list of all attached documents.

  4. A record is written to the Document Dispatch History window for each safety document printed.

Setting Up Transaction Types in the XML Gateway

Refer to the Oracle XML Gateway User's Guide for additional information on setting up transaction types.

  1. Define these XML Gateway-related profile options:

    • ECX: Log File Path is the log file path where the XML messages and runtime log are stored.

    • ECX: XSLT File Path is the path where XSLT style sheets are stored.

    • ECX: System Administrator Email Address is the e-mail address for the XML Gateway System Administrator.

    • ECX_OAG_LOGICALID is the sender's information system identifier.

    • ECX: Server Time Zone is the time zone where the database server is operating.

  2. Define the UTL_FILE_DIR Parameter in the INIT.ORA file.

  3. Enter Trading Partner information. Enable the following transaction types for the Trading Partner:

    • Type: GR, Subtype: GRRRO, GR: Document Rebuild Required (Outbound)

    • Type: GR, Subtype: GRIOO, GR: Regulatory Item Ordered (Outbound)

    • Type: GR, Subtype: GRDDO, GR: Document Dispatch History (Outbound)

    • Type: GR, Subtype: GRIIO, GR: Regulatory Item Information (Outbound)

    • Type: GR, Subtype: GRIRI, GR: Regulatory Item Information Request (Inbound)

    • Type: GR, Subtype: GRPCI, GR: Regulatory Property Change (Inbound)

    • Type: GR, Subtype: GRDDI, GR: Document Dispatch (Inbound)

      Refer to "Understanding OPM Hazard Communication XML Messages" for detailed explanations of these transaction types.

  4. Set up these profile options:

    • Set GR: Sales Order Check for Hazards to Yes.

    • Set GR: Document Rebuild Required to Enabled.

    • Set GR: Partner Application Site ID to a value equal to the site used in the Trading Partner setup.

    • Set GR:Soapaction to Yes.

    • Set GR: Ws Service Namespace to Yes.

Understanding OPM Hazard Communication Workflows

This topic introduces you to the concept of a workflow process and refers you to the documentation that fully explains Oracle workflows. It presents an understanding of the OPM Hazard Communication workflows, how to set them up, how to start them, and how to use their windows.

Technical Overview

OPM Hazard Communication workflows use two major components:

Oracle Workflow supports business process definitions to route hazard communications. Each workflow has a rules-based engine that resides in the database. Oracle Workflow routes summary and detail information to each decision maker in the workflow process.

The Oracle Workflow Business Event System defines key business events and associates each of these events to a subscription. The subscription initiates a designated workflow to perform the required database changes, to issue notifications, and to manage the hazard communications process. Events and subscriptions are enabled or disabled as needed using the business event system. You can add a new subscription to an event to perform customized actions.

Understanding Workflow Processes

Oracle Workflow lets you automate and continuously improve business processes by routing information according to a set of business rules. Transmit this information to individuals both inside and outside your enterprise on an individual basis.

Refer to the Oracle Workflow Guide and the Oracle E-Records Implementation Guide for additional information on:

OPM Hazard Communication Workflows

Document Rebuild Required Workflow

The Document Rebuild Required workflow generates the Regulatory Data Changed Notification. If the Notification is accepted, then the workflow generates the GR: Document Rebuild Required XML (Outbound) message.

Regulatory Item Information Request Workflow

The Regulatory Item Information Request Inbound event initiates the Regulatory Item Information Request workflow. If the notification is accepted, then the workflow generates the GR: Regulatory Item Information (Outbound) XML Message.

Partner Application Data Change Workflow

The Partner Application Data Change workflow generates the Partner Application Data Change Notification to notify the Regulatory Document Manager of a data change at the partner application.

Document Approval Workflow

Refer to the Oracle E-Records Implementation Guide for a description of the process to upload external documents using the iSignatures Files Approval.

Setting Up OPM Hazard Communication Workflows

For the proper functioning of the workflows, a few administrative steps must be handled. These include setting up notification contacts for the workflow and starting the workflow engine.

Document Rebuild Required Workflow

The OPM Document Rebuild Required workflow notifies the workflow recipient of the need to rebuild a safety document. The workflow is instantiated by the person who makes a change to an item, formula, technical parameter, or recipe validity rule.

Setting Up the Document Rebuild Required Workflow

Set up the Document Rebuild Required workflow as follows:

  1. Verify that these profile options are set up:

    • Set GR: Sales Order Check for Hazards to Yes.

    • Set GR: Document Rebuild Required to Enabled.

  2. Enable the Hazard Communication Outbound Information event.

  3. Enable the subscription to the event.

  4. Set up AME rules for the event.

Hazard Communication Outbound Information Event

This business event is triggered from a change to a regulatory item property, formula detail, technical parameter, or recipe validity rule.

Event Name

oracle.apps.gr.message.send

Subscriber

Subscriber Workflow:

Hazard Communication Outbound Information

Oracle Approval Management Transaction Name:

Regulatory Document Manager, oracle.apps.gr.reg.documentmanager

Recommended Attributes for Approval Configuration

Parameter Description
ITEM_NO Regulatory Item
ITEM_DESC Regulatory Item Description
FORMULA_NO Formula Number
FORMULA_VERSION Formula Version

Request Notifications

The workflow sends a notification to the contact person, requesting that a document be rebuilt.

The body of the Hazard Communication Outbound Information Notification for a formula or recipe validity rule change follows:

Regulatory Item:      &ITEM_NO


Item Description:     &ITEM_DESC


Formula No:           &FORMULA_NO


Formula Version:      &FORMULA_VERSION

The body of the Hazard Communication Outbound Information Notification for a regulatory item property change follows:

Regulatory Item:      &ITEM_NO


Item Description:     &ITEM_DESC

Partner Application Data Change Workflow

The Partner Application Data Change Workflow notifies the workflow recipient of a data change at the partner application. The workflow is instantiated by the XML Gateway.

Setting Up the Partner Application Data Change Workflow

Set up the Partner Application Data Change Workflow as follows:

  1. Verify that the GR: Partner Application Site ID profile option is set up.

  2. Enable the Regulatory Send Outbound Message event.

  3. Enable the subscription to the event.

  4. Set up AME rules for the event.

Regulatory Property Change Inbound Event

This business event is triggered by the partner application to notify the Regulatory Document Manager that the regulatory data changed at the partner application.

Event Name

oracle.apps.gr.message.send

Subscriber

Subscriber Workflow:

Regulatory Outbound Information

Oracle Approval Management Transaction Name:

Regulatory Document Manager, oracle.apps.gr.reg.documentmanager

Recommended Attributes for Approval Configuration

Parameter Description
ORGN_ID Organization ID
ITEM_NO Regulatory Item
ITEM_NAME Regulatory Item Description
PROPERTY_DETAILS Property Details

Request Notifications

The workflow sends a notification to the contact person stating that the property data or value changed at the partner application.

The body of the Regulatory Outbound Information Notification follows:

Organization ID:          &ORGN_ID


Regulatory Item:          &ITEM_NO


Regulatory Description:   &ITEM_NAME


Property Name:            &PROP_NAME


Current Property Value:   &PROP_VAL


Proposed Property Value:  &PROPSD_PROP_VAL


The following item attributes were sent in by the Partner Application but have no corresponding entry in Oracle Regulatory Management:


Property Name:            &UNMAP_PROP_NAME


Current Property Value:   &UNMAP_PROP_VAL


Proposed Property Value:  &UNMAP_PROPSD_PROP_VAL

Regulatory Item Information Request Workflow

The Regulatory Item Information Request workflow notifies the workflow recipient of a regulatory item information request by the partner application. The workflow is instantiated by the partner application.

Setting Up the Regulatory Item Information Request Workflow

Set up the Regulatory Item Information Request workflow as follows:

  1. Verify that the GR: Partner Application Site ID profile option is set up.

  2. Enable the Regulatory Send Outbound Message event.

  3. Enable the subscription to the event.

  4. Set up AME rules for the event.

Regulatory Item Information Request Inbound Event

This business event is triggered by the partner application to request regulatory item information. This information is sent to the Regulatory Document Manager.

Event Name

oracle.apps.gr.message.send

Subscriber

Subscriber Workflow:

Regulatory Outbound Information

Oracle Approval Management Transaction Name:

Regulatory Document Manager, oracle.apps.gr.reg.documentmanager

Recommended Attributes for Approval Configuration

Parameter Description
ORGN_ID Organization ID
FROM_ITEM From Item
TO_ITEM To Item

Request Notifications

The workflow sends a notification to the contact person requesting regulatory item information for the requested item details. The body of the Regulatory Item Information Request Notification is as follows:

Regulatory Data for the range of items listed below has been requested by the Partner Application:


Organization:  &ORGN_ID


From Item:     &FROM_ITEM


To Item:       &TO_ITEM


Please Note: Accept will generate GR Regulatory Item Information XML Outbound Message. Close will close the notification and end processing.

Understanding OPM Hazard Communication XML Messages

XML messages are enabled through the XML Gateway. These messages allow for the passing of data between the application and an Oracle partner or customer.

The interface point for the partner application is the Oracle Transport Agent as it is used by the XML Gateway. The Oracle Transport Agent manages server validation, message encryption, and the delivery of both inbound and outbound messages.

A message sent from and received by the Oracle E-Business Suite is transported from or to the Oracle Transport Agent through Oracle Advanced Queuing as it is implemented by the XML Gateway. The message is placed into the appropriate queue directly, or it can be placed in a queue through the use of Oracle Workflow.

Oracle Workflow Business Event System

The Oracle XML Gateway uses the Oracle Workflow Business Event System to publish and subscribe to application business events and to trigger message creation or consumption.

Oracle Advanced Queuing Interface

The XML Gateway Execution Engine interfaces with Oracle Advanced Queuing to stage outbound XML messages or receive inbound XML messages for processing.

Oracle Workflow Interface

The XML Gateway Execution Engine interfaces actively with Oracle Workflow to notify the XML Gateway system administrator regarding system or process errors, or the partner contact for data errors.

Oracle Transport Agent Interface

The Oracle Transport Agent interfaces with Oracle Advanced Queuing to deliver outbound messages and to receive inbound messages. The Transport Agent server is a Java-based servlet that uses the Transport Agent Messaging Protocol to support:

OPM Hazard Communication XML Messages

Following are the XML messages generated:

GR: Document Rebuild Required (Outbound) XML Message

This message is sent to the Oracle partner application when a new product is created that contains a regulatory item, or when a regulatory item in a product composition changes. It specifies which product the Oracle partner application must retrieve for safety information evaluation.

Transaction Definition

Following is the transaction definition for the XML message:

Parameter Definition
Party Type Exchange
Transaction Type GR
Transaction Subtype GRRRO
Transaction Description Alert the Oracle partner application that a regulatory document rebuild is required.
Standard Code UNIVERSAL
Direction OUT
External Transaction Type REGDOCREBUILD
External Subtype REQUEST
Queue ECX_OUTBOUND

Data Definition

The data values required for this message are sent from the procedure that determines if a document rebuild is required. An XML Gateway map is created based on the following DTD:

<!-- grgrrrod.dtd -->


<!-- $Header: grgrrrod.dtd 115.1 2005/05/03 15:02:15 kprasad noship $ -->


<!ELEMENT DocumentRebuildRequired (Product+) >


<!-- -->


<!--Identifies the Product/Item -->


<!ELEMENT Product (ProductName,ProductIdentifier,ProductIdentifierType) >


<!ELEMENT ProductName (#PCDATA)>


<!ELEMENT ProductIdentifier (#PCDATA)>


<!ELEMENT ProductIdentifierType (#PCDATA)>

GR: Regulatory Item Ordered (Outbound) XML Message

This message is sent to the Oracle partner application when a new sales order with at least one Regulatory Item is sent for Pick Release. It specifies which sales order the Oracle partner application must retrieve for regulatory information evaluation.

Transaction Definition

Following is the transaction definition for the XML message:

Parameter Definition
Party Type Exchange
Transaction Type GR
Transaction Subtype GRIOO
Transaction Description Alerts the Oracle partner application that a regulatory item appeared on a sales order.
Standard Code UNIVERSAL
Direction OUT
External Transaction Type REGITEMORDERED
External Subtype NOTIFY
Queue ECX_OUTBOUND

Definition

The data values required for this message are sent in the Pick Release function in Oracle Order Management. An XML Gateway map is created based on the following DTD:

<!-- grgriood.dtd -->
<!-- $Header: grgriood.dtd 120.1 2007/12/13 21:18:52 plowe ship $ -->
<!ELEMENT RegulatoryItemOrdered (SalesOrder*) >
<!--Identifies the Sales Order --> 
<!ELEMENT SalesOrder (Organization,Number,CustomerId,CustomerName,OrderLines*)>
<!ELEMENT Organization (#PCDATA)>
<!ELEMENT Number (#PCDATA)>
<!ELEMENT CustomerId (#PCDATA)>
<!ELEMENT CustomerName (#PCDATA)>
<!ELEMENT OrderLines (ProductName,RecipientSiteId,ShipToAddress1,ShipToAddress2)>
<!ELEMENT ProductName (#PCDATA)>
<!ELEMENT RecipientSiteId (#PCDATA)>
<!ELEMENT ShipToAddress1 (#PCDATA)>
<!ELEMENT ShipToAddress2 (#PCDATA)>

GR: Document Dispatch History (Outbound) XML Message

This message is sent to the Oracle partner application when a new Document Dispatch History record is written.

Transaction Definition

Following is the transaction definition for the XML message:

Parameter Definition
Party Type Exchange
Transaction Type GR
Transaction Subtype GRDDO
Transaction Description Alerts the Oracle partner application that a document was dispatched in the Oracle E-Business Suite.
Standard Code UNIVERSAL
Direction OUT
External Transaction Type REGDISPATCHHIST
External Subtype NOTIFY
Queue ECX_OUTBOUND

Data Definition

The data values required for this message are sent. An XML Gateway map is created based on the following DTD:

<!-- grgrddod.dtd -->


<!-- $Header: grgrddod.dtd 115.3 2005/06/07 16:05:53 kprasad noship $ -->


<!ELEMENT DispatchHistory (DispatchRecord+) >


<!--Contains Dispatch Information -->  


<!ELEMENT DispatchRecord ( DocumentName?, DocumentVersion?, 


AssociatedItem, AssociatedCasNum?, RecipientSiteId, RecipientId, DateSent, 


DispatchMethodCode, DocumentCode?, DisclosureCode?, DocumentLanguage?, UserId) >


<!-- -->


<!ELEMENT DocumentName (#PCDATA)>


<!ELEMENT DocumentVersion (#PCDATA)>


<!ELEMENT AssociatedItem (#PCDATA)>


<!ELEMENT AssociatedCasNum (#PCDATA)>


<!ELEMENT RecipientSiteId (#PCDATA)>


<!ELEMENT RecipientId (#PCDATA)>


<!ELEMENT DateSent (#PCDATA)>


<!ELEMENT DispatchMethodCode (#PCDATA)>


<!ELEMENT DocumentCode (#PCDATA)>


<!ELEMENT DisclosureCode (#PCDATA)>


<!ELEMENT DocumentLanguage (#PCDATA)>


<!ELEMENT UserId (#PCDATA)>

GR: Regulatory Item Information (Outbound) XML Message

This message is sent to the Oracle partner application after receiving a request for item information. It contains all pertinent regulatory properties for each item in the requested range.

Transaction Definition

Following is the transaction definition for the XML message:

Parameter Definition
Party Type Exchange
Transaction Type GR
Transaction Subtype GRIIO
Transaction Description Sends regulatory item information to the Oracle partner application.
Standard Code UNIVERSAL
Direction OUT
External Transaction Type REGITEMINFO
External Subtype PROCESS
Queue ECX_OUTBOUND

Data Definition

The data values required for this message are sent. An XML Gateway map is created based on the following DTD:

<!-- $Header: grgriiod.dtd 120.0 2005/06/20 07:01:11 kprasad noship $ -->


<!ELEMENT RegulatoryItemInformation (Organization?, Product*)>


<!--  -->


<!--  -->


<!ENTITY % pressUnit "(atm | bar | in_hg | mm_hg | in_H2O | mm_H2O | psi


| psf | Pa)">


<!ENTITY % volUnit "(cc | in3 | ft3 | m3 | gl | l | ml | cy | oz | bbl |


pt | qt)">


<!ENTITY % massUnit "(lb | oz | US_ton | metric_ton | kg | gm | mg |


stone | gr | ct)">


<!ENTITY % densUnit "(g_per_l | pct | lbs_per_gl | mg_per_ml)">


<!ENTITY % tempUnit "(F | C | K | na)">


<!ENTITY % qualifier "(= | > | < | >= | <=)">


<!ENTITY % miscUnit "(air_is_1.0 | water_is_1.0 | mg_per_l_H2O | other|


pct | cP | na)">


<!ENTITY % severity "(acute | chronic | none)">


<!ENTITY % YesNo "(Yes | No | Unknown)">


<!ENTITY % stateValue "(Liquid | Gas | Solid)">


<!--  -->


<!--  -->


<!ELEMENT Organization (#PCDATA)>


<!ELEMENT Product ( ProductName, ProductDescription?, ProductIdentifier,


ProductIdentifierType,  Ingredient*, RelatedItem*, 


AutoIgnitionTemp1?, AutoIgnitionTemp1Qualifier?, autoIgnitionTemp1Unit?,


BoilingPoint1?, BoilingPoint1Qualifier?, boilingPoint1TemperatureUnit?,


BoilingPoint2?, Color?, DecompositionTemp1?, DecompositionTemp1Qualifier?,


decompositionTemp1Unit?, EvaporationRate1?, evaporationRate1Qualifier?, 


FlashPoint1?, FlashPoint1Qualifier?, flashPoint1MethodUsed?, flashPoint1TempUnit?, FlashPoint2?,


FreezingPoint1?, FreezingPoint1Qualifier?, freezingPoint1Unit,


HazardousPolymerization?, LowerFlameLimit?, UpperFlameLimit?, ConsumerUse?,


TradeSecretNumber?, Carcengenicity?, ImmiscibleInWater?,


MeltingPoint1?,


meltingPoint1TempUnit?, MoistureAbsorbing?, SolubilityInEthanol?, SolubilityInFats?,


SolubilityInGlycerol?,  OtherSolubility?, SolubilityInWater?, MolecularWeight?,


Mutagenicity?, Odor?, pH1?, pH2?, SkinIrritant?, SpecificGravity1?, VaporPressure1?,


VaporPressure1Temp?, vaporPressure1TempUnit?, VaporDensity?,  vaporDensityUnit?,


VolatileOrganicContentPercent?, VolatileWeight?, volatileVolume?, StrongOxidizer?,


TradeSecretExpireDate?,


TradeSecretRegistration?, UNNumber?, classificationType?, UnSubsidiaryRisk?,


TransportRegulationPackingGroup?, 


EmergencyRespNumber?, 


EmergencyStorageCode?, KemmlerNo?, IMDGClass?, MarinePollutant?, ADRRIDNumber?,


ADRItemCode?, ADNRWaterway?, 


HazchemCode?, ChemtrecNumber?, CANUTECNumber?, EPARegistrationNumber?, SupplierNumber?,


SupplierRevisionDate?, 


SupplierDatePrepared?, ProductUse?, OtherPhysicalAndChemicalProperty*)>


<!--  -->


<!ELEMENT ProductName (#PCDATA)>


<!ELEMENT ProductIdentifier (#PCDATA)>


<!ELEMENT ProductIdentifierType (#PCDATA)>


<!ELEMENT ProductUse (#PCDATA)>


<!ELEMENT ProductDescription (#PCDATA)>


<!ELEMENT ConsumerUse   (#PCDATA)>


<!ELEMENT TradeSecretNumber  (#PCDATA)>


<!ELEMENT Carcengenicity  (#PCDATA)>


<!ELEMENT Ingredient (Code?, Name?, Classification?,ClassificationType?,


Percent1?, Percent1Qualifier?, PercentWeightVolumeIdentifier?)>


<!ELEMENT Code (#PCDATA)>


<!ELEMENT Name (#PCDATA)>


<!ELEMENT Classification (#PCDATA)>


<!ELEMENT ClassificationType (#PCDATA)>


<!ELEMENT Percent1 (#PCDATA)>


<!ELEMENT Percent1Qualifier (#PCDATA)>


<!ELEMENT PercentWeightVolumeIdentifier (#PCDATA)>


<!ELEMENT RelatedItem (Code?, Name?)>


<!--ELEMENT Code  - already defined)-->


<!--ELEMENT Name  - already defined)-->


<!--   -->


<!--   -->


<!ELEMENT AutoIgnitionTemp1 (#PCDATA)>


<!ELEMENT AutoIgnitionTemp1Qualifier (#PCDATA)>


<!ELEMENT autoIgnitionTemp1Unit (#PCDATA)>


<!ELEMENT BoilingPoint1 (#PCDATA)>


<!ELEMENT BoilingPoint1Qualifier (#PCDATA)>


<!ELEMENT boilingPoint1TemperatureUnit (#PCDATA)>


<!ELEMENT BoilingPoint2 (#PCDATA)>


<!ELEMENT freezingPoint1Unit    (#PCDATA)>


<!ELEMENT ImmiscibleInWater     (#PCDATA)>


<!ELEMENT MeltingPoint1         (#PCDATA)>


<!ELEMENT meltingPoint1TempUnit (#PCDATA)>


<!ELEMENT MoistureAbsorbing     (#PCDATA)>


<!ELEMENT Color (#PCDATA)>


<!ELEMENT DecompositionTemp1 (#PCDATA)>


<!ELEMENT DecompositionTemp1Qualifier (#PCDATA)>


<!ELEMENT decompositionTemp1Unit (#PCDATA)>


<!ELEMENT EvaporationRate1 (#PCDATA)>


<!ELEMENT evaporationRate1Qualifier (#PCDATA)>


<!ELEMENT LowerFlameLimit (#PCDATA)>


<!ELEMENT UpperFlameLimit (#PCDATA)>


<!ELEMENT FlashPoint1 (#PCDATA)>


<!ELEMENT FlashPoint1Qualifier (#PCDATA)>


<!ELEMENT flashPoint1MethodUsed (#PCDATA)>


<!ELEMENT flashPoint1TempUnit (#PCDATA)>


<!ELEMENT FlashPoint2 (#PCDATA)>


<!ELEMENT FreezingPoint1 (#PCDATA)>


<!ELEMENT FreezingPoint1Qualifier (#PCDATA)>


<!ELEMENT HazardousPolymerization (#PCDATA)>


<!ELEMENT MolecularWeight (#PCDATA)>


<!ELEMENT Mutagenicity (#PCDATA)>


<!ELEMENT Odor (#PCDATA)>


<!ELEMENT pH1 (#PCDATA)>


<!ELEMENT pH2 (#PCDATA)>


<!ELEMENT SkinIrritant (#PCDATA)>


<!ELEMENT SolubilityInEthanol   (#PCDATA)>


<!ELEMENT SolubilityInFats      (#PCDATA)>


<!ELEMENT SolubilityInGlycerol  (#PCDATA)>


<!ELEMENT OtherSolubility       (#PCDATA)>


<!ELEMENT SolubilityInWater     (#PCDATA)>


<!ELEMENT SpecificGravity1 (#PCDATA)>


<!ELEMENT VaporPressure1 (#PCDATA)>


<!ELEMENT VaporPressure1Temp (#PCDATA)>


<!ELEMENT vaporPressure1TempUnit (#PCDATA)>


<!ELEMENT VaporDensity (#PCDATA)>


<!ELEMENT vaporDensityUnit (#PCDATA)>


<!ELEMENT VolatileOrganicContentPercent (#PCDATA)>


<!ELEMENT VolatileWeight  (#PCDATA)>


<!ELEMENT volatileVolume  (#PCDATA)>


<!ELEMENT StrongOxidizer     (#PCDATA)>


<!ELEMENT TradeSecretExpireDate   (#PCDATA)>


<!ELEMENT TradeSecretRegistration (#PCDATA)>


<!ELEMENT UNNumber   (#PCDATA)>


<!ELEMENT classificationType (#PCDATA)> 


<!ELEMENT UnSubsidiaryRisk     (#PCDATA)>


<!ELEMENT TransportRegulationPackingGroup (#PCDATA)>


<!ELEMENT EmergencyRespNumber  (#PCDATA)>


<!ELEMENT EmergencyStorageCode (#PCDATA)>


<!ELEMENT KemmlerNo            (#PCDATA)>


<!ELEMENT IMDGClass            (#PCDATA)>


<!ELEMENT MarinePollutant      (#PCDATA)>


<!ELEMENT ADRRIDNumber         (#PCDATA)>


<!ELEMENT ADRItemCode          (#PCDATA)>


<!ELEMENT ADNRWaterway         (#PCDATA)>


<!ELEMENT HazchemCode          (#PCDATA)>


<!ELEMENT ChemtrecNumber       (#PCDATA)>


<!ELEMENT CANUTECNumber        (#PCDATA)>


<!ELEMENT EPARegistrationNumber  (#PCDATA)>


<!ELEMENT SupplierNumber         (#PCDATA)>


<!ELEMENT SupplierRevisionDate   (#PCDATA)>


<!ELEMENT SupplierDatePrepared   (#PCDATA)>


<!ELEMENT OtherPhysicalAndChemicalProperty  (OPCPName?, Property*)>


<!ELEMENT OPCPName (#PCDATA)>


<!ELEMENT Property (PropertyName?, PropertyValue?)>


<!ELEMENT PropertyName (#PCDATA)>


<!ELEMENT PropertyValue (#PCDATA)>

GR: Regulatory Item Information Request (Inbound) XML Message

This message is sent to the Oracle E-Business Suite by the Oracle partner application.

Transaction Definition

Following is the transaction definition for the XML message:

Parameter Definition
Party Type Exchange
Transaction Type GR
Transaction Subtype GRIRI
Transaction Description Requests regulatory item information.
Standard Code UNIVERSAL
Direction IN
External Transaction Type REGITEMDATAREQ
External Subtype PROCESS
Queue ECX_INBOUND

Data Definition

The data values required for this message are sent using an XML Gateway map created with a Target Action for the Execute Procedure that references the Export Regulatory Item Data API name as the procedure name. Constant parameters such as the API version used in the call to the API are set using the Assign Variable Value action. Variable parameters for use in the call to the API are mapped using the following DTD:

<!-- grgririd.dtd -->


<!-- $Header: grgririd.dtd 115.2 2005/06/10 14:38:35 kprasad noship $ -->


<!ELEMENT RegulatoryInformationRequest (Request) >


<!ELEMENT  Request (Organization?, FromItemName, ToItemName) >


<!--Identifies the range of items  -->


<!ELEMENT Organization (#PCDATA)>  


<!ELEMENT FromItemName (#PCDATA)>


<!ELEMENT ToItemName (#PCDATA)>

GR: Regulatory Property Change (Inbound) XML Message

This message is sent to the Oracle E-Business Suite by the partner application. Data contained in the message is used by the Partner Application Data Change Workflow to send a Notification to the Regulatory Document Manager to provide changes made to properties in the partner application.

Transaction Definition

Following is the transaction definition for the XML message:

Parameter Definition
Party Type Exchange
Transaction Type GR
Transaction Subtype GRPCI
Transaction Description Details of item property changes made in the partner application.
Standard Code UNIVERSAL
Direction IN
External Transaction Type REGPROPCHANGE
External Subtype PROCESS
Queue ECX_INBOUND

Definition

An XML Gateway map is created based on the following DTD:

<!-- grgrpcid.dtd -->


<!-- $Header: grgrpcid.dtd 115.2 2005/06/10 14:38:51 kprasad noship $ -->


<!ELEMENT RegulatoryPropertyChange (Item+) >


<!--Identifies the item -->  


<!ELEMENT Item (Organization?, Name, Property+) >


<!-- -->


<!ELEMENT Organization (#PCDATA)>


<!ELEMENT Name (#PCDATA)>


<!ELEMENT Property (propertyName, propertyValue)>


<!--Identifies the property --> 


<!ELEMENT propertyName (#PCDATA)>


<!ELEMENT propertyValue (#PCDATA)>

GR: Document Dispatch (Inbound) XML Message

This message is sent to the Oracle E-Business Suite by the partner application. The data contained in the message is used as parameters to call the Document Dispatch API.

Transaction Definition

Following is the transaction definition for the XML message:

Parameter Definition
Party Type Exchange
Transaction Type GR
Transaction Subtype GRDDI
Transaction Description Information pertaining to dispatch of a regulatory document outside the Oracle E-Business Suite.
Standard Code UNIVERSAL
Direction IN
External Transaction Type REGDOCDISPATCH
External Subtype PROCESS
Queue ECX_INBOUND

Data Definition

The data values required for this message are sent from the database trigger on gr_document_dispatch. An XML Gateway map is created based on the following DTD:

<!-- $Header: grgrddid.dtd 115.3 2005/06/23 14:40:03 pbamb noship $ -->


<!ELEMENT DocumentDispatch (Document+) >


<!--Identifies the Document and Dispatch Information -->  


<!ELEMENT Document (Name, Location, Version, Category, DocumentType, FileFormat, FileDescription?, AssociatedItem?, AssociatedCasNum?, RecipientSiteId, RecipientId, DateSent, 


DispatchMethodCode, DocumentCode, DisclosureCode, DocumentLanguage, UserId, OrganizationCode?) >


<!-- -->


<!ELEMENT Name (#PCDATA)>


<!ELEMENT Location (#PCDATA)>


<!ELEMENT Version (#PCDATA)>


<!ELEMENT Category (#PCDATA)>


<!ELEMENT DocumentType (#PCDATA)>


<!ELEMENT FileFormat (#PCDATA)>


<!ELEMENT FileDescription (#PCDATA)>


<!ELEMENT AssociatedItem (#PCDATA)>


<!ELEMENT AssociatedCasNum (#PCDATA)>


<!ELEMENT RecipientSiteId (#PCDATA)>


<!ELEMENT RecipientId (#PCDATA)>


<!ELEMENT DateSent (#PCDATA)>


<!ELEMENT DispatchMethodCode (#PCDATA)>


<!ELEMENT DocumentCode (#PCDATA)>


<!ELEMENT DisclosureCode (#PCDATA)>


<!ELEMENT DocumentLanguage (#PCDATA)>


<!ELEMENT UserId (#PCDATA)>


<!ELEMENT OrganizationCode (#PCDATA)>

Entering the Dispatch History

The Document Dispatch History window displays a list of safety documents sent with regulated items. The history includes the name of the document sent, its recipient, the date sent, and the method used to send the document.

Send a safety document as a fax, e-mail, or attached to a shipment. To record a manually dispatched safety document, enter a dispatched document on this window and save it.

You can use folders with this window.

Prerequisites

To enter a safety dispatch history:

  1. Navigate to the Document Dispatch History window. The Find Dispatch History window displays.

  2. Click New.

  3. Enter Item as the regulated item. Required.

  4. Enter Recipient as the party to whom the document was sent. Required.

  5. Enter Recipient Site Number as the number of the party site listing for the recipient entered in the Human Resources (Process Operations) application. Required.

  6. Select the Document name from the document catalog.

  7. Enter Date Sent as the date that the document was dispatched.

  8. Enter Dispatch Method as the method that was used to dispatch the document. Only the existing items are allowed in this field. Seeded dispatch methods are:

    • Delivered with Shipping Documents if the documents were delivered as part of the shipping document package.

    • Email if the documents were sent as part of an email.

    • Fax if the documents were sent by facsimile.

    • Mail if the documents were sent by the postal service.

    • XML Gateway if the documents were sent using the XML gateway.

      You can seed additional dispatch methods.

  9. The following fields are display only:

    • Document Category is the category assigned to the document in iSignatures Files Approval. For example, MSDS for Regulatory Item is a typical document category.

    • Document Description is a description of the document selected.

    • Document Version is the version of the document selected.

To display the safety document dispatch history:

  1. Navigate to the Document Dispatch History window. The Find Dispatch History window displays.

  2. Enter fields as described in "Finding a Dispatch History Record."

  3. Click Find. The window displays a history of documents that fit the search criteria entered.

To display a document attachment:

  1. Select the desired row in the dispatch history.

  2. Click Open Document. The document opens.

To display recipient information:

  1. Select the desired Recipient row.

  2. From the Actions menu, click Recipient Information.

  3. The Customers-Standard window displays. Refer to the Oracle Receivables User's Guide for an explanation of this window.

Finding a Dispatch History Record

Use the Find Dispatch History window to find a specific document that was dispatched.

To find a document dispatch history:

  1. Navigate to the Find Dispatch History window.

  2. Enter any of these fields to narrow your search:

    • Item as the regulated item. The Item Description displays.

    • CAS Number as the Chemical Abstracts Service registry number.

    • Ingredient as a regulatory item with the Ingredient indicator selected.

    • Document as the name of the document dispatched. The Document Description displays.

    • Document Category as the category assigned to the document in iSignatures Files Approval. For example, MSDS for Regulatory Item is a typical document category.

    • Recipient as the individual to whom the dispatch was sent.

    • Date Sent as the date or date range that the documents were dispatched.

    • Dispatch Method as the method that was used to dispatch the document. Dispatch methods are described in "Entering the Dispatch History."

  3. Click Find.