Hi Jacques and Happy New Year, I had thought cost centres are a separate issue. An organization using OFBiz might want to break down a purchase into multiple cost centres even if no tax is involved.
Is there a need to consider cost centres as part of this? Why so? Cheers Paul Foxworthy Jacques Le Roux wrote > > This remembers me this dicussion > http://markmail.org/message/oisyr3hqq2vn3yfz > There are maybe some good ideas there, are we not looking for cost > centers? > > Jacques > > From: "Hans Bakker" <mailinglist@> >> Sergei, Paul. >> >> as you suggested, >> producrstore should not be used for purchase orders or anything purchase >> tax related, >> productstore is for sales only >> >> regards, >> Hans >> >> On 12/31/2011 01:44 PM, Paul Foxworthy wrote: >>> Hi Sergei, >>> >>> Title transfer is about when ownership transfers from the seller to the >>> purchaser. See >>> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml?hb=true#to1000 >>> for the complete list of values. I don't think title transfer is >>> relevant to >>> adjustments, so I think it is not needed in the new entity. >>> >>> productStoreId is fine for sales, but is useless for purchases. I >>> suggest >>> the entity have both a productStoreId and a sellerGeoId. For purchases, >>> the >>> location of the seller would be used to locate tax rules. I've discussed >>> this issue before on the mailing list at >>> https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/data/AccountingTypeData.xml?hb=true#to1000 >>> . >>> >>> Cheers >>> >>> Paul Foxworthy >>> >>> >>> biletnikov wrote >>>> *Current problem:* >>>> we manage tax calculation for products by setting up a tax authority. >>>> The tax rate for products is set with TaxAuthorityRateProduct. >>>> In addition, tax setting for shipping and promotions adjustments can be >>>> set as special flags to each TaxAuthorityRateProduct (tax >>>> shipping/promotion Y or N). However, these 2 adjustments are taxed only >>>> if >>>> productCategoryId is empty, and these 2 adjustments look like a hack or >>>> temp solution here... >>>> I faced with a problem, where all adjustments must be taxed (very >>>> common >>>> case for VAT tax system) and it is very unhandy when you have to >>>> control >>>> the tax amount manually. In our case, the system taxes the shipping and >>>> promotion adjustments, but we have to add Sales tax to all another >>>> adjustments manually. >>>> In addition, OFBiz has tax amount correction logic, which compensates >>>> the >>>> tax difference automatically, example: >>>> Prdouct 100 euro >>>> Sales tax (VAT 19%) = 100 * 0.19 = 19 euro >>>> Shipping charge 10 euro >>>> Sales tax (VAT 19%) = 10 * 0.19 = 1.90 euro >>>> Other adjustment 20 euro >>>> Sales tax (VAT 19%) = 3.80 euro (we have to add it manually) >>>> *Sales tax (VAT 19%) = - 3.80 euro * (it is automatically added >>>> difference >>>> to correct the sales tax amount, because the sales tax for other >>>> adjustment is not taken into account.) >>>> and we have to delete the last tax adjustment manually. >>>> >>>> *Solution:* >>>> As we have TaxAuthorityRateProduct in OFBiz to manage the taxing of >>>> products, so why not to have the same mechanism for all adjustments? >>>> I propose the solution to have the TaxAuthorityRateAdjustment entity. >>>> TaxAuthorityRateAdjustment will have the following fields: >>>> >>>> *Tax type* (Sales Tax, etc) >>>> *Store ID* >>>> *Adjustment Type or (All adjustments)* >>>> Title Transfer ??? (I do not know, what can you suggest?) >>>> *Tax Percentage * >>>> *From Date * >>>> *Thru Date* >>>> *Description* >>>> >>>> The settings will be placed in the separate "Adjustment rates" tab, >>>> near >>>> to "Product rates" (Tax Authority settings). >>>> The UI should be very similar! >>>> >>>> RE: TaxAuthorityRateProduct >>>> we should retire >>>> *Tax Shipping* >>>> *Tax Promotions* >>>> >>>> The tax calculation service must be reworked, >>>> >>>> <service name="calcTax" engine="java" >>>> location="org.ofbiz.accounting.tax.TaxAuthorityServices" >>>> invoke="rateProductTaxCalc"> >>>> <description>Tax Authority Rate Product Calc >>>> Service</description> >>>> <implements service="calcTaxInterface"/> >>>> </service> >>>> >>>> <service name="calcTaxInterface" engine="interface" location="" >>>> invoke=""> >>>> <description>Tax Calc Service Interface</description> >>>> <attribute name="productStoreId" type="String" mode="IN" >>>> optional="true"></attribute> >>>> <attribute name="facilityId" type="String" mode="IN" >>>> optional="true"></attribute> >>>> <attribute name="payToPartyId" type="String" mode="IN" >>>> optional="true"/> >>>> <attribute name="billToPartyId" type="String" mode="IN" >>>> optional="true"></attribute> >>>> <attribute name="itemProductList" type="java.util.List" >>>> mode="IN" >>>> optional="false"></attribute> >>>> <attribute name="itemAmountList" type="java.util.List" >>>> mode="IN" >>>> optional="false"></attribute> >>>> <attribute name="itemPriceList" type="java.util.List" mode="IN" >>>> optional="false"></attribute> >>>> <attribute name="itemQuantityList" type="java.util.List" >>>> mode="IN" >>>> optional="true"></attribute> >>>> <attribute name="itemShippingList" type="java.util.List" >>>> mode="IN" >>>> optional="true"></attribute> >>>> *<attribute name="orderShippingAmount" type="BigDecimal" mode="IN" >>>> optional="true"/> >>>> <attribute name="orderPromotionsAmount" type="BigDecimal" >>>> mode="IN" >>>> optional="true"/> >>>> *<attribute name="shippingAddress" >>>> type="org.ofbiz.entity.GenericValue" mode="IN" optional="true"/> >>>> <attribute name="orderAdjustments" type="java.util.List" >>>> mode="OUT" >>>> optional="false"></attribute> >>>> <attribute name="itemAdjustments" type="java.util.List" >>>> mode="OUT" >>>> optional="false"></attribute> >>>> </service> >>>> >>>> This interface must have /OrderAdjustment/ list as IN parameter. >>>> >>>> That is my draft solution. >>>> Any ideas? What is your opinion? >>>> >>> -- >>> View this message in context: >>> http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4247763.html >>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >> > -- View this message in context: http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4254879.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
