Planning for Provi

This document was build to plan for the integration of Provi into WISK. It’s for a possible deep integration between the two companies

Table of content

• WISK Simplified data architecture
• Provi XLS data architecture (reverse engineered)
• A possible data structure for the WISK/Provi integration
• Use cases
  • Venues imported from Provi
  • Matching based on the WISK Distributors
  • Barcode scanning from the mobile app
• Venue in Wisk is a Retailer in Provi

WISK Simplified data architecture

classDiagram
Organization *-- Venue
Venue *-- Item
Venue *-- Invoices
Invoices *-- InvoiceLines
Venue *-- PurchaseOrders
PurchaseOrders *-- PurchaseOrdersLines
Item *-- Item_Variation
Item_Variation *-- Distributor
Venue *-- Country
Venue *-- Distributor
Venue *-- State
Distributor *-- WISKDistributor

class Organization {
    id: int
    name: string
}
class Venue{
    id: int
    organization_id: int
    name: String
    country: Country
    state: State
}
class Country {
    id: int
    name: String
}
class State {
    id: int
    name: String
    country_id: int
}
class Item{
    id: int
    name: String
    venue_id: int
}
class Item_Variation{
    id: int
    item_id: int
    variation_name: String
    quantity: double (ex: 1.3)
    unit_of_measurement(oz, lb, g, kg, etc)
    distributor_id: int
    distributor_code: String
    barcode: String
}
class Distributor{
    id: int 
    name: String
    venue_id: int
    wisk_distributor_id: int
    contacts: [Contact]
}
class WISKDistributor {
    id: int
    name: String
}
class Invoices {
    id: int
    distributor_id: int
    venue_id: int
}
class InvoiceLines {
    id: int
    invoice_id: int
    item_variation_id: int
    quantity: int
}
class PurchaseOrders {
    id: int
    distributor_id: int
    venue_id: int
}
class PurchaseOrdersLines {
    id: int
    purchase_order_id: int
    item_variation_id: int
    quantity: int
}

Provi XLS data architecture (reverse engineered)

classDiagram
    ProductLine *-- Product
    Product *-- Producer
    Product *-- Vendor
    Product *-- Country
    Product *-- Region
    Product *-- Supplier

    class ProductLine {
        +id: int    
        +name: string
    }
    class Product {
        +id: int
        +product_name: string
        +product_line_id: int
        +vendor_id: int
        +supplier_id: int
        +producer_id: int
        +sku: string
        +region_id: id
        +size: int
        +size_unit: string (ml/flOz/...)
        +container_type: string (bottle/can/...)
        +upc_code: string
    }
    class Vendor {
        +id: int
        +name: string
    }
    class Supplier {
        +id: int
        +name: string
    }
    class Producer {
        +id: int
        +name: string
    }
    class Country {
        +id: int
        +name: string
    }
    class Region {
        +id: int
        +name: string
    }

A possible data structure for the WISK/Provi integration

• An Item in WISK is a Product Line in Provi
• An ItemVariation in WISK is a Product in Provi
• the WISK Item will have a link to the Provi Product Line (provi_product_line_id)
• Within the WISK Item Variation we’ll have a link to a Provi Product (provi_product_id)

We’ll have a link in the WISK Distributor to a Provi Vendor (provi_vendor_id) Proposed changes to the WISK schema:

classDiagram
Item *-- Item_Variation
Item_Variation *-- Distributor
Item *-- Provi_Product_Line
Item_Variation *-- Provi_Product
Distributor *-- WISKDistributor
WISKDistributor *-- ProviVendor

class Item {
    id: int
    name: String
    provi_product_line_id: int
}
class Item_Variation {
    id: int
    name: String
    distributor_id: int
    distributor_code: String
    provi_product_id: int
}
class Provi_Product_Line {
    id: int
    name: String
}
class Provi_Product {
    id: int
    vendor_id: int
    name: String
    sku: String
}
class Distributor {
    id: int
    name: String
    provi_vendor_id: int
}
class WISKDistributor {
    id: int
    provi_vendor_id: int
    name: String
}
class ProviVendor {
    id: int
    name: String
}

Use cases

• the best way to match WISK Items to Provi products is using the Venue sku number
• the barcode matching should be used as a last resort when the client is using the WISK mobile app and the barcode scanner.
• It’s important that we have a clear understanding of the use cases for the integration. Here are the ones I can think of:

Venues imported from Provi

• For this we’ll have a single button in Provi to create a venue in WISK
• All the items already in their Provi account will be imported into the WISK venue
  • Will create the Items and ItemVariations
  • WISK will augment the data with the full and empty weights

Matching based on the WISK Distributors

In this scenario, the venue exists in both WISK and Provi, and the user wants to add a new item in WISK from an invoice:

• First we’ll need to make sure that Venue Distributors from WISK and Provi are linked
• Then based on Distributor Code we’ll match it to a venue sku in Provi
  • If the sku doesn’t exist in Provi we’ll need to show an exception to the user
• All ItemVariation in a WISK venue need to have a match to the Provi Product
  • If some are not matched we’ll show a list of the unmatched items to the user
  • The objective is to always have a 100% match between the two systems

Barcode scanning from the mobile app

During the inventory process the users can scan the barcodes of the items in the venue and the app will match the barcode to the item in WISK WISK currently prioritizes the match based on the following criteria:

sequenceDiagram
    Barcode->>+Organization: Find barcode
    Organization->>+VenueDistributors: Find barcode
    VenueDistributors->>+State: Find barcode
    State->>+Country: Find barcode

The proposed change is to first search the Provi database and then search the WISK database

sequenceDiagram
    Barcode->>+Organization: Find barcode in the 
    Organization->>+VenueDistributors: Find barcode
    VenueDistributors->>+ProviDatabase: Find barcode
    ProviDatabase->>+State: Find barcode
    State->>+Country: Find barcode

The proposed change is to search barcodes in the Provi database first and then search in the WISK database

• In the integration with Provi we’ll first find the barcode in the Provi database
• If we find more than one match we’ll show a list of the matches to the user and let them choose the correct one

---