Salesforce

Actuals Interface Requirements

V3.2 4/13/2012

Contents

1.

Opportunity
Description

We need to map Actuals to each opportunity. We match using the quote line details; this will give the maximum accuracy. We will send multiple rows to Yoda, one for each quote line item on every quote created in the opportunity. The actuals wont be presented in the opportunity screen. If actuals are returned then the system should set the Status to closed won automatically. The actuals stored will be used for reporting. Campaign management will link to the opportunity via the campaign name that is stored in the opportunity in order to report campaign success. We cannot use commodity to match on. We will only request actuals from Yoda for Opportunities with SFDC created quotes; we cannot request information for opportunities with attached quotes like OOG, Tenders and rate sheets. The actuals data returned will be purely control credit based.

Matching Criteria
SFDC Field Opportunity Id Message Type 1.Concern code Yoda data field N/a N/a Svc Contract Cust Conc Code Sample data 12345 OPPORTUNITY_QUOTE ***234206

2.SCV Customer Code Cargo Type Operator Code Receipt service mode Delivery service mode Place of Receipt Place of Delivery Container Size/Type Quote Effective from Quote Effective to PnQ Container Size/type Yoda size Type

OR Svc Contract Cust Code Cargo Type Operator Code Receipt Service Mode Delivery Service Mode Place of Receipt Place of Delivery Container size & container Type & container Height Operational Plan Port Dep 1 Date This is the LOPFI date in Yoda. Height Cargo Type

436234206 DRY, REEF MSL CY, SD CY, SD AEJAL GHTKD Please see PnQ to Yoda mapping table below. 2012-01-01 2012-06-30

20 Dry 40 Dry 40 Hdry 45 Hdry Nor 20 Reef 40 HReef

20 40 40 45 20 40 40 20 40

Dry Dry Dry Dry Reef Reef Reef

86 86 96 96 86 96 86 86 96

Dry Dry Dry Dry Dry Dry Dry Reef Reef

We will send you the PnQ values

UI Fields
The actuals data will only be used to set the status to closed won, it wont be displayed. Update Trigger/Frequency This data will be requested on a weekly basis. Actuals requesting should stop 6 weeks after quote effective to has been passed in time. Always start the matching on data from 2 weeks prior to the requesting.

Expected Volume
We estimate 3 million opportunities will be created per year.

Data Structure
This granularity will be returned from Yoda and stored in database. Opportunity Id Message Type Cargo Type Total FFE Total CY Bretts Notes - Opportunity/Quote When creating a quote Drop the field Historic FFE this is already covered under Actuals/Potentials. There was a comment that in PNQ we have historical FFE and historical BAS, but this can be left out for phase 1 if required. We dont need quote line actuals when the user is viewing the prices. In a new opportunity Expected FFE will be replaced with Route Expected FFE. When creating a new opportunity, under Opportunity Detail. The Cargo types should just be Dry or Reefer (With it defaulting to Dry). The other options that are currently there (Fwd FAK, Traded Commodities, BBK/OOG) should all be attachment types instead. Can we move the validity dates from the quoting stage to the opportunity stage (I believe this is already mentioned above). Rene wants reefer rates to be included also, so when no rate is returned the rate comes up blank then the user can manually update the quote with the amount from the rate sheet.

2.

Sales Targets
Description

We need to map Actuals to sales targets against customers and salesperson lump sum. Targets are not set against concerns. The actuals data returned will be based on control and non-control credit allocation. The actuals data returned will be stored on a monthly basis but displayed on screen as quarterly targets. The actuals data will also be used in reports. The business needs the ability to create next years budget in October of that current year and keep budget and targets for multiple years. Yoda will identify the lump sum totals for each sales person for controlled and non-controlled by applying the following logic: Sum of all FFE and CY actuals for all customers assigned to the salesperson excluding all actuals that have already been assigned to a customer level target.

Matching Criteria
Type 1 Route code & Direction Level SFDC Field Yoda data field Target Id N/a Message Type N/a SCV Customer Code Yoda will use both these fields to calculate and return the appropriate CY and FFE totals based on the control type specified Sales Person Route Code Route Code Route Direction Route Direction Cargo Type Cargo Type Operator Code Operator Code Control Type ? Year First Departure Year Type 2 Lump sum SFDC Field Target Id Message Type Sales Person Route Code Route Direction Cargo Type Operator Code Control Type Year Yoda data field N/a N/a Control logic calculation performed by Yoda Route Code Route Direction Cargo Type Operator Code ? Operational Plan Port Dep 1 Date Sample data 12345 TARGET_ROUTE 436234206

SMT002 E1 W DRY, REEF MSL Control/non-control 2012

Sample data 12345 TARGET_LUMPSUM E1 W DRY, REEF MSL Control/non-control 2012

UI Fields

The actuals data will be aggregated and displayed on the target screen at the following level. SCV Customer Route Code Route Direction Cargo Type Control or Non-Control Year Q1 FFE Q1 CY Q2 FFE Q2 CY Q3 FFE Q3 CY Q4 FFE Q4 CY

Update Trigger/Frequency
This data will be requested on a weekly basis. Actuals requesting should stop 6 weeks after the last quarter (December 31st). Actuals should only be requested for the current year.

Expected Volume
We estimate there will be 700, 000 targets created per each year.

Data Structure
This granularity will be returned from Yoda and stored in database. Target Id Message Type Route Code Route Direction Cargo Type Control Year FFE January February March April May June July August September October November December CY January February March April May June

July August September October November December Bretts Notes - Sales Targets Should sales targets be done in SFDC or BI? The Sales target overview screenshot needs to look like excel, at least for the reporting. Country to country is out of scope for targets, I need to check with Lorna why it was required from the RAD session (Main issue is where it is required from TNM). For targets we need the ability for the end user to do an excel extract, manipulate the data, then send to a SYSADMIN to upload back to SFDC. Need to investigate how using sales person I.D. for targets will affect the Inside Sales Development teams.

3.

Market Mapping
Description

We need to map actuals for the past 12 months rolling for each customer on a country to country basis. The data will be stored in the database and presented on screen as one value for the 12 month period. The business will also make use of this data within reports. The actuals dont make use of the control/non-control logic.

Matching Criteria
Type 1 - Export SFDC Field Market Mapping Id Message Type SCV Customer Code Current Date Yoda data field N/a N/a Shipper Cust Code We require the volumes to be based on rolling 12 months from the date of the request. Matching against Operational Plan Port Dep 1 Date POR Country Code POD Country Code Operator code Sample data MM-40 MARKET_EXPORT 436234206 2012-02-01

Mapped Country* To Country* Operator code

*These will be Geo Ids.

AE GH MSL

Type 2 - Import SFDC Field Market Mapping Id Message Type SCV Customer Code Current Date

Mapped Country* From Country* Operator code

*These will be Geo Ids.

Yoda data field N/a N/a Consignee Cust Code We require the volumes to be based on rolling 12 months from the date of the request. Matching against Operational Plan Port Dep 1 Date POD Country Code POR Country Code Operator code

Sample data MM-40 MARKET_IMPORT 436234206 2012-02-01

AE GH MSL

Type 3 Cross Trade SFDC Field Market Mapping Id Message Type SCV Customer Code

Yoda data field N/a N/a Contractual Cust Code. The shipment (Place of receipt/delivery ) must be happening outside of

Sample data MM-40 MARKET_CROSS 436234206

Current Date

From Country* To Country* Operator code

*These will be Geo Ids.

the country of the Contractual Cust Code in order to be classed as Cross trade We require the volumes to be based on rolling 12 months from the date of the request. Matching against Operational Plan Port Dep 1 Date Place of Receipt Country Place of Delivery Country Operator code

2012-02-01

AE GH MSL

UI Fields
The actuals data will be displayed in the Actual FFE field.

Update Trigger/Frequency This data will be requested on a monthly basis. SFDC will never stop requesting this information from Yoda. If a new market mapping corridor is added then that needs to be requested straight away.

Expected Volume
We estimate there will be 7 10 million market mapping lines but this could increase by a multiple of 5 when new customers are added (worst case scenario).

Data Structure
This granularity will be returned from Yoda and stored in database. SFDC will receive the below message structure for each of the different message types. A separate row for each of the different messages types returned. Market Mapping Id 12345 Message Type MARKET_EXPORT, MARKET_IMPORT, MARKET_CROSS Total FFE for rolling 12 month period

4.

Account Level Actuals

Description

We require 2 separate streams of data that will be stored against the account as follows: 1. Total FFE per customer for last 12 month period This value will be used in the Quoting process. The actuals FFE value will be based on either total FFE for all SCV customer codes associated to a concern code linked to the customer (if one exists) or total FFE for just that SCV customer code if no concern code association exists. 2. Year to date FFE (Jan to Now) This data will be returned at a more granular level for reporting but will be aggregated up to display on screen at a quarterly level, the values on screen will only display totals for Control actuals. The data will be displayed on the account screen and used in reports.

Matching Criteria
Last 12 months FFE (Rolling 12 months) SFDC Field Yoda data field Account Id N/a Message Type N/a . 1.Concern code Svc Contract Cust Conc Code Sample data 12345 ACCOUNT_ROLLING ***234206

2.SCV Customer Code Current Date

OR Svc contract owner Id Code

436234206

Operator code

We require the volumes to be 2012-02-01 based on rolling 12 months from the current date specified minus 2 weeks for the weekly refresh. Matching will be against Operational Plan Port Dep 1 Date Operator code MSL

Year to date FFE (January to now) SFDC Field Yoda data field Sample data Account Id N/a 12345 Message Type N/a ACCOUNT_YTD SCV Customer Code Yoda will used both these 436234206 fields to calculate and return the appropriate CY and FFE

SFDC Field Sales Person Current Date

Yoda data field totals based on the control credit logic.

Sample data

Operator code Year

SMT002 We require the volumes to be 2012-02-01 based on year to date (Jancurrent date). Matching against the Operational Plan Port Dep 1 Date Operator code MSL Operational Plan Port Dep 1 2012 Year

UI Fields
The screen will show totals based on summed control actuals only in the following fields: Controlled (Title) Last 12 months FFE This pre populates the potential ffe in the opportunity and quote screens. Year to date FFE - this is Jan to now Update Trigger/Frequency This data will be requested on a weekly basis. SFDC will never stop requesting this information from Yoda for any of the 3 streams. We will only request actuals for active customers.

Expected Volume
We need to send for all active customers (1.3 million) but the business only expect to receive back only 300,000 rows of data (That will be customers that are actively booking).

Data Structure
Two different levels of granularity will be returned from Yoda and stored in database. Last 12 months FFE (Rolling 12 months) Field Comments Account Id SFDC Unique key Message Type ACCOUNT_ROLLING Cargo Type DRY, REEF Total FFE

Year to date FFE (January to now) Field Comments Account Id SFDC Unique key Message Type ACCOUNT_YTD Route code E1 Route Direction E Cargo Type DRY, REEF

Control type FFE January February March April May June July August September October November December CY January February March April May June July August September October November December Total Revenue January February March April May June July August September October November December

Control, Non-Control

Bretts Notes - Account Under accounts, Performance Why do we have a Total Won Opportunity field, what is this used for? It seems largely irrelevant. For the performance section, we need to indicate that they are all control. Under Customer profiling Drop CO2 level increase and Global warming

5.

Campaigns
Description

We need to link to opportunities that have been associated to campaigns. We cant report against opportunities that dont have SFDC quotes created, this is a limitation. There is no need to display this information of screen only in reports. The actuals identified will be purely control credit based. There is no data stream to be requested from Yoda for this requirement; it will be sourced from the actuals data already stored against the Opportunities. .

Matching Criteria
Match campaign to opportunity via the Additional Information. Campaign Name field.

UI Fields
N/A Update Trigger/Frequency N/A

Expected Volume
N/A

Format of data Returned

See opportunity section above.

6.

Further Information

The sales BPO have advised that the actuals in Yoda for the 2 weeks prior to todays date are not accurate and therefore all calculations should be based on Todays date 2 weeks. The problem is the parties and details on the TP Docs are still being adjusted by Customer Service after vessel departure, so there is general instability in the base data. In RKMS2, this was covered by the vessel being released before any actuals were posted. YODA does not have that restriction as it contains current and future (booking) data as well. In order to ensure we are only assessing if a moved shipment truly was logged against a quote, we need the GCSS base data to stabilize to prevent any false positives and negatives. This stabilization of the base data is usually fairly complete 2 weeks after the first load date, and extremely stable after 6 weeks. Thus the rule of thumb is 2 weeks (and is also accepted by the business as to why there was always a lag in RKMS2 actuals).

7.
Version V0.1 V2.0

Change Log
Changes Done By Stephen Turner Stephen Turner Changes Made First Draft Share of wallet - Have removed feed request as Claus confirmed not required, we will use rolling 12 month actuals feed for the basis of the calculation. Account level actuals have revised this section in line with feedback from Daniel & Jason. Alignment of version number with Yoda team Opportinity have added in cargo type = Reef and added in the lookup container size/type values to the reference table. Opportunity Have reduced the granularity of the returned data to just cargo type, total FFE, total CY

V3.0

Stephen Turner

V3.1

Stephen Turner

V3.2

Stephen Turner