2565 rfsa

From UG

Revision as of 23:17, 12 December 2010 (edit) Alex (Talk | contribs) ← Older edit		Revision as of 23:18, 12 December 2010 (edit) (undo) Alex (Talk | contribs) (→Business Analysis) Newer edit →
Line 19:		Line 19:
	== Business Analysis ==		== Business Analysis ==
		+	''Author:''
	=== Glossary ===		=== Glossary ===

---

Revision as of 23:18, 12 December 2010

Contents 1 Info 2 Business Analysis 2.1 Glossary 2.2 Requirements 2.2.1 Estimated Cost 2.2.2 Estimated Sell 2.2.3 Reports 2.2.4 Dashboard 2.2.4.1 Dashboard visibility 2.2.5 DESIGN IDEAS 2.3 Possible solutions 2.4 RFP 3 Systems Analysis 3.1 Summary 3.2 Implementation Phase 1 3.2.1 Shipments 3.2.2 Reports 3.2.3 Misc 3.3 Implementation Phase 2 3.4 LA Notes 4 Architect Review 5 Implementation Summary 6 QA Plan 7 History

Info

Mantis: 0002515 [Estim P&L] .......<proj> This is a Project.

Product Team:

• Module Owner: Karen
• Business Analyst: Tracie

Development Team:

• Systems Analyst: Alex
• Architect: Kostya
• Developer: ?
• QA: ?

Business Analysis

Author:

Glossary

Gross Margin - same as "P/L".

Point Of Revenue Recognition - This is the date that the "Sale" is considered complete. (based on law/standard)

For Ocean LCL and FCL Shipments #Port Of Loading Actual Date

For Air shipments #Airport Of Departure Actual Date

For Truck shipments #Actual Export Pick Up Date

Month-end closing An accounting procedure undertaken at the end of the month to close out the current posting period. IN the context of this task it means to have all cost and sale numbers are available. This is for CTs that reached Point Of Revenue Recognition.

Requirements

Core: Enable accounting to “close out” the month end, at the actual end of each month, based on estimated charges. In order to achieve this we will follow the below.

We need to give operators the ability the enter estimated costs and sale rates for each CT record. This information will be used for accounting to close the accounting books Month-end closing at the end of each month.

Estimation for freight charges:

• Pull the estimated sell rate from a database to be entered under the client profile (to be handled on phase 2)
  • If nothing is in the database that matches the required information(TBA defined in Phase 2)the system should automatically calculate the estimated sell by:
    • Pull cost from a database (to also be handled in phase 2) and add 15% to it. The estimated sell should equal the total of the (cost x 15%)+ cost
  • Work around for Phase one - Operators should manually enter cost. The sell should calculate automatically be based on the above calculation.
• Operators will need to be able to edit the costs and sell and cost or sell estimations manually.
• They should also be able to add and remove lines from the estimation.

Exception:

• Customs Cost's
  • Charge Codes beginning with 12 should have no calculation. The sell should match the cost entered. (System should copy same number from cost to sales field).
  • The operators should still be able to manually update the cost and sell and the cost or sell.

Estimated Cost

should reflect:

• Dollar Amount
• Vendor
• Currency
• Charge Code
• Charge Code Description
• Total of all estimated Cost entered should be shown
• Currency of the total estimated Cost should be shown

Estimated Sell

should reflect:

• Dollar amount
• Currency
• Charge Code
• Charge Code Description
• Total of all estimated sell entered should be shown
• Currency of the total estimated sell should be shown

Reports

• Should be able to generate a report showing both estimated cost/sell and actual cost/sell
• The report should be per CT record
• should be within a selected time frame
• should able to download to excel

Dashboard

New type of dashboard panel required.

It should show how many CT records passed Point Of revenue recognition AND are CT is not estimated.

CT is not estimated - grand total is 0 on EstTab.

Dashboard visibility

To identify which operator should have CT posted to this dashboard the following criteria must be met:

• CT records passed Point Of revenue recognition AND
• CT is not estimated AND
• operator belongs to the office that handles the specified region:
  • Ct#Airport_Of_Destination/Ct#Destination_Terminal/Ct#Export_Delivery_To_Address belongs to the region defined in Geography>Regions>Office field for this given operator

DESIGN IDEAS

These charges will be entered in on a separate Tab Est., as per examples below

Once these charges are entered – It should then pull through and show on the P/L tab.

The difference between actual and estimation should be easily identified (by example attached maybe using a lighter color)

Possible solutions

RFP

Systems Analysis

Summary

• In order to perform of month-end closing, each CT that passed the Point Of Revenue Recognition within this month should be estimated:

• By default, estimated sale is calculated automatically as (est.cost x 15%)+ est.cost. Also should be ability to manually enter it.
• NOTE: This is performed normally within 5 days after Point Of Revenue Recognition. But in phase 1 it is not enforced (so it is up to operator).

• Estimated cost and sale should show on P/L Tab immediately.
• Need a report to show estimated and actual cost/sell per CT.
• Count of not-estimated CTs should be reflected on special dashboard panel.

Implementation Phase 1

Estimated cost is entered manually.

What need to do in:

Shipments

• Add new CT Tab - Estimated (like a New Invoice Template including Table of Charges)
  • List of Fields is specified in #Estimated_Cost and #Estimated_Sell sections.
• Update P/L Tab
  • Add new columns: Est Sales, Est Purchase.

Reports

• Update Profit/Loss for Multiple CTs report
  • change "Profit/Loss" in the name of report to "Gross Margin"
  • add new Date Type - Point of Revenue Recognition
  • add estimated columns to Output

Misc

• add new type of dashboard panel

Implementation Phase 2

Estimated cost is pulled from a database and is the client-specific.

LA Notes

• Requirement "Operators will need to be able to edit the costs and sell and cost or sell estimations manually." UI design should be "smart" to handle this well. For example add checkbox to every line indicating if it is "auto" or "manual". If auto then show sale box as read only. If "manual" then show both editable and do not apply auto calculate.

Architect Review

Implementation Summary

QA Plan

History

• 0002565: [Estim P&L] Complete Requirements / Design Ideas wiki sections
• complete re-work --Alex 18:17, 12 December 2010 (EST)