Approval-tracking of expected expenses, mostly for transport

Especially with transport I am having some trouble keeping track of transports that have been carried out, but not invoiced and paid.

For example I order some product, I pick up using a transporter who invoice every transport,
I receive a quote, I accept the quote and invoice it on to the customer.

Then a month passes, and I forget what transports I have approved but not paid, and then I receive an invoice which I do not know if it should be paid or not.

account_stock_landed_cost and account_stock_shipment_cost: Does not help because it requires a posted supplier invoice, which is received after I already forget what I approved.

purchase_shipment_cost
sale_shipment_cost
stock_shipment_cost

These allow to define the cost for the shipment, but I do not see how to reconcile shipment with payment for shipment before having the invoice.

I do not think what you are requesting is implemented but it is something interesting, specially if we just focus on the transport part. We have implemented a custom solution for one of our customers this week that tries to solve the same problem.

The idea is to define on the carrier if the service is externally purchased, so in such case when a cost is allocated for the carrier (when a shipment is done with the related carrier) the system generates a supplier invoice line for the carrier with the cost of the shipment.

This way at the end of the month, you have a list of supplier invoice lines for the carrier (one for each shipment sent with them) and you can check that the carrier is not invoicing more (or less) than expected.

Do you think that may solve to solve your problem?

I tought It may be interesting to have a standard module for it but I did not find motivated to start the contribution process.

Why not create a confirmed supplier invoice at that time?

Usually you receive a grouped invoice for the month for example. I do not think it helps to have detailed lines.

If you want to check if the invoice is correct, you need to check the agreed cost of all lines with the full detail. Or at least, be able to know which shipments are included on each invoices and ensure the total amount is the same.

No you just need to have the same total.

I guess you can have this information from the carrier invoice.
So it is just a matter of having shipment cost working the other way or at least compute the cost total of selected shipments and than create the corresponding invoice/line.

I understand Shipment cost as cost for Company running tryton.
In this case, the shipment cost will be paid by company one way or another, either through carrier invoice, or through a line on supplier invoice. Right?

In this case maybe it can be a good idea to reconcile stock shipment cost with invoice line (on carrier or on supplier because maybe he invoice you the transport)

I mean we already have the carrier party.
If the carrier add shipment cost, I guess it should be implicit that the company is paying?

For now the Shipment Cost document is used to update the cost of the shipments (which usually is just a prediction) with the real invoiced cost.
So the current workflow is to post the supplier/carrier invoice and then link the invoice lines to the corresponding shipments.

So I propose that the same document could be use in the other direction. You select the shipments and it compute the total from the shipments and then you can create/accept the supplier/carrier invoice (because the total match or almost match).

Is there then a way to check for details if the totals do not correspond?

How can the carrier invoice lines be linked to the proper shipments?
AFAIK there is no relation for that as we are not relating with stock moves (which exists) but to the full shipment.

That is an option that we already considered and I probably it makes more sense to have as default because it simplifies a little bit the workflow.

From the user prespective, what is important is to know if the shipment has been invoiced by the carrier (in which invoice) or not.