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" <mailingl...@antwebsystems.com>
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.
