Digital/Electronic shipment sheet part of E-Reporting

[sonikf]

Feature Request

According to EU proposal

https://taxation-customs.ec.europa.eu/taxation/vat/vat-digital-age-vida_en

VAT in the Digital Age (ViDA) will eventualy replace Vies. E-invoicing and e-reporting will be mandatory across Europe by 2030

Some more info and timeline

https://www.grantthornton.ie/insights/factsheets/vat-in-the-digital-age-vida-approaches/ https://www.vatcalc.com/eu/eu-vat-in-the-digital-age-vida-adopted-by-ec/

Top five implementations based on results are from Greece, Italy, Poland, Portugal and Spain and reports for these member states will act as reference for the rest.

Contributors from above countries please advise on following feature request

EU member states have already started ahead of schedule. In Greece starting from 1/4/2025 Digital/Electronic shipment sheet will be mandatory for all legal entities Starting from 1/7/2025 E- invoicing will be mandatory for all legal entities(another issue will follow)

Based on Greek implementation api, new fields(SQL part) should be added to core to also facilitate future core or module implementations

Use case

Implementation for simple shipment Process made easy through scanning single QR code

For ease of use an invoice can act also as shipment so new fields needed in both tables French Chorus pro Greek equivalent screenshot

Suggested implementation

Field	Type	Description	Dolibarr
IssueDate	date	shipment issue date	llx_facture OK llx_expedition KO
correlatedInvoices	BigInt	correlated invoices	llx_facture KO llx_expedition KO
qrCodeUrl	string	response received after issue of invoice	llx_facture KO llx_expedition KO
dispatchDate	date	shipment start date	llx_facture KO llx_expedition KO
dispatchTime	time	shipment start time(when vehicle is loaded and ready to begin)	llx_facture KO llx_expedition KO
vehicleNumber	string	licence plate of vehicle	llx_facture KO llx_expedition KO
movePurpose	int	Purpose of movement from list/dictionary of values..	llx_facture KO llx_expedition KO
otherMovePurposeTitle	string	other purpose not in list	llx_facture KO llx_expedition KO
isDeliveryNote	bool	only facture	llx_facture KO
loadingAddress	*AddressType	Could also be warehouse, branch, storing facility, contact full address....of issuer	-
deliveryAddress	*AddressType	Could also be warehouse, branch, storing facility, contact full address....of customer	-
startShippingBranch	int	Dispatching Start Location (Issuer)	-
completeShippingBranch	int	Receiving End Location (Recipient)	-

*AddressType	Field	Type	Description	Dolibarr
street	string	-	-
number	string	-	-
postalCode	string	-	-
city	string	-	-

-	-	LINES	-
TaricNo	string	TARif Intégré Communautaire; Integrated Tariff of the European Communities varchar(10)	llx_facturedet KO llx_expeditiondet KO
itemDescr	string	Item Description	llx_facturedet OK llx_expeditiondet KO
itemCode	string	Item Code varchar(10)	llx_facturedet KO llx_expeditiondet KO
measurementUnit	int	fk_unit	llx_facturedet OK llx_expeditiondet KO

Suggested steps

No response

[eldy]

I don't think we should include fields related to manage the push on external system (like chorus pro or similar in other country) into table llx_facture. We will surely have need to push soon in more than 1 system, so i think a separated table that could work for both invoice and shipment must be introduced instead of fields in existing tables.

[sonikf]

Hi @eldy Thanks for taking the time I came to the same conclusion as you and already working on it Still some fields i think should be introduced in existing tables	Field	Table	reason
fk_unit	llx_expeditiondet	for pieces, packs etc
datee	llx_expedition	issue date same as datef in llx_facture
isDeliveryNote	llx_facture	to differentiate from standard invoice
correlatedInvoices	llx_facture	would be useful also for projects,situation invoices etc