all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||
|
|
|
Yellow
|
|
|||
|
|||
|
|
|
Notes:
|
|
Questions & Known Issues with Code & Databases: - It has got to start at the login level. This needs to include the corp id… That will help it know where to go. - What about application wide variables and queries such as locations – maybe move from application to session scope… - It might be nice to get away from domain (cluster) specific code and have the cluster databases hold that code. Thinking of the top secret application cfm pages. There are also other pages that might be able to be controlled by a database vs. a hard coded page value. What about storing all cluster settings in a single table as a JSON object – or – do we just need to script a new table? Or do we just stay with custom code pages. - We need to kill all the old web service feeds. If we do this, we may also want to change all of the references to the web service as far as links. Remember the main link on the root index cfm page. - Known holes: o In line taxes & discounts o Image folders – need to add o Web services to older server o We could do any of these as later projects - What about back doors? - aka test page stuff. This may need a data source setting in order to play. - What about user clock in/out between corporations. This could get lost very easily with multiple database or it could be easier. Just worry about what it can find… Let the user take care of the rest. - Anything that has crop specific stuff, needs to be held at the corp or world level. Think about moving corps… it all needs to go. - WE need to figure out the payee to corp access stuff. This will include a new history record of when and how long each person visits, views, and/or does anything from inside of the world or corporation level. Most likely, this will require a new history table per corp. - Leave a footprint for every corp switch and switch back… as a note, this may be able to be accomplished by using the payee login history table and just adding a corp id to the table. Just a thought. - What about cluster specific help files? We need to put the cluster specific stuff on the actual help file page, not in the database… That will help with updates & syncs. - What about controlling last updates statuses on cluster tables. This will also help with mass updates. Think about updates from the universe and galaxy levels. Table Relationships: - Payee permission list & payee permission categories - Payee permission list & payee to corp to permissions - Additional customer types & additional customers - Adjustment pos & purchase orders - Allinv, inventory types, makes, models, sub inventory types, title accounts, allinv history, payee, invoices, payroll status, allinv subs, store location, allinv final numbers, allinv asset types, allinv floorplan, customers, customer types, purchase by types, web price settings - Allinv ages, store location - Allinv floorplan, title accounts - App types, tie in flex grid, payee, tie in flex grid history, time sub assignments, cms media main, tie in flex grid titles, custom documents, balance sheet items, financial categories, financial groups, financial group subs, store location, balance sheet subs, balance sheet photos, payee, balance sheet history - Banks, deposits, receipt payments - Check request types, receipt types, receipt, payee - Country, banks, corporations, store location Key id’s that are specific: - Allinv payments: o Ties to floorplan id, receipt number, receipt line id - All inv subs o Allinv subs rec inv - Receipt line id o All inv sub line o All inv sub type extra o 2 – receipt o 3 = invoice |