Also one of my client is interested by having shipping rates by suppliers, just another idea in this field (I don't develop for this
client, just some consulting by mail)
Jacques
From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
Hi Paul,
Yes you are right, could be a fallback only indeed (in some cases no needs to create more, for instance if you are doing business
only in France then the rates don't change)
Jacques
From: "Paul Foxworthy" <p...@cohsoft.com.au>
Hi Jacques,
I think there's a difference.
Yes, the ProductStore is indeed a profit centre for our organization.
It is reasonable to have VAT parameters related to a ProductStore for sales,
because the product store is in one location for tax accounting purposes.
The entries in TaxAuthorityRateProduct define the tax authorities that are
relevant to the location of the product store. Note that the taxAuthGeoId
attribute in TaxAuthorityRateProduct is for the location of the purchaser,
not the seller. Now, if we had two product stores located close to each
other, say in the same state/province, they could well have duplicated VAT
information. Provided the number of stores isn't huge, we can live with the
duplication.
In contrast, for purchases, there are many suppliers, perhaps in many
different locations with different VAT policies. The new entity we're
envisaging should have rows for each location where there is at least one
supplier, and we want estimated VAT to be automatically added to purchase
orders. I don't envisage a row for each supplier. That would mean an
explosion of rows with duplicated information on the VAT rates for some
location.
I think it most unlikely that you would want to allocate cost centres to a
purchase based just on the *location* of the supplier. You might want to do
it based on who the supplier is, which division of our organization is
making the purchase, what project the purchase is relevant to, or many other
criteria. But none of those facts will be in the new entity we're
considering.
Cheers
Paul Foxworthy
Jacques Le Roux wrote
Hi Paul,
This comes from Hans's answer
as you suggested,
producrstore should not be used for purchase orders or anything
purchase
tax related,
productstore is for sales only
My basic idea was that you set VAT parameters on profit center (VAT fields
in ProductStore UI:
...catalog/control/EditProductStore?productStoreId=...) so if you need to
set VAT for incoming orders (purchases) the same kind of
stuff could be set from a new CostCenter Entity. But really I did not put
much thoughts in that, just remembered this thread, and
it's maybe not even a good idea...
Jacques
From: "Paul Foxworthy" <paul@.com>
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.
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Tax-calculation-for-all-order-adjustments-tp4153757p4259790.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
