Right, better do it at the service level indeed, no even need to worry about js then
Jacques From: "Paul Foxworthy" <[email protected]> > 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" < > >> [email protected] > >> > >>> 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" < >>> >>>> [email protected] >>> >>>> > >>>>> 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" < >>>>> >>>>>> [email protected] >>>>> >>>>>> > >>>>>>> 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.
