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.
