Prestashop - Create delivery slip upon transfer of stock to other warehouse

Question

1. I need to create some sort of a transfer slip (just like a delivery slip) that has a transfer number (eg. Transfer #TR000008) upon the transfer of stock from one warehouse to another (Stock > Stock Management --> Actions > Transfer Stock).

2. And I would like to show the transfer number (eg. #TR000008) in the Stock Movement column.

3. And, if possible, I would like to change the LABEL from "Transfer to another warehouse" to "Transfer to [NAME OF WAREHOUSE HERE]".

Any way I could hack PrestaShop to do the above?

Help is really appreciated.

UPDATE:

If no.1 is too difficult, maybe just show me a way to add extra input field in the Stock Transfer form so that I can input the transfer number manually.

NOTE:

I really need help on getting a full working code maybe based on the direction @soulseekah provided.

PS: I'm using Prestashop 1.5.2.0

Answer 1

While Prestashop is quite rigid in terms of flexibility and extending its features, what you ask for is pretty much possible by sprinkling a bit of JavaScript magic (read: hacks) here and there.

Note: I'm using Prestashop 1.5.6.1 for this, so there might be some minor differences.

Assumptions

I assume you know how to write basic Prestashop modules, use Prestashop hooks, setup module install and uninstall actions, and work with the database, use jQuery.

Ready?

Stock transfers

There isn't a strict notion of stock transfers in Prestashop. But you do get a complete history of stock movement, which is stored in the stock_mvt table and backed by the StockMvt class.

This is very fortunate and saves you having to create and manage a table of transfers. However, it may not be too reliable.

Column action

The Stock Movement screen, which is rendered by AdminStockMvtController, doesn't have any hooks to alter columns. So this will need some JavaScript action.

The standard way of injecting JavaScript is to hook into displayBackOfficeHeader. Once you hook into this action, inject a JavaScript file.

public function hookDisplayBackOfficeHeader() {
    return '<script type="text/javascript" src="'.$this->_path.'transfers.js'.'"></script>';
}

Extra column

The above will include your script, that is shipped along with your module. This script can use jQuery to alter the look and content of the columns.

jQuery( '.table.stock_mvt thead tr:nth(0)' ).append( '<th>Transfer</th>' );
jQuery( '.table.stock_mvt thead tr:nth(1)' ).append( '<td></td>' );

Bonus points for sorting, searching, filtering by the new column.

Labels

Altering the names "Transfer to/from another warehouse" is simple and doesn't need any database calls. Simply look at each row, if the column contains a "from" look at the previous row and get the name from the Warehouse column. If it contains a "to" look at the next row.

This will obviously not work with sorts and filters just like that. In this case you can call the database for the warehouse names for each movement - see next section.

UI is pretty simple. But how do you get transfer slip data into there? Here comes the difficult part.

Transfer slip data

Like I said, movement data is available and can be easily retrieved in pretty much the same way AdminStockMvtController does it.

The table will require some data from the database. You need to get the ID of a movement between warehouses, which will be your slip ID and the name of the two warehouses involved.

Basically, you need to figure out pairs of transfers by looking at the stock_mvt_reason_lang table and finding consecutive "to" and "from" reason pairs, these have id_stock_mvt_reason you're interested in. Look inside stock_mvt, order by stock_mvt_id and pair them up in PHP or MySQL.

The id_stock will point to a warehouse, where you can get the names. Basically get whatever you need and pair consecutive "to" -> "from" movements as a transfer.

The slip ID should probably be the id_stock_mvt of the "to" movement, or the "from" movement (pick one and stick to it). This way you'll be able to generate a slip with one specific ID and find the two movements which were involved in the transfer.

Putting it all together

So what you have to do is throw an AJAX call at your module and return the needed data - transfer slip IDs, transfered to/from names, etc. Once this call completes you simply inject the data into the table as needed. Transfers would be links to generate your slips (see next section).

Since the table has no ID data, you'll have to make sure to return the results in the correct order, so don't forget to account for sorting, limits and pagination to output a correctly ordrdered payload to be injected into the table. You should be able to get away with sending only transfer data pairs.

Alternatively, you can create a new admin tab called "Stock Transfers" where you output the table in a clean way with transfers only.

PDF slips

PDF generation can be forked from AdminPdfController. You'd have to include the necessary data from transfers. By this point you would have already discovered the correct way to get all the needed data for output. Building the PDF is straightforward.

Once your generator gets the slip ID you go look for it in the movements table, get its pair and all their data. As you can imagine, generation ocurrs on the fly, and slips are never stored in Prestashops. Your new transfer slips do not need to be stored either.

Overview

A quick overview of what your module will need to contain:

• Basic module code (install, uninstall, hook registration)
• A registered hookDisplayBackOfficeHeader function
• A script.js file which does an AJAX request for table data
• An AJAX request responder, which given some parameters, will return slip IDs, warehouse names
• A PDF controller that can identify a pair from one of the IDs (id_stock_mvt) and output a nice slip for you to print
• Some conventional security measures, you don't want strangers poking around your transfers

Conclusion

The whole thing is far from easy (even explaining it is difficult) and will probably take a couple of days to implement basic functionality, but it's certainly possible with varying (mosly successful) results.

One of the main difficulties lies in how two related movements are not explicitly connected, instead of some binding transfer ID you have one "to" movement and one "from" movement, with a close time between them, and the same quantity.

Maintaining a clean core fork is also an option, by the way, where you make minimal changes to core that can be merged easily with updates. Like adding hooks in convenient places, substituting one core class for your own class, etc. This will let you have less hacks.

I'll be happy to chat and discuss specifics of the above approach. Happy holidays and good luck with your project!

Answer 2

Another approach would be to fork Prestashop. This is quite dangerous and should be avoided if possible, but sometimes there's no other way. It is not easier than writing a module with hacks, as my other answers, but allows you to do things that hacks make difficult to do.

Some of the ideas below can be related to my previous answer and contains some new ideas as well. By combining the two answers you can actually come up with a very reliable non-fork way of doing this probably, at the expense of more coding time required. I would also consider this answer an improvement on my previous answer as I've found several better ways of doing some things while exploring.

Assumptions

I'll assume you know a good amount of PHP and MySQL to make the necessary changes, and you know how to maintain and update a fork (using diffs and merges) when the main package is updated. You'll still probably need some jQuery or JavaScript action either way.

You'll also still need to get acquainted with Prestashop's APIs - the database, security and permissions, models, controllers and modules.

Again, coding a semi-working solutions may take a day or two for the experienced programmer, so don't expect any quick copy and paste solutions here - there will be none, unfortunately.

Minimal forking

So, you've decided to fork it all. What you should be concentrating on is making changes as tiny as possible. The rule is not more than 2 statements in each important part of a function. All logic should be written in custom files, that live outside of the core tree.

Database

Since Prestashop doesn't bother to maintain transfer ties, you'll need to create and maintain your own table to store a transfer. The table would need to have id_warehouse_to and id_warehouse_from as two foreign keys into the warehouse table. You can also have the extra column for your extra input field that we'll be adding in a moment.

This table will allow you find pairs without having to calculate shifts, and keep the core database safe.

Saving transfers

This method does not require forking, and can be combined with the previous solution.

A transfer can be detected inside the postProcess method of the controller, you'll see the transferBetweenWarehouses method being called on the StockManager.

Luckily, the StockManger is returned by a Factory, which can actually be hooked into using the stockManager hook.

Implement the StockManagerInterface, which proxies everything to the default StockMangaer. This will allow you to detect the transferBetweenWarehouses method invocation and record the neccessary data into your custom table.

I would go as far as forking that method completly and instead of storing warehouse IDs actually store the two stock movement IDs after each ->add and ->remove. This will enable you to find the actual prices, quantities, etc.

Extra input field

You can use JavaScript injection and inject an extra field that you can process inside your custom StockManagerInterface. Add a simple <input name="custom"> and then look for it using Tools::getValue('custom', null), for example. Then store it into your custom table along with the other transfer data.

The forking way, would require you to alter the form array inside AdminStockManagementController, some of the values may go deeper into the templates themselves, so make sure to go deeper with them. The rest should be handled inside your StockManager proxy that you coded in the previous step.

Outputting lists

I would go for a new tab with a list of its own, called "Stock Transfers" for example. This is easier than trying to alter the existing tab; but if you want to you can mangle up the renderList function inside the relevant controller and modify the template that is output (inside here and here).

PDF

The generation of the actual PDF would remain the same as in my other answer, but this time your IDs would come from your custom transfers table, like transfer_id (auto incremented). This will allow the PDF generator to look into your table, reference the things involved.

Conclusion

Overall I feel that by combining this and my previous answer you can get away with a very decent solution to your issue at hand without actually forking anything. I'd personally go for the StockManager proxy, some jQuery injection and a custom table inside a new admin tab that contains a list of all the transfers without forking anything.

Hope this all helps you come up with the code needed to get this feature implemented in a clean way. And if you're not comfortable with this all, try hiring a good developer, with the two guides I've written for you - there's no room for failure really.

Best of luck.

Answer 3

I have created some sample codes however since they are too long I have made them available here. The codes demonstrate a Module that extends the default StockManager implementation to associate the corresponding Stock Movements to a Transfer ID. I have not got to the point where the PDF generation is performed. May be one I have some time I will be able to continue it :)