[8.0] DdT, l10n_it_sale refactoring

[dcorio]

I'm working on a new addon here:
https://github.com/abstract-open-solutions/l10n-italy/tree/8.0-ddt

this is necessary to merge DdTs and create a grouped invoice.
the standard way (create invoice from pickings) as well as 3rd party addons like stock_picking_merge have already been discarded.

As per the italian law, DdT != Delivery Order

[dcorio]

Major missing features:

1. qweb report
2. invoice creation (should be possible to group DDTs to invoice)

[dcorio]

FYI: i'm working on the invoice creation right now

[LeartS]

I'm working on the qweb report: abstract-open-solutions#1

[eLBati]

I see a lot of complexity in adding a new model for DDT, expecially about the creation of invoices (I would not not know how to handle it).

What are the use cases not covered by the current v7 module?

[dcorio]

the possibility of creating a DdT from N pickings to avoid the various *merge modules, possibility to insert text lines and many more.

[eLBati]

See various improvements at abstract-open-solutions#2

[FrancoTampieri]

@eLBati Can i made a PR from Hurrico repo to this one?

[dcorio]

@drdran "this one" is an issue :-)

[dcorio]

btw, i noticed this:
https://github.com/hurrinico/l10n-italy/blob/hurrifix-8.0-ddt/l10n_it_ddt/models/stock.py#L93

do you prefer to show additional lines on reports only? i mean serial numbers, order references, etc
the purpose of stock.ddt.line was to replicate the sale_layout behavior.
but i don't want to maintain a fork so we could even drop that model and support your changes.

cc @hurrinico

[eLBati]

@dcorio if we need something similar to sale_layout, I would recommend to use the invoice_webkit approach: add html descriptive field to every line.
This would allow us to avoid to add complexity that would imply use cases hard to predict.

[dcorio]

@eLBati sure, but you can't display those info on the screen following the same layout of the printed version. that's something the users often pretend.
but for the moment we can avoid displaying those data on the screen to get rid of possibile issues introduced by stock.ddt.line.
so it's fine to me to remove this model.

[scigghia]

Hi all,
What happens if user need to add products on fly before printing document? I think stock.ddt.line I'd useful

[dcorio]

@scigghia for our customers i think we'll keep the picking_ids field editable so they can add/remove pickings anytime. Because you don't need to stock.ddt.line to do that.
actually, if you need to add/remove product you must to have a picking for that.

different scenario is the need to insert lines that have nothing to do with related pickings.
E.g. additional notes, serial numbers, etc...
But in this case we probably don't need to show those infos on the screen since we just need to print them on paper.

[eLBati]

for our customers i think we'll keep the picking_ids field editable so they can add/remove pickings anytime

Indeed we could even drop the ddt.from.pickings wizard and allow user to add pickings to DDT directly, as long as constraints checked here https://github.com/hurrinico/l10n-italy/blob/hurrifix-8.0-ddt/l10n_it_ddt/wizard/ddt_from_pickings.py#L41 are checked at DDT creation/modification

[dcorio]

@eLBati do we really need to set things like carriage condition, transportation reason & C. on the pickings?
Also the good description could not be useful if applied to the picking.

Use case:

1. YourCompany already created SO001 in order to sell ProductA (SO001) to CustomerA.
2. YourCompany now creates SO002 in order to sell ProductB (SO002) to CustomerA.
3. ProductA is available for the delivery on OUT/0001 and it is packaged in PackageType1
4. ProductB is available for the delivery on OUT/0002 and it is packaged in PackageType2

Since OUT/0001 hasn't been shipped already and OUT/0002 is ready to be shipped, YourCompany decides to delivery both today.

5. YourCompany creates DdT/0001 with OUT/0001 and OUT/0002 and chooses to ship everything packaged in PackageType3

6. YourCompany put the PackageType3 on a Pallet1

7. YourCompany has to add Pallet1 as a delivered product (with its serial number) on DdT/0001

8. YourCompany fills out all the fields on DdT/0001.

9. WarehouseUser1 gets notified about the fact that CustomerA just called and ordered ProductB and he has to add the newly created OUT/0003 (created by the confirmation of SO003) to DdT/0001.

10. WarehouseUser1 then adds the related picking to DdT/0001, changes what needs to be changed, confirm it and deliver the goods to CustomerA.

This is a real case i ofter have to manage.
Till now we used to merge OUT/0001, OUT/0002 and OUT/0003 and then assigned the DdT number to OUT/0004. But this is what we wanted to get rid off due to the complexity of the merging process and the bad quality of the available addons.

[scigghia]

@dcorio your previous comment explain well what users need, and I add ...

different scenario is the need to insert lines that have nothing to do with related pickings.

also this scenario is a really question every day, and we have started this module because those thinks are what we need!

If user needs to print a DDT with line like "These products must be delivered on the first floor" or like a service product from the sale order, how can we manage these?

[eLBati]

do we really need to set things like carriage condition, transportation reason & C. on the pickings?

It is not needed, but it allows to propagate those info from SO to DDT. If unwanted, they can be removed from picking and set on DDT directly, where they are important.

5. YourCompany creates DdT/0001 with OUT/0001 and OUT/0002 and chooses to ship everything packaged in PackageType3
6. YourCompany put the PackageType3 on a Pallet1
7. YourCompany has to add Pallet1 as a delivered product (with its serial number) on DdT/0001
8. YourCompany fills out all the fields on DdT/0001.

Packaging should be handled via odoo standard. Every info can be reported on DDT of course

9. WarehouseUser1 gets notified about the fact that CustomerA just called and ordered ProductB and he has to add the newly created OUT/0003 (created by the confirmation of SO003) to DdT/0001.
10. WarehouseUser1 then adds the related picking to DdT/0001, changes what needs to be changed, confirm it and deliver the goods to CustomerA.

This should be solved allowing users to add pickings to existing DDT.

[eLBati]

If user needs to print a DDT with line like "These products must be delivered on the first floor" or like a service product from the sale order, how can we manage these?

As said, I propose the invoice_webkit approach

[scigghia]

I looked in, for me it's ok :)

[eLBati]

#88 here is the WIP PR

[dcorio]

@eLBati @hurrinico have you already discussed about what is needed for the "fattura accompagnatoria". do you think that using a stock.ddt related to a specific invoice but without number (and a specific state) would be enough/appropriate? on the "fattura accompagnatoria" we need a lot of fields and logics already present on the DdT (cc: @drdran @giacomos)

[eLBati]

Technically, the relations between objects are
stock.ddt ← 1:N → stock.picking ← N:1 → account.invoice
that is: an invoice can be linked to N DDT

Functionally, the typical use case (when invoicing from delivery) is: from 1 DDT I create 1 invoice.

So, about your question

do you think that using a stock.ddt related to a specific invoice but without number (and a specific state) would be enough/appropriate?

yes, I think it's appropriate

My proposal:

From draft state, user will be able to follow 2 ways: 'confirm' and generate DDT number (existing way); 'create shipping invoice' (is 'shipping invoice' OK as translation of 'fattura accompagnatoria'?).
'create shipping invoice' button launches the ddt.create.invoice and sets the DDT in 'shipping invoiced' state, without giving it a number.

Then, I would add a report to account.invoice that contains invoice data + DDT data.
DDT data are directly retrieved from the linked DDT.
If more than 1 DDT are liked to invoice (as this is possible, in general) raise "Can't print shipping invoice: the invoice is linked to more than 1 DDT"

What do you think?

[dcorio]

👍

[FrancoTampieri]

Nice
👍

[eLBati]

About fattura accompagnatoria, created #99

[FrancoTampieri]

One minor news:
in the l10n_it_ddt module there isn't a filter view in for that method so I implemented that filter view here:
https://github.com/abstract-open-solutions/l10n-italy/blob/8.0-ddt/l10n_it_ddt/views/stock_view.xml#L86

@eLBati is the repo of Hurrico ready to merge in the branch 8.0-ddt? So we can make a PR for that, do u agree?

[eLBati]

Hello @drdran , l10n_it_ddt is nder review at #88
If you want to propose enhancements, you can make a PR for hurrinico:hurrifix-8.0-ddt branch