[FIX] *: first small clean of the code
Friday afternoon cleanup. This is required so we can use "make test", as
there are currently hundreds of errors. For now, it is unusable because
of the oldest code in this repo.
closes odoo/documentation#3544
X-original-commit: 26ddeef42c
Signed-off-by: Castillo Jonathan (jcs) <jcs@odoo.com>
This commit is contained in:
parent
772a56a693
commit
fd25400847
@ -1,8 +1,8 @@
|
||||
:nosearch:
|
||||
|
||||
=================
|
||||
========
|
||||
Advanced
|
||||
=================
|
||||
========
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
@ -1,7 +1,7 @@
|
||||
|
||||
==================================
|
||||
==========
|
||||
Containers
|
||||
==================================
|
||||
==========
|
||||
|
||||
Overview
|
||||
========
|
||||
|
@ -1,9 +1,9 @@
|
||||
|
||||
.. _odoosh-advanced-frequent_technical_questions:
|
||||
|
||||
==================================
|
||||
============================
|
||||
Frequent Technical Questions
|
||||
==================================
|
||||
============================
|
||||
|
||||
"Scheduled actions do not run at the exact time they were expected"
|
||||
-------------------------------------------------------------------
|
||||
|
@ -1,9 +1,9 @@
|
||||
|
||||
.. _odoosh-advanced-submodules:
|
||||
|
||||
==================================
|
||||
==========
|
||||
Submodules
|
||||
==================================
|
||||
==========
|
||||
|
||||
Overview
|
||||
========
|
||||
@ -64,7 +64,7 @@ On Github, you can get the repository URL with the *Clone or download* button of
|
||||
.. _odoosh-advanced-submodules-withgit:
|
||||
|
||||
With Git (advanced)
|
||||
---------------------
|
||||
-------------------
|
||||
|
||||
In a terminal, in the folder where your Git repository is cloned,
|
||||
checkout the branch in which you want to add a submodule:
|
||||
|
@ -1,8 +1,8 @@
|
||||
:nosearch:
|
||||
|
||||
=================
|
||||
===========
|
||||
Get started
|
||||
=================
|
||||
===========
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
@ -1,7 +1,6 @@
|
||||
|
||||
==================================
|
||||
========
|
||||
Branches
|
||||
==================================
|
||||
========
|
||||
|
||||
Overview
|
||||
========
|
||||
@ -14,7 +13,7 @@ The branches view gives you an overview of the different branches your repositor
|
||||
.. _odoosh-gettingstarted-branches-stages:
|
||||
|
||||
Stages
|
||||
===============
|
||||
======
|
||||
|
||||
Odoo.sh offers three different stages for your branches: production, staging and development.
|
||||
|
||||
@ -27,6 +26,7 @@ You can change the stage of a branch by drag and dropping it into the stage sect
|
||||
|
||||
Production
|
||||
----------
|
||||
|
||||
This is the branch holding the code on which your production database runs.
|
||||
There can be only one production branch.
|
||||
|
||||
@ -59,6 +59,7 @@ will automatically be set back to the development stage after 30 days.
|
||||
|
||||
Staging
|
||||
-------
|
||||
|
||||
Staging branches are meant to test your new features using the production data without compromising
|
||||
the actual production database with test records. They will create databases that are neutralized
|
||||
duplicates of the production database.
|
||||
@ -83,9 +84,9 @@ The unit tests are not performed as, in Odoo, they currently rely on the demo da
|
||||
production database. In the future, if Odoo supports to run the unit tests without the demo data,
|
||||
Odoo.sh will then consider running the tests on staging databases.
|
||||
|
||||
|
||||
Development
|
||||
-----------
|
||||
|
||||
Development branches create new databases using the demo data to run the unit tests.
|
||||
The installed modules are the ones included in your branches. You can change this list of modules
|
||||
to install in your :ref:`project Settings <odoosh-gettingstarted-settings-modules-installation>`.
|
||||
@ -107,6 +108,7 @@ After that, they can be automatically garbage collected to make room for new dat
|
||||
|
||||
Merging your branches
|
||||
---------------------
|
||||
|
||||
You can merge your branches easily by drag and dropping them into each other.
|
||||
|
||||
.. image:: branches/interface-branches-merge.png
|
||||
@ -147,10 +149,11 @@ If you test configuration changes in staging branches, and want them to be appli
|
||||
.. _odoosh-gettingstarted-branches-tabs:
|
||||
|
||||
Tabs
|
||||
=============
|
||||
====
|
||||
|
||||
History
|
||||
-------
|
||||
|
||||
An overview of your branch history:
|
||||
|
||||
* The messages of the commits and their authors,
|
||||
@ -168,6 +171,7 @@ When an operation is successful, you can access the database thanks to the *conn
|
||||
|
||||
Mails
|
||||
-----
|
||||
|
||||
This tab contains the mail catcher. It displays an overview of the emails sent by your database.
|
||||
The mail catcher is available for your development and
|
||||
staging branches as the emails of your production database are really sent instead of being intercepted.
|
||||
@ -178,6 +182,7 @@ staging branches as the emails of your production database are really sent inste
|
||||
|
||||
Shell
|
||||
-----
|
||||
|
||||
A shell access to your container. You can perform basic linux commands (:code:`ls`, :code:`top`)
|
||||
and open a shell on your database by typing :code:`psql`.
|
||||
|
||||
@ -187,13 +192,13 @@ and open a shell on your database by typing :code:`psql`.
|
||||
You can open multiple tabs and drag-and-drop them to arrange the layout as you wish,
|
||||
for instance side by side.
|
||||
|
||||
|
||||
.. Note::
|
||||
Long running shell instances are not guaranteed. Idle shells can be
|
||||
disconnected at anytime in order to free up resources.
|
||||
|
||||
Editor
|
||||
------
|
||||
|
||||
An online integrated development environment (IDE) to edit the source code.
|
||||
You can also open terminals, Python consoles and even Odoo Shell consoles.
|
||||
|
||||
@ -205,6 +210,7 @@ for instance side by side.
|
||||
|
||||
Monitoring
|
||||
----------
|
||||
|
||||
This link contains various monitoring metrics of the current build.
|
||||
|
||||
.. image:: branches/interface-branches-monitoring.png
|
||||
@ -217,6 +223,7 @@ On the graphs, annotations help you relate to changes on the build (database imp
|
||||
|
||||
Logs
|
||||
----
|
||||
|
||||
A viewer to have a look to your server logs.
|
||||
|
||||
.. image:: branches/interface-branches-logs.png
|
||||
@ -240,6 +247,7 @@ The fetching is automatically stopped after 5 minutes. You can restart it using
|
||||
|
||||
Backups
|
||||
-------
|
||||
|
||||
A list of the backups available for download and restore, the ability to perform a manual backup and to import a
|
||||
database.
|
||||
|
||||
@ -398,14 +406,13 @@ settings to increase the deliverability of your outgoing emails.
|
||||
The configuration steps are explained in the documentation about :ref:`SPF
|
||||
<email_communication/spf_compliant>` and :ref:`DKIM <email_communication/dkim_compliant>`.
|
||||
|
||||
|
||||
.. Warning::
|
||||
Forgetting to configure your SPF or DKIM to authorize Odoo as a sending host can lead to the
|
||||
delivery of your emails as spam in your contacts inbox.
|
||||
|
||||
|
||||
Shell commands
|
||||
==============
|
||||
|
||||
In the top right-hand corner of the view, different shell commands are available.
|
||||
|
||||
.. image:: branches/interface-branches-shellcommands.png
|
||||
@ -418,6 +425,7 @@ such as ``<URL>``, ``<PATH>``, ...
|
||||
|
||||
Clone
|
||||
-----
|
||||
|
||||
Download the Git repository.
|
||||
|
||||
.. code-block:: bash
|
||||
@ -433,6 +441,7 @@ The *run* button is not available for this command, as it is meant to be used on
|
||||
|
||||
Fork
|
||||
----
|
||||
|
||||
Create a new branch based on the current branch.
|
||||
|
||||
.. code-block:: bash
|
||||
@ -449,6 +458,7 @@ Uploads the new branch *feature-1* on your remote repository.
|
||||
|
||||
Merge
|
||||
-----
|
||||
|
||||
Merge the current branch in another branch.
|
||||
|
||||
.. code-block:: bash
|
||||
@ -465,8 +475,10 @@ Uploads the changes you just added in the *master* branch on your remote reposit
|
||||
|
||||
SSH
|
||||
---
|
||||
|
||||
Setup
|
||||
~~~~~
|
||||
|
||||
In order to use SSH, you have to set up your profile SSH public key (if it is not already done).
|
||||
To do so, follow these steps:
|
||||
|
||||
@ -506,7 +518,6 @@ you'll be granted ssh access to the build.
|
||||
Long running ssh connections are not guaranteed. Idle connections will be
|
||||
disconnected in order to free up resources.
|
||||
|
||||
|
||||
Submodule
|
||||
---------
|
||||
|
||||
|
@ -1,17 +1,18 @@
|
||||
|
||||
.. _odoosh-gettingstarted-builds:
|
||||
|
||||
==================================
|
||||
======
|
||||
Builds
|
||||
==================================
|
||||
======
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
In Odoo.sh, a build is considered as a database loaded by an Odoo server
|
||||
(`odoo/odoo <https://github.com/odoo/odoo>`_ & `odoo/enterprise <https://github.com/odoo/enterprise>`_)
|
||||
running on a specific revision of your project repository in a containerized environment.
|
||||
Its purpose is to test the well-behavior of the server, the database and the features with this revision.
|
||||
(`odoo/odoo <https://github.com/odoo/odoo>`_ & `odoo/enterprise
|
||||
<https://github.com/odoo/enterprise>`_) running on a specific revision of your project repository in
|
||||
a containerized environment. Its purpose is to test the well-behavior of the server, the database
|
||||
and the features with this revision.
|
||||
|
||||
.. image:: builds/interface-builds.png
|
||||
:align: center
|
||||
@ -28,13 +29,13 @@ A successful build is highlighted in green.
|
||||
A build is considered failed if errors come up during its creation.
|
||||
A failed build is highlighted in red.
|
||||
|
||||
If warnings come up during the creation, but there are no errors, the build is considered almost successful.
|
||||
It is highlighted in yellow to notify the developer warnings were raised.
|
||||
If warnings come up during the creation, but there are no errors, the build is considered almost
|
||||
successful. It is highlighted in yellow to notify the developer warnings were raised.
|
||||
|
||||
Builds do not always create a database from scratch.
|
||||
For instance, when pushing a change on the production branch, the build created just starts the server
|
||||
with your new revision and tries to load the current production database on it.
|
||||
If no errors come up, the build is considered successful, and otherwise failed.
|
||||
Builds do not always create a database from scratch. For instance, when pushing a change on the
|
||||
production branch, the build created just starts the server with your new revision and tries to load
|
||||
the current production database on it. If no errors come up, the build is considered successful, and
|
||||
otherwise failed.
|
||||
|
||||
Stages
|
||||
======
|
||||
@ -48,14 +49,15 @@ If this build is successful, this database is considered as the production datab
|
||||
From then, pushes on the production branch will create new builds that attempt to load the database
|
||||
using a server running with the new revision.
|
||||
|
||||
If the build is successful, or has warnings but no errors, the production database will now run with this build, along
|
||||
with the revision associated to this build.
|
||||
If the build is successful, or has warnings but no errors, the production database will now run with
|
||||
this build, along with the revision associated to this build.
|
||||
|
||||
If the build fails to load or update the database, then the previous successful build is re-used to load the database,
|
||||
and therefore the database will run using a server running with the previous successful revision.
|
||||
If the build fails to load or update the database, then the previous successful build is re-used to
|
||||
load the database, and therefore the database will run using a server running with the previous
|
||||
successful revision.
|
||||
|
||||
The build used to run the production database is always the first of the builds list. If a build fails, it is
|
||||
put after the build currently running the production database.
|
||||
The build used to run the production database is always the first of the builds list. If a build
|
||||
fails, it is put after the build currently running the production database.
|
||||
|
||||
Staging
|
||||
-------
|
||||
@ -63,18 +65,17 @@ Staging
|
||||
Staging builds duplicate the production database,
|
||||
and try to load this duplicate with the revisions of the staging branches.
|
||||
|
||||
Each time you push a new revision on a staging branch, the build created uses a new copy of the production database.
|
||||
The databases are not re-used between builds of the same branch. This ensures:
|
||||
Each time you push a new revision on a staging branch, the build created uses a new copy of the
|
||||
production database. The databases are not re-used between builds of the same branch. This ensures:
|
||||
|
||||
* staging builds use databases that are close to what the production looks like,
|
||||
so you do not make your tests with outdated data,
|
||||
* staging builds use databases that are close to what the production looks like, so you do not make
|
||||
your tests with outdated data,
|
||||
|
||||
* you can play around as much as you want in the same staging database,
|
||||
and you can then ask for a rebuild when you want to restart with a new copy of the production.
|
||||
* you can play around as much as you want in the same staging database, and you can then ask for a
|
||||
rebuild when you want to restart with a new copy of the production.
|
||||
|
||||
Nevertheless, this means that if you make configuration changes in staging databases
|
||||
and do not apply them in the production,
|
||||
they will not be passed on the next build of the same staging branch.
|
||||
Nevertheless, this means that if you make configuration changes in staging databases and do not
|
||||
apply them in the production, they will not be passed on the next build of the same staging branch.
|
||||
|
||||
Development
|
||||
-----------
|
||||
@ -86,30 +87,30 @@ as they are meant to raise errors if something wrong occurs.
|
||||
|
||||
If all tests pass, and there is no error, the build will be considered successful.
|
||||
|
||||
According to the list of modules to install and test, a development build can take up to 1 hour to be ready.
|
||||
This is due to the large number of tests set in the default Odoo modules suite.
|
||||
According to the list of modules to install and test, a development build can take up to 1 hour to
|
||||
be ready. This is due to the large number of tests set in the default Odoo modules suite.
|
||||
|
||||
Features
|
||||
========
|
||||
|
||||
The production branch will always appear first,
|
||||
and then the other branches are ordered by last build created. You can filter out the branches.
|
||||
The production branch will always appear first, and then the other branches are ordered by last
|
||||
build created. You can filter out the branches.
|
||||
|
||||
.. image:: builds/interface-builds-branches.png
|
||||
:align: center
|
||||
|
||||
For each branch, you can access the last build's database using the *Connect* link and jump to the branch code using
|
||||
the *Github* link. For other branches than the production, you can create a new build which will use the latest revision
|
||||
of the branch using the link *rebuild*. This last link is not available when there is already a build in progress for
|
||||
the branch.
|
||||
For each branch, you can access the last build's database using the *Connect* link and jump to the
|
||||
branch code using the *Github* link. For other branches than the production, you can create a new
|
||||
build which will use the latest revision of the branch using the link *rebuild*. This last link is
|
||||
not available when there is already a build in progress for the branch.
|
||||
|
||||
.. image:: builds/interface-builds-build.png
|
||||
:align: center
|
||||
|
||||
For each build, you can access the revision changes using the button with the Github icon.
|
||||
You can access the build's database as the administrator using the *Connect* button.
|
||||
Also, you can access the database with another user using the *Connect as* button,
|
||||
in the dropdown menu of the *Connect* button.
|
||||
For each build, you can access the revision changes using the button with the Github icon. You can
|
||||
access the build's database as the administrator using the *Connect* button. Also, you can access
|
||||
the database with another user using the *Connect as* button, in the dropdown menu of the *Connect*
|
||||
button.
|
||||
|
||||
.. _odoosh-gettingstarted-builds-download-dump:
|
||||
|
||||
@ -118,6 +119,6 @@ in the dropdown menu of the *Connect* button.
|
||||
|
||||
.. _odoosh-gettingstarted-builds-dropdown-menu:
|
||||
|
||||
In the dropdown menu of the build, you can access the same features than in :ref:`the branches view <odoosh-gettingstarted-branches-tabs>`:
|
||||
*Logs*, *Web Shell*, *Editor*, *Outgoing e-mails*.
|
||||
You also have the possibility to *Download a dump* of the build's database.
|
||||
In the dropdown menu of the build, you can access the same features than in :ref:`the branches view
|
||||
<odoosh-gettingstarted-branches-tabs>`: *Logs*, *Web Shell*, *Editor*, *Outgoing e-mails*. You also
|
||||
have the possibility to *Download a dump* of the build's database.
|
||||
|
@ -1,9 +1,9 @@
|
||||
|
||||
.. _odoosh-gettingstarted-create:
|
||||
|
||||
==================================
|
||||
===================
|
||||
Create your project
|
||||
==================================
|
||||
===================
|
||||
|
||||
Deploy your platform
|
||||
====================
|
||||
@ -16,7 +16,8 @@ Go to `Odoo.sh <https://www.odoo.sh/>`_ and hit the *Deploy your platform* butto
|
||||
Sign in with Github
|
||||
===================
|
||||
|
||||
Sign in with your Github account. If you do not have an account yet, hit the *Create an account* link.
|
||||
Sign in with your Github account. If you do not have an account yet, hit the *Create an account*
|
||||
link.
|
||||
|
||||
.. image:: create/github-signin.png
|
||||
:align: center
|
||||
@ -33,34 +34,44 @@ Odoo.sh basically needs:
|
||||
|
||||
* to know your Github login and email,
|
||||
* to create a new repository in case you decide to start from scratch,
|
||||
* to read your existing repositories, including the ones of your organizations, in case you want to start from an existing repository,
|
||||
* to read your existing repositories, including the ones of your organizations, in case you want to
|
||||
start from an existing repository,
|
||||
* to create a webhook to be notified each time you push changes,
|
||||
* to commit changes to make your deployment easier, merging branches or adding new `submodules <https://git-scm.com/book/en/v2/Git-Tools-Submodules>`_ for example.
|
||||
* to commit changes to make your deployment easier, merging branches or adding new `submodules
|
||||
<https://git-scm.com/book/en/v2/Git-Tools-Submodules>`_ for example.
|
||||
|
||||
Submit your project
|
||||
===================
|
||||
|
||||
Choose if you want to start from scratch by creating a new repository, or if you want to use an existing repository.
|
||||
Choose if you want to start from scratch by creating a new repository, or if you want to use an
|
||||
existing repository.
|
||||
|
||||
Then, choose a name or select the repository you want to use.
|
||||
|
||||
Choose the Odoo version you want to use. If you plan to import an existing database or an existing set of applications, you might need to choose the according version. If you start from scratch, use the latest version.
|
||||
Choose the Odoo version you want to use. If you plan to import an existing database or an existing
|
||||
set of applications, you might need to choose the according version. If you start from scratch, use
|
||||
the latest version.
|
||||
|
||||
Enter your *subscription code*. This is also called *subscription referral*, *contract number* or *activation code*.
|
||||
Enter your *subscription code*. This is also called *subscription referral*, *contract number* or
|
||||
*activation code*.
|
||||
|
||||
It should be the code of your Enterprise subscription that includes Odoo.sh.
|
||||
|
||||
Partners can use their partnership codes to start a trial. Should their clients start a project, they ought to get an Enterprise subscription including Odoo.sh and use its subscription code. The partner will get the full amount as back commission.
|
||||
Contact your sales representative or account manager in order to get it.
|
||||
Partners can use their partnership codes to start a trial. Should their clients start a project,
|
||||
they ought to get an Enterprise subscription including Odoo.sh and use its subscription code. The
|
||||
partner will get the full amount as back commission. Contact your sales representative or account
|
||||
manager in order to get it.
|
||||
|
||||
When submitting the form, if you are notified your subscription is not valid, it either means:
|
||||
|
||||
* it is not an existing subscription,
|
||||
* it is not a partnership subscription,
|
||||
* it is an enterprise subscription, but which does not include Odoo.sh,
|
||||
* it is neither a partnership subscription or an enterprise subscription (e.g. an online subscription).
|
||||
* it is neither a partnership subscription or an enterprise subscription (e.g. an online
|
||||
subscription).
|
||||
|
||||
In case of doubt with your subscription, please contact the `Odoo support <https://www.odoo.com/help>`_.
|
||||
In case of doubt with your subscription, please contact the `Odoo support
|
||||
<https://www.odoo.com/help>`_.
|
||||
|
||||
.. image:: create/deploy-form.png
|
||||
:align: center
|
||||
@ -68,7 +79,8 @@ In case of doubt with your subscription, please contact the `Odoo support <https
|
||||
You're done !
|
||||
=============
|
||||
|
||||
You can start using Odoo.sh. Your first build is about to be created. You will soon be able to connect to your first database.
|
||||
You can start using Odoo.sh. Your first build is about to be created. You will soon be able to
|
||||
connect to your first database.
|
||||
|
||||
.. image:: create/deploy-done.png
|
||||
:align: center
|
||||
@ -88,9 +100,10 @@ If you use community or custom modules, add them in a branch in your Github repo
|
||||
Databases hosted on the Odoo.com online platform do not have any custom modules.
|
||||
Users of these databases can therefore skip this step.
|
||||
|
||||
You can structure your modules as you wish, Odoo.sh will automatically detect the folders containing Odoo addons.
|
||||
For instance, you can put all your modules folder in the root directory of your repository,
|
||||
or group the modules in folders by categories that you define (accounting, project, ...).
|
||||
You can structure your modules as you wish, Odoo.sh will automatically detect the folders containing
|
||||
Odoo addons. For instance, you can put all your modules folder in the root directory of your
|
||||
repository, or group the modules in folders by categories that you define (accounting, project,
|
||||
...).
|
||||
|
||||
For community modules available in public Git repositories,
|
||||
you can also consider to add them using :ref:`Submodules <odoosh-advanced-submodules>`.
|
||||
@ -111,7 +124,8 @@ Access the URL :file:`/web/database/manager` of your on-premise database and dow
|
||||
If you cannot access the database manager, it may have been disabled by your system administrator.
|
||||
See the :ref:`database manager security documentation <db_manager_security>`.
|
||||
|
||||
You will need the master password of your database server. If you do not have it, contact your system administrator.
|
||||
You will need the master password of your database server. If you do not have it, contact your
|
||||
system administrator.
|
||||
|
||||
.. image:: create/create-import-onpremise-backup.png
|
||||
:align: center
|
||||
@ -124,10 +138,11 @@ Choose a zip including the filestore as the backup format.
|
||||
Odoo Online databases
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
`Access your databases manager <https://accounts.odoo.com/my/databases/manage>`_ and download a backup of your database.
|
||||
`Access your databases manager <https://accounts.odoo.com/my/databases/manage>`_ and download a
|
||||
backup of your database.
|
||||
|
||||
.. image:: create/create-import-online-backup.png
|
||||
:align: center
|
||||
:align: center
|
||||
|
||||
.. Warning::
|
||||
|
||||
@ -136,52 +151,55 @@ Odoo Online databases
|
||||
Upload the backup
|
||||
-----------------
|
||||
|
||||
Then, in your Odoo.sh project, in the backups tab of your production branch, import the backup you just downloaded.
|
||||
Then, in your Odoo.sh project, in the backups tab of your production branch, import the backup you
|
||||
just downloaded.
|
||||
|
||||
.. image:: create/create-import-production.png
|
||||
:align: center
|
||||
|
||||
Once the backup imported, you can access the database using the *Connect* button in the history of the branch.
|
||||
Once the backup imported, you can access the database using the *Connect* button in the history of
|
||||
the branch.
|
||||
|
||||
.. image:: create/create-import-production-done.png
|
||||
:align: center
|
||||
:align: center
|
||||
|
||||
Check your outgoing email servers
|
||||
---------------------------------
|
||||
|
||||
There is a default mail server provided with Odoo.sh.
|
||||
To use it, there must be no enabled outgoing mail server configured in your database in
|
||||
:menuselection:`Settings --> Technical --> Outgoing Mail Servers`
|
||||
(:ref:`Developer mode <developer-mode>` must be activated).
|
||||
:menuselection:`Settings --> Technical --> Outgoing Mail Servers` (:ref:`Developer mode
|
||||
<developer-mode>` must be activated).
|
||||
|
||||
After the import of your database,
|
||||
all outgoing email servers are disabled so you use the Odoo.sh email server provided by default.
|
||||
After the import of your database, all outgoing email servers are disabled so you use the Odoo.sh
|
||||
email server provided by default.
|
||||
|
||||
.. Warning::
|
||||
|
||||
Port 25 is (and will stay) closed. If you want to connect to an external SMTP server, you should use ports 465 and 587.
|
||||
.. warning::
|
||||
Port 25 is (and will stay) closed. If you want to connect to an external SMTP server, you should
|
||||
use ports 465 and 587.
|
||||
|
||||
Check your scheduled actions
|
||||
----------------------------
|
||||
|
||||
All scheduled actions are disabled after the import.
|
||||
|
||||
This is to prevent your newly imported database to perform actions that could impact your running production,
|
||||
such as sending the mails remaining in the queue, processing mass mailings, or third-party services synchronization
|
||||
(Calendars, files hosting, ...).
|
||||
This is to prevent your newly imported database to perform actions that could impact your running
|
||||
production, such as sending the mails remaining in the queue, processing mass mailings, or
|
||||
third-party services synchronization (Calendars, files hosting, ...).
|
||||
|
||||
If you plan to make the imported database your production, enable the scheduled actions you need.
|
||||
You can check what is enabled in the database of origin and enable the same actions in the imported database.
|
||||
Scheduled actions are located under :menuselection:`Settings --> Technical --> Automation --> Scheduled Actions`.
|
||||
You can check what is enabled in the database of origin and enable the same actions in the imported
|
||||
database. Scheduled actions are located under :menuselection:`Settings --> Technical --> Automation
|
||||
--> Scheduled Actions`.
|
||||
|
||||
Register your subscription
|
||||
--------------------------
|
||||
|
||||
Your subscription is unlinked after the import.
|
||||
|
||||
The imported database is considered a duplicate by default and the enterprise subscription is therefore removed,
|
||||
as you can only have one database linked per subscription.
|
||||
The imported database is considered a duplicate by default and the enterprise subscription is
|
||||
therefore removed, as you can only have one database linked per subscription.
|
||||
|
||||
If you plan to make it your production,
|
||||
unlink your former database from the subscription, and register the newly imported database.
|
||||
Read the :doc:`database registration documentation <../../maintain/on_premise>` for instructions.
|
||||
If you plan to make it your production, unlink your former database from the subscription, and
|
||||
register the newly imported database. Read the :doc:`database registration documentation
|
||||
<../../maintain/on_premise>` for instructions.
|
||||
|
@ -27,7 +27,7 @@ Create the development branch
|
||||
=============================
|
||||
|
||||
From Odoo.sh
|
||||
-------------
|
||||
------------
|
||||
|
||||
In the branches view:
|
||||
|
||||
@ -43,20 +43,18 @@ In the branches view:
|
||||
.. |pic2| image:: first_module/firstmodule-development-fork.png
|
||||
:width: 45%
|
||||
|
||||
|
||||
Once the build created, you can access the editor and browse to the folder *~/src/user* to access
|
||||
to the code of your development branch.
|
||||
|
||||
.. image:: first_module/firstmodule-development-editor.png
|
||||
:align: center
|
||||
:align: center
|
||||
|
||||
.. image:: first_module/firstmodule-development-editor-interface.png
|
||||
:align: center
|
||||
:align: center
|
||||
|
||||
From your computer
|
||||
------------------
|
||||
|
||||
|
||||
Clone your Github repository on your computer:
|
||||
|
||||
.. code-block:: bash
|
||||
@ -72,7 +70,6 @@ Create a new branch:
|
||||
|
||||
$ git checkout -b feature-1 master
|
||||
|
||||
|
||||
Create the module structure
|
||||
===========================
|
||||
|
||||
@ -119,11 +116,11 @@ The below structure will be generated:
|
||||
├── templates.xml
|
||||
└── views.xml
|
||||
|
||||
.. Warning::
|
||||
.. warning::
|
||||
|
||||
Do not use special characters other than the underscore ( _ ) for your module name, not even an
|
||||
hyphen ( - ). This name is used for the Python classes of your module, and having classes name
|
||||
with special characters other than the underscore is not valid in Python.
|
||||
Do not use special characters other than the underscore ( _ ) for your module name, not even an
|
||||
hyphen ( - ). This name is used for the Python classes of your module, and having classes name
|
||||
with special characters other than the underscore is not valid in Python.
|
||||
|
||||
Uncomment the content of the files:
|
||||
|
||||
@ -222,7 +219,6 @@ install.
|
||||
|
||||
You can then play around with your module, create new records and test your features and buttons.
|
||||
|
||||
|
||||
Test with the production data
|
||||
=============================
|
||||
|
||||
@ -237,12 +233,12 @@ You can either:
|
||||
title.
|
||||
|
||||
.. image:: first_module/firstmodule-test-devtostaging.png
|
||||
:align: center
|
||||
:align: center
|
||||
|
||||
* Merge it in an existing staging branch, by drag and dropping it onto the given staging branch.
|
||||
|
||||
.. image:: first_module/firstmodule-test-devinstaging.png
|
||||
:align: center
|
||||
:align: center
|
||||
|
||||
You can also use the :code:`git merge` command to merge your branches.
|
||||
|
||||
@ -250,7 +246,7 @@ This will create a new staging build, which will duplicate the production databa
|
||||
using a server updated with your latest changes of your branch.
|
||||
|
||||
.. image:: first_module/firstmodule-test-mergedinstaging.png
|
||||
:align: center
|
||||
:align: center
|
||||
|
||||
Once the database ready, you can access it using the *Connect* button.
|
||||
|
||||
@ -419,7 +415,7 @@ Or, from your computer terminal:
|
||||
The platform will then create a new build for the branch *feature-1*.
|
||||
|
||||
.. image:: first_module/firstmodule-test-addachange-build.png
|
||||
:align: center
|
||||
:align: center
|
||||
|
||||
Once you tested your changes, you can merge your changes in the production branch, for instance by
|
||||
drag-and-dropping the branch on the production branch in the Odoo.sh interface. As you increased the
|
||||
|
@ -1,9 +1,9 @@
|
||||
|
||||
.. _odoosh-gettingstarted-online-editor:
|
||||
|
||||
==================================
|
||||
=============
|
||||
Online Editor
|
||||
==================================
|
||||
=============
|
||||
|
||||
Overview
|
||||
========
|
||||
@ -120,24 +120,23 @@ In this last command,
|
||||
.. image:: online-editor/interface-editor-commit-push.png
|
||||
:align: center
|
||||
|
||||
.. Note::
|
||||
The SSH Github remote is not used because your SSH private key
|
||||
is not hosted in your build containers (for obvious security concerns)
|
||||
nor forwarded through an SSH Agent (as you access this editor through a web browser)
|
||||
and you therefore cannot authenticate yourself to Github using SSH.
|
||||
You have to use the HTTPS remote of your Github repository to push your changes,
|
||||
which is added automatically named as *https* in your Git remotes.
|
||||
You will be prompted to enter your Github username and password.
|
||||
If you activated the two-factor authentication on Github,
|
||||
you can create a
|
||||
`personal access token <https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/>`_
|
||||
and use it as password. Granting the ``repo`` permission suffices.
|
||||
.. note::
|
||||
The SSH Github remote is not used because your SSH private key
|
||||
is not hosted in your build containers (for obvious security concerns)
|
||||
nor forwarded through an SSH Agent (as you access this editor through a web browser)
|
||||
and you therefore cannot authenticate yourself to Github using SSH.
|
||||
You have to use the HTTPS remote of your Github repository to push your changes,
|
||||
which is added automatically named as *https* in your Git remotes.
|
||||
You will be prompted to enter your Github username and password.
|
||||
If you activated the two-factor authentication on Github,
|
||||
you can create a `personal access token
|
||||
<https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/>`_
|
||||
and use it as password. Granting the ``repo`` permission suffices.
|
||||
|
||||
|
||||
.. Note::
|
||||
The Git source folder *~/src/user* is not checked out on a branch but rather on a detached revision:
|
||||
This is because builds work on specific revisions rather than branches.
|
||||
In other words, this means you can have multiple builds on the same branch, but on different revisions.
|
||||
.. note::
|
||||
The Git source folder *~/src/user* is not checked out on a branch but rather on a detached revision:
|
||||
This is because builds work on specific revisions rather than branches.
|
||||
In other words, this means you can have multiple builds on the same branch, but on different revisions.
|
||||
|
||||
Once your changes are pushed,
|
||||
according to your :ref:`branch push behavior <odoosh-gettingstarted-branches-tabs-settings>`,
|
||||
@ -166,12 +165,11 @@ You can also open an Odoo Shell console to play around
|
||||
with the Odoo registry and model methods of your database. You can also directly read or write
|
||||
on your records.
|
||||
|
||||
.. Warning::
|
||||
In an Odoo Console, transactions are automatically committed.
|
||||
This means, for instance, that changes in records are applied effectively in the database.
|
||||
If you change the name of a user, the name of the user is changed in your database
|
||||
as well.
|
||||
You therefore should use Odoo consoles carefully on production databases.
|
||||
.. warning::
|
||||
In an Odoo Console, transactions are automatically committed.
|
||||
This means, for instance, that changes in records are applied effectively in the database.
|
||||
If you change the name of a user, the name of the user is changed in your database as well.
|
||||
You therefore should use Odoo consoles carefully on production databases.
|
||||
|
||||
You can use *env* to invoke models of your database registry, e.g. :code:`env['res.users']`.
|
||||
|
||||
@ -196,4 +194,4 @@ You can also use
|
||||
to display graphs.
|
||||
|
||||
.. image:: online-editor/interface-editor-console-odoo-graph.png
|
||||
:align: center
|
||||
:align: center
|
||||
|
@ -1,7 +1,6 @@
|
||||
|
||||
==================================
|
||||
========
|
||||
Settings
|
||||
==================================
|
||||
========
|
||||
|
||||
Overview
|
||||
========
|
||||
@ -21,8 +20,8 @@ The name of your project.
|
||||
|
||||
This defines the address that will be used to access your production database.
|
||||
|
||||
Addresses of your staging and development builds are derived from this name and assigned automatically.
|
||||
However, when you change your project name, only future builds will use the new name.
|
||||
Addresses of your staging and development builds are derived from this name and assigned
|
||||
automatically. However, when you change your project name, only future builds will use the new name.
|
||||
|
||||
.. _odoosh-gettingstarted-settings-collaborators:
|
||||
|
||||
@ -39,10 +38,10 @@ There are two levels of users:
|
||||
* Admin: has access to all features of Odoo.sh.
|
||||
* User: does not have access to the project settings nor to the production and staging databases.
|
||||
|
||||
The user group is meant for developers who can make modifications in your code but are not allowed to access the
|
||||
production data.
|
||||
Users of this group cannot connect to the production and staging databases using the *1-click connect* feature,
|
||||
but they can of course use their regular account on these databases if they have one, using their regular credentials.
|
||||
The user group is meant for developers who can make modifications in your code but are not allowed
|
||||
to access the production data. Users of this group cannot connect to the production and staging
|
||||
databases using the *1-click connect* feature, but they can of course use their regular account on
|
||||
these databases if they have one, using their regular credentials.
|
||||
|
||||
In addition, they cannot use the webshell nor have access to the server logs.
|
||||
|
||||
@ -90,7 +89,8 @@ Allow public access to your development builds.
|
||||
.. image:: settings/interface-settings-public.png
|
||||
:align: center
|
||||
|
||||
If activated, this option exposes the Builds page publicly, allowing visitors to connect to your development builds.
|
||||
If activated, this option exposes the Builds page publicly, allowing visitors to connect to your
|
||||
development builds.
|
||||
|
||||
In addition, visitors have access to the logs, shell and mails of your development builds.
|
||||
|
||||
@ -98,11 +98,11 @@ Production and staging builds are excluded, visitors can only see their status.
|
||||
|
||||
.. _odoosh-gettingstarted-settings-modules-installation:
|
||||
|
||||
|
||||
Custom domains
|
||||
==============
|
||||
|
||||
To configure additional domains please refer to the corresponding branch's :ref:`settings tab <odoosh-gettingstarted-branches-tabs-settings>`.
|
||||
To configure additional domains please refer to the corresponding branch's :ref:`settings tab
|
||||
<odoosh-gettingstarted-branches-tabs-settings>`.
|
||||
|
||||
.. _odoosh-gettingstarted-settings-submodules:
|
||||
|
||||
@ -112,10 +112,10 @@ Submodules
|
||||
Configure the deploy keys for the private repositories you use
|
||||
as submodules in your branches to allow Odoo.sh to download them.
|
||||
|
||||
.. Warning::
|
||||
These settings are required for **private repositories** only.
|
||||
If you are looking on how to set up your submodules,
|
||||
instructions are available in the chapter :ref:`Submodules <odoosh-advanced-submodules>` of this documentation.
|
||||
.. warning::
|
||||
These settings are required for **private repositories** only. If you are looking on how to set
|
||||
up your submodules, instructions are available in the chapter :ref:`Submodules
|
||||
<odoosh-advanced-submodules>` of this documentation.
|
||||
|
||||
.. image:: settings/interface-settings-submodules.png
|
||||
:align: center
|
||||
@ -130,7 +130,8 @@ To configure the deploy key for a private repository, proceed as follows:
|
||||
* in the input, paste the SSH URL of your private sub-repository and click on *Add*,
|
||||
|
||||
* e.g. *git@github.com:USERNAME/REPOSITORY.git*
|
||||
* it can be another Git server than Github, such as Bitbucket, Gitlab or even your own self-hosted server
|
||||
* it can be another Git server than Github, such as Bitbucket, Gitlab or even your own self-hosted
|
||||
server
|
||||
|
||||
* copy the public key,
|
||||
|
||||
@ -157,8 +158,9 @@ Storage size is computed as follows:
|
||||
|
||||
* the size of the disk files available in your container: database filestore, sessions storage directory...
|
||||
|
||||
.. Warning::
|
||||
In case you want to analyze disk usage, you can run the tool `ncdu <https://dev.yorhel.nl/ncdu/man>`_ in your Web Shell.
|
||||
.. warning::
|
||||
In case you want to analyze disk usage, you can run the tool `ncdu
|
||||
<https://dev.yorhel.nl/ncdu/man>`_ in your Web Shell.
|
||||
|
||||
Should your production database size grow to exceed what's provisioned in your subscription, it
|
||||
will automatically be synchronized with it.
|
||||
@ -191,7 +193,8 @@ add more, it will automatically be synchronized with your subscription.
|
||||
Activation
|
||||
==========
|
||||
|
||||
Shows the status of the project's activation. You can change the project's activation code if needed.
|
||||
Shows the status of the project's activation. You can change the project's activation code if
|
||||
needed.
|
||||
|
||||
.. image:: settings/interface-settings-activation.png
|
||||
:align: center
|
||||
|
@ -1,12 +1,12 @@
|
||||
|
||||
==================================
|
||||
======
|
||||
Status
|
||||
==================================
|
||||
======
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
The status page shows statistics regarding the servers your project uses. It includes the servers availability.
|
||||
The status page shows statistics regarding the servers your project uses. It includes the servers
|
||||
availability.
|
||||
|
||||
.. image:: status/interface-status.png
|
||||
:align: center
|
||||
|
@ -1,8 +1,8 @@
|
||||
:nosearch:
|
||||
|
||||
=================
|
||||
========
|
||||
Overview
|
||||
=================
|
||||
========
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
@ -1,7 +1,6 @@
|
||||
|
||||
==============================
|
||||
=======================
|
||||
Introduction to Odoo.sh
|
||||
==============================
|
||||
=======================
|
||||
|
||||
.. youtube:: QuNsa9n9PMg
|
||||
:align: right
|
||||
|
@ -59,7 +59,7 @@ Repeat the operation to create the Cedric Digory employee. Don't forget
|
||||
to specify its related user and **Timesheet Costs**.
|
||||
|
||||
Issue a Sales Order
|
||||
--------------------
|
||||
-------------------
|
||||
|
||||
We created two employees called Harry Potter and Cedric Diggory in the
|
||||
**Employee** app. Both of them will work on a consultancy contract for our
|
||||
@ -148,7 +148,7 @@ We can thus filter this information from the **Analytic Entries**.
|
||||
Enter the **Accounting** app, and click on :menuselection:`Adviser --> Analytic Entries`.
|
||||
In this menu we have several options to analyse the human resource cost.
|
||||
|
||||
1. We filter on the **Analytic account** so we can see the cost and revenues
|
||||
#. We filter on the **Analytic account** so we can see the cost and revenues
|
||||
of the project. Add a custom **Filter** where the **Analytic Account**
|
||||
contains the **Sales Order** number.
|
||||
|
||||
@ -161,7 +161,7 @@ In this menu we have several options to analyse the human resource cost.
|
||||
.. image:: timesheets/timesheets09.png
|
||||
:align: center
|
||||
|
||||
2. We can group the different analytical accounts together and check
|
||||
#. We can group the different analytical accounts together and check
|
||||
their respective revenues. Simply group by **Analytic account** and
|
||||
select the **Graph view** to have a clear overview.
|
||||
|
||||
|
@ -48,7 +48,7 @@ Post an expense to the right account
|
||||
------------------------------------
|
||||
|
||||
Select the account on a draft bill
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
On a draft bill, select the right account for all the products of which the expenses must be
|
||||
deferred.
|
||||
@ -72,7 +72,7 @@ save.
|
||||
`Automate the Deferred Expenses`_).
|
||||
|
||||
Change the account of a posted journal item
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To do so, open your Purchases Journal by going to :menuselection:`Accounting --> Accounting -->
|
||||
Purchases`, select the journal item you want to modify, click on the account, and select the right
|
||||
|
@ -71,7 +71,7 @@ save.
|
||||
`Automate the Deferred Revenues`_).
|
||||
|
||||
Change the account of a posted journal item
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To do so, open your Sales Journal by going to
|
||||
:menuselection:`Accounting --> Accounting --> Sales`, select the journal item you
|
||||
|
@ -81,7 +81,7 @@ Application
|
||||
.. _fiscal_positions/partner:
|
||||
|
||||
Assign a Fiscal Position to a partner
|
||||
--------------------------------------
|
||||
-------------------------------------
|
||||
|
||||
You can manually define which Fiscal Position must be used by default for a specific partner.
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
=======================================
|
||||
===================================
|
||||
How to get paid with wire transfers
|
||||
=======================================
|
||||
===================================
|
||||
|
||||
**Wire Transfer** is the default payment method available. The aim is providing your customers with
|
||||
your bank details so they can pay on their own. This is very easy to start with but slow and
|
||||
|
@ -1,19 +1,24 @@
|
||||
=====================================
|
||||
====================================
|
||||
Organize a cross-dock in a warehouse
|
||||
=====================================
|
||||
====================================
|
||||
|
||||
Cross-docking is the process of sending products that are received directly to the customers, without making them enter the stock. The trucks are simply unloaded in a *Cross-Dock* area in order to reorganize products and load another truck.
|
||||
Cross-docking is the process of sending products that are received directly to the customers,
|
||||
without making them enter the stock. The trucks are simply unloaded in a *Cross-Dock* area in order
|
||||
to reorganize products and load another truck.
|
||||
|
||||
.. image:: cross_dock/cross1.png
|
||||
:align: center
|
||||
|
||||
.. note::
|
||||
For more information on how to organize your warehouse, read our blog: `What is cross-docking and is it for me? <https://www.odoo.com/blog/business-hacks-1/post/what-is-cross-docking-and-is-it-for-me-270>`__
|
||||
For more information on how to organize your warehouse, read our blog: `What is cross-docking and
|
||||
is it for me?
|
||||
<https://www.odoo.com/blog/business-hacks-1/post/what-is-cross-docking-and-is-it-for-me-270>`_
|
||||
|
||||
Configuration
|
||||
==============
|
||||
|
||||
In the *Inventory* app, open :menuselection:`Configuration --> Settings` and activate the *Multi-Step Routes*.
|
||||
In the *Inventory* app, open :menuselection:`Configuration --> Settings` and activate the
|
||||
*Multi-Step Routes*.
|
||||
|
||||
.. image:: cross_dock/cross2.png
|
||||
:align: center
|
||||
@ -35,9 +40,11 @@ This modification will lead to the creation of a *Cross-Docking* route that can
|
||||
:align: center
|
||||
|
||||
Configure products with Cross-Dock Route
|
||||
=========================================
|
||||
========================================
|
||||
|
||||
Create the product that uses the *Cross-Dock Route* and then, in the inventory tab, select the routes *Buy* and *Cross-Dock*. Now, in the purchase tab, specify the vendor to who you buy the product and set a price for it.
|
||||
Create the product that uses the *Cross-Dock Route* and then, in the inventory tab, select the
|
||||
routes *Buy* and *Cross-Dock*. Now, in the purchase tab, specify the vendor to who you buy the
|
||||
product and set a price for it.
|
||||
|
||||
.. image:: cross_dock/cross5.png
|
||||
:align: center
|
||||
@ -45,7 +52,12 @@ Create the product that uses the *Cross-Dock Route* and then, in the inventory t
|
||||
.. image:: cross_dock/cross6.png
|
||||
:align: center
|
||||
|
||||
Once done, create a sale order for the product and confirm it. Odoo will automatically create two transfers which will be linked to the sale order. The first one is the transfer from the *Input Location* to the *Output Location*, corresponding to the move of the product in the *Cross-Dock* area. The second one is the delivery order from the *Output Location* to your *Customer Location. Both are in state *Waiting Another Operation* because we still need to order the product to our supplier.
|
||||
Once done, create a sale order for the product and confirm it. Odoo will automatically create two
|
||||
transfers which will be linked to the sale order. The first one is the transfer from the *Input
|
||||
Location* to the *Output Location*, corresponding to the move of the product in the *Cross-Dock*
|
||||
area. The second one is the delivery order from the *Output Location* to your *Customer Location.
|
||||
Both are in state *Waiting Another Operation* because we still need to order the product to our
|
||||
supplier.
|
||||
|
||||
.. image:: cross_dock/cross7.png
|
||||
:align: center
|
||||
@ -53,7 +65,8 @@ Once done, create a sale order for the product and confirm it. Odoo will automat
|
||||
.. image:: cross_dock/cross8.png
|
||||
:align: center
|
||||
|
||||
Now, go to the *Purchase* app. There, you will find the purchase order that has been automatically triggered by the system. Validate it and receive the products in the *Input Location*.
|
||||
Now, go to the *Purchase* app. There, you will find the purchase order that has been automatically
|
||||
triggered by the system. Validate it and receive the products in the *Input Location*.
|
||||
|
||||
.. image:: cross_dock/cross9.png
|
||||
:align: center
|
||||
@ -61,7 +74,8 @@ Now, go to the *Purchase* app. There, you will find the purchase order that has
|
||||
.. image:: cross_dock/cross10.png
|
||||
:align: center
|
||||
|
||||
When the products have been received from the supplier, you can go back to your initial sale order and validate the internal transfer from *Input* to *Output*.
|
||||
When the products have been received from the supplier, you can go back to your initial sale order
|
||||
and validate the internal transfer from *Input* to *Output*.
|
||||
|
||||
.. image:: cross_dock/cross11.png
|
||||
:align: center
|
||||
|
@ -10,32 +10,32 @@ to set those virtual warehouses.
|
||||
Set up virtual warehouses
|
||||
=========================
|
||||
|
||||
Let's say you have two warehouses: Warehouse A and Warehouse B. Create a new warehouse, that will
|
||||
be a virtual one. It will allow you to take the stock from A or B. To do so, go to your inventory
|
||||
app settings and enable the multi-warehouses feature. Then, go to the warehouses menu and click on
|
||||
Let's say you have two warehouses: Warehouse A and Warehouse B. Create a new warehouse, that will be
|
||||
a virtual one. It will allow you to take the stock from A or B. To do so, go to your inventory app
|
||||
settings and enable the multi-warehouses feature. Then, go to the warehouses menu and click on
|
||||
create.
|
||||
|
||||
.. image:: stock_warehouses/ware1.png
|
||||
:align: center
|
||||
|
||||
.. note::
|
||||
The *Storage Location* feature will be automatically enabled. Good news, because you will need
|
||||
it later in the process.
|
||||
The *Storage Location* feature will be automatically enabled. Good news, because you will need it
|
||||
later in the process.
|
||||
|
||||
Now, you have to make sure that the main stock locations of warehouse A and warehouse B are
|
||||
children locations of the main stock location of warehouse A + B. Go to the locations menu, and
|
||||
edit the main location of your two warehouses. Then, change their parent location to main location
|
||||
of warehouse A+B.
|
||||
Now, you have to make sure that the main stock locations of warehouse A and warehouse B are children
|
||||
locations of the main stock location of warehouse A + B. Go to the locations menu, and edit the main
|
||||
location of your two warehouses. Then, change their parent location to main location of warehouse
|
||||
A+B.
|
||||
|
||||
.. image:: stock_warehouses/ware2.png
|
||||
:align: center
|
||||
|
||||
Sell a product from the virtual warehouse
|
||||
==========================================
|
||||
=========================================
|
||||
|
||||
Let's say you have two products, one stored in warehouse A and one stored in warehouse B. Now, you
|
||||
can create a new quotation for one of each product. Go to other information and choose Warehouse
|
||||
A+B in the shipping information.
|
||||
can create a new quotation for one of each product. Go to other information and choose Warehouse A+B
|
||||
in the shipping information.
|
||||
|
||||
.. tip::
|
||||
You might find it handy to set the Warehouse A+B as the default warehouse for each sales person.
|
||||
|
@ -1,18 +1,21 @@
|
||||
========================
|
||||
=============
|
||||
Putaway rules
|
||||
=============
|
||||
|
||||
What is a Putaway Rule?
|
||||
========================
|
||||
=======================
|
||||
|
||||
A good warehouse implementation makes sure that products automatically move to their appropriate
|
||||
destination location. To make that process easier, Odoo uses *Putaway Rules*. Putaway is the
|
||||
process of taking products from the received shipments and putting them into the appropriate
|
||||
location.
|
||||
|
||||
If, for example, a warehouse contains volatile substances, it is important to make sure that
|
||||
certain products are not stored close to each other because of a potential chemical reaction.
|
||||
That's where putaway rules intervene, to avoid storing products wrongly.
|
||||
If, for example, a warehouse contains volatile substances, it is important to make sure that certain
|
||||
products are not stored close to each other because of a potential chemical reaction. That's where
|
||||
putaway rules intervene, to avoid storing products wrongly.
|
||||
|
||||
Configuration
|
||||
==============
|
||||
-------------
|
||||
|
||||
In the :guilabel:`Inventory` app, go to :menuselection:`Configuration --> Settings` and activate
|
||||
the :guilabel:`Multi-Step Routes` feature. By doing so, the :guilabel:`Storage Locations` feature
|
||||
@ -23,7 +26,7 @@ is also automatically activated.
|
||||
:alt: Activate Multi-Step Routes in Inventory configuration settings.
|
||||
|
||||
Setting up a putaway rule
|
||||
=========================
|
||||
-------------------------
|
||||
|
||||
In some cases, like for a retail shop storing fruits and vegetables, products should be stored in
|
||||
different locations depending on several factors like frequency, size, product category, specific
|
||||
@ -70,7 +73,6 @@ Take the following example:
|
||||
:align: center
|
||||
:alt: Some examples of putaway rules.
|
||||
|
||||
========================
|
||||
Using Storage Categories
|
||||
========================
|
||||
|
||||
@ -79,14 +81,14 @@ the quantity of products that can be stored in the location and how the location
|
||||
with putaway rules.
|
||||
|
||||
Configuration
|
||||
==============
|
||||
-------------
|
||||
|
||||
In the :guilabel:`Inventory` app, go to :menuselection:`Configuration --> Settings` and activate
|
||||
the :guilabel:`Storage Categories` feature. By doing so, the :guilabel:`Storage Locations` feature
|
||||
is also automatically activated.
|
||||
|
||||
Create a Storage Category
|
||||
=========================
|
||||
-------------------------
|
||||
|
||||
To create a storage category, go to :menuselection:`Inventory --> Configuration --> Storage
|
||||
Categories` and click :guilabel:`Create`. Then, click :guilabel:`Save` and click :guilabel:`Storage
|
||||
@ -116,7 +118,7 @@ Once the storage category settings are saved, the storage category can be linked
|
||||
:alt: When a Storage Category is created, it can be linked to a warehouse location.
|
||||
|
||||
Storage categories in putaway rules
|
||||
===================================
|
||||
-----------------------------------
|
||||
|
||||
To continue the example from above, apply the "High Frequency Pallets" on the PAL1 and PAL2
|
||||
locations and rework the putaway rules as follows:
|
||||
|
@ -14,15 +14,15 @@ An Access Key is a 16 character alphanumeric code that allows access to
|
||||
the UPS Developer Kit API Development and Production servers.
|
||||
|
||||
Create a UPS Account
|
||||
=====================
|
||||
====================
|
||||
|
||||
Note that only customers located in the US can open a UPS account online.
|
||||
If you are located outside the US, you will need to contact UPS Customer
|
||||
Service in order to to open an account.
|
||||
|
||||
You can read additional information about opening a UPS account on the
|
||||
their website, on the page,
|
||||
`How to Open a UPS Account Online <https://www.ups.com/content/us/en/resources/sri/openaccountonline.html?srch_pos=2&srch_phr=open+ups+account>`_
|
||||
their website, on the page, `How to Open a UPS Account Online
|
||||
<https://www.ups.com/content/us/en/resources/sri/openaccountonline.html?srch_pos=2&srch_phr=open+ups+account>`_
|
||||
|
||||
If you don't already have a UPS account, you can create one along with
|
||||
your online profile by following these steps:
|
||||
|
Loading…
Reference in New Issue
Block a user