unless someone speaks up of
course.
They were replaced around 3-4 years ago.
I don't think this is the case, but before we totally remove each from the data model we should search around the code base and
see if anything is referring to them.
I already checked for taxVatCode will do the 2
efore we totally remove each from the data model we should search around the code base and
see if anything is referring to them.
I already checked for taxVatCode will do the 2 others as well
Jacques
About taxCategory, it seems straightforward but should we keep ? (I don't think
so but I ch
earch around the code
base and see if anything is referring to them.
I already checked for taxVatCode will do the 2 others as well
Jacques
-David
Jacques Le Roux wrote:
In
http://www.nabble.com/Re%3A-VAT-vs-Sales-Tax-again-and-again-p15313132.html
Christian proposed to remove the field taxVatC
them.
-David
Jacques Le Roux wrote:
In
http://www.nabble.com/Re%3A-VAT-vs-Sales-Tax-again-and-again-p15313132.html
Christian proposed to remove the field taxVatCode from UI
I'd like to remove fieldstaxCategory
taxVatCode
taxDutyCode
not only from UI but completly from OFBiz. T
In http://www.nabble.com/Re%3A-VAT-vs-Sales-Tax-again-and-again-p15313132.html
Christian proposed to remove the field taxVatCode from UI
I'd like to remove fields
taxCategory
taxVatCode
taxDutyCode
not only from UI but completly from OFBiz. They are no longer used for years
ow Big
> > Decimal for prices this is not a problem (except in POS where I hope
to change that "soon")
> >
> > Before describing my proposition (very simple actually, because I
can't see any other means) I want to be sure that taxVatCode is
> > not used anymore
xcept in POS where I hope to
> change that "soon")
>
> Before describing my proposition (very simple actually, because I can't see
> any other means) I want to be sure that taxVatCode is
> not used anymore (catalog/product screen). I can't see any use of it except
Hi Chris,
> side note: on the std response, is it possible for your mail client
not
> to send a reply-to field in the headers when replying to mailing
lists?
> I'll try to keep a better eye on my replies, but that would be the
> root cause.
I use Outlook Express, not sure how to tune it for that
guess this is applicable for other
> > > similar
> > > > > types of taxes. Actually a gross prices is composed of 2
> parts :
> > > net prices (without tax) and tax. At some point it may be
> > > > annoying
> > > > > to loose precision abo
nt to enter gross prices we
>> have to make some choices. And at the end, reconstructing
>> the
>> > gross prices from the 2 parts seems easy. If we keep enough information
>> (ie decimals) this might be manageable. As we use now
> Big
>> > Decimal for price
> > prices we have to make some choices. And at the end, reconstructing
> > > the
> > > > gross prices from the 2 parts seems easy. If we keep enough
> > information (ie decimals) this might be manageable. As we use now
> > Big
> > > > Decimal fo
ng
> >>> to loose precision about them; but if we want to enter gross
prices we have to make some choices. And at the end, reconstructing
> >> the
> >>> gross prices from the 2 parts seems easy. If we keep enough
information (ie decimals) this might be manageable. As we use
r prices this is not a problem (except in POS where I hope to change that
"soon")
Before describing my proposition (very simple actually, because I can't see any
other means) I want to be sure that taxVatCode
is
not used anymore (catalog/product screen). I can't se
n about them; but if we want to enter gross
> prices we have to make some choices. And at the end, reconstructing
> > the
> > > gross prices from the 2 parts seems easy. If we keep enough
> information (ie decimals) this might be manageable. As we use now
> Big
> > >
o
> > change that "soon")
> >
> > Before describing my proposition (very simple actually, because I can't see
> > any other means) I want to be sure that taxVatCode
is
> > not used anymore (catalog/product screen). I can't see any use of it exce
cimals) this might be manageable. As we use now Big
> Decimal for prices this is not a problem (except in POS where I hope to
> change that "soon")
>
> Before describing my proposition (very simple actually, because I can't see
> any other means) I want to be sure that tax
nough information (ie
decimals) this might be manageable. As we use now Big
Decimal for prices this is not a problem (except in POS where I hope to change
that "soon")
Before describing my proposition (very simple actually, because I can't see any
other means) I want to be sure th
17 matches
Mail list logo
