Product Import Columns Guidance

How to Import Data into TouchPoint

• TIP: To understand the full process, check out this page for a full video walkthrough of how the TouchPoint Import/Export feature works.
• This Help Guide is focused on providing detailed documentation for every column available in TouchPoint’s Product Data CSV File Format.

How to Use the Columns (Fields) for Product Data

id

• System ID for the product
• This column is only used for importing raw data from another POS or data source where original IDs and data relationships must be preserved or in TouchPoint exports
• Generally this column can be ignored
• The numbers in this column should generally NEVER be modified

sku

• Stock-Keeping Unit for the product (can be different from vendor_sku and UPC)
• ONLY use letters, numbers, and dashes
• Never use any other characters like . or ” or ‘ or &
• SKU structure is critical for proper inventory management
• Every sku field in the entire file must be UNIQUE
• Parent and Child SKUs are required to automatically connect product variations
• Good Parent SKU Example: TSHIRT-ONE
• Good Child SKU Example:  TSHIRT-ONE-SM-BLUE
• Good Child SKU Example:  TSHIRT-ONE-SM-RED
• Good Child SKU Example:  TSHIRT-ONE-LG-BLUE
• Good Child SKU Example:  TSHIRT-ONE-LG-RED
• Bad SKU example: TSHIRT_1″
• Bad SKU example: T-shirt_vneck_2.5
• Bad SKU example: 10’board-&-bracket

parent_product

• System ID or SKU of the parent product for this child (variation) product
• This should be BLANK for every simple product (no variations like different colors) 
• This should be BLANK for rows that represent the Parent SKU
• Every product that has children products (like multiple colors) should have:
  • 1 row for the Parent SKU where parent_product is BLANK
  • 2+ rows for Child SKUs where parent_product = the sku of the Parent SKU
• By making the parent_product value of a row match the value in the sku field for another row, this will attach the product in that current row to the Parent SKU in a previous row
• Example of how it should look in the import file:

• IMPORTANT: TP accepts either raw ID numbers or SKUs in the parent_product field
• For initial import it’s easier to leverage human-readable SKUs for this
• When exporting TouchPoint data for bulk product management the parent_prouct field will use the raw system ID 
• As long as you don’t modify the id field or the parent_product field, other fields in the TP export files can be safely modified and re-imported into TP to update product data

name

• Product name / title
• If using TouchPoint’s ecommerce integrations (like WooCommerce sync) then this field will be used as the Product Title and SEO implications should be carefully considered.
• The values in this column should not be too long and should NOT (generally) carry any variation or attribute information (like “Red” or “Large”) UNLESS it is a simple product and those descriptors are inherently part of the product title.
• Typically this should match the manufacturer’s product name and be something that both staff and customers would know to search for.
• It should also be descriptive enough to quickly distinguish from other products in the catalog without being too long or cumbersome, and should avoid abbreviations or other “shorthand” terms that might be ambiguous for search engines
• It might often include the Brand as the first word or words
• Good Example: Nike Men’s Sport Champion T-Shirt
• Bad Example: Nike M’s T-Shirt
• Bad Example: Nike Men’s Sport Champion Red T-Shirt Large
• For Parent and Child products the name column will be identical for ALL of them because the product variations are defined by attributes and all variations share a single, common name.
• Example of how it should look in the import file:

short_description

• Optional
• A brief description of the product used in various short-format locations
• This will also be identical for all child products and their parent product

description

• Optional
• A longer description of the product used in various long-format locations
• This will also be identical for all child products and their parent product
• HTML markup supported

price

• What you want to sell the product for – what your customers should be charged BEFORE any coupons or discounts or sales are applied
• MUST be in numeric format and must NOT contain any currency symbols
• Good Example: 25
• Good Example: 25.00
• Good Example: 25.50
• Bad Example: $25.00

cost

• What you pay for inventory – what your Cost of Goods Sold (COGS) is for that product
• MUST be in numeric format and must NOT contain any currency symbols
• Good Example: 25
• Good Example: 25.00
• Good Example: 25.50
• Bad Example: $25.00
• This is used by reporting and the Purchase Order system and the more accurate this number is the better the financial reporting will be.

cost_floor

• Optional
• If your business uses and potentially sells in-store “floor models” then you can use this field to establish a separate COGS for any special, discounted “floor model” inventory you purchase and stock

vendor

• Optional
• Primarily used in the Purchase Order System
• Typically this will be the same value as taxonomy_brand and most stores will want to have both columns present and matching each other. 
• Vendors that already exist in TP upon import will be connected to those products and any Vendors that don’t exist will be created upon import. 
• There is a connection between Vendors and Products.
• Vendors are a separate data object and can have a lot more fields defined and has its own separate import as well if the Vendor and Purchase Order system will be used.
• This column in the import is strictly for the Vendor Name.
• Exercise care not to have 2 different spellings of the same Vendor or the system will create 2 different Vendors – one for each spelling. For example: if you have “Nike” in the Vendor field for some products and “Nike Shoes” for other products, the system will create both. Make sure any differences are intentional and always copy/paste to ensure that the same values are perfectly identical.

vendor_sku

• Optional
• This can be the same or different than your own SKU
• If no value is provided, the system will automatically populate this field with the value from the sku field

warranty

• Optional
• This is for short text (several sentences) describing any warranty conditions or terms you want to record per product.
• Many businesses might not use this at all

upc

• Optional
• The numeric representation of a standard UPC barcode for the product. 
• Typically, this should only be input by actually scanning a product’s UPC barcode with a hardware scanner, unless the data is available for import from another source.
• Touchpoint provides tools for quickly adding barcode numbers to this field per product using a standard scanner. 
• TouchPoint searches and inventory tools and the Cart all have UPC barcode scanning support.

reorder_type, reorder_qty, reorder_point

• Optional
• Only used for automated inventory re-ordering and stock level detection in the Purchase Order system.
• Requires additional training to understand and use.

is_custom

• Optional
• 0 = false (DEFAULT) – if blank then the system assigns this value
• 1 = true
• Primarily set to 1 (true) for cases like consignment or other situations where a custom product name needs to be input in the Cart during the purchase process. 
• Most businesses won’t need to use this, but it’s a powerful feature for dynamic, fluid product types that can’t be fully known until the moment of purchase.
• Another example use case for this is a product that has a high degree of customer-defined customization outside of standard attributes. For instance – custom flavor combinations and material selections or other things that can’t be predetermined

is_taxable

• 0 = false 
• 1 = true (DEFAULT) – if blank then the system assigns this value
• Determines whether or not sales taxes are applied to this product
• Examples of products that would be set to 0 might include intangible services or fees like delivery, maintenance, repairs, etc.

is_returnable

• 0 = false 
• 1 = true (DEFAULT) – if blank then the system assigns this value
• Determines whether or not this product is allowed to be returned

is_inventoried

• 0 = false 
• 1 = true (DEFAULT) – if blank then the system assigns this value
• Determines whether or not this product is tracked and managed by the robust inventory management system in TouchPoint. 
• There are many implications to this setting. 
• In almost all cases, physical products should be set to is_inventoried = 1 and non-physical products like downloads or services should be set to is_inventoried = 0. 

is_active

• 0 = false 
• 1 = true (DEFAULT) – if blank then the system assigns this value
• Determines whether or not the product shows up in search results, can be sold, etc.
• This is basically an archival mechanism for old products no longer being sold. Products can NEVER be completely deleted because that would corrupt the historical sales data that they are connected to. But making a product inactive can safely remove it from use without impacting historical data and reporting.

image

• Optional
• The URL of the product image. 
• TouchPoint can manage product images uploaded through TouchPoint or external images from imports like in WooCommerce.
• TP will use a generic product image placeholder if one isn’t specifically defined.

taxonomy_category

• There is a special column type in the TouchPoint import engine – any column that starts with taxonomy_ will create a new Taxonomy in the system with “terms” being created from the values in that column. 
• A Taxonomy is just a group of related terms that classifies data in a consistent way.
• The existence of a taxonomy_category column in the import file creates the Taxonomy called “Category” (if it doesn’t exist) and then assigns any terms found per product to that Taxonomy, creating any terms that also don’t already exist
• The column supports a hierarchy structure and a flat structure based on the value given.
• Terms can be filed under each other by using the > character.
• For Example:

• In addition, a single product or child product can be assigned to multiple terms in a taxonomy by using a vertical line character |
• For example this will assign a product to both categories in Men’s and Women’s shirts
  • Clothes>Men>Shirts|Clothes>Women>Shirts
• For example this will assign a product to the categories Accessories, Packs, and Bags (some can be top level categories and others can be sub-categories):
  • Bags|Containers>Packs|Gear>Accessories

taxonomy_brand

• This is another taxonomy column and all the normal taxonomy import rules apply.
• However, this is a common taxonomy most stores will probably want to use in a flat structure where it’s just a single name of the product’s brand like Nike.

attribute_size

• Attributes are a special taxonomy used to define child variations of a parent product. 
• All child products should define values in one or more attribute_ columns. 
• Attributes can be used across different product types and it usually makes sense to keep things consolidated. For example, clothing might use the attribute_size values of Small, Medium, and Large while mattress products might use the same attribute_size for Single, Twin, Queen, and King.
• Building on our previous example, this is another valid example:

• If the attribute called “Size” doesn’t already exist then it will be created.
• This works for any column starting with attribute_ (e.g. attribute_color will create an Attribute Taxonomy called Color. 
• It’s typical to see something like this among the attribute_ columns in an import file which shows how different child products are assigned one or more attributes at the same time:

• It’s important to remember that every row represents 1 unique combination product and the example above does NOT show all combos possible. For example, a unique row would also be needed for a Large, Blue, Smooth product. 

stock_1_new

stock_1_floor

stock_1_used

stock_1_reserved

• These stock_ columns are used to import / update current stock levels in the system.
• The number (like _1_ in this case) corresponds to the Location ID in the system. 
• Some of these columns are optional and can be ignored depending on how advanced your business inventory management needs are. 
• The _new column is the “normal” inventory level and what is available for sale. This is sync’ed with WooCommerce’s stock level if applicable.
• The _floor column is the number of floor models in inventory. These can also be sold when _new is 0.
• The _used column is the number of returned / damaged items that are inventory. These can also be sold at a discount or managed independently.
• The _reserved column is the number of items sold but not yet delivered, shipped, or picked up by the customer. Usually this column is only used with the Delivery system and it is very rare that anything other than 0 will be imported here. However, this number might be positive in exports from businesses actively using the Delivery system
• Inventory levels can be bulk edited in two primary ways:
  • Through the Inventory Counts system (this is the recommended way)
  • Through exporting > modifying > re-importing the data
• There are a LOT of implications for inventory adjustments in a robust inventory management system like TouchPoint. All inventory adjustments create accounting entries for things like COGS and Assets records. Inventory adjustments outside the normal Purchase Order Receiving and Product Sales process and should be a formal, intentional, careful process – especially if TouchPoint’s integration with QuickBooks Online is being used by a business.