Difference between revisions of "webBooks-Asset Management"

From Cliquesoft
Jump to: navigation, search
Line 152: Line 152:
 
===Copying an Existing Asset===
 
===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.
 
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 these 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.
 +
 +
'''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, the name of the customer it was purchased for, 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.
 +
 +
'''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 items 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 the 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 management is interested in having an inspection performed to see if the lost item(s) can be located, then you can begin the history details for this action using this entry. 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 inventory item(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 inventory. 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: inventory items aren't usually surplused (assets are the typical targets), but in the event that you do need to do that, 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 returned 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 typically initiated by the customer. This can be done using a webpage where the customer is required to fill out product information or a call-in request. It is important to note that the tag value can be anything of value to your company.
 +
 +
'''RMA (approval/denial):''' based on the information given by the customer, 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. Please note that this entry is just based on the information provided by the customer to see if the product(s) qualifies for any further RMA processing.
 +
 +
'''Inspection (queue):''' when RMA'ed item(s) have been received, they are typically inspected by the organization. Adding this optional history detail will begin the 'Inspection' process as defined below. On the other hand, if your company will just simply replace the returned item(s), then you can skip the 'Inspection' and 'Repair' entries below.
 +
 +
'''Inspection (initial):''' this history detail indicates that the initial inspection of the returned product(s) have begun. At this point, no changes to the item(s) should take place, just an inspection or testing that confirms the information provided by the customer as to what is wrong.
 +
 +
'''Inspection (pass/fail):''' if the customer provided information proves to be incorrect, then you can issue an 'Inspection (pass)' to indicate that the item(s) passed inspection without exhibiting the stated problems and to stop any further processing (which would begin return shipping history details).
 +
 +
'''Repair (queue):''' if the RMA'ed item(s) received an 'Inspection (fail)' from above and your company can or should be repair those item(s), then you can add this block of (Repair) entries. Adding this history detail will alert the appropriate group to begin the product repairs.
 +
 +
'''Repair (started):''' adding this entry indicates that the repairs have begun. If, along the way, the process is halted, be sure to add in a 'Repair (halted)' entry along with a note that indicates why the repair has been halted and what is needed to resume repairs. It is important to note that this step can also begin a work order for the repair. This is not automatically performed by the software, but is a place that the employees can initiate that step if necessary.
 +
 +
'''Repair (completed/unrepairable):''' based on the outcome of the repair, one of these history details will be added. Each should be self explanatory and will result in a subsequent record as described below.
 +
 +
EITHER
 +
 +
'''Inspection (QA):''' if the previous entry was a 'Repair (completed)', then the returned item(s) were successfully repaired and can be returned to the customer. This history detail can be used as one of the final entries and indicates that the products had a quality assurance review before leaving the organization.
 +
 +
'''RMA (replacement):''' if the returned item could NOT be repaired, then you will need to ship a replacement product. In that instance, add this item to the history details list using the serial number of the replacement product as the tag value.
 +
 +
NOTE: After one of the above entries has been added, you will need to begin the appropriate 'Shipping' entries. See the prior sections for examples, or check out the 'History' section further above regarding which 'Shipping' entries to use.

Revision as of 08:52, 3 December 2014

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. For example, the following can be a common starting list of details (by action) for each asset:

Purchased: when the item was purchased along with the invoice number that corresponds to the purchase of the item from the vendor.

Shipping (sent): an optional detail that only deals with vendors that have shipped the product as opposed to an employee picking the item up. 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.

Shipping (received): another optional detail that outlines when the package was received by your company. The associated tag information here is also the assigned tracking number from the freight company.

Stocked: this detail has uses outside of just being part of the history list, and allows the user to define the shipping and product costs associated with the asset. Other modules use this specific history detail for various reasons. For example, if the 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.

Destocked: since the inbound shipping costs are calculated as part of the product costs and tallied using the 'stocked' value from above, this option allows us to track the outbound shipping costs when selling the product(s) to the customer. Aside from just storing that shipping cost, this option also stores the organizations cost of the products being shipped. This way you have a concise entry of information pertaining to the items that are being sold on a per product, per invoice level.

Installed: the action that will usually wrap up most asset history details, the associated tag information will specify the invoice or work order number that offers more details on the installation of this particular asset.

From this point, the history per asset will become unique. For example, you may turn the asset into an inventory item which will add the appropriate information to indicate this. Or perhaps the product may stop working at some point which would prompt the use of any of the 'Surplus' actions being added to the list. There are several many actions that can be used to track all sorts of information per asset and it is up to the business to inform the employees on which ones are applicable to use.



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 these 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.

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, the name of the customer it was purchased for, 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.

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 items 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 the 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 management is interested in having an inspection performed to see if the lost item(s) can be located, then you can begin the history details for this action using this entry. 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 inventory item(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 inventory. 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: inventory items aren't usually surplused (assets are the typical targets), but in the event that you do need to do that, 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 returned 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 typically initiated by the customer. This can be done using a webpage where the customer is required to fill out product information or a call-in request. It is important to note that the tag value can be anything of value to your company.

RMA (approval/denial): based on the information given by the customer, 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. Please note that this entry is just based on the information provided by the customer to see if the product(s) qualifies for any further RMA processing.

Inspection (queue): when RMA'ed item(s) have been received, they are typically inspected by the organization. Adding this optional history detail will begin the 'Inspection' process as defined below. On the other hand, if your company will just simply replace the returned item(s), then you can skip the 'Inspection' and 'Repair' entries below.

Inspection (initial): this history detail indicates that the initial inspection of the returned product(s) have begun. At this point, no changes to the item(s) should take place, just an inspection or testing that confirms the information provided by the customer as to what is wrong.

Inspection (pass/fail): if the customer provided information proves to be incorrect, then you can issue an 'Inspection (pass)' to indicate that the item(s) passed inspection without exhibiting the stated problems and to stop any further processing (which would begin return shipping history details).

Repair (queue): if the RMA'ed item(s) received an 'Inspection (fail)' from above and your company can or should be repair those item(s), then you can add this block of (Repair) entries. Adding this history detail will alert the appropriate group to begin the product repairs.

Repair (started): adding this entry indicates that the repairs have begun. If, along the way, the process is halted, be sure to add in a 'Repair (halted)' entry along with a note that indicates why the repair has been halted and what is needed to resume repairs. It is important to note that this step can also begin a work order for the repair. This is not automatically performed by the software, but is a place that the employees can initiate that step if necessary.

Repair (completed/unrepairable): based on the outcome of the repair, one of these history details will be added. Each should be self explanatory and will result in a subsequent record as described below.

EITHER

Inspection (QA): if the previous entry was a 'Repair (completed)', then the returned item(s) were successfully repaired and can be returned to the customer. This history detail can be used as one of the final entries and indicates that the products had a quality assurance review before leaving the organization.

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

NOTE: After one of the above entries has been added, you will need to begin the appropriate 'Shipping' entries. See the prior sections for examples, or check out the 'History' section further above regarding which 'Shipping' entries to use.