You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Paul Foxworthy <pa...@cohsoft.com.au> on 2013/03/03 13:59:39 UTC
Re: Shipping - Adjustments vs Products
Hi all,
Adjustments can be for shipping, promotion (usually a discount when some
condition is met), and tax.
Shipping and promotion can be per item or once for the entire order.
Per-item adjustments are associated with an item, so if the item is changed
or removed, it's easy to update or remove corresponding adjustments.
Given we need per-item adjustments, per-order adjustments should be as
similar as possible, so I would argue should be adjustments and not items.
If there are no products, there's no order and there should be no
adjustments. I would only want to see a shipping product if my company is in
the shipping business. If I'm in some other industry, my customers would
never just order a shipping service from me.
I do think we should treat adjustments in a more general way, rather than
assuming that shipping, promotion and tax are all we'll ever encounter. So
any adjustment would have an adjustment type, we can create new ones if the
need ever arises, and we just communicate one collection of adjustments for
each item and one for the order, rather than splitting out promotion and
shipping.
Cheers
Paul Foxworthy
Jacques Le Roux wrote
> This means also some code changes, but yes maybe...
>
> Jacques
>
> From: "Adrian Crum" <
> adrian.crum@
> >
>>I have wondered that myself. It would make more sense if shipping was a
>> non-stock product.
>>
>> -Adrian
>>
>> On 1/25/2013 2:21 AM, Michael Alleblas wrote:
>>> Why are shipping charges an adjustment as opposed to a service and added
>>> just like any other product? This would allow taxation to be calculated
>>> as
>>> simply as it is for products.
>>>
>>> I may be missing something here, and I presume it may pertain to the US
>>> taxation model. I am from Australia and we operate under the VAT/GST
>>> model.
>>>
>>> -Michael A
>>>
>>
-----
--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639673.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Shipping - Adjustments vs Products
Posted by Jacques Le Roux <ja...@les7arts.com>.
Right, better do it at the service level indeed, no even need to worry about js then
Jacques
From: "Paul Foxworthy" <pa...@cohsoft.com.au>
> Hi Jacques,
>
> Thanks, I had forgotten the relevance of our earlier discussion to this.
>
> I have no objection to the Javascript validation. The
> createTaxAuthorityRateProduct and updateTaxAuthorityRateProduct services
> must also do it, so the validation happens if initiated by a service call
> rather then the TARP pages. We know the general security principle:
> Javascript validation must be repeated on the server side, it may never have
> happened on the client side.
>
> If it is there in the services, how important would client side Javascript
> be?
>
> Cheers
>
> Paul Foxworthy
>
>
> Jacques Le Roux wrote
>> Hi Paul,
>>
>> Thanks to continue on this :)
>>
>> I just tried with R4.0 and there was only a tax on Shipping then.
>> This lead us back to http://markmail.org/message/ewvaljuqg3voiy2s
>>
>> There are 2 solutions
>> 1) Keep the current data model with TaxAuthorityRateProduct fields
>> taxShipping and taxPromotions and add a js script to prevent users to add
>> more than one line with "Y" for a taxAuthPartyId and taxAuthGeoId
>> 2) Change the data model (no time to think more about it atm)
>>
>> 2) seems better but I 1) can be used in the meantime
>>
>> Jacques
>>
>> From: "Paul Foxworthy" <
>
>> paul@.com
>
>> >
>>> Hi Jacques and Michael,
>>>
>>> I've just noticed one place where OFBiz talks about Shipping and
>>> Promotion
>>> rather than adjustments in general is the Edit Tax Authority Product
>>> Rates
>>> screen. See
>>> https://demo-stable.ofbiz.apache.org/accounting/control/EditTaxAuthorityRateProducts?taxAuthPartyId=UT_TAXMAN&taxAuthGeoId=UT
>>> on the demo site.
>>>
>>> Do you think it's time for a Jira issue to track this?
>>>
>>> Cheers
>>>
>>> Paul Foxworthy
>>>
>>>
>>> Jacques Le Roux wrote
>>>> Yes, then I agree, code shall follow data model
>>>>
>>>> Jacques
>>>>
>>>> From: "Paul Foxworthy" <
>>>
>>>> paul@.com
>>>
>>>> >
>>>>> Hi Jacques,
>>>>>
>>>>> Yes, the data model is pretty good, the processing not so much. This is
>>>>> not
>>>>> the only place in OFBiz where that is so.
>>>>>
>>>>> Look at
>>>>>
>>>>> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/servicedef/services_tax.xml?r=1030778#to39
>>>>>
>>>>> The calcTax service specifically expects promotion and shipping
>>>>> amounts,
>>>>> not
>>>>> adjustments in general. I don't see what's so special about those two.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Paul Foxworthy
>>>>>
>>>>>
>>>>> Jacques Le Roux wrote
>>>>>> Hi Paul,
>>>>>>
>>>>>> I guess there was an intentional will to separate promotions and
>>>>>> shipping.
>>>>>> The reason is certainly a quite obvious simplication and I can agree
>>>>>> on
>>>>>> adding new OrderAdjustmentType, we have already quite a bit
>>>>>>
>>>>
>> <OrderAdjustmentType description="Promotion" hasTable="N"
>>>
>>>>
>>>>> orderAdjustmentTypeId="PROMOTION_ADJUSTMENT" parentTypeId=""/>
>>>>>>
>>>>
>> <OrderAdjustmentType description="Replacement" hasTable="N"
>>>
>>>>
>>>>> orderAdjustmentTypeId="REPLACE_ADJUSTMENT" parentTypeId=""/>
>>>>>>
>>>>
>> <OrderAdjustmentType description="Discount" hasTable="N"
>>>
>>>>
>>>>> orderAdjustmentTypeId="DISCOUNT_ADJUSTMENT" parentTypeId=""/>
>>>>>>
>>>>
>> <OrderAdjustmentType description="Donation" hasTable="N"
>>>
>>>>
>>>>> orderAdjustmentTypeId="DONATION_ADJUSTMENT" parentTypeId=""/>
>>>>>>
>>>>
>> <OrderAdjustmentType description="Fee" hasTable="N"
>>>
>>>>
>>>>> orderAdjustmentTypeId="FEE" parentTypeId=""/>
>>>>>>
>>>>
>> <OrderAdjustmentType description="Miscellaneous Charges" hasTable="N"
>>>
>>>>
>>>>> orderAdjustmentTypeId="MISCELLANEOUS_CHARGE" parentTypeId=""/>
>>>>>>
>>>>
>> <OrderAdjustmentType description="Sales Tax" hasTable="N"
>>>
>>>>
>>>>> orderAdjustmentTypeId="SALES_TAX" parentTypeId=""/>
>>>>>>
>>>>
>> <OrderAdjustmentType description="VAT Tax (not added to totals)"
>>>
>>>>
>>>>> hasTable="N" orderAdjustmentTypeId="VAT_TAX" parentTypeId=""/>
>>>>>>
>>>>
>> <OrderAdjustmentType description="VAT Price Correction" hasTable="N"
>>>
>>>>
>>>>> orderAdjustmentTypeId="VAT_PRICE_CORRECT" parentTypeId=""/>
>>>>>>
>>>>
>> <OrderAdjustmentType description="Shipping and Handling" hasTable="N"
>>>
>>>>
>>>>> orderAdjustmentTypeId="SHIPPING_CHARGES" parentTypeId=""/>
>>>>>>
>>>>
>> <OrderAdjustmentType description="Surcharge" hasTable="N"
>>>
>>>>
>>>>> orderAdjustmentTypeId="SURCHARGE_ADJUSTMENT" parentTypeId=""/>
>>>>>>
>>>>
>> <OrderAdjustmentType description="Additional Feature" hasTable="N"
>>>
>>>>
>>>>> orderAdjustmentTypeId="ADDITIONAL_FEATURE" parentTypeId=""/>
>>>>>>
>>>>
>> <OrderAdjustmentType description="Warranty" hasTable="N"
>>>
>>>>
>>>>> orderAdjustmentTypeId="WARRANTY_ADJUSTMENT" parentTypeId=""/>
>>>>>>
>>>>
>> <OrderAdjustmentType description="Marketing Package Adjustment"
>>>
>>>>
>>>>> hasTable="N" orderAdjustmentTypeId="MKTG_PKG_AUTO_ADJUST"
>>>>>> parentTypeId=""/>
>>>>>> We have already OrderAdjustment.orderAdjustmentTypeId what do we need
>>>>>> more?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Paul Foxworthy" <
>>>>>
>>>>>> paul@.com
>>>>>
>>>>>> >
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Adjustments can be for shipping, promotion (usually a discount when
>>>>>>> some
>>>>>>> condition is met), and tax.
>>>>>>>
>>>>>>> Shipping and promotion can be per item or once for the entire order.
>>>>>>> Per-item adjustments are associated with an item, so if the item is
>>>>>>> changed
>>>>>>> or removed, it's easy to update or remove corresponding adjustments.
>>>>>>>
>>>>>>> Given we need per-item adjustments, per-order adjustments should be
>>>>>>> as
>>>>>>> similar as possible, so I would argue should be adjustments and not
>>>>>>> items.
>>>>>>> If there are no products, there's no order and there should be no
>>>>>>> adjustments. I would only want to see a shipping product if my
>>>>>>> company
>>>>>>> is
>>>>>>> in
>>>>>>> the shipping business. If I'm in some other industry, my customers
>>>>>>> would
>>>>>>> never just order a shipping service from me.
>>>>>>>
>>>>>>> I do think we should treat adjustments in a more general way, rather
>>>>>>> than
>>>>>>> assuming that shipping, promotion and tax are all we'll ever
>>>>>>> encounter.
>>>>>>> So
>>>>>>> any adjustment would have an adjustment type, we can create new ones
>>>>>>> if
>>>>>>> the
>>>>>>> need ever arises, and we just communicate one collection of
>>>>>>> adjustments
>>>>>>> for
>>>>>>> each item and one for the order, rather than splitting out promotion
>>>>>>> and
>>>>>>> shipping.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Paul Foxworthy
>>>>>>>
>>>>>>>
>>>>>>> Jacques Le Roux wrote
>>>>>>>> This means also some code changes, but yes maybe...
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>> From: "Adrian Crum" <
>>>>>>>
>>>>>>>> adrian.crum@
>>>>>>>
>>>>>>>> >
>>>>>>>>>I have wondered that myself. It would make more sense if shipping
> was
>>> a
>>>>>>>>> non-stock product.
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>> On 1/25/2013 2:21 AM, Michael Alleblas wrote:
>>>>>>>>>> Why are shipping charges an adjustment as opposed to a service and
>>>>>>>>>> added
>>>>>>>>>> just like any other product? This would allow taxation to be
>>>>>>>>>> calculated
>>>>>>>>>> as
>>>>>>>>>> simply as it is for products.
>>>>>>>>>>
>>>>>>>>>> I may be missing something here, and I presume it may pertain to
>>>>>>>>>> the
>>>>>>>>>> US
>>>>>>>>>> taxation model. I am from Australia and we operate under the
>>>>>>>>>> VAT/GST
>>>>>>>>>> model.
>>>>>>>>>>
>>>>>>>>>> -Michael A
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----
>>>>>>> --
>>>>>>> Coherent Software Australia Pty Ltd
>>>>>>> http://www.coherentsoftware.com.au/
>>>>>>>
>>>>>>> Bonsai ERP, the all-inclusive ERP system
>>>>>>> http://www.bonsaierp.com.au/
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639673.html
>>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----
>>>>> --
>>>>> Coherent Software Australia Pty Ltd
>>>>> http://www.coherentsoftware.com.au/
>>>>>
>>>>> Bonsai ERP, the all-inclusive ERP system
>>>>> http://www.bonsaierp.com.au/
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639703.html
>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>
>>>
>>>
>>>
>>>
>>> -----
>>> --
>>> Coherent Software Australia Pty Ltd
>>> http://www.coherentsoftware.com.au/
>>>
>>> Bonsai ERP, the all-inclusive ERP system
>>> http://www.bonsaierp.com.au/
>>>
>>> --
>>> View this message in context:
>>> http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639777.html
>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
>
>
>
>
> -----
> --
> Coherent Software Australia Pty Ltd
> http://www.coherentsoftware.com.au/
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639791.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Shipping - Adjustments vs Products
Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
Hi Jacques,
Thanks, I had forgotten the relevance of our earlier discussion to this.
I have no objection to the Javascript validation. The
createTaxAuthorityRateProduct and updateTaxAuthorityRateProduct services
must also do it, so the validation happens if initiated by a service call
rather then the TARP pages. We know the general security principle:
Javascript validation must be repeated on the server side, it may never have
happened on the client side.
If it is there in the services, how important would client side Javascript
be?
Cheers
Paul Foxworthy
Jacques Le Roux wrote
> Hi Paul,
>
> Thanks to continue on this :)
>
> I just tried with R4.0 and there was only a tax on Shipping then.
> This lead us back to http://markmail.org/message/ewvaljuqg3voiy2s
>
> There are 2 solutions
> 1) Keep the current data model with TaxAuthorityRateProduct fields
> taxShipping and taxPromotions and add a js script to prevent users to add
> more than one line with "Y" for a taxAuthPartyId and taxAuthGeoId
> 2) Change the data model (no time to think more about it atm)
>
> 2) seems better but I 1) can be used in the meantime
>
> Jacques
>
> From: "Paul Foxworthy" <
> paul@.com
> >
>> Hi Jacques and Michael,
>>
>> I've just noticed one place where OFBiz talks about Shipping and
>> Promotion
>> rather than adjustments in general is the Edit Tax Authority Product
>> Rates
>> screen. See
>> https://demo-stable.ofbiz.apache.org/accounting/control/EditTaxAuthorityRateProducts?taxAuthPartyId=UT_TAXMAN&taxAuthGeoId=UT
>> on the demo site.
>>
>> Do you think it's time for a Jira issue to track this?
>>
>> Cheers
>>
>> Paul Foxworthy
>>
>>
>> Jacques Le Roux wrote
>>> Yes, then I agree, code shall follow data model
>>>
>>> Jacques
>>>
>>> From: "Paul Foxworthy" <
>>
>>> paul@.com
>>
>>> >
>>>> Hi Jacques,
>>>>
>>>> Yes, the data model is pretty good, the processing not so much. This is
>>>> not
>>>> the only place in OFBiz where that is so.
>>>>
>>>> Look at
>>>>
>>>> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/servicedef/services_tax.xml?r=1030778#to39
>>>>
>>>> The calcTax service specifically expects promotion and shipping
>>>> amounts,
>>>> not
>>>> adjustments in general. I don't see what's so special about those two.
>>>>
>>>> Cheers
>>>>
>>>> Paul Foxworthy
>>>>
>>>>
>>>> Jacques Le Roux wrote
>>>>> Hi Paul,
>>>>>
>>>>> I guess there was an intentional will to separate promotions and
>>>>> shipping.
>>>>> The reason is certainly a quite obvious simplication and I can agree
>>>>> on
>>>>> adding new OrderAdjustmentType, we have already quite a bit
>>>>>
>>>
> <OrderAdjustmentType description="Promotion" hasTable="N"
>>
>>>
>>>> orderAdjustmentTypeId="PROMOTION_ADJUSTMENT" parentTypeId=""/>
>>>>>
>>>
> <OrderAdjustmentType description="Replacement" hasTable="N"
>>
>>>
>>>> orderAdjustmentTypeId="REPLACE_ADJUSTMENT" parentTypeId=""/>
>>>>>
>>>
> <OrderAdjustmentType description="Discount" hasTable="N"
>>
>>>
>>>> orderAdjustmentTypeId="DISCOUNT_ADJUSTMENT" parentTypeId=""/>
>>>>>
>>>
> <OrderAdjustmentType description="Donation" hasTable="N"
>>
>>>
>>>> orderAdjustmentTypeId="DONATION_ADJUSTMENT" parentTypeId=""/>
>>>>>
>>>
> <OrderAdjustmentType description="Fee" hasTable="N"
>>
>>>
>>>> orderAdjustmentTypeId="FEE" parentTypeId=""/>
>>>>>
>>>
> <OrderAdjustmentType description="Miscellaneous Charges" hasTable="N"
>>
>>>
>>>> orderAdjustmentTypeId="MISCELLANEOUS_CHARGE" parentTypeId=""/>
>>>>>
>>>
> <OrderAdjustmentType description="Sales Tax" hasTable="N"
>>
>>>
>>>> orderAdjustmentTypeId="SALES_TAX" parentTypeId=""/>
>>>>>
>>>
> <OrderAdjustmentType description="VAT Tax (not added to totals)"
>>
>>>
>>>> hasTable="N" orderAdjustmentTypeId="VAT_TAX" parentTypeId=""/>
>>>>>
>>>
> <OrderAdjustmentType description="VAT Price Correction" hasTable="N"
>>
>>>
>>>> orderAdjustmentTypeId="VAT_PRICE_CORRECT" parentTypeId=""/>
>>>>>
>>>
> <OrderAdjustmentType description="Shipping and Handling" hasTable="N"
>>
>>>
>>>> orderAdjustmentTypeId="SHIPPING_CHARGES" parentTypeId=""/>
>>>>>
>>>
> <OrderAdjustmentType description="Surcharge" hasTable="N"
>>
>>>
>>>> orderAdjustmentTypeId="SURCHARGE_ADJUSTMENT" parentTypeId=""/>
>>>>>
>>>
> <OrderAdjustmentType description="Additional Feature" hasTable="N"
>>
>>>
>>>> orderAdjustmentTypeId="ADDITIONAL_FEATURE" parentTypeId=""/>
>>>>>
>>>
> <OrderAdjustmentType description="Warranty" hasTable="N"
>>
>>>
>>>> orderAdjustmentTypeId="WARRANTY_ADJUSTMENT" parentTypeId=""/>
>>>>>
>>>
> <OrderAdjustmentType description="Marketing Package Adjustment"
>>
>>>
>>>> hasTable="N" orderAdjustmentTypeId="MKTG_PKG_AUTO_ADJUST"
>>>>> parentTypeId=""/>
>>>>> We have already OrderAdjustment.orderAdjustmentTypeId what do we need
>>>>> more?
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "Paul Foxworthy" <
>>>>
>>>>> paul@.com
>>>>
>>>>> >
>>>>>> Hi all,
>>>>>>
>>>>>> Adjustments can be for shipping, promotion (usually a discount when
>>>>>> some
>>>>>> condition is met), and tax.
>>>>>>
>>>>>> Shipping and promotion can be per item or once for the entire order.
>>>>>> Per-item adjustments are associated with an item, so if the item is
>>>>>> changed
>>>>>> or removed, it's easy to update or remove corresponding adjustments.
>>>>>>
>>>>>> Given we need per-item adjustments, per-order adjustments should be
>>>>>> as
>>>>>> similar as possible, so I would argue should be adjustments and not
>>>>>> items.
>>>>>> If there are no products, there's no order and there should be no
>>>>>> adjustments. I would only want to see a shipping product if my
>>>>>> company
>>>>>> is
>>>>>> in
>>>>>> the shipping business. If I'm in some other industry, my customers
>>>>>> would
>>>>>> never just order a shipping service from me.
>>>>>>
>>>>>> I do think we should treat adjustments in a more general way, rather
>>>>>> than
>>>>>> assuming that shipping, promotion and tax are all we'll ever
>>>>>> encounter.
>>>>>> So
>>>>>> any adjustment would have an adjustment type, we can create new ones
>>>>>> if
>>>>>> the
>>>>>> need ever arises, and we just communicate one collection of
>>>>>> adjustments
>>>>>> for
>>>>>> each item and one for the order, rather than splitting out promotion
>>>>>> and
>>>>>> shipping.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Paul Foxworthy
>>>>>>
>>>>>>
>>>>>> Jacques Le Roux wrote
>>>>>>> This means also some code changes, but yes maybe...
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> From: "Adrian Crum" <
>>>>>>
>>>>>>> adrian.crum@
>>>>>>
>>>>>>> >
>>>>>>>>I have wondered that myself. It would make more sense if shipping
was
>> a
>>>>>>>> non-stock product.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 1/25/2013 2:21 AM, Michael Alleblas wrote:
>>>>>>>>> Why are shipping charges an adjustment as opposed to a service and
>>>>>>>>> added
>>>>>>>>> just like any other product? This would allow taxation to be
>>>>>>>>> calculated
>>>>>>>>> as
>>>>>>>>> simply as it is for products.
>>>>>>>>>
>>>>>>>>> I may be missing something here, and I presume it may pertain to
>>>>>>>>> the
>>>>>>>>> US
>>>>>>>>> taxation model. I am from Australia and we operate under the
>>>>>>>>> VAT/GST
>>>>>>>>> model.
>>>>>>>>>
>>>>>>>>> -Michael A
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----
>>>>>> --
>>>>>> Coherent Software Australia Pty Ltd
>>>>>> http://www.coherentsoftware.com.au/
>>>>>>
>>>>>> Bonsai ERP, the all-inclusive ERP system
>>>>>> http://www.bonsaierp.com.au/
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639673.html
>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----
>>>> --
>>>> Coherent Software Australia Pty Ltd
>>>> http://www.coherentsoftware.com.au/
>>>>
>>>> Bonsai ERP, the all-inclusive ERP system
>>>> http://www.bonsaierp.com.au/
>>>>
>>>> --
>>>> View this message in context:
>>>> http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639703.html
>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>
>>
>>
>>
>>
>> -----
>> --
>> Coherent Software Australia Pty Ltd
>> http://www.coherentsoftware.com.au/
>>
>> Bonsai ERP, the all-inclusive ERP system
>> http://www.bonsaierp.com.au/
>>
>> --
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639777.html
>> Sent from the OFBiz - User mailing list archive at Nabble.com.
-----
--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639791.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Shipping - Adjustments vs Products
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Paul,
Thanks to continue on this :)
I just tried with R4.0 and there was only a tax on Shipping then.
This lead us back to http://markmail.org/message/ewvaljuqg3voiy2s
There are 2 solutions
1) Keep the current data model with TaxAuthorityRateProduct fields taxShipping and taxPromotions and add a js script to prevent users to add more than one line with "Y" for a taxAuthPartyId and taxAuthGeoId
2) Change the data model (no time to think more about it atm)
2) seems better but I 1) can be used in the meantime
Jacques
From: "Paul Foxworthy" <pa...@cohsoft.com.au>
> Hi Jacques and Michael,
>
> I've just noticed one place where OFBiz talks about Shipping and Promotion
> rather than adjustments in general is the Edit Tax Authority Product Rates
> screen. See
> https://demo-stable.ofbiz.apache.org/accounting/control/EditTaxAuthorityRateProducts?taxAuthPartyId=UT_TAXMAN&taxAuthGeoId=UT
> on the demo site.
>
> Do you think it's time for a Jira issue to track this?
>
> Cheers
>
> Paul Foxworthy
>
>
> Jacques Le Roux wrote
>> Yes, then I agree, code shall follow data model
>>
>> Jacques
>>
>> From: "Paul Foxworthy" <
>
>> paul@.com
>
>> >
>>> Hi Jacques,
>>>
>>> Yes, the data model is pretty good, the processing not so much. This is
>>> not
>>> the only place in OFBiz where that is so.
>>>
>>> Look at
>>>
>>> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/servicedef/services_tax.xml?r=1030778#to39
>>>
>>> The calcTax service specifically expects promotion and shipping amounts,
>>> not
>>> adjustments in general. I don't see what's so special about those two.
>>>
>>> Cheers
>>>
>>> Paul Foxworthy
>>>
>>>
>>> Jacques Le Roux wrote
>>>> Hi Paul,
>>>>
>>>> I guess there was an intentional will to separate promotions and
>>>> shipping.
>>>> The reason is certainly a quite obvious simplication and I can agree on
>>>> adding new OrderAdjustmentType, we have already quite a bit
>>>>
>> <OrderAdjustmentType description="Promotion" hasTable="N"
>>>
>>> orderAdjustmentTypeId="PROMOTION_ADJUSTMENT" parentTypeId=""/>
>>>>
>> <OrderAdjustmentType description="Replacement" hasTable="N"
>>>
>>> orderAdjustmentTypeId="REPLACE_ADJUSTMENT" parentTypeId=""/>
>>>>
>> <OrderAdjustmentType description="Discount" hasTable="N"
>>>
>>> orderAdjustmentTypeId="DISCOUNT_ADJUSTMENT" parentTypeId=""/>
>>>>
>> <OrderAdjustmentType description="Donation" hasTable="N"
>>>
>>> orderAdjustmentTypeId="DONATION_ADJUSTMENT" parentTypeId=""/>
>>>>
>> <OrderAdjustmentType description="Fee" hasTable="N"
>>>
>>> orderAdjustmentTypeId="FEE" parentTypeId=""/>
>>>>
>> <OrderAdjustmentType description="Miscellaneous Charges" hasTable="N"
>>>
>>> orderAdjustmentTypeId="MISCELLANEOUS_CHARGE" parentTypeId=""/>
>>>>
>> <OrderAdjustmentType description="Sales Tax" hasTable="N"
>>>
>>> orderAdjustmentTypeId="SALES_TAX" parentTypeId=""/>
>>>>
>> <OrderAdjustmentType description="VAT Tax (not added to totals)"
>>>
>>> hasTable="N" orderAdjustmentTypeId="VAT_TAX" parentTypeId=""/>
>>>>
>> <OrderAdjustmentType description="VAT Price Correction" hasTable="N"
>>>
>>> orderAdjustmentTypeId="VAT_PRICE_CORRECT" parentTypeId=""/>
>>>>
>> <OrderAdjustmentType description="Shipping and Handling" hasTable="N"
>>>
>>> orderAdjustmentTypeId="SHIPPING_CHARGES" parentTypeId=""/>
>>>>
>> <OrderAdjustmentType description="Surcharge" hasTable="N"
>>>
>>> orderAdjustmentTypeId="SURCHARGE_ADJUSTMENT" parentTypeId=""/>
>>>>
>> <OrderAdjustmentType description="Additional Feature" hasTable="N"
>>>
>>> orderAdjustmentTypeId="ADDITIONAL_FEATURE" parentTypeId=""/>
>>>>
>> <OrderAdjustmentType description="Warranty" hasTable="N"
>>>
>>> orderAdjustmentTypeId="WARRANTY_ADJUSTMENT" parentTypeId=""/>
>>>>
>> <OrderAdjustmentType description="Marketing Package Adjustment"
>>>
>>> hasTable="N" orderAdjustmentTypeId="MKTG_PKG_AUTO_ADJUST"
>>>> parentTypeId=""/>
>>>> We have already OrderAdjustment.orderAdjustmentTypeId what do we need
>>>> more?
>>>>
>>>> Jacques
>>>>
>>>> From: "Paul Foxworthy" <
>>>
>>>> paul@.com
>>>
>>>> >
>>>>> Hi all,
>>>>>
>>>>> Adjustments can be for shipping, promotion (usually a discount when
>>>>> some
>>>>> condition is met), and tax.
>>>>>
>>>>> Shipping and promotion can be per item or once for the entire order.
>>>>> Per-item adjustments are associated with an item, so if the item is
>>>>> changed
>>>>> or removed, it's easy to update or remove corresponding adjustments.
>>>>>
>>>>> Given we need per-item adjustments, per-order adjustments should be as
>>>>> similar as possible, so I would argue should be adjustments and not
>>>>> items.
>>>>> If there are no products, there's no order and there should be no
>>>>> adjustments. I would only want to see a shipping product if my company
>>>>> is
>>>>> in
>>>>> the shipping business. If I'm in some other industry, my customers
>>>>> would
>>>>> never just order a shipping service from me.
>>>>>
>>>>> I do think we should treat adjustments in a more general way, rather
>>>>> than
>>>>> assuming that shipping, promotion and tax are all we'll ever encounter.
>>>>> So
>>>>> any adjustment would have an adjustment type, we can create new ones if
>>>>> the
>>>>> need ever arises, and we just communicate one collection of adjustments
>>>>> for
>>>>> each item and one for the order, rather than splitting out promotion
>>>>> and
>>>>> shipping.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Paul Foxworthy
>>>>>
>>>>>
>>>>> Jacques Le Roux wrote
>>>>>> This means also some code changes, but yes maybe...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "Adrian Crum" <
>>>>>
>>>>>> adrian.crum@
>>>>>
>>>>>> >
>>>>>>>I have wondered that myself. It would make more sense if shipping was
> a
>>>>>>> non-stock product.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> On 1/25/2013 2:21 AM, Michael Alleblas wrote:
>>>>>>>> Why are shipping charges an adjustment as opposed to a service and
>>>>>>>> added
>>>>>>>> just like any other product? This would allow taxation to be
>>>>>>>> calculated
>>>>>>>> as
>>>>>>>> simply as it is for products.
>>>>>>>>
>>>>>>>> I may be missing something here, and I presume it may pertain to the
>>>>>>>> US
>>>>>>>> taxation model. I am from Australia and we operate under the VAT/GST
>>>>>>>> model.
>>>>>>>>
>>>>>>>> -Michael A
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----
>>>>> --
>>>>> Coherent Software Australia Pty Ltd
>>>>> http://www.coherentsoftware.com.au/
>>>>>
>>>>> Bonsai ERP, the all-inclusive ERP system
>>>>> http://www.bonsaierp.com.au/
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639673.html
>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>
>>>
>>>
>>>
>>>
>>> -----
>>> --
>>> Coherent Software Australia Pty Ltd
>>> http://www.coherentsoftware.com.au/
>>>
>>> Bonsai ERP, the all-inclusive ERP system
>>> http://www.bonsaierp.com.au/
>>>
>>> --
>>> View this message in context:
>>> http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639703.html
>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
>
>
>
>
> -----
> --
> Coherent Software Australia Pty Ltd
> http://www.coherentsoftware.com.au/
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639777.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Shipping - Adjustments vs Products
Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
Hi Jacques and Michael,
I've just noticed one place where OFBiz talks about Shipping and Promotion
rather than adjustments in general is the Edit Tax Authority Product Rates
screen. See
https://demo-stable.ofbiz.apache.org/accounting/control/EditTaxAuthorityRateProducts?taxAuthPartyId=UT_TAXMAN&taxAuthGeoId=UT
on the demo site.
Do you think it's time for a Jira issue to track this?
Cheers
Paul Foxworthy
Jacques Le Roux wrote
> Yes, then I agree, code shall follow data model
>
> Jacques
>
> From: "Paul Foxworthy" <
> paul@.com
> >
>> Hi Jacques,
>>
>> Yes, the data model is pretty good, the processing not so much. This is
>> not
>> the only place in OFBiz where that is so.
>>
>> Look at
>>
>> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/servicedef/services_tax.xml?r=1030778#to39
>>
>> The calcTax service specifically expects promotion and shipping amounts,
>> not
>> adjustments in general. I don't see what's so special about those two.
>>
>> Cheers
>>
>> Paul Foxworthy
>>
>>
>> Jacques Le Roux wrote
>>> Hi Paul,
>>>
>>> I guess there was an intentional will to separate promotions and
>>> shipping.
>>> The reason is certainly a quite obvious simplication and I can agree on
>>> adding new OrderAdjustmentType, we have already quite a bit
>>>
> <OrderAdjustmentType description="Promotion" hasTable="N"
>>
>> orderAdjustmentTypeId="PROMOTION_ADJUSTMENT" parentTypeId=""/>
>>>
> <OrderAdjustmentType description="Replacement" hasTable="N"
>>
>> orderAdjustmentTypeId="REPLACE_ADJUSTMENT" parentTypeId=""/>
>>>
> <OrderAdjustmentType description="Discount" hasTable="N"
>>
>> orderAdjustmentTypeId="DISCOUNT_ADJUSTMENT" parentTypeId=""/>
>>>
> <OrderAdjustmentType description="Donation" hasTable="N"
>>
>> orderAdjustmentTypeId="DONATION_ADJUSTMENT" parentTypeId=""/>
>>>
> <OrderAdjustmentType description="Fee" hasTable="N"
>>
>> orderAdjustmentTypeId="FEE" parentTypeId=""/>
>>>
> <OrderAdjustmentType description="Miscellaneous Charges" hasTable="N"
>>
>> orderAdjustmentTypeId="MISCELLANEOUS_CHARGE" parentTypeId=""/>
>>>
> <OrderAdjustmentType description="Sales Tax" hasTable="N"
>>
>> orderAdjustmentTypeId="SALES_TAX" parentTypeId=""/>
>>>
> <OrderAdjustmentType description="VAT Tax (not added to totals)"
>>
>> hasTable="N" orderAdjustmentTypeId="VAT_TAX" parentTypeId=""/>
>>>
> <OrderAdjustmentType description="VAT Price Correction" hasTable="N"
>>
>> orderAdjustmentTypeId="VAT_PRICE_CORRECT" parentTypeId=""/>
>>>
> <OrderAdjustmentType description="Shipping and Handling" hasTable="N"
>>
>> orderAdjustmentTypeId="SHIPPING_CHARGES" parentTypeId=""/>
>>>
> <OrderAdjustmentType description="Surcharge" hasTable="N"
>>
>> orderAdjustmentTypeId="SURCHARGE_ADJUSTMENT" parentTypeId=""/>
>>>
> <OrderAdjustmentType description="Additional Feature" hasTable="N"
>>
>> orderAdjustmentTypeId="ADDITIONAL_FEATURE" parentTypeId=""/>
>>>
> <OrderAdjustmentType description="Warranty" hasTable="N"
>>
>> orderAdjustmentTypeId="WARRANTY_ADJUSTMENT" parentTypeId=""/>
>>>
> <OrderAdjustmentType description="Marketing Package Adjustment"
>>
>> hasTable="N" orderAdjustmentTypeId="MKTG_PKG_AUTO_ADJUST"
>>> parentTypeId=""/>
>>> We have already OrderAdjustment.orderAdjustmentTypeId what do we need
>>> more?
>>>
>>> Jacques
>>>
>>> From: "Paul Foxworthy" <
>>
>>> paul@.com
>>
>>> >
>>>> Hi all,
>>>>
>>>> Adjustments can be for shipping, promotion (usually a discount when
>>>> some
>>>> condition is met), and tax.
>>>>
>>>> Shipping and promotion can be per item or once for the entire order.
>>>> Per-item adjustments are associated with an item, so if the item is
>>>> changed
>>>> or removed, it's easy to update or remove corresponding adjustments.
>>>>
>>>> Given we need per-item adjustments, per-order adjustments should be as
>>>> similar as possible, so I would argue should be adjustments and not
>>>> items.
>>>> If there are no products, there's no order and there should be no
>>>> adjustments. I would only want to see a shipping product if my company
>>>> is
>>>> in
>>>> the shipping business. If I'm in some other industry, my customers
>>>> would
>>>> never just order a shipping service from me.
>>>>
>>>> I do think we should treat adjustments in a more general way, rather
>>>> than
>>>> assuming that shipping, promotion and tax are all we'll ever encounter.
>>>> So
>>>> any adjustment would have an adjustment type, we can create new ones if
>>>> the
>>>> need ever arises, and we just communicate one collection of adjustments
>>>> for
>>>> each item and one for the order, rather than splitting out promotion
>>>> and
>>>> shipping.
>>>>
>>>> Cheers
>>>>
>>>> Paul Foxworthy
>>>>
>>>>
>>>> Jacques Le Roux wrote
>>>>> This means also some code changes, but yes maybe...
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "Adrian Crum" <
>>>>
>>>>> adrian.crum@
>>>>
>>>>> >
>>>>>>I have wondered that myself. It would make more sense if shipping was
a
>>>>>> non-stock product.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> On 1/25/2013 2:21 AM, Michael Alleblas wrote:
>>>>>>> Why are shipping charges an adjustment as opposed to a service and
>>>>>>> added
>>>>>>> just like any other product? This would allow taxation to be
>>>>>>> calculated
>>>>>>> as
>>>>>>> simply as it is for products.
>>>>>>>
>>>>>>> I may be missing something here, and I presume it may pertain to the
>>>>>>> US
>>>>>>> taxation model. I am from Australia and we operate under the VAT/GST
>>>>>>> model.
>>>>>>>
>>>>>>> -Michael A
>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----
>>>> --
>>>> Coherent Software Australia Pty Ltd
>>>> http://www.coherentsoftware.com.au/
>>>>
>>>> Bonsai ERP, the all-inclusive ERP system
>>>> http://www.bonsaierp.com.au/
>>>>
>>>> --
>>>> View this message in context:
>>>> http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639673.html
>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>
>>
>>
>>
>>
>> -----
>> --
>> Coherent Software Australia Pty Ltd
>> http://www.coherentsoftware.com.au/
>>
>> Bonsai ERP, the all-inclusive ERP system
>> http://www.bonsaierp.com.au/
>>
>> --
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639703.html
>> Sent from the OFBiz - User mailing list archive at Nabble.com.
-----
--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639777.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Shipping - Adjustments vs Products
Posted by Jacques Le Roux <ja...@les7arts.com>.
Yes, then I agree, code shall follow data model
Jacques
From: "Paul Foxworthy" <pa...@cohsoft.com.au>
> Hi Jacques,
>
> Yes, the data model is pretty good, the processing not so much. This is not
> the only place in OFBiz where that is so.
>
> Look at
>
> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/servicedef/services_tax.xml?r=1030778#to39
>
> The calcTax service specifically expects promotion and shipping amounts, not
> adjustments in general. I don't see what's so special about those two.
>
> Cheers
>
> Paul Foxworthy
>
>
> Jacques Le Roux wrote
>> Hi Paul,
>>
>> I guess there was an intentional will to separate promotions and shipping.
>> The reason is certainly a quite obvious simplication and I can agree on
>> adding new OrderAdjustmentType, we have already quite a bit
>> <OrderAdjustmentType description="Promotion" hasTable="N"
>> orderAdjustmentTypeId="PROMOTION_ADJUSTMENT" parentTypeId=""/>
>> <OrderAdjustmentType description="Replacement" hasTable="N"
>> orderAdjustmentTypeId="REPLACE_ADJUSTMENT" parentTypeId=""/>
>> <OrderAdjustmentType description="Discount" hasTable="N"
>> orderAdjustmentTypeId="DISCOUNT_ADJUSTMENT" parentTypeId=""/>
>> <OrderAdjustmentType description="Donation" hasTable="N"
>> orderAdjustmentTypeId="DONATION_ADJUSTMENT" parentTypeId=""/>
>> <OrderAdjustmentType description="Fee" hasTable="N"
>> orderAdjustmentTypeId="FEE" parentTypeId=""/>
>> <OrderAdjustmentType description="Miscellaneous Charges" hasTable="N"
>> orderAdjustmentTypeId="MISCELLANEOUS_CHARGE" parentTypeId=""/>
>> <OrderAdjustmentType description="Sales Tax" hasTable="N"
>> orderAdjustmentTypeId="SALES_TAX" parentTypeId=""/>
>> <OrderAdjustmentType description="VAT Tax (not added to totals)"
>> hasTable="N" orderAdjustmentTypeId="VAT_TAX" parentTypeId=""/>
>> <OrderAdjustmentType description="VAT Price Correction" hasTable="N"
>> orderAdjustmentTypeId="VAT_PRICE_CORRECT" parentTypeId=""/>
>> <OrderAdjustmentType description="Shipping and Handling" hasTable="N"
>> orderAdjustmentTypeId="SHIPPING_CHARGES" parentTypeId=""/>
>> <OrderAdjustmentType description="Surcharge" hasTable="N"
>> orderAdjustmentTypeId="SURCHARGE_ADJUSTMENT" parentTypeId=""/>
>> <OrderAdjustmentType description="Additional Feature" hasTable="N"
>> orderAdjustmentTypeId="ADDITIONAL_FEATURE" parentTypeId=""/>
>> <OrderAdjustmentType description="Warranty" hasTable="N"
>> orderAdjustmentTypeId="WARRANTY_ADJUSTMENT" parentTypeId=""/>
>> <OrderAdjustmentType description="Marketing Package Adjustment"
>> hasTable="N" orderAdjustmentTypeId="MKTG_PKG_AUTO_ADJUST"
>> parentTypeId=""/>
>> We have already OrderAdjustment.orderAdjustmentTypeId what do we need
>> more?
>>
>> Jacques
>>
>> From: "Paul Foxworthy" <
>
>> paul@.com
>
>> >
>>> Hi all,
>>>
>>> Adjustments can be for shipping, promotion (usually a discount when some
>>> condition is met), and tax.
>>>
>>> Shipping and promotion can be per item or once for the entire order.
>>> Per-item adjustments are associated with an item, so if the item is
>>> changed
>>> or removed, it's easy to update or remove corresponding adjustments.
>>>
>>> Given we need per-item adjustments, per-order adjustments should be as
>>> similar as possible, so I would argue should be adjustments and not
>>> items.
>>> If there are no products, there's no order and there should be no
>>> adjustments. I would only want to see a shipping product if my company is
>>> in
>>> the shipping business. If I'm in some other industry, my customers would
>>> never just order a shipping service from me.
>>>
>>> I do think we should treat adjustments in a more general way, rather than
>>> assuming that shipping, promotion and tax are all we'll ever encounter.
>>> So
>>> any adjustment would have an adjustment type, we can create new ones if
>>> the
>>> need ever arises, and we just communicate one collection of adjustments
>>> for
>>> each item and one for the order, rather than splitting out promotion and
>>> shipping.
>>>
>>> Cheers
>>>
>>> Paul Foxworthy
>>>
>>>
>>> Jacques Le Roux wrote
>>>> This means also some code changes, but yes maybe...
>>>>
>>>> Jacques
>>>>
>>>> From: "Adrian Crum" <
>>>
>>>> adrian.crum@
>>>
>>>> >
>>>>>I have wondered that myself. It would make more sense if shipping was a
>>>>> non-stock product.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 1/25/2013 2:21 AM, Michael Alleblas wrote:
>>>>>> Why are shipping charges an adjustment as opposed to a service and
>>>>>> added
>>>>>> just like any other product? This would allow taxation to be
>>>>>> calculated
>>>>>> as
>>>>>> simply as it is for products.
>>>>>>
>>>>>> I may be missing something here, and I presume it may pertain to the
>>>>>> US
>>>>>> taxation model. I am from Australia and we operate under the VAT/GST
>>>>>> model.
>>>>>>
>>>>>> -Michael A
>>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>
>>> -----
>>> --
>>> Coherent Software Australia Pty Ltd
>>> http://www.coherentsoftware.com.au/
>>>
>>> Bonsai ERP, the all-inclusive ERP system
>>> http://www.bonsaierp.com.au/
>>>
>>> --
>>> View this message in context:
>>> http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639673.html
>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
>
>
>
>
> -----
> --
> Coherent Software Australia Pty Ltd
> http://www.coherentsoftware.com.au/
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639703.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Shipping - Adjustments vs Products
Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
Hi Jacques,
Yes, the data model is pretty good, the processing not so much. This is not
the only place in OFBiz where that is so.
Look at
https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/servicedef/services_tax.xml?r=1030778#to39
The calcTax service specifically expects promotion and shipping amounts, not
adjustments in general. I don't see what's so special about those two.
Cheers
Paul Foxworthy
Jacques Le Roux wrote
> Hi Paul,
>
> I guess there was an intentional will to separate promotions and shipping.
> The reason is certainly a quite obvious simplication and I can agree on
> adding new OrderAdjustmentType, we have already quite a bit
> <OrderAdjustmentType description="Promotion" hasTable="N"
> orderAdjustmentTypeId="PROMOTION_ADJUSTMENT" parentTypeId=""/>
> <OrderAdjustmentType description="Replacement" hasTable="N"
> orderAdjustmentTypeId="REPLACE_ADJUSTMENT" parentTypeId=""/>
> <OrderAdjustmentType description="Discount" hasTable="N"
> orderAdjustmentTypeId="DISCOUNT_ADJUSTMENT" parentTypeId=""/>
> <OrderAdjustmentType description="Donation" hasTable="N"
> orderAdjustmentTypeId="DONATION_ADJUSTMENT" parentTypeId=""/>
> <OrderAdjustmentType description="Fee" hasTable="N"
> orderAdjustmentTypeId="FEE" parentTypeId=""/>
> <OrderAdjustmentType description="Miscellaneous Charges" hasTable="N"
> orderAdjustmentTypeId="MISCELLANEOUS_CHARGE" parentTypeId=""/>
> <OrderAdjustmentType description="Sales Tax" hasTable="N"
> orderAdjustmentTypeId="SALES_TAX" parentTypeId=""/>
> <OrderAdjustmentType description="VAT Tax (not added to totals)"
> hasTable="N" orderAdjustmentTypeId="VAT_TAX" parentTypeId=""/>
> <OrderAdjustmentType description="VAT Price Correction" hasTable="N"
> orderAdjustmentTypeId="VAT_PRICE_CORRECT" parentTypeId=""/>
> <OrderAdjustmentType description="Shipping and Handling" hasTable="N"
> orderAdjustmentTypeId="SHIPPING_CHARGES" parentTypeId=""/>
> <OrderAdjustmentType description="Surcharge" hasTable="N"
> orderAdjustmentTypeId="SURCHARGE_ADJUSTMENT" parentTypeId=""/>
> <OrderAdjustmentType description="Additional Feature" hasTable="N"
> orderAdjustmentTypeId="ADDITIONAL_FEATURE" parentTypeId=""/>
> <OrderAdjustmentType description="Warranty" hasTable="N"
> orderAdjustmentTypeId="WARRANTY_ADJUSTMENT" parentTypeId=""/>
> <OrderAdjustmentType description="Marketing Package Adjustment"
> hasTable="N" orderAdjustmentTypeId="MKTG_PKG_AUTO_ADJUST"
> parentTypeId=""/>
> We have already OrderAdjustment.orderAdjustmentTypeId what do we need
> more?
>
> Jacques
>
> From: "Paul Foxworthy" <
> paul@.com
> >
>> Hi all,
>>
>> Adjustments can be for shipping, promotion (usually a discount when some
>> condition is met), and tax.
>>
>> Shipping and promotion can be per item or once for the entire order.
>> Per-item adjustments are associated with an item, so if the item is
>> changed
>> or removed, it's easy to update or remove corresponding adjustments.
>>
>> Given we need per-item adjustments, per-order adjustments should be as
>> similar as possible, so I would argue should be adjustments and not
>> items.
>> If there are no products, there's no order and there should be no
>> adjustments. I would only want to see a shipping product if my company is
>> in
>> the shipping business. If I'm in some other industry, my customers would
>> never just order a shipping service from me.
>>
>> I do think we should treat adjustments in a more general way, rather than
>> assuming that shipping, promotion and tax are all we'll ever encounter.
>> So
>> any adjustment would have an adjustment type, we can create new ones if
>> the
>> need ever arises, and we just communicate one collection of adjustments
>> for
>> each item and one for the order, rather than splitting out promotion and
>> shipping.
>>
>> Cheers
>>
>> Paul Foxworthy
>>
>>
>> Jacques Le Roux wrote
>>> This means also some code changes, but yes maybe...
>>>
>>> Jacques
>>>
>>> From: "Adrian Crum" <
>>
>>> adrian.crum@
>>
>>> >
>>>>I have wondered that myself. It would make more sense if shipping was a
>>>> non-stock product.
>>>>
>>>> -Adrian
>>>>
>>>> On 1/25/2013 2:21 AM, Michael Alleblas wrote:
>>>>> Why are shipping charges an adjustment as opposed to a service and
>>>>> added
>>>>> just like any other product? This would allow taxation to be
>>>>> calculated
>>>>> as
>>>>> simply as it is for products.
>>>>>
>>>>> I may be missing something here, and I presume it may pertain to the
>>>>> US
>>>>> taxation model. I am from Australia and we operate under the VAT/GST
>>>>> model.
>>>>>
>>>>> -Michael A
>>>>>
>>>>
>>
>>
>>
>>
>>
>> -----
>> --
>> Coherent Software Australia Pty Ltd
>> http://www.coherentsoftware.com.au/
>>
>> Bonsai ERP, the all-inclusive ERP system
>> http://www.bonsaierp.com.au/
>>
>> --
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639673.html
>> Sent from the OFBiz - User mailing list archive at Nabble.com.
-----
--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639703.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Shipping - Adjustments vs Products
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Paul,
I guess there was an intentional will to separate promotions and shipping. The reason is certainly a quite obvious simplication and I can agree on adding new OrderAdjustmentType, we have already quite a bit
<OrderAdjustmentType description="Promotion" hasTable="N" orderAdjustmentTypeId="PROMOTION_ADJUSTMENT" parentTypeId=""/>
<OrderAdjustmentType description="Replacement" hasTable="N" orderAdjustmentTypeId="REPLACE_ADJUSTMENT" parentTypeId=""/>
<OrderAdjustmentType description="Discount" hasTable="N" orderAdjustmentTypeId="DISCOUNT_ADJUSTMENT" parentTypeId=""/>
<OrderAdjustmentType description="Donation" hasTable="N" orderAdjustmentTypeId="DONATION_ADJUSTMENT" parentTypeId=""/>
<OrderAdjustmentType description="Fee" hasTable="N" orderAdjustmentTypeId="FEE" parentTypeId=""/>
<OrderAdjustmentType description="Miscellaneous Charges" hasTable="N" orderAdjustmentTypeId="MISCELLANEOUS_CHARGE" parentTypeId=""/>
<OrderAdjustmentType description="Sales Tax" hasTable="N" orderAdjustmentTypeId="SALES_TAX" parentTypeId=""/>
<OrderAdjustmentType description="VAT Tax (not added to totals)" hasTable="N" orderAdjustmentTypeId="VAT_TAX" parentTypeId=""/>
<OrderAdjustmentType description="VAT Price Correction" hasTable="N" orderAdjustmentTypeId="VAT_PRICE_CORRECT" parentTypeId=""/>
<OrderAdjustmentType description="Shipping and Handling" hasTable="N" orderAdjustmentTypeId="SHIPPING_CHARGES" parentTypeId=""/>
<OrderAdjustmentType description="Surcharge" hasTable="N" orderAdjustmentTypeId="SURCHARGE_ADJUSTMENT" parentTypeId=""/>
<OrderAdjustmentType description="Additional Feature" hasTable="N" orderAdjustmentTypeId="ADDITIONAL_FEATURE" parentTypeId=""/>
<OrderAdjustmentType description="Warranty" hasTable="N" orderAdjustmentTypeId="WARRANTY_ADJUSTMENT" parentTypeId=""/>
<OrderAdjustmentType description="Marketing Package Adjustment" hasTable="N" orderAdjustmentTypeId="MKTG_PKG_AUTO_ADJUST" parentTypeId=""/>
We have already OrderAdjustment.orderAdjustmentTypeId what do we need more?
Jacques
From: "Paul Foxworthy" <pa...@cohsoft.com.au>
> Hi all,
>
> Adjustments can be for shipping, promotion (usually a discount when some
> condition is met), and tax.
>
> Shipping and promotion can be per item or once for the entire order.
> Per-item adjustments are associated with an item, so if the item is changed
> or removed, it's easy to update or remove corresponding adjustments.
>
> Given we need per-item adjustments, per-order adjustments should be as
> similar as possible, so I would argue should be adjustments and not items.
> If there are no products, there's no order and there should be no
> adjustments. I would only want to see a shipping product if my company is in
> the shipping business. If I'm in some other industry, my customers would
> never just order a shipping service from me.
>
> I do think we should treat adjustments in a more general way, rather than
> assuming that shipping, promotion and tax are all we'll ever encounter. So
> any adjustment would have an adjustment type, we can create new ones if the
> need ever arises, and we just communicate one collection of adjustments for
> each item and one for the order, rather than splitting out promotion and
> shipping.
>
> Cheers
>
> Paul Foxworthy
>
>
> Jacques Le Roux wrote
>> This means also some code changes, but yes maybe...
>>
>> Jacques
>>
>> From: "Adrian Crum" <
>
>> adrian.crum@
>
>> >
>>>I have wondered that myself. It would make more sense if shipping was a
>>> non-stock product.
>>>
>>> -Adrian
>>>
>>> On 1/25/2013 2:21 AM, Michael Alleblas wrote:
>>>> Why are shipping charges an adjustment as opposed to a service and added
>>>> just like any other product? This would allow taxation to be calculated
>>>> as
>>>> simply as it is for products.
>>>>
>>>> I may be missing something here, and I presume it may pertain to the US
>>>> taxation model. I am from Australia and we operate under the VAT/GST
>>>> model.
>>>>
>>>> -Michael A
>>>>
>>>
>
>
>
>
>
> -----
> --
> Coherent Software Australia Pty Ltd
> http://www.coherentsoftware.com.au/
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Shipping-Adjustments-vs-Products-tp4639135p4639673.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.