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.
