Shipping - Adjustments vs Products
Locked
 
|
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 |
Re: Shipping - Adjustments vs Products
|
|
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 > |
Re: Shipping - Adjustments vs Products
Administrator
|
This means also some code changes, but yes maybe...
Jacques From: "Adrian Crum" <[hidden email]> >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 >> > |
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
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
Re: Shipping - Adjustments vs Products
|
Administrator
|
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" <[hidden email]> > 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
|
|
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
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
Re: Shipping - Adjustments vs Products
|
Administrator
|
Yes, then I agree, code shall follow data model
Jacques From: "Paul Foxworthy" <[hidden email]> > 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
|
|
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
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
Re: Shipping - Adjustments vs Products
|
Administrator
|
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" <[hidden email]> > 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
|
|
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
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
Re: Shipping - Adjustments vs Products
|
Administrator
|
Right, better do it at the service level indeed, no even need to worry about js then
Jacques From: "Paul Foxworthy" <[hidden email]> > 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. |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |