ITrack/Enterprise/Configuration

Server configuration

A server must be chosen and configured for multiple purposes. A mysql server must be installed and configured (this will usually be done by brian). The IP, port, username, and password of this server must be used to configure the database section of all clients' host.ini files. At that point, someone must create an EE database on the database server. This would usually be either me or dayton. This installation should eventually contain all 'initial data' that a new system should have. This includes part types, permissions, and make/models. Most likely this 'initial data' should be tested and added to.

A folder should be created on that server (or on mutliple servers depending on company) that will contain the report repository and another that will contain attachment and picture repositories. All clients' inis should be pointed at these locations (either through IP or mapped drive letter).

Client configuration

Each client machine should have ITrack installed, the crystal binaries, vinpower, and the MS VC redistributable. This should all be done by our support people. The computers' inis should be configured to work on the system. Each machine should be registered (given a product code) that is checked for duplication and entered into the autoupdater for future updates. This is a process that should be made more automatic as part of the registration process eventually. Also, the machine should have all desired printers added and assigned to report types in the edit->options dialog on the printers page.

Stores

One should be created for each branch. I believe these can be created through edit->options->stores. This info is stored in the store table.

User list/permissions

Pretty self explanatory, this is used to login for users, and can be configured through the "configure->users" dialog. Users are stored in the table user and their permissions are in userpermission. Users should also be given stores to log into. This can be done on the user stores tab of the "configure->users" dialog. This is stored in the userstore table.

Groups

used to categorize users, especially for permissions. Can be configured through "configure->groups" dialog. Stored in the group table (user group assignments are in usergroup and group permissions are in grouppermission).

Store/global settings

Used for various automated decision support processes in the software. Users can have settings too, but they're usually just UI preferences. Store settings and global settings essentially represent a company's business decisions embedded in the software (like: by default do you charge taxes on inherent cores, which GL category should misc items go to, etc). Almost all of these have defaults that we assume if they aren't set, though a few (like gl accounts or categories) need to be set in order for the related screen to function correctly. These are used everywhere and configurable through "configure->settings". Settings are stored in setting and the user's choices are stored in storesettingvalue.

Accounting

An accountant should visit the accounting screen at some point (probably with our assistance) and configure things in 2 batches:

1. GL accounts and GL category creation. The accounting individual should create and configure all the gl accounts they want to have in the system and all gl categories that they will use for parts, labor, vehicles, etc. These are stored in glaccount and glcategory.
2. After they understand the category/context system (a difficult undertaking without help), they can go to the categories tab and pick the accounts hit in different operations. This data is stored in glcategorycontext.

For detailed help and examples on accounting configuration, refer to the account configuration help section.

Point of sale

Other than some settings, SOs need terms, taxitems, payment methods, and sales order documents.

1. terms represent the terms of sales and they are assigned to customers and SOs and used to assess finance charges. They are stored in the term table and cannot be created anywhere through an interface (yet).
2. taxitems represent a tax schema that can be applied to a SO. They can be assigned to SOs, external WOs, POs, and customers. Taxitems can be configured as 'customer taxes' or not. Customer taxes are tax liability accounts that you have to pay the gov for and they may have different accounting from those taxes you use on POs. Taxitems are stored in taxitem and can be configured on the tax items tab of the edit->options dialog.
3. payment methods represent the discrete methods in which a company is willing to credit a customer's account (most of which represent actual payment). Payment methods are given to payments, and also assigned to customers as allowed payment methods (stored in customerpaymentmethod). They can be configured on the payment methods tab of the edit->options dialog.
4. sales order documents represent discrete points in a SO's lifecycle or logical distinctions between types of invoices (e.g. counter sale, internet sale). These are stored in salesorderdocument and get assigned to salesorders. There is no interface for creating these currently.

Adjustment types

Adjustments are monetary values applied to transactions to affect their total or balance. These have accounting associated with them, so they must be configured accordingly. The system has 3 hard-coded adjustment types that it uses on payment entry and finance charge areas. In addition, the user can create as many other adjustment types as they wish specifying whether they appear on SOs, POs, or both and associating a name, description, code, and gl account with them. These can be configured through configure->adjustments dialog and are stored in adjustmenttype.

Region data

This isn't 100% required, depending on how quickly the customer wishes to start creating store regions for store credit attribution or sales regions for salesperson credit. Firstly, accurate city lists for a state are hard to find, so we only do the states that people request. Once this data is found, it is pushed into the city table. Using configure->regions->sales regions and configure->regions->store regions, the user can assign citys or entire counties to abstract 'regions'. These regions can, in turn, be assigned to a salesperson or store. Based on these addresses, customers will default their store and salesperson based on their city/state and whatever region that falls into. This is just a default though, and customers can have their store or salesperson reassigned. This data is stored in tables region and city.

Inventory data

We ship with some inventory data, but customers usually have their own ideas and specific domains requiring custom data here. Data that can be configured is part types, manufacturer/models, make/models, categories, teardowns, and customer unit types.

1. Part types are encouraged to stay the same so that there isn't a problem importing into HTP.net, but a customer should create what makes sense for them (at least by disabling parttypes that don't work for them). In addition, a single whole unit part type is not usually sufficient, so clients are encouraged to create more whole unit types as they see fit. This can be configured on the part configuration screen on the parts list tab. The data is stored in inventorytype. There is also inventory Q&A (extra user-defined data) that can be created per part type by clicking on "Edit Part Questions" on the parts list tab on the part configuration screen. This is stored in inventoryoption.
2. Manufacturers and models are pretty important in the interchange branch of EE, as it is how we define what things really are. They are dependent on a particular part type. This data most likely will be imported for most users, but who knows. Its stored in tables manufacturer and model. Models can also be assigned category specifc pricing defaults on the inventory models tab of the part configuration screen by checking the edit prices checkbox and selecting a particular model. This information is stored in modelcategorypricing.
3. make/models are for vehicles. Eventually, we'd like this data to simply be stored in the manufacturer/model list for whole unit part types. I think we pretty much ship a standard list of data for this with our install, but a customer might want to customize. This data is stored in vehiclemodel I believe and can be configured on the vehicle models tab of part configuration.
4. Categories are user-defined ways of describing parts. They are defined on the categories tab on the part configuration screen. After they are created, they can be assigned to part types. This information is stored in the category table.
5. Teardowns are only necessary for those yards who take whole units and part them out (like ACME). Teardowns are also somewhat similar to the category concept, as they allow you to categorize your vehicles. Vehicles inhererit a teardown based on their make/model (teardown type can be assigned to vehicle models). Teardown types can be given a list of part types that represent the list of parts that can be taken off of a vehicle of that type when they do a teardown. In addition, the user can define vehicle Q&A here (extra vehicle options that the user can fill out). This data is configured on the teardowns tab and stored in the tables teardown and teardowninventorytype.
6. Service units only need to be configured if the customer plans on doing external WOs and tracking their customers units (which represent shit the customer has/can brought in to have work done). The user can create unit types (stored in customerunittype) and assign 'options' to them (like Q&A) which is stored in customerunitoption and customerunitoptionchoice.

Inventory maintenance

The inventory table can be configured so that the company can configure what columns can be searched on the search screen, which log changes when they are changed, etc. This data can be configured from the part modification screen by clicking on the manage columns button. This data is stored in inventorysetting and inventorysettingjoin.

Pricing

There are several areas that can be configured to affect inventory pricing. Firstly, there is the 'sell price class' that can be assigned to specific inventory records. These assignments allow customers to be given discounts on all parts in a particular sell price class. I don't think there is an interface for this, but they are stored in the sellpriceclass table (they can even have a heirarchical relationship). In addition, vendors can pricing classes and purchase classes. These classes really just specify defaults for inventory items you stock from that vendor, and only really are necessary once you start entering new parts (replenishable parts). This can be configured on the inventory tab of the vendor information screen. While they're there, they might as well specify ordering groups for the vendors, which define categories to purchase vendors for doing mass suggested orders.

Customers and vendors

Customers and vendors can also have Q&A. They can be configured on the additional info tab of the customer information screen and vendor information screen. This data is stored in customeroption and vendoroption.

Shipping methods

Shipping methods represent the discrete ways that stock is shipped. This has a big effect on the deliveries screen, but its somewhat broken right now, so its not too important. This data is stored in shippingmethod, but I don't think there is an interface for it.

Work orders

WOs have several things that can be configured on them.

1. work order types (stored in workordertype). These are like sales order documents, as they specify defaults for all WOs of that type. They define such things as the report to print and whether its an internal or external WO. This can be added to or updated by clicking the green checkbox button on the WO screen.
2. job templates. These are saved templates of things that can be added to WOs. This can include jobparts, job tasks, and labor. To enter template creation mode, hit the "Define" button under job on the workorder screen and hit save when you're done.