In case customer returned the below items and took the money back.
Create a Sales Return against Delivery Note. Against a Sales Invoice, create a Credit Note, with “Is Paid” checked".
Customer returned the below items and purchased other items of the same value of the returned items(Item C and Item D)
Create a Sales Return against Delivery Note. Make a new Delivery Note against a Sales Order for the replacement item.
Customer returned the below items and purchased other items of different value of the returned items(Item C and Item D), Value can be more or less, both cases.
Create a Credit Note and Sales Invoice for the original Sales Invoice. Create a new Sales Invoice for the new items. In the payment entry, you should be able to keep both the invoices and pay only the difference amount.
Hi @umair, this is the post that comes closest to determining the problems with returns. Case 2, restrictive by code, is one of the most normal cases.
To all this could be added the cases of return and reuse of money, without using the form of the journal entry that is not very intuitive.
They are elementary issues for retail, and we usually create many PR with my team (which lately are all corrections and still do not accept them in V11 ), but this exceeds us, and we do not understand why they do not give importance, as they are reason for filtering when choosing an ERP.
If in this or another post, you can define well the requirements, and that can impact, we can take charge of the development, but usefully not even in github we are having an answer.
These issues are not exclusive to ratail, we are simply talking about any company that manages stock.
Not to mention the accounting issues related to credits and use credit notes as a balance.
We can discuss it and develop a new topic, but we are having a hard time accepting PRs or simply expressing an opinion about it (besides being correct or not, it goes to V12).
The case 2 of your examples, is the one that we should prioritize since it is the simplest and most common case, and we see some complexity in which would be the correct form (for example, to take out the condition that allows to make a DN, it is not feasible, because the process of sale is wrong. another example, to use a button like the one that has the OV, to update items, neither we understand if it is correct that it is invoiced to another product in case that only modifies the order of sale, and allows to deliver this new product).
This case alone has several issues that we need to help us validate, and not waste time then reject the PR.