Compare commits
52 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| b0f322ffd6 | |||
| 00d78c39e4 | |||
| 74c00734f0 | |||
| 1a4e3d6163 | |||
| b9cdeb304a | |||
| 18be17dada | |||
| 682a290793 | |||
| 649b6bcd5c | |||
| 9d4fc6cd55 | |||
| fb1f81f735 | |||
| 50d0d32bf6 | |||
| f84c00cb0d | |||
| 70701aa589 | |||
| 85cb4170af | |||
| a8292df22f | |||
| 8ab0935d74 | |||
| 9486fece94 | |||
| cd31079f69 | |||
| 2935c3b2df | |||
| b00ae1f3b0 | |||
| 0f87ffef1a | |||
| 23e773f31e | |||
| a1371aee87 | |||
| f2f9b32a1d | |||
| ad06489c98 | |||
| 86fa534deb | |||
| 3667e71c92 | |||
| 599e50159e | |||
| cc7857b363 | |||
| 4b3fecf2cb | |||
| 1f788bf750 | |||
| 0edc606b42 | |||
| 8377f9f068 | |||
| b81c06ecef | |||
| 36de103e3a | |||
| 3d920ded85 | |||
| 2b6fa74e40 | |||
| 7674dbdbbc | |||
| a76635c09c | |||
| d4565c6c20 | |||
| 81b1a9fd8e | |||
| d91cead9e7 | |||
| 4827f3fe20 | |||
| 4a24238376 | |||
| e6d68071fc | |||
| bce2a875c5 | |||
| b738a4e002 | |||
| 3da71625f1 | |||
| 833109636a | |||
| 044670f15e | |||
| 1bb11f0654 | |||
| 63789b0aa7 |
@@ -41,9 +41,8 @@ current_major_version = current_major_branch.replace('.0', '')
|
||||
# The minimal Sphinx version required to build the documentation.
|
||||
needs_sphinx = '3.0.0'
|
||||
|
||||
# The default language in which the documentation is written. It is set to `None` because Sphinx
|
||||
# considers that no language means 'en'.
|
||||
language = None
|
||||
# The default language in which the documentation is written.
|
||||
language = 'en'
|
||||
|
||||
# The suffix of source filenames.
|
||||
source_suffix = '.rst'
|
||||
@@ -65,6 +64,8 @@ exclude_patterns = [
|
||||
# See https://docutils.sourceforge.io/docs/ref/rst/roles.html#standard-roles for other roles.
|
||||
default_role = 'literal'
|
||||
|
||||
# Global config to lazy load images by default
|
||||
image_loading = 'lazy'
|
||||
|
||||
# Whether scaled down images should be be wrapped in a `<a/>` tag linking to the image file or not.
|
||||
html_scaled_image_link = False
|
||||
@@ -498,7 +499,7 @@ def _generate_alternate_urls(app, pagename, templatename, context, doctree):
|
||||
_root = app.config.project_root
|
||||
else:
|
||||
# Project root like .../documentation/_build/html/14.0/fr
|
||||
_root = re.sub(rf'(/{app.config.version})?(/{app.config.language})?$', '', app.outdir)
|
||||
_root = re.sub(rf'(/{app.config.version})?(/{app.config.language})?$', '', str(app.outdir))
|
||||
# If the canonical version is not set, assume that the project has a single version
|
||||
_canonical_version = app.config.canonical_version or app.config.version
|
||||
_version = _version or app.config.version
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
After Width: | Height: | Size: 2.9 KiB |
@@ -4,9 +4,9 @@
|
||||
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).
|
||||
Odoo *Expenses* streamlines the management of expenses. After an employee submits their expenses 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.
|
||||
|
||||
@@ -483,9 +378,9 @@ 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.
|
||||
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
|
||||
@@ -493,8 +388,8 @@ so that only the :guilabel:`Approved` status is enabled.
|
||||
|
||||
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`.
|
||||
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:`Post Entries`.
|
||||
|
||||
.. image:: expenses/post-entries.png
|
||||
:align: center
|
||||
@@ -532,8 +427,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 +463,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 +485,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,11 +505,11 @@ 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
|
||||
@@ -651,3 +547,11 @@ 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/expense_reports`
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
expenses/expense_reports
|
||||
|
||||
|
Before Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 26 KiB |
@@ -0,0 +1,125 @@
|
||||
===============
|
||||
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::
|
||||
The :ref:`expenses/approve`, :ref:`expenses/post`, and :ref:`expenses/reimburse` sections are
|
||||
**only** for users with the appropriate *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 |
@@ -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)
|
||||
|
||||
@@ -33,6 +33,8 @@ Configuration on the Xendit Dashboard
|
||||
#. In the :guilabel:`Webhook URL` section, enter your Odoo database's URL, followed by
|
||||
`/payment/xendit/webhook` (e.g., `https://example.odoo.com/payment/xendit/webhook`) in the field
|
||||
:guilabel:`Invoices paid` and click the :guilabel:`Test and save` button next to it.
|
||||
#. Navigate to the `Card Settings page <https://dashboard.xendit.co/settings/payment-methods/cards-configuration>`_
|
||||
and ensure that :guilabel:`Optional 3DS` is enabled while :guilabel:`Dynamic 3DS` is disabled.
|
||||
|
||||
Configuration on Odoo
|
||||
=====================
|
||||
|
||||
@@ -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 |
@@ -1,5 +1,4 @@
|
||||
:show-content:
|
||||
:show-toc:
|
||||
|
||||
===========
|
||||
Recruitment
|
||||
@@ -191,8 +190,8 @@ Odoo:
|
||||
- :ref:`Initial Qualification <recruitment/initial-qualification>`
|
||||
- :ref:`First Interview <recruitment/first-interview>`
|
||||
- :ref:`Second Interview <recruitment/second-interview>`
|
||||
- :ref:`Contract Proposal <recruitment/contract-proposal>`
|
||||
- :ref:`Contract Signed <recruitment/contract-signed>`
|
||||
- :doc:`Contract Proposal <recruitment/offer_job_positions>`
|
||||
- :ref:`Contract Signed <recruitment/offer_job_positions/contract-signed>`
|
||||
|
||||
The last column, :guilabel:`Contract Signed`, is folded by default. Folded columns appear gray, and
|
||||
the applicants in it are hidden from view. To expand the folded stage and view the applicant cards
|
||||
@@ -369,314 +368,24 @@ 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.
|
||||
|
||||
.. _recruitment/contract-proposal:
|
||||
|
||||
Contract proposal
|
||||
-----------------
|
||||
|
||||
When the applicant has passed the interview stages and an offer is ready to be sent, they can be
|
||||
moved to the :guilabel:`Contract Proposal` stage. Drag and drop the applicant's card to the
|
||||
:guilabel:`Contract Proposal` stage, or click on the :guilabel:`Contract Proposal` stage button at
|
||||
the top-right of the individual applicant's card.
|
||||
|
||||
The next step is to send an offer to the applicant. On the applicant's card, click the
|
||||
:guilabel:`Generate Offer` button. A :guilabel:`Generate a Simulation Link` pop-up appears. Most
|
||||
fields are pre-populated with information from the job position. If any necessary fields are blank,
|
||||
enter the relevant information in the fields.
|
||||
|
||||
.. note::
|
||||
Not all fields may appear on the :guilabel:`Generate a Simulation Link` pop-up. Depending on the
|
||||
localization setting for the company and the applications installed, some fields may not appear.
|
||||
For example if the *Fleet* application is not installed, any fields related to vehicles do not
|
||||
appear on the pop-up window.
|
||||
|
||||
Universal fields
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The following fields appear for all offers sent to applicants regardless of localization settings.
|
||||
|
||||
- :guilabel:`Contract Template`: the template currently being used to populate the
|
||||
:guilabel:`Generate a Simulation Link` pop-up window. To modify the template, click the
|
||||
:guilabel:`Internal link` icon to the right of the drop-down arrow. Make any changes, then click
|
||||
:guilabel:`Save & Close`. A different :guilabel:`Contract Template` can be selected using the
|
||||
drop-down menu.
|
||||
- :guilabel:`Job Position`: the name of the :guilabel:`Job Position` being offered to the
|
||||
applicant. The selections available in the drop-down menu correspond to the :guilabel:`Job
|
||||
Positions` configured on the main *Recruitment* dashboard.
|
||||
- :guilabel:`Job Title`: the specific name of the position being offered to the applicant.
|
||||
- :guilabel:`Department`: the :guilabel:`Department` the job position falls under.
|
||||
- :guilabel:`Contract Start Date`: the date the contract takes effect. The default date is the
|
||||
current date. To modify the date, click the drop-down to reveal a calendar. Use the :guilabel:`<
|
||||
(left)` and :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.
|
||||
- :guilabel:`Yearly Cost`: the annual salary being offered.
|
||||
- :guilabel:`Link Expiration Date`: job offers are only valid for a specific period of time. The
|
||||
default expiration date is 30 days. Modify the expiration date, if desired.
|
||||
|
||||
Send offer
|
||||
~~~~~~~~~~
|
||||
|
||||
When the information is all updated, click :guilabel:`Send By Email` to send the offer to the
|
||||
applicant.
|
||||
|
||||
If the applicant does not have an email address listed on their applicant card, a warning appears in
|
||||
a red box at the bottom of the :guilabel:`Generate a Simulation Link` pop-up window, stating
|
||||
:guilabel:`The applicant does not have a valid email set. The Offer Link won't be able to be
|
||||
completed.` Click :guilabel:`Discard`, enter an email on the applicant's card, then click the
|
||||
:guilabel:`Generate Offer` button again.
|
||||
|
||||
An email pop-up window loads. The default :guilabel:`Recruitment: Your Salary Package` email
|
||||
template is used, and the :guilabel:`Recipients`, :guilabel:`Subject`, and email body are
|
||||
pre-populated based on the email template.
|
||||
|
||||
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.
|
||||
|
||||
Once the email is ready to send, click :guilabel:`Send`.
|
||||
|
||||
.. note::
|
||||
To send an offer, ensure the *Sign* application is installed. This is necessary so the offer can
|
||||
be sent to the applicant by the recruiter. The applicant does not need any software installed.
|
||||
|
||||
.. image:: recruitment/send-offer.png
|
||||
:align: center
|
||||
:alt: Send an email to the applicant with a link to the offered salary.
|
||||
|
||||
Configure your package
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The email template includes a :guilabel:`Configure your package` button. This link takes the
|
||||
applicant to a webpage where they can modify the proposed salary package, and enter their personal
|
||||
information.
|
||||
|
||||
Once the applicant is hired, the personal information entered on the webpage is imported to their
|
||||
employee record, when created.
|
||||
|
||||
If applicable, the applicant can modify their salary package. This option is not available for all
|
||||
localizations. Depending on where the company is located, this option may not be available.
|
||||
|
||||
Once all the information is completed, the applicant accepts the offer by clicking the
|
||||
:guilabel:`Review Contract & Sign` button to accept the contract and sign it using the *Sign*
|
||||
application.
|
||||
|
||||
.. _recruitment/contract-signed:
|
||||
|
||||
Contract signed
|
||||
---------------
|
||||
|
||||
Once the applicant has accepted the offer and signed the contract, the next step is to move the
|
||||
applicant to the :guilabel:`Contract Signed` stage. To move the applicant to the next stage, drag
|
||||
and drop the applicant's card to the :guilabel:`Contract Signed` stage, or click the
|
||||
:guilabel:`More` button at the top of the applicant's card to reveal the :guilabel:`Contract
|
||||
Signed` stage button at the top of the individual applicant's card, and click :guilabel:`Contract
|
||||
Signed`.
|
||||
|
||||
The :guilabel:`Contract Signed` stage is folded in the Kanban view, but the card may still be
|
||||
dragged and dropped into that stage.
|
||||
|
||||
Once the applicant's card moves to the :guilabel:`Contract Signed` stage, a green :guilabel:`HIRED`
|
||||
banner appears in the top-right of the applicant's card.
|
||||
|
||||
.. image:: recruitment/hired.png
|
||||
:align: center
|
||||
:alt: Hired banner in the top right corner of applicant card.
|
||||
|
||||
Create employee
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Once the applicant has been hired, the next step is to create an employee record of them. On the
|
||||
applicant's card, click the :guilabel:`Create Employee` button in the top-left. An employee form
|
||||
appears, and any information from the applicant's card that can be imported into the employee card
|
||||
appears in the form.
|
||||
|
||||
Fill out the rest of the form. For detailed information on the fields, refer to the
|
||||
:doc:`employees/new_employee` documentation. When done, the employee record is saved in the
|
||||
*Employees* app.
|
||||
|
||||
.. seealso::
|
||||
- recruitment/new_job
|
||||
- recruitment/schedule_interviews
|
||||
- recruitment/add-new-applicants
|
||||
- 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/schedule_interviews
|
||||
recruitment/recruitment-flow
|
||||
recruitment/add-new-applicants
|
||||
recruitment/schedule_interviews
|
||||
recruitment/offer_job_positions
|
||||
recruitment/refuse_applicant
|
||||
|
||||
@@ -0,0 +1,162 @@
|
||||
===================
|
||||
Offer job positions
|
||||
===================
|
||||
|
||||
Once an applicant has successfully passed the various interview stages, the recruitment team is
|
||||
ready to send an offer for employment. The next step is to send the applicant a contract.
|
||||
|
||||
.. seealso::
|
||||
Refer to the :doc:`recruitment <../recruitment>` documentation for details on the various stages
|
||||
of the recruitment process.
|
||||
|
||||
Contract proposal
|
||||
=================
|
||||
|
||||
When an offer is ready to be sent, first open the applicant's card by navigating to the
|
||||
:menuselection:`Recruitment app`, and clicking on the desired job position card.
|
||||
|
||||
From the resulting :guilabel:`Job Positions` Kanban view, the corresponding applicant card can be
|
||||
dragged-and-dropped to the :guilabel:`Contract Proposal` stage. Or, click into the desired
|
||||
applicant's card, and click the :guilabel:`Contract Proposal` stage, located in the status bar in
|
||||
the top-right of the applicant's form.
|
||||
|
||||
The next step is to send an offer to the applicant. Start by selecting the desired applicant's card
|
||||
to open their applicant form.
|
||||
|
||||
On the applicant's form, click the :guilabel:`Generate Offer` button. A :guilabel:`Generate a
|
||||
Simulation Link` pop-up window appears.
|
||||
|
||||
Most fields are pre-populated with information from the job position. If any necessary fields are
|
||||
blank, or if any information needs to be updated, enter, or update, the relevant information in the
|
||||
corresponding fields.
|
||||
|
||||
.. note::
|
||||
Depending on the localization setting for the company, and which applications are installed, some
|
||||
fields may not appear in the :guilabel:`Generate a Simulation Link` pop-up window.
|
||||
|
||||
For example, if the *Fleet* application is **not** installed, any fields related to vehicles do
|
||||
**not** appear.
|
||||
|
||||
Universal fields
|
||||
----------------
|
||||
|
||||
The following fields appear in the :guilabel:`Generate a Simulation Link` pop-up window, regardless
|
||||
of the localization.
|
||||
|
||||
- :guilabel:`Contract Template`: the template currently being used to populate the
|
||||
:guilabel:`Generate a Simulation Link` pop-up window. Use the drop-down menu to select a different
|
||||
:guilabel:`Contract Template`, if desired.
|
||||
|
||||
.. note::
|
||||
To modify the template, hover over the current template name, and click the :icon:`oi-launch`
|
||||
:guilabel:`Internal link` icon that appears to the right of the field. Make any desired
|
||||
changes, then click :guilabel:`Save & Close`.
|
||||
|
||||
- :guilabel:`Job Position`: the name of the :guilabel:`Job Position` being offered to the applicant.
|
||||
The selections available in the drop-down menu correspond to the job position configured on the
|
||||
main *Recruitment* dashboard.
|
||||
- :guilabel:`Job Title`: the selected :guilabel:`Job Position` populates this field, by default.
|
||||
The title can be modified to suit the specific applicant's position and provide more details.
|
||||
|
||||
.. example::
|
||||
An applicant is offered a marketing manager job at a shoe company, specifically for the
|
||||
children's line.
|
||||
|
||||
The :guilabel:`Job Position` selected from the drop-down menu is `Marketing Manager`, and the
|
||||
:guilabel:`Job Title` is modified for their specific responsibilities, `Marketing Manager:
|
||||
Children's Shoes`.
|
||||
|
||||
- :guilabel:`Department`: the department the job position falls under.
|
||||
- :guilabel:`Contract Start Date`: the date the contract takes effect. The default date is the
|
||||
current date. To modify the date, click on the displayed date to reveal a calendar popover window.
|
||||
Navigate to the desired month, then click the day to select the date.
|
||||
- :guilabel:`Yearly Cost`: the annual salary being offered.
|
||||
- :guilabel:`Link Expiration Date`: the number of days the job offer is valid. The default
|
||||
expiration date is `30` days. Modify the expiration date, if desired.
|
||||
|
||||
Send offer
|
||||
----------
|
||||
|
||||
Once the :guilabel:`Generate a Simulation Link` pop-up window is complete, click :guilabel:`Send By
|
||||
Email` to reveal an email pop-up window.
|
||||
|
||||
.. important::
|
||||
If the applicant does not have an email address listed on their applicant card, a warning appears
|
||||
in a red box at the bottom of the :guilabel:`Generate a Simulation Link` pop-up window, stating:
|
||||
:guilabel:`The applicant does not have a valid email set. The Offer Link won't be able to be
|
||||
completed.` Click :guilabel:`Discard`, then enter an email on the applicant's card. Once an email
|
||||
is entered, click the :guilabel:`Generate Offer` button, and the email pop-up window loads again.
|
||||
|
||||
The default :guilabel:`Recruitment: Your Salary Package` email template is used (set in the
|
||||
:guilabel:`Load template` field), and the :guilabel:`Recipients`, :guilabel:`Subject`, and email
|
||||
body are pre-populated based on the email template.
|
||||
|
||||
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, then click :guilabel:`Open` to
|
||||
attach it to the email. The attachment loads, and is listed above the :icon:`fa-paperclip`
|
||||
:guilabel:`Attachments` button.
|
||||
|
||||
Once the email is ready to send, click :guilabel:`Send`. The email pop-up window closes, and an
|
||||
:guilabel:`Offers` smart button appears at the top of the applicant's card.
|
||||
|
||||
.. note::
|
||||
To send an offer, ensure the *Sign* application is installed. This is necessary, so the offer can
|
||||
be sent to the applicant by the recruiter, and they can actually sign the offer. The applicant
|
||||
does **not** need any software installed to sign the offer.
|
||||
|
||||
.. image:: offer_job_positions/send-offer.png
|
||||
:align: center
|
||||
:alt: Send an email to the applicant with a link to the offered salary.
|
||||
|
||||
Configure your package
|
||||
----------------------
|
||||
|
||||
If applicable, the applicant can modify their salary package. This option is not available for all
|
||||
localizations. Depending on where the company is located, this option may not be available.
|
||||
|
||||
The email template includes a :guilabel:`Configure your package` button. This link takes the
|
||||
applicant to a webpage, where they can modify the proposed salary package, and enter their personal
|
||||
information.
|
||||
|
||||
Once the applicant is hired, the personal information entered on the webpage is imported to their
|
||||
employee record, when created.
|
||||
|
||||
Once all the information is completed, the applicant can then accept the offer by clicking the
|
||||
:guilabel:`Review Contract & Sign` button to accept the contract, and sign it using the *Sign*
|
||||
application.
|
||||
|
||||
.. _recruitment/offer_job_positions/contract-signed:
|
||||
|
||||
Contract signed
|
||||
===============
|
||||
|
||||
Once the applicant has accepted the offer and signed the contract, the next step is to move the
|
||||
applicant to the :guilabel:`Contract Signed` stage. This stage is folded in the Kanban view, by
|
||||
default.
|
||||
|
||||
To move the applicant to that stage, drag-and-drop the applicant's card to the :guilabel:`Contract
|
||||
Signed` stage. If the stage is not visible, click the :icon:`fa-ellipsis-h` :guilabel:`(ellipsis)`
|
||||
button to the right of :guilabel:`Contract Proposal` on the applicant's form, and click
|
||||
:guilabel:`Contract Signed` from the resulting drop-down menu.
|
||||
|
||||
Once the applicant is moved to the :guilabel:`Contract Signed` stage, a green :guilabel:`HIRED`
|
||||
banner appears in the top-right of the applicant's card and form.
|
||||
|
||||
.. image:: offer_job_positions/hired.png
|
||||
:align: center
|
||||
:alt: Hired banner in the top right corner of applicant card.
|
||||
|
||||
.. _recruitment/new-employee:
|
||||
|
||||
Create employee
|
||||
===============
|
||||
|
||||
Once the applicant has been hired, the next step is to create their employee record. Click the
|
||||
:guilabel:`Create Employee` button in the top-left corner of the hired applicant's form.
|
||||
|
||||
An employee form appears, with information from the applicant's card, and the employee contract.
|
||||
|
||||
Fill out the rest of the employee form. For detailed information on the fields, refer to the
|
||||
:doc:`../employees/new_employee` documentation.
|
||||
|
||||
Once completed, the employee record is saved in the *Employees* app.
|
||||
|
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
|
Before Width: | Height: | Size: 32 KiB After Width: | Height: | Size: 32 KiB |
@@ -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 |
@@ -22,6 +22,8 @@ the :ref:`reporting <referrals/reporting>` and configurations menus. For more in
|
||||
and access rights, refer to these documents: :doc:`../general/users` and
|
||||
:doc:`../general/users/access_rights`.
|
||||
|
||||
.. _referrals/onboarding:
|
||||
|
||||
Onboarding
|
||||
==========
|
||||
|
||||
@@ -168,76 +170,6 @@ any changes, and revert to the original content.
|
||||
original image. To revert to the original image, the *Referrals* application must be *uninstalled
|
||||
then reinstalled.*
|
||||
|
||||
Referral points
|
||||
===============
|
||||
|
||||
The referral program is based on earning points that are then exchanged for rewards. On the main
|
||||
*Referrals* application dashboard, the top displays a summary of the user's current points. The left
|
||||
side of the summary displays the total points earned, and the right side displays the points that
|
||||
are available to spend.
|
||||
|
||||
To see the various referrals and the points earned for each, click on one of the buttons directly
|
||||
beneath the avatars. The options are :guilabel:`Referrals`, :guilabel:`Ongoing`, and
|
||||
:guilabel:`Successful`.
|
||||
|
||||
The current number of referrals who are still active in the recruitment pipeline, and have not yet
|
||||
been hired or refused, appear above the :guilabel:`Ongoing` button. The number of referrals who have
|
||||
been hired appear above the :guilabel:`Successful` button. The total number of referrals (both the
|
||||
ongoing and successful referrals combined) appear above the :guilabel:`Referrals` button.
|
||||
|
||||
.. note::
|
||||
To view the referrals associated with each of the categories, :guilabel:`Referrals`,
|
||||
:guilabel:`Ongoing`, and :guilabel:`Successful`, click on the corresponding button. All the
|
||||
referrals for that specific category are displayed.
|
||||
|
||||
My referrals
|
||||
------------
|
||||
|
||||
To see all the referrals (both ongoing and successful) click the :guilabel:`Referrals` button. A
|
||||
:guilabel:`My Referral` window loads. This screen displays all the referrals, with each referral in
|
||||
its own referral card.
|
||||
|
||||
A successful referral displays a green :guilabel:`Hired` banner in the top-right corner of the card.
|
||||
Referrals that are in process display a purple :guilabel:`In Progress` banner in the top-right
|
||||
corner.
|
||||
|
||||
Each referral card lists the name of the applicant, the subject/application title (as it appears on
|
||||
the applicant card in the *Recruitment* app), the name of the job position, the person responsible
|
||||
for filling the role (recruiter), and the points earned. For referrals that have been hired, the
|
||||
selected avatar also appears on the card.
|
||||
|
||||
.. image:: referrals/referrals.png
|
||||
:align: center
|
||||
:alt: Two referral cards, one hired and one in-progress.
|
||||
|
||||
Points
|
||||
~~~~~~
|
||||
|
||||
The points that can be earned for a referral are the same across all job positions. Each stage of
|
||||
the recruitment process has corresponding points assigned to it. The stages listed correspond to the
|
||||
stages configured in the *Recruitment* application.
|
||||
|
||||
On each individual referral card, beneath the points earned is a bar chart that displays how many
|
||||
points have been earned out of the total possible points that can be earned if the applicant is
|
||||
hired.
|
||||
|
||||
Beneath the bar chart is a list of the various recruitment stages and the points earned when the
|
||||
referral moves to that stage. If a stage has been achieved and the points have been earned, a green
|
||||
check mark appears next to the stage.
|
||||
|
||||
.. example::
|
||||
The pre-configured point structure for referrals is as follows:
|
||||
|
||||
- :guilabel:`Initial Qualification`: 1 point
|
||||
- :guilabel:`First Interview`: 20 points
|
||||
- :guilabel:`Second Interview`: 9 points
|
||||
- :guilabel:`Contract Proposal`: 5 points
|
||||
- :guilabel:`Contract Signed`: 50 points
|
||||
|
||||
The total points earned for a referral that is hired is 85 points. Modifications of the points
|
||||
earned for each stage are done in the *Recruitment* application. Refer to the
|
||||
:ref:`Recruitment <recruitment/modify-stages>` documentation to modify the points for each stage.
|
||||
|
||||
.. _referrals/levels:
|
||||
|
||||
Levels
|
||||
@@ -356,11 +288,13 @@ spreadsheet from the drop-down menu, or select :guilabel:`New Spreadsheet`. Clic
|
||||
|
||||
.. seealso::
|
||||
- :doc:`referrals/share_jobs`
|
||||
- :doc:`referrals/alerts`
|
||||
- :doc:`referrals/points`
|
||||
- :doc:`referrals/rewards`
|
||||
- :doc:`referrals/alerts`
|
||||
|
||||
.. toctree::
|
||||
|
||||
referrals/share_jobs
|
||||
referrals/alerts
|
||||
referrals/points
|
||||
referrals/rewards
|
||||
referrals/alerts
|
||||
|
||||
@@ -0,0 +1,72 @@
|
||||
===============
|
||||
Referral points
|
||||
===============
|
||||
|
||||
The *Referrals* application allows employees to earn points that are then exchanged for
|
||||
:doc:`rewards <rewards>`.
|
||||
|
||||
Current referral points can be viewed on the main *Referrals* app dashboard, which appears when the
|
||||
application is opened, after the :ref:`onboarding <referrals/onboarding>` slides have been viewed or
|
||||
skipped.
|
||||
|
||||
At the top, a summary of the user's current points is displayed. The left side of the summary
|
||||
displays the :guilabel:`Total` points earned, and the right side displays the points that are
|
||||
available :guilabel:`To Spend`.
|
||||
|
||||
To view the various referral stages, and their respective earned points, click one of the referral
|
||||
statuses beneath the avatar. The options are: :guilabel:`Referrals`, :guilabel:`Ongoing`, and
|
||||
:guilabel:`Successful`.
|
||||
|
||||
The current number of referrals that are still active in the recruitment pipeline, but have not yet
|
||||
been hired or refused, appear above :guilabel:`Ongoing`. The number of referrals that have been
|
||||
hired, appear above :guilabel:`Successful`. The total number of referrals, both the ongoing and
|
||||
successful referrals combined, appears above :guilabel:`Referrals`.
|
||||
|
||||
My referrals
|
||||
============
|
||||
|
||||
To see all the referrals, both ongoing and successful, click :guilabel:`Referrals`. The
|
||||
:guilabel:`My Referral` screen page displays all the referrals, with each individual referral housed
|
||||
in its own referral card.
|
||||
|
||||
A successful referral displays a white :icon:`fa-check` :guilabel:`Hired` badge in the top-right
|
||||
corner of the card, along with a vertical green stripe on the left-side of the card. Referrals that
|
||||
are in process have a purple :guilabel:`In Progress` badge in the top-right corner.
|
||||
|
||||
Each referral card lists the name of the applicant, the subject/application title as it appears on
|
||||
the applicant card in the *Recruitment* app, the name of the job position, the person responsible
|
||||
for filling the role (i.e. the recruiter), and the points earned.
|
||||
|
||||
For referrals that have been hired, the selected avatar also appears on the card.
|
||||
|
||||
.. image:: points/referrals.png
|
||||
:align: center
|
||||
:alt: Two referral cards, one hired and one in-progress.
|
||||
|
||||
Points
|
||||
------
|
||||
|
||||
The points that can be earned for a referral are the same across all job positions. Each stage of
|
||||
the recruitment process has corresponding points assigned to it. The stages listed correspond to the
|
||||
stages configured in the *Recruitment* application.
|
||||
|
||||
On each individual referral card, beneath the points earned, is a progress bar that displays how
|
||||
many points have been earned out of the total possible points that can be earned, if the applicant
|
||||
is hired.
|
||||
|
||||
Beneath the bar chart is a list of the various recruitment stages, and the points earned when the
|
||||
referral moves to that stage. If a stage has been achieved, and the points have been earned, a green
|
||||
:icon:`fa-check` :guilabel:`(checkmark)` appears next to the stage.
|
||||
|
||||
.. note::
|
||||
The preconfigured point structure for referrals is as follows:
|
||||
|
||||
- :guilabel:`Initial Qualification`: 1 point
|
||||
- :guilabel:`First Interview`: 20 points
|
||||
- :guilabel:`Second Interview`: 9 points
|
||||
- :guilabel:`Contract Proposal`: 5 points
|
||||
- :guilabel:`Contract Signed`: 50 points
|
||||
|
||||
The default total points earned for a referral that is hired is 85 points. Modifications of the
|
||||
points earned for each stage are made in the *Recruitment* application. Refer to the
|
||||
:ref:`Recruitment <recruitment/modify-stages>` documentation to modify the points for each stage.
|
||||
|
After Width: | Height: | Size: 40 KiB |
|
Before Width: | Height: | Size: 26 KiB |
@@ -8,7 +8,7 @@ Odoo's *Time Off* application serves as a centralized hub for all time-off-relat
|
||||
application manages requests, balances, allocations, approvals, and reports.
|
||||
|
||||
Users can :doc:`request time off <../hr/time_off/request_time_off>`, and see an overview of their
|
||||
requests and time off balances. Managers can :ref:`allocate time off <time_off/allocate>` to
|
||||
requests and time off balances. Managers can :doc:`allocate time off <time_off/allocations>` to
|
||||
individuals, teams, or the whole company, and :ref:`approve time off requests
|
||||
<time_off/manage-time-off>`.
|
||||
|
||||
@@ -429,124 +429,6 @@ Enter the following information on that new line:
|
||||
:align: center
|
||||
:alt: The Mandatory Days section with three configured days.
|
||||
|
||||
.. _time_off/allocate:
|
||||
|
||||
Allocate time off
|
||||
=================
|
||||
|
||||
Once time off types and accrual plans have been configured, the next step is to allocate, or give,
|
||||
time off to employees. This section is only visible to users who have either :guilabel:`Time Off
|
||||
Officer` or :guilabel:`Administrator` access rights for the *Time Off* application.
|
||||
|
||||
To create a new allocation, navigate to :menuselection:`Time Off app --> Management -->
|
||||
Allocations`.
|
||||
|
||||
This presents a list of all current allocations, including their respective statuses.
|
||||
|
||||
Click :guilabel:`New` to allocate time off, and a blank allocation form appears.
|
||||
|
||||
After entering a name for the allocation on the first blank field of the form, enter the following
|
||||
information:
|
||||
|
||||
- :guilabel:`Time Off Type`: using the drop-down menu, select the type of time off that is being
|
||||
allocated to the employees.
|
||||
- :guilabel:`Allocation Type`: select either :guilabel:`Regular Allocation` or :guilabel:`Accrual
|
||||
Allocation`. If the allocation is **not** based on an accrual plan, select :guilabel:`Regular
|
||||
Allocation`.
|
||||
- :guilabel:`Accrual Plan`: if :guilabel:`Accrual Allocation` is selected for the
|
||||
:guilabel:`Allocation Type`, the :guilabel:`Accrual Plan` field appears. Using the drop-down menu,
|
||||
select the accrual plan with which the allocation is associated. An accrual plan **must** be
|
||||
selected for an :guilabel:`Accrual Allocation`.
|
||||
- :guilabel:`Validity Period/Start Date`: if :guilabel:`Regular Allocation` is selected for the
|
||||
:guilabel:`Allocation Type`, this field is labeled :guilabel:`Validity Period`. If
|
||||
:guilabel:`Accrual Allocation` is selected for the :guilabel:`Allocation Type`, this field is
|
||||
labeled :guilabel:`Start Date`.
|
||||
|
||||
The current date populates the first date field by default. To select another date, click on the
|
||||
pre-populated date to reveal a popover calendar window. Navigate to the desired start date for the
|
||||
allocation, and click on the date to select it.
|
||||
|
||||
If the allocation expires, select the expiration date in the next date field. If the time off does
|
||||
*not* expire, leave the second date field blank. `No Limit` appears in the field if no date is
|
||||
selected.
|
||||
|
||||
If :guilabel:`Accrual Allocation` is selected for the :guilabel:`Allocation Type`, this second
|
||||
field is labeled :guilabel:`Run until`.
|
||||
- :guilabel:`Allocation`: enter the amount of time that is being allocated to the employees. This
|
||||
field displays the time in either :guilabel:`Hours` or :guilabel:`Days`, depending on how the
|
||||
selected :ref:`Time Off Type <time_off/time-off-types>` is configured (in hours or days).
|
||||
- :guilabel:`Mode`: using the drop-down menu, select how the allocation is assigned. This selection
|
||||
determines who receives the time off allocation. The options are :guilabel:`By Employee`,
|
||||
:guilabel:`By Company`, :guilabel:`By Department`, or :guilabel:`By Employee Tag`.
|
||||
|
||||
Depending on what is selected for the :guilabel:`Mode`, this following field is labeled either:
|
||||
:guilabel:`Employees`, :guilabel:`Company`, :guilabel:`Department`, or :guilabel:`Employee Tag`.
|
||||
|
||||
Using the drop-down menu, indicate the specific employees, company, department, or employee tags
|
||||
who are receiving this time off.
|
||||
|
||||
Multiple selections can be made for either :guilabel:`Employees` or :guilabel:`Employee Tag`.
|
||||
|
||||
Only one selection can be made for the :guilabel:`Company` or :guilabel:`Department`.
|
||||
- :guilabel:`Add a reason...`: if any description or note is necessary to explain the time off
|
||||
allocation, enter it in this field at the bottom of the form.
|
||||
|
||||
.. image:: time_off/new-allocation.png
|
||||
:align: center
|
||||
:alt: A new allocation form with all the fields filled out for the annual two week vacation
|
||||
granted to all employees.
|
||||
|
||||
.. _time_off/request-allocation:
|
||||
|
||||
Request allocation
|
||||
==================
|
||||
|
||||
If an employee has used all their time off, or is going to run out of time off, they can request an
|
||||
allocation for additional time. Allocations can be requested in one of two ways, either from the
|
||||
:ref:`Dashboard <time_off/dashboard>` or the :ref:`My Allocations <time_off/my-allocations>` view.
|
||||
|
||||
To create a new allocation request, click either the :guilabel:`New Allocation Request` button on
|
||||
the main *Time Off* dashboard, or the :guilabel:`New` button in the :guilabel:`My Allocations` list
|
||||
view. Both buttons open a new allocation request form.
|
||||
|
||||
.. note::
|
||||
Both :guilabel:`New` buttons open a :guilabel:`New Allocation` request form, but when requested
|
||||
from the :guilabel:`Dashboard`, the form appears in a modal. When requested from the
|
||||
:guilabel:`My Allocations` list view, the screen navigates to a new allocation request page,
|
||||
instead.
|
||||
|
||||
Enter the following information on the :guilabel:`New Allocation` request form:
|
||||
|
||||
- :guilabel:`Time Off Type`: select the type of time off being requested for the allocation from the
|
||||
drop-down menu. After a selection is made, the title updates with the time off type.
|
||||
- :guilabel:`Validity Period`: this field **only** appears if requesting an allocation with a time
|
||||
off type that has the :guilabel:`Take Time Off in` field :ref:`configured
|
||||
<time_off/time-off-officer>` to either :guilabel:`Day` or :guilabel:`Half Day`. This field does
|
||||
**not** appear if the :guilabel:`Take Time Off in` field is set to :guilabel:`Hours`.
|
||||
|
||||
Using the calendar selector, select a start and end date the allocation is valid for. By default,
|
||||
the current date populates the first field, and :guilabel:`No Limit` populates the second field.
|
||||
|
||||
Adjust both of these dates, if desired.
|
||||
- :guilabel:`Allocation`: enter the amount of time being requested in this field. The format is
|
||||
presented in either days or hours, depending on how the time off type is configured. Once this
|
||||
field is populated, the name of the allocation request is updated to include the amount of time
|
||||
being requested.
|
||||
- :guilabel:`Add a reason...`: enter a description for the allocation request. This should include
|
||||
any details that managers and approvers may need in order to approve the request.
|
||||
|
||||
If the request was created from the :guilabel:`Dashboard`, click the :guilabel:`Save & Close` button
|
||||
to save the information and submit the request.
|
||||
|
||||
If the form was completed from the :guilabel:`My Allocations` list view, the information is
|
||||
automatically saved as it is entered. However, the form can be saved manually at any time by
|
||||
clicking the *save manually* button, represented by a :guilabel:`(cloud upload)` icon.
|
||||
|
||||
.. image:: time_off/allocation-request.png
|
||||
:align: center
|
||||
:alt: An allocation request form filled out for an employee requesting an additional week of
|
||||
sick time.
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
@@ -664,6 +546,7 @@ detailed information on the reports, and their various options, refer to the :do
|
||||
<../essentials/reporting>` documentation.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`time_off/allocations`
|
||||
- :doc:`time_off/request_time_off`
|
||||
- :doc:`time_off/my_time`
|
||||
- :doc:`time_off/management`
|
||||
@@ -671,6 +554,7 @@ detailed information on the reports, and their various options, refer to the :do
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
time_off/allocations
|
||||
time_off/request_time_off
|
||||
time_off/my_time
|
||||
time_off/management
|
||||
|
||||
@@ -0,0 +1,118 @@
|
||||
===========
|
||||
Allocations
|
||||
===========
|
||||
|
||||
Once :ref:`time off types <time_off/time-off-types>` and :ref:`accrual plans
|
||||
<time_off/accrual-plans>` have been configured, the next step is to *allocate*, or give, time off to
|
||||
employees.
|
||||
|
||||
The *Allocations* section of the *Time Off* app is **only** visible to users who have either
|
||||
:guilabel:`Time Off Officer` or :guilabel:`Administrator` access rights for the *Time Off*
|
||||
application. For more information on access rights, refer to the :doc:`access rights
|
||||
<../../general/users/access_rights/>` documentation.
|
||||
|
||||
Allocate time off
|
||||
=================
|
||||
|
||||
To create a new allocation, navigate to :menuselection:`Time Off app --> Management -->
|
||||
Allocations`.
|
||||
|
||||
This presents a list of all current allocations, including their respective statuses.
|
||||
|
||||
Click :guilabel:`New` to allocate time off, and a blank allocation form appears.
|
||||
|
||||
After entering a name for the allocation on the first blank field of the form, enter the following
|
||||
information:
|
||||
|
||||
- :guilabel:`Time Off Type`: using the drop-down menu, select the type of time off that is being
|
||||
allocated to the employees.
|
||||
- :guilabel:`Allocation Type`: select either :guilabel:`Regular Allocation` or :guilabel:`Accrual
|
||||
Allocation`. If the allocation is **not** based on an :ref:`accrual plan
|
||||
<time_off/accrual-plans>`, select :guilabel:`Regular Allocation`.
|
||||
- :guilabel:`Accrual Plan`: if :guilabel:`Accrual Allocation` is selected for the
|
||||
:guilabel:`Allocation Type`, the :guilabel:`Accrual Plan` field appears. Using the drop-down menu,
|
||||
select the accrual plan with which the allocation is associated. An accrual plan **must** be
|
||||
selected for an :guilabel:`Accrual Allocation`.
|
||||
- :guilabel:`Validity Period/Start Date`: if :guilabel:`Regular Allocation` is selected for the
|
||||
:guilabel:`Allocation Type`, this field is labeled :guilabel:`Validity Period`. If
|
||||
:guilabel:`Accrual Allocation` is selected for the :guilabel:`Allocation Type`, this field is
|
||||
labeled :guilabel:`Start Date`.
|
||||
|
||||
The current date populates the first date field, by default. To select another date, click on the
|
||||
pre-populated date to reveal a popover calendar window. Navigate to the desired start date for the
|
||||
allocation, and click on the date to select it.
|
||||
|
||||
If the allocation expires, select the expiration date in the next date field. If the time off does
|
||||
*not* expire, leave the second date field blank. :guilabel:`No Limit` appears in the field if no
|
||||
date is selected.
|
||||
|
||||
If :guilabel:`Accrual Allocation` is selected for the :guilabel:`Allocation Type`, this second
|
||||
field is labeled :guilabel:`Run until`.
|
||||
- :guilabel:`Allocation`: enter the amount of time that is being allocated to the employees. This
|
||||
field displays the time in either :guilabel:`Hours` or :guilabel:`Days`, depending on how the
|
||||
selected :ref:`Time Off Type <time_off/time-off-types>` is configured.
|
||||
- :guilabel:`Mode`: using the drop-down menu, select how the allocation is assigned. This selection
|
||||
determines who receives the time off allocation. The options are :guilabel:`By Employee`,
|
||||
:guilabel:`By Company`, :guilabel:`By Department`, or :guilabel:`By Employee Tag`.
|
||||
|
||||
Depending on what is selected for the :guilabel:`Mode`, the following field is labeled either:
|
||||
:guilabel:`Employees`, :guilabel:`Company`, :guilabel:`Department`, or :guilabel:`Employee Tag`.
|
||||
|
||||
Using the drop-down menu, indicate the specific employees, company, department, or employee tags
|
||||
receiving this time off.
|
||||
|
||||
Multiple selections can be made for either :guilabel:`Employees` or :guilabel:`Employee Tag`.
|
||||
|
||||
Only one selection can be made for the :guilabel:`Company` or :guilabel:`Department`.
|
||||
- :guilabel:`Add a reason...`: if any description or note is necessary to explain the time off
|
||||
allocation, enter it in this field at the bottom of the form.
|
||||
|
||||
.. image:: allocations/new-allocation.png
|
||||
:align: center
|
||||
:alt: A new allocation form with all the fields filled out for the annual two week vacation
|
||||
granted to all employees.
|
||||
|
||||
.. _time_off/request-allocation:
|
||||
|
||||
Request allocation
|
||||
==================
|
||||
|
||||
If an employee has used all their time off, or will run out of time off, they can request an
|
||||
allocation for additional time. Allocations can be requested in one of two ways, either from the
|
||||
:ref:`Dashboard <time_off/dashboard>` or the :ref:`My Allocations <time_off/my-allocations>` view.
|
||||
|
||||
To create a new allocation request, click either the :guilabel:`New Allocation Request` button on
|
||||
the main *Time Off* dashboard, or the :guilabel:`New` button in the :guilabel:`My Allocations` list
|
||||
view. Both buttons open a new allocation request form.
|
||||
|
||||
.. note::
|
||||
Both options open a new allocation request form, but when requested from the
|
||||
:guilabel:`Dashboard`, the form appears in a pop-up window. When requested from the
|
||||
:guilabel:`My Allocations` list view, the screen navigates to a new allocation request page,
|
||||
instead.
|
||||
|
||||
Enter the following information on the new allocation request form:
|
||||
|
||||
- :guilabel:`Time Off Type`: select the type of time off being requested for the allocation from the
|
||||
drop-down menu. After a selection is made, the title updates with the time off type.
|
||||
- :guilabel:`Validity Period`: using the calendar selector, select a start and end date the
|
||||
allocation is valid for. By default, the current date populates the first field, and :guilabel:`No
|
||||
Limit` populates the second field. Adjust both of these dates, if desired.
|
||||
- :guilabel:`Allocation`: enter the amount of time being requested in this field. The format is
|
||||
presented in either :guilabel:`Days` or :guilabel:`Hours`, depending on how the :guilabel:`Time
|
||||
Off Type` is configured. Once this field is populated, the name of the allocation request is
|
||||
updated to include the amount of time being requested.
|
||||
- :guilabel:`Add a reason...`: enter a description for the allocation request. This should include
|
||||
any details that approvers may need to approve the request.
|
||||
|
||||
If the request was created from the :guilabel:`Dashboard`, click the :guilabel:`Save & Close` button
|
||||
on the :guilabel:`New Allocation` pop-up window to save the information and submit the request.
|
||||
|
||||
If the form was completed from the :guilabel:`My Allocations` list view, the information is
|
||||
automatically saved as it is entered. However, the form can be saved manually at any time by
|
||||
clicking the :icon:`fa-cloud-upload` :guilabel:`(cloud upload)` icon.
|
||||
|
||||
.. image:: allocations/allocation-request.png
|
||||
:align: center
|
||||
:alt: An allocation request form filled out for an employee requesting an additional week of
|
||||
sick time.
|
||||
|
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 25 KiB |
|
Before Width: | Height: | Size: 19 KiB After Width: | Height: | Size: 19 KiB |
@@ -26,7 +26,13 @@ To begin, go to the `Bpost website <https://parcel.bpost.be/en/home/business>`_
|
||||
into, the company's Bpost business account. When creating the Bpost account, have the company's VAT
|
||||
number and mobile phone number ready.
|
||||
|
||||
Follow the website's steps to complete registration, and sign up for shipping services.
|
||||
Follow the website's steps to complete registration, and sign up for shipping services. Doing so
|
||||
submits a request to enter a contractual business relationship between the company and Bpost.
|
||||
|
||||
.. important::
|
||||
Odoo **cannot** be integrated with `non-business Bpost
|
||||
<https://bpost.freshdesk.com/support/solutions/articles/174847-account-id-and-passphrase>`_
|
||||
accounts.
|
||||
|
||||
After completing the setup, get the Bpost account ID and passphrase, by navigating to the
|
||||
:guilabel:`Shipping Manager` menu item.
|
||||
|
||||
@@ -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 |
@@ -93,6 +93,8 @@ match is found:
|
||||
:align: center
|
||||
:alt: Some examples of putaway rules.
|
||||
|
||||
.. _inventory/warehouses_storage/storage-category:
|
||||
|
||||
Storage categories
|
||||
==================
|
||||
|
||||
|
||||
@@ -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>`
|
||||
|
||||
|
||||
@@ -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 |
@@ -21,21 +21,7 @@ from physical inventory, and placing it in a virtual scrap location (*Virtual Lo
|
||||
physical inventory.
|
||||
|
||||
For more information about virtual locations, see the documentation about the different types of
|
||||
:ref:`locations <inventory/warehouses_storage/difference-warehouse-location>`.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
To use locations in warehouse, including a virtual scrap location, the *Storage Locations* feature
|
||||
must first be enabled.
|
||||
|
||||
To do so, navigate to :menuselection:`Inventory app --> Configuration --> Settings`, and scroll down
|
||||
to the :guilabel:`Warehouse` section. Tick the checkbox next to :guilabel:`Storage Locations` to
|
||||
enable the feature, and click :guilabel:`Save`.
|
||||
|
||||
.. image:: scrap_inventory/scrap-inventory-enabled-setting.png
|
||||
:align: center
|
||||
:alt: Enabled Storage Locations setting in Inventory app settings.
|
||||
:ref:`location types <inventory/warehouses_storage/location-type>`.
|
||||
|
||||
Scrap from stock
|
||||
================
|
||||
|
||||
@@ -2,66 +2,71 @@
|
||||
Locations
|
||||
=========
|
||||
|
||||
In Odoo *Inventory*, a *location* is a specific space within a warehouse. This can be a shelf, room,
|
||||
aisle, rack, bin, etc.
|
||||
|
||||
There are also external and virtual locations. For example, customer locations, and locations
|
||||
specifically designated as "virtual", instead of real, physical locations.
|
||||
|
||||
Locations allow for the storage of products in designated areas of the warehouse, to help track
|
||||
inventory accurately.
|
||||
A *location* is a specific space within a warehouse. This can be a shelf, room, aisle, etc.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
To specify storage locations, the *Storage Locations* setting must be enabled. To do so, navigate to
|
||||
:menuselection:`Inventory app --> Configuration --> Settings`, and scroll down to the
|
||||
:guilabel:`Warehouse` section. Tick the checkbox next to :guilabel:`Storage Locations` to enable the
|
||||
feature, and click :guilabel:`Save`.
|
||||
To create specific storage locations, enable the *Storage Locations* feature by going to
|
||||
:menuselection:`Inventory app --> Configuration --> Settings`. In the :guilabel:`Warehouses`
|
||||
section, tick the :guilabel:`Storage Locations` checkbox. Then, click :guilabel:`Save`.
|
||||
|
||||
.. image:: use_locations/use-locations-enabled-setting.png
|
||||
.. note::
|
||||
Typically, the :guilabel:`Storage Locations` feature is used with :doc:`Multi-Step Routes
|
||||
<use_routes>`, which controls how products move between locations.
|
||||
|
||||
.. image:: use_locations/enable-location.png
|
||||
:align: center
|
||||
:alt: Enabled Storage Location setting in Inventory app settings.
|
||||
:alt: Show Storage Locations feature.
|
||||
|
||||
Once the :guilabel:`Storage Locations` feature is enabled, two additional internal link options
|
||||
appear below it: :guilabel:`Locations` and :guilabel:`Putaway Rules`. Click :guilabel:`Locations` to
|
||||
open a list of all existing locations in the warehouse.
|
||||
Create new location
|
||||
===================
|
||||
|
||||
Create a new location inside a warehouse
|
||||
========================================
|
||||
After enabling *Storage Locations*, go to :menuselection:`Inventory app --> Configuration -->
|
||||
Locations`.
|
||||
|
||||
To create a new location inside a warehouse, navigate to :menuselection:`Inventory app -->
|
||||
Configuration --> Locations`. Doing so opens a list of all existing locations. Click :guilabel:`New`
|
||||
to open a new location creation form.
|
||||
.. image:: use_locations/locations.png
|
||||
:align: center
|
||||
:alt: List of internal locations.
|
||||
|
||||
In the :guilabel:`Location Name` field, assign a name for the new location. In the :guilabel:`Parent
|
||||
Location` field, assign the location that this new location exists in.
|
||||
On this page, click :guilabel:`New`. The new location form can then be configured as follows:
|
||||
|
||||
.. example::
|
||||
A new location `Gate 1` is created. Its parent location is `Dispatch Zone`. In the
|
||||
:guilabel:`Parent Location` for `Gate 1`, select `Dispatch Zone`.
|
||||
- :guilabel:`Location Name`: recognizable name of the location.
|
||||
- :guilabel:`Parent Location`: the location within which the new location exists. After the location
|
||||
is created, it is listed on the :guilabel:`Locations` page using a *location hierarchy*, to
|
||||
describe how a specific location fits within larger areas of the warehouse.
|
||||
|
||||
In the :guilabel:`Additional Information` section, fill out the necessary details for the new
|
||||
location.
|
||||
.. example::
|
||||
In `WH/Stock/Zone A/Refrigerator 1`, "Refrigerator 1" is the location name, "Zone A" is the
|
||||
parent location, and everything before it is the path showing where this spot is within the
|
||||
warehouse.
|
||||
|
||||
In the :guilabel:`Location Type` field, select which type of location this is. There are seven
|
||||
different types of locations to choose from:
|
||||
Additional Information section
|
||||
------------------------------
|
||||
|
||||
- :guilabel:`Vendor Location`: virtual location representing the source location for products coming
|
||||
from vendors.
|
||||
- :guilabel:`View`: virtual location used to create a hierarchical structure for a warehouse;
|
||||
aggregates its child locations. **Should not directly contain products**.
|
||||
- :guilabel:`Internal Location`: physical location inside a warehouse.
|
||||
- :guilabel:`Customer Location`: virtual location representing the destination location for products
|
||||
sent to customers.
|
||||
- :guilabel:`Inventory Loss`: virtual location serving as a counterpart for inventory operations.
|
||||
Used to correct stock levels of physical inventory.
|
||||
- :guilabel:`Production`: virtual counterpart location for production operations. This location
|
||||
consumes components and produces finished products.
|
||||
- :guilabel:`Transit Location`: counterpart location that should be used in inter-company or
|
||||
inter-warehouse operations.
|
||||
In addition to the required fields above, configure the following location fields to ensure the
|
||||
location serves its intended purpose in the database:
|
||||
|
||||
.. image:: use_locations/use-locations-new-location-form.png
|
||||
- :guilabel:`Location Type`: from the drop-down menu, choose :guilabel:`Vendor Location`,
|
||||
:guilabel:`View`, :guilabel:`Internal Location`, :guilabel:`Customer Location`,
|
||||
:guilabel:`Inventory Loss`, :guilabel:`Production`, or :guilabel:`Transit Location` to categorize
|
||||
the location. For details on each location type, refer to the :ref:`Location Types section
|
||||
<inventory/warehouses_storage/location-type>`.
|
||||
- :guilabel:`Storage Category`: only available with the :ref:`Storage Categories
|
||||
<inventory/warehouses_storage/storage-category>` feature enabled in :menuselection:`Inventory app
|
||||
--> Configuration --> Settings`.
|
||||
- :guilabel:`Company`: the company the location belongs to.
|
||||
- :guilabel:`Is a Scrap Location?`: tick this checkbox to allow for scrapped/damaged goods to be
|
||||
stored in this location.
|
||||
- :guilabel:`Is a Return Location?`: tick this checkbox to allow products to be returned to this
|
||||
location.
|
||||
- :guilabel:`Barcode`: used with the *Barcode* app, enter the barcode to :ref:`identify actions
|
||||
<barcode/setup/location>` at this location when scanned.
|
||||
- :guilabel:`Replenish Location`: used for :doc:`configuring routes <use_routes>`, tick this
|
||||
checkbox to set the location as a destination for receiving products from *Buy*, *Manufacture*, or
|
||||
other procurement routes, ensuring products are correctly supplied to the warehouse.
|
||||
|
||||
.. image:: use_locations/new-location.png
|
||||
:align: center
|
||||
:alt: Additional Information section of new location creation form.
|
||||
|
||||
@@ -93,26 +98,50 @@ from this location.
|
||||
|
||||
.. _inventory/location-hierarchy:
|
||||
|
||||
Create location hierarchies
|
||||
===========================
|
||||
Cyclic Counting section
|
||||
-----------------------
|
||||
|
||||
The *Parent Location* setting on the new location form allows for a location to exist within a
|
||||
warehouse, or below another location.
|
||||
To schedule regular inventory counts at this location, set the :guilabel:`Inventory Frequency
|
||||
(Days)` field to the desired interval. By default, it is set to `0` (no scheduled counts).
|
||||
|
||||
Every location can serve as a parent location, and every parent location can have multiple locations
|
||||
within it, allowing for the creation of a hierarchical structure.
|
||||
For example, setting this field to `30`, schedules a count every thirty days. For more specifics on
|
||||
setting up and using this feature, refer to the :doc:`Cycle Counts documentation <cycle_counts>`.
|
||||
|
||||
The :guilabel:`Last Effective Inventory` field displays the date the last inventory count at this
|
||||
location occurred. When scheduled inventory counts are enabled, the :guilabel:`Next Expected
|
||||
Inventory` field displays the date of the next inventory count.
|
||||
|
||||
.. example::
|
||||
Location hierarchy could be organized so that a small refrigerator is located on a specific
|
||||
shelf, which is located in the warehouse.
|
||||
With inventory counts scheduled to occur every `30` days, and the :guilabel:`Last Effective
|
||||
Inventory` count occurring on July 16, the :guilabel:`Next Expected Inventory` is August 15.
|
||||
|
||||
.. image:: use_locations/use-locations-hierarchy.png
|
||||
.. image:: use_locations/scheduled-count.png
|
||||
:align: center
|
||||
:alt: Location hierarchy of small refrigerator, on a shelf in a warehouse.
|
||||
:alt: Show Cyclic Count section of the locations form.
|
||||
|
||||
To create the location hierarchy in the example above (`WH/Stock/Shelf 2/Small Refrigerator`),
|
||||
set the warehouse stock as the parent of the shelf, and the shelf as the parent of the small
|
||||
refrigerator. This can be adapted to a hierarchy of any magnitude.
|
||||
Logistics section
|
||||
-----------------
|
||||
|
||||
In the :guilabel:`Logistics` section of the locations form, optionally select a :guilabel:`Removal
|
||||
Strategy` to determine the order and priority of how products are picked from inventory. The options
|
||||
are: :guilabel:`First In First Out (FIFO)`, :guilabel:`Last In First Out (LIFO)`, :guilabel:`Closest
|
||||
Location`, and :guilabel:`First Expiry First Out (FEFO)`.
|
||||
|
||||
.. seealso::
|
||||
:doc:`warehouses_locations`
|
||||
:doc:`../removal_strategies`
|
||||
|
||||
Current stock at location
|
||||
=========================
|
||||
|
||||
To view the current stock at a single location, go to :menuselection:`Inventory app -->
|
||||
Configuration --> Locations`, and select the desired location.
|
||||
|
||||
Next, click the :guilabel:`Current Stock` smart button to get a list of all products at the
|
||||
location.
|
||||
|
||||
.. example::
|
||||
A list of current stock at `Shelf 1` consists of `266` cabinets and `39` desks.
|
||||
|
||||
.. image:: use_locations/current-stock.png
|
||||
:align: center
|
||||
:alt: Show stock at Shelf 1.
|
||||
|
||||
|
After Width: | Height: | Size: 9.6 KiB |
|
After Width: | Height: | Size: 5.8 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 5.2 KiB |
@@ -0,0 +1,73 @@
|
||||
==========
|
||||
Warehouses
|
||||
==========
|
||||
|
||||
In the Odoo *Inventory* app, a *warehouse* is a physical space with an address for storing items,
|
||||
such as a storage facility, distribution center, or physical store.
|
||||
|
||||
Each database has a pre-configured warehouse with the company's address. Users can set up multiple
|
||||
warehouses, and :doc:`create stock moves <use_routes>` between them.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
To create or manage warehouses, go to :menuselection:`Inventory app --> Configuration -->
|
||||
Warehouses`.
|
||||
|
||||
Then, select an existing warehouse, or create a new one by clicking :guilabel:`New`. Doing so opens
|
||||
the warehouse form, which contains the following fields:
|
||||
|
||||
- :guilabel:`Warehouse` (*required field*): the full name of the warehouse.
|
||||
- :guilabel:`Short Name` (*required field*): the abbreviated code for the warehouse (maximum five
|
||||
characters). The short name for the default warehouse in Odoo is `WH`.
|
||||
|
||||
.. important::
|
||||
The :guilabel:`Short Name` appears on warehouse documents, so it is recommended to use an
|
||||
memorable one, like "WH[first letters of location]" (e.g. `WHA`, `WHB`, etc.).
|
||||
|
||||
- :guilabel:`Address` (*required field*): the address of the warehouse. To change the warehouse
|
||||
address when creating two or more warehouses, hover over the field, and click the
|
||||
:icon:`fa-arrow-right` :guilabel:`(right arrow)`.
|
||||
- :guilabel:`Company` (*required field*): 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:`Intrastat region`: :doc:`region name
|
||||
<../../../../finance/accounting/reporting/intrastat>` required for companies in the European
|
||||
Union.
|
||||
|
||||
.. important::
|
||||
The options below are available **only** when the *Multi-Step Routes* feature is enabled in
|
||||
:menuselection:`Inventory app --> Configuration --> Settings`.
|
||||
|
||||
- :guilabel:`Incoming Shipments`: select the option to receive products from the warehouse in
|
||||
:doc:`one <../../shipping_receiving/daily_operations/receipts_delivery_one_step>`, :doc:`two
|
||||
<../../shipping_receiving/daily_operations/receipts_delivery_two_steps>`, or :doc:`three
|
||||
<../../shipping_receiving/daily_operations/receipts_three_steps>` steps.
|
||||
|
||||
- :guilabel:`Outgoing Shipments`: select the option to deliver products from the warehouse in
|
||||
:doc:`one <../../shipping_receiving/daily_operations/receipts_delivery_one_step>`, :doc:`two
|
||||
<../../shipping_receiving/daily_operations/receipts_delivery_two_steps>`, or :doc:`three
|
||||
<../../shipping_receiving/daily_operations/delivery_three_steps>` steps.
|
||||
|
||||
- :guilabel:`Dropship Subcontractors`: available with the *Subcontracting* feature enabled in
|
||||
:menuselection:`Manufacturing app --> Configuration --> Settings`. Tick this checkbox to purchase
|
||||
components from vendors, and dropship them to subcontractors.
|
||||
- :guilabel:`Resupply Subcontractors`: available with the *Subcontracting* feature, tick this
|
||||
checkbox to supply subcontractors with raw materials stored in *this* specific warehouse.
|
||||
- :guilabel:`Manufacture to Resupply`: tick this checkbox to allow for items to be manufactured in
|
||||
this warehouse.
|
||||
- :guilabel:`Manufacture`: choose whether to manufacture products in :doc:`one
|
||||
<../../../manufacturing/basic_setup/one_step_manufacturing>`, :doc:`two
|
||||
<../../../manufacturing/basic_setup/two_step_manufacturing>`, or :doc:`three steps
|
||||
<../../../manufacturing/basic_setup/three_step_manufacturing>`.
|
||||
- :guilabel:`Buy to Resupply`: tick this checkbox to allow for purchased products to be delivered to
|
||||
the warehouse.
|
||||
- :guilabel:`Resupply From`: available with multiple warehouses in the database, select warehouses
|
||||
to pull stock *from* to fulfill orders.
|
||||
|
||||
.. seealso::
|
||||
:doc:`Use inventory adjustments to add stock to new warehouses <count_products>`
|
||||
|
||||
.. image:: warehouses/warehouse-form.png
|
||||
:align: center
|
||||
:alt: Example warehouse form.
|
||||
|
||||
|
After Width: | Height: | Size: 22 KiB |
@@ -1,115 +0,0 @@
|
||||
===============================
|
||||
Manage warehouses and locations
|
||||
===============================
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
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.
|
||||
|
||||
Multiple warehouses can be set up in Odoo, and stock moves can be created between warehouses.
|
||||
|
||||
.. _inventory/warehouses_storage/difference-warehouse-location:
|
||||
|
||||
Location
|
||||
--------
|
||||
|
||||
In Odoo *Inventory*, a *location* is a specific space within a warehouse. This can be a shelf, room,
|
||||
aisle, rack, bin, etc. Locations allow for the storage of products in designated areas of the
|
||||
warehouse, to help track inventory accurately.
|
||||
|
||||
A location is only part of *one* warehouse, and can **not** be linked to multiple warehouses. As
|
||||
many locations can be configured as needed under one warehouse.
|
||||
|
||||
There are three types of locations in Odoo *Inventory*:
|
||||
|
||||
- **Physical Locations**: internal locations within a single warehouse owned by the company. This
|
||||
can include shipping and loading docks, aisles, shelves, storage areas, and more.
|
||||
- **Partner Locations**: external locations, such as designated spaces in a customer or vendor's
|
||||
warehouse. They are similar to physical locations, but they are **not** owned by the user's
|
||||
company.
|
||||
- **Virtual Locations**: this type of location does not exist as a physical space, but products can
|
||||
be "stored" here when they are not physically in an inventory yet. *Inventory Loss* and
|
||||
*Procurements* are examples of virtual locations, for products that are lost or in transit to the
|
||||
warehouse.
|
||||
|
||||
Every location within a warehouse can serve as a parent location, and every parent location can have
|
||||
multiple locations within it, allowing for the creation of a hierarchical structure. This allows for
|
||||
more detailed levels of analysis of the stock operations and the organization of the warehouses.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
For companies with one warehouse, no additional settings are required to activate before editing the
|
||||
warehouse.
|
||||
|
||||
For companies with multiple warehouses, and to create locations within a warehouse, the *Storage
|
||||
Locations* feature must be enabled.
|
||||
|
||||
To do so, navigate to :menuselection:`Inventory app --> Configuration --> Settings`, and scroll down
|
||||
to the :guilabel:`Warehouse` section. Tick the :guilabel:`Storage Locations` checkbox to enable the
|
||||
feature, and click :guilabel:`Save`.
|
||||
|
||||
.. image:: warehouses_locations/warehouses-locations-enabled-setting.png
|
||||
:align: center
|
||||
:alt: Storage Locations feature enabled in the Inventory app settings.
|
||||
|
||||
.. tip::
|
||||
To manage warehouse *routes*, such as two-and-three-step receipts and deliveries, enable the
|
||||
*Multi-Step Routes* feature from the *Inventory* app settings, as well. For more on routes, see
|
||||
:doc:`use_routes`.
|
||||
|
||||
Create a 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.
|
||||
|
||||
Begin by assigning a :guilabel:`Warehouse Name`, and a :guilabel:`Short Name`. The :guilabel:`Short
|
||||
Name` field is limited to a **five** character maximum.
|
||||
|
||||
.. image:: warehouses_locations/warehouses-locations-new-warehouse.png
|
||||
:align: center
|
||||
:alt: New warehouse creation form name configuration fields.
|
||||
|
||||
.. important::
|
||||
The :guilabel:`Short Name` appears on transfer orders and other warehouse documents. Odoo
|
||||
recommends using an understandable one like `WH/[first letters of location]`.
|
||||
|
||||
For example, a warehouse named `Warehouse #2` might have the :guilabel:`Short Name` `WH2` (the
|
||||
short name for the default warehouse in Odoo is `WH`).
|
||||
|
||||
Once the warehouse is created, navigate back to the :menuselection:`Inventory` dashboard. New
|
||||
operations for the newly created warehouse are automatically generated there.
|
||||
|
||||
For more on creating new warehouses, see :doc:`create_a_second_warehouse`.
|
||||
|
||||
.. image:: warehouses_locations/warehouses-locations-new-wh-operations.png
|
||||
:align: center
|
||||
:alt: Inventory app dashboard displaying new transfers for the new warehouse.
|
||||
|
||||
.. 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 a new location
|
||||
=====================
|
||||
|
||||
To create a new location inside a warehouse, navigate to :menuselection:`Inventory app -->
|
||||
Configuration --> Locations`. Doing so opens a list of all existing locations. Click :guilabel:`New`
|
||||
to open a new location creation form.
|
||||
|
||||
In the :guilabel:`Location Name` field, assign a name for the new location. In the :guilabel:`Parent
|
||||
Location` field, assign the location that this new location exists in.
|
||||
|
||||
For more on locations, see :doc:`use_locations`.
|
||||
|
||||
.. image:: warehouses_locations/warehouses-locations-new-location.png
|
||||
:align: center
|
||||
:alt: New warehouse location creation form.
|
||||
|
Before Width: | Height: | Size: 26 KiB |
|
Before Width: | Height: | Size: 77 KiB |
|
Before Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 34 KiB |
@@ -27,12 +27,18 @@ valuation updates in the *Inventory* app. For an introduction of inventory valua
|
||||
to the :doc:`using_inventory_valuation` documentation.
|
||||
|
||||
.. warning::
|
||||
Switching to automatic inventory valuation **does not** create journal entries for existing
|
||||
stock, potentially leading to discrepancies between stock valuation and accounting journals.
|
||||
Switching from manual to automatic inventory valuation may cause discrepancies between stock
|
||||
valuation and accounting journals.
|
||||
|
||||
To manually post journal entries for existing stock, navigate to :menuselection:`Inventory app
|
||||
--> Reporting --> Valuation` for a list of current stock and its value. Then, :doc:`post a
|
||||
journal entry <../../../../finance/accounting/vendor_bills>` for each existing item.
|
||||
One `successful strategy <https://www.odoo.com/r/Kvfg>`_ for switching to automated valuation:
|
||||
|
||||
#. Clear existing stock (possibly with an :doc:`inventory adjustment
|
||||
<../inventory_management/count_products>`)
|
||||
#. Change the inventory valuation method to *Automatic*
|
||||
#. Return the existing stock, with the original monetary value (using an inventory adjustment)
|
||||
|
||||
Once the existing stock is recovered, the Odoo *Accounting* app automatically generates the
|
||||
journal entries to corresponding stock valuation records.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
@@ -24,8 +24,7 @@ and :guilabel:`Category`, which shows products within a selected product categor
|
||||
|
||||
.. note::
|
||||
The :guilabel:`Warehouse` grouping is only available when there are multiple warehouses in the
|
||||
database. Refer to the :doc:`../inventory_management/create_a_second_warehouse` documentation for
|
||||
more details.
|
||||
database. Refer to the :doc:`../inventory_management/warehouses` documentation for more details.
|
||||
|
||||
In the report itself, the columns represent:
|
||||
|
||||
|
||||