openerp-expert-accounting team mailing list archive

[Cloves Almeida <cjalmeida@xxxxxxxxx>]

For refunds, I don't think you should recalculate return price based on 
quantity, better just to use averages. If a customer is "gaming the 
system" by issuing too many refunds just to benefit from the volume 
discount, IMO you have a sales problem, not an accounting one :)


Parthiv Patel escreveu:
> Hi,
>
>     I have just been through this issue. IMHO is that for refund
>     invoice we can keep the association with Customer / Supplier
>     Invoice, and from that invoice, we can get the invoice lines and
>     from those line we can get the prices. We need to maintain list of
>     refunds for the same invoice.
>
>     But again even in this case, if product prices are calculated
>     based on qty (for example : for 1 product $5, for 2 price is $8,)
>     then at the time of return of 1 product either recalculation has
>     to be done for refund or manual intervation is needed . which i
>     think will lead to same situation.
>
>     The second solution can be a date based price list maintenance.
>     Instead of changing the values directly in price list. One must
>     create the new price list to avoid such conflicts.
>
>     I would also looking forward for views of other accounting experts
>     for the same.
>
> Thanks & Regards,
> Parthiv
>
> On Fri, Feb 26, 2010 at 2:39 PM, Jan Verlaan - Veritos 
> <jverlaan@xxxxxxxxxx <mailto:jverlaan@xxxxxxxxxx>> wrote:
>
>     Hi accounting experts,
>
>     There is a bug found for Refund pickings and corresponding
>     invoices when the product price has changed between creating the
>     initial invoice and creation of the refund.
>
>     Refund Invoice takes the actual price of the products to make the
>     cost of sales move
>     https://bugs.launchpad.net/openobject-addons/+bug/527120
>
>     It figured out that always the product standard price is taken for
>     a refund, despite if this prices has changed, while it should take
>     the standard price at the moment the product is invoiced.
>
>     We came across a theoretical solution to solve this issue, but
>     maybe there is a better solution to come up with.
>     I can imaging that we need for stable a other solution as for
>     trunk, where we have more possibilities to add table fields.
>     You input is highly appreciated, will you have a look?
>     -- 
>     ------------------------------------------------------------------------
>
>     Met vriendelijke groet,
>
>     *Veritos - Open Source Business Solutions
>     Jan Verlaan CPIM*
>
>
>     _______________________________________________
>     Mailing list: https://launchpad.net/~openerp-expert-accounting
>     <https://launchpad.net/%7Eopenerp-expert-accounting>
>     Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
>     <mailto:openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~openerp-expert-accounting
>     <https://launchpad.net/%7Eopenerp-expert-accounting>
>     More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> Thanks & Regards,
> Parthiv Patel
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-accounting
> Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
> More help   : https://help.launchpad.net/ListHelp
>