here is our standard workflow on the Sales Side.
> Sales Order
> Sales Invoice
> Delivery Note
Imagine a scenario where you are shipping more Ordered. You will have to bill that and collect payment.
This is easy once you ship the goods (Delivery Note created from Sales Order) and then create another SINV from that Delivery Note. However I can not figure out the correct way to do this before submitting the Delivery Note (in other words before you are physically handing out goods to a shipment company).
I believe it is not possible to create a second invoice invoice with excess goods from the original Sales Order. Creating a second Sales Order only for overdelivered items neither seems to be logical to me.
can anyone advise how this can be achieved?
I feel delivery note is not in the right place?
it should be before sales invoice and after sales order, correct me if I am wrong.
second did you try this option from accounts setting
also try use
instead of payment doctype
you are wrong for the usecase here. I guess the sequence of a Sales workflow can be different given the particular circumstances or company policies.
In the usecase I am discussing here it is as described. Payment is being done before delivery. Even if this is not the standard procedure for every company it is a completely legitimate process.
So, there must be a way to fully bill excess quantities before issuing a Delivery Note
see enter independent payments, deliver, then generate invoice, finally do reconcile payment with invoice
I won’t be able to receive a payment without issuing an invoice before.
what I need *in that exact sequence) is to …
- notify the customer (in the form factor of an invoice [or at least some equivalent to that]) how much she has to pay for excess goods for that particular Sales Order
- collect the payment
- ship the goods
I do not see how your suggested sequence
can be aligned to that really.
The only workaround I could think of was to …
- create the invoice for excess items manually
not submit that invoice but print out the draft
- collect the payment based upon that draft
- Submit the SINV after/with receipt of payment
- deliver for the original plus the secondary Invoice
I such a scenario I would not have any connection between then original Sales order and the secondary Invoice then, right?
Also this seems like really having to stretch the system to it’s limits without really have the feeling that this is a clean way to do such kind of thing
you can set Delivery Note Required from Selling > Selling Settings > Delivery Note Required : No and create invoice before delivery against Sales Orders. And change Over Billing Allowance.
and you can edit the sales order item quantities and make only one Delivery note at end, and create last Sales İnvoice with remaining amount.
Tx, i‘ll Look into that
I am aware I can do that technically, but don’t think it’s good practice to change a SO unless the customer has added anything (which is not the case in a scenario like this)
EDIT: Also, and even more relevant here … you can not update item qties once a Sales Ivnoice has been generated from that PO (just chekched in a v11 & v12 instance)
apparently This (
Delivery Note Required : No) is the default.
And yes I can create an Invoice out of thin air, but there will not be any connection to the SO these excess quantities stem from.
another downside … you have to calculate the excess quantities outside of ERPNext manually which is and unnessecarrily error-prone procedure. The Kombination SO/Delivery Note detext the differences for you (which is what en ERP System should be all about)
So this is not a solution I am afraid.
I finally figured it out somehow. You create basically 2 Workflows which are at the end connected in the Delivery Note. I was not aware that you could generate a DN from a Sales Order directly, so I did not come up with this earlier.
- PO1 > SINV1 > PE1
- SINV2 > PE2 > Delivery (from SINV2, & also use
Get Items from PO1
it’s not the most beatiful solution I could imagine because there is no connection between SO1 & SINV2, neither any connection between SINV2 and the DN and likewise no direct hint that the reason for PINV2 actually is overproduction of SO1 though. But at least something that kind of covers everything to some extent.
So I believe this is a gap in functionality that needs to be closed
thx @nmami & @emre for your contributions.