Structure of products in the system.
The part entry screen consists of four parts:
Part information
Vendor information
Customer information
File attachments
The paragraphs below discuss each of the four sections. The part definition section contains both required and optional fields. The information in the remaining three sections is entirely optional.
Every part requires the following fields to be entered:
The (alphanumeric) code the company uses to identify the item
The (native language) description of the item, used as the default description on sales invoices
The asset account used to maintain the monetary equivalent of the inventory amount
The P&L (income) account to post the sales revenues on
The P&L (expense) Cost of Goods Sold (COGS) account to use to post cost of sold items on
The default selling price used on sales invoices
The other fields in this section of the screen are optional:
Informational; can be used for any (monetary) purpose
Last buying price, updated when a vendor invoice listing the current part is posted
Markup on Last cost to calculate the Sell price
A five-character field shown on the invoice
Informational; can be used by add-ons or when customizing
Reorder point - when the inventory drops below this number, the part will show up in “Short parts” reports
The storage location in the warehouse
Apart from these fields, there are also the Make and Model paired fields. Every part can have as many Make/Model lines as required. They are informational, but can be used when customizing the software.
The Average Cost and On Hand fields are output-only calculated fields. Average Cost is calculated from the historic buying prices. On Hand is the current inventory, which is updated when posting a vendor invoice (increased) or sales invoice (decreased).
Right below the accounts selection section, there is the Tax section, which lists all tax accounts with a check mark. Each account corresponds with a certain tax type and rate. E.g. in the Netherlands, there’s one VAT tax type (BTW) which has two rates, one of which applies to every product. This setup requires two accounts. There’s more on the subject of sales taxes in Chapter 27 starting at page 27.
By checking the check mark on an account, the system is signaled to calculate that kind of tax for the part if the customer (or vendor) has the appropriate setup as described in section
This section of the screen lists one or more vendors from which the part can be purchased, with purchasing information for the given vendor:
Code used by the vendor to identify the good, to be used by and future customization and enhancements (currently informational only)
Lead time of the part from the vendor in days
Last price at which the good was purchased from the vendor
The currency belonging to the Last cost field
The customer information section specifies sell prices per customer or price group where those are required to deviate from the default sell price. This mechanism exists to support the marketing principle of categorizing customers.
Price for this part to be used for this customer
Start of the applicability window of the price (inclusive)
End of the applicability window of the price (inclusive)
When adding parts, services, or overhead in Goods and Services they can be categorized in ’part groups’ . When searching, the part group can help to limit the number of matches. Currently, this is the only use of ’part groups’.
When no part groups have been defined, the part group assignment field doesn’t show up on any of the goods entry screens. Part groups never show up on the add assembly screen.
There’s no requirement that a good be assigned to any specific part group.
Often times, one may want to sell pre-packaged multiples of a single item, such as Jack in Chapter 7 starting at page 7 who wants to sell memory modules in pairs as well as single items, with the price for the pair set separately from the single-item price.
There are basically two use-cases
Pre-packaged sales which are separately stocked
Single item sales which are achieved by unwrapping the multi-item packages
The former case would be that of a supermarket selling packages of coffee in singles and shrink-wrapped in pairs. These items get stocked, sold and produced separately. Handling these is straight forward: as they are basically separate products from the point of administration and inventory management, they’re handled as separate parts.
The latter case would be Jack’s case where single-item sales is achieved by unwrapping a multi-item package. Basically, there’s a single inventory for both types of packaging. This situation can be handled (a) by creating separate parts or (b) by creating a part and an assembly. To reiterate: The fact that one wants to be able to separately set a pricing strategy for the bundled items is the driver to go look for other solutions than just sell a multiple of the original item.
There is no option which matches the actual practice: one inventory for two parts. The solution always will keeps two separate stocks for the two items, but one may work better in practice than the other.
Option a (separate parts) keeps the inventory of both items strictly separate, meaning there’s no way to convert between the two, other than selling and buying.
Option b (a part and an assembly) mismatches reality in so far that it will require one to stock the single items and update the assembly stock regularly while in practice the multi-item packages are stocked and unwrapped upon single-item sales. This procedure works to have the assembly stock go negative on sales and restock regularly (e.g. daily) to update assembly stock back to 0 (zero). This removes inventory from the single-item stock, allowing for a semi-automated way to convert stock from one type of inventory to another.