User orientation and training: ROSS-ICBS Interface 04/11/2011

User orientation and training: ROSS-ICBS Interface 04/11/2011

Features of the interface • Beginning on December 7, 2010, ICBS and ROSS began exchanging incident, request and fulfillment information • The system of record for all incidents will be ROSS • When incident issues are created by an ICBS user, ICBS will query ROSS for the appropriate incident information • Requests can be initiated in either ICBS or in ROSS • When ICBS users take action on requests, this information will be sent to ROSS • ICBS users will be notified of incidents and requests through the ‘Alert’ function that displays on the user’s home page

Incident Creation • Incident can be created basically two ways: • ICBS initiated Incident • ICBS user enters incident number and year in the Issue Entry screen • If the incident does not already exist in ICBS then a query is sent to ROSS for the incident information and displays the incident details • ROSS initiated Incident • ROSS user creates incident and request for NFES items • ROSS sends incident information to ICBS along with request details

ICBS Initiated Incident • Incident is created in ICBS through Issue Entry screen • Enter Incident Number, Incident Year and tab out

ICBS Initiated Incident (cont.) If incident does not exist in ICBS the following prompt will display Click on OK If the incident does not exist in ROSS this error will display © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

ICBS Initiated Incident (cont.) • If an incident exists in ROSS, the Incident Details screen will be populated. The ‘ROSS Financial Codes’ section shows the code(s) that exists in ROSS. This is just a reference for the ICBS user • The ICBS user will need to fill in the appropriate agency ‘Account Code’ field(s) in the ‘Incident Properties’ section ICBS user enters BLM, FS and/or Other account code(s) as needed here ROSS provides a “read only” account code here © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

Register/Deregister Incident Interest • When an incident is created in ICBS the default is ‘register interest in ROSS’ and the box is checked • ‘Registering’ an incident is how ICBS ‘tells’ ROSS it wants to be kept updated on any of its incidents • Whenever incident information is changed in ROSS for registered incidents, ROSS sends this info to ICBS • Examples of updates include: • Incident name • Account code(s) • Address(es) • Incident merges

Register/Deregister Incident Interest (cont.) • Although there’s an option to “Deregister Incident Interest” on the menu, there’s currently no reason for an ICBS user to do that • An ICBS user registers or deregisters interest by clicking the ‘Register or Deregister Incident Interest’ button on the ‘Incident Details’ screen • ICBS ‘tells’ ROSS through a webservice call that ICBS is interested or not interested in this incident

Active/Inactive Incident • The Active or Inactive flag is set from the ‘Incident Details’ screen. • User checks/unchecks ‘Active’ check box and clicks on Save button. ICBS sends the current status of the incident in a message to ROSS via a webservice call (backend)

Unlock Incident • An incident will be locked for different reasons: • Temporarily when ICBS sends a message to ROSS to activate/inactivate an incident or to register/deregister interest in it • When ROSS will not accept messages for an incident: • The incident does not exist in ROSS • The ('source') incident has been merged in ROSS with another ('surviving') incident • The user can unlock an incident from the Incident Details screen © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

Update Incident Notification Message • Notification is received via the NWCG Incident Success or Failure Queue • ICBS updates incident information based on changes in ROSS • It receives a notification from ROSS when the following information changes: • Incident Billing Organization • Shipping Address Updates • Financial Code • Contact • Type • Name

Update Incident Notification (cont.) • ICBS raises an alert for ‘Update Incident Notification’ if incident does not have: • Valid Customer ID • ROSS primary financial codes • Request number blocks • The failure alert will occur in ICBS • The ICBS user should then contact a ROSS user to correct the information and resend to ICBS

Update Incident Key Notification • Notification is received via the NWCG Incident Success or Failure Queue • This notification is used to update the ‘Incident Key’ of an incident • An Incident key is made up of the incident number and year • Example: ID-BOF-23456 2011 • ICBS creates a new incident with the new incident key, copies over the old incident information and updates the ‘last incident 1’ field

Transfer Incident Notification Notification is received via the NWCG Incident Success or Failure Queue This notification is used to update the ‘Dispatch Unit ID’ on an incident in ICBS ROSS ‘transfers’ an incident from its original dispatch organization to a different dispatch organization

Incident Issues • Incident Issues can be created in ICBS in two ways: • ICBS initiated issue • ROSS initiated NFES request

ICBS Initiated Issue • Issues can be created in ICBS for all NFES items with the exception ROSS tracked resource items (i.e. NIRSC radio kits, RAWS, etc) • As part of the Issue creation, ICBS validates the following with ROSS: • Incident data • ICBS performs an internal validation of these items: • Different Address Types • Item information • Request Number block

ICBS Initiated Issue – Communication with ROSS • A ‘Create Request’ message ‘tells’ ROSS that a new issue and request lines have been created in ICBS • This is sent to ROSS on successful ‘Schedule and Release’ in ICBS • The message contains the following data for all the request lines: • Incident Data, Item Data • Request Number, Quantity Requested • Address, Shipping Contact Name and Shipping Contact Phone • Line Comments, Shipping Node, Issue Info (Issue number, Issue Create Timestamp, Requested Delivery Date, Addresses)

ICBS Initiated Issue – Communication with ROSS (cont.) • An alert is generated in NWCG_ISSUE_FAILURE queue if ROSS sends a negative response for Create Request message • This, does not prevent the issue from being processed, but ICBS will be unable to send the issue info to ROSS • The ICBS user • Research the error for resolution or contact the ICBS helpdesk if the description of the error is unclear and the user is unsure of what the remedy should be. Depending on the issue failure there may need to be involvement from the developers to assist to get the two systems back in synch. • Contact a ROSS user and give them the ICBS error description (e.g. ROSS system is down, etc.) so they can determine why they were unable to create the request in ROSS

ICBS Initiated Issue – Communication with ROSS (cont.) Once the problem has been resolved, the ICBS user should close the alert.

ROSS Initiated Issue Notification of a ROSS initiated request will be in 'NWCG Issue Success' or 'NWCG Issue Failure' alert queue in the Alerts section on the user’s home page. De Depending on if the user is the default for the alerts the information will display differently pending on if they are the default for the alerts the information will display differently © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

User accesses the Alert Queue from their home page Click on Click on the NWCG Issue Success or the particular Alert ID.Click on the NWCG Issue Success or the particular Alert ID.the NWCG Issue Success or the particular Alert ID. © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

It’s the ICBS user’s responsibility to update the appropriate agency accounting information in the Incident Properties panel based on the ROSS Financial Code that is marked as ‘true’ and SAVE. © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

Once the incident is saved click on the back button to the Alert Detail screen again. • Click on the Issue Detail Link hyperlink to access the issue details © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

ROSS Initiated Issue – Issue Details Status of issue is ‘Draft Order Created by ROSS Issue is processed as normal from this point © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

Processing requests • You will still be able to fill, forward, backorder and UTF requests (or parts of them) • Substitutions and consolidation process will be implemented: © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

Processing ‘Item Substitution’ -- Enter cache items and click on SAVE - Issue needs to be in ‘Draft Order Created’ or ‘Created’ status - Check box next to item to be substituted - Click on >> and selection ‘Substitute Item’ Enter the number of lines for substitution and click on Add or tab out © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

Complete item substitution -- Request number auto fills with .dot notation - Enter the Item ID and quantity for substitution - Click on SAVE © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

Item Substitution – Issue Details Original request number status = ‘Cancelled due to substitution’ Issue is completed with normal steps © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

Processing Item Consolidation -- Enter cache items and click on SAVE - Issue needs to be in ‘Draft Order Created’ or ‘Created’ status - Check box next to items to be consolidated - Click on >> and selection ‘Consolidate Items’ © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

Processing Item Consolidation (cont.) Select the request number to be used for the consolidation by clicking the button next to it -- Request number auto fills with .dot notation - Enter the Item ID and quantity for consolidation - Click on SAVE © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

Item Consolidation – Issue Details Original request numbers status = ‘Cancelled due to consolidation’ Issue is completed with normal steps © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

Update Request Message • An ‘Update Request’ message informs ROSS when the ICBS user takes action on requests: • Fulfilled request information is sent to ROSS when the user successfully ‘Confirms Shipment’ • Info on full UTF requests and 'Non-surviving Consolidated' requests is sent to ROSS as part of an agent which runs at regular intervals. Right now that is set to run every 5 minutes.

Status Request Message A ‘Status Request’ can be initiated by a ROSS user, which sends a message to ICBS to get the current status of a request line(s) This is a system call and there are no visual changes on the ICBS console

Incident Merge Message • A ‘Merge Notification’ message from ROSS tells ICBS that a registered incident has been merged with another incident • The registered incident is called the ‘source incident’ and it’s merged with a ‘destination’ incident • Upon processing of a Merge Notification in ICBS: • The source incident is locked and closed in ICBS • The destination incident becomes active • An alert is generated in NWCG_INCIDENT_SUCCESS or NWCG_INCIDENT_FAILURE queue

Other Issues • ‘Other Issues’ are created only in ICBS • No information comes from ROSS for this type of issue • ICBS doesn’t communicate Other Issue information to ROSS

ICBS Alerts • Alerts are how ROSS notifies ICBS users of changes in incident information, new requests and other things needing the attention of an ICBS user • Alert queues: • Many users at a cache can be assigned to queues to see alerts • Anyone can take actions needed • Alerts: • Are broadcast to specific queues (e.g. incident, request, inventory, etc.) • Assigned by default to one person per cache

ICBS Alerts (cont.) Managing and using alerts will take some getting used to To prevent incident orders for NFES items from being overlooked, we’d suggest that cache personnel ask dispatchers to phone the cache to let them know when incident order requests are created in ROSS – at least until everyone gets used to alerts © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

Frequently Asked Questions (FAQ) • Will I be able to create incidents? • No. They’ll be created in ROSS. • When you create an incident Issue, ICBS will query ROSS to get the incident details if the incident isn’t already present in ICBS

FAQ (cont.) Will all incident order requests have to be created in ROSS? • Will I be able to find the incidents I need? • If the incident doesn’t exist in ROSS, you’ll need to call your dispatch office and have them create it © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

FAQ (cont.) • Will all requests need to be created in ROSS? • Requests can be created in ROSS or ICBS. • For cache input of requests, incidents will be given a block of request numbers (S-100000 to S-199999) to use. This keeps ICBS and ROSS from trying to use the same request numbers © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

FAQ (cont.) • Do dispatchers and incident teams know about the block of request numbers that caches will use? • A memo was distributed on this topic by the ROSS Team over a year ago • On February 25, 2011 a memo addressing this, and other ROSS-ICBS interface issues, was issued by the Equipment Technology Committee (ETC) to Incident Commanders and Logistics Section Chiefs (as well as Coordinators, Dispatchers and National Cache Managers). • It was also discussed with incident logistics personnel at the National Logistics Workshop on March 1, 2011. © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

FAQ (cont.) • Can Incident Management Team (IMT) Pre-Orders be created in ROSS and placed through the interface to a cache? • Yes. The only limitation a ROSS user needs to be aware of is that supplies and non-supplies can’t be on the same Pre-Order in ROSS. This is because caches require additional shipping information for supply orders that is not required for orders not placed with a cache. © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

FAQ (cont.) • How are request numbers created for Pre-Orders placed with a cache? • If the Pre-Order is created in ROSS, the ROSS user will assign the S-numbers in ROSS, and the “ROSS-initiated issue” will show up in ICBS with the S-numbers assigned to each request line. • If the Pre-Order is faxed or hand-delivered to the cache to be entered in ICBS, the dispatcher or IMT should provide the request numbers from the “incident-to-cache” block of numbers assigned by ROSS for incident-to-cache © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

FAQ (cont.) • Does ROSS display Standard Pack information to help the user request NFES items so they can be issued in standard packs? • Yes. On the ROSS New Request screen, the user searches for an NFES catalog item (e.g.“BATTERY, size AA, 1.5 volt, penlight 000030”). When the user highlights the desired item, the "Standard Pack" field under the Catalog Item will display the appropriate standard pack value (i.e. 24/PG) © 2009 Sterling Commerce. All rights reserved. Confidential and Proprietary.

User orientation and training: ROSS-ICBS Interface 04/11/2011