HemiKnowledge BaseHemiCore
Related Articles
Knowledge Base
Hemi System Administration Integrations Hemi PRD Library Hemi Content Stream General Information Custom additions Core Integrations & Marketplace Documentation Hemi Advanced Functionalities Data Management MP Tokens generation Hemi Technology Trainings Hemi Platform Integrations Release Notes
FAQs

Imports & Exports / Imports Exports full update / Imports Update for UI MVP / Imports new handle

Imports new handle

  1. General

    1. Column position is the one that should be leading based on the mapping, not the header name
    2. Imported file (if CSV/Excel/TXT) can be with or without a header and this should be available for control in the mapping and each import below to be able to work with both options
    3. Each import should be doing a data check validation - if we try and insert / update characters in a float field we should block the update of this specific field - discuss with Product team - do we want to block the whole record? Are there instances that blocking only the field update can result in a problem if other fields are updated?
      1. Data validation should work for all data fields
      2. Fields that accept free text should be checked and properly assessed for security breaches and decided how and if to handle escapings for html for example the same way that later UI, Exports and integrations will work together with this. This should be prepared in such a way that it can be switched on and off so it can be prepared for all functionalities and switched on together

  2. Items

    1. Map by SKU to items in Hemi
    2. Map by Product ID to items in Hemi - if both provided ID is with priority and we SHOULD update the SKU in Hemi as well. Uniqueness by SKU still applies - we should either block if the new update is duplicating a SKU OR we should track the whole file and if the second SKU is also updated via same feed update both and continue as there will be no actual duplications in the DB. Discuss with Tech team - we should prioritise performance in this case! Most probably block
    3. Map all "table" fields via taking the Header as "Key" and the provided info in the column as "Value" for said product record. This should work for every field in Hemi that is with type "table"
    4. Map and create update Product Accounts by the "Account ID" provided in the feed or by an Account selected from the dropdown. Uniqueness still remains SKU + Account ID for this section (single product can't have more than one Listings for the same Account)
    5. Any table field import should support the following additional actions:
      1. If Value is "" (empty) it should be skipped (no import for both create or update even if the Key exists) - discuss with Product team to confirm behaviour
      2. If Key or Value contains commas or quotes or any other special symbols those should be imported in the Hemi field
      3. If the Value is "[DELETE]" we should remove this pair Key+Value from this specific product as a whole
    6. More images (both on Product and in MP Specifics) are to be treated as a table field that just doesn't store "Key" but just loads one after the other all imported "Values"
    7. Map and create / update custom fields based on the header of the column when selected that this specific column is a Custom Field
    8. Track products and update what is already in Hemi and create what is not (follow uniqueness needed for different sections). This should also be controlled in the import creation phase to select if we want to create+update, only create or only update (default - create+update)
    9. We should have an option only to update existing products (no creations) OR to only create new products (no updates) OR as a default - do both
    10. Items import should have a general parameter to push content to MP if updated (or just created)? Should this be tied with prices and stock?
    11. We should be able to control generally how we handle data fields for escapes and encodings. We should be readily available to switch on encoding on all type of text fields when integrations and Hemi outputs are ready to properly decode them
    12. We should ensure there are no scripts or any sql available for insertion into Hemi
    13. We should do validations on the data type when reading the input (can't import text into a price field, if enum is wrong we don't import the unexisting value, etc.) based on the field types and options
    14. We should be doing rounding on numbers based on Hemi field allowance before we import (we don't want a thousand History updates because of roundings in the field itself...)
    15. Price fields & Quantity fields will be available in the items import but will not have any specific extended functionality as their respective dedicated imports - discuss with Product team if we want to handle this
    16. If in the items import we've mapped the field "Fields For Revise" and our internal field "List / Update the whole item" is anything different from "Not Needed" or empty value we are to concatenate the information from "Fields For Revise" mapping in the Hemi field as opposed to replacing directly with the value in the file
    17. All other fields are to be mapped directly only based on their type. No additional data transformations or parsing info for specific tasks

  3. Stock

    1. Map by a chosen "Product identifier" to the product in Hemi to determine if a Stock record should be stored (only stock for existing products is to be stored) - Map to Products should be by SKU / MPN / EAN and we should be able to add more later if we want to
    2. We should be able to map a Location from the file or chose one from the UI. If there is a location mapped in the file and one chosen in the dropdown the one in the file is to be with bigger priority
    3. All fields are mapped to the Stock holding table directly (meaning there is no transformation or any specific value that we have to read and parse an action) - Fields are only "Product Identifier", "LocationID", "Quantity"
    4. We should compare the values for Quantity and import in Hemi only the changed quantity products (or new inserts) and properly update the dates as well so it can be recognised by the stock recalculation
      1. SHOULD WE UPDATE THE DATE IF THERE IS NO DIFFERENCE? - Check with Product team and see implication for stock calculation - performance and accuracy
    5. We should be able to control and set an option to zero out all products not received in the file
      1. The way it should work is that we should check how many products are missing in the latest picked file compared to our previous import and set zero quantity (with relevant date updates too) for every product that is missing
      2. We should be able to set a blocker in place. The blocker should have a % difference between the latest file and the previous one. If the % difference is more than the set in Hemi the file should be blocked as a whole and Notification should be created (start with an email if set, notification center when ready)

  4. Price

    1. Map by SKU to items in Hemi
    2. Map by Account to the Product Account - this should be available in UI or in the file as mapping - discuss with Product team implications of removing this as mandatory field
    3. Price import should only update existing products accounts
    4. All fields are mapped to the Price fields directly (meaning there is no transformation or any specific value that we have to read and parse an action) - Fields are only "Price", "RRP", "Original Price", "VAT"
    5. If changes to "Price" or "RRP" we should flag the product for an update on the MP - discuss with Product team if we should include RRP in the mix now
    6. We want to have blockers in place to prevent huge price differences or notify in the event of such. There should be two price difference options
      1. Per the product - We should be able to set a % difference and if the price coming from the file differs with more perform the chosen action. Actions available should be block, notify, block+notify. Notifications should be originally sent via email and later added to the Notification center
      2. Per the file - We should be able to set a % difference and if there are more products in the file that have differences perform the action for the whole file. Actions available should be block, notify, block+notify. Block would mean block the whole file so we should not import any of the prices in it. Notifications should be originally sent via email and later added to the Notification center - discuss with Product team - this is a good to have but how often is it used? Prices are changed a lot? Do we want to keep this complication in? Have we ever used it?

  5. Bundles

    1. Map by SKU to the items in Hemi
    2. Map by Component SKU for creating the components. We should make a check by the mapped Component SKU if said item exists in Items and insert only existing items as components
    3. One bundle can have multiple SKUs as components BUT it can have only 1 occurrence of each SKU
    4. If we have Quantity mapped with value of "[DELETE]" we are to remove this bundle component from the bundle as a whole. Any other value that is not an int is to be blocked as validation issue
    5. All other fields are mapped to the Bundle Components section directly, no transformations, no other rules
Is this article helpful?
0 0 0