Community mailing list archives

community@mail.odoo.com

Re: Accounting v9: updated specifications

by
dar
- 11/20/2014 12:26:44
Hi Fabien, sorry for delay: Best, David
Why do you need to separate retention taxes and normal taxes? Is this
because:
  - they are not displayed on the invoice
 
-> NO​ / the existing concept of hiding away taxes is good enough (although it probably is already necesarily scheduled for improvement, as we quit the concept of tax codes +1000!)
 

  - they are grouped in the printing of the invoice
 
-> YES, they apply after the subtotal as "Retentions/Perceptions", the total get`s the syntactical meaning of "TO PAY" (as beeing different to "TOTAL amount of the inovice")​ - On the list view, for example, you want to know, how much did it cost a) without taxes, how much it was b) taxes included, and how much c) retention/perception was applied
 

  - they are computed differently
 
-> NO they behave like taxes (moving around percentages from one account to another, example: retentions with counterparty, or applying a real alteration on the invoice, example: normal perceptions, but they are syntactically different from taxes)


Is this like this?
  - Total - Retention = To Pay?
​CORRECT, but could be also: TOTAL +(!) PERCEPTIONS = TO PAY​
 

Thanks,

On 11/06/2014 01:27 AM, David Arnold wrote:
> *Hi Fabien*
> *Hi Community*
> *
> *
> I wanted to bother to follow up this discussion, as I fear it might have
> been forgotten neglegted. I wanted to ask feedback from Fabien/Odoo on
> my suggestion to his question NR3.
>
> On the other hand I wanted to raise to your attention the following
> situation:
>
> In almost all jurisdiction you would work with a internal accounting and
> a tributary accounting, so you would at least have two different
> acocuntings, if not more...
>
> Generally you start from the internal accounting, and apply a delta to
> get to the different versions of reality. (Example, an invoice does not
> count as fiscally deductable, so the fiscal reality would be as if this
> invoice never existed, or you would rather take it to another special
> account)
>
> This process might be quite common but until now lacks a
> conceptualization (please can you confirm...)
>
> So my suggestion is to might be able to tag movelines as DELTA-LINES
> (lines that alterate) which only serve the purpose of adapting the
> internal accounting to the tributarian or other. Those lines never
> should be actually applied, but maintained in a "waiting state" unless
> you want a report which considers those movelines as beeing applied. -
> This is by the way inline with the pattern of postponing the processing
> of aggregational information towards report time (see CoA concept).
>
> Dear Community, may I ask you about your opinion about this idea and
> probably even the previous suggestion concerning the "tax included"
> question.
>
> *Thanks,* David
>
>
> *
> *
>
> <http://www.elaleman.co/>
>
> *Saludos Cordiales*
> David Arnold
> ​ <http://www.elaleman.co/>
>
> David Arnold BA HSG / Analista
> 315 304 13 68/ dar@devco.co <mailto:dar@devco.co>
>
> *devCO - empresa de consultoría de sistemas (en fundación)*
> http://www.devco.co
>
> This e-mail message may contain confidential or legally privileged
> information and is intended only for the use of the intended
> recipient(s). Any unauthorized disclosure, dissemination, distribution,
> copying or the taking of any action in reliance on the information
> herein is prohibited. E-mails are not secure and cannot be guaranteed to
> be error free as they can be intercepted, amended, or contain viruses.
> Anyone who communicates with us by e-mail is deemed to have accepted
> these risks. devCO is not responsible for errors or omissions in this
> message and denies any responsibility for any damage arising from the
> use of e-mail. Any opinion and other statement contained in this message
> and any attachment are solely those of the author and do not necessarily
> represent those of the company.
>
>
> 2014-10-29 18:56 GMT-05:00 David Arnold <dar@devco.co
> <mailto:dar@devco.co>>:
>
>     *THE MOST IMPORTANT COMMENT IS ON 3 !!!!!!!!*
>
>     *1/* does anyone use "Python" computed taxes for another reason than:
>     rounding (at 0.05 in Switzerland) or division computation (like in
>     Bolivia or Brazil)
>
>     -> The "provide hooks/inhertits" is the way to go. Then, there would not be the localdict restriction and would be hidden away from the user, and left ofer to l10n developers. *Please quit.*
>
>     *2/* does anyone have refund Tax accounts that are different from the tax
>     account of the related invoice? (I mean account.account, not
>     account.tax.code)
>
>     -> The risk of oversimplification might be present, and this part does not seem overly complex to me. *Please keep.*
>
>     *3/* do you sometimes have for THE SAME invoice, some lines which are with
>     tax included in price and other lines with tax excluded of the price?
>
>     -> Fabien, I have a* compelling and innovative* proposal on how to solve this, which is perfectly in line with your spimlification vision.
>
>     *-> Please analyze the difference (yellow - orangish) between the following two mockups:*
>
>     *https://gomockingbird.com/mockingbird/#zq0em7d/mBiAW
>     *
>
>     *https://gomockingbird.com/mockingbird/#zq0em7d/g1JeG5
>     *
>
>     *-> Please ask, if the idea is not clear. PLEASE!*
>
>     *4/* did you ever needed a tax with two levels? (a tax that has children
>     and those children also have children)
>
>     -> Leave this complexity to l10n. *Please quit.*
>
>
>
>     <http://www.elaleman.co/>
>
>     *Saludos Cordiales*
>     David Arnold
>     ​ <http://www.elaleman.co/>
>
>     David Arnold BA HSG / Analista
>     315 304 13 68/ dar@devco.co <mailto:dar@devco.co>
>
>     *devCO - empresa de consultoría de sistemas (en fundación)*
>     http://www.devco.co
>
>     This e-mail message may contain confidential or legally privileged
>     information and is intended only for the use of the intended
>     recipient(s). Any unauthorized disclosure, dissemination,
>     distribution, copying or the taking of any action in reliance on the
>     information herein is prohibited. E-mails are not secure and cannot
>     be guaranteed to be error free as they can be intercepted, amended,
>     or contain viruses. Anyone who communicates with us by e-mail is
>     deemed to have accepted these risks. devCO is not responsible for
>     errors or omissions in this message and denies any responsibility
>     for any damage arising from the use of e-mail. Any opinion and other
>     statement contained in this message and any attachment are solely
>     those of the author and do not necessarily represent those of the
>     company.
>
>
>     2014-10-28 11:27 GMT-05:00 Marc Cassuto
>     <marc.cassuto@savoirfairelinux.com
>     <mailto:marc.cassuto@savoirfairelinux.com>>:
>
>         Hello all,
>
>         answers for Canada :
>
>
>         > 1/ does anyone use "Python" computed taxes for another reason than:
>         > rounding (at 0.05 in Switzerland) or division computation (like in
>         > Bolivia or Brazil)
>         No
>
>         > 2/ does anyone have refund Tax accounts that are different from the
>         > tax
>         > account of the related invoice? (I mean account.account, not
>         > account.tax.code)
>         No
>
>         > 3/ do you sometimes have for THE SAME invoice, some lines which are
>         > with
>         > tax included in price and other lines with tax excluded of the price?
>         No
>
>         > 4/ did you ever needed a tax with two levels? (a tax that has
>         > children
>         > and those children also have children)
>         We did but not anymore since January 1st, 2013
>
>         Regards,
>         Marc
>
>         _______________________________________________
>         Mailing-List: https://www.odoo.com/groups/community-59
>         Post to: mailto:community@mail.odoo.com
>         <mailto:community@mail.odoo.com>
>         Unsubscribe: https://www.odoo.com/groups?unsubscribe
>
>
>
> _______________________________________________
> Mailing-List: https://www.odoo.com/groups/community-59
> Post to: mailto:community@mail.odoo.com
> Unsubscribe: https://www.odoo.com/groups?unsubscribe
>


--
Fabien Pinckaers
Odoo Founder

Phone: +32.81.81.37.00
Web: https://www.odoo.com
Twitter: @fpodoo

Instant Demo: https://odoo.com/start