Comments (27)
Major missing features:
- qweb report
- invoice creation (should be possible to group DDTs to invoice)
from l10n-italy.
FYI: i'm working on the invoice creation right now
from l10n-italy.
I'm working on the qweb report: abstract-open-solutions#1
from l10n-italy.
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?
from l10n-italy.
the possibility of creating a DdT from N pickings to avoid the various *merge modules, possibility to insert text lines and many more.
from l10n-italy.
See various improvements at abstract-open-solutions#2
from l10n-italy.
@eLBati Can i made a PR from Hurrico repo to this one?
from l10n-italy.
@drdran "this one" is an issue :-)
from l10n-italy.
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
from l10n-italy.
@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.
from l10n-italy.
@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.
from l10n-italy.
Hi all,
What happens if user need to add products on fly before printing document? I think stock.ddt.line I'd useful
from l10n-italy.
@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.
from l10n-italy.
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
from l10n-italy.
@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:
- YourCompany already created SO001 in order to sell ProductA (SO001) to CustomerA.
- YourCompany now creates SO002 in order to sell ProductB (SO002) to CustomerA.
- ProductA is available for the delivery on OUT/0001 and it is packaged in PackageType1
- 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.
-
YourCompany creates DdT/0001 with OUT/0001 and OUT/0002 and chooses to ship everything packaged in PackageType3
-
YourCompany put the PackageType3 on a Pallet1
-
YourCompany has to add Pallet1 as a delivered product (with its serial number) on DdT/0001
-
YourCompany fills out all the fields on DdT/0001.
-
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.
-
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.
from l10n-italy.
@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?
from l10n-italy.
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.
- YourCompany creates DdT/0001 with OUT/0001 and OUT/0002 and chooses to ship everything packaged in PackageType3
- YourCompany put the PackageType3 on a Pallet1
- YourCompany has to add Pallet1 as a delivered product (with its serial number) on DdT/0001
- 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
- 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.
- 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.
from l10n-italy.
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
from l10n-italy.
I looked in, for me it's ok :)
from l10n-italy.
#88 here is the WIP PR
from l10n-italy.
@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)
from l10n-italy.
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?
from l10n-italy.
๐
from l10n-italy.
Nice
๐
from l10n-italy.
About fattura accompagnatoria, created #99
from l10n-italy.
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?
from l10n-italy.
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
from l10n-italy.
Related Issues (20)
- l10n_it_fatturapa_in: errore importo fattura con arrotondamento HOT 6
- l10n_it_delivery_note: add hook to prepare vals needed to create DN
- Con enterprise, il menu delle RiBa รจ sotto Fatturazione
- Errore nei test di currency_rate_update_boi HOT 1
- Errore calcolo di ricevute bancarie HOT 2
- not possible to update/clone the repo on a Windows operating system. HOT 5
- Nuove specifiche fatturazione elettronica dal 1ยฐ Febbraio 2024 HOT 4
- l10n_it_delivery_note: picking's dn fields optional in tree view
- Poter aprire una distinta RiBa quando la fattura collegata รจ stata eliminata
- [l10n_it_delivery_note] - usare lo stesso carrier nel DN e nel picking
- l10n_it_intrastat_statement restore move date instead of invoice date when compute intrastat statemet lines
- Consistenza nel segno dei gruppi di conto
- L'importo totale non corrisponde con lo stesso importo totale della fattura elettronica
- Prima riga e pagina Libro giornale reportlab non corretta per stampe suddivise
- l10n_it_delivery_note: aggiornare report per trasferimento interno
- [FIX] l10n_it_declaration_of_intent: controllo dichiarazione solo se tipo fattura
- l10n_it_ricevute_bancarie do not group riba with cig cup
- [10.0][FIX] l10n_it_vat_registries - somma errata nell'imponibile dei registri iva quando ci sono valori negativi nella nota credito HOT 3
- l10n_it_fatturapa_in: In caso di eccezioni in creazione fattura, la precisione decimale, se modificata nel wizard, viene impostata diversa da quella originale
- [l10n_it_delivery_note] - riferimento SO e rif. cliente del SO in DN e report DN
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from l10n-italy.