






VIZ
We have 3 views
> list
> grid
> detail

What about user feedback (b2b/b2c), vizualize statistics? vizalizse best wall?
=> should generate information useful to the retailer! user
When should we vizualize?
There should be an editor single/mass editing
Write a default order for offers?
Drag and dropable?
Select all?
Show items, which are missing information
Repair first-aid function to create a list of all items with missing info
Should dump and display!

There should be a selector and dumper, which can dump to many things.
> dump to wall/hanger?
  => where to the store dims come from? Retailer may provide
  => can use himself or ask brand to fill?
  => if shop-in-shop, hangers will be available as 3d sketch?
  => otherwise just do assortment, finished like in fashion mags
> dump to PDFBestandsliste
> dump to PDFline-sheet
> dump to recommendation
> dump to Inventur
> dump to picklist? or in import? with barcode?
> dump to PDFworkbook = image pix? must be supplied with products?
> dump to offer
> dump to Serie = cross-selling information
> dump to Shop > SELL (should check for validity to sell)
> dump to assortment = cross-selling information
> dump to stammdaten 
> dump to export (intersport, CSV/PRICAT)



The idea is that the user can select and group products and save the group or some information
on the group. By doing it this way, there is only one function (select and save) and when
saving the user



  




PRODUCTS = project
Stuff = tasks!
=================================================================
A IMPORT
Protcol:
> all this stuff requires a user and a protocol entry!
> don't forget we should have multiple barcodes (seller and buyer, order, return...)
Settings:
1. Erfassung
  > define default language
  > define product fields
  > use custom formats (downloadable)
  > include schemas = if want to sell on Amazon, check, Ebay check...
  > automatically required fieldlist for imports
  > fields for generating variants of a product = just type a list of comma values... like stack overflow
  > when doing so... we should also provide access to automatically map to generic categories (vs doing it later)
2. Erfassung Bestandsdaten für Wareneingang
  > Lager definieren
  > Zuordnung automatisch Y/N

1. Erfassung Produktdaten
  > manually = create a new product (SHORTCUT include quantity/quality check/returns)
  > manually = barcode scan (SHORTCUT requires 3rd party access, include quantity/qualitiy check/returns)
  > automatic = import a file
    > XML, CSV, EDI
      > CSV-default
      > CSV-custom
      > XML-custom
      > EDI-default (requires 3rd party acccess)
        > PRICAT für Hersteller/Fachhandel (requires 3rd party acccess)
        > DESADV für Hersteller/Fachhandel (requires 3rd party acccess)
  => when importing we generate core and variants
  => when importing we generate a default language file entry with article texts
     along with pointers to the multilanguage texts
  => question is what is being kept in core for fast search? Need brand and description, but in what language...!

2. Erfassung Bestandsdaten
  > warehoues should be determined on intake!
    > if only one warehouse, it should display which warehouse we are going to
    > if multiple warehouses, user can select and only if use changes, will it be switched
    > on delivery intake, warehouse can be preset or switched? or same as above?
  > intake
    > manually = item/barcode + qty - include quantity/quality check/returns)
    > barcode = qty >  requires 3rd party access, include quantity/qualitiy check/returns)
    > by delivery = requires 3rd party access (create scannable list with info on good/bad plus (Shortcut warehouse))
      > should include option to automatically intake delivery?
      > claims can also be done later?
      > what about missing qty?
    > automatic by EDI - DESADV, INVRPT
      > this is no automatic intake, just an automatic generation of what to intake
    > should also include returns from B2Cing...
  > after intake
    > finish
    > fehlender/fehlerhafte items claimen
    > automatic generation of documents to print or RECADV (Wareneingangs- und Differenzmeldung)

B CATALOGIZATION
Protocol:
> we need a media protocol and a media element for each core+dim or core
> before going live, this should be published to check whether images are
  available or not. If not, we do not display the products
> we should display in viz, if product has image or not and don't set
  products without images on sales!
> user should be able to auto-run a scan of all items to see what's missing

Settings:
1. Images
  > access from brand (requires 3rd party access! who pays?)
  OR
  > Upload and convert images Y/N (this is a service!)
    > resolutions
      > default+base64 (offline)
  > location from where to upload
  > store where
    > location
    > rent storeage (3D)
  > define image core filename = core style + dim + dim + dim?
  OR
  > pull images from supplied location
  > run a precheck to not do this in runtime, determine image status
2. Texts
  > Set default language (textfields will be stored under this language)
  > Pick languages shop should be available
3. Settings
  > Need to define default pricelist and currency
  > Need to define additional pricelists and currencies to be used
  > Need to specify the countries in which items are being sold (what for?)
  > Allocation of pricelist possible by country (B2C) or client/country (B2B, only if retailers pre-register)
  > We need some kind of allocation on what basis a price is used (per EAN, per Core)
    > what happens if a core product has multiple prices!!!

1. Images
  > Manual upload (display information m01, c01, ...)
    > drag and drop?
    > multiple files?
    > camera bei Neuanlage artikel (kennzeichen x for internal use only)
  > Automatic
    > with import > default = defined core + jpg/png Ende
    > with import advanced = JSON (default)
    > media API:
        x = internal  > x01.jpg, x02.jpg, x03.jpg...
        c = color icon> c01.jpg
        i = images    > i01.jpg, i02.jpg, i03.jpg...
        m = movies    > m01.fla, m02.mpeg, m03.mp2eg...
        d = 3d        > d01.jpg, d02.jpg, d03.jpg...
    > JSON: {"img":["01.jpg", "02.jpg", "03.jpg"], "color": ["c01.png"]...}
    > custom import would allow to do as many import fields as required and import field by field

2. Texts (Multilanguage)
  > if using multiple languages, user needs to provide language elements
  > include description, but also material, color, size translations
  > the core product will only include the header-description in all shop languages
    > question is if description will be searchable?
    > or do we also keep keywords per core products?
    > or do we allocate keywords based on category and mappings?
  > rest is kept in language table, stored by id
  > translations:
    > manual > webform, check how i18n is doing
    > automatic > import
      > user can import a CSV file with translations
      > user can import his own CSV with language fields
      > user can request translations - service?

3. Pricing
  > manual - enter prices in webform when adding product data
  > automatic - import with custom or default CSV
  > we should have EK, EK%, VK, VK% for every pricelist along with currency, name and EAN/core+dim?
    > alternative manuf, manufa%, buying, %buying, selling, %selling
  > a pricelist can have a scope
    > scope can be... B2B/B2C? a country? a marketplace? Not sure yet


4. Mappings
  > as currently, an import will extract all unique values from the import object
    and provide the user with a list of values to map to
  > values are stored even when removing underlying items
  > mapping categories
      > by hand = add comma,list,of,values
      > by import
        > import comma-list
        > import existing key (FEDAS etc)
        > import in custom-import
    > all provided internal kategories are available in all languages and along with all SEO and schema.org
      information, so the user must only map once
    > also, all mappings automatically allocate the correct categories for BTE, FEDAS, AMAZON, EBAY ...
      to a product, so the user does not have to do anything here anymore
    > mappings may include season and name, to fast id product ranges.
      > not sure yet, where to add and how...
  > mapping colors
    > nothing special, also map to everyone involved
  > mapping sizes
    > if the internal data would run by size ranges, the user could pick a size range per product, which
      could be available in international size ranges as well. Not sure size range is the best way to store
      but for the moment do it like this.

5. Cross-Selling
  > automatic
    > the user can import cross selling items in a field list
    > we don't differentiate between accessories and items, all cross-sellers are cross-sellers
  > manual
    > in VIZ, the user can make a selection, by tapping items and saving them as something
      > something could be a recommendation
      > something could be a linesheet
      > something could be a group of related articles for cross-selling
      > this way, easy and quick and visual to create ranges
      > when doing cross-selling, this could also be used to specify "collection names" for a series

C VIZUALITAION





  