This functionality is working as of 7/20/2020

April 4 - 7 - 3.5 hours on mapping locations.

March 2nd to 7th - 11 hours

View of Aggregate Vendor ID with mapping to Transactional IDs 

2 hours

1.5 Hours planning the Vendor Data Table Layout

Goal - Display the Aggregate ID next to the many Transactional ID's

Notes: cross_corp_enterprise_mapping.cfm

Looping over the Transactional IDs and try to match based on the Hard Coded name value.

6 hours building out the drop down to tie the aggregate ID to the transactional ID's

2.5 hours on the display card.

Using the cross corp mapping table to hold Aggregate ID to Transactional ID's for vendors by conditioning the table_name to 'master',

the app_type_id to 9, and then JSON string holds the list of Transactional ID's that can be updated.

Card View that Identifies 

1 Aggregate (Top Level)  Corp ID

Unlimited Transactional (Lower Level) Corp ID's

Builds a list to pass to the mapping page where these are displayed horizontally per vendor. Looped Table View with filters.

A small window opens an allows mapping per Aggregate Corp vendor to Transactional Corp(s) vendor. 

Page then process all mapping points at the same time.

3 hours on 02/06/20

2 hours on 02/07/20

cross_corp_enterprise_vendor_id_builder.cfm

This pops out a new window that sort the vendors to aid in the selection mapping, trying to automate the process.

A phase 2 would be adding in a match if this occurs. JavaScript or Ajax

cross_corp_enterprise_mapping.cfm

Met with Brandon to plan out the mapping page. 

1. Report that returns Top Level Corp (Aggregated) and Sub Corp (Transactional) as well as app type ID (Vendor)

2. Show Mapping

2 hours working on mappings so that all Vendors over all Corps will be mapped via ID instead of hard coded. 

App Type ID's

Brandon and I meet and reviewed the table that will hold all the ID's

This is the cross_corp_mapping table

It has 12 columns that we will be using to map the Aggregated Corp to the Transactional Corps

Name Type Null Default Extra Index

cross_corp_id int(10)   auto_increment

corp_id int(10) unsigned

app_type_id tinyint(1) unsigned

main_id int(10) unsigned

sub_id int(10) unsigned

table_name varchar(100)

corp_id_2 int(10) 

app_type_id_2 tinyint(1) 

main_id_2 int(10) 

sub_id_2 int(10) 

table_name_2 varchar(100)

json_value text

Brandon suggested using locations in place of categories, what about using Corp ID? or is this the same as at the 

Enterprise level as 'Location' would be the Transactional Corp ID or Name.

Idea - A Corp Type in the settings, default 'Transactional' with 'Enterprise' as choice.

            Or allow dynamic naming (Phase 2).

Idea - A Corp ID String, those systems associated (tied to) with each other. 1 would be the Enterprise system and the others Transactional

Idea - A top level setting that allows for this Corp Type to drive functionality in both the Enterprise and Transactional Systems

Question - Inventory must be consistent, thus Vendors and Items need top level 'Control'. So if the Corp Type is Enterprise the master 

list of Vendors would exist there and all Transactional Systems must conform. This would be better than mapping as new vendors are 

added and edits take place. Items would follow.

Enterprise System - Parent or Top Level System - The One

Transactional Systems - Child or Lower Level Systems - The Many

Goal is to allow the Transactional Systems to function naturally, processing all normal day to day transactions for the unique 'location' as the Enterprise functionality rolls up the transactions or rolls down relevant transactions or edits. Bi-Directional

• Inventory Purchases - Inventory, A/P, Payments - Totals Roll Up?
• Daily Sales - Totals Roll Up
• Expenses - Totals Roll Up

PDF Link