Transferts de stocks entre entrepôts d'entreprise Agrandir l'image

Transferts de stocks entre entrepôts d'entreprise



InternalStockTransfers intègre à Dolibarr la possibilité de gérer les transferts de stocks entre entrepôts d'entreprise au sein d'un flux de travail qui gère l'entrée / sortie des stocks des entrepôts concernés, en incorporant différents types de documents pour soutenir le processus. Il intègre également un module pour gérer les permis d'E/S des marchandises des entrepôts.

Plus de détails

400,00 €

En savoir plus

Dolibarr InternalStockTransfers

Stock transfers between corporate warehouses

Module version: auto
Publisher/Licence: Federico García-Patiño / GPL-v3
User interface language: English, Spanish
Help/Support: [email protected]

  • Dolibarr min version: auto
  • Dolibarr max version: auto

Install (For Dolibarr v9+:

  • Go into menu Home - Setup - Modules - Deploy an external module and submit the zip file
  • Module or skin is then available and can be activated.

Install (For Dolibarr v8-):

  • Download the archive file of module (.zip file) from web site
  • Put the file into the root directory of Dolibarr.
  • Uncompress the zip file, for example with command  unzip
  • Module or skin is then available and can be activated.

Documentation original language: Spanish

The problem

Frequently, a company's stock supply needs cause stock movements between its own warehouses.

Dolibarr has a series of processes to manage warehouse input and output of stock in a complete, reliable and secure manner, from its standard "orders" (customers and suppliers) and "shipping" modules. It also incorporates in its stock management module tools that allow stock transfers between warehouses, but these have to be carried out immediately.

These transfers do not take into account that sometimes the transport generates a situation in which the stock during the process may not be in any warehouse, and also, requires documentation that is not possible generate from the tools in the Dolibarr standard.

A workflow is also necessary to complete such expeditions, which also demands new document types. On the one hand, there is a stock  transfer request, where a user authorized to receive stock in a warehouse makes a request to another user authorized to issue stock from another warehouse. In between, it is necessary to configure a shipment with the concrete products that will be sent, the company that is going to carry it out, the dates on which things happen, and the necessary documentation for the shipment. At the time of transport, the stock leaves the source warehouse, and when the shipment is received, the stock is incorporated into the target warehouse.

Additionally, the configuration of the shipment may or may not require the tertiary packaging of the products, and for security and conservation reasons it will be convenient to keep these packages in the warehouse where the stock is received, so it is also necessary to generate the documentation with the description of the content of these packages that facilitates subsequent inventory processes.

The solution

InternalStockTransfers incorporates a set of tools around a workflow to perform the entire process, allowing operations with products configured with batches, and incorporating the necessary documentary elements for their control.

The permissions module

The permissions module allows to specify the I/O permissions of each user in each warehouse as follows:

  • If a user has input permissions in a warehouse, it means that they can make stock transfer requests to another warehouse and the user is authorized to receive the stock shipped

  • If a user has output permissions in a warehouse means that it is possible to work with the transfer requests made to that warehouse, and is authorized to configure the shipment and produce the output of the involved stock.

The stock transfer request form

Each stock transfer request requires information that is completed based on the status of the request. The model that represents a request and the stages where the information is as follows:

  • Applicant: user requesting stock

  • Source Warehouse: warehouse where the stock will be received

  • Target Warehouse: warehouse from which the stock is requested

  • Date of need: date in which it is necessary for the stock to be in the target warehouse. Completed at the time of request

  • Request Date

  • Issue Date: completed at the time of shipment setup

  • Expected Delivery Date: Completed at the time of shipment setup

  • Date of reception: it is completed at the moment of the reception of the stock

  • Requested product lines: products that are requested. Lots do not need to be specified at this stage

  • Lines of products assigned to the shipment: concrete products associated with the request. When the batch product management module is configured and the product configuration includes this feature, the necessary information is taken into account.

  • Tertiary packaging (pallets): it is completed in the “pallets” tab associated with the stock transfer request.

    Note: In order to have the functions to manage tertiary packaging, it is necessary to have the ExpeditionPallets” module installed, which can be downloaded from the official Dolibarr Dolistore store.

Statuses of a request

Each stock transfer request goes through a series of stages or statuses that require providing different information depending on the status in question. The statuses are as follows: 

  • Draft: A user with access permissions to a warehouse makes a stock transfer request to another company warehouse. In this state, the requesting user specifies the goods and the date on which they need to be available in the destination warehouse.

  • Validated: The requesting user sends the stock transfer request to the warehouse of origin. Two things can happen at this point

    • The requesting user can return the request to the draft state to be modified.

    • Users with output permissions on the source store can evolve the request to the “preparing” state, at which point the requesting users will not be able to alter its state.

  • In preparation: A user with output permissions on the source store accepts the request. At this time, the configuration of the shipment to be made is produced, including tertiary packaging if necessary. Users can return requests to validation status so that they can be modified by users with input permissions on the target store.

  • Shipped: A user with exit permissions in the origin warehouse indicates that the configuration of the stock transfer has been completed and at that moment the goods leave the origin warehouse. Users with exit permissions at the origin warehouse can change the status to "in preparation" to return the goods to the origin warehouse.

  • Received: A user with entry permissions at the destination warehouse receives the shipment and the goods. At this time, the goods are incorporated into the destination warehouse.


The status relationship of the requests with the users occurs differently depending on whether or not the users have permissions to perform the different actions. The following table shows all possible state transitions: 


User Permission


Next State



Source - Check



Order Description


Source - Check



Grants access to request management


Source - Check

Return to draft


Cancels access to the management of the request


Destination - Output

Prepare shipment


Access to the management of the shipment

In preparation

Destination - Output

Return to validated


Rejects the management of the shipment

In preparation

Destination - Output



Ends the management of the shipment


Destination - Exit

Cancel shipment


Cancel shipment


Origin - Entry



Receive merchandise


The document model

The management of the stock transfer is aided by different types of documentation that appear depending on the state in which the request is found.  The documentary types and their associated function correspond to the following:

  • Stock transfer request: incorporates the information of the request and the list of products that are requested, including comments of the requesting user for each product line requested. This document is generated automatically in the validation of the requests. 

  • Load summary: incorporates the information of the request and the list of specific products that are part of the shipment, including batches (if applicable), weights and volumes. This document is generated automatically when a request reaches the “shipped” status, and can be the documentation for the carrier or used for counting on delivery at the destination warehouse.

  • Pallet details: this document must be generated explicitly, and includes the detailed information on the content of the pallets configured in relation to the request.

    Note: module must be installed,ExpeditionPalletswhich can be downloaded from the official Dolibarr Dolistore store. A detailed description of the required configuration can be found in the product publication.


The installation of InternalStockTransfers is done in the same way as any other Dolibarr module.

Once the installation is complete, you should identify the following options at the bottom of the side menu of the "Products" main menu:


  • Internal transfers: query the requests and their status and allow access to the individual file of each one .

  • New request: allows to create new requests

  • Permissions: allows to set the I/O permissions in the warehouses by system users.


In order for the different users to be able to use the InternalStockTransfers module, it is necessary to assign permissions on the different functionalities of the module. This action is carried out by the administrator in the usual assignment of Dolibarr permissions. The relevant permissions are as follows:

  • Add InternalStockTransfers objects (users who can create and modify requests)

  • Read InternalStockTransfers objects 
  • Modify warehouse permissions

Before using InternalStockTransfers it is necessary to take into account the permission settings of the different users authorized to issue/receive stock at each warehouse . See the use case below for detailed information on this process.

Use case

Lifecycle of a request and the state transitions that occur in the action of the different users involved in the process.

All state transitions are recorded as events associated with the request. You can check these events directly in the application file, or in the "events" tab.


Detail of the event viewer in the request tab.

Information domain

  • Warehouses: Warehouse A, Warehouse B

  • Transport service providers (thirdparty transport supplier)

  • Products (in this case managed with batches), and materials for tertiary packaging

  • Users with different configurations of I/O warehouse permissions 

I/O warehouse permissions

From the “Permissions” option in the module menu, the I/O permissions for warehouses and users are configured: 

User 1 manages “ALM_0” and can issue and receive stock only in this warehouse .


User 2 manages “ALM_AUX” and can ship and receive stock only in this warehouse.

Create a new request

Once the permissions for the warehouses and users have been configured, it is possible to create a request, taking into account that a user can select any source warehouse configured, and will only be able to select those warehouses where he can receive stock as destination warehouses.

By clicking on the “Create” button, a new request will be created in draft status and will redirected to the transfer file to be accessed, on which the products that are requested can be described.

Request products

The request for products occurs in the tab of the transfer file, and can only be done when the file is in draft status, and by those users who have access permissions on the target warehouse.


Details of the application form.



  1. Updates the header data of the request

  2. Adds a product line to the order, allowing a small comment to be written

  3. Deletes the request. 

Once the products that are part of the request have been completed, the option to "Validate" the request is enabled. In the "validated" state, the requesting user can return the request to the "Draft" state, and users with exit permissions in the origin warehouse (the one from which the goods are requested), can capture the request and proceed to the configuration of the shipment.


Detail of an order line

The validation of the shipment will automatically create a document called "order" that reflects the content of the request that serves as a guide for the subsequent preparation of the shipment. Access to this document occurs from the usual Dolibarr standard within the request file, or from the "documents" tab

Prepare the shipment

Once the request has been validated, users with exit permissions in the warehouse of origin can access the requests by clicking on the reference created for the request, and proceed to the preparation of the shipments.


Details of the list of requests:

Details of the validated request


When the "Prepare delivery" button is pressed, the status of the request is changed to "preparing", and the controls that allow to set new information on the request are enabled within the tab. Relevant header for the request,

Detail of the header information

This new information includes:

  • Company that will be in charge of the transport

  • Reference of the shipment for the transport company

  • Date of the expedition

  • Estimated date of arrival of the stockat the destination


and the set of controls that They allow you to set the details of the products that will be part of the shipment, specifying the quantities and batches (if any).

Stock shipment

Once the product lines that will be part of the shipment have been completed, the user responsible for the source warehouse can press “send stock”, which will place the request in the “shipped” state and a new document called “transport” will be automatically generated showing the load summary. This document can be part of the physical documentation of the shipment both for the transport company and for the reception of the stock at the target warehouse.

The shipment of the stock implies the registry of the outgoing movements of the products involved in the warehouse of origin, and in case the pallet module is activated, also of the auxiliary materials that were part of the tertiary packaging. 


Detail of the cargo summary document.

Alternatively, the user responsible for the source warehouse can decide to set the status of the request to "validated" if he considers that it should be corrected by the requesting user. 

Note: since the reality of the shipment depends on the management of the stock in the source warehouse, the shipped quantities do not have to correspond to the quantities that are requested.


The functions for the configuration of tertiary packaging depend on the installation of the “ExpeditionPallets” module that is published in the official Dolibarr store “Dolistore”. You can access a detailed description of the ExpeditionPallets module by clicking this link

Once the content that will be part of the shipment has been specified, it is possible to configure the tertiary packaging for its transport. The functions for the configuration of pallets are enabled in a new tab called “Pallets” that appears next to the stock transfer request tab.

Pallet configuration detail

Note: Since the content of the pallets depends on the products included in the shipment preparation, it is recommended to complete the shipment preparation before proceeding to the pallet configuration.

The functions for the configuration of pallets include a new document type called “pallets”. This document includes a page with the summary of the content of each pallet. These documents can be printed and physically attached to pallets to facilitate subsequent inventory processes. The generation of this document is not automatic and must be executed by the user each time it is required.


Detail of the pallet document.


The reception of the stock

Once the shipment has been made, the user responsible for source warehouse can receive the stock by pressing the “receive” button. This action incorporates the products involved in the shipment into the destination warehouse.

In case the "ExpeditionPallets" module is activated and there are pallets configured in the shipment, the materials used for tertiary packaging will also be incorporated into the destination warehouse. Its existence is recorded, either for waste management or for subsequent reuse.

The reception of the merchandise implies the reception of the entire shipment, and in case of incidents (breakages, losses) this circumstance can be reflected through manual stock corrections from the Dolibarr standard module.

Annex I: Documentary types

Stock transfer request


Load Summary


Detail of pallets


Annex II: Disclaimer

The InternalStockTransfers module offers service to real companies in the indicated Dolibarr contexts, without any problem or derived adverse effect having been detected of its installation or its use. 

The acquisition of the module includes its source code, and the author is not responsible for any effect that could be attributed to its installation or its use, nor for any modification that may be made subsequently by the person who acquires it. The possible improvements introduced by third-party users must be made known to the author, both in their functional description and the source code.

The acquisition of the module does not imply the commitment of maintenance by the author. Although it undertakes to provide the result of the evolutionary work carried out on the module for a period of one year from the time of its acquisition. 

Although contact possibilities are offered, this does not imply that suggestions for improvement or correction of problems are addressed, although the possibility of carrying out the activities necessary for incorporation into the product will be assessed based on its usefulness and cost. at the discretion of the author.

Annex III: Warnings

Module class references in stock movement listings

The stock movement lists of a warehouse do not reflect the reference of the original objects that give rise to the movements. This is due to a Dolibarr limitation “by design”, where the rule for the meta-information description of references is limited to 32 characters.

If you want to remove this restriction you can change the size of the “origintype” field of the “ stock_mouvement ” table to an arbitrarily large value (eg 128 characters). This is not considered a good practice because it changes the original state of your Dolibarr installation and this modification may be lost in subsequent updates, or could cause indesiderable behaviours (not observed).

Execute the following SQL statement if you want to correct this issue.

ALTER TABLE `llx_stock_mouvement` CHANGE `origintype` `origintype` VARCHAR(128)

Anexo IV: Aknowledgements

Warehouse icons created by Freepik - Flaticon