I am very interested in testing your module.
I will explain the (workaround) solution i propose: "Use write-off
functionality"
Given EXAMPLE:
*100 EUR 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
<mailto: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
<https://code.launchpad.net/%7Etherp-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 <mailto: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
<https://launchpad.net/%7Eopenerp-community>
Post to : openerp-community@xxxxxxxxxxxxxxxxxxx
<mailto:openerp-community@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openerp-community
<https://launchpad.net/%7Eopenerp-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
