Latest revision as of 11:22, 16 December 2016

Unlike the 'Asset Management' module (which manages the company's assets), this module deals with the products and services that an organization sells to its customers. It keeps track of quantities, back orders, product markup, commissions, and more! There is also the ability to convert inventory items into company assets and vice-versa.

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.

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.

Products & Services

As the name suggests, this is the list of all the products and services currently available to customers.

Included ID codes

This field will need a little further explanation. Upon selecting an item from the 'Products & Services' combobox, this one becomes enabled for interaction and will allow you to select multiple items in the list by holding the 'ctrl' key and clicking on the desired options. As you will also notice, this field contains the same values as the 'Products & Services' which acts like a parent to this one and is used to specify what ID Codes should be associated with the top-level selection. So for example, lets say that you own a restaurant and you have the following items: COMBO1, COMBO2, HAMBURGER, CHICKENSNDWCH, DRINK, and FRIES. You can select the 'COMBO1' option in the 'Products & Services' combobox and then select 'HAMBURGER', 'FRIES', and 'DRINK' in the 'Included ID codes' combobox. You can then select 'COMBO2' for the 'Products & Services' and then 'CHICKENSNDWCH', 'FRIES', and 'DRINK' for this value. That will specify that when you are creating an invoice and 'COMBO1' is selected, the items 'HAMBURGER', 'FRIES', and 'DRINK' should be included (which their quantities adjusted accordingly). This is a way to group items while having the ability to sell them individually as well (since the company can also singly sell a hamburger, fries, and a drink).

ID Code

The value entered here is what gets added to the above comboboxes upon saving the form and is also what is used to identify products or services when creating invoices and work orders.

Short description

This value is used by various modules such as the 'Accounting' module to display entries in the ledger for unsold inventory for the balance sheet totals. You should put some type of short explanation here so that you can at least roughly identify the inventory item, even if it is something general such as 'Unknown accessory' or 'Unsold used tires'.

Long description

The value here is used to completely describe the product or service and is used by other modules such as 'Quotes & Invoices' when filling out an invoice. As a way to provide flexibility, there are some variables that can be used within this value so that the description can be more encompassing. For example, you may have a service that you re-bill every month with the name of the month as part of the description and instead of having to edit it before printing an invoice, a variable can be used. The syntax for a variable is a capital identifier (e.g. MONTH, YEAR) surrounded by curly brackets (e.g. {}). The ones available are listed below:

{MONTH} specifies the current month.

{MONTH+n} specifies some month in the future (from the current month) as designated by 'n'. For example, {MONTH+1} would have the next month substituted for the value, {MONTH+2} would have two months from now substituted, etc.

{YEAR} specifies the current year.

{YEAR+n} specifies some year in the future as designated by 'n'. See '{MONTH+n}' above.

{CUSTOMER} specifies the customer account name.

If any user would like to have more added, please contact our staff!

Quantities

As the name suggests, this field contains the current stocked quantity and uses a default value of 0 (meaning that you are out of stock). If you are migrating from a prior system or already have items in possession, you would need to enter the number currently on hand for this value. This works great if you are creating or updating a product, but services do not usually have quantities to be tracked. For those situations, just erase the value here altogether. This will inform webBooks not to track quantities or back orders for this particular ID code.

The other field on this line is a read-only value that specifies the back ordered amount.

Reorder method

These next three lines of fields enable webBooks to automate some aspects of your business. This particular value can enable automatic reordering of the selected ID code based on criteria specified in the following fields. There are currently three values to choose from within both listboxes on this line. The first one has:

Automatic (webBooks): If your vendor is also using webBooks and the two instances have been connected via the 'Commerce URI' and 'Commerce SID' from the 'Business Configuration' module.

Automatic (email): If your vendor is using webBooks but is not connected to yours (via 'Commerce URI' and 'Commerce SID') or they are not using webBooks, you can have your software automatically send an email to each associated vendor asking for their current price so you can reply to the selected vendor to reorder.

Manually: This option disables all automatic reordering of the ID code. However, if there is a non-zero value for the 'Reorder Criteria' section for alerting the selected contact upon reaching the specified stocked quantity, then that functionality will still persist.

The second listbox populates values based on the selection from the first listbox. All of the values will be presented below and will mention when each option will be available.

Not Applicable: This option takes no automatic action and is only available when 'Manually' is selected for the first listbox.

Priority Value: This option means that the automatic reordering will take place based on the priority value you have assigned to each vendor in your vendor list for the selected ID code (see 'Vendors' below). This option is available when 'Automatic (webBooks)' and 'Automatic (email)' is selected for the first listbox.

Lowest Price: This option will perform some intelligent processing before making an automatic reorder. It will contact all the vendors in your vendor list that have been connected to your version and will check the pricing currently offered. After it has compiled that list, it will make the necessary purchase with the vendor with the lowest price. This option is only available when 'Automatic (webBooks)' has been selected for the first listbox.

Reorder criteria

This line contains three values: the quantity level that informs the 'Reorder contact' once reached, the quantity threshold that begins the automatic reordering process, and the quantity to reorder from the selected vendor. The separation of the values means that the business has the most flexibility as well as the ability to define these parameters on a per ID code basis. Also keep in mind that entering 0 for any of these values will disable that particular functionality.

Reorder contact

Just as a precaution, the software can alert an employee when the automatic reordering process takes place. That way they can make sure that no unintended issues arise.

Price & Commission

Another line that contains multiple values with the first field containing the MSRP for the ID code currently selected. The next two fields let webBooks know how to handle commissions for any sales of the ID code with the listbox either enabling or disabling this type of payout. If that value is set to 'yes', then the final field contains the commission to pay to the employee. This field can take several types of values and include a fixed commission (e.g. '$10' would mean a fixed ten dollars of commission per sale) or a percentage (e.g. '2%' would mean a two percent commission per sale).

Markup

There are another three values on this line that are used to set suggested sales prices when creating invoices. The markup that gets added to the suggested price relates to the account type (e.g. wholesale, resell, or retail as defined in the 'Customer Accounts' module) and it is determined by subtracting the related value from the 'Price' value above. So for example, lets say that you have '$100' as the value for 'Price' and these values are '20%', '10%', '0' respectively. If the customer account is a resellers account, then the suggested price would be $90 ($100-10%).

Like the 'Commission' field from above, each value on this line can accept multiple types - a dollar amount (e.g. $10) or a percentage (e.g. '15%') that is subtracted from the 'Price' value.

Assignments

This line contains two listboxes that allow the assignment of work to a department based on the history detail that get entered on the 'History' tab. By selecting one of the values from the first listbox, you can specify which department gets notified of work when that queue gets added as a new history detail. For example, all the employees of the department selected for the 'Shipping (queue)' would have a new job show up on the 'Dashboard > Employees > Outstanding Work' section everytime that history detail is added to the list.

Discounts

Unlike the Customer Accounts module where you can assign per customer discounts, the discounts configured here deal with all products sold under the selected ID Code. This section is optional and calculates any discounts based on the 'Price' value after the 'markup' (from above) has been applied (e.g. gross value)! Please remember, that both the account discounts and the inventory discounts are independent of one another and are not a factor when calculating either value meaning that they are accumulative. There are several fields in top of this section that we will cover below:

Start: This field defines the starting quantity value for the range that applies to the discount. For instance, to create a discount code for quantities between 10-15, then you would enter '10' for this value.

End: This field defines the ending quantity value for the range that applies to the discount. Using the example given above, you would enter '15' here.

Discount: Like the 'Commission' field from above, this value can be several types of ranges that include a fixed discount (e.g. '$10' would mean a fixed ten dollar discount) or a percentage (e.g. '2%' would mean a two percent discount).

Promo Code: An optional field, you can enter a promo code that must be used before the discount is applied to the customer's invoice.

Expires: Another optional field that can be used to control when a discount can be used, this field specifies the expiration date. It is important to note that the discount can be applied as soon as it has been created, so do not use or release (the promo code) for any discounts until you are ready to have them used by your customers.

Vendors

This optional block of fields permits the user to add all the vendors (via the vendor list within the Business Configuration module) to the associated combobox. We will cover each field below:

Vendors: This listbox contains all the vendors that were entered on the 'Business Configuration' module. Select, one by one, which items do sell the ID code that is currently selected.

ID Code & Priority: Unlike the 'ID Code' referenced at the top of this document, this value refers to the vendors ID code for the same product. For example, you may sell the product using your own ID code (from the top of the document) 'XYZ123' whereas the vendor that you buy from sells it as 'ABC321'. This creates the link between your own codes and each vendors.

The second field on this line sets the priority of the vendor to buy the selected 'ID Code' (from the top of the document) when you are using automated reordering (see 'Reorder method' above).

Contact: This list is dynamically populated with the vendor contacts that were entered in the 'Business Configuration' module. Select which one will be the contact when using 'Automated (email)' as the 'Reorder method' value.

Purchase: This value defines how the purchase will be made from the vendor and is also referenced in the automated reorder email (if that is the method chosen). The second listbox specifies how tax should be handled when purchasing from the vendor.

Shipping terms: If the product(s) needs to be shipped, this listbox defines who will pay for the shipping.

Shipping accounts: Changing the 'Shipping terms' to either 'We ship' or 'Vendor ships' will dynamically populate this field with the respectively configured freight accounts from the 'Business Configuration' module.

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 product or service. 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 toward 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 product or service 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 when and what quantity of the selected inventory item has been purchased. 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. Even though you may not know the serial numbers at the time of purchase, it is important to add these when you do. That way you can associate this history detail with the appropriate products since the tag value will not accomplish this goal.

Installed: This detail type should be used when an inventory item has been installed at a customers location. If you have the 'Work Orders' module installed, this detail will automatically be added to the history list when the serial number has been included from within that module. This is another detail type that will need to have the serial numbers entered for it to relate it to a products history since the tag value relates this to an invoice or work order.

Leased: You should add this detail when a lease has been created for one of your customers. If you have the 'Quotes And Invoices' module installed, this detail will automatically be added to the history list when the serial number has been included from within that module. The associated tag value should be the document number of the lease and you should include all the product serial numbers included in the lease to associate this detail with each items history.

Prepped: If your organization has any prep work that needs to be done before the work day begins, this is the history detail that will need to be used. This is a generic value that can be used for various things, and as such, the tag value can be anything of relevance to your company. However, you will need to enter the serial numbers of the products being prepped so that this record can be correlated to a products history details.

Queue: This is another 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. The serial numbers will need to be entered for this value too.

Returned: Used as a way of keeping track of when leased items are returned, the tag value associated with this detail type should be the lease number from the 'Quotes And Invoices' document containing the original lease. Once again, the serial numbers will need to be entered for this as well.

Sold: While working with the 'Quotes And Invoices' module, any serial numbers that appear in an invoice will have this entry automatically added to the history details. As you can see, this detail type is used to identify when the item(s) were sold. 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 should be used by an organization that has purchased items from a vendor and will either resell them or include them as part of their assets since it increases the available quantity to be re-sold. The serial numbers of the stocked items will need to be input. Also, the tag value associated with this detail type is used by various modules and includes the freight cost and the product cost. Both of those values needs to be the TOTAL 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 '30.60|40' (cost of freight|per-item cost * quantity). 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|40'.

Destocked: After using the 'Stocked' history detail to increase available in-stock quantities, this one should be used by an organization when it sells products to others no matter that classification (e.g. wholesale, resell, retail) as this will reduce the available quantities. This detail also needs to have the serial numbers entered and has the same tag value structure as the 'Stocked' detail covered above that needs to contain the total cost for freight and the total sales price of the items being shipped. For example, if the shipping costs were $8.10 and the package contained two items with a total sales price of $92.17, then the tag value for this history detail would be '8.10|92.17'. If the customer wanted to use their freight company instead of you (as the vendor) paying for freight, then a value of '0|92.17' would need to be entered for the tag value.

Restocked: This particular detail type is used to when a product is returned to your organization, possibly after using several of the 'RMA' details listed below. The associated tag value should be the incurred restocking fee that is associated with this action and all the serial numbers need to be entered for the products being returned.

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

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.

Create a New Inventory Item

When opening this module, the form comes up ready to load an existing inventory item or to create a new one. If you currently have an inventory item 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 item is to fill out the (cleared) form and click the 'Save' button at the top of the screen.

NOTES:

* When creating a new inventory item, if you do NOT want to keep track of an in-stock quantity for the item (e.g. for a service such as LABOR), the erase the value in the first 'Quantities' textbox. A value of '0' means that you are out of stock, a null value means not to track quantities for the selected inventory item.

* Some of your products or services may contain individual items. For example, if your organization is a restaurant then you may have things like COMBO1, COMBO2, etc that contains individual items like a hamburger, drink, and fries, or a chicken sandwich, drink, and fries. You can select 'COMBO1' from the 'Products & Services' combobox and then the HAMBURGER, DRINK, and FRIES items in the 'Included ID codes' combobox.

This can also apply for other industries too. For example, a computer manufacturer may have a service ID code such as 'SMBIZSERVER' for a small business that contains individual MOTHERBOARD, CPU, RAM, and VIDEO ID codes as the components that make up the server. Another example might be a florist who might have a Valentines day special with ID code 'VDAYSURPRISE' that might include 12ROSES, TEDDYBEAR, and CARD. The process works the same no matter what industry you work in or what ID codes you have.

History entries of an inventory purchase (stock)

When your organization purchases products to add to its stocked inventory, there are several history details that will help you keep track of all the information associated with that transaction. A common set of information will be provided below in the order that each step occurs. It is important to remember that all of these details are optional, but can be used to keep track of various bits of information that relates to an inventory items history.

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. You can safely skip all the 'Shipping' entries if the inventory item(s) were 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 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 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 of a product sale (destock)

Companies sell products and/or services in order to stay in business. As a result, there will be various bits of information that should be kept in order to keep track of the sale. We will include the most detailed set of entries that can be used below, but be sure to reference the note at the bottom in the instance that shipping to the customer is not required for the sale.

Sold: This history detail should be automatically added to the list once an invoice has been created which will remove the entered quantity of items from the stocked inventory levels.

Shipping (queue): Creating this record will allow you to assign the job to the appropriate department that handles the shipping and receiving for your organization. You can optionally enter the associated serial numbers of the products being shipped to the customer, but these values are not necessary.

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.

Shipping (sent): After the item(s) have been assembled for shipping after being packaged from the 'Destocked' entry above, this history detail will indicate that it now has a tracking number and is waiting for the courier to pickup the package. Be sure to include that number as the tag value.

Shipping (transit): Once the courier has picked up the package, you should add this entry to indicate that this step has been completed. This detail also needs to include the tracking number as the tag value.

Shipping (received): This entry is used as the history detail that indicates the customer has received the shipped package. Once again, you should add the tracking number as the tag value so you will know which freight entries belong to which packages.

NOTE: if your organization did not have to ship the sold item(s) to the customer, then simply use just the 'Sold' and 'Destocked' history details outlined above.

History entries for lost inventory

There are times when inventory either gets lost, or sadly, stolen. In those instances your organization will need to add history details to indicate that this unfortunate incident 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.