All organizations have assets that are part of the company such as electronics, vehicles, and tools. These are not to be confused with inventory that the company resells (which would involve the 'Inventory' module) to customers. The 'Asset' module helps to track and maintain all the equipment and other possessions of the business.

Tabs

Each module will contain several tabs that help group the various types of associated information. Below we will cover the details of each one currently available in the latest release of the module.

?

This tab is found in each module as the way to access helpful documentation and, when clicked, will load this wiki page for the module. Of course, you can always go directly to our wiki and read through the entire software documentation.

#

Not quite as prevalent as the '?' and 'General' tab, this one presents the user with a list of all the assets currently cataloged for the company. The page is setup to have a table layout that can be filtered using the textboxes and listboxes toward the top of the page. The more of those filter objects are used, the more specific the results are in the table. To load any of the assets that are shown in the table (regardless if the filters are used or not), simply click on the serial number of the item.

General

Also found in most of the available extensions, this tab provides the general information associated with the module. Below you will find the details of each field available on the form.

Serial number As the name suggests, this is the serial number of the item. This textbox also doubles as a submission field where you can enter in the (partial) serial number and all matches will be shown in a selectable list which will populate the tab data upon clicking the desired item in the list.

Short description This value allows you to enter in a brief description of the asset.

Tag As a way to provide a little flexibility, webBooks allows a company to use this field to store some particular information relevant to the company for the asset.

ID Code webBooks has the ability to convert assets into inventory due to the fact that sometimes a business has run out of stock of a particular sales item but can use one of their own assets in its place. This will obviously only be applicable to a certain percentage of your assets. If the asset doesn't belong to any ID Code, you can leave the default value of '_NOT APPLICABLE_'.

Vendor To keep track of where the company assets have been purchased from, you can optionally specify a vendor for this field value. If the product was purchased from someone other than the vendors stored in webBooks, you can leave the default '_NOT APPLICABLE_' value.

Current location There are two values that can be selected for this field - business location or customer location. The prior value specifies that the asset is currently installed somewhere within the business. The latter specifies that the asset is currently being used at a customers location. Depending on the selected value, the following field will have its list dynamically changed to indicate the exact location or account where the asset has been installed.

Account As mentioned above, when that value changes, the values in this list are updated as well. If you selected 'Business location' above, then this list will contain a fixed value of '_HEAD QUARTERS_' as well as all the additional locations you entered in the 'Business Configuration' module. If the above field was set to 'Customer location', then this listbox will contain all the customer accounts. It is important to note that when this value is selected, the phone, fax, website, and address fields below will be populated with their information, but will be read only.

Phone & Fax These are the contact numbers for the selected 'Account' from above.

Website Also related to the 'Account' selected above, this is the associated website.

Address As the name suggests, this is the address associated with the selected 'Account'.

Location details Once you have selected the where the asset is located at, this value will provide the specific details of where the item is stored onsite. You might list something like 'server closet' or 'Daves office'.

Asset owner To help keep track of assets, this field allows the company to assign ownership of items to a particular employee.

Contacts This column reflects the contacts that are associated with the selected 'Account' value. This way the user does not have to go back and forth between modules to lookup the associated people in case they need to be contacted in regards to the asset.

Associated info The assets created in this module can be transformed into other module data. For example, assets can be converted into inventory items. To convert an asset into some other type of data, select the target format in the top listbox and then click the '+' button. Once the conversion has been made, you can double click on any items in the combobox to have the respective module load with the converted data.

Notes

Also found in many of the modules for webBooks, this tab allows co-workers to add notes to your account. Most likely the ones adding information here will be managers, but for flexibility anyone can add notes (access should be defined by company policy). There are only three fields on this page with the 'Creator' and 'Note' values being self-explanatory. The first field, however, may need more details. This listbox is used to define who has access to the note being entered and contains two fixed values along with any number of dynamic values. The two fixed are '_EVERYONE_' and '_MANAGERS_', meaning that either everyone can see the note being entered, or only employees who have the 'Manager' flag set for their account. Any other value in the list will be a dynamic value that corresponds to each department you have entered on the 'Business Configuration' module. This in turn will restrict access to the note being entered to all employees that work in the selected department.

Specs

Sometimes a user will need to check certain information on a product. This tab will help with that problem and has three columns that deal with three different types of specs. Working from left to right, the first column presents a standard set of specifications that deal with the asset, the next column deals with specs that were set by the vendor, and the final column defines any further details about the item that are of interest to your organization. With this many fields to store part information, you should be able to store all the information you will need at any point in time.

Data

Another tab found in many of the modules in webBooks, this page allows you to upload various data that you feel is important (or necessary) to keep on file for a particular record. You may see several default items that you can use, but you also have the ability to dynamically add any number of additional fields by clicking the 'Add new Entry' button. This gives you a way to name and select each added entry.

There are two different ways that you can upload your files. The first way is by simply clicking on the upload box itself. Please note that if you are using this way, you can click the checkbox in the lower right-hand corner to select multiple files at once. Contrarily, you can also use a file manager to drag-n-drop file(s) onto the upload box. Either way will create an icon (with progress meter) for every file you are currently uploading. After you have uploaded at least one file, you will be able to select the file from any of the listbox entries. And after performing those steps, click the associated 'Update' button.

You may notice two additional buttons next to the 'Update' buttons. These remove the entry and encrypt the file respectively. Currently the encryption button is disabled as this feature will come online in a future version.

History

You may also notice this tab as the final tab on many modules in webBooks, and it keeps track of all the history details that deal with a loaded asset. In order to add a line to the history, you will need to specify a date when the action occurred, the action that occurred, associated tag information (this will dynamically change depending on the action selected), and a note that corresponds to the selected action. After filling all of that out, simply click the '+' button towards the top of the form and the line item will be added to the details list at the bottom.

The list allows a company to define various bits of information on the asset so that its history can be reviewed at any time. To see examples of the entries that pertain to various common actions, see the below [section]. We will now cover each of the possible detail types, but it is important to remember that these can be used for other purposes than what is described below and that the associated tag values are all optional. Also, any below types that mention being used by various modules do have specific functionality. And, unless otherwise mentioned, what correlates the various history details will be the tag values and/or the serial numbers.

Purchased: As the name suggests, this value is used to identify several bits of information for the purchased asset. The associated tag value should be the invoice or receipt number of the vendor that sold the product. If you would like to keep track of the vendor who sold it, you should add that as part of the optional note.

Installed: This detail type should be used when an asset has been temporarily installed at a customers location (since anything permanent would mean the sale of the asset). If you have the 'Work Orders' module installed, you will need to include the work order number as the tag value here so that you can relate those two pieces of information.

Leased: Currently this is mainly used for the 'Inventory' module, but has been included for completeness in the event that an organization wants to use it in this module.

Prepped: If your organization has any prep work that needs to be done before an asset can be used, add this history detail to explain that work. The tag value can be anything of relevance to your company.

Queue: This is a general purpose detail type for use as a general queue for anything your organization does. Like the 'Prepped' value, the associated tag value can contain anything of relevance to your company.

Returned: Used as a way of keeping track of when leased items are returned, this entry is mainly used for inventory items, but was included for completeness.

Sold: As you can see, this detail type is used to identify when the asset(s) are sold. Once again, this will most likely be used with the 'Inventory' module, not the 'Asset Management' module. The associated tag value should be the invoice number of the sold product(s) along with the serial number of each.

Stocked: This history detail will usually be included in one of the top spots in the history list and indicates that the asset has been 'stocked'. The values placed in the tag can be used by other modules in the event that an asset is converted into an inventory item, or if you have the 'Accounting' module installed (to calculate the value of the company assets in the ledger). The tag value includes the freight cost and the product cost. Both of those values needs to be the INDIVIDUAL of both of those costs. For example, if the freight was $30.60 to ship the package and it contained a quantity of four items with an individual cost of $10 a piece, then the tag value for this history detail would be '7.65|10' (per-item cost of freight|per-item cost). If the vendor absorbs the shipping cost, then simply provide a '0' for that value. So in the afore mentioned example, the tag value would become '0|10'.

Destocked: Used as the opposite to the 'Stocked' entry, this detail indicates that an item has been sold. Since companies typically sell inventory and not assets, this type will most likely not be used in the 'Asset Management' module. If the organization does want to sell an asset, the desired method would be to first convert it into an inventory item, then sell it. If you do end up using it in this module, be aware that the tag value structure is the same as the 'Stocked' detail covered above and needs to contain the per-item cost for freight and the purchase price. Please refer to the 'Stocked' entry above for an example of this value.

Restocked: This particular detail type is used to when a product is returned to your organization. Again, since assets are not typically sold, this history detail most likely will not be used in this module either, but was included for completeness. If you do use it, you may also want to include several of the 'RMA' details listed below. Also, the associated tag value should be the incurred restocking fee that is associated with this action.

Inspection (queue): The 'Inspection' detail types can be used in combination with several other detail types outlined here wither as a pre or post set of information. For instance, you can use these as a first set of steps in processing an RMA in order to inspect the returned product(s) before processing any further. In another example, several of these 'Inspection' details can be used in the post-processing of a repair (e.g. using the 'Inspection QA'). The tag value for this type can be anything that is meaningful to your organization. Also, the serial numbers of each product being inspected will need to be entered.

Inspection (initial): Sometimes a company will need to conduct an initial inspection before completing any necessary work. This detail type is used for that very purpose. Again, since this is another general-use item, the tag value can be anything meaningful to your company, but the serial numbers of each inspected item will need to be entered.

Inspection (pass): Used as a complement to the other 'Inspection' details, this indicates that the inspection passed successfully. As with the other 'Inspection' types, the tag can be anything of value to your organization. Once again, add in all the serial numbers!

Inspection (fail): Similar to the 'Inspection (pass)', this detail type indicates that the inspection failed. The serial numbers will need to be entered for each failed inspection, and the tag value can be anything.

Inspection (QA): This history detail type will typically be used as a final step in some type of process and indicates that a quality assurance has taken place on the product. As with all the other 'Inspection' types, the tag value can be anything, but the serial numbers will be needed for this one as well.

Lost (request): Unfortunately things can get lost and this is a way to track this unintended event. If your organization is large enough that there is a series of people that are involved with processing these history details, then this will be used as one of the first steps to completing a company loss. This is also an general-use detail type, so the tag value can be anything. The serial numbers will be necessary though.

Lost (approval): As mentioned in the preceding history detail, if your company has a multi-person sign-off for processing a lost inventory item, this value can be used to indicate that the lost request has been approved. If your company is small and only has one person that approves lost items, this can be the only detail used for processing any lost inventory. The optional tag value for this history detail can be an approval number if necessary. Be sure to include the serial number of each inventory item that has been approved as being lost.

Lost (denial): If, for some reason, a lost request is denied, use this detail type to indicate that. The tag value here can be any value you wish, but be sure to include the appropriate serial numbers.

Repair (queue): Some organizations will perform repairs on the products they sell, or perhaps that's all they do! This detail type can be used to indicate that a repair of an item is going to begin. Include the serial number of each item to be repaired along with an optional tag value. It should be noted that some companies may want additional checks before a product goes into the repair queue. In that instance, you can use the 'Inspection' values listed above for any pre-processing of those items before beginning this step.

Repair (started): As the name suggests, this value can be used to indicate that a repair has started for a particular inventory item. Don't forget to add in all the serial numbers and an optional tag value.

Repair (halted): At times a repair will need to be halted for various reasons (e.g. lack of replacement parts, availability of a repairmen, etc). This history detail will allow a company to see that progress was paused, and by using the optional note, they can see why. Be sure to include the serial numbers and any optional tag value your company requires.

Repair (completed): After a successful repair, use this detail type to indicate everything is finished up. Again, some companies may want additional checks afterwards. As a result, some of the 'Inspection' details (e.g. 'Inspection (QA)') can follow this one as a means of making sure that the quality of workmanship is to the level required by the organization. As with most other history details, be sure to enter the serial numbers and optional tag value.

Repair (unrepairable): Sometimes a product can not be repaired, and in that scenario this detail type can be used to indicate just that! This is another generic-use value, so the tag value can be anything meaningful to your company. The serial numbers will need to be added for any correlation of prior history details though.

RMA (request): If a product is damaged or needs to be returned for some reason, typically a business will require the customer to get a return merchandise authorization (RMA) number before any processing can occur. As mentioned above, if your company has multiple people that are required in order to get an approval, this should be one of the first history details in that process. On the other hand, a small company can simply use the appropriate values below. This tag value is optional, but the serial number of each item in the RMA should be entered.

RMA (approval): Once the appropriate staff has approved the RMA, this detail type can be used to record that decision. If your organization requires approval numbers, then enter that as the tag value here. This may also be the RMA number that is given to your customer, but it doesn't have to be. You will, however, need to enter the serial number of the product(s) that apply under this RMA.

RMA (denial): If the RMA is not permitted for some reason, include this as part of the products history. It may also be advantageous to enter a note as to why this RMA was denied. The tag value can be anything of meaning to your company, but you should enter the serial number of each denied item.

RMA (replacement): Unlike other history details where you can combine multiple items (via their serial numbers) to a single entry, this item should contain a one-to-one ratio. This is because the tag value needs to include the original RMA product along with a single serial number added as its replacement.

Shipping (queue): If your organization needs to ship some products out, this entry should be one of the first that gets added to the history. This detail type indicates that an invoice or work order has been created that require at least one product. The tag value should actually be the invoice or work order number. At this stage, there won't be any defined serial numbers, so they can be skipped.

Shipping (error): Unfortunately, some times packages don't make it to their destination. In those instances, this detail type should be used along with an optional note that provides more information about the shipping error. As with all the other shipping entries, the tag value should contain the tracking number of the package. The serial numbers are optional.

Shipping (sent): Used by the shipper, this detail indicates that the shipping process has begun (e.g. obtained a tracking number and alerted their courier about a package pickup). At this point you should have a freight tracking number which should be entered as the tag value. The serial numbers for the products being shipped should also be available so they should be included as well.

Shipping (transit): This step indicates that the courier now has possession of the package with it being in route towards its destination. To correlate this shipping step with any others, the tag value also needs to be the tracking number. The serial numbers can be omitted since the tracking number will bind these together.

Shipping (received): As the name suggests, this will most likely be the last step in the shipping process and indicates that the package has been received by its intended recipient. Once again, the tag value should contain the freight tracking number so that all the used shipping entries can be associated with one another.

Surplus (queue): Although these detail types are mainly geared towards the 'Asset Management' module, it could be used for the 'Inventory' module as well (e.g. for a defective product or a product that can't be sold). Using this type indicates that certain products need to be disposed of and adding this entry will begin that process (if your company has multiple employees that are involved in completing a surplus of products). The tag value can be anything of meaning to the company, but the serial numbers of the products should be included.

Surplus (request): Just like several other types discussed, this entry can be used if multiple employees are required to approve a surplus. The tag can be anything, but to help tie in the various surplus entries, the serial numbers should be added for this history detail.

Surplus (approval): This will obviously be the approval of a 'Surplus (request)' and can optionally take an approval number as the tag value. Once again, to relate the various surplus entries, you should include all the included serial numbers.

Surplus (denial): As the name suggests, this is a denial for a 'Surplus (request)'. The tag can be any value, but the serial numbers should still be included.

Other: This option was included as a generic entry since we are sure that some organizations will require more history detail types than what is currently available. Using the optional note along with a common tag value and serial numbers list can help keep employees aware of the function of this entry. If your company needs additional entries, please contact our staff to see about having them added to the official version of this software!

Buttons

The buttons located in the header of each form will be covered below (see the respective sections above for inline buttons).

Copy (General)

Since this module deals with individual items, users will find out that at some point you will most likely end up creating a record for similar items. For example, if the business has ten employees that all use the same make and model of a computer, then those ten devices will carry the same information with the only exception being a different serial number. In that scenario, this button will help save time by simply loading the asset you would like to copy and then clicking this button. The user will then be prompted for the new serial number followed by another prompt asking if you would like to also copy the information found on the 'History' tab. This second prompt was added just in case the history information is the same between the two assets. Going back to the example we referenced above, if all ten computers were purchased at the same time, then they will at least share a portion of the history details (e.g. shipping, stocking, etc). However, if some of the computers were purchased at different times, you can choose not to copy the history details, and instead, enter the history that is specifically for the asset (e.g. different purchased dates, different shipping info, different stocking values, etc).

NOTE: when copying assets, the 'Notes' tab information is excluded during the copy no matter what.

Clear (General)

Clicking this button will clear all the tabs loaded data so that you can create (see the 'Save' button below) or load another record (see the 'General' tab above).

Save (General)

One of two buttons available in the header of the 'General' tab, click this button once you have filled out all available fields to save or update a new or existing asset. It is important to note that this ONLY saves information listed on this tab - no others!

Save (Notes)

The 'Save' button on this page will add the note to the list.

Save (Specs)

Just like the other 'Save' buttons, this ones saves all the information with in the tab.

Common Tasks

The below sections cover several common tasks that a user may need to perform at some point in their interaction with the software. These will be expanded as time elapses.

Creating a New Asset

When opening this module, the form comes up ready to load an existing asset or to create a new one. If you currently have an asset loaded and want to create a new one, simply click the 'Clear' button within the header. Otherwise, all that is necessary to create a new asset is to fill out the (cleared) form and click the 'Save' button at the top of the screen.

Copying an Existing Asset

It is not uncommon for an organization to have several of the same asset (e.g. computers) and because of this, webBooks provides you the ability to quickly copy an existing asset so all of the same information doesn't have to be re-entered. To accomplish this goal, you simply load the asset you want to make a copy of and then click the 'Copy' button in the header. You will be prompted to enter the serial number of the new asset followed by a prompt asking if you want to copy the history details as well. It is important to remember that clicking the 'Cancel' button of the first prompt will cancel the copy, however, clicking the 'Cancel' for the second prompt means that you do NOT want to copy them (not cancel the copy)! After a successful copy has been made, you can now load the new asset and make any specific changes or additions to that particular record.

History entries of an asset purchase

Organizations acquire assets all the time so the below entries will most likely start the history details list for each asset acquired. All of these entries are optional, but obviously the more you enter, the more information you will have to review at any point in the future.

Purchased: this history detail begins the trail of information associated with the purchase. Adding a history detail with this option allows you to enter the date, quantity, and vendor invoice or receipt number along with an optional note (possibly defining the vendor that it was purchased from or any other valuable information for your organization).

Shipping (sent): this detail indicates that the vendor has started the shipping process (e.g. obtained a tracking number and alerted their courier about a package pickup). The additional tag information for this action specifies the tracking number assigned by the freight company. This will allow tracking the shipment until it is delivered. You can safely skip all the 'Shipping' entries if the asset was picked up instead of begin shipped.

Shipping (transit): Once the courier has picked up the package, this detail can be used to acknowledge that step in the shipping process. To keep track of all the freight entries, this one utilizes the tracking number as the tag value.

Shipping (received): this history detail outlines when the package was received by your organization. The associated tag information here is also the assigned tracking number from the freight company so that you will know that individual status of each package being received.

Stocked: this detail has uses outside of just being part of the assets history and allows the user to define the freight and product costs associated with the shipped package. Other modules use this specific history detail for various reasons. For example, if an asset gets converted into an inventory item (via the 'Associated info' listbox on the 'General' tab) at some point, that module will use this history detail to determine a product cost (included assigned shipping costs) when the product gets sold.

History entries for a lost or surplused asset

There are times when assets become unwanted by the company or either gets lost, or sadly, stolen. In those instances your organization will need to add history details to indicate that this has occurred.

Inspection (queue): if the asset(s) have become lost and management is interested in having an inspection performed to see if they can be located, then you can begin the history details for this action using this entry. Otherwise you can safely skip all the 'Inspection' entries. It is important to note that tag value should be the same for all of these entries so they can correspond to one another.

Inspection (pass/fail): if the asset(s) were found, then a simple 'Inspection (pass)' entry can denote that they were found, otherwise you should use the 'Inspection (fail)' detail to indicate that nothing was found. Again, this entry is optional but should use the same tag value as the previous history detail.

Lost (request): if your organization is large enough to require multiple peoples approval before the below entry can be added, then use this one beforehand. Be sure to use the same tag value here as with the previous entries so they can be related.

Lost (approval/denial): this is the only entry that is "required" in order to designate lost assets. As stated in the above detail, if your company is large and requires approval, then you should use that value as the value for the tag here. Otherwise, you should use the same tag value as all the previous entries.

NOTE: if the asset(s) need to be surplused instead of recorded as being lost, then you can use the the same layout as described above just replace each 'Lost' entry with the corresponding 'Surplus' detail.

History entries for RMA's

Hopefully your organization does not have to process too many RMA's, but in the event that you do need to accomplish this task, then you can use some or all of the history details below. If you have several items to return under the same RMA, you should add any of the below records per item, not as a group! Also be sure to include the serial number for each entry added.

RMA (request): this is where the process starts and is usually submitted via the vendors website or a call to their staff. Although this entry more or less acts as a time stamp of when the request was made, you can also supply any additional information as the tag value.

RMA (approval/denial): based on the information given to the vendor, the RMA request can be approved or denied. A denial at this point will obviously stop the process from continuing. In that event, be sure to use the same tag value associated with the above step here so that the two can be related. Otherwise you can use an approval number for that value.

Shipping (sent): if your organization is mailing the package back to the vendor, you can use this history detail to record that information. As mentioned above, this detail indicates that the shipping process has started (e.g. obtained a tracking number and alerted their courier about a package pickup). The additional tag information for this action specifies the tracking number assigned by the freight company.

Shipping (transit): once the courier has picked up the package, you can use this entry to record the relevant information. The tag value should also contain the tracking number associated with the package being shipped.

Shipping (received): this history detail should be added when the vendor receives the RMA'ed package. Just like the previous 'Shipping' details, the tag value needs to be the tracking number so all these records can correspond with one another.

After the vendor has repaired the returned item (if it is repairable), you can add the necessary 'Shipping' entries for its return trip back. On the other hand, if the item could not be repaired, then you should still add the return 'Shipping' details followed by the below entry.

RMA (replacement): if the returned item(s) could NOT be repaired, then a replacement product should be sent back. In that instance, add this item to the history details list using the serial number of the replacement product as the tag value.

webBooks-Asset Management

Contents