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.
