Code-driven fields are fields that involve looking up and selecting a parameter. In other words, selections in code-driven fields must be attached to a code and an accompanying description. In a code-driven field, there is always a binoculars icon at the right of the field. Clicking on the icon (or pressing F3 while your cursor is positioned in the field) takes you to a Find, or lookup, screen; from there, you select the code you want. For information on how to look up and select parameters in code-driven fields, click here.
For information on how to create the actual codes and descriptions for code-driven parameters, click here.
This page is used to define the code-driven fields you will find in [i] Merchant. It is separated into two basic sections: Product and Customer. Product code-driven fields deal with products; customer code-driven fields pertain to customers.
Accompanying Materials: This is not a "true" code-driven field, but it does have a pulldown menu. There are two choices open to you in the pulldown menu: "None", and "Has Material". This essentially means: either a product is supposed to come with accompanying material, or it is not. For example, maybe a book is supposed to come with an accompanying CD. If this were the case, you would select "Has Material" from the pulldown menu.
Accompanying Material Present: This goes hand in hand with the Accompanying Materials field, and is not a "true" code-driven field--that is, it has a pulldown menu with two choices: "Material is present", and "Missing". This field is only applicable for a product whose Accompanying Materials field is set to "Has Material". What the Accompanying Material Present field is essentially asking is: If a product is supposed to have accompanying material (such as a book that is supposed to come with a CD), did the accompanying material actually come with the product--yes ("Material is present") or no ("Missing").
Accounting Category: This very important field represents the general ledger information needed for posting, as well as giving you the option of tagging products to be non-tracked inventory items.
Products (as well as services, tenders, and tax codes) will belong to particular Accounting Categories. In addition to the basic code and description, there is also a POS Sales Summary Group field. This field is used by the POS Sales and Receipts Summary Report to create logical groupings and subtotals in the Sales Summary area of the report. You can create as many POS Sales Summary Groups as you want.
The Accounting Category parameter also has a G/L Accounts section. The G/L Accounts are separated under two headings: "Inventory Accounts," and "Sales and Expense Accounts."
There are three fields under "Inventory Accounts": Inventory-Purchase Receipts, Inventory-Returns, and Inventory-Withdrawals. These three fields deal exclusively with products (as opposed to tax codes, tenders, or services).
There are four fields under "Sales and Expense Accounts": Sales/Sales Tax, Discounts, Cost-of-Goods Sold, and Inventory Adjustments. All of the seven aforementioned fields are code-driven, where you will select the appropriate G/L Code.
For Accounting Categories attached to products, assign G/L Codes to all seven of the above fields.
For Accounting Categories attached to services, assign GL Codes in the Sales/Sales Tax field. For discounts, assign GL Codes to the Discounts field.
For Accounting Categories attached to Tax Codes, assign GL Codes in the Sales/Sales Tax field.
For Accounting Categories attached to Tenders, assign GL Codes in the Sales/Sales Tax field.
Two fields apply to non-tracked inventory. Non-tracked inventory is inventory whose onhand values will not be tracked by [i] Merchant.
The first of these two fields, Inventory will Not Be Maintained, has a checkbox to the left of it. If you leave the box unchecked, all products belonging to the Accounting Category will be regular, tracked items. If this is the case, the field to the right of it, Cost %, will be grayed out, as it only applies to non-tracked inventory.
However, if you check the Inventory will Not Be Maintained box, then all products belonging to this Accounting Category will be non-tracked. As such, the Cost % of Retail needs to be filled in. Simply key in the Cost % of Retail value you want. This value is primarily informational, and will apply to certain reports, such as the Product Sales Report, where "Cost" is a column header. Cost, in those reports, as pertaining to non-tracked inventory, will get its value based on the percentage you enter here, coupled with the product's selling price. For example, if the non-tracked product is sold for $10.00, and you enter 40% here for the Cost % of Retail, then the Cost (as it will appear on the applicable reports) will be $4.00 (40% of $10.00 selling price = $4.00). However, in Product Properties, the Cost value for all non-tracked inventory will always be zero.
Accounting General Ledger Codes: These are codes you create and then attach to Accounting Categories. The General Ledger Codes you use should reflect General Ledger Codes you already use in an external accounting system. Setting these codes up in [i] Merchant will enable you to run G/L Exporting from [i] Merchant into your external accounting system.
Binding: This field pertains exclusively to books. The binding is separated into categories such as soft cover, hard cover, etc. Create as many Binding Codes as you want.
Book Class: This is a user-definable field that, as Book Class, pertains exclusively to books. Create as many Book Class codes as you want. Book Class codes are codes used to define a book in some way (example: R for Remainder, BS for Best Seller, etc.). Set up codes and descriptions that apply to your store and make sense to you.
Can Transfer: This field has two choices under the pulldown menu: "Allow Transfers", and "Do Not allow transfers". Essentially, what you are choosing is: Do you want the product to be allowed to be transferred between stores (in a multi-store setup), or do you want to disallow transfers between stores for the product in question.
Condition: This is a user-definable field. Create Condition Codes to tag inventory by its condition. You may create a Code of P for Poor or E for Excellent. Examples of inventory that would be tailored to Condition Codes: used books, collectible comic books, or antiques--items where condition is crucial to value. The Condition Multiplier field is a percentage. Multiply the used-product retail price by the Condition Multiplier to get the adjusted used retail price for a product. For example, a "Poor" book would cost less than a "Good" book. For more information, please click here.
Country Code: This is where you can create a code and description for different countries. Example, Code: US, Description: United Stated
Currency Code: This is where you can create a code and description for different currencies--for example, U.S. dollars, Canadian dollars, Japanese yen, etc. In addition to the code and description, there is also a Symbol field (where you enter the currency's symbol--for example, $ for dollars) as well as a POS Exchange field. The POS Exchange field is where you establish the exchange rate between the currency in question and the U.S. dollar. Lastly, there is a History button at the top of the window, where you can view the history of the currency's start and end dates, exchange rate, and updates.
Department Category: Department Categories allow you to segment your inventory into groups. Create as many Department Categories as you want. For example, for Fiction, the code might be F and the description might be Fiction. Or you can drill down deeper and create more specific, detailed Department Categories. The options are limitless.
Dust Jacket: This is not a "true" code-driven field, but it does have a pulldown menu. There are two choices open to you in the pulldown menu: "None", and "Yes". This essentially means: either a book is supposed to come with a dust jacket, or it is not.
Dust Jacket Condition: This is a user-definable field that goes hand in hand with the Dust Jacket field. Use the Dust Jacket Condition field to establish codes that denote the condition of the dust jacket (i.e., "torn," "good," "poor," "ripped," etc.).
Imprint: Imprint pertains only to the book industry. An imprint is a subgroup of a publishing house. For example, Penguin Classics would be an imprint of the parent Penguin. Create as many Imprint Codes as you need.
New Used: New Used pertains primarily to the book industry. It is a marker that identifies a book as either new or used, or as a Remainder. This is related to any Balance Card tender types that you set up as used credit. In order for the used-credit tender to apply at the POS, the applicable purchased products must be flagged as Used Products or as Remainders using the New Used field in Product Properties.
Overstock Code: This is a user-definable field. Generally, this is a yes-no coded field, but you can create more options if desired. "Yes" indicates that additional copies of the product are available in stock, but are not on the store shelves (perhaps they are in a warehouse). "No" indicates that no additional copies exist--all in-stock copies are on the shelves or are allocated for Customer Orders.
Problem Code: Problem Codes deal with problems in Receiving and Electronic Ordering. Create Problem Codes such as SS for Short Shipped, or B for on Backorder, etc. In Receiving, assign the appropriate Problem Code to an item not received, or received in poor condition, overshipped, etc. You can create as many Problem Codes as you need.
The Problem Code parameter has additional layers to it. You will want to use these layers if you want automatic reorders or returns to result from certain specific Problem Codes. The reordering portion of the Problem Code parameter is listed under the "Reorder Settings" heading. The returns portion is listed under the "Return Settings" heading.
Let's look at the "Reorder Settings" first.
If you are, for instance, short shipped (SS), you may want the system to automatically reorder the product. Here is what you will need to do . . .
The Setup Reorder field needs to be checked if you want products with this Problem Code (whatever Problem Code you are defining) to be reordered automatically. If you check this field, such products will be reordered automatically both in Receiving and in Electronic Ordering. If you do not check this field, such products will not be automatically reordered.
The Remaining Quantity Still Coming field applies to the Receive Status flag. If you check this field for a particular Problem Code, the system knows that you were short-shipped (SS) and that more copies of the product are still due. In this case, the Receive Status flag will still say, "Pending". If you leave this field unchecked for a Problem Code, then the system will assume that no further copies of the product are forthcoming, and the Receive Status flag will say, "Complete".
The To Be Ordered (TBO) Type field is where you assign the TBO Type for products being automatically reordered when they are assigned this Problem Code. (This TBO Type will automatically carry over to products placed on the TBO screen. However, in the EDI module, you must set the TBO type there. The system will not carry over the TBO Type as defined in the Problem Code.)
To automate the Returns process (that is, to have a product with a particular Problem Code automatically scheduled in the TBR module), you must check the "Make entry into return system" box under the "Return Settings" heading. A product with a Problem Code of Damaged (D) would be a good candidate to be automatically placed in the TBR module.
Then, assign a code in the To Be Returned Type field.
Lastly, there is a Customer Order Notifications section.
Check the "Create a Problem Notice" box if you want a Customer Order with a product that includes a particular Problem Code to appear in the Customer Order Notifications program when you run a search for Problem Notices. If the box is not checked, then Orders with these Problem Codes won't appear in Customer Order Notifications when Problem Notices is selected.
"Complete Customer Order After creating Notice" is also a check-box field. Check this box if you want the product with a particualr Problem Code attached to it to be marked as Complete once the Customer Order in question has been searched and called up in Customer Order Notifications. If you leave the box unchecked, then the product in question will not be marked as Complete by the system after being called up in Customer Order Notifications.
Product Type: Product Type is directly tied in with Vendor Properties. In Vendor Properties, in the Vendor Properties Rules section, you set up and define ordering guidelines for products ordered from that vendor. As you do this, you choose from the Product Types you have established. Create as many Product Types as you want.
Reorder Rule: The Reorder Rule determines when and how a product is suggested to be reordered. For example, you might set up a Reorder Rule of S, which might mean that every time a product sells at the POS, the system automatically flags that product to be reordered in the Auto Buy field of the Buying Manager program. So, if twenty copies of a book were sold today, twenty copies would be suggested to be reordered in the Auto Buy field. You can create as many Reorder Rules as you want. Then set the Reorder Rule field in Product Properties to define which Reorder Rule you want to use for each product on your system. (Be sure to place the Reorder Rule in Product Properties using the Screen Designer if you want to use the Auto Buy function in Buying Manager.)
The Reorder Rule works in conjunction with the Buying Manager, specifically the Auto Buy field within the Buying Manager program.
The Reorder Rule has a few layers to it above and beyond the Code and Description:
The Method field determines how the Reorder Rule will operate. There are four choices: Auto-Buy none (0), Use Restock Value, Replace Sales, and Use Stock Level.
Auto-Buy none (0) negates the Reorder Rule function. Essentially, if you select Auto-Buy none (0), you are telling the system that you do not want this Reorder Rule to suggest anything--all reorder suggestions under the Auto Buy field in Buying Manager will be set to 0. You might choose Auto-Buy none (0) for products that you do not order very much.
Use Restock Value simply means this Rule will suggest the Restock Value calculated in Buying Manager as the quantity to be reordered in the Auto Buy field. It ensures that the Restock Value and the Auto Buy value will match.
Replace Sales simply means: for every copy of the product sold, one copy should be reordered. So, if 6 copies sold during the time frame you are querying about, the Auto Buy field in Buying Manager will fill in with a 6.
The most dynamic method you can use is: Use Stock Level. This method is more complex and works in conjunction with the ReOrder Point and Stock Level fields. Essentially, you are determining a projected onhand amount (which takes into consideration quantities needed to fill Customer Orders, quantities already included on active POs, and TBO records) for a product below which you do not want to go (ReOrder Point). Then you are determining how many copies of the product you want to have in stock (Stock Level).
|
Example: |
You set the Method field for this Rule to Use Stock Level. You set the ReOrder Point field at 3. You set the Stock Level field at 6. The system will be prompted to suggest a reorder for this product when the projected onhand falls below 3. It will suggest (and place in the Auto Buy field of the Buying Manager program) a reorder amount that will increase the onhand amount back up to 6. So, let us say the projected onhand amount plummets to 1. The system will suggest (in the Auto Buy field) a reorder quantity of 5, in order to get the onhand amount back up to the Stock Level value of 6. |
Rewards: This is where you establish the different Customer Reward Premiums. For information on Customer Rewards, please click here.
Return Reason Code: This is an optional Code in Returns and TBR that allows you to attach a Reason Code to any product being returned. This is a standard Code and Description parameter.
Sales Event: This field allows you to create codes and descriptions for Sales Events. Events can be anything, from a Veteran's Day promotion, to a day-after-Christmas sale. Set up as many Sales Events as you want. The POS clerk can assign Sales Events during any particular transaction.
Shipping Code: This field allows you to create codes and descriptions for shipping charges--generally applied during Charge & Send Customer Orders. For example, some Shipping Codes you may want to create are: UPS Ground, FedEx, US Mail, etc. The standard code and description settings apply, but there are multiple fields you need to fill in when creating a Shipping Code.
You will notice a field called "Service used at POS." This essentially ties the Shipping Code to a Service. This Service, which of course must be set up beforehand in Service Properties, is the service that POS, for lack of a better term, "sells" when issuing shipping charges. You will probably want to name the service "Shipping," or something like it. You can, of course, create more than one Shipping service in Service Properties and then tie the appropriate Shipping Code to the appropriate service.
To the right of this, there is the "Calculation Method" field. Click on the down arrow at the right, and select one of the two options--"By Item" or "Manual Entry." "By Item" will automatically assign a shipping charged at the POS for each applicable item sold. "Manual Entry" will force the POS clerk to manually enter a shipping charge at the POS during the transaction.
The rest of the Shipping Code parameter screen is divided into two columns listed under the heading "Shipping Rates." The two columns are: Normal and Partial. The values under "Normal" deal with a full order. The values under "Partial" deal with only a partial order, in which not all items ordered will be shipped to the customer. Beneath both columns, the same individual fields exist. But you can set the values differently under "Normal" versus under "Partial":
Minimum $: This is the minimum amount your store will charge for shipping on any order. For example, if you charge $1.00 for the first item shipped and 50 cents for each subsequent item included in an order, you may still set the Minimum $ amount to, say, $3.00. In this example, if a customer orders two items, she would be charged only $1.50 according to the first item being charged $1.00 and the second item being charged 50 cents. But the Minimum $ amount overrides this, and she will be charged $3.00 for shipping.
Maximum $: This is the maximum amount your store will charge for shipping on any individual order.
First Item: This is what your store will charge for shipping for the first item on an order. As explained above, this value can be overriden by the Minimum $ amount value.
Each Additional Item: This is what your store will charge for shipping for each item in an order after the first item. If you set the "First Item" field to $1.00 and the "Each Additional Item" field to 50 cents, and the customer purchases five items, the shipping charge will be $3.00 ($1.00 for first item, and 50 cents for the four subsequent items--50 cents + 50 cents + 50 cents + 50 cents = $2.00, plus the $1.00 for the first item = total of $3.00)
The last field under Shipping Code is a checkbox field. If you want to apply shipping charges to services (in addition to products), check the box next to the "Apply Rates to Service items" field. If you do not want to charge shipping for services (which can include, among other things, gift cards, store certificates, etc.), then leave the checkbox field blank.
Slip Case: This is not a "true" code-driven field, but it does have a pulldown menu. There are two choices open to you in the pulldown menu: "None", and "Yes". This essentially means: either a product is supposed to come with a slip case, or it is not.
Slip Case Condition: This is a user-definable field that goes hand in hand with the Slip Case field. Use the Slip Case Condition field to establish codes that denote the condition of the slip case (i.e., "excellent," "good," "poor," "damaged," etc.).
Status Code: This is an informational field that simply depicts the status of an item (for example, S for Shelved, OO for On Order, etc.) Create as many Status Codes as you want.
Stop Type: (Single Title Order Plan). This field pertains exclusively to books. Essentially, a Single Title Order Plan is just what it says: It is a special set of rules and guidelines that pertain to one particular title. Maybe you have special ordering rules, for example, for Harry Potter. Create a Stop Type Code, and then create the rules that define the code in the Vendor Properties Rules section for the applicable vendors. Stop Type works just like Product Type, except it deals exclusively with one specific title.
Store Number: Create codes and descriptions for all of the stores in your chain--or if you have only one store, simply add the code and description for the one store. An example code would be: 1. The accompanying description might be: Main Street Books.
Tax Code: More often than not, you will only need two basic Tax Codes: Y for items that are taxable, and N for items that are tax-exempt. However, other Tax Codes may be necessary sometimes, such as a special City or County tax. Create as many Tax Codes as you need. Tax Codes work together with Tax Area.
Unit of Measure: A unit of measure determines the quantity or state of an item being sold. For example, you would create one Unit of Measure Code to be E for Each. But then you might create one for D, for Dozen, or B, for Box, and so on. Create as many as you want, then select the appropriate one for an item at the Product Properties screen.
User Defined Code-driven Fields (PD_Codes, Prod_Codes, and PA_Codes): These code-driven fields are user-definable; that is, you can name any of them anything you want and use them for anything you want. User-definable fields are essentially additional, optional fields you can use to help further classify your inventory. They provide you with increased flexibility. (The PD_Codes and PA_Codes are at the item level for a product; the Prod_Codes are at the product level.) If you want to use one of these fields, select it in Screen Designer, rename it, and create the codes and descriptions. We will have some user-definable fields already named and set up for you (such as Condition and Book Class), but you can rename and redefine these as well, if you want.
Auto Discount: The Automatic Discount field is directly tied in with the Customer Discount program.
Customer Notification: Customer Notification parameters are integrated with the Customer Order Notifications program. Set up as many Customer Notifcation codes as you need, and use the appropriate codes when utilizing the Customer Order Notifications program. In addition to the standard code and description fields, there are also two free-form fields, where you can key in the text both before and after the information about the applicable Customer Order.
Customer Type: Customer Types help to sort customers into groups of your choosing. For example, you may have Customer Types of B (Business), R (Regular), T (Teacher), etc. Create as many Customer Types as you want.
Discount Rule: The Discount Rule is set up for specific customers using the Customer Discount program. In Customer Orders, the field will fill in automatically if a customer has a Discount Rule attached to his or her file.
Location: The Location Code generally is used to identify the shelf location of customer orders. Create as many Location Codes as you want.
Order Type: Order Type pertains to Customer Orders. An Order Type Code might be W for Walk-in, or P for Phone Order, I for Internet Order, or R for Rush. Create as many Order Types as you need.
Origin: Origin pertains to Customer Orders. Origin is similar to Order Type (there may be some overlap), but whereas Order Type can apply to anything regarding a Customer Order (such as R for Rushed), Origin deals specifically with where the order originated (on the Web, on the phone, as a walk-in, etc.)
Price Type: The Price Type field is optional, and you would only use it if you incorporate a promised price at the Customer Order screen. But even then, the Price Type is optional. Price Type is a parameter you can establish where you define promised prices. For example, if a particular business generally receives a certain special price for selected items, you might want to define a Price Type. In short, Price Type can be used to describe or codify different types of promised prices.
User Defined Code-driven fields (CA_Codes1-3 and Cust_Codes1-5): The CA_Codes pertain to address fields in the Address section of Customer Maintenance. The Cust_Codes can pertain to anything else. User-definable code-driven fields can be used (or not used) any way you want, and you can rename the fields in ways that make the most sense to you. These fields are designed to provide you with greater flexibility.