openerp-community team mailing list archive

[Ana Juaristi <ajuaristio@xxxxxxxxx>]

Just an small remark about how is it made in Spain. It's conceptually so
simple as applying a fixed discount to global amount on invoice and also on
any tax.
That is.. Having several lines making 100 EURO total + 5% global discount +
21%tax in any line we should only apply 21% tax to 95 EURO amount.
As openerp is only calculating discounts by line we use to solve applying
5% discount on every line but this would not be valid in several cases
where each line has got their own discount.

We have got another issue here where a lot of customers use to apply
chained discounts like 45% + 5%. Price should be obtained first applying
45%and after 5% on result that is different to apply directly 50%.

There is several community modules named global discount, thee discounts,
additional discount (i could count more than 5 different modules on apps
5.0, 6.0 and 6.1) trying to cover all casuistic for global discounts and
offers but i think none of them is covering properly full process from
sales to payment.

The case of applying discount only if customer pays in time is not necesary
here. We just need having correct discounts on invoice so i think it's much
more simple to cover.
Just my 2 cents.
Ana
El 14/02/2014 15:59, "Thorsten Vocks" <thorsten.vocks@xxxxxxxxxxxxxxxxxx>
escribió:

> Hi Holger,
>
> nice to hear that you pick it up again. We have developed a working
> solution for cash discount (including  integrated tax correction) some
> years ago. Deep introduction of account_voucher into V6.0 broke the
> functionality and due to overhead of complexity we decided to explain
> customers from that time how to deal with that situation.
>
> Here you find the (V5 compatible) sources:
> http://bazaar.launchpad.net/~openbig/bigconsulting/addons/files/head:/account_invoice_cash_discount/
>
> The 6.1 module you have taken as base ground (Ferdinand) seems to cover
> some
> parts of requirements. Anyway as you know in the meantime the
> reconcilation feature changed a lot and still i think it doesn't cover
> basic things (f.e. tax in bank statements), which makes analysis /
> specification / functionality testing of 6.0/6.1modules not even easier.
>
> I am very interested in testing your module.
>
> I will explain the (workaround) solution i propose: "Use write-off
> functionality"
>
> Given EXAMPLE:
>
> *100 EURO income + 19% tax , 2% cash dicount)
> * example customer payment is done in time frame of cash discount
>
> Workaround steps:
>
> 1. Usage of write-off functionality on payment (enter payment amount:
> 116,62)
> 2. Choose the correct write of account (f.e. "8888 cash discount brutto
> 19% -> 2,38)
> 3. Correct manually in separate Journal min. 1 time a year the included
> tax amount:
>
> Here for 1 invoice: 2,38 * 19/119 = 0,38
>
> 4. Posting a manual account move in a specific journal "Tax Correction",
> which allows
> additionally to edit the fields "tax", "tax" and "tax_base":
>
> 8888 Cash Discount Brutto       2,38
> vs. Tax                                   0,38
> vs. 8887 Cash Discount Net     2,00
>
> This should be correct way and except the volume is extreme, nobody will
> complain against that practise (It is not 100% correct regarding periods).
>
> If "tax include" functionality would work in combination write-off
> functionality this would be perfect and still flexible solution. IMHO this
> doesn't work as i know.
>
> EVENTUALLY i would wish: Boolean field to decide if tax correction should
> be applied or not (case to case decision)
>
>
> Further potential issues to regard if they are relevant or can be ignored:
> - coverage of refunds
> - incompatibility if additional export tools if they are used (interfaces
> to DATEV)
> - incompatibility to account_voucher (no automated detection)
> - different requirements / solutions for customer / supplier invoices
> - compatibility to bank frameworks (does it break the mapping logic, does
> it detect if cash discount should be deducted or not ...)
>
>
> Further remark:
>
> Why does this issues not exist in other countries ?
>
> As i know Spain + Italy doesn't allow to correct tax of declared invoices
> after payment date. These countries apply refunds before invoicing. For
> sure this doesn't motivate a company to offer such payment terms (if they
> finally have to pay too much taxes).
>
> It is stupid german tax system allowing such things. On the other hand it
> is a instrument to motivate customers to pay in time. Anyway i know ERP
> systems in germany applying logic like: "Deduct cash discount in any case"
> (means a payee is deducting cash discount either if it is allowed (=in
> time) or not. ...
>
>
> Thanks for your initiative to pick up that neverending accounting nerds
> topic again.
>
>
> Thorsten Vocks
>
> openBIG.org
>
>
>
>
> 2014-02-14 11:25 GMT+01:00 Holger Brunn <hbrunn@xxxxxxxx>:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Hello community,
>>
>> in Austria and Germany, you would offer your client a discount when
>> paying early. So you write a usual invoice, but the payment terms say
>> that you are allowed to subtract 5% of the total amount when paying
>> within a week and 3% when paying within two weeks. This is to give
>> customers an incentive to pay as soon as possible.
>>
>> First question: Do other countries have sort-like arrangements and how
>> is it called there?
>>
>> Given that you don't know when the customer is going to pay, you'll
>> have to invoice the full amount and see what happens. From the OpenERP
>> point of view, this means you'll have to fiddle with the already
>> posted move for the invoice.
>>
>> There is a port of account_cash_discount which implements that:
>> https://www.openerp.com/apps/7.0/account_cash_discount_61/ , but with
>> some drawbacks (no multiple discounts, too much raw sql in the code
>> imho), so I reimplemented that and proposed it to account invoicing:
>>
>> https://code.launchpad.net/~therp-nl/account-invoicing/7.0-account_cash_discount/+merge/203359
>>
>> My second question would be if some Austrian/German (or other
>> countries where that's relevant) developers could have a look at it?
>> For discussions, we maybe better use the MP instead of the list.
>>
>> I'll soon start working on the possibility to also accept a
>> configurable amount of deviation. Currently, if there's a discount of
>> 5%, you have to pay exactly 95% for the magic to work, so if you pay
>> EUR95 for a EUR100.10 invoice, it won't be seen as payment with the
>> discount. In practice, businesses would want to accept that.
>>
>> Thanks in advance for your input,
>> regards,
>> Holger
>>
>> - --
>> Therp - Maatwerk in open ontwikkeling
>>
>> Holger Brunn - Ontwerp en implementatie
>>
>> mail: holger@xxxxxxxx
>> web: http://therp.nl
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>>
>> iF4EAREIAAYFAlL97zEACgkQAcl2D+yjrhjCzwD/VnaWDsccg2pllCPYJAEg+Wgj
>> Y9wSZe4ZwjZsx1Z3AeQA/j+TsuCNzHMAa6ii3xsV11snEMFN/dqDEmccPvr/Ichh
>> =STUO
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>