0% found this document useful (0 votes)
1K views

Project Statement For Odoo Implementation

This document outlines EJAM's requirements for implementing Odoo to unify its various business platforms and systems. Key requirements include integrating inventory, order fulfillment, and shipping updates from three third-party warehouses into Odoo. The proposal also details customizing Odoo with additional modules, API integrations, and reports to improve business processes and provide dashboard views of key metrics. Implementation will include setting up default Odoo modules for sales, inventory, CRM, purchasing, and accounting, as well as additional third-party app installations, configurations, and customizations.

Uploaded by

Siva singh
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
1K views

Project Statement For Odoo Implementation

This document outlines EJAM's requirements for implementing Odoo to unify its various business platforms and systems. Key requirements include integrating inventory, order fulfillment, and shipping updates from three third-party warehouses into Odoo. The proposal also details customizing Odoo with additional modules, API integrations, and reports to improve business processes and provide dashboard views of key metrics. Implementation will include setting up default Odoo modules for sales, inventory, CRM, purchasing, and accounting, as well as additional third-party app installations, configurations, and customizations.

Uploaded by

Siva singh
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 13

PROJECT STATEMENT FOR ODOO I MPLEMENTATION V1.

03 3/13/2018
EJAM, INC.

This document and any communications with EJAM should be considered highly confidential. Neither the ideas
expressed herein, nor any part of this document or any other information or communications related thereto shall be
copied or disclosed to any party, nor shall they be used for any purpose other than meeting with representatives from
EJAM, without the written consent of EJAM. By accepting delivery of this document, the recipient agrees that:

I. in the event the recipient does not wish to pursue this matter, the recipient will return this copy to EJAM
II. the recipient will not copy, fax, reproduce or distribute this document, in whole or in part, without written
permission
III. all of the information contained herein will be treated as confidential material, and shall not be used for any
purposes other than evaluation.

EJAM, INC.

Contact: Frank Shen

Mobile: (909) 573-6056

Email: [email protected]

PROJECT STATEMENT FOR ODOO I MPLEMENTATION V1.03 3/13/2018


Table of Contents
I. 1.0 Objective
1.1 Baseline
1.2 Revision
II. 2.0 Review of Vertex China’s Requirements
2.1 Organizational Profile
2.2 Vertex China’s Requirement
2.3 EJAM’ Requirements
III. 3.0 Proposal and Hour Summary
3.2 Odoo Development
IV. 4.0 Estimated Timeline and Hours Summary
4.1 Estimated Timeline
V. 5.0 Billing and Invoice Structure
VI. 6.0 Assumptions and Exceptions
VII. 7.0 Signatures

1.0 Objective
EJAM is seeking development assistance to migrate its business’ core operation from various platforms to a unified
platform where the system is easy to expand and development resource is wider.

EJAM wishes to improve on: 3PL (3rd Party Logistic) warehouse integration (Rakuten, Amazon FBA) on inventory
levels, dispatches, & fulfillment; unified sales system by incorporating Customer Relation Management (CRM)
system; HelpDesk for customer service; basic accounting configuration; better inventory forecast between
procurement and 3PL (3rd Party Logistic) warehouses; user-friendly dashboard interface

Currently EJAM’s business invovles using or interacting the following system/platforms:

● SendGrid
● ChatFuel-
● Konnektive- Is the CRM- This is where products need to get created before deployment
on dashboard.

PROJECT STATEMENT FOR ODOO I MPLEMENTATION V1.03 3/13/2018


● AfterShip- Shipment tracking (Shopify plug-in?)
● ShipStation ??
● ZenDesk
● GOG
● Fatcher (Import Amazon Orders)
● Xcally
● Paypal
● Vantiv
● Shopify
● Twillio
● Zapier
● QuickBakg
● G.T.M.
● Centuries IO
● TaxJar
● G.A.
● FaceBook
● FunnelFlux
● Order Matrix
● Aliexpress
● Zapier
● QuickBooks

The ideal new system(s) will provide easy-to-use interface that limits user-training to the lowest possible; seamless
communications between team members, great reporting data for department managers, accounting report functions,
purchase and multiple 3PL warehouse management, inventory forecast and projection, 3PL shipping rate
integrations, easier order confirmation process with customers, and ability to have orders created in Odoo by
offering custom landing page to process credit card payments.

Desire for Automated Business Process Improvement:

● 3PL inventory, dispatch order, shipment rate & tracking update, inventory transfer via API or EDI
(Rakuten)
● 3PL inventory, dispatch order, shipment rate & tracking update, inventory transfer via API or EDI (Rapid
Fulfillment)
● 3PL inventory, dispatch order, shipment rate & tracking update, inventory transfer via flat file such as CSV
(Lansil)
● Partial/declined campaign generation for post-sale and abandon-cart operation
● 3rd Party Email marketing system integration
● Chargeback data import (Paypal Vantiv – WorldPay, Ebanx, Seezzle))
● Landing Page / Checkout Page javascript import via API
● Calculation of product margin & net costs
● Inventory forecasting ability
● Credit card transaction settlement automation through Paypal, WorldPay (Vantiv)
● Electronic bank reconciliation
● Automated emails for order confirmation & tracking update
● Trackable links for tracking numbers (USPS, UPS, FedEx, DHL) in Odoo and emails

PROJECT STATEMENT FOR ODOO I MPLEMENTATION V1.03 3/13/2018


● API integration for realtime tracking update in Odoo
● Automated emails for Purchase Orders
● Automated import of employee timesheets from TimeDoctor
● Customization & 3rd-party apps requirements are described here:
o https://docs.google.com/spreadsheets/d/1PGOz5YHRIqX6tIUFbaHZREzR6OzwxLff0BcMLnXac
YE/edit?usp=sharing

1.1 Baseline
This document presents the Project Statement for the implementation and customization of Odoo ERP and
represents an overview of EJAM’s requirements for this project.

1.2 Revision
You may request a revision to the Project Statement with knowledge that such revision may impact the scope and
timing of this Project Statement.

2.0 Review of EJAM’s Requirements


2.1 Organizational Profile
EJAM is an online retailer with multiple brands with presence in social media, search engines, Sopify store, affiliate
marketing, etc. EJAM is a multinational company which its 3 rd-party warehouses (products shipped a fulfilled by
3rd-parties, ex, Rakuten, Rapid Fulfillment, and Lansil) in China and America.

EJAM is looking for a system to unify the platforms that it’s currently using:

● Order management
● Fulfillment management with 3rd-party warehouses
● Inventory management with 3rd-party warehouses
● Helpdesk support tickets
● Purchasing document management
● Purchasing new product campaign management
● Accounting & tax reporting

2.2 EJAM’s Requirement


The requirements described below represent an overview of EJAM’s requirements.

Following are the major components:

● Sales
● Inventory
● CRM
● Purchase
● Invoicing
● Discuss
● Calendar

PROJECT STATEMENT FOR ODOO I MPLEMENTATION V1.03 3/13/2018


● Notes
● Contacts
● Manufacturing
● Project
● Timesheets
● Email Marketing
● Employees
● Expenses
● Dashboards
● Helpdesk (Customer Support)
● Custom Rakuten Shipping Charge Report
● Custom Dashboard Reports Commented [1]: Tell me about the reporting engine
● Custom Rakuten API Integration via CamptoCamp Connector module and it costs.
● Custom Rapid Fulfillment API Integration via CamptoCamp Connector module What reports come with the standard purchase of the
● 3rd Party Module Installation/Configuration/Customization platform and is every new reporting section an up
charge or a development charge?

Default Module Setup & Configurations Commented [2R1]: Default Odoo Purchase Analysis
module example:
https://screencast.com/t/YhKgXot9
SALES
If we create views, the charges are minimum; if
creating a report that the Purchase Analysis does not
Enable the following settings: support, then the charge is higher (ex, Dashboard
reports)
Product Packagings, Discounts, Multiple Sales Prices Per Product (Multiple prices per product (e.g.
customer segments, currencies)), Margins, Customer Account (On invitation), Customer Addresses,
Shipping Costs, Delivery Date, Order-Specific Routes, Invoice what is delivered

Customer Attributes:

Sales Order Status:

● Invoiced
● Partial (abandon cart, customer filled in partial contact information)
● Declined (credit card declined)
● Refunded (credit memo is created)
● Cancelled (Sales Order is cancelled and order is never fulfilled)

INVENTORY

Total Warehouse to Add:

Warehouse details:

https://docs.google.com/spreadsheets/d/1h85_x_2u-9Pj9wqHR9iJL6nXn_fyZghtiJ-
xRiX9Ua4/edit?usp=sharing

Inventory Tracking:

PROJECT STATEMENT FOR ODOO I MPLEMENTATION V1.03 3/13/2018


FIFO (create workflow to automatically select the earliest incoming lot for order fulfillments) Commented [3]: We need to discuss with the film and
Centers if they are capable of supporting FIFO and
serialized or lot based inventory
Enable the following settings:
Commented [4R3]: _Marked as resolved_
Landed Costs (Split Method: Quantity, Ex, Multi-Warehouses (Set Warehouse Routes based on Odoo Commented [5R3]: _Re-opened_
Shops), Lots & Serial Numbers
Commented [6R3]: I think you mean the fulfillment
centers; 2 out of 3 supports lot/serials (Rakuten and
Pacurate.io, Direct Injection via DHL, order Routing Logic (at carrier, location, inventory) - real time RapidFulfillment). However the purpose is to retrieve
costing, etc. - see Shipwire’s functionality the average costs based on previous/new purchased
prices minus previous inventories which are already
sold and shipped, I think we can use lots/serials with
fulfillment centers in the future. Our shipments from
China will also need to bear an additional barcode for
lot/serial numbers.

Warehouse Inventory Reorder Points:

● Total Inventory Qty divided by Daily Sales Velocity (Average sales of last 7 days) = # of days
left in inventory
● “Total Inventory Qty divided by Daily Sales Velocity (Average sales of last 7 days) = # of
days left in inventory)” - Factory Lead Time + Shipping Lead Time = Days we need to
reorder
● EX: Wash Wizard: Total inventory: 5551/283 = 19.6 Days until out of Inventory
● Ex: 19.62 - (12 Days Factory Lead Time + 10 Days Air Freight) = -4 (Days Until Reorder
(Airfreight))
● Ex: 19.62 - (12 Days Factory Lead Time + 10 Days Air Freight) = -4 (Days Until Reorder
(Fast Boat))

Example

PROJECT STATEMENT FOR ODOO I MPLEMENTATION V1.03 3/13/2018


CRM Commented [7]: This seems to be completely related
to Zendesk, as any thought or planning been put into
dealing with wholesale customers?
Enable: Leads, Phone Formatting (Add international prefix)
This section of the ERP is ideal for dealing with this.
Sales Teams:
Can the vendor object in the ERP also be used to take
people through workflow?
● America
● Mexico Commented [8R7]: 1. We can synchronize data from
Zendesk

Lead Generation Stage: 2. I agree

3. I do not understand your question


● New
● Open (when Salesperson is assigned)
● Won
● Lost

Stage Filters:

● Brand
● Shops
● Country (use shipping address country first; if not available, use bill-to address country)

Lost Reasons:

● DC – Disconnected Numbers
● DNC – Do Not Call
● NA – Not Available
● NI – Not Interested

Lead Generation Rules:

a) Partials – all customers with status of Sales Order in “Partial”

PROJECT STATEMENT FOR ODOO I MPLEMENTATION V1.03 3/13/2018


b) Declined – all customers with status of Sales Order in “Declined”
c) Order Confirmation – all customers who places new order and status of Sales Order is
“Paid”

PURCHASE

Enable the following settings: Commented [9]: When the time comes to implement
this, make sure that we discuss how deposit payments
will be posted against the balance sheet to avoid
● Purchase Order Approval, Bill Control (Delivered quantities)
inventory paid but not received situations like we had in
previous companies
Purchase order workflow:
Commented [10R9]: This should be a controllable
user process to always pay the remaining balance only
● Request for Quotation after shipment is ready to go out and booking of
● Email vendor PQ in PDF container has scheduled.
● Vendor confirmation
● Odoo user uploads vendor Performa Invoice We can also add a system validation process to require
Odoo user to click a button or update BOL numbers to
● Confirm PQ (Purchase Quote) to create PO (Purchase Order) validate shipment before final payment can be made by
● Managers Validates PO accounting.
● Send PO to vendor
● Odoo user uploads vendor invoices
● Odoo user creates Bill for initial deposit
● Odoo user notifies accounting department for remaining balance
● Accounting Validates Bill in Odoo
● Accounting Register Payment in Odoo
● Accounting Validates payment
● Odoo users adds Landed Cost (freight charge) to PO
● Odoo user confirms inventory receipt in Odoo

Odoo system workflow:

● https://drive.google.com/file/d/1zrRqWEitGQ-
DCw6OoztdYoqbrURMKOn3/view?usp=sharing

Purchase Order layout sample:

● Revise Odoo Purchase Order format to match current format


● Sample format:
https://drive.google.com/file/d/1R0Cv9Qoi1CzOWKL_sHWrWIO-UkUqXLIz/view?usp=sharing

INVOICING

Enable the following settings:

● Main Currency: USD


● Multi-Currencies

Chart of Accounts:

● Import from here:


https://docs.google.com/spreadsheets/d/1gssoT9n8E2AmNuoKDoT103Mk4DwtdrkbdLpNxg
-sBZU/edit?usp=sharing

PROJECT STATEMENT FOR ODOO I MPLEMENTATION V1.03 3/13/2018


Currencies:

● USD
● EUR
● Install Currency Converter App for daily exchange rate update:
https://www.odoo.com/apps/modules/12.0/xe_currency_converter/

Tax:

● Taxes are used only when the state of customer’s shipping address is the same as the ship-from
warehouse’s state Commented [11]: This is an incorrect statement, and
● Import taxes for states where warehouses are located in the U.S. needs to be updated with 2019 tax laws
● Connect to an external platform to download sales tax rates
Commented [12R11]: TaxJar is an app that provides
o Import sales tax (based on counties level) via API (once a day, overwrite) via TaxJar
realtime tax rates by counties. This project is to
connector connect to an external platform to download sales tax
o Reference module: rates
https://github.com/LasLabs/odoo-connector-taxjar

o Reference API document:


https://developers.taxjar.com/api/reference/#get-list-tax-categories

Bank Accounts:

● Physical Bank: 8 Commented [13]: Limitation here on Numbers? Why is


● Paypal: 8 this number in here? I want to understand the process
and or the cost of product and or development when
adding a bank account
Payment Terms:
Commented [14R13]: We are adding them ourselves
● Credit Cards (Number of Days: 0)
● Paypal (Number of Days: 0)

Payment Acquirers:

● Credit Cards (Number of Days: 0)

CALENDAR

● Install & activate default module


● Set up will be performed internally

NOTES

● Install & activate default module


● Set up will be performed internally Commented [15]: Are we currently operating on the
bill of materials? Or are we operating with assembly
items? I want to make sure that we actually need this
CONTACTS module, or if we are doing kits/virtual bundles instead
of actual assembly’s
● Install & activate default module Commented [16R15]: This is called Phantom BOM.
● Set up will be performed internally The system automatically builds them for the items we
sell in packs/sets. The products that we sell in
packs/sets, ex, 3 packs of Clear Air (if base product is
MANUFACTURING
1 pack of Clear Air), then we create a product for 3
packs of Clear Air and the product type is consumable.

PROJECT STATEMENT FOR ODOO I MPLEMENTATION V1.03 3/13/2018


● Install & activate default module
● Set up sample product bundle (ex, selling 3 units of SKU ABC at the same time) using Phantom
BOM
● Phantom BOM Options:
o No variants on products
o No by-products in bills of materials (A+BC)
● Sample BOM:
o SKU: PEST-DEFENDER_2 (“_numbers” refers to number of units inside the BOM, base
product here is “PEST-DEFENDER”)
o Qty: 2 X base product PEST-DEFENDER
o Product Type: Consumable

TIMESHEETS

● Install & activate default module


● Import employee timesheets via API from Time Doctor
● Generate timesheet report
o Sample report format:
o https://drive.google.com/file/d/1rtOAG-
MJl_MDHXuQ19E2q2WCkECdRyRG/view?usp=sharing

● Time Doctor API reference:


o https://support2.timedoctor.com/en/
Commented [17]: Will the EMS be Odoo, this module
EMAIL MARKETING does not seem necessary from an email marketing
standpoint, however being able to email invoices and
purchase orders from the system does seem to be very
● Install & activate default module useful.
Commented [18R17]: Paul has mentioned that we are
EMPLOYEES currently using SendGrid for email marketing and we
will only need to install the module to connect
SendGrid.
● Install & activate default module
● Set up will be performed internally Commented [19]: A substantial amount of the
expenses for this company flow through credit card
purchases to digital marketing companies like
EXPENSES Facebook and Google, how is this handled inside of
overdue from an expense account, and or budget?
● Install & activate default module
● Set up will be performed internally Most e-commerce expenses also will flow through to
the credit card and are not paid on an invoice level but
are paid on the automatic billing level? Does this
Orders & Fulfillment platform allow for this type of business in the expense
module?

Workflow: https://drive.google.com/open?id=1afV6F5kbE1mzjpGxaTpwlCL2eHc2pBzD Commented [20]: This is sufficient for the current set
up, but how will we integrate via API, EDI, or CSV
upload for clients other than the ones contemplated on
Requirements: this list?
Commented [21R20]: The system has framework to
support all three types of data feed that you mentioned;
● New order data are separated into the following types: the GoogleSheet for 3rd-party modules includes
o Shopify installation for CSV/API imports. Additionally Odoo
o Landing Pages (EJAM Dashboard) supports EDI; developer will just need to make
templates matching client's EDI templates.
o Phone Orders (entered manually by Odoo users)
Commented [22]: Does the system support line item
o Amazon (FBA)
level for film it from different physical locations? If so
● Product location: has that and contemplated in this implementation?
o Rakuten Commented [23R22]: I am not sure I understand your
question; can you give me more information?

PROJECT STATEMENT FOR ODOO I MPLEMENTATION V1.03 3/13/2018


o Rapid Fulfillment
o Lansil
o FBA

Odoo Operation Process for Landing Pages:

● Upon checkout, when submitting payment, if credit card is selected as payment type,
payment data is sent from EJAM Dashboard (a Heroku Platform) via API to Odoo and
use Emipro Odoo WorldPay Payment Acquirer module to collect payment
o The payment status (ex, Authorized, Captured, Authorized & Captured,
Declined) needs to create respond in API
o Odoo Sales Order Number and Invoice Number needs to be responded in API as
well
● Upon checkout, when submitting payment, if Paypal is selected as payment type,
payment data is sent via API to Odoo and use Forfens Tech’s PayPal Payflow Pro
Payment Gateway app to collect payment

Custom Rakuten Shipping Charge Reports Commented [24]: Are we currently passing live rates
through the shopping cart, or do we work off of a
weight-based chart for our estimated charges?
Purpose: Compare the price that Rakuten charges us against the estimated shipping charges based on
agreed charges from Rakuten’s invoice I would like to see how this works. In the past I have
created a custom fields and have been able to pull into
each sales order and do a cash sale line item cost from
Integration: a three PL for reconciliation purposes.
Commented [25R24]: We do not passing live rates;
● Use “Shipping Charge” from Rakuten’s API feed we currently offer free-shipping on all products
● Actual Shipping Charge = Handling Charges (from Correct, this requires creating fields called "Expected
https://drive.google.com/file/d/1Qn6wfgHKhAqmBK_5KW0EpWOuXWAK8uR4/view?usp=shar Shipping Charge" and "Actual Shipping Charge" for
sales orders, then the reconciliation can be at per
ing) + Discount
transaction level.
● Handling Charge = Projected number of packages based on average packages per day for the
current month;
o ex, if projected monthly packages shipped by Rakuten Warehouse in Odoo is 5001, the
handling charge per box is $1.17 per package (shipping box)

Customization:

● Calculate dimensional Weight of each package (Length x Width x Height / 139)


● Use estimated shipping box size to compare if actual shipping weight is lower than dimensional weight; if
it is, use dimensional weight
● Custom Rakuten Shipping Charge Report

Report Sample in Excel:

● https://docs.google.com/spreadsheets/d/1hEiuNK4w_g23OL-
iFWzhzwR0b3qscnx4rL_FXuyVu_U/edit?usp=sharing
● Report should include export in PDF and Excel (CSV)

PROJECT STATEMENT FOR ODOO I MPLEMENTATION V1.03 3/13/2018


Rakuten Shipping Rates Example:

● https://docs.google.com/spreadsheets/d/14aUB_6SZUD9V3PkdWW6r6hfpcamjjEGs9oPaYswP70k/edit?us
p=sharing

3.0 Assumptions and Exceptions


This list covers all of the assumptions and exceptions that EJAM makes. Please note, these are generic assumptions
and my not apply specifically to this project.

● Developer will move any added files in the upgrade, make sure core modification to any JS or prototype
files will not be overwritten on upgrade.
● EJAM will provide a list of these files in advance.
● Developer understands that all third party modules, along with any local overrides, must be tested.
● EJAM will be responsible for the purchase of any modules that need to be acquired unless otherwise
specified by EJAM.
● Developer will test the functionality of site using the default theme. The tests will include the following:
access to the admin panel, functioning crons.
● Developer will receive full access to the decided upon hosting environment. This includes: root access to
the server via SSH, and access to and credentials for other relevant services such as PostgresSQL and
SFTP/SCP .
● Developer will notify EJAM prior to any downtime on the live site.
● Developer will offer testing to EJAM at critical junctures to ensure proper UAT.

7.0 Signatures

Print Name, Title

COMPANY NAME
_____________________________________________________ __________________
Authorized Signature Date

Signatures in the boxes above indicated acceptance the original Project Statement as described. Authorized
signatures are those from individuals with the rights to sign contracts on behalf of their organizations. Any changes
to the original document must be made through the Change Order Management System.

PROJECT STATEMENT FOR ODOO I MPLEMENTATION V1.03 3/13/2018

You might also like