Tax included in price for sale and invoice.

33 views
Skip to first unread message

Christophe (net)

unread,
Jan 20, 2014, 9:41:52 AM1/20/14
to tryto...@googlegroups.com
Hi,
I return to the subject of the sales price with tax included.
I have carefully read the blue print and I have followed the discution
with Cedric on TUB2013, the general idea had concensus was to define a
object dedicated for these sales. If I agree with this idea, the
implementation is heavy (many module to modify based on this new object:
sale_pos, nereid, ...) , this weekend I decided to overload the Sale
object and Invoice object to allow sales management with prices tax
included.
This new module (sale_b2bc) depends on the module sale_shop from
ZikZakmedia.
In summary:
- Adding a flag on products to indicate if the list_price is tax included
- Adding a choice to the store to indicate if sales can be made ​​tax
included, tax excluded or both
- Adding an option to object Sale to indicate if price is tax included
or not.
- Change the calculation of taxes on sale and invoice to add tax
included possibility
- Modification of invoice object to adding tax included calculation like
sale.
- Modification of the generation of accounting entries

what remains to be done
- The integration with stock management : valuation movements and
invoice creation from deliveries
- Add the installation procedure for PyPI
- Add unit tests
- Add doc
- And tests, tests and still test :-)

You can find the repository of the dev version here:
https://gitorious.org/ate_modules/trytond-sale_b2bc : branch dev_3.0

Regards
--
Christophe
Adiczion
Tél : +33.6.65.59.39.68

Albert Cervera i Areny

unread,
Jan 20, 2014, 1:11:52 PM1/20/14
to tryto...@googlegroups.com
2014/1/20 Christophe (net) <c...@adiczion.net>:
> Hi,
> I return to the subject of the sales price with tax included.
> I have carefully read the blue print and I have followed the discution with
> Cedric on TUB2013, the general idea had concensus was to define a object
> dedicated for these sales. If I agree with this idea, the implementation is
> heavy (many module to modify based on this new object: sale_pos, nereid,
> ...) , this weekend I decided to overload the Sale object and Invoice object
> to allow sales management with prices tax included.
> This new module (sale_b2bc) depends on the module sale_shop from
> ZikZakmedia.
> In summary:
> - Adding a flag on products to indicate if the list_price is tax included
> - Adding a choice to the store to indicate if sales can be made tax
> included, tax excluded or both

I'd separate the shop/store module from the tax included one. I think
there's no need to depend on stores...

> - Adding an option to object Sale to indicate if price is tax included or
> not.
> - Change the calculation of taxes on sale and invoice to add tax included
> possibility
> - Modification of invoice object to adding tax included calculation like
> sale.

I think invoice should be done in a different module. By the way, did
you take into account account_invoice_line_standalone? It should not
be possible to mix lines with tax included with lines with tax
excluded in the same invoice.

> - Modification of the generation of accounting entries
>
> what remains to be done
> - The integration with stock management : valuation movements and invoice
> creation from deliveries
> - Add the installation procedure for PyPI
> - Add unit tests
> - Add doc
> - And tests, tests and still test :-)
>
> You can find the repository of the dev version here:
> https://gitorious.org/ate_modules/trytond-sale_b2bc : branch dev_3.0

I could not see the code. Just the .gitignore file...

Note that Cédric preferred to have slightly different objects sharing
a large common base for managing both types of sales on the grounds
of:

- Tax included/excluded was a very important information that made it
not a very good option to have all fields at sale line and use ones or
the others depending on a flag
- The workflow of sales could be different

That means that maybe your proposal it is hard it will be included in
Tryton as is, but I'm still very interested in it.

--
Albert Cervera i Areny
Tel. 93 553 18 03
@albertnan
www.NaN-tic.com

Cédric Krier

unread,
Jan 20, 2014, 1:31:04 PM1/20/14
to tryto...@googlegroups.com
On 20 Jan 15:41, Christophe (net) wrote:
> Hi,
> I return to the subject of the sales price with tax included.
> I have carefully read the blue print and I have followed the
> discution with Cedric on TUB2013, the general idea had concensus was
> to define a object dedicated for these sales. If I agree with this
> idea, the implementation is heavy (many module to modify based on
> this new object: sale_pos, nereid, ...) ,

Those module will have to be adapted any way.

> this weekend I decided to
> overload the Sale object and Invoice object to allow sales management
> with prices tax included.

That's very unfortunate.
Because it was clearly identify that the workflows were very different.

> This new module (sale_b2bc) depends on the module sale_shop from
> ZikZakmedia.
> In summary:
> - Adding a flag on products to indicate if the list_price is tax included

This will break any module that rely on list_price being tax excluded.
So it must be an other field.

> - Adding a choice to the store to indicate if sales can be made ​​tax
> included, tax excluded or both
> - Adding an option to object Sale to indicate if price is tax
> included or not.

What happens if changed after filled lines?
Why having such flag? As in any way, a unit price tax excluded should be
computed, why not just put it on the sale line?

> - Change the calculation of taxes on sale and invoice to add tax
> included possibility

The reverse tax computation should be interresting.

> - Modification of invoice object to adding tax included calculation
> like sale.

What is the point? Why would you want an invoice tax included? And what
does it mean?

> - Modification of the generation of accounting entries

The accounting should not be changed if you sale with tax included or
not.

> what remains to be done
> - The integration with stock management : valuation movements and
> invoice creation from deliveries

Don't understand this should have nothing to do with taxes.

> - Add the installation procedure for PyPI
> - Add unit tests
> - Add doc
> - And tests, tests and still test :-)
>
> You can find the repository of the dev version here:
> https://gitorious.org/ate_modules/trytond-sale_b2bc : branch dev_3.0

I doubt such module could be included.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

Christophe (net)

unread,
Jan 20, 2014, 1:34:33 PM1/20/14
to tryto...@googlegroups.com
Le 20/01/2014 19:11, Albert Cervera i Areny a �crit :
> 2014/1/20 Christophe (net) <c...@adiczion.net>:
>> Hi,
>> I return to the subject of the sales price with tax included.
>> I have carefully read the blue print and I have followed the discution with
>> Cedric on TUB2013, the general idea had concensus was to define a object
>> dedicated for these sales. If I agree with this idea, the implementation is
>> heavy (many module to modify based on this new object: sale_pos, nereid,
>> ...) , this weekend I decided to overload the Sale object and Invoice object
>> to allow sales management with prices tax included.
>> This new module (sale_b2bc) depends on the module sale_shop from
>> ZikZakmedia.
>> In summary:
>> - Adding a flag on products to indicate if the list_price is tax included
>> - Adding a choice to the store to indicate if sales can be made tax
>> included, tax excluded or both
>
> I'd separate the shop/store module from the tax included one. I think
> there's no need to depend on stores...
I put this dependency because I needed to choose whether a store can
make sales with taxe included or not, but this should be in a separate
module.

>
>> - Adding an option to object Sale to indicate if price is tax included or
>> not.
>> - Change the calculation of taxes on sale and invoice to add tax included
>> possibility
>> - Modification of invoice object to adding tax included calculation like
>> sale.
>
> I think invoice should be done in a different module.
Why, because if a sale is made with price with tax included invoice must
also tax included ?

By the way, did
> you take into account account_invoice_line_standalone?
Not in this version this is my first writing ...

It should not
> be possible to mix lines with tax included with lines with tax
> excluded in the same invoice.
Of course :-)

>
>> - Modification of the generation of accounting entries
>>
>> what remains to be done
>> - The integration with stock management : valuation movements and invoice
>> creation from deliveries
>> - Add the installation procedure for PyPI
>> - Add unit tests
>> - Add doc
>> - And tests, tests and still test :-)
>>
>> You can find the repository of the dev version here:
>> https://gitorious.org/ate_modules/trytond-sale_b2bc : branch dev_3.0
>
> I could not see the code. Just the .gitignore file...
change the branch : dev_3.0
>
> Note that C�dric preferred to have slightly different objects sharing
> a large common base for managing both types of sales on the grounds
> of:
>
> - Tax included/excluded was a very important information that made it
> not a very good option to have all fields at sale line and use ones or
> the others depending on a flag
> - The workflow of sales could be different
Yes, I wrote this module until the official version because I needed it
now, and to do some advance topic

>
> That means that maybe your proposal it is hard it will be included in
> Tryton as is, but I'm still very interested in it.
I do not think this module has now its place in the official version but
if it can help someone that is perfect ....

--
Christophe
Adiczion
T�l : +33.6.65.59.39.68

Cédric Krier

unread,
Jan 20, 2014, 2:31:47 PM1/20/14
to tryto...@googlegroups.com
On 20 Jan 19:34, Christophe (net) wrote:
> >
> >That means that maybe your proposal it is hard it will be included in
> >Tryton as is, but I'm still very interested in it.
> I do not think this module has now its place in the official version
> but if it can help someone that is perfect ....

So tryton-contrib is the right mailing list.
Here is about Tryton development so everything is looked in the
perspective of being included.

Christophe (net)

unread,
Jan 21, 2014, 2:10:51 AM1/21/14
to tryto...@googlegroups.com
Le 20/01/2014 20:31, Cédric Krier a écrit :
> On 20 Jan 19:34, Christophe (net) wrote:
>>>
>>> That means that maybe your proposal it is hard it will be included in
>>> Tryton as is, but I'm still very interested in it.
>> I do not think this module has now its place in the official version
>> but if it can help someone that is perfect ....
>
> So tryton-contrib is the right mailing list.
> Here is about Tryton development so everything is looked in the
> perspective of being included.
>

I had not seen this list, ok, my next post will be there
--
Christophe
Adiczion

Christophe (net)

unread,
Jan 21, 2014, 7:15:13 AM1/21/14
to tryto...@googlegroups.com


Le 20/01/2014 19:31, Cédric Krier a écrit :
> On 20 Jan 15:41, Christophe (net) wrote:
>> Hi,
>> I return to the subject of the sales price with tax included.
>> I have carefully read the blue print and I have followed the
>> discution with Cedric on TUB2013, the general idea had concensus was
>> to define a object dedicated for these sales. If I agree with this
>> idea, the implementation is heavy (many module to modify based on
>> this new object: sale_pos, nereid, ...) ,
>
> Those module will have to be adapted any way.

Yes of course but the change will be less important.

>
>> this weekend I decided to
>> overload the Sale object and Invoice object to allow sales management
>> with prices tax included.
>
> That's very unfortunate.
> Because it was clearly identify that the workflows were very different.

For my needs the current workflow enough and I needed to go fast.

>
>> This new module (sale_b2bc) depends on the module sale_shop from
>> ZikZakmedia.
>> In summary:
>> - Adding a flag on products to indicate if the list_price is tax included
>
> This will break any module that rely on list_price being tax excluded.
> So it must be an other field.

You're right, at first I needed to test the sales flow quickly for the
rounding error so I made this choice, but I just changed it to add
another field as you suggest.

>
>> - Adding a choice to the store to indicate if sales can be made ​​tax
>> included, tax excluded or both
>> - Adding an option to object Sale to indicate if price is tax
>> included or not.
>
> What happens if changed after filled lines?

After the first line this field is locked

> Why having such flag? As in any way, a unit price tax excluded should be
> computed, why not just put it on the sale line?

I have to keep the possibility of sales in 2 modes it had seemed wise to
leave the choice to the user.
Currently I do not calculate the VAT but the total price of the line HT

>
>> - Change the calculation of taxes on sale and invoice to add tax
>> included possibility
>
> The reverse tax computation should be interresting.
>
>> - Modification of invoice object to adding tax included calculation
>> like sale.
>
> What is the point? Why would you want an invoice tax included? And what
> does it mean?

Sometimes we need to make a invoice without a full sales flow, either
with price with tax include or not

>
>> - Modification of the generation of accounting entries
>
> The accounting should not be changed if you sale with tax included or
> not.

it seems to me that the amount of accounting movements (credit or debit)
is generated from the amount of the invoice line which in my case may be
include tax or tax excluded

>
>> what remains to be done
>> - The integration with stock management : valuation movements and
>> invoice creation from deliveries
>
> Don't understand this should have nothing to do with taxes.
>
>> - Add the installation procedure for PyPI
>> - Add unit tests
>> - Add doc
>> - And tests, tests and still test :-)
>>
>> You can find the repository of the dev version here:
>> https://gitorious.org/ate_modules/trytond-sale_b2bc : branch dev_3.0
>
> I doubt such module could be included.
>

I understand this position and I repeat this module is just that until
one of the official version.

--
Christophe
Adiczion
Reply all
Reply to author
Forward
0 new messages