Compare commits
41 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 391ea762bc | |||
| 6f74248de1 | |||
| be0b5e65d5 | |||
| 83b6895deb | |||
| 16537bb9c5 | |||
| 71e2a50d40 | |||
| 514c175824 | |||
| 65e7f1b3c5 | |||
| d362d4ebdb | |||
| 1aee294219 | |||
| d8cd13b659 | |||
| 2f5e130179 | |||
| d5fd2f1c66 | |||
| 92c5c3db31 | |||
| bed068f95a | |||
| 7212fc98cd | |||
| 3b40e6c1ec | |||
| d2497d2b14 | |||
| 5965bad8ea | |||
| ee8aed02c8 | |||
| 17787e62c3 | |||
| 7ecaf74124 | |||
| afbc491940 | |||
| b3e2b51a6a | |||
| acf8d5e4a7 | |||
| 916b185065 | |||
| 93a0f41756 | |||
| bf9bbff058 | |||
| 32976cdd84 | |||
| 00e96e5635 | |||
| c4fd10f94e | |||
| 10a92e66cf | |||
| 634a5af824 | |||
| 53f8dcd991 | |||
| a535d2fe9d | |||
| cb51299cf1 | |||
| a42a88bf7c | |||
| 8cea31c24d | |||
| d03b45c6f9 | |||
| e238e63240 | |||
| e14c53b60c |
@@ -2,6 +2,9 @@
|
||||
Export and import data
|
||||
======================
|
||||
|
||||
.. |list| replace:: :icon:`oi-view-list` :guilabel:`(list)` icon
|
||||
.. |actions| replace:: :icon:`fa-cog` :guilabel:`Actions`
|
||||
|
||||
In Odoo, it is sometimes necessary to export or import data for running reports, or for data
|
||||
modification. This document covers the export and import of data into and out of Odoo.
|
||||
|
||||
@@ -20,9 +23,9 @@ can aid in reporting on activities, although, Odoo provides a precise and easy r
|
||||
each available application.
|
||||
|
||||
With Odoo, the values can be exported from any field in any record. To do so, activate the list view
|
||||
(:guilabel:`≣ (four horizontal lines)` icon), on the items that need to be exported, and then
|
||||
select the records that should be exported. To select a record, tick the checkbox next to the
|
||||
corresponding record. Finally, click on :guilabel:`⚙️ Action`, and then :guilabel:`Export`.
|
||||
(|list|), on the items that need to be exported, then select the records that should be exported. To
|
||||
select a record, tick the checkbox next to the corresponding record. Finally, click on |actions|,
|
||||
then :guilabel:`Export`.
|
||||
|
||||
.. image:: export_import_data/list-view-export.png
|
||||
:align: center
|
||||
@@ -36,9 +39,10 @@ several options for the data to export:
|
||||
:alt: Overview of options to consider when exporting data in Odoo..
|
||||
|
||||
#. With the :guilabel:`I want to update data (import-compatable export)` option ticked, the system
|
||||
only shows the fields that can be imported. This is helpful in the case where the existing
|
||||
records need to be updated. This works like a filter. Leaving the box unticked, gives many more
|
||||
field options because it shows all the fields, not just the ones that can be imported.
|
||||
only shows the fields that can be imported. This is helpful in the case where the :ref:`existing
|
||||
records need to be updated <essentials/update-data>`. This works like a filter. Leaving the box
|
||||
unticked, gives many more field options because it shows all the fields, not just the ones that
|
||||
can be imported.
|
||||
#. When exporting, there is the option to export in two formats: `.csv` and `.xls`. With `.csv`,
|
||||
items are separated by a comma, while `.xls` holds information about all the worksheets in a
|
||||
file, including both content and formatting.
|
||||
@@ -70,7 +74,8 @@ Import data into Odoo
|
||||
=====================
|
||||
|
||||
Importing data into Odoo is extremely helpful during implementation, or in times where data needs to
|
||||
be updated in bulk. The following documentation covers how to import data into an Odoo database.
|
||||
be :ref:`updated in bulk <essentials/update-data>`. The following documentation covers how to import
|
||||
data into an Odoo database.
|
||||
|
||||
.. warning::
|
||||
Imports are permanent and **cannot** be undone. However, it is possible to use filters (`created
|
||||
@@ -158,6 +163,9 @@ Once the template is downloaded, proceed to follow these steps:
|
||||
using the fields that should be imported. This way, if there is not a sample import template,
|
||||
the names are accurate.
|
||||
|
||||
|
||||
.. _essentials/external-id:
|
||||
|
||||
Import from another application
|
||||
-------------------------------
|
||||
|
||||
@@ -166,7 +174,8 @@ from previous software to facilitate the transition to Odoo.
|
||||
|
||||
Setting an ID is not mandatory when importing, but it helps in many cases:
|
||||
|
||||
- Update imports: import the same file several times without creating duplicates.
|
||||
- :ref:`Update imports <essentials/update-data>`: import the same file several times without
|
||||
creating duplicates.
|
||||
- :ref:`Import relation fields <export_import_data/relation-fields>`.
|
||||
|
||||
To recreate relationships between different records, the unique identifier from the original
|
||||
@@ -176,10 +185,7 @@ When another record is imported that links to the first one, use **XXX/ID** (XXX
|
||||
the original unique identifier. This record can also be found using its name.
|
||||
|
||||
.. warning::
|
||||
It should be noted that there will be a conflict if two or more records have the same name.
|
||||
|
||||
The :guilabel:`External ID` (ID) can also be used to update the original import, if modified data
|
||||
needs to be re-imported later, therefore, it is a good practice to specify it whenever possible.
|
||||
It should be noted that conflicts occur if two (or more) records have the same *External ID*.
|
||||
|
||||
Field missing to map column
|
||||
---------------------------
|
||||
@@ -476,3 +482,43 @@ The two files produced are ready to be imported in Odoo without any modification
|
||||
imported these two :abbr:`CSV (Comma-separated Values)` files, there are four contacts and three
|
||||
companies (the first two contacts are linked to the first company). Keep in mind to first import
|
||||
the companies, and then the people.
|
||||
|
||||
.. _essentials/update-data:
|
||||
|
||||
Update data in Odoo
|
||||
===================
|
||||
|
||||
Existing data can be updated in bulk through a data import, as long as the :ref:`External ID
|
||||
<essentials/external-id>` remains consistent.
|
||||
|
||||
Prepare data export
|
||||
-------------------
|
||||
|
||||
To update data through an import, first navigate to the data to be updated, and select the |list| to
|
||||
activate list view. On the far-left side of the list, tick the checkbox for any record to be
|
||||
updated. Then, click |actions|, and select :icon:`fa-upload` :guilabel:`Export` from the drop-down
|
||||
menu.
|
||||
|
||||
On the resulting :guilabel:`Export Data` pop-up window, tick the checkbox labeled, :guilabel:`I want
|
||||
to update data (import-compatible export)`. This automatically includes the *External ID* in the
|
||||
export. Additionally, it limits the :guilabel:`Fields to export` list to **only** include fields
|
||||
that are able to be imported.
|
||||
|
||||
.. note::
|
||||
The :guilabel:`External ID` field does **not** appear in the :guilabel:`Fields to export` list
|
||||
unless it is manually added, but it is still included in the export. However, if the :guilabel:`I
|
||||
want to update data (import-compatible export)` checkbox is ticked, it is included in the export.
|
||||
|
||||
Select the required fields to be included in the export using the :ref:`options <export-data>` on
|
||||
the pop-up window, then click :guilabel:`Export`.
|
||||
|
||||
Import updated data
|
||||
-------------------
|
||||
|
||||
After exporting, make any necessary changes to the data file. When the file is ready, it can be
|
||||
:ref:`imported <import-data>` by following the same process as a normal data import.
|
||||
|
||||
.. danger::
|
||||
When updating data, it is extremely important that the *External ID* remain consistent, as
|
||||
this is how the system identifies a record. If an ID is altered, or removed, the system may add a
|
||||
duplicate record, instead of updating the existing one.
|
||||
|
||||
@@ -181,6 +181,75 @@ It is possible to *customize groups* by using a field present on the model. To d
|
||||
cluster, the next one that is added further divides the main group's categories, and so on.
|
||||
Furthermore, filters and groups can be used together to refine the view even more.
|
||||
|
||||
.. _search/comparison:
|
||||
|
||||
Comparison
|
||||
==========
|
||||
|
||||
Certain reporting dashboards include a :guilabel:`Comparison` section in the drop-down menus of
|
||||
their :guilabel:`Search...` bars. This includes the :doc:`Overall Equipment Effectiveness
|
||||
<../inventory_and_mrp/manufacturing/workflows/oee>` report for the *Manufacturing* app, and the
|
||||
:doc:`Purchase <../inventory_and_mrp/purchase/advanced/analyze>` report for the *Purchase* app,
|
||||
among others.
|
||||
|
||||
The options in the :icon:`fa-adjust` :guilabel:`Comparison` section are used to compare data from
|
||||
two different time periods. There are two comparison options to choose from: :guilabel:`(Time
|
||||
Filter): Previous Period` and :guilabel:`(Time Filter): Previous Year`.
|
||||
|
||||
.. important::
|
||||
For some reports, the :guilabel:`Comparison` section **only** appears in the
|
||||
:guilabel:`Search...` bar drop-down menu if one (or more) time periods have been selected in the
|
||||
:guilabel:`Filters` column. This is because, if no time period is specified, there is nothing to
|
||||
compare.
|
||||
|
||||
Additionally, some reports only allow use of the :guilabel:`Comparison` feature when the
|
||||
:icon:`fa-pie-chart` :guilabel:`(pie chart)` graph type, or the :icon:`oi-view-pivot`
|
||||
:guilabel:`(pivot)` view, is selected. A :guilabel:`Comparison` option can be selected even if
|
||||
another view is enabled, but doing so does **not** change the way data is displayed on the
|
||||
report.
|
||||
|
||||
.. image:: search/comparison-section.png
|
||||
:align: center
|
||||
:alt: The Search... bar for the production analysis report.
|
||||
|
||||
To view data using one of the two comparisons, begin by selecting a time period in the
|
||||
:guilabel:`Filters` column of the :guilabel:`Search...` bar drop-down menu. Then, select either
|
||||
:guilabel:`(Time Filter): Previous Period` or :guilabel:`(Time Filter): Previous Year` in the
|
||||
:guilabel:`Comparison` section.
|
||||
|
||||
With one of the :guilabel:`Comparison` options enabled, the report compares the data for the
|
||||
selected period, with the data for the same unit of time (month, quarter, year), one period or year
|
||||
prior. The way the data is displayed depends on the selected view:
|
||||
|
||||
- The :icon:`fa-bar-chart` :guilabel:`(bar chart)` shows two bars, side-by-side, for each unit of
|
||||
time for the selected time period. The left bar represents the selected time period, while the
|
||||
right bar represents the previous time period.
|
||||
- The :icon:`fa-line-chart` :guilabel:`(line chart)` is displayed with two lines, one representing
|
||||
the selected time period, and the other representing the previous time period.
|
||||
- The :icon:`fa-pie-chart` :guilabel:`(pie chart)` appears as a large circle with a smaller circle
|
||||
inside. The larger circle represents the selected time period, while the smaller circle represents
|
||||
the previous time period.
|
||||
- The :icon:`oi-view-pivot` :guilabel:`(pivot table)` is displayed with each column split into two
|
||||
smaller columns. The right column represents the selected time period, while the left column
|
||||
represents the previous time period.
|
||||
|
||||
.. example::
|
||||
In the :guilabel:`Production Analysis` report of the :menuselection:`Manufacturing` app, data for
|
||||
the second quarter of 2024 is compared to data for the second quarter of 2023. :guilabel:`Q2` is
|
||||
selected in the :guilabel:`End Date` filter section of the :guilabel:`Search...` bar drop-down
|
||||
menu. In the :guilabel:`Comparison` section, :guilabel:`End Date: Previous Year` is selected.
|
||||
|
||||
The current year is 2024, so the larger circle shows data for the second quarter (Q2) of 2024.
|
||||
The smaller circle shows data for the second quarter (Q2) of 2023, which is the same time period,
|
||||
but one *year* prior.
|
||||
|
||||
If :guilabel:`End Date: Previous Period` is selected instead, the smaller circle shows data for
|
||||
the first quarter (Q1) of 2024, which is the same time period, but one *period* prior.
|
||||
|
||||
.. image:: search/comparison.png
|
||||
:align: center
|
||||
:alt: The comparison view of the Production Analysis report.
|
||||
|
||||
.. _search/favorites:
|
||||
|
||||
Favorites
|
||||
|
||||
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 31 KiB |
@@ -5,8 +5,8 @@ Expenses
|
||||
========
|
||||
|
||||
Odoo **Expenses** streamlines the management of expenses. After an employee submits their expenses
|
||||
in Odoo, the expenses are reviewed by management and accounting teams. Once approved, payments can
|
||||
then be processed and disbursed back to the employee for reimbursement(s).
|
||||
in Odoo, they are reviewed by management and accounting teams. Once approved, payments can then be
|
||||
processed, and disbursed back to the employee for reimbursement.
|
||||
|
||||
.. seealso::
|
||||
`Odoo Expenses: product page <https://www.odoo.com/app/expenses>`_
|
||||
@@ -62,16 +62,16 @@ report the actual cost when submitting an expense report.
|
||||
Here are some examples for when to set a specific :guilabel:`Cost` on a product vs. leaving the
|
||||
:guilabel:`Cost` at `0.00`:
|
||||
|
||||
- **Meals**: Set the :guilabel:`Cost` to `0.00`. When an employee logs an expense for a meal,
|
||||
- **Meals**: set the :guilabel:`Cost` to `0.00`. When an employee logs an expense for a meal,
|
||||
they enter the actual amount of the bill and will be reimbursed for that amount. An expense for
|
||||
a meal costing $95.23 would equal a reimbursement for $95.23.
|
||||
- **Mileage**: Set the :guilabel:`Cost` to `0.30`. When an employee logs an expense for
|
||||
- **Mileage**: set the :guilabel:`Cost` to `0.30`. When an employee logs an expense for
|
||||
"mileage", they enter the number of miles driven in the :guilabel:`Quantity` field, and are
|
||||
reimbursed 0.30 per mile they entered. An expense for 100 miles would equal a reimbursement for
|
||||
$30.00.
|
||||
- **Monthly Parking**: Set the :guilabel:`Cost` to `75.00`. When an employee logs an expense for
|
||||
- **Monthly Parking**: set the :guilabel:`Cost` to `75.00`. When an employee logs an expense for
|
||||
"monthly parking", the reimbursement would be for $75.00.
|
||||
- **Expenses**: Set the :guilabel:`Cost` to `0.00`. When an employee logs an expense that is not
|
||||
- **Expenses**: set the :guilabel:`Cost` to `0.00`. When an employee logs an expense that is not
|
||||
a meal, mileage, or monthly parking, they use the generic :guilabel:`Expenses` product. An
|
||||
expense for a laptop costing $350.00 would be logged as an :guilabel:`Expenses` product, and
|
||||
the reimbursement would be for $350.00.
|
||||
@@ -98,10 +98,10 @@ the default :guilabel:`My Expenses` view. This view can also be accessed from
|
||||
|
||||
First, click :guilabel:`New`, and then fill out the various fields on the form.
|
||||
|
||||
- :guilabel:`Description`: Enter a short description for the expense in the :guilabel:`Description`
|
||||
- :guilabel:`Description`: enter a short description for the expense in the :guilabel:`Description`
|
||||
field. This should be short and informative, such as `lunch with client` or `hotel for
|
||||
conference`.
|
||||
- :guilabel:`Category`: Select the expense category from the drop-down menu that most closely
|
||||
- :guilabel:`Category`: select the expense category from the drop-down menu that most closely
|
||||
corresponds to the expense. For example, an airplane ticket would be appropriate for an expense
|
||||
:guilabel:`Category` named :guilabel:`Air Travel`.
|
||||
- :guilabel:`Total`: Enter the total amount paid for the expense in one of two ways:
|
||||
@@ -119,7 +119,7 @@ First, click :guilabel:`New`, and then fill out the various fields on the form.
|
||||
cost *per mile*. Set the :guilabel:`Quantity` to the *number of miles* driven, and the total
|
||||
is calculated.
|
||||
|
||||
- :guilabel:`Included Taxes`: If taxes were configured on the expense category, the tax percentage
|
||||
- :guilabel:`Included Taxes`: if taxes were configured on the expense category, the tax percentage
|
||||
and amount appear automatically after entering either the :guilabel:`Total` or the
|
||||
:guilabel:`Quantity`.
|
||||
|
||||
@@ -127,20 +127,20 @@ First, click :guilabel:`New`, and then fill out the various fields on the form.
|
||||
When a tax is configured on an expense category, the :guilabel:`Included Taxes` value will
|
||||
update in real time as the :guilabel:`Total` or :guilabel:`Quantity` is updated.
|
||||
|
||||
- :guilabel:`Employee`: Using the drop-down menu, select the employee this expense is for.
|
||||
- :guilabel:`Paid By`: Click the radio button to indicate who paid for the expense and should be
|
||||
- :guilabel:`Employee`: using the drop-down menu, select the employee this expense is for.
|
||||
- :guilabel:`Paid By`: click the radio button to indicate who paid for the expense and should be
|
||||
reimbursed. If the employee paid for the expense (and should be reimbursed) select
|
||||
:guilabel:`Employee (to reimburse)`. If the company paid directly instead (e.g. if the company
|
||||
credit card was used to pay for the expense) select :guilabel:`Company`. Depending on the expense
|
||||
category selected, this field may not appear.
|
||||
- :guilabel:`Bill Reference`: If there is any reference text that should be included for the
|
||||
- :guilabel:`Bill Reference`: if there is any reference text that should be included for the
|
||||
expense, enter it in this field.
|
||||
- :guilabel:`Expense Date`: Using the calendar module, enter the date the expense was incurred. Use
|
||||
- :guilabel:`Expense Date`: using the calendar module, enter the date the expense was incurred. Use
|
||||
the :guilabel:`< (left)` and :guilabel:`> (right)` arrows to navigate to the correct month, then
|
||||
click on the specific day to enter the selection.
|
||||
- :guilabel:`Account`: Select the expense account that this expense should be logged on from the
|
||||
- :guilabel:`Account`: select the expense account that this expense should be logged on from the
|
||||
drop-down menu.
|
||||
- :guilabel:`Customer to Reinvoice`: If the expense is something that should be paid for by a
|
||||
- :guilabel:`Customer to Reinvoice`: if the expense is something that should be paid for by a
|
||||
customer, select the :abbr:`SO (Sales Order)` and customer that will be invoiced for this expense
|
||||
from the drop-down menu. All sales orders in the drop-down menu list both the :abbr:`SO (Sales
|
||||
Order)` as well as the company the sales order is written for, but after the expense is saved, the
|
||||
@@ -152,14 +152,13 @@ First, click :guilabel:`New`, and then fill out the various fields on the form.
|
||||
expenses tied to that meeting would indicate the sales order for the custom garden (which also
|
||||
references the customer) as the :guilabel:`Customer to Reinvoice`.
|
||||
|
||||
- :guilabel:`Analytic Distribution`: Select the account(s) the expense should be written against
|
||||
from the drop-down menu for either :guilabel:`Projects`, :guilabel:`Departments`, or both.
|
||||
Multiple accounts can be listed for each category if needed. Adjust the percentage for each
|
||||
analytic account by typing in the percentage value next to the account.
|
||||
- :guilabel:`Company`: If multiple companies are set up, select the company this expense should be
|
||||
filed for from the drop-down menu. The current company will automatically populate this field.
|
||||
- :guilabel:`Notes...`: If any notes are needed in order to clarify the expense, enter them in the
|
||||
notes field.
|
||||
- :guilabel:`Analytic Distribution`: select the accounts the expense should be written against from
|
||||
the drop-down menu for either :guilabel:`Projects`, :guilabel:`Departments`, or both. Multiple
|
||||
accounts can be listed for each category, if needed. Adjust the percentage for each analytic
|
||||
account by typing in the percentage value next to the account.
|
||||
- :guilabel:`Company`: if multiple companies are set up, select the company this expense should be
|
||||
filed for from the drop-down menu. The current company automatically populates this field.
|
||||
- :guilabel:`Notes...`: if any notes are needed to clarify the expense, enter them in this field.
|
||||
|
||||
.. image:: expenses/expense-filled-in.png
|
||||
:align: center
|
||||
@@ -263,110 +262,6 @@ appears: :guilabel:`Use this reference as a subject prefix when submitting by em
|
||||
- The :guilabel:`Internal Reference` for the expense category `Meals` is `FOOD`
|
||||
- The :guilabel:`Cost` for the expense is `$25.00`
|
||||
|
||||
.. _expenses/report:
|
||||
|
||||
Create an expense report
|
||||
========================
|
||||
|
||||
When expenses are ready to submit (such as at the end of a business trip, or once a month), an
|
||||
*expense report* needs to be created. Go to the main :menuselection:`Expenses` app dashboard, which
|
||||
displays a default :guilabel:`My Expenses` view, or go to :menuselection:`Expenses app --> My
|
||||
Expenses --> My Expenses`.
|
||||
|
||||
Expenses are color coded by status. Any expense with a status of :guilabel:`To Report` (expenses
|
||||
that still need to be added to an expense report) the text appears in blue. All other statuses
|
||||
(:guilabel:`To Submit`, :guilabel:`Submitted`, and :guilabel:`Approved`) the text appears in black.
|
||||
|
||||
First, select each individual expense for the report by clicking the check box next to each entry,
|
||||
or quickly select all the expenses in the list by clicking the check box next to :guilabel:`Expense
|
||||
Date`.
|
||||
|
||||
Another way to quickly add all expenses that are not on an expense report is to click
|
||||
:guilabel:`Create Report` without selecting any expenses, and Odoo will select all expenses with a
|
||||
status of :guilabel:`To Submit` that are not already on a report.
|
||||
|
||||
.. image:: expenses/create-report.png
|
||||
:align: center
|
||||
:alt: Select the expenses to submit, then create the report.
|
||||
|
||||
.. note::
|
||||
Any expense can be selected from the :guilabel:`My Expenses` list, regardless of status. The
|
||||
:guilabel:`Create Report` button is visible as long as there is a minimum of 1 expense with a
|
||||
status of :guilabel:`To Report` selected. When the :guilabel:`Create Report` button is clicked,
|
||||
only expenses with a status of :guilabel:`To Submit` that are *not* currently on another expense
|
||||
report will appear in the newly created expense report.
|
||||
|
||||
Once the expenses have been selected, click the :guilabel:`Create Report` button. The new report
|
||||
appears with all the expenses listed in the :guilabel:`Expense` tab. If there is a receipt attached
|
||||
to an individual expense, a :guilabel:`📎 (paperclip)` icon appears next to the :guilabel:`Customer
|
||||
to Reinvoice` and :guilabel:`Analytic Distribution` columns.
|
||||
|
||||
When the report is created, the date range for the expenses appears in the :guilabel:`Expense Report
|
||||
Summary` field by default. It is recommended to edit this field with a short summary for each report
|
||||
to help keep expenses organized. Enter a short description for the expense report (such as `Client
|
||||
Trip NYC`, or `Repairs for Company Car`) in the :guilabel:`Expense Report Summary` field. Next,
|
||||
select a :guilabel:`Manager` from the drop-down menu to assign a manager to review the report. If
|
||||
needed, the :guilabel:`Journal` can be changed. Use the drop-down menu to select a different
|
||||
:guilabel:`Journal`.
|
||||
|
||||
.. image:: expenses/expense-report-summary.png
|
||||
:align: center
|
||||
:alt: Enter a short description and select a manager for the report.
|
||||
|
||||
If some expenses are not on the report that should be, they can still be added. Click :guilabel:`Add
|
||||
a line` at the bottom of the :guilabel:`Expense` tab. A pop up appears with all the available
|
||||
expenses that can be added to the report (with a status of :guilabel:`To Submit`). Click the check
|
||||
box next to each expense to add, then click :guilabel:`Select`. The items now appear on the report
|
||||
that was just created. If a new expense needs to be added that does *not* appear on the list, click
|
||||
:guilabel:`New` to create a new expense and add it to the report.
|
||||
|
||||
.. image:: expenses/add-an-expense-line.png
|
||||
:align: center
|
||||
:alt: Add more expenses to the report before submitting.
|
||||
|
||||
.. note::
|
||||
Expense reports can be created in one of three places:
|
||||
|
||||
#. Go to the main :menuselection:`Expenses` app dashboard (also accessed by going to
|
||||
:menuselection:`Expenses app --> My Expenses --> My Expenses`)
|
||||
#. Go to :menuselection:`Expenses app --> My Expenses --> My Reports`
|
||||
#. Go to :menuselection:`Expenses app --> Expense Reports`
|
||||
|
||||
In any of these views, click :guilabel:`New` to create a new expense report.
|
||||
|
||||
.. _expenses/submit:
|
||||
|
||||
Submit an expense report
|
||||
------------------------
|
||||
|
||||
When an expense report is completed, the next step is to submit the report to a manager for
|
||||
approval. Reports must be individually submitted, and cannot be submitted in batches. Open the
|
||||
specific report from the list of expense reports (if the report is not already open). To view all
|
||||
expense reports, go to :menuselection:`Expenses app --> My Expenses --> My Reports`.
|
||||
|
||||
If the list is large, grouping the results by status may be helpful since only reports that have a
|
||||
:guilabel:`To Submit` status need to be submitted, reports with an :guilabel:`Approved` or
|
||||
:guilabel:`Submitted` status do not.
|
||||
|
||||
The :guilabel:`To Submit` expenses are easily identifiable not just from the :guilabel:`To Submit`
|
||||
status, but the text appears in blue, while the other expenses text appears in black.
|
||||
|
||||
.. image:: expenses/expense-status.png
|
||||
:align: center
|
||||
:alt: Submit the report to the manager.
|
||||
|
||||
.. note::
|
||||
The status of each report is shown in the :guilabel:`Status` column on the right. If the
|
||||
:guilabel:`Status` column is not visible, click the :guilabel:`Additional Options (two dots)`
|
||||
icon at the end of the row, and enable :guilabel:`Status`.
|
||||
|
||||
Click on a report to open it, then click :guilabel:`Submit To Manager`. After submitting a report,
|
||||
the next step is to wait for the manager to approve it.
|
||||
|
||||
.. important::
|
||||
The :ref:`expenses/approve`, :ref:`expenses/post`, and :ref:`expenses/reimburse` sections are
|
||||
**only** for users with the *necessary rights*.
|
||||
|
||||
.. _expenses/approve:
|
||||
|
||||
Approve expenses
|
||||
@@ -386,10 +281,10 @@ To see who has rights to approve, go to the main :menuselection:`Settings` app a
|
||||
:guilabel:`Administration` section (bottom right of the :guilabel:`Access Rights` tab) is set to
|
||||
one of three options:
|
||||
|
||||
- :guilabel:`None (blank)`: The user cannot access the *Settings* app at all.
|
||||
- :guilabel:`Access Rights`: The user can only view the :guilabel:`User's & Companies` section of
|
||||
- :guilabel:`None (blank)`: the user cannot access the *Settings* app at all.
|
||||
- :guilabel:`Access Rights`: the user can only view the :guilabel:`User's & Companies` section of
|
||||
the *Settings* app.
|
||||
- :guilabel:`Settings`: The user has access to the entire *Settings* app with no restrictions.
|
||||
- :guilabel:`Settings`: the user has access to the entire *Settings* app with no restrictions.
|
||||
|
||||
Please refer to :doc:`this document </applications/general/users>` to learn more about managing
|
||||
users and their access rights.
|
||||
@@ -398,12 +293,12 @@ Click on an individual to view their card, which displays the :guilabel:`Access
|
||||
default view. Scroll down to the :guilabel:`Human Resources` section. Under :guilabel:`Expenses`,
|
||||
there are four options:
|
||||
|
||||
- :guilabel:`None (blank)`: A blank field means the user has no rights to view or approve expense
|
||||
- :guilabel:`None (blank)`: a blank field means the user has no rights to view or approve expense
|
||||
reports, and can only view their own.
|
||||
- :guilabel:`Team Approver`: The user can only view and approve expense reports for their own
|
||||
- :guilabel:`Team Approver`: the user can only view and approve expense reports for their own
|
||||
specific team.
|
||||
- :guilabel:`All Approver`: The user can view and approve any expense report.
|
||||
- :guilabel:`Administrator`: The user can view and approve any expense report, as well as access the
|
||||
- :guilabel:`All Approver`: the user can view and approve any expense report.
|
||||
- :guilabel:`Administrator`: the user can view and approve any expense report, as well as access the
|
||||
reporting and configuration menus in the *Expenses* app.
|
||||
|
||||
Users who are able to approve expense reports (typically managers) can easily view all expense
|
||||
@@ -416,18 +311,18 @@ reports with a status of :guilabel:`Refused` are hidden in the default view.
|
||||
:align: center
|
||||
:alt: Reports to validate are found on the Reports to Approve page.
|
||||
|
||||
When viewing expense reports, there is a panel of filters that can be enabled or disabled on the
|
||||
left side. The three categories that filters can be applied on are :guilabel:`Status`,
|
||||
When viewing expense reports, there is a panel of filters that can be enabled (or disabled) on the
|
||||
left side. The three categories where filters can be applied on are :guilabel:`Status`,
|
||||
:guilabel:`Employee`, and :guilabel:`Company`. To view only expense reports with a particular
|
||||
status, enable the specific status filter to display the expense reports with only that status.
|
||||
Disable the specific status filter to hide the reports with that status. To view expense reports for
|
||||
a particular employee and/or company, enable the specific employee name filter and/or company filter
|
||||
in the :guilabel:`Employee` and :guilabel:`Company` sections.
|
||||
|
||||
Reports can be approved in two ways (individually or several at once) and refused only one way. To
|
||||
Reports can be approved in two ways (individually or several at once), and refused only one way. To
|
||||
approve multiple expense reports at once, remain in the list view. First, select the reports to
|
||||
approve by clicking the check box next to each report, or click the box next to :guilabel:`Employee`
|
||||
to select all the reports in the list.
|
||||
approve by ticking the checkbox next to each report, or tick the checkbox next to
|
||||
:guilabel:`Employee` to select all the reports in the list.
|
||||
|
||||
.. important::
|
||||
Only reports with a status of :guilabel:`Submitted` can be approved. It is recommended to only
|
||||
@@ -435,7 +330,7 @@ to select all the reports in the list.
|
||||
:guilabel:`Submitted` filter enabled.
|
||||
|
||||
If a report is selected that is unable to be approved, the :guilabel:`Approve Report` button
|
||||
**will not appear**, indicating there is a problem with the selected report(s).
|
||||
does **not** appear, indicating there is a problem with the selected report.
|
||||
|
||||
Next, click the :guilabel:`Approve Report` button.
|
||||
|
||||
@@ -477,46 +372,6 @@ the manager's team.
|
||||
:align: center
|
||||
:alt: Send messages in the chatter.
|
||||
|
||||
.. _expenses/post:
|
||||
|
||||
Post expenses in accounting
|
||||
===========================
|
||||
|
||||
Once an expense report is approved, the next step is to post the report to the accounting journal.
|
||||
To view all expense reports, go to :menuselection:`Expenses app --> Expense Reports`. To view only the
|
||||
expense reports that have been approved and need to be posted, adjust the filters on the left side
|
||||
so that only the :guilabel:`Approved` status is enabled.
|
||||
|
||||
.. image:: expenses/post-reports.png
|
||||
:align: center
|
||||
:alt: View reports to post by clicking on expense reports, then reports to post.
|
||||
|
||||
Just like approvals, expense reports can be posted in two ways (individually or several at once). To
|
||||
post multiple expense reports at once, remain in the list view. First, select the reports to post by
|
||||
clicking the check box next to each report, or click the box next to :guilabel:`Employee` to select
|
||||
all the reports in the list. Next, click :guilabel:`Post Entries`.
|
||||
|
||||
.. image:: expenses/post-entries.png
|
||||
:align: center
|
||||
:alt: Post multiple reports at a time from the Expense Reports view, with the Approved filter.
|
||||
|
||||
To post an individual report, click on a report to go to the detailed view of that report. In this
|
||||
view, several options are presented: :guilabel:`Post Journal Entries`, :guilabel:`Report In Next
|
||||
Payslip`, :guilabel:`Refuse`, or :guilabel:`Reset to Draft`. Click :guilabel:`Post Journal Entries`
|
||||
to post the report.
|
||||
|
||||
If :guilabel:`Refuse` is clicked, a pop-up window appears. Enter a brief explanation for the refusal
|
||||
in the :guilabel:`Reason to Refuse Expense` field, and then click :guilabel:`Refuse`. Refused
|
||||
reports can be viewed by going to :menuselection:`Expenses app --> Expense Reports`, then adjusting
|
||||
the filters on the left so that only :guilabel:`Refused` is selected. This will only show the
|
||||
refused expense reports.
|
||||
|
||||
.. important::
|
||||
To post expense reports to an accounting journal, the user must have following access rights:
|
||||
|
||||
- Accounting: Accountant or Adviser
|
||||
- Expenses: Manager
|
||||
|
||||
.. _expenses/reimburse:
|
||||
|
||||
Reimburse employees
|
||||
@@ -532,8 +387,9 @@ Reports --> Reports To Pay`.
|
||||
|
||||
Just like approvals and posting, expense reports can be paid in two ways (individually or several at
|
||||
once). To pay multiple expense reports at once, remain in the list view. First, select the reports
|
||||
to pay by clicking the check box next to each report, or click the box next to :guilabel:`Employee`
|
||||
to select all the reports in the list. Next, click :guilabel:`Register Payment`.
|
||||
to pay by ticking the checkbox next to each report, or tick the checkbox next to
|
||||
:guilabel:`Employee` to select all the reports in the list. Next, click :guilabel:`Register
|
||||
Payment`.
|
||||
|
||||
.. image:: expenses/register-payment.png
|
||||
:align: center
|
||||
@@ -567,7 +423,7 @@ If expenses are tracked on customer projects, expenses can be automatically char
|
||||
customer. This is done by creating an expense, referencing the :abbr:`SO (Sales Order)` the expense
|
||||
should be added to, and then creating the expense report. Next, managers approve the expense report,
|
||||
and the accounting department posts the journal entries. Finally, once the expense report is posted
|
||||
to a journal, the expense(s) appears on the :abbr:`SO (Sales Order)` that was referenced. The sales
|
||||
to a journal, the expenses appear on the :abbr:`SO (Sales Order)` that was referenced. The sales
|
||||
order can then be invoiced, thus invoicing the customer for the expense.
|
||||
|
||||
Setup
|
||||
@@ -589,11 +445,11 @@ Create an expense
|
||||
-----------------
|
||||
|
||||
First, when :ref:`creating a new expense <expenses/new>`, the correct information needs to be
|
||||
entered in order to re-invoice a customer. Select the *sales order* the expense will appear on in
|
||||
the :guilabel:`Customer to Reinvoice` section, from the drop-down menu. Next, select the
|
||||
:guilabel:`Analytic Account` the expense will be posted to. After the expense(s) are created, the
|
||||
expense report needs to be :ref:`created <expenses/report>` and :ref:`submitted <expenses/submit>`
|
||||
as usual.
|
||||
entered to re-invoice a customer. Select the sales order the expense should appear on in the
|
||||
:guilabel:`Customer to Reinvoice` section, from the drop-down menu. Next, select the
|
||||
:guilabel:`Analytic Account` the expense should be posted to. After the expenses are created, the
|
||||
expense report needs to be :doc:`created <expenses/expense_reports>`, and :ref:`submitted
|
||||
<expenses/submit>`, as usual.
|
||||
|
||||
.. image:: expenses/reinvoice-expense.png
|
||||
:align: center
|
||||
@@ -609,16 +465,16 @@ as usual.
|
||||
Validate and post expenses
|
||||
--------------------------
|
||||
|
||||
Only employees with permissions (typically managers or supervisors) can :ref:`approve expenses
|
||||
Only employees with permissions (typically, managers or supervisors) can :ref:`approve expenses
|
||||
<expenses/approve>`. Before approving an expense report, ensure the :guilabel:`Analytic
|
||||
Distribution` is set on every expense line of a report. If an :guilabel:`Analytic Distribution` is
|
||||
missing, assign the correct account(s) from the drop-down menu, and then click :guilabel:`Approve`
|
||||
or :guilabel:`Refuse`.
|
||||
missing, assign the correct accounts from the drop-down menu, and click :guilabel:`Approve` or
|
||||
:guilabel:`Refuse`.
|
||||
|
||||
The accounting department is typically responsible for :ref:`posting journal entries
|
||||
<expenses/post>`. Once an expense report is approved, it can then be posted. The :abbr:`SO (Sales
|
||||
Order)` is **only** updated *after the journal entries are posted*. One the journal entries are
|
||||
posted, the expenses now appear on the referenced :abbr:`SO (Sales Order)`.
|
||||
The accounting department is typically responsible for :doc:`posting journal entries
|
||||
<expenses/post_expenses>`. Once an expense report is approved, it can then be posted. The :abbr:`SO
|
||||
(Sales Order)` is **only** updated *after* the journal entries are posted. Once the journal entries
|
||||
are posted, the expenses now appear on the referenced :abbr:`SO (Sales Order)`.
|
||||
|
||||
Invoice expenses
|
||||
----------------
|
||||
@@ -651,3 +507,13 @@ Next, click :guilabel:`Create Invoice`, and select if the invoice is for a :guil
|
||||
invoice`, a :guilabel:`Down payment (percentage)`, or a :guilabel:`Down payment (fixed amount)` by
|
||||
clicking the radio button next to it. Then, click :guilabel:`Create Invoice`. The customer has now
|
||||
been invoiced for the expenses.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`expenses/post_expenses`
|
||||
- :doc:`expenses/expense_reports`
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
expenses/post_expenses
|
||||
expenses/expense_reports
|
||||
|
||||
|
Before Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 26 KiB |
@@ -0,0 +1,126 @@
|
||||
===============
|
||||
Expense reports
|
||||
===============
|
||||
|
||||
When expenses are ready to submit (such as, at the end of a business trip, or once a month), an
|
||||
*expense report* needs to be created. Open the main :menuselection:`Expenses app` dashboard, which
|
||||
displays the :guilabel:`My Expenses` dashboard, by default. Alternatively, navigate to
|
||||
:menuselection:`Expenses app --> My Expenses --> My Expenses`.
|
||||
|
||||
Expenses are color-coded by status. Any expense with a status of :guilabel:`To Report` (expenses
|
||||
that still need to be added to an expense report) is shown in blue text. All other statuses
|
||||
(:guilabel:`To Submit`, :guilabel:`Submitted`, and :guilabel:`Approved`) the text appears in black.
|
||||
|
||||
Create expense reports
|
||||
======================
|
||||
|
||||
First, select each desired expense to be added to the report on the :guilabel:`My Expenses`
|
||||
dashboard, by ticking the checkbox next to each entry, or quickly select all the expenses in the
|
||||
list by ticking the checkbox next to the :guilabel:`Expense Date` column title, if needed.
|
||||
|
||||
Another way to quickly add all expenses that are not on a expense report, is to click the
|
||||
:guilabel:`Create Report` button, *without* selecting any expenses, and Odoo automatically selects
|
||||
all expenses with a status of :guilabel:`To Submit` that are not already on a report.
|
||||
|
||||
.. image:: expense_reports/create-report.png
|
||||
:align: center
|
||||
:alt: Select the expenses to submit, then create the report.
|
||||
|
||||
.. note::
|
||||
Any expense can be selected from the :guilabel:`My Expenses` list, except for expenses with a
|
||||
status of :guilabel:`Approved`.
|
||||
|
||||
The :guilabel:`Create Report` button is visible as long as there is a minimum of one expense on
|
||||
the list with a status of either :guilabel:`To Report` or :guilabel:`To Submit`.
|
||||
|
||||
When the :guilabel:`Create Report` button is clicked, all expenses with a status of :guilabel:`To
|
||||
Submit` that are *not* currently on another expense report appears in the newly-created expense
|
||||
report.
|
||||
|
||||
If all expenses on the :guilabel:`My Expenses` report are already associated with another expense
|
||||
report, an :guilabel:`Invalid Operation` pop-up window appears, stating :guilabel:`You have no
|
||||
expenses to report.`
|
||||
|
||||
Once the expenses have been selected, click the :guilabel:`Create Report` button. The new report
|
||||
appears with all the expenses listed in the :guilabel:`Expense` tab. If there is a receipt attached
|
||||
to an individual expense, a :icon:`fa-paperclip` :guilabel:`(paperclip)` icon appears between the
|
||||
:guilabel:`Customer to Reinvoice` and :guilabel:`Analytic Distribution` columns.
|
||||
|
||||
When the report is created, the date range for the expenses appears in the :guilabel:`Expense Report
|
||||
Summary` field, by default. It is recommended to edit this field with a short summary for each
|
||||
report to help keep expenses organized. Enter a description for the expense report, such as `Client
|
||||
Trip NYC`, or `Office Supplies for Presentation`, in the :guilabel:`Expense Report Summary` field.
|
||||
|
||||
The :guilabel:`Employee`, :guilabel:`Paid By`, and :guilabel:`Company` fields autopoulate with the
|
||||
information listed on the individual expenses.
|
||||
|
||||
Next, select a :guilabel:`Manager` from the drop-down menu to assign a manager to review the report.
|
||||
If needed, update the :guilabel:`Journal` field, using the drop-down menu.
|
||||
|
||||
.. image:: expense_reports/expense-report-summary.png
|
||||
:align: center
|
||||
:alt: Enter a short description and select a manager for the report.
|
||||
|
||||
If some expenses are missing from the report, they can still be added from this report form. To do
|
||||
so, click :guilabel:`Add a line` at the bottom of the :guilabel:`Expense` tab.
|
||||
|
||||
An :guilabel:`Add: Expense Lines` pop-up window appears, displaying all the available expenses (with
|
||||
a :guilabel:`To Submit` status) that can be added to the report.
|
||||
|
||||
If a new expense needs to be added that does **not** appear on the list, click :guilabel:`New` to
|
||||
:ref:`create a new expense <expenses/new>` and add it to the report.
|
||||
|
||||
Tick the checkbox next to each expense being added, then click :guilabel:`Select`.
|
||||
|
||||
Doing so removes the pop-up window, and the items now appear on the report.
|
||||
|
||||
.. image:: expense_reports/add-an-expense-line.png
|
||||
:align: center
|
||||
:alt: Add more expenses to the report before submitting.
|
||||
|
||||
.. note::
|
||||
Expense reports can be created in one of three places:
|
||||
|
||||
#. Navigate to the main :menuselection:`Expenses app` dashboard (also accessible, via
|
||||
:menuselection:`Expenses app --> My Expenses --> My Expenses`)
|
||||
#. Navigate to :menuselection:`Expenses app --> My Expenses --> My Reports`
|
||||
#. Navigate to :menuselection:`Expenses app --> Expense Reports`
|
||||
|
||||
In any of these views, click :guilabel:`New` to create a new expense report.
|
||||
|
||||
.. _expenses/submit:
|
||||
|
||||
Submit expense reports
|
||||
======================
|
||||
|
||||
When an expense report is completed, the next step is to submit the report to a manager for
|
||||
approval. To view all expense reports, navigate to :menuselection:`Expenses app --> My Expenses -->
|
||||
My Reports`. Open the specific report from the list of expense reports.
|
||||
|
||||
.. note::
|
||||
Reports must be individually submitted, and **cannot** be submitted in batches.
|
||||
|
||||
If the list is large, grouping the results by status may be helpful, since only reports with a
|
||||
:guilabel:`To Submit` status need to be submitted; reports with an :guilabel:`Approved` or
|
||||
:guilabel:`Submitted` status do not.
|
||||
|
||||
The :guilabel:`To Submit` expenses are identifiable by the :guilabel:`To Submit` status, and by the
|
||||
blue text, while all other expense text appears in black.
|
||||
|
||||
.. image:: expense_reports/expense-status.png
|
||||
:align: center
|
||||
:alt: Submit the report to the manager.
|
||||
|
||||
.. note::
|
||||
The status of each report is shown in the :guilabel:`Status` column. If the :guilabel:`Status`
|
||||
column is not visible, click the :icon:`oi-settings-adjust` :guilabel:`(additional options)` icon
|
||||
at the end of the row, and tick the checkbox beside :guilabel:`Status` from the resulting
|
||||
drop-down menu.
|
||||
|
||||
Click on a report to open it, then click :guilabel:`Submit To Manager`. After submitting a report,
|
||||
the next step is to wait for the manager to approve it.
|
||||
|
||||
.. important::
|
||||
:ref:`Approving <expenses/approve>`, :doc:`posting <../expenses/post_expenses>`, and
|
||||
:ref:`reimbursing <expenses/reimburse>` expenses are **only** for users with the appropriate
|
||||
:doc:`access rights <../../general/users/access_rights>`.
|
||||
|
Before Width: | Height: | Size: 8.6 KiB After Width: | Height: | Size: 8.6 KiB |
|
After Width: | Height: | Size: 31 KiB |
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 29 KiB |
|
Before Width: | Height: | Size: 12 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 25 KiB |
|
Before Width: | Height: | Size: 14 KiB |
@@ -0,0 +1,75 @@
|
||||
=============
|
||||
Post expenses
|
||||
=============
|
||||
|
||||
Once an expense report is :ref:`approved <expenses/approve>`, the next step is to post the expense
|
||||
report to the proper accounting journal.
|
||||
|
||||
.. important::
|
||||
To post expense reports to an accounting journal, the user **must** have the following
|
||||
:doc:`access rights <../../general/users/access_rights>`:
|
||||
|
||||
- Accounting: *Accountant* or *Adviser*
|
||||
- Expenses: *Manager*
|
||||
|
||||
Only expense reports with an *Approved* status can post the expenses to a journal. To view all
|
||||
expense reports, navigate to :menuselection:`Expenses app --> Expense Reports`. Next, to view
|
||||
**only** approved expense reports that need to be posted, adjust the filters on the left side, so
|
||||
only the :guilabel:`Approved` checkbox is ticked.
|
||||
|
||||
.. image:: post-expenses/post-reports.png
|
||||
:align: center
|
||||
:alt: View reports to post by clicking on expense reports, then reports to post.
|
||||
|
||||
.. note::
|
||||
The default :guilabel:`All Reports` dashboard displays all expense reports, except reports with a
|
||||
status of :guilabel:`Refused`.
|
||||
|
||||
Expense reports can be posted to accounting journals in two ways: :ref:`individually
|
||||
<expenses/individual>` or :ref:`in bulk <expenses/multiple>`.
|
||||
|
||||
.. _expenses/individual:
|
||||
|
||||
Post individual reports
|
||||
-----------------------
|
||||
|
||||
To post an individual report, navigate to :menuselection:`Expenses app --> Expense Reports`, and
|
||||
click on an individual report with a :guilabel:`Status` of :guilabel:`Approved`, to view the report
|
||||
form. In this view, several options are presented: :guilabel:`Post Journal Entries`,
|
||||
:guilabel:`Report In Next Payslip`, :guilabel:`Refuse`, or :guilabel:`Reset to Draft`.
|
||||
|
||||
Click :guilabel:`Post Journal Entries` to post the report.
|
||||
|
||||
The accounting journal the expenses are posted to is listed in the :guilabel:`Journal` field of the
|
||||
expense report.
|
||||
|
||||
After posting the expenses to an accounting journal, a :guilabel:`Journal Entry` smart button
|
||||
appears at the top of the screen. Click the :guilabel:`Journal Entry` smart button, and the details
|
||||
for the journal entry appear, with a status of :guilabel:`Posted`.
|
||||
|
||||
.. _expenses/multiple:
|
||||
|
||||
Post multiple reports
|
||||
---------------------
|
||||
|
||||
To post multiple expense reports at once, navigate to :menuselection:`Expenses app --> Expense
|
||||
Reports` to view a list of expense reports. Next, select the reports to approve by ticking the
|
||||
checkbox next to each report being approved.
|
||||
|
||||
.. note::
|
||||
Only expense reports with a status of :guilabel:`Approved` are able to post the expenses to an
|
||||
accounting journal. If an expense report is selected that **cannot** be posted, such as an
|
||||
unapproved report, or the report has already been posted to a journal, the :guilabel:`Post
|
||||
Entries` button is **not** visible.
|
||||
|
||||
.. tip::
|
||||
To select **only** approved expense reports, adjust the filters on the left side, so that only
|
||||
the :guilabel:`Approved` checkbox is ticked. Next, tick the checkbox next to the
|
||||
:guilabel:`Employee` column title to select **all** the :guilabel:`Approved` reports in the list
|
||||
at once.
|
||||
|
||||
Next, click the :guilabel:`Post Entries` button.
|
||||
|
||||
.. image:: post-expenses/post-entries.png
|
||||
:align: center
|
||||
:alt: Post multiple reports at a time from the Expense Reports view, with the Approved filter.
|
||||
@@ -1018,69 +1018,37 @@ specific product.
|
||||
Reports
|
||||
=======
|
||||
|
||||
As part of the localization installation, financial reporting for Argentina was added to the
|
||||
:guilabel:`Accounting` dashboard. Access these reports by navigating to :menuselection:`Accounting
|
||||
--> Reporting --> Argentinean Reports`
|
||||
As part of the localization installation, financial reporting for Argentina is available in the
|
||||
:guilabel:`Accounting` dashboard. To access these reports, navigate to :menuselection:`Accounting
|
||||
--> Reporting --> Argentinean Statements`.
|
||||
|
||||
.. image:: argentina/argentinian-reports.png
|
||||
:align: center
|
||||
:alt: Argentinean reports.
|
||||
To access the VAT book report, go to :menuselection:`Accounting --> Reporting --> Tax Report`, click
|
||||
the :icon:`fa-book` (:guilabel:`book`), and select :guilabel:`Argentinean VAT book (AR)`.
|
||||
|
||||
VAT reports
|
||||
-----------
|
||||
|
||||
Sales VAT book
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
This report records all the sales, which are taken as the basis for the accounting records
|
||||
to determine the VAT (Tax Debit). The :guilabel:`Sales VAT` book report can be exported as a `.zip`
|
||||
file using the :guilabel:`VAT BOOK (ZIP)` button at the top left, containing `.txt` files to upload
|
||||
to the AFIP portal.
|
||||
|
||||
.. image:: argentina/sales-vat-book.png
|
||||
:align: center
|
||||
:alt: Sales VAT book.
|
||||
|
||||
Purchases VAT book
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The :guilabel:`Purchases VAT` book report can be exported as a `.zip` file using the
|
||||
:guilabel:`VAT BOOK (ZIP)` button at the top left, which contains `.txt` files to upload to the AFIP
|
||||
portal.
|
||||
|
||||
.. image:: argentina/purchases-vat-book.png
|
||||
:align: center
|
||||
:alt: Purchases VAT book.
|
||||
.. note::
|
||||
The VAT book report can be exported as a `.zip` file by selecting it in the dropdown menu in the
|
||||
top-left corner.
|
||||
|
||||
VAT summary
|
||||
~~~~~~~~~~~
|
||||
-----------
|
||||
|
||||
Pivot table designed to check the monthly VAT totals. This report is for internal use and is not
|
||||
sent to the AFIP.
|
||||
|
||||
.. image:: argentina/vat-summary.png
|
||||
:align: center
|
||||
:alt: VAT Summary.
|
||||
|
||||
IIBB - Reports
|
||||
--------------
|
||||
This pivot table is designed to check the monthly VAT totals. This report is for internal use and is
|
||||
not sent to the AFIP.
|
||||
|
||||
IIBB - Sales by jurisdiction
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
----------------------------
|
||||
|
||||
Pivot table where you can validate the gross income in each jurisdiction. Affidavit for the
|
||||
corresponding taxes to pay; and therefore, it is not sent to the AFIP.
|
||||
This pivot table allows you to validate the gross income in each jurisdiction. It serves as an
|
||||
affidavit for the corresponding taxes due but is not submitted to the AFIP.
|
||||
|
||||
.. image:: argentina/iibb-sales-jurisdiction.png
|
||||
:align: center
|
||||
:alt: IIBB Sales by jurisdiction.
|
||||
|
||||
IIBB - Purchases by jurisdiction
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
--------------------------------
|
||||
|
||||
Pivot table where you can validate the gross purchases in each jurisdiction. Affidavit for the
|
||||
corresponding taxes to pay; and therefore, it is not sent to the AFIP.
|
||||
This pivot table allows you to validate the gross purchases in each jurisdiction. It serves as an
|
||||
affidavit for the corresponding taxes due but is not submitted to the AFIP.
|
||||
|
||||
.. image:: argentina/iibb-purchases-jurisdiction.png
|
||||
:align: center
|
||||
:alt: IIBB Purchases by jurisdiction.
|
||||
|
||||
|
Before Width: | Height: | Size: 54 KiB |
|
Before Width: | Height: | Size: 25 KiB |
|
Before Width: | Height: | Size: 52 KiB |
|
Before Width: | Height: | Size: 56 KiB |
@@ -511,10 +511,6 @@ Once the invoice is accepted and validated by the :abbr:`SII (Servicio de Impues
|
||||
the PDF is printed, it includes the fiscal elements that indicate that the document is fiscally
|
||||
valid.
|
||||
|
||||
.. image:: chile/sii-validation-elements.png
|
||||
:alt: SII Validation fiscal elements.
|
||||
:align: center
|
||||
|
||||
.. important::
|
||||
If you are hosted in Odoo SH or On-Premise, you should manually install the `pdf417gen
|
||||
<https://pypi.org/project/pdf417gen/>`_ library. Use the following command to install it:
|
||||
|
||||
|
Before Width: | Height: | Size: 26 KiB |
@@ -33,6 +33,8 @@ Here are some terms that are essential on the Ecuadorian localization:
|
||||
Configuration
|
||||
=============
|
||||
|
||||
.. _l10n_ec/module-installation:
|
||||
|
||||
Modules installation
|
||||
--------------------
|
||||
|
||||
@@ -75,7 +77,7 @@ localization:
|
||||
* - :guilabel:`Ecuadorian Point of Sale`
|
||||
- `l10n_ec_edi_pos`
|
||||
- Includes all the technical and functional requirements to generate automatic electronic
|
||||
invoices from a PoS sale.
|
||||
invoices from a POS sale.
|
||||
|
||||
.. note::
|
||||
When you install a database from scratch selecting `Ecuador` as the country, Odoo automatically
|
||||
@@ -631,7 +633,7 @@ time.
|
||||
eCommerce workflow
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Type and identification number
|
||||
Identification type and number
|
||||
******************************
|
||||
|
||||
The client who is making a purchase will have the option to indicate their identification type and
|
||||
@@ -639,18 +641,74 @@ number during the checkout process. This information is required to correctly ge
|
||||
electronic invoice after the checkout is completed.
|
||||
|
||||
.. image:: ecuador/website-checkout-form.png
|
||||
:align: center
|
||||
:alt: Website checkout form.
|
||||
|
||||
.. note::
|
||||
Verification is done to ensure the *Identification Number* field is completed and has the correct
|
||||
number of digits. For RUC identification, 13 digits are required. For Cédula, 9 digits are
|
||||
required.
|
||||
Verification is done to ensure the :guilabel:`Identification Number` field is completed and has
|
||||
the correct number of digits. For RUC identification, 13 digits are required. For Cédula,
|
||||
9 digits are required.
|
||||
|
||||
After finishing the checkout process, a confirmed invoice is generated, ready to be sent manually or
|
||||
asynchronously to the SRI.
|
||||
|
||||
Financial Reports
|
||||
Point of Sale electronic invoicing
|
||||
----------------------------------
|
||||
|
||||
Make sure the *Ecuadorian module for Point of Sale* (`l10n_ec_edi_pos`) is :ref:`installed
|
||||
<l10n_ec/module-installation>` to enable the following features and configurations:
|
||||
|
||||
- Choose the SRI payment method in each payment method configuration.
|
||||
- Manually input the customer's identification type and identification number when creating a
|
||||
new contact on *POS*.
|
||||
- Automatically generate a valid electronic invoice for Ecuador at the end of the checkout process.
|
||||
|
||||
Payment method configuration
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To :doc:`create a payment method for a point of sale <../../sales/point_of_sale/payment_methods>`,
|
||||
go to :menuselection:`Point of Sale --> Configuration --> Payment Methods`. Then, set the
|
||||
:guilabel:`SRI Payment Method` in the payment method form.
|
||||
|
||||
Invoicing flows
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Identification type and number
|
||||
******************************
|
||||
|
||||
The POS cashier can :ref:`create a new contact for a customer <pos/customers>` who requests an
|
||||
invoice from an open POS session.
|
||||
|
||||
The *Ecuadorian Module for Point of Sale* adds two new fields to the contact creation form:
|
||||
:guilabel:`Identification Type` and :guilabel:`Tax ID`.
|
||||
|
||||
.. note::
|
||||
As the identification number length differs depending on the identification type, Odoo
|
||||
automatically checks the :guilabel:`Tax ID` field upon saving the contact form. To manually
|
||||
ensure the length is correct, know that the :guilabel:`RUC` and :guilabel:`Citizenship` types
|
||||
require 13 and 10 digits, respectively.
|
||||
|
||||
Electronic invoice: anonymous end consumer
|
||||
******************************************
|
||||
|
||||
When clients do not request an electronic invoice for their purchase, Odoo automatically sets the
|
||||
customer as :guilabel:`Consumidor Final` and generates an electronic invoice anyway.
|
||||
|
||||
.. note::
|
||||
If the client requests a credit note due to a return of this type of purchase, the credit note
|
||||
should be made using the client's real contact information. Credit notes cannot be created to
|
||||
*Consumidor Final* and can be managed :ref:`directly from the POS session <pos/refund>`.
|
||||
|
||||
Electronic invoice: specific customer
|
||||
*************************************
|
||||
|
||||
If a customer requests an invoice for their purchase, it is possible to select or create a contact
|
||||
with their fiscal information. This ensures the invoice is generated with accurate customer details.
|
||||
|
||||
.. note::
|
||||
If the client requests a credit note due to a return of this type of purchase, the credit note
|
||||
and return process can be managed :ref:`directly from the POS session <pos/refund>`.
|
||||
|
||||
Financial reports
|
||||
=================
|
||||
|
||||
In Ecuador, there are fiscal reports that the company presents to SRI. Odoo supports two of the main
|
||||
|
||||
@@ -370,9 +370,8 @@ Payment complements
|
||||
Payment policy
|
||||
**************
|
||||
|
||||
One addition of the Mexican localization is the :guilabel:`Payment Policy` field . `According to
|
||||
the SAT documentation <https://www.sat.gob.mx/consultas/92764/comprobante-de-recepcion-de-pagos>`_,
|
||||
there may be 2 types of payments:
|
||||
One addition of the Mexican localization is the :guilabel:`Payment Policy` field. According to
|
||||
the SAT documentation, there are two types of payments:
|
||||
|
||||
- `PUE` (Pago en una Sola Exhibición/Payment in a Single Exhibition)
|
||||
- `PPD` (Pago en Parcialidades o Diferido/Payment in Installements or Deferred)
|
||||
|
||||
@@ -34,14 +34,14 @@ registration`. On the :guilabel:`Register an application` screen, rename the :gu
|
||||
and personal Microsoft accounts (e.g. Skype, Xbox)`.
|
||||
|
||||
Under the :guilabel:`Redirect URL` section, select :guilabel:`Web` as the platform, and then input
|
||||
`https://<odoo base url>/microsoft_outlook/confirm` in the :guilabel:`URL` field. The Odoo base URL
|
||||
is the canonical domain at which your Odoo instance can be reached in the URL field.
|
||||
`https://<web base url>/microsoft_outlook/confirm` in the :guilabel:`URL` field. The `web.base.url`
|
||||
is subject to change depending on the URL used to log in to the database.
|
||||
|
||||
.. example::
|
||||
*mydatabase.odoo.com*, where *mydatabase* is the actual prefix of the database's subdomain,
|
||||
assuming it's hosted on Odoo.com
|
||||
.. note::
|
||||
The documentation about the :ref:`web.base.url <domain-name/web-base-url>` explains how to freeze
|
||||
a unique URL. It is also possible to add different redirect URLs on the Microsoft app.
|
||||
|
||||
After the URL has been added to the field, :guilabel:`Register` the application so it is created.
|
||||
After the URL has been added to the field, :guilabel:`Register` the application, so it is created.
|
||||
|
||||
API permissions
|
||||
---------------
|
||||
|
||||
@@ -51,11 +51,13 @@ except under the following circumstances:
|
||||
Mitchell Admin has multiple companies enabled, but the current company is `My Company (Chicago)`.
|
||||
When he creates a new product record, the :guilabel:`Company` field is left blank by default.
|
||||
|
||||
When he creates a new sales team, the :guilabel:`Company` field automatically defaults to `My
|
||||
When a new sales team is created, the :guilabel:`Company` field automatically defaults to `My
|
||||
Company (Chicago)`.
|
||||
|
||||
Sharing data
|
||||
============
|
||||
.. _general/sharing-data:
|
||||
|
||||
Share data
|
||||
==========
|
||||
|
||||
In a |mcd|, certain records are able to be utilized by all of the companies (or several, based on
|
||||
permissions).
|
||||
@@ -113,3 +115,26 @@ To keep their database from becoming overly complex, the furniture company does
|
||||
entirely new company. Instead, they can take advantage of existing features, such as :doc:`analytic
|
||||
accounting <../finance/accounting/reporting/analytic_accounting>`, and multiple warehouses, to
|
||||
manage the new product line, without having to overly complicate transactions.
|
||||
|
||||
Limitations
|
||||
===========
|
||||
|
||||
In some instances, a |mcd| may *not* be the best option, due to potential limitations.
|
||||
|
||||
Access rights
|
||||
-------------
|
||||
|
||||
A user's access rights are configured on a database level. If a user has access to more than one
|
||||
company in a |mcd|, their access rights are the same across every company.
|
||||
|
||||
Shared records
|
||||
--------------
|
||||
|
||||
Individual records are either :ref:`shared <general/sharing-data>` between all companies, or belong
|
||||
to a single company.
|
||||
|
||||
PDF Reports
|
||||
-----------
|
||||
|
||||
Some customizations, specifically for PDF reports, apply to all companies. It is not always possible
|
||||
to separate reports for individual companies.
|
||||
|
||||
@@ -254,6 +254,7 @@ company.
|
||||
users/2fa
|
||||
users/access_rights
|
||||
users/portal
|
||||
users/facebook
|
||||
users/google
|
||||
users/azure
|
||||
users/ldap
|
||||
|
||||
@@ -1,127 +1,125 @@
|
||||
=========================
|
||||
Two-factor Authentication
|
||||
Two-factor authentication
|
||||
=========================
|
||||
|
||||
Two-factor authentication ("2FA") is a good way to improve the
|
||||
security of an account, to make it less likely that an other person
|
||||
will manage to log in instead of you.
|
||||
.. |2fa| replace:: :abbr:`2FA (two-factor authentication)`
|
||||
.. |QR| replace:: :abbr:`QR (Quick Response)` code
|
||||
|
||||
Practically, it means storing a secret inside an *authenticator*
|
||||
(usually your cell phone) and exchanging a code from the authenticator
|
||||
when you try to log in.
|
||||
*Two-factor authentication (2FA)* is a way to improve security, and prevent unauthorized persons
|
||||
from accessing user accounts.
|
||||
|
||||
This means an attacker needs *both* to have guessed (or found) your
|
||||
password and to access (or steal) your authenticator, a more difficult
|
||||
proposition than either one or the other.
|
||||
Practically, |2fa| means storing a secret inside an *authenticator*, usually on a mobile phone, and
|
||||
exchanging a code from the authenticator when trying to log in.
|
||||
|
||||
This means an unauthorized user would need to guess the account password *and* have access to the
|
||||
authenticator, which is a more difficult proposition.
|
||||
|
||||
Requirements
|
||||
============
|
||||
|
||||
.. note:: These lists are just examples, they are not endorsements of
|
||||
any specific software.
|
||||
.. important::
|
||||
These lists are just examples. They are **not** endorsements of any specific software.
|
||||
|
||||
If you don't already have one, you will need to choose an
|
||||
authenticator.
|
||||
Phone-based authenticators are the easiest and most commonly used. Examples include:
|
||||
|
||||
Phone-based authenticators are the easiest and most common so we will
|
||||
assume you'll pick and install one on your phone, examples include
|
||||
`Authy <https://authy.com/>`_, `FreeOTP
|
||||
<https://freeotp.github.io/>`_, `Google Authenticator
|
||||
<https://support.google.com/accounts/answer/1066447?hl=en>`_,
|
||||
`LastPass Authenticator <https://lastpass.com/auth/>`_, `Microsoft
|
||||
Authenticator
|
||||
<https://www.microsoft.com/en-gb/account/authenticator?cmp=h66ftb_42hbak>`_,
|
||||
...; password managers also commonly include :abbr:`2FA (two-factor
|
||||
authentication)` support e.g. `1Password
|
||||
<https://support.1password.com/one-time-passwords/>`_, `Bitwarden
|
||||
<https://bitwarden.com/help/article/authenticator-keys/>`_, ...
|
||||
- `Authy <https://authy.com/>`_
|
||||
- `FreeOTP <https://freeotp.github.io/>`_
|
||||
- `Google Authenticator <https://support.google.com/accounts/answer/1066447?hl=en>`_
|
||||
- `LastPass Authenticator <https://lastpass.com/auth/>`_
|
||||
- `Microsoft Authenticator
|
||||
<https://www.microsoft.com/en-gb/account/authenticator?cmp=h66ftb_42hbak>`_
|
||||
|
||||
For the sake of demonstration we will be using Google Authenticator
|
||||
(not because it is any good but because it is quite common).
|
||||
Password managers are another option. Common examples include:
|
||||
|
||||
Setting up two-factor authentication
|
||||
====================================
|
||||
|
||||
Once you have your authenticator of choice, go to the Odoo instance
|
||||
you want to setup :abbr:`2FA (two-factor authentication)`, then open
|
||||
:guilabel:`Preferences` (or :guilabel:`My Profile`):
|
||||
|
||||
.. figure:: 2fa/preferences.png
|
||||
:align: center
|
||||
|
||||
Open the :guilabel:`Account Security` tab, then click the
|
||||
:guilabel:`Enable two-factor authentication` button:
|
||||
|
||||
.. figure:: 2fa/sec_tab.png
|
||||
:align: center
|
||||
|
||||
Because this is a security-sensitive action, you will need to input
|
||||
your password:
|
||||
|
||||
.. figure:: 2fa/sec_enhanced.png
|
||||
:align: center
|
||||
|
||||
After which you will see this screen with a barcode:
|
||||
|
||||
.. figure:: 2fa/totp_scan.png
|
||||
:align: center
|
||||
|
||||
In most applications, you can simply *scan the barcode* via the
|
||||
authenticator of your choice, the authenticator will then take care of
|
||||
all the setup:
|
||||
|
||||
.. figure:: 2fa/scan_barcode.jpg
|
||||
:align: center
|
||||
- `1Password <https://support.1password.com/one-time-passwords/>`_
|
||||
- `Bitwarden <https://bitwarden.com/help/article/authenticator-keys/>`_,
|
||||
|
||||
.. note::
|
||||
The remainder of this document uses Google Authenticator as an example, as it is one of the most
|
||||
commonly used. This is **not** an endorsement of the product.
|
||||
|
||||
If you can not scan the screen (e.g. because you are doing this
|
||||
set-up on the same phone as the authenticator application), you can
|
||||
click the provided link, or copy the secret to manually set-up your
|
||||
authenticator:
|
||||
Two-factor authentication setup
|
||||
===============================
|
||||
|
||||
.. figure:: 2fa/secret_visible.png
|
||||
After selecting an authenticator, log in to Odoo, then click the profile avatar in the upper-right
|
||||
corner, and select :guilabel:`My Profile` from the resulting drop-down menu.
|
||||
|
||||
Click the :guilabel:`Account Security` tab, then slide the :guilabel:`Two-Factor Authentication`
|
||||
toggle to *active*.
|
||||
|
||||
.. figure:: 2fa/account-security.png
|
||||
:align: center
|
||||
|
||||
This generates a :guilabel:`Security Control` pop-up window that requires password confirmation to
|
||||
continue. Enter the appropriate password, then click :guilabel:`Confirm Password`. Next, a
|
||||
:guilabel:`Two-Factor Authentication Activation` pop-up window appears, with a |QR|.
|
||||
|
||||
|
||||
.. figure:: 2fa/qr-code.png
|
||||
:align: center
|
||||
|
||||
Using the desired authenticator application, scan the |QR| when prompted.
|
||||
|
||||
.. tip::
|
||||
If scanning the screen is not possible (e.g. the setup is being completed on the *same* device as
|
||||
the authenticator application), clicking the provided :guilabel:`Cannot scan it?` link, or
|
||||
copying the secret to manually set up the authenticator, is an alternative.
|
||||
|
||||
.. figure:: 2fa/secret-visible.png
|
||||
:align: center
|
||||
|
||||
.. figure:: 2fa/input_secret.png
|
||||
.. figure:: 2fa/input-secret.png
|
||||
:align: center
|
||||
|
||||
Once this is done, the authenticator should display a *verification
|
||||
code* with some useful identifying information (e.g. the domain and
|
||||
login for which the code is):
|
||||
Afterwards, the authenticator should display a *verification code*.
|
||||
|
||||
.. figure:: 2fa/authenticator.png
|
||||
:align: center
|
||||
|
||||
You can now input the code into the :guilabel:`Verification Code`
|
||||
field, then click the :guilabel:`Enable two-factor authentication`
|
||||
button.
|
||||
Enter the code into the :guilabel:`Verification Code` field, then click :guilabel:`Activate`.
|
||||
|
||||
Congratulation, your account is now protected by two-factor
|
||||
authentication!
|
||||
|
||||
.. figure:: 2fa/totp_enabled.png
|
||||
.. figure:: 2fa/2fa-enabled.png
|
||||
:align: center
|
||||
|
||||
Logging in
|
||||
==========
|
||||
|
||||
You should now :guilabel:`Log out` to follow along.
|
||||
To confirm |2fa| setup is complete, log out of Odoo.
|
||||
|
||||
On the login page, input the username and password of the account for
|
||||
which you set up :abbr:`2FA (two-factor authentication)`, rather than
|
||||
immediately enter Odoo you will now get a second log-in screen:
|
||||
On the login page, input the username and password, then click :guilabel:`Log in`. On the
|
||||
:guilabel:`Two-factor Authentication` page, input the code provided by the chosen authenticator in
|
||||
the :guilabel:`Authentication Code` field, then click :guilabel:`Log in`.
|
||||
|
||||
.. figure:: 2fa/2fa_input.png
|
||||
.. image:: 2fa/2fa-login.png
|
||||
:align: center
|
||||
:alt: The login page with 2fa enabled.
|
||||
|
||||
Get your authenticator, input the code it provides for the domain and
|
||||
account, validate, and you're now in.
|
||||
.. danger::
|
||||
If a user loses access to their authenticator, an administrator **must** deactivate |2fa| on the
|
||||
account before the user can log in.
|
||||
|
||||
And that's it. From now on, unless you disable :abbr:`2FA (two-factor
|
||||
authentication)` you will have a two-step log-in process rather than
|
||||
the old one-step process.
|
||||
Enforce two-factor authentication
|
||||
=================================
|
||||
|
||||
.. danger:: Don't lose your authenticator, if you do, you will need an
|
||||
*Odoo Administrator* to disable :abbr:`2FA (two-factor
|
||||
authentication)` on the account.
|
||||
To enforce the use of |2fa| for all users, first navigate to :menuselection:`Main Odoo Dashboard -->
|
||||
Apps`. Remove the :guilabel:`Apps` filter from the :guilabel:`Search...` bar, then search for `2FA
|
||||
by mail`.
|
||||
|
||||
Click :guilabel:`Install` on the Kanban card for the :guilabel:`2FA by mail` module.
|
||||
|
||||
.. image:: 2fa/2FA-by-mail.png
|
||||
:align: center
|
||||
:alt: The 2FA by mail module in the Apps directory.
|
||||
|
||||
After installation is complete, go to :guilabel:`Settings app: Permissions`. Tick the checkbox
|
||||
labeled, :guilabel:`Enforce two-factor authentication`. Then, use the radio buttons to choose
|
||||
whether to apply this setting to :guilabel:`Employees only`, or :guilabel:`All users`.
|
||||
|
||||
.. note::
|
||||
Selecting :guilabel:`All users` applies the setting to portal users, in addition to employees.
|
||||
|
||||
.. image:: 2fa/enforce-settings.png
|
||||
:align: center
|
||||
:alt: The enforce two factor setting in the Settings application.
|
||||
|
||||
Click :guilabel:`Save` to commit any unsaved changes.
|
||||
|
||||
|
After Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 5.3 KiB |
|
After Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 6.7 KiB |
|
After Width: | Height: | Size: 29 KiB |
|
After Width: | Height: | Size: 37 KiB |
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
|
Before Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 33 KiB |
|
Before Width: | Height: | Size: 98 KiB |
|
Before Width: | Height: | Size: 6.3 KiB |
|
Before Width: | Height: | Size: 18 KiB |
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 22 KiB |
@@ -0,0 +1,132 @@
|
||||
===============================
|
||||
Facebook sign-in authentication
|
||||
===============================
|
||||
|
||||
The *Facebook* OAuth sign-in function allows Odoo users to sign in to their database with their
|
||||
Facebook account.
|
||||
|
||||
.. danger::
|
||||
Databases housed on Odoo.com should **not** use OAuth login for the owner or administrator of the
|
||||
database, as it would unlink the database from their Odoo.com account. If OAuth is setup for
|
||||
that user, the database can no longer be duplicated, renamed, or otherwise managed from the
|
||||
Odoo.com portal.
|
||||
|
||||
Meta for Developers setup
|
||||
=========================
|
||||
|
||||
Go to `Meta for Developers <https://developers.facebook.com/>`_ and log in. Click :guilabel:`My
|
||||
Apps`. On the :guilabel:`Apps` page, click :guilabel:`Create App`.
|
||||
|
||||
On the :guilabel:`Use cases` page, select :guilabel:`Authenticate and request data from users with
|
||||
Facebook Login`, then click :guilabel:`Next`.
|
||||
|
||||
In the :guilabel:`Add an app name` field, enter `Odoo Login OAuth`, or a similar title.
|
||||
|
||||
.. note::
|
||||
The :guilabel:`App contact email` automatically defaults to the email address associated with the
|
||||
Meta account. If this email address is not regularly monitored, it may be wise to use another
|
||||
email address.
|
||||
|
||||
Click :guilabel:`Next`. Review the :guilabel:`Publishing requirements`, the :guilabel:`Meta
|
||||
Platform Terms`, and :guilabel:`Developer Policies`. Then, click :guilabel:`Create app`.
|
||||
|
||||
.. important::
|
||||
Clicking :guilabel:`Create app` may require password re-entry.
|
||||
|
||||
Customize app
|
||||
-------------
|
||||
|
||||
After the new app is created, the :guilabel:`Dashboard` page appears, with a list of steps to be
|
||||
completed before the app can be published. From here, click :guilabel:`Customize adding a Facebook
|
||||
Login button`.
|
||||
|
||||
.. image:: facebook/app-requirements.png
|
||||
:align: center
|
||||
:alt: The App Dashboard in the Meta for developers platform.
|
||||
|
||||
On the :guilabel:`Customize` page, click :guilabel:`Settings`.
|
||||
|
||||
In the :guilabel:`Valid OAuth Redirect URIs` field, enter `https://<odoo base
|
||||
url>/auth_oauth/signin`, replacing `<odoo base url>` with the URL of the applicable database.
|
||||
|
||||
.. example::
|
||||
If a database has the URL `https://example.odoo.com`, the URL
|
||||
`https://example.odoo.com/auth_oauth/signin` would be entered in the :guilabel:`Valid OAuth
|
||||
Redirect URIs` field.
|
||||
|
||||
Click :guilabel:`Save changes` when finished.
|
||||
|
||||
Configure settings
|
||||
------------------
|
||||
|
||||
At the far left of the page, click :menuselection:`App settings --> Basic`. This page contains
|
||||
additional settings that are required before the app can be submitted for approval.
|
||||
|
||||
In the :guilabel:`Privacy Policy URL` field, enter `https://www.odoo.com/privacy`.
|
||||
|
||||
.. note::
|
||||
`<https://www.odoo.com/privacy>`_ is the default privacy policy for databases hosted on Odoo.com.
|
||||
|
||||
Click the :guilabel:`App Icon` field to open a file upload window. From here, select and upload an
|
||||
app icon.
|
||||
|
||||
In the :guilabel:`User data deletion` field, enter
|
||||
`https://www.odoo.com/documentation/17.0/administration/odoo_accounts.html`.
|
||||
|
||||
.. note::
|
||||
This document provides instructions on how a user can delete their Odoo account.
|
||||
|
||||
Lastly, click the :guilabel:`Category` field, and select :guilabel:`Business and pages` from the
|
||||
drop-down menu.
|
||||
|
||||
Click :guilabel:`Save changes`.
|
||||
|
||||
.. image:: facebook/app-id.png
|
||||
:align: center
|
||||
:alt: An exampled of the Basic Settings page in the Meta for developers platform.
|
||||
|
||||
.. _users/app-id:
|
||||
|
||||
Capture app ID
|
||||
--------------
|
||||
|
||||
After the app is created, and approved, select and copy the :guilabel:`App ID`. Paste this
|
||||
information on a clipboard or notepad file, as it is needed in a later step to complete the setup.
|
||||
|
||||
Publish
|
||||
-------
|
||||
|
||||
On the left side of the page, click :guilabel:`Publish`. Depending on the status of the connected
|
||||
Facebook account, additional verification and testing steps may be required, and are listed on this
|
||||
page.
|
||||
|
||||
After reviewing the information, click :guilabel:`Publish`.
|
||||
|
||||
.. seealso::
|
||||
Additional information regarding Meta App Development, including further details on building,
|
||||
testing, and use cases, can be found in the `Meta for developers documentation
|
||||
<https://developers.facebook.com/docs/development>`_.
|
||||
|
||||
Odoo setup
|
||||
==========
|
||||
|
||||
First, activate :ref:`Developer mode <developer-mode/activation>`.
|
||||
|
||||
Navigate to the :menuselection:`Settings app`, and scroll down to the :guilabel:`Integrations`
|
||||
section. There, tick the checkbox labeled, :guilabel:`OAuth Authentication`. Click :guilabel:`Save`.
|
||||
|
||||
.. image:: facebook/enable-oauth.png
|
||||
:align: center
|
||||
:alt: The enable OAuth setting in the Settings app.
|
||||
|
||||
Then, sign in to the database once the login screen loads.
|
||||
|
||||
After successfully logging in, navigate to :menuselection:`Settings app --> Users & Companies -->
|
||||
OAuth Providers`. Click :guilabel:`Facebook Graph`.
|
||||
|
||||
In the :guilabel:`Client ID` field, enter the :ref:`App ID <users/app-id>` from the previous
|
||||
section, then tick the :guilabel:`Allowed` checkbox.
|
||||
|
||||
.. image:: facebook/facebook-graph.png
|
||||
:align: center
|
||||
:alt: The Facebook Graph record in Odoo.
|
||||
|
After Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 26 KiB |
@@ -85,6 +85,7 @@ When the information is entered, click :guilabel:`Save`.
|
||||
- :doc:`fleet/models`
|
||||
- :doc:`fleet/new_vehicle`
|
||||
- :doc:`fleet/service`
|
||||
- :doc:`fleet/accidents`
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
@@ -92,3 +93,4 @@ When the information is entered, click :guilabel:`Save`.
|
||||
fleet/models
|
||||
fleet/new_vehicle
|
||||
fleet/service
|
||||
fleet/accidents
|
||||
|
||||
@@ -0,0 +1,280 @@
|
||||
=========
|
||||
Accidents
|
||||
=========
|
||||
|
||||
When managing a fleet, accidents are inevitable. Tracking accidents is crucial for understanding
|
||||
vehicle maintenance costs and identifying safe drivers.
|
||||
|
||||
Odoo's *Fleet* app offers multiple ways to track accidents. Below are step-by-step instructions for
|
||||
only **one** method to monitor accidents and repair costs.
|
||||
|
||||
Structure
|
||||
=========
|
||||
|
||||
For this example, to track accidents, two :ref:`service types <fleet/new-type>` are created:
|
||||
`Accident - Driver's Fault` and `Accident - No Fault`.
|
||||
|
||||
This tracks various repairs associated with accidents, organized by who was at fault.
|
||||
|
||||
When an accident occurs, a service record is created. The specific repairs needed for the accident
|
||||
are logged in the *Description* of the service record, and the details about the accident are logged
|
||||
in the *Notes* section.
|
||||
|
||||
With this organizational structure, it is possible to view all accidents organized by fault, car,
|
||||
driver, or cost.
|
||||
|
||||
.. note::
|
||||
To manage accidents, the creation of service records is **required**.
|
||||
|
||||
Refer to the :doc:`service` documentation for detailed instructions on creating service records
|
||||
in Odoo's *Fleet* app.
|
||||
|
||||
Log accidents and repairs
|
||||
=========================
|
||||
|
||||
To log an accident, and initiate the repair process, the first step is to :ref:`create a service
|
||||
record <fleet/service-form>` detailing the specific repairs needed.
|
||||
|
||||
.. note::
|
||||
Some accidents require multiple repairs with several different vendors. For these scenarios, a
|
||||
separate service record is needed for each vendor performing repairs. To keep records organized,
|
||||
it is recommended to keep the *Notes* field identical, as well as attaching the same important
|
||||
documentation, such as a police report.
|
||||
|
||||
Navigate to :menuselection:`Fleet app --> Fleet --> Services` to view the main :guilabel:`Services`
|
||||
dashboard. Click :guilabel:`New` in the top-left corner, and a blank service form loads.
|
||||
|
||||
Enter the following information on the form:
|
||||
|
||||
- :guilabel:`Description`: enter the description of repairs needed to fully repair the vehicle, such
|
||||
as `Bodywork`, `Windshield Replacement`, or `Replacement Bumper, Tires, and Windows`.
|
||||
- :guilabel:`Service Type`: for this example, select either `Accident - Driver's Fault` or
|
||||
`Accident - No Fault`, depending on the situation.
|
||||
|
||||
When entering either of these two :guilabel:`Service Types` for the first time, type in the new
|
||||
service type, then click :guilabel:`Create (new service type)`. A :guilabel:`Create Service Type`
|
||||
pop-up window appears, with the new service type populating the :guilabel:`Name` field. In the
|
||||
:guilabel:`Category` field, select :guilabel:`Service` from the drop-down menu, then click the
|
||||
:guilabel:`Save & Close` button.
|
||||
|
||||
Once an accident service type has been added to the database, it is available to select from the
|
||||
drop-down menu in the :guilabel:`Service Type` field.
|
||||
- :guilabel:`Date`: using the calendar popover window, select the date the accident occurred.
|
||||
Navigate to the desired month using the :icon:`fa-chevron-left` :icon:`fa-chevron-right`
|
||||
:guilabel:`(arrow)` icons, then click the date to select it.
|
||||
- :guilabel:`Cost`: leave this field blank, as the repair cost is not yet known.
|
||||
- :guilabel:`Vendor`: select the vendor performing the repairs using the drop-down menu. If the
|
||||
vendor has not already been entered in the system, type in the vendor name, and click either
|
||||
:guilabel:`Create` to add them, or :guilabel:`Create and edit...` to :ref:`add and configure the
|
||||
vendor <fleet/new-vendor>`.
|
||||
- :guilabel:`Vehicle`: select the vehicle that was in the accident from the drop-down menu. When the
|
||||
vehicle is selected, the :guilabel:`Driver` field is populated, and the unit of measure for the
|
||||
:guilabel:`Odometer Value` field appears.
|
||||
- :guilabel:`Driver`: the current driver listed for the selected vehicle populates this field when
|
||||
the :guilabel:`Vehicle` is selected. If a different driver was operating the vehicle when the
|
||||
accident occurred, select the correct driver from the drop-down menu.
|
||||
- :guilabel:`Odometer Value`: enter the odometer reading when the accident occurred. The units of
|
||||
measure are either in kilometers (:guilabel:`km`) or miles (:guilabel:`mi`), depending on how the
|
||||
selected vehicle was configured.
|
||||
- :guilabel:`NOTES`: enter the specific details of the accident at the bottom of the service form,
|
||||
such as `Hit a deer` or `Rear-ended at an intersection while stopped`.
|
||||
|
||||
Odoo provides the ability to attach any important paperwork, such as repair estimates and police
|
||||
reports, to the service record. To do so, click the :icon:`fa-paperclip` :guilabel:`(paperclip)`
|
||||
icon, located in the *chatter* of the form, and a file explorer pop-up window appears. Navigate to
|
||||
the desired record, and click :guilabel:`Open` to upload the file.
|
||||
|
||||
.. note::
|
||||
Once a file is added to a service record, a :guilabel:`Files` section appears in the *chatter*.
|
||||
To attach more records, click :icon:`fa-plus-square` :guilabel:`Attach files` to add more
|
||||
documents.
|
||||
|
||||
.. image:: accidents/service-form.png
|
||||
:align: center
|
||||
:alt: Enter the information for an accident repair.
|
||||
|
||||
Service stages
|
||||
==============
|
||||
|
||||
In Odoo's *Fleet* app, there are four default service stages:
|
||||
|
||||
.. tabs::
|
||||
|
||||
.. tab:: New
|
||||
|
||||
The default stage when a service record is created. The service has been requested, but
|
||||
repairs have not begun. The :guilabel:`Cost` field for this stage remains zero.
|
||||
|
||||
.. tab:: Running
|
||||
|
||||
The repair is in-process, but not yet complete. The estimate for repairs is listed in the
|
||||
:guilabel:`Cost` field.
|
||||
|
||||
.. tab:: Completed
|
||||
|
||||
All repairs listed on the service form have been completed. The :guilabel:`Cost` field is
|
||||
updated to reflect the final total cost charged for the repairs.
|
||||
|
||||
.. tab:: Cancelled
|
||||
|
||||
The service request has been cancelled.
|
||||
|
||||
During the repair process, change the service status to reflect the vehicle's current state in one
|
||||
of two ways: on the individual :ref:`service record <fleet/service_record>`, or in the :ref:`Kanban
|
||||
service view <fleet/Kanban>`.
|
||||
|
||||
.. _fleet/service_record:
|
||||
|
||||
Service record
|
||||
--------------
|
||||
|
||||
Open the main *Services* dashboard, by navigating to :menuselection:`Fleet app --> Fleet -->
|
||||
Services`. Next, click on the individual service record to open the detailed service form. Click the
|
||||
desired stage in the top-right corner, above the service form, to change the status.
|
||||
|
||||
.. image:: accidents/running.png
|
||||
:align: center
|
||||
:alt: The stages as seen from the service form.
|
||||
|
||||
.. _fleet/Kanban:
|
||||
|
||||
Kanban view
|
||||
-----------
|
||||
|
||||
Open the main *Services* dashboard, by navigating to :menuselection:`Fleet app --> Fleet -->
|
||||
Services`. First, click the :icon:`oi-view-kanban` :guilabel:`Kanban` icon in the top-right of the
|
||||
screen, which organizes all repairs by vehicle.
|
||||
|
||||
Next, remove the default :guilabel:`Service Type` filter in the search bar. Upon doing so, all
|
||||
services appear in a Kanban view, organized by their respective :guilabel:`Status`.
|
||||
|
||||
Drag-and-drop the service record to the desired stage.
|
||||
|
||||
.. image:: accidents/drag-n-drop.png
|
||||
:align: center
|
||||
:alt: The Kanban view of stages, with a card being dragged and dropped to the Running stage.
|
||||
|
||||
Accident reporting
|
||||
==================
|
||||
|
||||
One of the main reasons to track accidents using the method outlined in this document is the ability
|
||||
to view the total accident cost, determine the safest drivers, and calculate the actual total cost
|
||||
for specific vehicles.
|
||||
|
||||
The main :ref:`Services dashboard <fleet/services_dashboard>` displays all the various accident
|
||||
information, while the :ref:`Reporting dashboard <fleet/reporting_dashboard>` displays the total
|
||||
cost for specific vehicles.
|
||||
|
||||
.. _fleet/services_dashboard:
|
||||
|
||||
Services dashboard
|
||||
------------------
|
||||
|
||||
Navigate to :menuselection:`Fleet app --> Fleet --> Services` to view the :guilabel:`Services`
|
||||
dashboard. All service records are displayed in a :icon:`oi-view-list` :guilabel:`(List)` view,
|
||||
grouped alphabetically, by :guilabel:`Service Type`.
|
||||
|
||||
The two service types created for accident tracking appear in the list: :guilabel:`Accident -
|
||||
Driver Fault` and :guilabel:`Accident - No Fault`.
|
||||
|
||||
Each grouping displays the number of records within each type, and lists the individual records
|
||||
beneath each grouping title.
|
||||
|
||||
.. example::
|
||||
In this example, there are six accidents where the driver was at fault, and four accidents that
|
||||
were not the driver's fault. This dashboard also displays the estimated total :guilabel:`Cost`
|
||||
for all the accidents in each group.
|
||||
|
||||
An estimated `$19,164.81` dollars are for driver-caused accident repairs, and an estimated
|
||||
`$2,548.21` dollars are for no-fault accidents.
|
||||
|
||||
.. image:: accidents/group-accidents.png
|
||||
:align: center
|
||||
:alt: Accident services, with the total costs highlighted.
|
||||
|
||||
.. note::
|
||||
The total :guilabel:`Cost` calculates **all** costs on the repair form, including estimated
|
||||
costs, as well as final repair costs. This number may not be accurate, if there are any repairs
|
||||
in the *Running* stage, and the final bill has not yet been calculated.
|
||||
|
||||
.. _fleet/reporting_dashboard:
|
||||
|
||||
Reporting dashboard
|
||||
-------------------
|
||||
|
||||
Navigate to :menuselection:`Fleet app --> Reporting --> Costs` to view the :menuselection:`Cost
|
||||
Analysis` report. This report displays a :icon:`fa-bar-chart` :guilabel:`(Bar Chart)` of all
|
||||
:guilabel:`Contract` and :guilabel:`Service` costs for the current year, organized by month
|
||||
(:guilabel:`Date : (year)`), by default. The :guilabel:`Sum`, represented by a gray dotted line, is
|
||||
the combined total of both the :guilabel:`Contract` and :guilabel:`Service` costs.
|
||||
|
||||
To view the total cost by vehicle, click the :icon:`fa-caret-down` :guilabel:`(down arrow)` icon at
|
||||
the right of the search bar, revealing a drop-down menu. Click :guilabel:`Vehicle` in the
|
||||
:icon:`oi-group` :guilabel:`Group By` column, and the data is organized by vehicle.
|
||||
|
||||
This displays the true cost for each vehicle, including both the contract cost (such as the monthly
|
||||
vehicle lease cost) and all service costs, including all accidents. Hover over a column to reveal a
|
||||
data popover window, which displays the vehicle name and the total cost. This allows for a more
|
||||
complete view of the vehicle cost.
|
||||
|
||||
.. image:: accidents/total-costs.png
|
||||
:align: center
|
||||
:alt: The Cost Analysis report, displaying total costs by vehicle.
|
||||
|
||||
To view the individual cost details for both contract costs and repairs, click the
|
||||
:icon:`oi-view-pivot` :guilabel:`(Pivot)` icon in the top-right corner of the :guilabel:`Cost
|
||||
Analysis` dashboard. This displays each vehicle on a separate line, and displays the
|
||||
:guilabel:`Contract` cost and :guilabel:`Service` cost, as well as the :guilabel:`Total` cost.
|
||||
|
||||
.. image:: accidents/fleet-pivot.png
|
||||
:align: center
|
||||
:alt: The Cost Analysis report, displaying the contract and service costs separately, as well as
|
||||
the total.
|
||||
|
||||
.. note::
|
||||
The :icon:`oi-view-pivot` :guilabel:`(Pivot)` view organizes the data by vehicle, by default,
|
||||
therefore grouping the data by :guilabel:`Vehicle` is not required. If this filer is already
|
||||
activated, it does not affect the presented data.
|
||||
|
||||
Manage accident repairs
|
||||
=======================
|
||||
|
||||
For companies with multiple employees, who manage a large fleet of vehicles, displaying only service
|
||||
records in the :guilabel:`New` and :guilabel:`Running` stages can be time-saving, if there are a
|
||||
large number of records in the *Services* dashboard.
|
||||
|
||||
Navigate to :menuselection:`Fleet app --> Fleet --> Services`, where all service requests are
|
||||
organized by :guilabel:`Service Type`. Next, click the :icon:`fa-caret-down` :guilabel:`(down
|
||||
arrow)` icon at the right of the search bar, revealing a drop-down menu. Click :guilabel:`Add Custom
|
||||
Filter` in the :icon:`fa-filter` :guilabel:`Filters` column, and a :guilabel:`Add Custom Filter`
|
||||
pop-up window appears.
|
||||
|
||||
Three drop-down fields need to be configured on the pop-up window.
|
||||
|
||||
In the first field, scroll down, and select :guilabel:`Stage`.
|
||||
|
||||
Leave the second field set to :guilabel:`=`.
|
||||
|
||||
Select :guilabel:`Running` from the drop-down menu in the last field.
|
||||
|
||||
Next, click the :icon:`fa-plus` :guilabel:`(plus)` icon to the right of the last field, and an
|
||||
identical rule appears beneath the current rule.
|
||||
|
||||
Then, change :guilabel:`Running` to :guilabel:`New` in the third field of the second rule, leaving
|
||||
the other fields as-is.
|
||||
|
||||
Click the :guilabel:`Add` button at the bottom to add the new custom filter.
|
||||
|
||||
.. image:: accidents/custom-filters.png
|
||||
:align: center
|
||||
:alt: The filter settings to be added to only display new and running services.
|
||||
|
||||
This slight modification only presents services in the :guilabel:`New` and :guilabel:`Running`
|
||||
stages. This is a helpful report for a company managing a high number of repairs at any given time.
|
||||
|
||||
To have this report appear as the default report when opening the :guilabel:`Services` dashboard,
|
||||
click the :icon:`fa-caret-down` :guilabel:`(down arrow)` icon at the far-right of the search bar.
|
||||
Next, click :guilabel:`Save current search`, beneath the :icon:`fa-star` :guilabel:`Favorites`
|
||||
column, which reveals another drop-down column beneath it. Tick the checkbox beside
|
||||
:guilabel:`Default Filter`, then click :guilabel:`Save`. Then, this customized :guilabel:`Services`
|
||||
dashboard appears, by default, anytime the :guilabel:`Services` dashboard is accessed.
|
||||
|
After Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 33 KiB |
|
After Width: | Height: | Size: 23 KiB |
|
After Width: | Height: | Size: 48 KiB |
|
After Width: | Height: | Size: 12 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 9.2 KiB |
@@ -1,5 +1,4 @@
|
||||
:show-content:
|
||||
:show-toc:
|
||||
|
||||
===========
|
||||
Recruitment
|
||||
@@ -369,190 +368,23 @@ saved to be used in the future, the email can be saved as a new template. Click
|
||||
Template` button in the bottom. To send the email, click :guilabel:`Send` and the email is sent to
|
||||
the applicant. The email then appears in the chatter.
|
||||
|
||||
Stage flow
|
||||
==========
|
||||
|
||||
In order to move an applicant's card from one stage to another, the applicant's card can either be
|
||||
dragged and dropped in the Kanban view to the desired stage, or the stage can be modified on the
|
||||
applicant's card.
|
||||
|
||||
To change the stage on the applicant's card, click on the applicant's card in the Kanban view to go
|
||||
to a detailed view of the card. The current stage for the card is highlighted at the top, above the
|
||||
card.
|
||||
|
||||
Click the desired stage for the card, and the stage changes. A log note indicating the stage change
|
||||
appears in the chatter. Navigate back to the Kanban view by clicking on :guilabel:`Applications` in
|
||||
the breadcrumb menu in the top-left, and the applicant's card now appears in the new stage.
|
||||
|
||||
.. image:: recruitment/stage-change.png
|
||||
:align: center
|
||||
:alt: Change the stage of an applicant by clicking on the desired stage at the top of the
|
||||
applicant's card.
|
||||
|
||||
.. _recruitment/new:
|
||||
|
||||
New
|
||||
---
|
||||
|
||||
.. important::
|
||||
The following information is based on Odoo's default recruitment pipeline flow. Be advised that
|
||||
if modifications are made to create a customized recruitment pipeline flow, it will vary from the
|
||||
following information.
|
||||
|
||||
All applicants appear in the :guilabel:`New` stage, whether submitted online or if the applicant is
|
||||
manually entered by a recruiter.
|
||||
|
||||
When the applicant's card is created, Odoo automatically populates the
|
||||
:guilabel:`Subject/Application`, the applicant's :guilabel:`Name`, :guilabel:`Email`,
|
||||
:guilabel:`Mobile` number, and :guilabel:`LinkedIn Profile` on the applicant's card. This
|
||||
information is required when applying for a job position, by default.
|
||||
|
||||
.. note::
|
||||
If the website application form is modified, different fields may be populated based on what
|
||||
information is requested on the website.
|
||||
|
||||
If the applicant entered any information in the :guilabel:`Short Introduction` section of the online
|
||||
application, it will populate in the :guilabel:`Application Summary` tab at the bottom of the
|
||||
applicant's card.
|
||||
|
||||
Resumé
|
||||
~~~~~~
|
||||
|
||||
If a resumé was attached to the online application, the resumé would appear in the attachments
|
||||
section of the chatter, and is also stored in the *Documents* application. To find the recruitment
|
||||
documents stored in the *Documents* application, navigate to the main :menuselection:`Documents`
|
||||
dashboard, and click the folder labeled :guilabel:`Recruitment` on the left-hand side. All
|
||||
recruitment documents are stored within that folder.
|
||||
|
||||
If the :ref:`CV Display <recruitment/cv-display>` option was enabled in the :ref:`Settings
|
||||
<recruitment/settings>` menu, the resumé appears on the applicant's card, on the right-hand side.
|
||||
|
||||
Send interview
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
At any point in the hiring process, an *interview* can be sent to the applicant to obtain more
|
||||
information. These interviews are custom-made, and can be formatted in a variety of ways.
|
||||
|
||||
The *Surveys* application is used to send these *interviews*, therefore the *Surveys* application
|
||||
must be installed to send an interview to an applicant.
|
||||
|
||||
Odoo uses the term *interview*, but these can be thought of as questionnaires, surveys, tests,
|
||||
certifications, etc. Custom interviews can be formatted to suit each individual job positions
|
||||
needs. For more information on creating and editing interview forms, refer to the
|
||||
:doc:`../hr/recruitment/new_job` documentation.
|
||||
|
||||
.. example::
|
||||
A job position for a computer programmer could have an interview in the form of a programming
|
||||
quiz to determine the skill level of the applicant. A job position for a restaurant server could
|
||||
have a questionnaire inquiring about the applicant's availability, if the desired applicant needs
|
||||
to be available on weekend evenings.
|
||||
|
||||
To send an interview to an applicant, click on an applicant's card to navigate to a detailed view of
|
||||
the applicant's card. At the top-left of the applicant's card, click the :guilabel:`Send Interview`
|
||||
button.
|
||||
|
||||
If the applicant's card has an email address on file, a :guilabel:`Send an interview` pop-up window
|
||||
appears, with all the information populated.
|
||||
|
||||
.. note::
|
||||
In order to send an email to an applicant, there must be an email address on the applicant's
|
||||
card. If an email address is not entered on the applicant's card, when :guilabel:`Send Interview`
|
||||
is clicked, an :guilabel:`Edit:(Applicant)` pop-up window appears on top of the :guilabel:`Send
|
||||
an interview` pop-up window. Enter the email address in the :guilabel:`email` field, then click
|
||||
:guilabel:`Save & Close`. Once the applicant's information is saved, the :guilabel:`Edit:
|
||||
(Applicant)` closes and the :guilabel:`Send an interview` pop-up window remains.
|
||||
|
||||
Email templates use dynamic placeholders to personalize the email to the applicant and the job
|
||||
position. Add any additional recipients for the survey if more people should receive the email. If
|
||||
an email is in the database as a contact, add that contact in the :guilabel:`Recipients` field. If
|
||||
an email should be sent to someone who is not in the database as a contact, and they should **not**
|
||||
be added as a contact, add their email in the :guilabel:`Additional emails` field.
|
||||
|
||||
If any attachments need to be added, click the :guilabel:`Attachments` button and a file explorer
|
||||
window appears. Navigate to the desired file, then click :guilabel:`Open` to attach it to the email.
|
||||
The attachment loads, and is listed above the :guilabel:`Attachments` button.
|
||||
|
||||
If the emailed interview must be completed by a specific date, select a date for the
|
||||
:guilabel:`Answer deadline` in the lower-right area of the pop-up window. Click on the line next to
|
||||
:guilabel:`Answer deadline`, and a calendar selector appears. Use the :icon:`fa-chevron-left`
|
||||
:guilabel:`(left)` and :icon:`fa-chevron-right` :guilabel:`(right)` arrows on either side of the
|
||||
month to navigate to the desired month, then click on the :guilabel:`day` to select the date.
|
||||
|
||||
The :guilabel:`Mail Template` field is pre-populated based on the configuration for the interview. A
|
||||
different template can be chosen from the drop-down menu if desired. If a new template is selected,
|
||||
the new email template loads in the email body.
|
||||
|
||||
To send the email with the interview link to the applicant, click :guilabel:`Send` at the bottom of
|
||||
the email pop-up.
|
||||
|
||||
.. image:: recruitment/send-survey.png
|
||||
:align: center
|
||||
:alt: Send a custom survey, also referred to as an interview form, to an applicant using a
|
||||
pre-configured template.
|
||||
|
||||
.. _recruitment/initial-qualification:
|
||||
|
||||
Initial qualification
|
||||
---------------------
|
||||
|
||||
If an applicant seems to be a good potential candidate, they are moved to the :guilabel:`Initial
|
||||
Qualification` stage. This could be for a number of reasons, such as they have the relevant
|
||||
experience, education, or certifications the position requires.
|
||||
|
||||
This stage is to quickly sort candidates that have potential, and those that do not meet the
|
||||
requirements. No automatic actions, such as emails, are set for this stage. This stage simply
|
||||
informs the recruitment team to potentially set up a phone call or an interview with the candidate.
|
||||
|
||||
.. _recruitment/first-interview:
|
||||
|
||||
First interview
|
||||
---------------
|
||||
|
||||
After an applicant has passed the :guilabel:`Initial Qualification` stage, they can be moved to the
|
||||
:guilabel:`First Interview` stage in the job position Kanban view. To move the applicant to the next
|
||||
stage, drag and drop the applicant's card to the :guilabel:`First Interview` stage, or click on the
|
||||
:guilabel:`First Interview` stage button at the top of the individual applicant's card.
|
||||
|
||||
.. image:: recruitment/move.png
|
||||
:align: center
|
||||
:alt: An applicant's card moves from one stage to another by using the click and drag method.
|
||||
|
||||
.. tip::
|
||||
The :guilabel:`First Interview` stage can be modified, so when the applicant's card moves to the
|
||||
:guilabel:`First Interview` stage, an email is automatically sent to the applicant, stating an
|
||||
interview is requested, and :ref:`requests the applicant to schedule their interview
|
||||
<recruitment/schedule_interviews/applicant-scheduled>`.
|
||||
|
||||
:ref:`Edit <recruitment/edit-stage>` the :guilabel:`First Interview` stage, and select the
|
||||
:guilabel:`Recruitment: Schedule Interview` for the :guilabel:`Email Template` field, to automate
|
||||
this action.
|
||||
|
||||
.. _recruitment/second-interview:
|
||||
|
||||
Second interview
|
||||
----------------
|
||||
|
||||
After an applicant has passed the :guilabel:`First Interview` stage, they can be moved to the
|
||||
:guilabel:`Second Interview` stage. To move the applicant to the next stage, drag and drop the
|
||||
applicant's card to the :guilabel:`Second Interview` stage, or click on the :guilabel:`Second
|
||||
Interview` stage button at the top of the individual applicant's card.
|
||||
|
||||
When the applicant's card moves to the :guilabel:`Second Interview` stage, there are no automatic
|
||||
activities or emails configured. The recruiter can now :doc:`schedule a second interview
|
||||
<recruitment/schedule_interviews>` with the applicant, following the same process as the first
|
||||
interview.
|
||||
|
||||
.. seealso::
|
||||
- recruitment/new_job
|
||||
- recruitment/add-new-applicants
|
||||
- recruitment/schedule_interviews
|
||||
- recruitment/offer_job_positions
|
||||
- recruitment/refuse_applicant
|
||||
- :doc:`recruitment/new_job`
|
||||
- :doc:`recruitment/add-new-applicants`
|
||||
- :doc:`recruitment/schedule_interviews`
|
||||
- :doc:`recruitment/offer_job_positions`
|
||||
- :doc:`recruitment/refuse_applicant`
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
recruitment/new_job
|
||||
recruitment/recruitment-flow
|
||||
recruitment/add-new-applicants
|
||||
recruitment/schedule_interviews
|
||||
recruitment/offer_job_positions
|
||||
|
||||
@@ -146,6 +146,8 @@ banner appears in the top-right of the applicant's card and form.
|
||||
:align: center
|
||||
:alt: Hired banner in the top right corner of applicant card.
|
||||
|
||||
.. _recruitment/new-employee:
|
||||
|
||||
Create employee
|
||||
===============
|
||||
|
||||
|
||||
@@ -0,0 +1,233 @@
|
||||
================
|
||||
Recruitment flow
|
||||
================
|
||||
|
||||
When a prospective employee applies for a job in Odoo, there is a preconfigured process from the
|
||||
:ref:`initial inquiry <recruitment/new>` to the :ref:`creating of a new employee
|
||||
<recruitment/new-employee>` once hired. The following outlines the default recruitment process for
|
||||
Odoo's *Recruitment* application.
|
||||
|
||||
.. important::
|
||||
The following is based on Odoo's default recruitment pipeline. Be advised that if
|
||||
:ref:`modifications are made <recruitment/customize-stages>` to the pipeline, the process
|
||||
differs.
|
||||
|
||||
.. _recruitment/new:
|
||||
|
||||
New
|
||||
===
|
||||
|
||||
At the start of the process, all applicants appear in the :guilabel:`New` stage on the
|
||||
:guilabel:`Applications` page, whether submitted online or if the applicant is :doc:`manually
|
||||
entered by a recruiter <add-new-applicants>`.
|
||||
|
||||
When the applicant's card is created, Odoo automatically populates the
|
||||
:guilabel:`Subject/Application`, the :guilabel:`Applicant's Name`, :guilabel:`Email`, and
|
||||
:guilabel:`Mobile` number, on the applicant's card. This information is required when applying for
|
||||
a job position, by default.
|
||||
|
||||
.. note::
|
||||
If the website application form is modified, different fields may be populated, based on what
|
||||
information is requested on the website.
|
||||
|
||||
If the applicant entered any information in the *Short Introduction* section of the online
|
||||
application, it populates the :guilabel:`Application Summary` tab at the bottom of the applicant's
|
||||
card.
|
||||
|
||||
Resumé
|
||||
------
|
||||
|
||||
If a resumé was attached to the online application, it appears in the :guilabel:`Files` section of
|
||||
the chatter, and is also stored in the *Documents* application.
|
||||
|
||||
To find the recruitment documents, navigate to the main :menuselection:`Documents app` dashboard,
|
||||
and click the :guilabel:`Recruitment` folder on the left-hand side. All recruitment documents are
|
||||
stored within that folder.
|
||||
|
||||
If the :ref:`CV Display <recruitment/cv-display>` option was enabled in the :ref:`Settings
|
||||
<recruitment/settings>` of the *Recruitment* app, the resumé appears on the applicant's card, on the
|
||||
right-hand side.
|
||||
|
||||
.. note::
|
||||
Depending on the browser zoom level, or size of the browser screen, the resumé may appear below
|
||||
the main applicant card information as a PDF link.
|
||||
|
||||
Send interview
|
||||
--------------
|
||||
|
||||
At any point in the hiring process, an interview can be sent to the applicant to obtain more
|
||||
information. These interviews are custom-made, and can be formatted in a variety of ways.
|
||||
|
||||
The *Surveys* application is **required** to send interviews to an applicant, so it **must** be
|
||||
installed.
|
||||
|
||||
Odoo uses the term *interview*, but these can be thought of as questionnaires, surveys, tests,
|
||||
certifications, etc. Custom interviews can be formatted to suit each individual job position's
|
||||
needs. For more information on creating and editing interviews, refer to the
|
||||
:doc:`../../hr/recruitment/new_job` documentation.
|
||||
|
||||
.. example::
|
||||
A job position for a computer programmer could have an interview in the form of a programming
|
||||
quiz to determine the skill level of the applicant. A job position for a restaurant server could
|
||||
have a questionnaire inquiring about the applicant's availability, if the desired applicant needs
|
||||
to be available on weekend evenings.
|
||||
|
||||
To send an interview to an applicant, first click the applicant's card from the
|
||||
:guilabel:`Applications` page, to view the detailed applicant information. At the top-left of the
|
||||
applicant's card, click the :guilabel:`Send Interview` button.
|
||||
|
||||
If the applicant's card has an email address on file, a :guilabel:`Send an interview` pop-up window
|
||||
appears, with the :guilabel:`Recipients`, :guilabel:`Subject`, and email body populated.
|
||||
|
||||
.. note::
|
||||
To send an email to an applicant, there **must** be an :guilabel:`Email` address on the
|
||||
applicant's card.
|
||||
|
||||
If an email address is not entered on the applicant's card, when the :guilabel:`Send Interview`
|
||||
button is clicked, an :guilabel:`Edit: (Applicant's Name)` pop-up window appears, *on top of* the
|
||||
:guilabel:`Send an interview` pop-up window.
|
||||
|
||||
Enter the email address in the :guilabel:`Email` field, then click :guilabel:`Save & Close`.
|
||||
|
||||
Once the applicant's information is saved, the :guilabel:`Edit: (Applicant's Name)` pop-up window
|
||||
closes, and the :guilabel:`Send an interview` pop-up window remains.
|
||||
|
||||
Sometimes, preconfigured email templates in Odoo use dynamic placeholders, which are automatically
|
||||
filled with specific data when the email is sent. For example, if a placeholder for the applicant's
|
||||
name is used, it is replaced with the actual name of the applicant in the email. For more detailed
|
||||
information on email templates, refer to the :doc:`../../general/companies/email_template`
|
||||
documentation.
|
||||
|
||||
Add the email addresses of any additional recipients for the survey in the :guilabel:`Additional
|
||||
emails` field, if more people should receive the email. If an email address is in the database as a
|
||||
contact, add that contact in the :guilabel:`Recipients` field. If an email should be sent to someone
|
||||
who is not in the database as a contact, and they should **not** be added as a contact, add their
|
||||
email address in the :guilabel:`Additional emails` field.
|
||||
|
||||
If any attachments need to be added, click the :icon:`fa-paperclip` :guilabel:`Attachments` button,
|
||||
and a file explorer window appears. Navigate to the desired file, and click :guilabel:`Open` to
|
||||
attach it to the email. The attachment loads, and is listed above the :icon:`fa-paperclip`
|
||||
:guilabel:`Attachments` button.
|
||||
|
||||
If the emailed interview must be completed by a specific date, enter that date in the
|
||||
:guilabel:`Answer deadline` field, located in the lower-right area of the pop-up window.
|
||||
|
||||
To do so, click the empty field next to :guilabel:`Answer deadline`, and a calendar selector
|
||||
appears. Use the :icon:`fa-chevron-left` :guilabel:`(left)` and :icon:`fa-chevron-right`
|
||||
:guilabel:`(right)` arrows, on either side of the month, to navigate to the desired month. Then,
|
||||
click on the desired day to select the date.
|
||||
|
||||
The :guilabel:`Mail Template` field is pre-populated, based on the configuration for the interview.
|
||||
A different template can be chosen from the drop-down menu, if desired. If a new template is
|
||||
selected, the new email template loads in the email body.
|
||||
|
||||
To send the email with the interview link to the applicant, click :guilabel:`Send` at the bottom of
|
||||
the email pop-up window.
|
||||
|
||||
.. image:: recruitment-flow/send-survey.png
|
||||
:align: center
|
||||
:alt: Send a custom survey, also referred to as an interview form, to an applicant using a
|
||||
pre-configured template.
|
||||
|
||||
.. _recruitment/initial-qualification:
|
||||
|
||||
Initial qualification
|
||||
=====================
|
||||
|
||||
If an applicant seems to be a good potential candidate, they are moved to the :guilabel:`Initial
|
||||
Qualification` stage.
|
||||
|
||||
This stage exists to quickly sort candidates that have potential, from those that do not meet the
|
||||
requirements. No automatic actions, such as emails, are set for this stage. This stage simply
|
||||
informs the recruitment team to potentially set up a phone call or an interview with the candidate.
|
||||
|
||||
.. note::
|
||||
In order to move an applicant's card from one stage to another, the applicant's card can either
|
||||
be dragged and dropped in the Kanban view of the :guilabel:`Applications` page to the desired
|
||||
stage, or the stage can be modified on the applicant's card.
|
||||
|
||||
To change the stage on the applicant's card, first click the desired applicant's card from the
|
||||
:guilabel:`Applications` page. The current stage for the card is highlighted at the top on a
|
||||
status bar, above the card.
|
||||
|
||||
Click the desired stage for the card, and the stage changes. A log note indicating the stage
|
||||
change appears in the chatter, as well.
|
||||
|
||||
.. image:: recruitment-flow/stage-change.png
|
||||
:align: center
|
||||
:alt: Change the stage of an applicant by clicking on the desired stage at the top of the
|
||||
applicant's card.
|
||||
|
||||
.. _recruitment/first-interview:
|
||||
|
||||
First interview
|
||||
===============
|
||||
|
||||
After an applicant has passed the :guilabel:`Initial Qualification` stage, they can be manually
|
||||
moved to the :guilabel:`First Interview` stage on the :guilabel:`Applications` page, while in Kanban
|
||||
view.
|
||||
|
||||
To move the applicant to the next stage, drag-and-drop the applicant's card to the :guilabel:`First
|
||||
Interview` stage.
|
||||
|
||||
Alternatively, open the desired applicant's card from the :guilabel:`Applications` page, and click
|
||||
the :guilabel:`First Interview` stage on the status bar at the top of the individual applicant's
|
||||
card.
|
||||
|
||||
.. image:: recruitment-flow/move.png
|
||||
:align: center
|
||||
:alt: An applicant's card moves from one stage to another by using the click and drag method.
|
||||
|
||||
.. tip::
|
||||
The :guilabel:`First Interview` stage can be modified, so when the applicant's card moves to the
|
||||
:guilabel:`First Interview` stage, an email can be automatically sent to the applicant, stating
|
||||
an interview is requested. In this pre-configured email template, a link to the recruiting team's
|
||||
calendar appears, allowing the applicant to schedule their interview.
|
||||
|
||||
:ref:`Edit <recruitment/edit-stage>` the :guilabel:`First Interview` stage, and select the
|
||||
:guilabel:`Recruitment: Schedule Interview` option in the :guilabel:`Email Template` field, to
|
||||
automate this action.
|
||||
|
||||
.. _recruitment/second-interview:
|
||||
|
||||
Second interview
|
||||
================
|
||||
|
||||
After an applicant has passed the :guilabel:`First Interview` stage, they can be moved to the
|
||||
:guilabel:`Second Interview` stage. To move the applicant to the next stage, drag-and-drop the
|
||||
applicant's card to the :guilabel:`Second Interview` stage from the Kanban view of the
|
||||
:guilabel:`Applications` page, or click on the :guilabel:`Second Interview` stage at the top of the
|
||||
individual applicant's card.
|
||||
|
||||
When the applicant's card moves to the :guilabel:`Second Interview` stage, there are no automatic
|
||||
activities or emails configured for this stage, by default. The recruiter can now :ref:`schedule a
|
||||
second interview <recruitment/schedule_interviews/recruitment-scheduled>` with the applicant,
|
||||
following the same process as the first interview.
|
||||
|
||||
.. _recruitment/contract-proposal:
|
||||
|
||||
Contract Proposal
|
||||
=================
|
||||
|
||||
After the applicant has completed the various interview processes, the next step is to :doc:`send
|
||||
the job offer <offer_job_positions>`.
|
||||
|
||||
Once the offer has been sent, drag-and-drop the applicant's card to the :guilabel:`Contract
|
||||
Proposal` stage from the Kanban view of the :guilabel:`Applications` page, or click on the
|
||||
:guilabel:`Contract Proposal` stage at the top of the individual applicant's card.
|
||||
|
||||
Contract Signed
|
||||
===============
|
||||
|
||||
Once the contract has been signed, and the applicant has been hired, the applicant's card moves to
|
||||
the :guilabel:`Contract Signed` stage.
|
||||
|
||||
Drag-and-drop the applicant's card to the :guilabel:`Contract Signed` stage from the Kanban view of
|
||||
the :guilabel:`Applications` page, or click the :icon:`fa-ellipsis-h` :guilabel:`(ellipsis)` icon at
|
||||
the top of the individual applicant's card, then click :guilabel:`Contract Signed` on the status
|
||||
bar.
|
||||
|
||||
Refuse applicant
|
||||
================
|
||||
|
||||
At any point in the recruitment process, a candidate can be :doc:`refused <refuse_applicant>`.
|
||||
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 13 KiB |
|
Before Width: | Height: | Size: 30 KiB After Width: | Height: | Size: 30 KiB |
|
After Width: | Height: | Size: 31 KiB |
|
After Width: | Height: | Size: 36 KiB |
|
After Width: | Height: | Size: 30 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 32 KiB |
|
After Width: | Height: | Size: 10 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
Before Width: | Height: | Size: 9.0 KiB After Width: | Height: | Size: 9.0 KiB |
@@ -12,111 +12,139 @@ scanned, it is associated to the **first** rule with a matching pattern. The pat
|
||||
described in Odoo's nomenclature list using a regular expression, and a barcode is successfully read
|
||||
by Odoo if its prefix and/or length matches the one defined in the barcode's rule.
|
||||
|
||||
Odoo *Barcode* supports UPC (Universal Product Code), EAN (European Article Number), and GS1
|
||||
encoding. The pre-configured nomenclatures in Odoo are *Default Nomenclature* and *Default GS1
|
||||
Nomenclature*. The default nomenclature uses |UPC| and |EAN| encoding, and supports |UPC|/|EAN|
|
||||
conversion.
|
||||
For instance, at a :doc:`Point of Sale <../../../sales/point_of_sale>` station, product weight
|
||||
barcodes in the European Article Number (EAN) format, which begin with `21` and have five digits
|
||||
specifying the weight, are used to weigh products and generate a barcode depicting the weight and
|
||||
price. The `21` and five-digit weight is the barcode pattern used to identify the barcode and can be
|
||||
customized to ensure Odoo correctly interprets all barcodes for the business.
|
||||
|
||||
.. note::
|
||||
Barcodes are also commonly used with Odoo's **Inventory** and **Barcode** apps.
|
||||
|
||||
Odoo **Barcode** supports |EAN|, Universal Product Code (UPC), and :doc:`GS1 <gs1_nomenclature>`
|
||||
formats. This document exclusively focuses on :ref:`default rules and patterns in Odoo
|
||||
<barcode/operations/default-nomenclature-list>`, which use |UPC| and |EAN| encoding.
|
||||
|
||||
.. important::
|
||||
|UPC| and |EAN| barcodes **must** be `purchased from GS1
|
||||
<https://www.gs1.org/standards/get-barcodes>`_ to use these barcodes. GS1 is the **only**
|
||||
official provider of |UPC|/|EAN| and GS1 |GTINs| in the world.
|
||||
To use |UPC| and |EAN| barcodes for uniquely identifying products across the entire supply chain,
|
||||
they **must** be `purchased from GS1 <https://www.gs1.org/standards/get-barcodes>`_.
|
||||
|
||||
.. _barcode/operations/set-up-nomenclature:
|
||||
In Odoo, custom barcode patterns can be defined to recognize barcodes specific to the company.
|
||||
Barcodes do not need to be purchased if used only within the company, such as in the
|
||||
:ref:`example <barcode/operations/product-weight>` where the barcode is written in the |EAN|
|
||||
format.
|
||||
|
||||
Set up barcode nomenclature
|
||||
===========================
|
||||
Configuration
|
||||
=============
|
||||
|
||||
To use default nomenclature, navigate to :menuselection:`Inventory app --> Configuration -->
|
||||
Settings`. Under the :guilabel:`Barcode` section, click the checkbox next to :guilabel:`Barcode
|
||||
Scanner` to enable barcodes. Doing so installs the *Barcode* app in the database.
|
||||
Settings`. Under the :guilabel:`Barcode` section, tick the :guilabel:`Barcode Scanner` checkbox.
|
||||
Doing so installs the **Barcode** app in the database.
|
||||
|
||||
Next, ensure that the :guilabel:`Default Nomenclature` setting is selected in the :guilabel:`Barcode
|
||||
Nomenclature` field. Then, click :guilabel:`Save`.
|
||||
Next, in the :guilabel:`Barcode Nomenclature` field, ensure :guilabel:`Default Nomenclature` is
|
||||
selected. Then, click :guilabel:`Save`.
|
||||
|
||||
.. image:: barcode_nomenclature/barcode-nomenclature-enabled-setting.png
|
||||
.. image:: barcode_nomenclature/enable-nomenclature.png
|
||||
:align: center
|
||||
:alt: Enabled barcode setting with Default Nomenclature selected.
|
||||
|
||||
Once the nomenclature is saved and selected, the :menuselection:`Barcode Nomenclatures` settings can
|
||||
be accessed, via a hidden menu that is **only** discoverable after enabling :ref:`developer mode
|
||||
<developer-mode>`.
|
||||
With the **Barcode** module installed, and the :guilabel:`Default Nomenclature` selected, the
|
||||
barcode actions using |UPC| and |EAN|, detailed in the :ref:`default nomenclature list
|
||||
<barcode/operations/default-nomenclature-list>`, are available for use. And, by default, Odoo
|
||||
automatically handles |UPC|/|EAN| conversion.
|
||||
|
||||
Once developer mode is enabled, navigate to :menuselection:`Inventory app --> Configuration -->
|
||||
Barcode Nomenclatures` menu, and select :guilabel:`Default Nomenclature`.
|
||||
.. _barcode/operations/product-weight:
|
||||
|
||||
From this page, the :guilabel:`Barcode Nomenclature` is specified at the top as the `Default
|
||||
Nomenclature`.
|
||||
Example: product weight barcode
|
||||
===============================
|
||||
|
||||
Under that, the :guilabel:`UPC/EAN Conversion` field is set to :guilabel:`Always`, by default. This
|
||||
setting determines if a |UPC|/|EAN| barcode should be automatically converted one way or another
|
||||
when trying to match a rule with the other encoding.
|
||||
To better understand how barcode nomenclature is used to identify products in Odoo, this example
|
||||
where product weight barcodes in |EAN| format are used to allow a :doc:`Point of Sale
|
||||
<../../../sales/point_of_sale>` business to automatically print barcodes, and calculate the price
|
||||
using the weight of the item.
|
||||
|
||||
The other available options for this field are :guilabel:`Never`, :guilabel:`EAN-13 to UPC-A`, and
|
||||
:guilabel:`UPC-A to EAN-13`.
|
||||
To set up barcodes for weighted products, the following rule is used:
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
|
||||
* - Rule Name
|
||||
- Barcode Pattern
|
||||
- Field in Odoo
|
||||
* - Weighted Barcodes 3 Decimals
|
||||
- (21)....{NNDDD}
|
||||
- :guilabel:`Barcode` field on product form
|
||||
|
||||
.. example::
|
||||
To better understand the barcode pattern for weighted products, consider the barcode,
|
||||
`2112345000008`:
|
||||
|
||||
- `21`: code that identifies this a barcode for weighted products.
|
||||
- `12345`: five digits (denoted by `.....` in the table above) that identify the product.
|
||||
- `00000`: five digits (denoted by `{NNDDD}` in the table) representing the weight of the
|
||||
product. On the product form, the five weight values **must** be `00000`. The first two digits
|
||||
are whole number values, and the last three digits are decimal values. For example, "13.5
|
||||
grams" in the `{NNDDD}` format is `13500`.
|
||||
- `8`: `check digit <https://www.gs1.org/services/check-digit-calculator>`_ for `211234500000`.
|
||||
|
||||
Together, these components make up a 13-character |EAN| - 13 barcode.
|
||||
|
||||
To configure the product barcode for `Pasta Bolognese`, the |EAN| barcode for weighted products,
|
||||
`2112345000008`, is entered in the :guilabel:`Barcode` field on the product form (accessible by
|
||||
going to :menuselection:`Inventory app --> Products --> Products`, and selecting the desired
|
||||
product). In addition, the :guilabel:`Unit of Measure` is set to :guilabel:`kg`.
|
||||
|
||||
.. image:: barcode_nomenclature/barcode.png
|
||||
:align: center
|
||||
:alt: Barcode field on the product form.
|
||||
|
||||
Next, a customer's bowl of pasta is weighed to be `1.5` kilograms. This generates a new barcode for
|
||||
the pasta, according to the weight: `211234501500`, which has a check digit of `2`. The new barcode
|
||||
is `2112345015002`.
|
||||
|
||||
.. image:: barcode_nomenclature/weighted-barcode.png
|
||||
:align: center
|
||||
:alt: Generated barcode that includes a weight of 1.5 kg.
|
||||
|
||||
Ensure the products scan properly, by navigating to the :menuselection:`Barcode app --> Operations`.
|
||||
Next, click any operation type, such as :guilabel:`Receipts`. Then, click the :guilabel:`New` button
|
||||
to create a draft stock move. Scan the product weight barcode, such as `2112345015002`, and if the
|
||||
intended product appears, the barcode setup is correct.
|
||||
|
||||
.. image:: barcode_nomenclature/barcode-scan.png
|
||||
:align: center
|
||||
:alt: Show successfully scanned barcode.
|
||||
|
||||
Create rules
|
||||
============
|
||||
|
||||
.. important::
|
||||
For |UPC|/|EAN| conversion to work for every barcode scanned, the setting in the
|
||||
:guilabel:`UPC/EAN Conversion` field **must** be set to :guilabel:`Always`.
|
||||
Adding new rules is necessary for |UPC| and |EAN| formats that are **not** in Odoo's default
|
||||
list, since barcodes cannot be read successfully if there are unknown fields.
|
||||
|
||||
The last field at the top of the page is the :guilabel:`Is GS1 Nomenclature` field. For the
|
||||
:guilabel:`Default Nomenclature`, this field should remain unchecked. This is because the
|
||||
:guilabel:`Default Nomenclature` uses |UPC| and |EAN| encoding, *not* GS1 encoding.
|
||||
While new rules can be created, Odoo fields do **not** auto-populate with information from these
|
||||
rules. `Custom development <https://www.odoo.com/appointment/132>`_ is required for this
|
||||
functionality.
|
||||
|
||||
.. image:: barcode_nomenclature/barcode-nomenclature-page-fields.png
|
||||
To create a rule, first enable :ref:`developer mode <developer-mode>`. Then, navigate to
|
||||
:menuselection:`Inventory app --> Configuration --> Barcode Nomenclatures`, and select
|
||||
:guilabel:`Default Nomenclature`.
|
||||
|
||||
On this page, configure the following optional fields:
|
||||
|
||||
- :guilabel:`UPC/EAN Conversion`: determines if a |UPC|/|EAN| barcode should be automatically
|
||||
converted when matching a rule with another encoding. Options include :guilabel:`Always` (the
|
||||
default option), :guilabel:`Never`, :guilabel:`EAN-13 to UPC-A`, and :guilabel:`UPC-A to EAN-13`.
|
||||
- :guilabel:`Is GS1 Nomenclature`: ensure this checkbox is **not** ticked, as the
|
||||
:guilabel:`Default Nomenclature` uses |UPC| and |EAN| encoding, *not* GS1 encoding.
|
||||
|
||||
.. image:: barcode_nomenclature/rule-config.png
|
||||
:align: center
|
||||
:alt: Default Nomenclature page setting fields.
|
||||
|
||||
Further down the page, there is a list showcasing the :guilabel:`Rule Name`, :guilabel:`Type`,
|
||||
:guilabel:`Encoding`, and :guilabel:`Barcode Pattern` for the *rules* and *barcode patterns* that
|
||||
Odoo supports for the default nomenclature.
|
||||
|
||||
The :ref:`default nomenclature list <barcode/operations/default-nomenclature-list>` contains all the
|
||||
information that can be condensed with a |UPC|/|EAN| barcode.
|
||||
|
||||
.. _barcode/operations/use-upc-ean-barcodes:
|
||||
|
||||
Use UPC/EAN barcodes in Odoo
|
||||
============================
|
||||
|
||||
For product identification using |UPC|/|EAN| barcodes in Odoo, businesses **must** obtain `barcodes
|
||||
<https://www.gs1us.org/upcs-barcodes-prefixes/how-to-get-a-upc-barcode>`_ purchased directly from
|
||||
GS1.
|
||||
|
||||
The |UPC| and |EAN| barcode formats are predominantly used in their own regions. |UPC| is used only
|
||||
in the United States and Canada, while |EAN| is used everywhere else globally.
|
||||
|
||||
A |UPC| is usually a 12-digit barcode used to identify most products, while |EAN| barcodes use
|
||||
13-digit barcodes to identify products.
|
||||
|
||||
|UPC| codes can be converted to |EAN| by prefixing them with a zero. In Odoo, by default,
|
||||
|UPC|/|EAN| barcodes are automatically converted one way or another when trying to match a rule with
|
||||
the other encoding.
|
||||
|
||||
Refer to the :ref:`default nomenclature list <barcode/operations/default-nomenclature-list>` to see
|
||||
a comprehensive list of all barcode patterns and rules to follow.
|
||||
|
||||
Create rules
|
||||
------------
|
||||
|
||||
|UPC| and |EAN| barcodes contain specific information in the barcode. Scanning these codes from the
|
||||
:ref:`default nomenclature list <barcode/operations/default-nomenclature-list>` automatically fills
|
||||
corresponding data in the Odoo database.
|
||||
|
||||
Adding new barcode rules to this list ensures that non-standard (:dfn:`user-created`) formats are
|
||||
interpreted accurately.
|
||||
|
||||
To create new rules, first activate :ref:`developer mode <developer-mode>`. Then, navigate to
|
||||
:menuselection:`Inventory app --> Configuration --> Barcode Nomenclatures`. Select the
|
||||
:guilabel:`Default Nomenclature` list item.
|
||||
|
||||
On the :guilabel:`Default Nomenclature` page, select :guilabel:`Add a line` at the bottom of the
|
||||
On the :guilabel:`Default Nomenclature` page, click :guilabel:`Add a line` at the bottom of the
|
||||
table, which opens a :guilabel:`Create Rules` pop-up window to create a new rule.
|
||||
|
||||
.. image:: barcode_nomenclature/barcode-nomenclature-new-rule-popup.png
|
||||
:align: center
|
||||
:alt: Create Rules pop-up window on Default Nomenclature page.
|
||||
|
||||
The :guilabel:`Rule Name` field is used internally to identify what the barcode represents.
|
||||
|
||||
The :guilabel:`Sequence` field represents the priority of the rule; meaning the smaller the value,
|
||||
@@ -126,31 +154,23 @@ The barcode :guilabel:`Type` field represents different classifications of infor
|
||||
understood by the system (e.g., :guilabel:`Package`, :guilabel:`Lot`, :guilabel:`Location`,
|
||||
:guilabel:`Coupon`, etc.).
|
||||
|
||||
The :guilabel:`Encoding` field specifies which encoding the barcode uses; this rule **only** applies
|
||||
The :guilabel:`Encoding` field specifies which encoding the barcode uses. This rule **only** applies
|
||||
if the barcode uses this specific encoding. The available :guilabel:`Encoding` options are:
|
||||
:guilabel:`EAN-13`, :guilabel:`EAN-8`, :guilabel:`UPC-A`, and :guilabel:`GS1-28`.
|
||||
|
||||
The :guilabel:`Barcode Pattern` field represents how the sequence of letters or numbers is
|
||||
recognized by the system to contain information about the product. Odoo follows the sequential order
|
||||
of this table, and uses the first rule it matches, based on the sequence.
|
||||
recognized by the system to contain information about the product. Sometimes, when a certain amount
|
||||
of digits are required, the number of `.` is shown. `N` represents whole number digits, and `D`
|
||||
represent decimal digits.
|
||||
|
||||
.. note::
|
||||
Barcode patterns can also define how numerical values, such as weight or price, are encoded in
|
||||
the barcode.
|
||||
|
||||
They are indicated by **{NNN}**, where `N` defines where the number's digits are encoded.
|
||||
*Floats* are also supported with the decimals, indicated by `D`, such as **{NNNDD}**.
|
||||
|
||||
In this case, the barcode field on the associated records **must** show these digits as zeros.
|
||||
.. example::
|
||||
`1...` represents any 4-digit number that starts with 1. `NNDD` represents a two digit number
|
||||
with two decimal points. For example, `14.25` is 1425.
|
||||
|
||||
After filling in the information, click the :guilabel:`Save & New` button to save the rule, and
|
||||
instantly start creating another rule. Or, click :guilabel:`Save & Close` to save the rule, and
|
||||
return to the table of rules.
|
||||
|
||||
.. tip::
|
||||
When the :guilabel:`Barcode Pattern` field contains `.*`, it means it can contain **any** number
|
||||
of characters - those characters being **any** number or type of character.
|
||||
|
||||
.. _barcode/operations/default-nomenclature-list:
|
||||
|
||||
Default nomenclature list
|
||||
@@ -212,5 +232,9 @@ written in regular expressions.
|
||||
- Any
|
||||
- .*
|
||||
|
||||
.. note::
|
||||
When the :guilabel:`Barcode Pattern` contains `.*`, it means it can contain any number or type of
|
||||
characters.
|
||||
|
||||
.. seealso::
|
||||
:doc:`gs1_nomenclature`
|
||||
|
||||
|
After Width: | Height: | Size: 9.5 KiB |
|
After Width: | Height: | Size: 43 KiB |
|
After Width: | Height: | Size: 6.5 KiB |
|
After Width: | Height: | Size: 60 KiB |
|
After Width: | Height: | Size: 5.6 KiB |
@@ -97,8 +97,8 @@ Install Sendcloud shipping module
|
||||
---------------------------------
|
||||
|
||||
After the Sendcloud account is set up and configured, it's time to configure the Odoo database. To
|
||||
get started, go to Odoo's :guilabel:`Apps` module, search for the `Sendcloud Shipping`
|
||||
integration, and install it.
|
||||
get started, go to Odoo's :guilabel:`Apps` module, search for the `Sendcloud Shipping` integration,
|
||||
and install it.
|
||||
|
||||
.. image:: sendcloud_shipping/sendcloud-mod.png
|
||||
:align: center
|
||||
@@ -214,9 +214,40 @@ chatter, which include the following:
|
||||
Additionally, the tracking number is now available.
|
||||
|
||||
.. important::
|
||||
When return labels are created, Sendcloud will automatically charge the configured Sendcloud
|
||||
When return labels are created, Sendcloud automatically charges the configured Sendcloud
|
||||
account.
|
||||
|
||||
Shipping rules
|
||||
--------------
|
||||
|
||||
Optionally, create shipping rules to automatically generate shipping labels tailored to different
|
||||
product needs. For example, a shipping rule can be created for customers shipping expensive jewelry
|
||||
items to purchase insurance.
|
||||
|
||||
To use shipping rules, navigate to :menuselection:`Inventory app --> Configuration --> Delivery:
|
||||
Shipping Methods`, and select the intended `Sendcloud` shipping method.
|
||||
|
||||
Under the :guilabel:`Sendcloud Configuration` tab, in the :guilabel:`OPTIONS` section, choose the
|
||||
kind of shipments the shipping rules apply to, via the :guilabel:`Use Sendcloud shipping rules`
|
||||
field.
|
||||
|
||||
From here, choose either: :guilabel:`Shipping` to customers, :guilabel:`Returns` from customers, or
|
||||
:guilabel:`Both`.
|
||||
|
||||
.. image:: sendcloud_shipping/enable-shipping-rules.png
|
||||
:align: center
|
||||
:alt: Use Shipping Rules field.
|
||||
|
||||
Then, in the Sendcloud website, navigate to :menuselection:`Settings --> Shipping rules`. Create a
|
||||
new shipping rule by clicking :guilabel:`Create New`.
|
||||
|
||||
In the :guilabel:`Actions` section, set a :guilabel:`Condition` to determine when the rule applies.
|
||||
Then, configure what to do when packages meet the condition.
|
||||
|
||||
.. seealso::
|
||||
`Create shipping rules on Sendcloud
|
||||
<https://support.sendcloud.com/hc/en-us/articles/10274470454292-How-to-create-shipping-rules#examples-smart-shipping-rules>`_
|
||||
|
||||
FAQ
|
||||
===
|
||||
|
||||
|
||||
|
After Width: | Height: | Size: 5.9 KiB |
@@ -13,4 +13,5 @@ Advanced operations
|
||||
advanced_operations_warehouse/cross_dock
|
||||
advanced_operations_warehouse/stock_warehouses
|
||||
advanced_operations_warehouse/putaway
|
||||
advanced_operations_warehouse/storage_category
|
||||
advanced_operations_warehouse/cluster_picking
|
||||
|
||||
@@ -93,83 +93,3 @@ match is found:
|
||||
:align: center
|
||||
:alt: Some examples of putaway rules.
|
||||
|
||||
Storage categories
|
||||
==================
|
||||
|
||||
A *storage category* is an extra location attribute. Storage categories allow the user to define
|
||||
the quantity of products that can be stored in the location, and how the location will be selected
|
||||
with putaway rules.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
To enable storage categories, go to :menuselection:`Inventory app --> Configuration --> Settings`,
|
||||
and activate the :guilabel:`Storage Categories` feature in the :guilabel:`Warehouse` section. Then,
|
||||
click :guilabel:`Save`.
|
||||
|
||||
.. important::
|
||||
The :guilabel:`Storage Locations` feature **must** be enabled to enable :guilabel:`Storage
|
||||
Categories`.
|
||||
|
||||
Define storage category
|
||||
-----------------------
|
||||
|
||||
To create a storage category, go to :menuselection:`Inventory app --> Configuration --> Storage
|
||||
Categories` and click :guilabel:`Create`.
|
||||
|
||||
On the storage category form, type a name for the :guilabel:`Storage Category` field.
|
||||
|
||||
Options are available to limit the capacity by weight, by product, or by package type. The
|
||||
:guilabel:`Allow New Product` field defines when the location is considered available to store a
|
||||
product:
|
||||
|
||||
- :guilabel:`If location is empty`: a product can be added there only if the location is empty.
|
||||
- :guilabel:`If products are the same`: a product can be added there only if the same product is
|
||||
already there.
|
||||
- :guilabel:`Allow mixed products`: several different products can be stored in this location at
|
||||
the same time.
|
||||
|
||||
.. example::
|
||||
Create putaway rules for pallet-stored items and ensure real-time storage capacity checks by
|
||||
creating the `High Frequency pallets` storage category.
|
||||
|
||||
Name the :guilabel:`Storage Category`, and select :guilabel:`If all products are same` in the
|
||||
:guilabel:`Allow New Product` field.
|
||||
|
||||
Then, define package capacity in the :guilabel:`Capacity by Package` tab, specifying the number
|
||||
of packages for the designated :guilabel:`Package Type` and setting a maximum of `2.00` `Pallets`
|
||||
for a specific location.
|
||||
|
||||
.. image:: putaway/storage-category.png
|
||||
:align: center
|
||||
:alt: Create a storage category on the page.
|
||||
|
||||
Once the storage category settings are saved, the storage category can be linked to a location.
|
||||
|
||||
To do that, navigate to the location by going to :menuselection:`Inventory app --> Configuration -->
|
||||
Locations`, and select the location. Click :guilabel:`Edit` and select the created category in the
|
||||
:guilabel:`Storage Category` field.
|
||||
|
||||
.. example::
|
||||
Assign the `High Frequency pallets` storage category to the `WH/Stock/pallets/PAL 1`
|
||||
sub-location.
|
||||
|
||||
.. image:: putaway/location-storage-category.png
|
||||
:align: center
|
||||
:alt: When a Storage Category is created, it can be linked to a warehouse location.
|
||||
|
||||
Storage categories in putaway rules
|
||||
-----------------------------------
|
||||
|
||||
To continue the example from above, apply the `High Frequency Pallets` on the `PAL1` and `PAL2`
|
||||
locations and :ref:`rework the putaway rules <inventory/routes/putaway-rule>` as follows:
|
||||
|
||||
Assume one pallet of lemonade cans is received:
|
||||
|
||||
- If PAL1 and PAL2 are empty, the pallet will be redirected to WH/Stock/Pallets/PAL1.
|
||||
- If PAL1 is full, the pallet will be redirected to WH/Stock/Pallets/PAL2.
|
||||
- If PAL1 and 2 are full, the pallet will be redirected to WH/Stock/Pallets.
|
||||
|
||||
.. image:: putaway/smart-putaways.png
|
||||
:align: center
|
||||
:alt: Storage Categories used in a variety of putaway rules.
|
||||
|
||||
@@ -73,7 +73,7 @@ steps below to finish configuring the virtual parent warehouse.
|
||||
:alt: New warehouse form.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`Warehouse configurations <../inventory_management/warehouses_locations>`
|
||||
- :doc:`Warehouse configurations <../inventory_management/warehouses>`
|
||||
- :ref:`Incoming and outgoing shipments <inventory/receipts_delivery_one_step/wh>`
|
||||
- :doc:`Resupply from another warehouse <../inventory_management/resupply_warehouses>`
|
||||
|
||||
|
||||
@@ -0,0 +1,177 @@
|
||||
==================
|
||||
Storage categories
|
||||
==================
|
||||
|
||||
A *storage category* is used with :doc:`putaway rules <putaway>`, as an extra location attribute to
|
||||
automatically propose optimal storage locations for products.
|
||||
|
||||
Follow these steps to complete the setup:
|
||||
|
||||
#. :ref:`Enable the Storage Category feature <inventory/routes/enable-storage-categories>`
|
||||
#. :ref:`Define a storage category <inventory/routes/define-storage>` with specific limitations
|
||||
#. Assign a :ref:`category to storage locations <inventory/routes/assign-location>`
|
||||
#. Add the storage category as an attribute to a :ref:`putaway rule
|
||||
<inventory/routes/set-putaway-attribute>`
|
||||
|
||||
.. seealso::
|
||||
:doc:`putaway`
|
||||
|
||||
.. note::
|
||||
Assigning categories to storage locations tells Odoo these locations meet specific
|
||||
requirements, such as temperature or accessibility. Odoo then evaluates these locations, based on
|
||||
defined capacity, and recommends the best one on the warehouse transfer form.
|
||||
.. _inventory/routes/enable-storage-categories:
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
To enable storage categories, go to :menuselection:`Inventory app --> Configuration --> Settings`.
|
||||
Then, in the :guilabel:`Warehouse` section, ensure the :guilabel:`Storage Locations` and
|
||||
:guilabel:`Multi-Step Routes` features are enabled.
|
||||
|
||||
Next, activate the :guilabel:`Storage Categories` feature. Finally, click :guilabel:`Save`.
|
||||
|
||||
.. image:: storage_category/enable-categories.png
|
||||
:align: center
|
||||
:alt: Show the Storage Categories feature.
|
||||
|
||||
.. _inventory/routes/define-storage:
|
||||
|
||||
Define storage category
|
||||
=======================
|
||||
|
||||
A storage category with specific limitations **must** be created first, before it is applied to
|
||||
locations, in order to decide the optimal storage location.
|
||||
|
||||
To create a storage category, go to :menuselection:`Inventory app --> Configuration --> Storage
|
||||
Categories`, and click :guilabel:`Create`.
|
||||
|
||||
On the storage category form, type a name for the category in the :guilabel:`Storage Category`
|
||||
field.
|
||||
|
||||
Options are available to limit capacity by weight, product, and package type.
|
||||
|
||||
.. note::
|
||||
Weight limits can be combined with capacity by package or product (e.g. a maximum of one hundred
|
||||
products with a total weight of two hundred kilograms).
|
||||
|
||||
While it is possible to limit capacity by product and package type at the same location, it may
|
||||
be more practical to store items in different amounts across various locations, as shown in this
|
||||
example of :ref:`capacity by package <inventory/routes/set-capacity-package>`.
|
||||
|
||||
The :guilabel:`Allow New Product` field defines when the location is considered available to store a
|
||||
product:
|
||||
|
||||
- :guilabel:`If location is empty`: a product can be added there only if the location is empty.
|
||||
- :guilabel:`If products are the same`: a product can be added there only if the same product is
|
||||
already there.
|
||||
- :guilabel:`Allow mixed products`: several different products can be stored in this location at
|
||||
the same time.
|
||||
|
||||
.. tip::
|
||||
When clicked, the :guilabel:`Location` smart button shows which storage locations the category
|
||||
has been assigned to.
|
||||
|
||||
Capacity by weight
|
||||
------------------
|
||||
|
||||
On a storage category form (:menuselection:`Inventory app --> Configuration --> Storage
|
||||
Categories`), set a maximum product weight in the :guilabel:`Max Weight` field. This limit applies
|
||||
to each location assigned this storage category.
|
||||
|
||||
Capacity by product
|
||||
-------------------
|
||||
|
||||
In the :guilabel:`Capacity by Product` tab, click :guilabel:`Add a Line` to input items, and enter
|
||||
their capacities in the :guilabel:`Quantity` field.
|
||||
|
||||
.. example::
|
||||
Ensure only a maximum of five `Large Cabinets` and two `Corner Desk Right Sit` are stored at a
|
||||
single storage location, by specifying those amounts in the :guilabel:`Capacity by Product` tab
|
||||
of a storage category form.
|
||||
|
||||
.. image:: storage_category/capacity-by-product.png
|
||||
:align: center
|
||||
:alt: Show storage category limiting by product count.
|
||||
|
||||
.. _inventory/routes/set-capacity-package:
|
||||
|
||||
Capacity by package
|
||||
-------------------
|
||||
|
||||
For companies using :doc:`packages <../../product_management/product_tracking/package>`, it becomes
|
||||
possible to ensure real-time storage capacity checks, based on package types (e.g., crates, bins,
|
||||
boxes, etc.).
|
||||
|
||||
.. important::
|
||||
Enable the :guilabel:`Packages` feature in :menuselection:`Inventory app --> Configuration -->
|
||||
Settings` to show the :guilabel:`Capacity by Package` tab.
|
||||
|
||||
.. example::
|
||||
Create putaway rules for pallet-stored items, by creating the `High Frequency pallets` storage
|
||||
category.
|
||||
|
||||
In the :guilabel:`Capacity by Package` tab, specify the number of packages for the designated
|
||||
:guilabel:`Package Type`, and set a maximum of `2.00` `Pallets` for a specific location.
|
||||
|
||||
.. image:: storage_category/storage-category.png
|
||||
:align: center
|
||||
:alt: Create a storage category on the page.
|
||||
|
||||
.. _inventory/routes/assign-location:
|
||||
|
||||
Assign to location
|
||||
==================
|
||||
|
||||
Once the storage category is created, assign it to a location. Navigate to the location by going to
|
||||
:menuselection:`Inventory app --> Configuration --> Locations`, and select the desired location.
|
||||
Then, select the created category in the :guilabel:`Storage Category` field.
|
||||
|
||||
.. example::
|
||||
Assign the `High Frequency pallets` storage category (which limits pallets stored at any location
|
||||
to two pallets) to the `WH/Stock/pallets/PAL 1` sub-location.
|
||||
|
||||
.. image:: storage_category/location-storage-category.png
|
||||
:align: center
|
||||
:alt: When a Storage Category is created, it can be linked to a warehouse location.
|
||||
|
||||
.. _inventory/routes/set-putaway-attribute:
|
||||
|
||||
Putaway rule
|
||||
============
|
||||
|
||||
With the :ref:`storage category <inventory/routes/define-storage>` and :ref:`location
|
||||
<inventory/routes/assign-location>` set up, create the :doc:`putaway rule <putaway>` by navigating
|
||||
to :menuselection:`Inventory app --> Configuration --> Putaway Rules`.
|
||||
|
||||
Click the :guilabel:`Create` button to create the putaway rule. In the :guilabel:`Having Category`
|
||||
field of the new putaway rule form, select the storage category.
|
||||
|
||||
.. example::
|
||||
Continuing the example from above, the `High Frequency Pallets` storage category is assigned to
|
||||
the putaway rule directing pallets of lemonade to locations with the `High Frequency Pallets`
|
||||
storage category :ref:`assigned to them <inventory/routes/assign-location>`.
|
||||
|
||||
.. image:: storage_category/smart-putaways.png
|
||||
:align: center
|
||||
:alt: Storage Categories used in a variety of putaway rules.
|
||||
|
||||
Use case: limit capacity by package
|
||||
===================================
|
||||
|
||||
To limit the capacity of a storage location by a specific number of packages, :ref:`create a storage
|
||||
category with a Capacity By Package <inventory/routes/set-capacity-package>`.
|
||||
|
||||
Continuing the example from above, the `High Frequency Pallets` storage category is assigned to the
|
||||
`PAL1` and `PAL2` locations.
|
||||
|
||||
Then, :ref:`putaway rules <inventory/routes/putaway-rule>` are set, so that any pallets received in
|
||||
the warehouse are directed to be stored in `PAL1` and `PAL2` locations.
|
||||
|
||||
Depending on the number of pallets on-hand at each of the storage locations, when one pallet of
|
||||
lemonade cans is received, the following scenarios happen:
|
||||
|
||||
- If `PAL1` and `PAL2` are empty, the pallet is redirected to `WH/Stock/Pallets/PAL1`.
|
||||
- If `PAL1` is full, the pallet is redirected to `WH/Stock/Pallets/PAL2`.
|
||||
- If `PAL1` and `PAL2` are full, the pallet is redirected to `WH/Stock/Pallets`.
|
||||
|
||||
|
After Width: | Height: | Size: 9.6 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 8.6 KiB |
|
After Width: | Height: | Size: 8.4 KiB |
|
After Width: | Height: | Size: 11 KiB |
@@ -1,18 +1,144 @@
|
||||
:nosearch:
|
||||
:show-content:
|
||||
:hide-page-toc:
|
||||
|
||||
====================
|
||||
Inventory management
|
||||
====================
|
||||
|
||||
In the Odoo *Inventory* app, :doc:`warehouses <inventory_management/warehouses>` handle the broader
|
||||
organization and distribution of stock across different physical sites, while :doc:`locations
|
||||
<inventory_management/use_locations>` provide a more detailed breakdown within each warehouse for
|
||||
efficient item management.
|
||||
|
||||
This document serves as an introduction to the terminology and concepts necessary to master
|
||||
*Inventory*. For specific instructions and examples of how things work, refer to individual
|
||||
documentation pages.
|
||||
|
||||
.. seealso::
|
||||
`Odoo Tutorials: Warehouses & Locations <https://www.youtube.com/watch?v=zMvudZVLuUo>`_
|
||||
|
||||
Warehouses
|
||||
==========
|
||||
|
||||
:doc:`Warehouses <inventory_management/warehouses>` represent a physical place, with a physical
|
||||
address, where a company's items are stored.
|
||||
|
||||
Configure :doc:`routes <inventory_management/use_routes>` in a warehouse to control how products
|
||||
move to customers, from vendors, within the warehouse, or :doc:`between warehouses
|
||||
<inventory_management/resupply_warehouses>`.
|
||||
|
||||
Locations
|
||||
=========
|
||||
|
||||
:doc:`Locations <inventory_management/use_locations>` refer to specific areas within a warehouse,
|
||||
such as shelves, floors, or aisles. These are sub-divisions within a warehouse, and are unique to
|
||||
that warehouse. Users can create and manage numerous locations within a single warehouse to organize
|
||||
inventory more precisely.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`inventory_management/use_locations`
|
||||
- :doc:`inventory_management/count_products`
|
||||
- :doc:`inventory_management/cycle_counts`
|
||||
- :doc:`inventory_management/scrap_inventory`
|
||||
|
||||
.. _inventory/warehouses_storage/location-type:
|
||||
|
||||
Location types
|
||||
--------------
|
||||
|
||||
*Location types* in Odoo help categorize and manage where products are, and what actions need to be
|
||||
taken with them. By default, on the :menuselection:`Inventory app --> Configuration --> Locations`
|
||||
page, only internal locations are displayed.
|
||||
|
||||
To view the seven location types in Odoo, select any location, and in the :guilabel:`Location Type`
|
||||
field, there are:
|
||||
|
||||
- :guilabel:`Vendor Location`: defines an area where products purchased from vendors originate.
|
||||
Items here are **not** in stock.
|
||||
|
||||
- :guilabel:`View`: used to organize and structure the warehouse hierarchy. For example, the view
|
||||
location `WH` (short for warehouse) groups all internal locations, such as `Stock`, receiving
|
||||
docks, quality checkpoints, and packing areas to show they all belong to the same warehouse.
|
||||
|
||||
.. important::
|
||||
View locations should **not** contain products, but it is possible to move them there.
|
||||
|
||||
- :guilabel:`Internal Location`: storage locations within the warehouse. Items stored in these
|
||||
locations are accounted for in :doc:`inventory valuation
|
||||
<inventory_valuation/using_inventory_valuation>`.
|
||||
|
||||
- :guilabel:`Customer Location`: where sold products are tracked; items here are no longer in stock.
|
||||
|
||||
- :guilabel:`Inventory Loss`: counterpart location to consume missing items or create stock,
|
||||
accounting for discrepancies.
|
||||
|
||||
In Odoo, examples of inventory loss locations are *Inventory Adjustment*, used to account for
|
||||
discrepancies during an inventory count, and *Scrap*, which is where damaged goods are sent to
|
||||
account for inventory losses.
|
||||
|
||||
.. example::
|
||||
`Virtual Locations/Inventory Adjustment` is a location with the :guilabel:`Inventory Loss`
|
||||
type. The database shows `65` units in `WH/Stock`, but an inventory check reveals `60`. To
|
||||
correct the quantity, five units are moved from `WH/Stock` to `Virtual Locations/Inventory
|
||||
Adjustment`.
|
||||
|
||||
.. image:: inventory_management/inventory_management/inventory-loss.png
|
||||
:align: center
|
||||
:alt: Product ends up in Virtual Locations/Inventory Adjustment.
|
||||
|
||||
- :guilabel:`Production`: where raw materials are consumed, and :doc:`manufactured products
|
||||
<../../manufacturing>` are created.
|
||||
|
||||
- :guilabel:`Transit Location`: used for inter-company or inter-warehouse operations to track
|
||||
products shipped between different addresses, such as :ref:`Physical Locations/Inter-warehouse
|
||||
transit <inventory/warehouses_storage/interwarehouse-transit>`.
|
||||
|
||||
.. image:: inventory_management/inventory_management/locations.png
|
||||
:align: center
|
||||
:alt: List of locations in Odoo.
|
||||
|
||||
.. note::
|
||||
In Odoo, location types are color-coded:
|
||||
- **Red**: internal locations
|
||||
- **Blue**: view locations
|
||||
- **Black**: external locations (including inventory loss, vendor, and customer locations).
|
||||
|
||||
View locations in Odoo
|
||||
----------------------
|
||||
|
||||
Odoo databases include pre-configured view locations to organize the hierarchy of locations. These
|
||||
provide helpful context, and distinguish between internal and external locations.
|
||||
|
||||
- *Physical locations* serve as an umbrella for external locations, without changing a product's
|
||||
inventory value. (Inventory valuation changes occur when products move from internal to external
|
||||
locations).
|
||||
|
||||
.. _inventory/warehouses_storage/interwarehouse-transit:
|
||||
|
||||
.. example::
|
||||
When moving products in warehouses `WH` and `WH2`, the items are not in either warehouse, but
|
||||
still belong to the company. While in transit, they are placed in the `Inter-warehouse transit`
|
||||
location, a :guilabel:`Transit Location` type.
|
||||
|
||||
This location is under the view location, `Physical Locations`, indicating that
|
||||
`Inter-warehouse transit` is outside of a warehouse, but still part of the company. Doing so
|
||||
does not affect the inventory valuation of the products.
|
||||
|
||||
- *Partner locations* group customer and vendor locations (external locations) together. Transfers
|
||||
to these locations affect inventory valuation.
|
||||
- *Virtual locations* are locations that do **not** exist physically, but it is where items that are
|
||||
not in inventory can be placed. These can be items that are no longer in inventory due to loss, or
|
||||
other factors.
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
inventory_management/resupply_warehouses
|
||||
inventory_management/warehouse_replenishment_transfer
|
||||
inventory_management/warehouses_locations
|
||||
inventory_management/create_a_second_warehouse
|
||||
inventory_management/use_routes
|
||||
inventory_management/warehouses
|
||||
inventory_management/use_locations
|
||||
inventory_management/count_products
|
||||
inventory_management/cycle_counts
|
||||
inventory_management/scrap_inventory
|
||||
inventory_management/resupply_warehouses
|
||||
inventory_management/warehouse_replenishment_transfer
|
||||
inventory_management/use_routes
|
||||
|
||||
|
||||
@@ -1,139 +0,0 @@
|
||||
=========================
|
||||
Create a second warehouse
|
||||
=========================
|
||||
|
||||
In Odoo *Inventory*, a *warehouse* is a physical building or space where items are stored. By
|
||||
default, each Odoo database has one warehouse already pre-configured, with the address set as the
|
||||
company's address.
|
||||
|
||||
However, it is possible to set up multiple additional warehouses, and transfer stored items between
|
||||
them.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
To create a second warehouse, the *Storage Locations* feature must be enabled. To enable this
|
||||
feature, navigate to :menuselection:`Inventory app --> Configuration --> Settings`. Under the
|
||||
:guilabel:`Warehouse` section, tick the checkbox next to :guilabel:`Storage Locations`, and
|
||||
:guilabel:`Save` changes.
|
||||
|
||||
.. image:: create_a_second_warehouse/create-a-second-warehouse-enabled-setting.png
|
||||
:align: center
|
||||
:alt: Warning pop-up window for creating a second warehouse before enabling Storage Locations.
|
||||
|
||||
.. note::
|
||||
Creating a second warehouse without first enabling the *Storage Locations* feature triggers a
|
||||
:guilabel:`Warning` pop-up window. It indicates creating a second warehouse automatically
|
||||
activates the *Storage Locations* setting.
|
||||
|
||||
Create new warehouse
|
||||
====================
|
||||
|
||||
To create a new warehouse, navigate to :menuselection:`Inventory app --> Configuration -->
|
||||
Warehouses`, and click :guilabel:`New`. Doing so opens a blank warehouse creation form.
|
||||
|
||||
Fill out the following fields as necessary:
|
||||
|
||||
- :guilabel:`Warehouse`: the full name of the warehouse.
|
||||
- :guilabel:`Short Name`: the abbreviated code used to identify the warehouse, i.e. `WH2` (the short
|
||||
name for the default warehouse in Odoo is `WH`).
|
||||
- :guilabel:`Company`: the company that owns the warehouse. This can be set as the company that owns
|
||||
the Odoo database or the company of a customer or vendor.
|
||||
- :guilabel:`Address`: the address where the warehouse is located. By default, this is set to the
|
||||
company's address in the database.
|
||||
|
||||
.. image:: create_a_second_warehouse/create-a-second-warehouse-new-warehouse-settings.png
|
||||
:align: center
|
||||
:alt: Filled out warehouse name and address settings on warehouse creation form.
|
||||
|
||||
Under the :guilabel:`Warehouse Configuration` tab, configure the warehouse's main workflow in the
|
||||
:guilabel:`Shipments` section, and set available replenishment methods in the :guilabel:`Resupply`
|
||||
section.
|
||||
|
||||
.. important::
|
||||
The :guilabel:`Shipments` and :guilabel:`Resupply` sections only appear if the
|
||||
:guilabel:`Multi-Step Routes` checkbox is enabled in :menuselection:`Inventory app -->
|
||||
Configuration --> Settings`, under the :guilabel:`Warehouse` heading. For more information about
|
||||
routes and how they work in Odoo, see :ref:`Using Routes and Pull/Push Rules <use-routes>`.
|
||||
|
||||
In the :guilabel:`Shipments` section, choose between one, two, or three-step processes for both
|
||||
incoming and outgoing shipments.
|
||||
|
||||
In the :guilabel:`Resupply` section, edit the following settings:
|
||||
|
||||
- :guilabel:`Dropship Subcontractors`: enable this feature to coordinate with vendors, and have
|
||||
components dropshipped directly to subcontractors for manufacturing.
|
||||
- :guilabel:`Resupply Subcontractors`: allow subcontractors to be resupplied with goods from this
|
||||
warehouse.
|
||||
- :guilabel:`Manufacture to Resupply`: when products are manufactured, they can be delivered to this
|
||||
warehouse.
|
||||
- :guilabel:`Manufacture`: the route that should be followed when manufacturing goods inside the
|
||||
warehouse. Choose from one, two, and three-step production.
|
||||
- :guilabel:`Buy to Resupply`: when products are purchased, they can be delivered to this warehouse.
|
||||
- :guilabel:`Resupply From`: Check the box next to the other warehouses from which this warehouse
|
||||
can replenish products. If the current warehouse does not have the stock, it can also pull
|
||||
products from these selected warehouses in the database. Automatic resupply routes will be created
|
||||
accordingly.
|
||||
|
||||
.. image:: create_a_second_warehouse/create-a-second-warehouse-warehouse-configuration-tab.png
|
||||
:align: center
|
||||
:alt: Filled out Warehouse Configuration tab settings on warehouse creation form.
|
||||
|
||||
Once ready, click :guilabel:`Save` to save the new warehouse's settings.
|
||||
|
||||
Add inventory to a new warehouse
|
||||
================================
|
||||
|
||||
If a new warehouse is created to represent a real-world storage location with existing stock, update
|
||||
the warehouse's stock using an inventory adjustment.
|
||||
|
||||
.. seealso::
|
||||
:doc:`count_products`
|
||||
|
||||
To perform an inventory adjustment, navigate to :menuselection:`Inventory app --> Operations -->
|
||||
Physical Inventory`, and click :guilabel:`New`. Doing so adds a new line at the bottom of the list
|
||||
of inventory adjustments.
|
||||
|
||||
Configure the line by filling out the following fields as necessary:
|
||||
|
||||
- :guilabel:`Location`: the location where the product is currently stored in the new warehouse.
|
||||
This can be set as the overall warehouse, or a location within the warehouse.
|
||||
- :guilabel:`Product`: the product being added to inventory.
|
||||
- :guilabel:`Lot/Serial Number`: the lot that the product belongs to or the serial number used to
|
||||
identify it, if the product is tracked.
|
||||
- :guilabel:`On Hand Quantity`: the total quantity of the product stored in the location for which
|
||||
inventory is being adjusted. For a new warehouse or location where a count or a prior inventory
|
||||
adjustment has not taken place, this should be set to `0.00`.
|
||||
- :guilabel:`UoM`: the unit of measure (UoM) used for counting the product.
|
||||
- :guilabel:`Counted Quantity`: the amount of the product being added to inventory.
|
||||
- :guilabel:`Difference`: the difference between the on-hand and counted quantities. This
|
||||
automatically updates to reflect the value entered in the :guilabel:`Counted Quantity` column.
|
||||
- :guilabel:`Scheduled Date`: the date selected for the next inventory count for this product.
|
||||
- :guilabel:`User`: the user who recorded the inventory adjustment in the database.
|
||||
|
||||
.. image:: create_a_second_warehouse/create-a-second-warehouse-inventory-adjustment.png
|
||||
:align: center
|
||||
:alt: Filled out inventory adjustment line for product in new warehouse.
|
||||
|
||||
Once each line for the products being added to the new warehouse is configured, click
|
||||
:guilabel:`Apply` on each line to apply the new inventory counts.
|
||||
|
||||
The values in the :guilabel:`On Hand Quantity` column update to reflect those in the
|
||||
:guilabel:`Counted Quantity` column, and the products added appear in the new warehouse's stock.
|
||||
|
||||
.. note::
|
||||
If products tracked using a lot number or serial number are added without specifying the tracking
|
||||
number, a :guilabel:`Tracked Products in Inventory Adjustment` pop-up window appears upon
|
||||
clicking :guilabel:`Apply` on that product's line.
|
||||
|
||||
The pop-up indicates tracked products were added, but the lots/serial numbers were not defined.
|
||||
To apply the adjustment without the numbers, click :guilabel:`Apply`. To add the numbers before
|
||||
applying, click :guilabel:`Discard`, and add the numbers. Then, once ready, click
|
||||
:guilabel:`Apply` again.
|
||||
|
||||
.. image:: create_a_second_warehouse/create-a-second-warehouse-popup-window.png
|
||||
:align: center
|
||||
:alt: Tracked Products in Inventory Adjustment pop-up window.
|
||||
|
||||
.. seealso::
|
||||
:doc:`warehouses_locations`
|
||||
|
Before Width: | Height: | Size: 31 KiB |
|
Before Width: | Height: | Size: 68 KiB |
|
Before Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 36 KiB |
|
Before Width: | Height: | Size: 51 KiB |
|
After Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 90 KiB |