See Also

  1. Importing from Turbo Lister
  2. Exchanging Data
  3. Importing from XML
  4. Importing from eBay
  5. Importing_from_eBay_Blackthorne
  6. Importing from a Comma Separated Values Flat File
  7. Advanced Database Automation

Rules for Importing Items via CSV

These rules are specific to importing items from a CSV.  For general documentation on importing from a CSV, see Importing from a Comma Separated Values Flat File.

 

Importing data from a CSV is a similar for all types of data, however there are some differences depending upon the datatype.  The following rules apply when importing item data.

Updating Running Listings

Importing from a flat file is a great way to quickly change all of your item information, but you can also use it to update your running listings.  During the import, SixBit may perform updates to existing items.  If any of those items also have running listings, the listing can be updated by checking the Update Running Listings option at the bottom of the Import window.  This will update the listings immediately without relying on the SixBit Agent.

 

This is a great way to keep pricing info updated from your supplier.  Import the new file with the new prices and SixBit will make all the changes to the listings automatically.  

 

Note that only some fields can be updated - for example QuantityToList or Listing Title cannot be updated due to being able to have multiple listings to one item (one item change would overwrite multiple listings they may want to keep).

 

Unique Identifiers

The unique identifier fields for an item are used to determine whether an existing item should be updated or a new item should be added.  

 

When adding new items, all unique identifiers can be set at the time of creation.  Since unique identifiers are used to identify an item, some special rules must be applied when trying to update items.  For example, if an import file has only provide the SKU as an identifying field, then obviously it is used as the primary key and can't be used to update the SKU in the database.  If however the ItemID and SKU are provided, then the Item can be identified by the ItemID and the SKU could then be updated.   If however, SKU's are set to be unique, and an attempt is made to update a SKU to a SKU that already exists, it will be ignored.

 

For this to work, a precedence order must be set to determine which unique identifiers override the others.  The order of precedence is ItemID, ExternalItemID, SKU, ProductID.  For non variation items, any lower precedence field can be updated as long as a higher precedence field value is found.  For example, ProductID can be set if an ItemID, ExternalItemID or SKU has been provided and found in the data.  ExternalItemID can only be updated if the ItemID is specified.  ItemID has the highest precedence and cannot be updated.

 

In addition, since SKU and ProductID are stored for each variation, then the order of precedence on multi variation items is SKU, then ProductID, with SKU being the highest precedence field that cannot be updated.   In other words, the ProductID on multi-variation items can be updated if the SKU is provided, but the SKU cannot be updated from the ProductID.

 

Titles

There are different types of titles on an item.  The Product Title is global across all sites.  Each site in turn has its own title.  The Product Title is mapped to the Item tab during the import.  If the title of the item on the site should be different, it would be mapped to the Title field on the tab for that site (i.e. the eBay tab).

Folders

When providing folder names, separate hierarchical levels with double colons (::).  For example the Comedy folder under the Movies folder under the Media folder would be specified as Media::Movies::Comedy.

Status

Status should contain the name or the internal SixBit numeric identifier of the item status.  Allowed names and identifiers include:

1000 = "Under Construction"

2000 = "Awaiting Upload"

100000 = "Previously Listed"

110000 = "Retired"

Sub Status

When importing Substatuses there needs to be a column for Status so that the import can accurately find the desired Substatus, e.g. 
Status, Substatus Name
Under Construction, On Hold

Categories and SubCategories

When specifying categories, the numeric CategoryID from the site can be mapped to the CategoryXID field, or the full path can be provided in the CategoryXName field.  When providing the path to the category, separate levels with double colons (::) like this:  Disney::Pins::Parks.

 

Item Specifics

Each category can have its own set of item specifics.  If we provided a mappable field for every possible item specific, then our list of mappable columns would have thousands of entries.  Rather than provide a separate mapping field for each item specific, we have provided a single drop box location for all item specific fields to be placed.   When you drag a field from the CSV file into the Item Specifics drop box, this indicates that this field is an item specific field.  During the import, SixBit will check the category of the item being imported and if it has an item specific with the same name as any fields you have dropped into the Item Specific drop box, it will use that value for the item specific during the import.  

 

Some item specifics are multi-value item specifics.  This means they can accept multiple values.  For example, an item specific of Format may accept both NTSC and PAL.  To import multiple values for a multi-value item specific, separate the values in the CSV file with a double pipe "||" character.

 

 For item specific imports to work, you MUST provide a category through either the CSV file or the default item template.  Without the category, SixBit will not know which item specifics apply to any given item.
The names of the item specifics fields in your CSV file must match the names of the item specifics in SixBit exactly.  

Variations

Importing variations must be handled with a special case because each variation does not get its own item record.  Instead they all share the same item record and have separate inventory/stock records, each with its own SKU, that relate back to the primary item record.  This situation is handled by using the "External ItemID" field to link the master item record with its sub inventory/stock records.    

   

When importing a variation item, first import the "master" item record and give it a unique External ItemID.  This is where any common item information like the description, category, and shipping/payment presets are added.    For each variation of the item you must then create a variation row that contains a value in its "External ItemID" field so SixBit will know which item the variation is associated with.  It must also contain a unique SKU on each variation record to make them uniquely identifiable.  See the example below.  The first row is the master item record, and the remaining rows are the variation records.  The master item record and each of the variation records has the External ItemID field filled in.   
 

Title Qty On Hand Cost Category Variation Set Name SKU BIN Price Material Size (Men's) Color

External ItemID
T-Shirt     15687 T-Shirt1   7.00       1234
T-Shirt Yellow - XL 5 .51     T-Yel-XL 7.00 Cotton XL Yellow 1234
T-Shirt Red - L 4 .51     T-Red-L   Cotton L Red 1234
T-Shirt Blue - XS 3 .60     T-Blue-XS 8.00 Cotton XS Blue 1234

Determining the Variants

We know that the last three rows are variation records, however, how can we tell which columns are to be used as variants.? In other words, how do we specify which columns the buyer gets to select from? This can be determined in two ways.    

   

First, a value for the "Variation Set Name" can be provided on the master item record during the import.  SixBit will then look up the named variation definition that was previously defined and used to map the appropriate fields from the CSV file.  For instance, if you created a variation set named "T-Shirt1", that has variants of "Color" and "Size (Men's)" and then mapped to it during the import, SixBit would look for fields with those exact names in the CSV file and use those values.  The field names in the CSV must have the exact name as the variant in the Variation Set definition or it will not work.  Also note, that since "Material" was not included in the variation set definition, that field would be ignored.

   

The alternate method of determining the variants that will be used during the import is to specify a category.  When a category is selected,  SixBit will look through all the unmapped item specifics defined for that category and try to match them up with field names in the CSV.   For example, the Men's T-Shirts category have item specifics including "Material", "Size (Men's)" and "Color", so SixBit will use all three fields as variants.  Note that since the same fields are provided for all rows in the file, there will be only one variation set created for each category.

 

A variation sample CSV file can be downloaded here.  

   

Some things to recognize:

  • although the variation records each have a title, it will not be imported into SixBit.  The title of "T-Shirt" will be assigned to the "master" item record and will be used for the listings.

  • category is ignored for variation records.

  • When looking for matching variant fields, the first variant field found (the leftmost) will be used as the "picture variant".

  • When a Pictures column is provided, the pictures provided on the Master Item record will be stored with the item and the pictures provided on each variant row will be stored with the variant.  If different pictures are provided on each variant row with the same value, the pictures stored with that variant will be the superset of all pictures.  For example, if the picture variant is color, and there are 3 rows for green t-shirts, each with a different picture, all three pictures will be stored with that variation.

   

To update existing variation records from a CSV later,  specify the SKU on the import record and it will match it with the existing variation record.

 

 When importing variations from a CSV file, if the value for a variation is not found in the item specifics value for the chosen category, then that variation will not be imported.  Take the example of importing cell phone covers.  If the category has an item specific called color that contains values Red, Blue and Green, a variation item with a color of Yellow on the import will not be imported.

Items vs. Inventory Import

In versions prior to SixBit 2.0, the only way to import inventory was to include it during an Item import.  This was very limiting because it only allowed the user to specify inventory and supplier information when creating new items, however, when updating items, the only action available was to perform a reconciliation.

 

In SixBit 2.0, a much more robust and separate inventory import process has been created.   See Rules for Importing Inventory via CSV for more details.  Rather than setting item and inventory information in the same import, the preferred method in SixBit 2.0 is to perform separate imports.  The first import will import the item data and the second import to update the inventory.   This allows for much more control over the inventory update and allows you to perform actions like adding, removing, shrinking, reconciling or setting inventory information on both new and existing items.

Providing Initial Inventory Information During an Item Import

Although the preferred method of importing inventory information is with a separate import, the ability to import inventory on newly added records still exists with the Item import.  In other words, if your import is adding new items, you can set the initial quantity, cost, and supplier information, but to update existing records you will need to use an Inventory import.

 

 If your source file has both item and inventory information in it, you can use the same file to import Items and Inventory separately.  You would simply map the appropriate fields during each import.

Importing inventory with Items from a flat file has some considerations you should be aware of.  Inventory, by its nature, is not "flat" data and does not import from a flat file well.  Inventory is not a row with fields, but rather a series rows.  Every time inventory is purchased,  the user can specify the quantity purchased, price, date, shrink count and supplier.   There may be many inventory purchase rows for each item.  When importing from a flat file, each item only gets one row, therefore, entering multiple inventory records can be a problem.

 

In order to still accommodate the ability to import inventory information with items, we must make a concession to only import a single inventory purchase row; this  means you can only enter one purchased quantity, price, date and supplier for each item.  The fields that will be used to enter the inventory purchase information on an import can be found on the "Purchase" or "Supplier" tabs of the import window.  

 

 These fields are only meaningful when importing new items.  When updating existing items the fields on the Purchase and Supplier tabs will be ignored.