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 <[email protected]>: > -----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: [email protected] > 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 : [email protected] > Unsubscribe : https://launchpad.net/~openerp-community > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
