openerp-community team mailing list archive

[Thorsten Vocks <thorsten.vocks@xxxxxxxxxxxxxxxxxx>]

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 € 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
>