all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||
|
|
|
Blue
|
|
|||
|
|||
|
|
|
Notes:
|
|
-On inline custom code – we could technically even switch domains, scripting languages, and traverse databases. We could use Asp.net, Ruby, Php, Java, etc. If someone wanted to, they could make a local code set that could run locally and then batch update a server. Tons of options. -Once we have an open API and/or custom inline code and corp-wide settings and corp-wide permissions. It may be worth our time and money to become certified as an official shopping cart and get on people’s radar as a certified solution or platform. -This may or may not happen, but it may be fun to take adilas to the open source level. -On pages – it would be cool to control the navigation links, buttons, and options. This could either be corp-wide settings and permissions or user settings and permissions. Or, I suppose, it could be a combination of both personal and corp-wide. -On parts categories – it would be cool to have a graphic tied to the category. It would also be cool to allow and show counts of what you had. For example: Accessories (7), Men’s Shoes (26), trailer parts (137). -I’m thinking of leaving the web (general customer side web site) presence on a remote server. If the companies want to use eCommerce, pull it back under the main adilas.biz roof. The web presence would be free and eCommerce would be variable, depending on the corporation. Variable meaning setup cost and/or fees. It may also depend on usage or quantity of items. -On eCommerce, maybe have levels… under x number of items we do it for free. Over x number of items we charge a small fee or add it to your monthly. -We may need a way to monitor eCommerce activity. This could be invoices created, quotes made, statements made, payments made, items or parts, etc. -eCommerce may need special settings for sub domains, load balancing and access. -When migrating to stand alone databases and systems maybe consider: - Integer field sizes - 10 vs. 11 - Database storage engines - MyISAM vs. InnoDB tables - Inter-corp actions and assignments - Customer settings for look-ups and drop-down menus. - Use of corp_id even though each corp will be a standalone. This value may be needed later on if doing a multi-corp look-up or report. -On getting corp-wide settings – that method or function may need to be broken up into smaller pieces for speed and economy. I’m thinking about a general setting, a subset (pre-set values), or a custom list (list of fields to pull). Anyways, it is starting to get bigger and bigger with more options planned. |