GMS

From UG

Contents 1 Info 1.1 Mantis 1.2 Scope 2 Glossary 3 Business Requirements 1 4 OC Functionality 4.1 OC status 4.1.1 Closing Time Frame 4.1.2 OC Status Values 4.1.3 Setting OC status automatically 4.1.3.1 Closed CT condition 4.1.3.2 OC process 4.1.4 Setting OC status manually 4.1.5 Closed CT have different permissions 4.1.6 Setting OC status by script 4.1.7 Display OC status on Gen Tab 4.2 Opening and Closing shipments when Groups and Masters are involved 4.3 Viewer for CT, Master and Group 4.4 Interface to manually "open" and "close" CTs 4.5 Block altering of the "closed" CT/Master/Group 4.6 DR report to show all manually opened CTs in the system 4.7 DR report for closed files without a delivery status 5 GMS functionality 5.1 Prerequisites for GMS calculations 5.1.1 Owners Office 5.1.2 Import, Export and Third Offices 5.1.3 GMS section in Admin 5.1.3.1 GM Split Rules 5.1.3.1.1 GM ratio 5.1.3.2 Schedule for GM Split calculation 5.1.3.3 Credit to the office 5.1.3.4 Limitations on pending GMS and closed files 5.1.3.5 Log for GMS Admin Changes 5.1.3.6 Access Rights 5.2 GMS status 5.3 GMS Splitter Process 5.3.1 Steps for GMS Splitter 5.3.2 GMS Algorithm 5.3.2.1 Example 1 5.3.2.2 Example 2 5.3.2.3 Example 3 5.3.2.4 Example 4 5.3.3 Invoices generated by GM Splitter 5.3.3.1 Number of invoices 5.3.3.2 Two types of Internal Invoices 5.3.3.3 Invoice numbering 5.3.3.4 Timing 5.3.3.5 Layout 5.4 CT Tabs 5.4.1 Inv Tab 5.4.2 P/L Tab 5.5 Existing Acc Reports 5.5.1 Search Inv Report 5.5.2 P n L for Multiple CTs 5.6 Browser for Consolidated Internal Invoices 5.7 GMS Misc 5.7.1 Display OO, EO, IO, GMS Status, GMS Case on Gen Tab 5.7.2 UC: How to apply new GMS split rules to GMS completed CTs 5.7.3 Create DR report to identify all new shipments without an Owner Office 5.7.3.1 Info for E0 estimate

Info

Mantis

• 0003321 [Profit Sharing Module]

Scope

Covers this one module - Profit Sharing Module.

Glossary

Business Requirements 1

See GM Split Requirements.

OC Functionality

OC status

At some point in the life of a shipment record it will not be updated anymore. Moreover some updates would become harmful. Therefore, certain types of functionality should be blocked for "old/mature" records. This would prevent undesirable situations such as:

• altering shipment weight after invoices has been issued
• issuing invoice before all PI/SI are in
• etc

Record that have limited functionality as far as updates/etc is called "closed" and should have status "closed". Otherwise it is "open".

We call this status "OC status" - (Open/Closed) status.

Closing Time Frame

We need a table in the system that defines how many days shipment should stay open since it was created.

For every MOT this number is different.

Typical values:

Air - 35 days
FCL - 60 days
LCL - 70 days
Truck (all 3 sub-modes) - 35 days

Number of days is editable field.

Set default as 1000.

Add this to User Access table.

OC Status Values

• n/a

for CTs closed before 2012

• open

for new CTs or manually re-opened CTs

• manually open

for CTs that were manually opened by user

• closed but not delivered

CTs closed by user or system (satisfy #Closed CT condition) but do NOT satisfy "delivered CT" condition - see List_CTs#DELIVERED

• closed and delivered

CTs closed by user or system (satisfy #Closed CT condition) and that do satisfy "delivered condition" - see List_CTs#DELIVERED

There are three ways to set this status: automatically, manually and by script.

Setting OC status automatically

When new shipment is created its status is automatically "open".

Closed CT condition

When the number of days between Actual Date Of Departure and today's day becomes equal to 
#Closing Time Frame CT is said to satisfy "closed" condition.

OC process

• OC Process is a process that runs periodically and updates "OC status" and "GMS status":
  • it checks on all "open" CTs to see if they can be set as "closed but not delivered" or "closed and delivered"
  • it checks on all "closed but not delivered" and see if now they can be set as "closed and delivered"
  • also if it is changing CT status to "closed and delivered" then it will also set GMS status to "pending" from "not ready"

• Currently it is defined to run once a day (maybe defined in Admin)

Setting OC status manually

We need to provide functionality to manually:

• set status to "closed" on open and manually open CTs
• set status to "mannually open" on closed CTs (user who opened CT manually must close CT manually)

This is subject to user access permissions.

Suggested implementation: add "Close/Open file" button to P/L Tab.

Closed CT have different permissions

CT (file) that has "closed" status should limit what operators can do with record.

See #Viewer for CT, Master and Group

Setting OC status by script

All CTs that would close prior to Jan 1, 2012 (if this functionality would be available since the beginning) should have status "n/a" or "closed before 2012".

All CTs that would close from Jan 1, 2012 to Release day (if this functionality would be available since the beginning) should have status "closed before 2012" should have status "closed".

Tech Note
--------
To achieve above we need to write and run appropriate scripts prior Release !

Display OC status on Gen Tab

Opening and Closing shipments when Groups and Masters are involved

In general, we want to have Master or Group to be consistent in terms of open/close status. It means:

Master/Group has open status if and only if 
       every CT inside of that Master/Group has open status.
Master/Group has closed status if and only if 
       every CT inside of that Master/Group has closed status.

Closing

CT that is a part of a Group or/and of the Master can be closed only when ALL CTs in that Group or Master can be closed based on the individual time frames.

In case of automatic closing System would have to wait for all CTs to "mature" in terms of timeframes.

In case of manual closing System should give a warning to the user that all CTs (in related M/GRP) are going to be closed.

Opening

In case of manual opening System should give a warning to the user that all CTs (in related M/GRP) would be opened.

Viewer for CT, Master and Group

• should mimic look and feel/layout for editors
• block all functionality that would affect GM Split (editing records, adding CTs to Master, etc)

Interface to manually "open" and "close" CTs

• "Open/close" button on P/L tab
• This is subject to access table
• Log who/when opened/closed

Block altering of the "closed" CT/Master/Group

For users who have no ability to open manually system should display error explaining why edit is not possible and suggest "view" instead.

DR report to show all manually opened CTs in the system

• Lev 1: counter - how many CTs have status "manually" open
• Lev 2: xls (if no extra time); sortable HTML with xls option (if enough time); Columns:
  • CT# (hyperlink)
  • Client
  • who manually opened
  • when manually opened

DR report for closed files without a delivery status

This report should show all CTs that have #OC_Status_Values = closed but not delivered

• Lev 1: counter
• Lev 2: xls (if no extra time); sortable HTML with xls option (if enough time); Columns:
  • CT# (hyperlink)
  • Client
  • Days since closed

GMS functionality

Prerequisites for GMS calculations

In order to calculate GMS Split we need the following to be defined for the record:

• OO
• EO
• IO
• TO
• GMS ratio
• GMS schedule

Owners Office

Owners Office (OO) is a field (attribute) that identify what Jaguar office is the OO for particular Client Company - see Client Companies.

Relationship is one to one.

Add this to "Part A." section on UI.

Make sure changes are posted into Log.

Import, Export and Third Offices

EO, IO, TO are properties of CT and set on Gen Tab.

GMS section in Admin

Add number of configuration options - see below.

Add under Acc > GM Split.

GM Split Rules

See table below.

%-ages must be stored in the system.

Need a view of current %s.

User could edit %s.

One table is for default values and one for Client Company specific are required.

Add this as a property into User Access table.

Add changes to log.

GM ratio

More than one "GM ratio" (“percentage model”) could be applicable - more than one table as in Fig above could be defined.

Each case should have a name (optional, need textbox for that) and id generated by the system.

We should have one default "GM ratio", and then a number of alternative "GM ratio" (same scenarios, just different percentages). By default a Client Company would be subject to the ‘default’ model.

It means that "GM ratio" is a new property for Client Company entity.

Make sure changes are posted into Log.

Schedule for GM Split calculation

For example it would be possible to say that GM Split calculation will happen once a day at 17:00 EST

Credit to the office

Per Karen this is no longer needed

Limitations on pending GMS and closed files

Not required at least for this release

Log for GMS Admin Changes

Post all changes into Log.

Access Rights

Have only one item in User Access Rights table regulating GM Split Admin (all tabs).

GMS status

GMS (Global Marging Split) Statuses:

• n/a

-GMS status for CTs that have OC status "closed before 2012". Need script - see below.

• not ready

- default status for all new CTs

• pending

- these CTs will be included into the next run of GM Splitter

- this status is set by #OC Process

• completed

- after system runs Global Margin Splitter on this CT system successfully must change status to "completed"

- set by GM Splitter

• error

- after system runs Global Margin Splitter on this CT system unsuccessfully (example: CT does not fall under any of GMS case)

-set by GM Splitter

Tech Note
---------
Need to run script that will set  n/a: closed before 2012  for all CTs that have OC status "closed before 2012".

GMS Splitter Process

This process runs periodically for example once a day.

Exact schedule would be defined here: #Schedule for GM Split calculation.

Steps for GMS Splitter

• Look at all CTs with GMS status = "pending"

• See if CT info is complete/correct:
  • OO is defined
  • OO/IO/EO/TO combination falls under cases defined in GMS Admin

• If info is complete/correct then:
  • calculate GM Split - see #GMS Algorithm
  • issue invoices - see also #Invoices generated by GM Splitter
  • post results into DB

• Else set GMS status = "error"

GMS Algorithm

• For every CT (subject to this algorithm):
  • identify what GM case it belongs to (based on OO, IO, EO, TO values)
  • calculate based on % defined in #GMS Section in Admin

Note: take into account previously issued internal invoices.

Example 1

Example 2

Example 3

Example 4

Invoices generated by GM Splitter

Number of invoices

There should be limited number of invoices issued each time Runner runs. It corresponds to num of unique pairs from the list of offices. In 2012 it would be:

• NY/HK
• NY/Lon
• NY/Par
• HK/Lon
• HK/Par
• Lon/Par

So every time it runs between 0 and 6 Consolidated Invoices would be generated.

Two types of Internal Invoices

System would continue registering and generating old types of Individual Internal Invoices (per CT or Group).

They would be generated automatically by the System.

Layout would stay the same.

Old functionality related to these invoices would be preserved (Inv Tab, P/L Tab, SearchInvoices, etc).

At the same time new Consolidated Invoices will be generated as well (by GMS Splitter).

Invoice numbering

New consolidated invoice should follow "old" sequence (as defined in Acc_CT_Tabs_Sales_or_Internal )

Individual Internal Invoices (per CT or Group) would follow this pattern:

<Related Consolidated Invoice>"-"<CT#>

Consolidated Invoices pattern:

"IIGMS"<office code><sequence>

Example:

Assume GM Splitter discovered only 2 CTs that are pending GMS.

• for CT#555 office NY owes 10USD to office HK and
• for CT#888 office HK owes 20USD to office NY

System would register:

• one Consolidated Invoice IIGMSNY12345 from NY to HK for 10USD.
• and two Individual Invoices:
  • IIGMSHK12345-555 from HK to NY for 10USD
  • IIGMSNY12345-888 from NY to HK for 20USD

Timing

Both Individual and consolidated invoices will be generated at the same time.

Layout

See mock up below.

CT Tabs

Inv Tab

Add link to related Consolidated Invoice.

P/L Tab

No change required I assume.

Existing Acc Reports

We are changing the way we handle Internal Invoices. This could affect or even break some of the existing reports such as PnL Report for Multiple CTs (summary and detailed view).

Search Inv Report

P n L for Multiple CTs

Browser for Consolidated Internal Invoices

This module should provide basic capabilities to browse Consolidated Internal Invoices issued by the system.

We need at least core filters:

• issuing date: from/to
• issuing office

Paging and sorting are required.

GMS Misc

Display OO, EO, IO, GMS Status, GMS Case on Gen Tab

See mock up below, Red Box B.

UC: How to apply new GMS split rules to GMS completed CTs

'!!! Spec changed !!!

This is the case when we want to change GM Split %ages and apply them not only in the future GMS runs but also recalculate for CTs that have GMS status completed.

This can be achieved by changing OC status for such group of CTs from closed to open to closed. This will force GMS status to be "pending" and next time GMS Runner runs it will re-adjust GMS for these CTs.

This can be done just by user - no programming required.

Create DR report to identify all new shipments without an Owner Office

0003490: [GM Split ] Create DR report to identify all new shipments without an Owner Office

Info for E0 estimate

Core need: To identify early CTs that have Client Companies that do not have Owners Office set

• Level one: counter
• Level two: xls with 2 columns - CT#(with link) and Client Company