Dev - Mods to the TaxAuth services to display party's taxes in prices instead of product store's one

[Jacopo Cappellato]

Hi all,

I need your help to review some mods I did to the
TaxAuthorityServices.java file to improve the way prices are shown in
ecommerce when the ProductStore.showPricesWithVatTax is set to "Y".

When the flag is set to "Y", prices in ecommerce pages are shown with
tax included.

However there are some problems with the current code:

1) a NPE is thrown because the "shippingAmount" variable is not set when
you browse products' categories; easy to fix (see the mod in the
attached patch around lines @@ -295,7 +316,7 @@)

2) taxes are always shown for the authorities set in the ProductStore;
this is ok for anonymous users but not for logged in users: for the
latter we should try to show taxes based on the users' shipping (or
billing?) address instead of the ones of the store; yes, it's true that
if a user has more than one shipping address (belonging to different
states with different tax auths) we will know which taxes to apply only
after the user has selected the shipping destination in the checkout
process; however, in my opinion, it's better to show the taxes applied
to one of the user's addresses instead of the ones of the product store;
the code in the patch does exactly this:

in the rateProductTaxCalcForDisplay method, if a party can be found for
the "billToPartyId" parameter, the first shipping address is searched,
if not found the first billing address is searched; if nothing is found,
then the product store's authorities are used, otherwise only the
authorities relevant for the party are considered.

What do you thing of this? Can I put it in SVN?

To facilitate the review of this mod, you'll find attached to this
message the patch and the whole class.

Let me know! I've tested it and it works fine.

Jacopo

Index: applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
===================================================================
--- applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java (revision 7388)
+++ applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java (working copy)
@@ -91,15 +91,32 @@
             
             if ("Y".equals(productStore.getString("showPricesWithVatTax"))) {
                 Set taxAuthoritySet = FastSet.newInstance();
-                if (productStore.get("vatTaxAuthPartyId") == null) {
-                    List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.EQUALS, productStore.get("vatTaxAuthGeoId")), null, null);
-                    taxAuthoritySet.addAll(taxAuthorityRawList);
-                } else {
-                    GenericValue taxAuthority = delegator.findByPrimaryKeyCache("TaxAuthority", UtilMisc.toMap("taxAuthGeoId", productStore.get("vatTaxAuthGeoId"), "taxAuthPartyId", productStore.get("vatTaxAuthPartyId")));
-                    taxAuthoritySet.add(taxAuthority);
+                // First of all, search for tax authorities for the party (if there is one)
+                GenericValue party = delegator.findByPrimaryKey("Party", UtilMisc.toMap("partyId", billToPartyId));
+                if (party != null) {
+                    List billingContactMechList = (List)org.ofbiz.party.contact.ContactHelper.getContactMech(party, "SHIPPING_LOCATION", "POSTAL_ADDRESS", false);
+                    GenericValue defaultShippingContactMech = EntityUtil.getFirst(billingContactMechList);
+                    if (defaultShippingContactMech == null) {
+                        billingContactMechList = (List)org.ofbiz.party.contact.ContactHelper.getContactMech(party, "BILLING_LOCATION", "POSTAL_ADDRESS", false);
+                        defaultShippingContactMech = EntityUtil.getFirst(billingContactMechList);
+                    }
+                    GenericValue shippingAddress = null;
+                    if (defaultShippingContactMech != null) {
+                        shippingAddress = delegator.findByPrimaryKey("PostalAddress", UtilMisc.toMap("contactMechId", defaultShippingContactMech.getString("contactMechId")));
+                    }
+                    getTaxAuthorities(delegator, shippingAddress, taxAuthoritySet);
                 }
-                
+                // If no tax authority is found for the given party, then use the product store's authority
                 if (taxAuthoritySet.size() == 0) {
+                    if (productStore.get("vatTaxAuthPartyId") == null) {
+                        List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.EQUALS, productStore.get("vatTaxAuthGeoId")), null, null);
+                        taxAuthoritySet.addAll(taxAuthorityRawList);
+                    } else {
+                        GenericValue taxAuthority = delegator.findByPrimaryKeyCache("TaxAuthority", UtilMisc.toMap("taxAuthGeoId", productStore.get("vatTaxAuthGeoId"), "taxAuthPartyId", productStore.get("vatTaxAuthPartyId")));
+                        taxAuthoritySet.add(taxAuthority);
+                    }
+                }
+                if (taxAuthoritySet.size() == 0) {
                     throw new IllegalArgumentException("Could not find any Tax Authories for store with ID [" + productStoreId + "] for tax calculation; the store settings may need to be corrected.");
                 }
                 
@@ -152,26 +169,10 @@
         Set taxAuthoritySet = FastSet.newInstance();
         GenericValue productStore = null;
         try {
-            Set geoIdSet = FastSet.newInstance();
-            if (shippingAddress != null) {
-                if (shippingAddress.getString("countryGeoId") != null) {
-                    geoIdSet.add(shippingAddress.getString("countryGeoId"));
-                }
-                if (shippingAddress.getString("stateProvinceGeoId") != null) {
-                    geoIdSet.add(shippingAddress.getString("stateProvinceGeoId"));
-                }
-            }
-            
-            if (geoIdSet.size() == 0) {
+            getTaxAuthorities(delegator, shippingAddress, taxAuthoritySet);
+            if (taxAuthoritySet.size() == 0) {
                 return ServiceUtil.returnError("The address(es) used for tax calculation did not have State/Province or Country values set, so we cannot determine the taxes to charge.");
             }
-            
-            // get the most granular, or all available, geoIds and then find parents by GeoAssoc with geoAssocTypeId="REGIONS" and geoIdTo=<granular geoId> and find the GeoAssoc.geoId
-            geoIdSet = GeoWorker.expandGeoRegionDeep(geoIdSet, delegator);
-
-            List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.IN, geoIdSet), null, null);
-            taxAuthoritySet.addAll(taxAuthorityRawList);
-
             productStore = delegator.findByPrimaryKey("ProductStore", UtilMisc.toMap("productStoreId", productStoreId));
         } catch (GenericEntityException e) {
             String errMsg = "Data error getting tax settings: " + e.toString();
@@ -212,6 +213,26 @@
         return result;
     }
 
+    private static void getTaxAuthorities(GenericDelegator delegator, GenericValue shippingAddress, Set taxAuthoritySet) throws GenericEntityException {
+        Set geoIdSet = FastSet.newInstance();
+        if (shippingAddress != null) {
+            if (shippingAddress.getString("countryGeoId") != null) {
+                geoIdSet.add(shippingAddress.getString("countryGeoId"));
+            }
+            if (shippingAddress.getString("stateProvinceGeoId") != null) {
+                geoIdSet.add(shippingAddress.getString("stateProvinceGeoId"));
+            }
+        }
+
+        if (geoIdSet.size() > 0) {
+            // get the most granular, or all available, geoIds and then find parents by GeoAssoc with geoAssocTypeId="REGIONS" and geoIdTo=<granular geoId> and find the GeoAssoc.geoId
+            geoIdSet = GeoWorker.expandGeoRegionDeep(geoIdSet, delegator);
+
+            List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.IN, geoIdSet), null, null);
+            taxAuthoritySet.addAll(taxAuthorityRawList);
+        }
+    }
+
     private static List getTaxAdjustments(GenericDelegator delegator, GenericValue product, GenericValue productStore, String billToPartyId, Set taxAuthoritySet, BigDecimal itemPrice, BigDecimal itemAmount, BigDecimal shippingAmount) {
         Timestamp nowTimestamp = UtilDateTime.nowTimestamp();
         List adjustments = FastList.newInstance();
@@ -295,7 +316,7 @@
                 if (product != null && (product.get("taxable") == null || (product.get("taxable") != null && product.getBoolean("taxable").booleanValue()))) {
                     taxable = taxable.add(itemAmount);
                 }
-                if (taxAuthorityRateProduct != null && (taxAuthorityRateProduct.get("taxShipping") == null || (taxAuthorityRateProduct.get("taxShipping") != null && taxAuthorityRateProduct.getBoolean("taxShipping").booleanValue()))) {
+                if (shippingAmount != null && taxAuthorityRateProduct != null && (taxAuthorityRateProduct.get("taxShipping") == null || (taxAuthorityRateProduct.get("taxShipping") != null && taxAuthorityRateProduct.getBoolean("taxShipping").booleanValue()))) {
                     taxable = taxable.add(shippingAmount);
                 }
                 

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

Please,

ignore the patches attached to my previous post and consider the ones
attached to this one (there was an error in them).

Jacopo

Jacopo Cappellato wrote:

> Hi all,
>
> I need your help to review some mods I did to the
> TaxAuthorityServices.java file to improve the way prices are shown in
> ecommerce when the ProductStore.showPricesWithVatTax is set to "Y".
>
> When the flag is set to "Y", prices in ecommerce pages are shown with
> tax included.
>
> However there are some problems with the current code:
>
> 1) a NPE is thrown because the "shippingAmount" variable is not set when
> you browse products' categories; easy to fix (see the mod in the
> attached patch around lines @@ -295,7 +316,7 @@)
>
> 2) taxes are always shown for the authorities set in the ProductStore;
> this is ok for anonymous users but not for logged in users: for the
> latter we should try to show taxes based on the users' shipping (or
> billing?) address instead of the ones of the store; yes, it's true that
> if a user has more than one shipping address (belonging to different
> states with different tax auths) we will know which taxes to apply only
> after the user has selected the shipping destination in the checkout
> process; however, in my opinion, it's better to show the taxes applied
> to one of the user's addresses instead of the ones of the product store;
> the code in the patch does exactly this:
>
> in the rateProductTaxCalcForDisplay method, if a party can be found for
> the "billToPartyId" parameter, the first shipping address is searched,
> if not found the first billing address is searched; if nothing is found,
> then the product store's authorities are used, otherwise only the
> authorities relevant for the party are considered.
>
> What do you thing of this? Can I put it in SVN?
>
> To facilitate the review of this mod, you'll find attached to this
> message the patch and the whole class.
>
> Let me know! I've tested it and it works fine.
>
> Jacopo
>
>

Index: applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
===================================================================
--- applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java (revision 7388)
+++ applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java (working copy)
@@ -91,15 +91,32 @@
             
             if ("Y".equals(productStore.getString("showPricesWithVatTax"))) {
                 Set taxAuthoritySet = FastSet.newInstance();
-                if (productStore.get("vatTaxAuthPartyId") == null) {
-                    List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.EQUALS, productStore.get("vatTaxAuthGeoId")), null, null);
-                    taxAuthoritySet.addAll(taxAuthorityRawList);
-                } else {
-                    GenericValue taxAuthority = delegator.findByPrimaryKeyCache("TaxAuthority", UtilMisc.toMap("taxAuthGeoId", productStore.get("vatTaxAuthGeoId"), "taxAuthPartyId", productStore.get("vatTaxAuthPartyId")));
-                    taxAuthoritySet.add(taxAuthority);
+                // First of all, search for tax authorities for the party (if there is one)
+                GenericValue party = delegator.findByPrimaryKey("Party", UtilMisc.toMap("partyId", billToPartyId));
+                if (party != null) {
+                    List billingContactMechList = (List)org.ofbiz.party.contact.ContactHelper.getContactMech(party, "SHIPPING_LOCATION", "POSTAL_ADDRESS", false);
+                    GenericValue defaultShippingContactMech = EntityUtil.getFirst(billingContactMechList);
+                    if (defaultShippingContactMech == null) {
+                        billingContactMechList = (List)org.ofbiz.party.contact.ContactHelper.getContactMech(party, "BILLING_LOCATION", "POSTAL_ADDRESS", false);
+                        defaultShippingContactMech = EntityUtil.getFirst(billingContactMechList);
+                    }
+                    GenericValue shippingAddress = null;
+                    if (defaultShippingContactMech != null) {
+                        shippingAddress = delegator.findByPrimaryKey("PostalAddress", UtilMisc.toMap("contactMechId", defaultShippingContactMech.getString("contactMechId")));
+                    }
+                    getTaxAuthorities(delegator, shippingAddress, taxAuthoritySet);
                 }
-                
+                // If no tax authority is found for the given party, then use the product store's authority
                 if (taxAuthoritySet.size() == 0) {
+                    if (productStore.get("vatTaxAuthPartyId") == null) {
+                        List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.EQUALS, productStore.get("vatTaxAuthGeoId")), null, null);
+                        taxAuthoritySet.addAll(taxAuthorityRawList);
+                    } else {
+                        GenericValue taxAuthority = delegator.findByPrimaryKeyCache("TaxAuthority", UtilMisc.toMap("taxAuthGeoId", productStore.get("vatTaxAuthGeoId"), "taxAuthPartyId", productStore.get("vatTaxAuthPartyId")));
+                        taxAuthoritySet.add(taxAuthority);
+                    }
+                }
+                if (taxAuthoritySet.size() == 0) {
                     throw new IllegalArgumentException("Could not find any Tax Authories for store with ID [" + productStoreId + "] for tax calculation; the store settings may need to be corrected.");
                 }
                 
@@ -148,30 +165,14 @@
         BigDecimal orderShippingAmount = (BigDecimal) context.get("orderShippingAmount");
         GenericValue shippingAddress = (GenericValue) context.get("shippingAddress");
 
+        if (shippingAddress == null || (shippingAddress.get("countryGeoId") == null && shippingAddress.get("stateProvinceGeoId") == null)) {
+            return ServiceUtil.returnError("The address(es) used for tax calculation did not have State/Province or Country values set, so we cannot determine the taxes to charge.");
+        }
         // without knowing the TaxAuthority parties, just find all TaxAuthories for the set of IDs...
         Set taxAuthoritySet = FastSet.newInstance();
         GenericValue productStore = null;
         try {
-            Set geoIdSet = FastSet.newInstance();
-            if (shippingAddress != null) {
-                if (shippingAddress.getString("countryGeoId") != null) {
-                    geoIdSet.add(shippingAddress.getString("countryGeoId"));
-                }
-                if (shippingAddress.getString("stateProvinceGeoId") != null) {
-                    geoIdSet.add(shippingAddress.getString("stateProvinceGeoId"));
-                }
-            }
-            
-            if (geoIdSet.size() == 0) {
-                return ServiceUtil.returnError("The address(es) used for tax calculation did not have State/Province or Country values set, so we cannot determine the taxes to charge.");
-            }
-            
-            // get the most granular, or all available, geoIds and then find parents by GeoAssoc with geoAssocTypeId="REGIONS" and geoIdTo=<granular geoId> and find the GeoAssoc.geoId
-            geoIdSet = GeoWorker.expandGeoRegionDeep(geoIdSet, delegator);
-
-            List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.IN, geoIdSet), null, null);
-            taxAuthoritySet.addAll(taxAuthorityRawList);
-
+            getTaxAuthorities(delegator, shippingAddress, taxAuthoritySet);
             productStore = delegator.findByPrimaryKey("ProductStore", UtilMisc.toMap("productStoreId", productStoreId));
         } catch (GenericEntityException e) {
             String errMsg = "Data error getting tax settings: " + e.toString();
@@ -212,6 +213,23 @@
         return result;
     }
 
+    private static void getTaxAuthorities(GenericDelegator delegator, GenericValue shippingAddress, Set taxAuthoritySet) throws GenericEntityException {
+        Set geoIdSet = FastSet.newInstance();
+        if (shippingAddress != null) {
+            if (shippingAddress.getString("countryGeoId") != null) {
+                geoIdSet.add(shippingAddress.getString("countryGeoId"));
+            }
+            if (shippingAddress.getString("stateProvinceGeoId") != null) {
+                geoIdSet.add(shippingAddress.getString("stateProvinceGeoId"));
+            }
+        }
+        // get the most granular, or all available, geoIds and then find parents by GeoAssoc with geoAssocTypeId="REGIONS" and geoIdTo=<granular geoId> and find the GeoAssoc.geoId
+        geoIdSet = GeoWorker.expandGeoRegionDeep(geoIdSet, delegator);
+
+        List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.IN, geoIdSet), null, null);
+        taxAuthoritySet.addAll(taxAuthorityRawList);
+    }
+
     private static List getTaxAdjustments(GenericDelegator delegator, GenericValue product, GenericValue productStore, String billToPartyId, Set taxAuthoritySet, BigDecimal itemPrice, BigDecimal itemAmount, BigDecimal shippingAmount) {
         Timestamp nowTimestamp = UtilDateTime.nowTimestamp();
         List adjustments = FastList.newInstance();
@@ -295,7 +313,7 @@
                 if (product != null && (product.get("taxable") == null || (product.get("taxable") != null && product.getBoolean("taxable").booleanValue()))) {
                     taxable = taxable.add(itemAmount);
                 }
-                if (taxAuthorityRateProduct != null && (taxAuthorityRateProduct.get("taxShipping") == null || (taxAuthorityRateProduct.get("taxShipping") != null && taxAuthorityRateProduct.getBoolean("taxShipping").booleanValue()))) {
+                if (shippingAmount != null && taxAuthorityRateProduct != null && (taxAuthorityRateProduct.get("taxShipping") == null || (taxAuthorityRateProduct.get("taxShipping") != null && taxAuthorityRateProduct.getBoolean("taxShipping").booleanValue()))) {
                     taxable = taxable.add(shippingAmount);
                 }
                 

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Daniel Kunkel]

Hi Jacopo

Please excuse me if there's a solution to a related issue and I've
missed it... but given your current idea I thought I would share it.

We have customers that want not to be taxed on the products that they
resell and to be taxed on others.

Is there an easy way to change the tax adjustments on a product by
product basis is an order...  or would it also be worthwhile to add some
user control as to whether or not to charge tax on a particular product?

Actually, a more flexible system would allow the qualified users (those
with tax resale status) to adjust the number of items up to the number
ordered as resale.

Thanks

Daniel




On Mon, 2006-04-24 at 17:02 +0200, Jacopo Cappellato wrote:

> Please,
>
> ignore the patches attached to my previous post and consider the ones
> attached to this one (there was an error in them).
>
> Jacopo
>
> Jacopo Cappellato wrote:
> > Hi all,
> >
> > I need your help to review some mods I did to the
> > TaxAuthorityServices.java file to improve the way prices are shown in
> > ecommerce when the ProductStore.showPricesWithVatTax is set to "Y".
> >
> > When the flag is set to "Y", prices in ecommerce pages are shown with
> > tax included.
> >
> > However there are some problems with the current code:
> >
> > 1) a NPE is thrown because the "shippingAmount" variable is not set when
> > you browse products' categories; easy to fix (see the mod in the
> > attached patch around lines @@ -295,7 +316,7 @@)
> >
> > 2) taxes are always shown for the authorities set in the ProductStore;
> > this is ok for anonymous users but not for logged in users: for the
> > latter we should try to show taxes based on the users' shipping (or
> > billing?) address instead of the ones of the store; yes, it's true that
> > if a user has more than one shipping address (belonging to different
> > states with different tax auths) we will know which taxes to apply only
> > after the user has selected the shipping destination in the checkout
> > process; however, in my opinion, it's better to show the taxes applied
> > to one of the user's addresses instead of the ones of the product store;
> > the code in the patch does exactly this:
> >
> > in the rateProductTaxCalcForDisplay method, if a party can be found for
> > the "billToPartyId" parameter, the first shipping address is searched,
> > if not found the first billing address is searched; if nothing is found,
> > then the product store's authorities are used, otherwise only the
> > authorities relevant for the party are considered.
> >
> > What do you thing of this? Can I put it in SVN?
> >
> > To facilitate the review of this mod, you'll find attached to this
> > message the patch and the whole class.
> >
> > Let me know! I've tested it and it works fine.
> >
> > Jacopo
> >
> >
>
> plain text document attachment (TaxAuthorityServices.java.patch)
> Index: applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
> ===================================================================
> --- applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java (revision 7388)
> +++ applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java (working copy)
> @@ -91,15 +91,32 @@
>              
>              if ("Y".equals(productStore.getString("showPricesWithVatTax"))) {
>                  Set taxAuthoritySet = FastSet.newInstance();
> -                if (productStore.get("vatTaxAuthPartyId") == null) {
> -                    List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.EQUALS, productStore.get("vatTaxAuthGeoId")), null, null);
> -                    taxAuthoritySet.addAll(taxAuthorityRawList);
> -                } else {
> -                    GenericValue taxAuthority = delegator.findByPrimaryKeyCache("TaxAuthority", UtilMisc.toMap("taxAuthGeoId", productStore.get("vatTaxAuthGeoId"), "taxAuthPartyId", productStore.get("vatTaxAuthPartyId")));
> -                    taxAuthoritySet.add(taxAuthority);
> +                // First of all, search for tax authorities for the party (if there is one)
> +                GenericValue party = delegator.findByPrimaryKey("Party", UtilMisc.toMap("partyId", billToPartyId));
> +                if (party != null) {
> +                    List billingContactMechList = (List)org.ofbiz.party.contact.ContactHelper.getContactMech(party, "SHIPPING_LOCATION", "POSTAL_ADDRESS", false);
> +                    GenericValue defaultShippingContactMech = EntityUtil.getFirst(billingContactMechList);
> +                    if (defaultShippingContactMech == null) {
> +                        billingContactMechList = (List)org.ofbiz.party.contact.ContactHelper.getContactMech(party, "BILLING_LOCATION", "POSTAL_ADDRESS", false);
> +                        defaultShippingContactMech = EntityUtil.getFirst(billingContactMechList);
> +                    }
> +                    GenericValue shippingAddress = null;
> +                    if (defaultShippingContactMech != null) {
> +                        shippingAddress = delegator.findByPrimaryKey("PostalAddress", UtilMisc.toMap("contactMechId", defaultShippingContactMech.getString("contactMechId")));
> +                    }
> +                    getTaxAuthorities(delegator, shippingAddress, taxAuthoritySet);
>                  }
> -                
> +                // If no tax authority is found for the given party, then use the product store's authority
>                  if (taxAuthoritySet.size() == 0) {
> +                    if (productStore.get("vatTaxAuthPartyId") == null) {
> +                        List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.EQUALS, productStore.get("vatTaxAuthGeoId")), null, null);
> +                        taxAuthoritySet.addAll(taxAuthorityRawList);
> +                    } else {
> +                        GenericValue taxAuthority = delegator.findByPrimaryKeyCache("TaxAuthority", UtilMisc.toMap("taxAuthGeoId", productStore.get("vatTaxAuthGeoId"), "taxAuthPartyId", productStore.get("vatTaxAuthPartyId")));
> +                        taxAuthoritySet.add(taxAuthority);
> +                    }
> +                }
> +                if (taxAuthoritySet.size() == 0) {
>                      throw new IllegalArgumentException("Could not find any Tax Authories for store with ID [" + productStoreId + "] for tax calculation; the store settings may need to be corrected.");
>                  }
>                  
> @@ -148,30 +165,14 @@
>          BigDecimal orderShippingAmount = (BigDecimal) context.get("orderShippingAmount");
>          GenericValue shippingAddress = (GenericValue) context.get("shippingAddress");
>  
> +        if (shippingAddress == null || (shippingAddress.get("countryGeoId") == null && shippingAddress.get("stateProvinceGeoId") == null)) {
> +            return ServiceUtil.returnError("The address(es) used for tax calculation did not have State/Province or Country values set, so we cannot determine the taxes to charge.");
> +        }
>          // without knowing the TaxAuthority parties, just find all TaxAuthories for the set of IDs...
>          Set taxAuthoritySet = FastSet.newInstance();
>          GenericValue productStore = null;
>          try {
> -            Set geoIdSet = FastSet.newInstance();
> -            if (shippingAddress != null) {
> -                if (shippingAddress.getString("countryGeoId") != null) {
> -                    geoIdSet.add(shippingAddress.getString("countryGeoId"));
> -                }
> -                if (shippingAddress.getString("stateProvinceGeoId") != null) {
> -                    geoIdSet.add(shippingAddress.getString("stateProvinceGeoId"));
> -                }
> -            }
> -            
> -            if (geoIdSet.size() == 0) {
> -                return ServiceUtil.returnError("The address(es) used for tax calculation did not have State/Province or Country values set, so we cannot determine the taxes to charge.");
> -            }
> -            
> -            // get the most granular, or all available, geoIds and then find parents by GeoAssoc with geoAssocTypeId="REGIONS" and geoIdTo=<granular geoId> and find the GeoAssoc.geoId
> -            geoIdSet = GeoWorker.expandGeoRegionDeep(geoIdSet, delegator);
> -
> -            List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.IN, geoIdSet), null, null);
> -            taxAuthoritySet.addAll(taxAuthorityRawList);
> -
> +            getTaxAuthorities(delegator, shippingAddress, taxAuthoritySet);
>              productStore = delegator.findByPrimaryKey("ProductStore", UtilMisc.toMap("productStoreId", productStoreId));
>          } catch (GenericEntityException e) {
>              String errMsg = "Data error getting tax settings: " + e.toString();
> @@ -212,6 +213,23 @@
>          return result;
>      }
>  
> +    private static void getTaxAuthorities(GenericDelegator delegator, GenericValue shippingAddress, Set taxAuthoritySet) throws GenericEntityException {
> +        Set geoIdSet = FastSet.newInstance();
> +        if (shippingAddress != null) {
> +            if (shippingAddress.getString("countryGeoId") != null) {
> +                geoIdSet.add(shippingAddress.getString("countryGeoId"));
> +            }
> +            if (shippingAddress.getString("stateProvinceGeoId") != null) {
> +                geoIdSet.add(shippingAddress.getString("stateProvinceGeoId"));
> +            }
> +        }
> +        // get the most granular, or all available, geoIds and then find parents by GeoAssoc with geoAssocTypeId="REGIONS" and geoIdTo=<granular geoId> and find the GeoAssoc.geoId
> +        geoIdSet = GeoWorker.expandGeoRegionDeep(geoIdSet, delegator);
> +
> +        List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.IN, geoIdSet), null, null);
> +        taxAuthoritySet.addAll(taxAuthorityRawList);
> +    }
> +
>      private static List getTaxAdjustments(GenericDelegator delegator, GenericValue product, GenericValue productStore, String billToPartyId, Set taxAuthoritySet, BigDecimal itemPrice, BigDecimal itemAmount, BigDecimal shippingAmount) {
>          Timestamp nowTimestamp = UtilDateTime.nowTimestamp();
>          List adjustments = FastList.newInstance();
> @@ -295,7 +313,7 @@
>                  if (product != null && (product.get("taxable") == null || (product.get("taxable") != null && product.getBoolean("taxable").booleanValue()))) {
>                      taxable = taxable.add(itemAmount);
>                  }
> -                if (taxAuthorityRateProduct != null && (taxAuthorityRateProduct.get("taxShipping") == null || (taxAuthorityRateProduct.get("taxShipping") != null && taxAuthorityRateProduct.getBoolean("taxShipping").booleanValue()))) {
> +                if (shippingAmount != null && taxAuthorityRateProduct != null && (taxAuthorityRateProduct.get("taxShipping") == null || (taxAuthorityRateProduct.get("taxShipping") != null && taxAuthorityRateProduct.getBoolean("taxShipping").booleanValue()))) {
>                      taxable = taxable.add(shippingAmount);
>                  }
>                  
>  _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

--
Daniel

*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Have a GREAT Day!

Daniel Kunkel           [hidden email]
BioWaves, LLC           http://www.BioWaves.com
14150 NE 20th St. Suite F1
Bellevue, WA 98007
800-734-3588    425-895-0050
http://www.Apartment-Pets.com  http://www.Focus-Illusion.com
http://www.Brain-Fun.com       http://www.ColorGlasses.com
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

Daniel,

I think you can already do this setting properly the
TaxAuthorityRateProduct entries.

Have a look at Accounting->Tax Authorities->Product Rates

Jacopo

Daniel Kunkel wrote:

> Hi Jacopo
>
> Please excuse me if there's a solution to a related issue and I've
> missed it... but given your current idea I thought I would share it.
>
> We have customers that want not to be taxed on the products that they
> resell and to be taxed on others.
>
> Is there an easy way to change the tax adjustments on a product by
> product basis is an order...  or would it also be worthwhile to add some
> user control as to whether or not to charge tax on a particular product?
>
> Actually, a more flexible system would allow the qualified users (those
> with tax resale status) to adjust the number of items up to the number
> ordered as resale.
>
> Thanks
>
> Daniel
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Jacopo,

I haven't reviewed your patches in detail, so this is mostly just a response to your comments...

The changes for #1 should be good. Solving NPE problems is pretty much always a good thing.

For #2 this brings up a difficult question that the current design avoids asking by just supporting the concept that different locales would have different ProductStores, even if those different ProductStores were used to sell the same Products.

The hard question is when to charge a VAT tax. The rules for charging VAT taxes are often different from a sales tax, so the VAT to charge my not have anything to do with where the customer is having the order billed or shipped to, but rather where it is coming from. I think this varies in different jurisdictions according to their local tax policy. This was another the reason for putting it on the ProductStore, that tax would generally just be charged for the location of the business behind the store, or of the fulfillment center or what not.

Even without considering what is in that last paragraph, and perhaps some sort of flag on each TaxAuthority record to specify how tax should be handled, and it is necessary to collect a VAT tax based on the customer's billing or shipping address, another things that should go into your list of things to check is if the "Company" selling the good (ie the one specified on the ProductStore) has a "nexus" or sufficient presence in that Geo to have a need to collect taxes there (this is already considered for other parts of the tax functionality, so using it here would just make it more consistent.

-David


Jacopo Cappellato wrote:

> Hi all,
>
> I need your help to review some mods I did to the
> TaxAuthorityServices.java file to improve the way prices are shown in
> ecommerce when the ProductStore.showPricesWithVatTax is set to "Y".
>
> When the flag is set to "Y", prices in ecommerce pages are shown with
> tax included.
>
> However there are some problems with the current code:
>
> 1) a NPE is thrown because the "shippingAmount" variable is not set when
> you browse products' categories; easy to fix (see the mod in the
> attached patch around lines @@ -295,7 +316,7 @@)
>
> 2) taxes are always shown for the authorities set in the ProductStore;
> this is ok for anonymous users but not for logged in users: for the
> latter we should try to show taxes based on the users' shipping (or
> billing?) address instead of the ones of the store; yes, it's true that
> if a user has more than one shipping address (belonging to different
> states with different tax auths) we will know which taxes to apply only
> after the user has selected the shipping destination in the checkout
> process; however, in my opinion, it's better to show the taxes applied
> to one of the user's addresses instead of the ones of the product store;
> the code in the patch does exactly this:
>
> in the rateProductTaxCalcForDisplay method, if a party can be found for
> the "billToPartyId" parameter, the first shipping address is searched,
> if not found the first billing address is searched; if nothing is found,
> then the product store's authorities are used, otherwise only the
> authorities relevant for the party are considered.
>
> What do you thing of this? Can I put it in SVN?
>
> To facilitate the review of this mod, you'll find attached to this
> message the patch and the whole class.
>
> Let me know! I've tested it and it works fine.
>
> Jacopo
>
>
> ------------------------------------------------------------------------
>
> Index: applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
> ===================================================================
> --- applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java (revision 7388)
> +++ applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java (working copy)
> @@ -91,15 +91,32 @@
>              
>              if ("Y".equals(productStore.getString("showPricesWithVatTax"))) {
>                  Set taxAuthoritySet = FastSet.newInstance();
> -                if (productStore.get("vatTaxAuthPartyId") == null) {
> -                    List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.EQUALS, productStore.get("vatTaxAuthGeoId")), null, null);
> -                    taxAuthoritySet.addAll(taxAuthorityRawList);
> -                } else {
> -                    GenericValue taxAuthority = delegator.findByPrimaryKeyCache("TaxAuthority", UtilMisc.toMap("taxAuthGeoId", productStore.get("vatTaxAuthGeoId"), "taxAuthPartyId", productStore.get("vatTaxAuthPartyId")));
> -                    taxAuthoritySet.add(taxAuthority);
> +                // First of all, search for tax authorities for the party (if there is one)
> +                GenericValue party = delegator.findByPrimaryKey("Party", UtilMisc.toMap("partyId", billToPartyId));
> +                if (party != null) {
> +                    List billingContactMechList = (List)org.ofbiz.party.contact.ContactHelper.getContactMech(party, "SHIPPING_LOCATION", "POSTAL_ADDRESS", false);
> +                    GenericValue defaultShippingContactMech = EntityUtil.getFirst(billingContactMechList);
> +                    if (defaultShippingContactMech == null) {
> +                        billingContactMechList = (List)org.ofbiz.party.contact.ContactHelper.getContactMech(party, "BILLING_LOCATION", "POSTAL_ADDRESS", false);
> +                        defaultShippingContactMech = EntityUtil.getFirst(billingContactMechList);
> +                    }
> +                    GenericValue shippingAddress = null;
> +                    if (defaultShippingContactMech != null) {
> +                        shippingAddress = delegator.findByPrimaryKey("PostalAddress", UtilMisc.toMap("contactMechId", defaultShippingContactMech.getString("contactMechId")));
> +                    }
> +                    getTaxAuthorities(delegator, shippingAddress, taxAuthoritySet);
>                  }
> -                
> +                // If no tax authority is found for the given party, then use the product store's authority
>                  if (taxAuthoritySet.size() == 0) {
> +                    if (productStore.get("vatTaxAuthPartyId") == null) {
> +                        List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.EQUALS, productStore.get("vatTaxAuthGeoId")), null, null);
> +                        taxAuthoritySet.addAll(taxAuthorityRawList);
> +                    } else {
> +                        GenericValue taxAuthority = delegator.findByPrimaryKeyCache("TaxAuthority", UtilMisc.toMap("taxAuthGeoId", productStore.get("vatTaxAuthGeoId"), "taxAuthPartyId", productStore.get("vatTaxAuthPartyId")));
> +                        taxAuthoritySet.add(taxAuthority);
> +                    }
> +                }
> +                if (taxAuthoritySet.size() == 0) {
>                      throw new IllegalArgumentException("Could not find any Tax Authories for store with ID [" + productStoreId + "] for tax calculation; the store settings may need to be corrected.");
>                  }
>                  
> @@ -152,26 +169,10 @@
>          Set taxAuthoritySet = FastSet.newInstance();
>          GenericValue productStore = null;
>          try {
> -            Set geoIdSet = FastSet.newInstance();
> -            if (shippingAddress != null) {
> -                if (shippingAddress.getString("countryGeoId") != null) {
> -                    geoIdSet.add(shippingAddress.getString("countryGeoId"));
> -                }
> -                if (shippingAddress.getString("stateProvinceGeoId") != null) {
> -                    geoIdSet.add(shippingAddress.getString("stateProvinceGeoId"));
> -                }
> -            }
> -            
> -            if (geoIdSet.size() == 0) {
> +            getTaxAuthorities(delegator, shippingAddress, taxAuthoritySet);
> +            if (taxAuthoritySet.size() == 0) {
>                  return ServiceUtil.returnError("The address(es) used for tax calculation did not have State/Province or Country values set, so we cannot determine the taxes to charge.");
>              }
> -            
> -            // get the most granular, or all available, geoIds and then find parents by GeoAssoc with geoAssocTypeId="REGIONS" and geoIdTo=<granular geoId> and find the GeoAssoc.geoId
> -            geoIdSet = GeoWorker.expandGeoRegionDeep(geoIdSet, delegator);
> -
> -            List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.IN, geoIdSet), null, null);
> -            taxAuthoritySet.addAll(taxAuthorityRawList);
> -
>              productStore = delegator.findByPrimaryKey("ProductStore", UtilMisc.toMap("productStoreId", productStoreId));
>          } catch (GenericEntityException e) {
>              String errMsg = "Data error getting tax settings: " + e.toString();
> @@ -212,6 +213,26 @@
>          return result;
>      }
>  
> +    private static void getTaxAuthorities(GenericDelegator delegator, GenericValue shippingAddress, Set taxAuthoritySet) throws GenericEntityException {
> +        Set geoIdSet = FastSet.newInstance();
> +        if (shippingAddress != null) {
> +            if (shippingAddress.getString("countryGeoId") != null) {
> +                geoIdSet.add(shippingAddress.getString("countryGeoId"));
> +            }
> +            if (shippingAddress.getString("stateProvinceGeoId") != null) {
> +                geoIdSet.add(shippingAddress.getString("stateProvinceGeoId"));
> +            }
> +        }
> +
> +        if (geoIdSet.size() > 0) {
> +            // get the most granular, or all available, geoIds and then find parents by GeoAssoc with geoAssocTypeId="REGIONS" and geoIdTo=<granular geoId> and find the GeoAssoc.geoId
> +            geoIdSet = GeoWorker.expandGeoRegionDeep(geoIdSet, delegator);
> +
> +            List taxAuthorityRawList = delegator.findByConditionCache("TaxAuthority", new EntityExpr("taxAuthGeoId", EntityOperator.IN, geoIdSet), null, null);
> +            taxAuthoritySet.addAll(taxAuthorityRawList);
> +        }
> +    }
> +
>      private static List getTaxAdjustments(GenericDelegator delegator, GenericValue product, GenericValue productStore, String billToPartyId, Set taxAuthoritySet, BigDecimal itemPrice, BigDecimal itemAmount, BigDecimal shippingAmount) {
>          Timestamp nowTimestamp = UtilDateTime.nowTimestamp();
>          List adjustments = FastList.newInstance();
> @@ -295,7 +316,7 @@
>                  if (product != null && (product.get("taxable") == null || (product.get("taxable") != null && product.getBoolean("taxable").booleanValue()))) {
>                      taxable = taxable.add(itemAmount);
>                  }
> -                if (taxAuthorityRateProduct != null && (taxAuthorityRateProduct.get("taxShipping") == null || (taxAuthorityRateProduct.get("taxShipping") != null && taxAuthorityRateProduct.getBoolean("taxShipping").booleanValue()))) {
> +                if (shippingAmount != null && taxAuthorityRateProduct != null && (taxAuthorityRateProduct.get("taxShipping") == null || (taxAuthorityRateProduct.get("taxShipping") != null && taxAuthorityRateProduct.getBoolean("taxShipping").booleanValue()))) {
>                      taxable = taxable.add(shippingAmount);
>                  }
>                  
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David,

thanks for the interesting information: I'll think a bit more about all
this stuff and I'll comment on them later on.

Jacopo

David E Jones wrote:

> Jacopo,
>
> I haven't reviewed your patches in detail, so this is mostly just a response to your comments...
>
> The changes for #1 should be good. Solving NPE problems is pretty much always a good thing.
>
> For #2 this brings up a difficult question that the current design avoids asking by just supporting the concept that different locales would have different ProductStores, even if those different ProductStores were used to sell the same Products.
>
> The hard question is when to charge a VAT tax. The rules for charging VAT taxes are often different from a sales tax, so the VAT to charge my not have anything to do with where the customer is having the order billed or shipped to, but rather where it is coming from. I think this varies in different jurisdictions according to their local tax policy. This was another the reason for putting it on the ProductStore, that tax would generally just be charged for the location of the business behind the store, or of the fulfillment center or what not.
>
> Even without considering what is in that last paragraph, and perhaps some sort of flag on each TaxAuthority record to specify how tax should be handled, and it is necessary to collect a VAT tax based on the customer's billing or shipping address, another things that should go into your list of things to check is if the "Company" selling the good (ie the one specified on the ProductStore) has a "nexus" or sufficient presence in that Geo to have a need to collect taxes there (this is already considered for other parts of the tax functionality, so using it here would just make it more consistent.
>
> -David
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David,

ok, I've reviewed the two TaxAuthorityServices responsible for tax
calculations:

* rateProductTaxCalc
* rateProductTaxCalcForDisplay

The former is used during checkout, the latter is used to display the
tax with the price in the category and product details screens of the
ecommerce site (when the ProductStore.showPricesWithVatTax is set to Y).

I think that the main problem (but I'm probably missing something) is
that the product store's vatTaxAuthGeoId and vatTaxAuthPartyId are only
considered by the rateProductTaxCalcForDisplay service and not by the
rateProductTaxCalc service: for this reason the taxes shown in the
category pages are different by the taxes used in checkout.

I'm not sure what was the original design, however I think that there
are two possibilities:

a) we leave rateProductTaxCalcForDisplay as is (i.e. to only consider
the tax authority set in the product store); we patch the
rateProductTaxCalc service to not consider the tax authorities
associated to the shippingAddress of the client (but only the tax auth
of the product store) IF the ProductStore.showPricesWithVatTax is set to Y

b) we modify the rateProductTaxCalcForDisplay to work in the same way
the rateProductTaxCalc service works if a party with a shippingAddress
is available; if not available (i.e. anonymous user or logged in user
with no postalAddress set) the tax auth of the product store is used

What do you think of these?

Thanks,

Jacopo




Jacopo Cappellato wrote:

> David,
>
> thanks for the interesting information: I'll think a bit more about all
> this stuff and I'll comment on them later on.
>
> Jacopo
>
> David E Jones wrote:
>> Jacopo,
>>
>> I haven't reviewed your patches in detail, so this is mostly just a response to your comments...
>>
>> The changes for #1 should be good. Solving NPE problems is pretty much always a good thing.
>>
>> For #2 this brings up a difficult question that the current design avoids asking by just supporting the concept that different locales would have different ProductStores, even if those different ProductStores were used to sell the same Products.
>>
>> The hard question is when to charge a VAT tax. The rules for charging VAT taxes are often different from a sales tax, so the VAT to charge my not have anything to do with where the customer is having the order billed or shipped to, but rather where it is coming from. I think this varies in different jurisdictions according to their local tax policy. This was another the reason for putting it on the ProductStore, that tax would generally just be charged for the location of the business behind the store, or of the fulfillment center or what not.
>>
>> Even without considering what is in that last paragraph, and perhaps some sort of flag on each TaxAuthority record to specify how tax should be handled, and it is necessary to collect a VAT tax based on the customer's billing or shipping address, another things that should go into your list of things to check is if the "Company" selling the good (ie the one specified on the ProductStore) has a "nexus" or sufficient presence in that Geo to have a need to collect taxes there (this is already considered for other parts of the tax functionality, so using it here would just make it more consistent.
>>
>> -David
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David,

I've forgot to mention that I've moved to a wiki page the information
about the TaxAuthrity data model that you posted to this list some time ago:

http://ofbizwiki.go-integral.com/Wiki.jsp?page=TaxAuthorityDataModel

These notes are pure gold!

Jacopo

Jacopo Cappellato wrote:

> David,
>
> ok, I've reviewed the two TaxAuthorityServices responsible for tax
> calculations:
>
> * rateProductTaxCalc
> * rateProductTaxCalcForDisplay
>
> The former is used during checkout, the latter is used to display the
> tax with the price in the category and product details screens of the
> ecommerce site (when the ProductStore.showPricesWithVatTax is set to Y).
>
> I think that the main problem (but I'm probably missing something) is
> that the product store's vatTaxAuthGeoId and vatTaxAuthPartyId are only
> considered by the rateProductTaxCalcForDisplay service and not by the
> rateProductTaxCalc service: for this reason the taxes shown in the
> category pages are different by the taxes used in checkout.
>
> I'm not sure what was the original design, however I think that there
> are two possibilities:
>
> a) we leave rateProductTaxCalcForDisplay as is (i.e. to only consider
> the tax authority set in the product store); we patch the
> rateProductTaxCalc service to not consider the tax authorities
> associated to the shippingAddress of the client (but only the tax auth
> of the product store) IF the ProductStore.showPricesWithVatTax is set to Y
>
> b) we modify the rateProductTaxCalcForDisplay to work in the same way
> the rateProductTaxCalc service works if a party with a shippingAddress
> is available; if not available (i.e. anonymous user or logged in user
> with no postalAddress set) the tax auth of the product store is used
>
> What do you think of these?
>
> Thanks,
>
> Jacopo
>
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Jacopo,

Yeah, there is a difference in these based on the information known when they are run.

One way or another there is a potential difference in the tax because of information not known until checkout begins. I like the (b) option more than (a) because it is at least an attempt to use information available when the user is logged in, but it doesn't solve the problem as the user could have multiple shipping and billing addresses and if a different one is selected or entered during checkout that will change the tax terms anyway.

It would be interesting to hear from others, but I don't think the (a) option is a good idea because tax may be charged that shouldn't be... But it depends on the tax rules of the local government. If they require a VAT tax regardless of where the product is shipped or billed to, then this would be the case. This could be an option on the TaxAuthority itself so that it is configured. That would be more appropriate as the goal for this code is legal compliance according to information we know from the customer at the time, not really consistency throughout (as unfortunately compliance is not so simple and friendly...).

Thanks for posting that stuff on the wiki, BTW.

-David


Jacopo Cappellato wrote:

> David,
>
> ok, I've reviewed the two TaxAuthorityServices responsible for tax
> calculations:
>
> * rateProductTaxCalc
> * rateProductTaxCalcForDisplay
>
> The former is used during checkout, the latter is used to display the
> tax with the price in the category and product details screens of the
> ecommerce site (when the ProductStore.showPricesWithVatTax is set to Y).
>
> I think that the main problem (but I'm probably missing something) is
> that the product store's vatTaxAuthGeoId and vatTaxAuthPartyId are only
> considered by the rateProductTaxCalcForDisplay service and not by the
> rateProductTaxCalc service: for this reason the taxes shown in the
> category pages are different by the taxes used in checkout.
>
> I'm not sure what was the original design, however I think that there
> are two possibilities:
>
> a) we leave rateProductTaxCalcForDisplay as is (i.e. to only consider
> the tax authority set in the product store); we patch the
> rateProductTaxCalc service to not consider the tax authorities
> associated to the shippingAddress of the client (but only the tax auth
> of the product store) IF the ProductStore.showPricesWithVatTax is set to Y
>
> b) we modify the rateProductTaxCalcForDisplay to work in the same way
> the rateProductTaxCalc service works if a party with a shippingAddress
> is available; if not available (i.e. anonymous user or logged in user
> with no postalAddress set) the tax auth of the product store is used
>
> What do you think of these?
>
> Thanks,
>
> Jacopo
>
>
>
>
> Jacopo Cappellato wrote:
>> David,
>>
>> thanks for the interesting information: I'll think a bit more about all
>> this stuff and I'll comment on them later on.
>>
>> Jacopo
>>
>> David E Jones wrote:
>>> Jacopo,
>>>
>>> I haven't reviewed your patches in detail, so this is mostly just a response to your comments...
>>>
>>> The changes for #1 should be good. Solving NPE problems is pretty much always a good thing.
>>>
>>> For #2 this brings up a difficult question that the current design avoids asking by just supporting the concept that different locales would have different ProductStores, even if those different ProductStores were used to sell the same Products.
>>>
>>> The hard question is when to charge a VAT tax. The rules for charging VAT taxes are often different from a sales tax, so the VAT to charge my not have anything to do with where the customer is having the order billed or shipped to, but rather where it is coming from. I think this varies in different jurisdictions according to their local tax policy. This was another the reason for putting it on the ProductStore, that tax would generally just be charged for the location of the business behind the store, or of the fulfillment center or what not.
>>>
>>> Even without considering what is in that last paragraph, and perhaps some sort of flag on each TaxAuthority record to specify how tax should be handled, and it is necessary to collect a VAT tax based on the customer's billing or shipping address, another things that should go into your list of things to check is if the "Company" selling the good (ie the one specified on the ProductStore) has a "nexus" or sufficient presence in that Geo to have a need to collect taxes there (this is already considered for other parts of the tax functionality, so using it here would just make it more consistent.
>>>
>>> -David
>>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Scott Gray]

Hi

I'm no expert on ecommerce but sometimes that can be a good thing if you
know what I mean...

My preference would be to see no taxes rather than the wrong taxes as I
might be basing my purchasing decision on what I'm seeing while I browse.  

How about showing prices excl taxes by default and possibly having an
'include my taxes' link near the price where a user could be shown a pop-up
window where they can enter their shipping address or geoid or whatever.
Perhaps if they are logged in they can select one of their shipping
addresses.  This is then stored for their session and prices are shown
including the correct taxes.

Regards
Scott

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of David E Jones
Sent: Thursday, 27 April 2006 10:08 a.m.
To: OFBiz Project Development Discussion
Subject: Re: [OFBiz] Dev - Mods to the TaxAuth services to display party's
taxes in prices instead of product store's one


Jacopo,

Yeah, there is a difference in these based on the information known when
they are run.

One way or another there is a potential difference in the tax because of
information not known until checkout begins. I like the (b) option more than
(a) because it is at least an attempt to use information available when the
user is logged in, but it doesn't solve the problem as the user could have
multiple shipping and billing addresses and if a different one is selected
or entered during checkout that will change the tax terms anyway.

It would be interesting to hear from others, but I don't think the (a)
option is a good idea because tax may be charged that shouldn't be... But it
depends on the tax rules of the local government. If they require a VAT tax
regardless of where the product is shipped or billed to, then this would be
the case. This could be an option on the TaxAuthority itself so that it is
configured. That would be more appropriate as the goal for this code is
legal compliance according to information we know from the customer at the
time, not really consistency throughout (as unfortunately compliance is not
so simple and friendly...).

Thanks for posting that stuff on the wiki, BTW.

-David


Jacopo Cappellato wrote:

> David,
>
> ok, I've reviewed the two TaxAuthorityServices responsible for tax
> calculations:
>
> * rateProductTaxCalc
> * rateProductTaxCalcForDisplay
>
> The former is used during checkout, the latter is used to display the
> tax with the price in the category and product details screens of the
> ecommerce site (when the ProductStore.showPricesWithVatTax is set to Y).
>
> I think that the main problem (but I'm probably missing something) is
> that the product store's vatTaxAuthGeoId and vatTaxAuthPartyId are only
> considered by the rateProductTaxCalcForDisplay service and not by the
> rateProductTaxCalc service: for this reason the taxes shown in the
> category pages are different by the taxes used in checkout.
>
> I'm not sure what was the original design, however I think that there
> are two possibilities:
>
> a) we leave rateProductTaxCalcForDisplay as is (i.e. to only consider
> the tax authority set in the product store); we patch the
> rateProductTaxCalc service to not consider the tax authorities
> associated to the shippingAddress of the client (but only the tax auth
> of the product store) IF the ProductStore.showPricesWithVatTax is set to Y
>
> b) we modify the rateProductTaxCalcForDisplay to work in the same way
> the rateProductTaxCalc service works if a party with a shippingAddress
> is available; if not available (i.e. anonymous user or logged in user
> with no postalAddress set) the tax auth of the product store is used
>
> What do you think of these?
>
> Thanks,
>
> Jacopo
>
>
>
>
> Jacopo Cappellato wrote:
>> David,
>>
>> thanks for the interesting information: I'll think a bit more about all
>> this stuff and I'll comment on them later on.
>>
>> Jacopo
>>
>> David E Jones wrote:
>>> Jacopo,
>>>
>>> I haven't reviewed your patches in detail, so this is mostly just a

response to your comments...
>>>
>>> The changes for #1 should be good. Solving NPE problems is pretty much
always a good thing.
>>>
>>> For #2 this brings up a difficult question that the current design
avoids asking by just supporting the concept that different locales would
have different ProductStores, even if those different ProductStores were
used to sell the same Products.
>>>
>>> The hard question is when to charge a VAT tax. The rules for charging
VAT taxes are often different from a sales tax, so the VAT to charge my not
have anything to do with where the customer is having the order billed or
shipped to, but rather where it is coming from. I think this varies in
different jurisdictions according to their local tax policy. This was
another the reason for putting it on the ProductStore, that tax would
generally just be charged for the location of the business behind the store,
or of the fulfillment center or what not.
>>>
>>> Even without considering what is in that last paragraph, and perhaps
some sort of flag on each TaxAuthority record to specify how tax should be
handled, and it is necessary to collect a VAT tax based on the customer's
billing or shipping address, another things that should go into your list of
things to check is if the "Company" selling the good (ie the one specified
on the ProductStore) has a "nexus" or sufficient presence in that Geo to
have a need to collect taxes there (this is already considered for other
parts of the tax functionality, so using it here would just make it more
consistent.

>>>
>>> -David
>>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Unfortunately for legal compliance this can be a problem...

The normal approach necessitated by commerce laws (and desire for more effective localized content, practices and management) is often to have separate sites for different locales, and in OFBiz that translates into separate stores. I just don't see a good way around that for global companies, but of course that is also from my somewhat limited experience...

-David


Scott Gray wrote:

> Hi
>
> I'm no expert on ecommerce but sometimes that can be a good thing if you
> know what I mean...
>
> My preference would be to see no taxes rather than the wrong taxes as I
> might be basing my purchasing decision on what I'm seeing while I browse.  
>
> How about showing prices excl taxes by default and possibly having an
> 'include my taxes' link near the price where a user could be shown a pop-up
> window where they can enter their shipping address or geoid or whatever.
> Perhaps if they are logged in they can select one of their shipping
> addresses.  This is then stored for their session and prices are shown
> including the correct taxes.
>
> Regards
> Scott
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of David E Jones
> Sent: Thursday, 27 April 2006 10:08 a.m.
> To: OFBiz Project Development Discussion
> Subject: Re: [OFBiz] Dev - Mods to the TaxAuth services to display party's
> taxes in prices instead of product store's one
>
>
> Jacopo,
>
> Yeah, there is a difference in these based on the information known when
> they are run.
>
> One way or another there is a potential difference in the tax because of
> information not known until checkout begins. I like the (b) option more than
> (a) because it is at least an attempt to use information available when the
> user is logged in, but it doesn't solve the problem as the user could have
> multiple shipping and billing addresses and if a different one is selected
> or entered during checkout that will change the tax terms anyway.
>
> It would be interesting to hear from others, but I don't think the (a)
> option is a good idea because tax may be charged that shouldn't be... But it
> depends on the tax rules of the local government. If they require a VAT tax
> regardless of where the product is shipped or billed to, then this would be
> the case. This could be an option on the TaxAuthority itself so that it is
> configured. That would be more appropriate as the goal for this code is
> legal compliance according to information we know from the customer at the
> time, not really consistency throughout (as unfortunately compliance is not
> so simple and friendly...).
>
> Thanks for posting that stuff on the wiki, BTW.
>
> -David
>
>
> Jacopo Cappellato wrote:
>> David,
>>
>> ok, I've reviewed the two TaxAuthorityServices responsible for tax
>> calculations:
>>
>> * rateProductTaxCalc
>> * rateProductTaxCalcForDisplay
>>
>> The former is used during checkout, the latter is used to display the
>> tax with the price in the category and product details screens of the
>> ecommerce site (when the ProductStore.showPricesWithVatTax is set to Y).
>>
>> I think that the main problem (but I'm probably missing something) is
>> that the product store's vatTaxAuthGeoId and vatTaxAuthPartyId are only
>> considered by the rateProductTaxCalcForDisplay service and not by the
>> rateProductTaxCalc service: for this reason the taxes shown in the
>> category pages are different by the taxes used in checkout.
>>
>> I'm not sure what was the original design, however I think that there
>> are two possibilities:
>>
>> a) we leave rateProductTaxCalcForDisplay as is (i.e. to only consider
>> the tax authority set in the product store); we patch the
>> rateProductTaxCalc service to not consider the tax authorities
>> associated to the shippingAddress of the client (but only the tax auth
>> of the product store) IF the ProductStore.showPricesWithVatTax is set to Y
>>
>> b) we modify the rateProductTaxCalcForDisplay to work in the same way
>> the rateProductTaxCalc service works if a party with a shippingAddress
>> is available; if not available (i.e. anonymous user or logged in user
>> with no postalAddress set) the tax auth of the product store is used
>>
>> What do you think of these?
>>
>> Thanks,
>>
>> Jacopo
>>
>>
>>
>>
>> Jacopo Cappellato wrote:
>>> David,
>>>
>>> thanks for the interesting information: I'll think a bit more about all
>>> this stuff and I'll comment on them later on.
>>>
>>> Jacopo
>>>
>>> David E Jones wrote:
>>>> Jacopo,
>>>>
>>>> I haven't reviewed your patches in detail, so this is mostly just a
> response to your comments...
>>>> The changes for #1 should be good. Solving NPE problems is pretty much
> always a good thing.
>>>> For #2 this brings up a difficult question that the current design
> avoids asking by just supporting the concept that different locales would
> have different ProductStores, even if those different ProductStores were
> used to sell the same Products.
>>>> The hard question is when to charge a VAT tax. The rules for charging
> VAT taxes are often different from a sales tax, so the VAT to charge my not
> have anything to do with where the customer is having the order billed or
> shipped to, but rather where it is coming from. I think this varies in
> different jurisdictions according to their local tax policy. This was
> another the reason for putting it on the ProductStore, that tax would
> generally just be charged for the location of the business behind the store,
> or of the fulfillment center or what not.
>>>> Even without considering what is in that last paragraph, and perhaps
> some sort of flag on each TaxAuthority record to specify how tax should be
> handled, and it is necessary to collect a VAT tax based on the customer's
> billing or shipping address, another things that should go into your list of
> things to check is if the "Company" selling the good (ie the one specified
> on the ProductStore) has a "nexus" or sufficient presence in that Geo to
> have a need to collect taxes there (this is already considered for other
> parts of the tax functionality, so using it here would just make it more
> consistent.
>>>> -David
>>>>
>>>  
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacques Le Roux]

David,

I was asking myself about changing licence to Apache 2 in POS files. Do you want
that I do this task ? Is there any problem to do so ?

Jacques

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacques Le Roux]

To be more precise , I must say that I think that you, Andy, Ray and me are the
only contributors to POS and Ray has also sent and iCLA.

May you confirm this point ?

Jacques



> David,
>
> I was asking myself about changing licence to Apache 2 in POS files. Do you
want
> that I do this task ? Is there any problem to do so ?
>
> Jacques
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

Hi Jacques,

first of all, you should issue an "svn log" command in the pos folder to
get all the commit messages related to the pos component; then, quickly
review them to see who contributed code; for every person found, go to
the http://ofbizwiki.go-integral.com/Wiki.jsp?page=OFBizDevelopers page
and see if that person has signed the iCLA; then you can change the license.

Jacopo


Jacques Le Roux wrote:

> David,
>
> I was asking myself about changing licence to Apache 2 in POS files. Do you want
> that I do this task ? Is there any problem to do so ?
>
> Jacques
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Jacques,

For any files that you have changed if you don't have a CLA on file yet then we're a bit stuck until that is taken care of. Technically you shouldn't have had commit privileges until your CLA was on file, but I guess we're not so formal yet. That will have to change soon and once the code base is moved to the ASF resources there won't be any option.

It is also necessary to review the commit logs (just "svn log" from the pos directory) and make sure no one without a CLA has made any significant changes. For some components, like I've started to play with, this is easy as few people have touched them, but you have to review the logs to make sure of that.

-David


Jacques Le Roux wrote:

> David,
>
> I was asking myself about changing licence to Apache 2 in POS files. Do you want
> that I do this task ? Is there any problem to do so ?
>
> Jacques
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Scott Gray]

I'm only talking about solving the problem of locales that you are obliged
to collect tax for e.g. you wouldn't want to setup a different store for
each EU country just to display the correct taxes while browsing.  

Rather than displaying no tax you could always display your local taxes and
use my suggestion to display alternate taxes if the user wishes to do so.

But anyway that's my last comment because I really have no idea what I'm
talking about!

Regards

Scott

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of David E Jones
Sent: Thursday, 27 April 2006 7:50 p.m.
To: OFBiz Project Development Discussion
Subject: Re: [OFBiz] Dev - Mods to the TaxAuth services to display party's
taxes in prices instead of product store's one


Unfortunately for legal compliance this can be a problem...

The normal approach necessitated by commerce laws (and desire for more
effective localized content, practices and management) is often to have
separate sites for different locales, and in OFBiz that translates into
separate stores. I just don't see a good way around that for global
companies, but of course that is also from my somewhat limited experience...

-David


Scott Gray wrote:
> Hi
>
> I'm no expert on ecommerce but sometimes that can be a good thing if you
> know what I mean...
>
> My preference would be to see no taxes rather than the wrong taxes as I
> might be basing my purchasing decision on what I'm seeing while I browse.

>
> How about showing prices excl taxes by default and possibly having an
> 'include my taxes' link near the price where a user could be shown a
pop-up

> window where they can enter their shipping address or geoid or whatever.
> Perhaps if they are logged in they can select one of their shipping
> addresses.  This is then stored for their session and prices are shown
> including the correct taxes.
>
> Regards
> Scott
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of David E Jones
> Sent: Thursday, 27 April 2006 10:08 a.m.
> To: OFBiz Project Development Discussion
> Subject: Re: [OFBiz] Dev - Mods to the TaxAuth services to display party's
> taxes in prices instead of product store's one
>
>
> Jacopo,
>
> Yeah, there is a difference in these based on the information known when
> they are run.
>
> One way or another there is a potential difference in the tax because of
> information not known until checkout begins. I like the (b) option more

than
> (a) because it is at least an attempt to use information available when
the
> user is logged in, but it doesn't solve the problem as the user could have
> multiple shipping and billing addresses and if a different one is selected
> or entered during checkout that will change the tax terms anyway.
>
> It would be interesting to hear from others, but I don't think the (a)
> option is a good idea because tax may be charged that shouldn't be... But
it
> depends on the tax rules of the local government. If they require a VAT
tax
> regardless of where the product is shipped or billed to, then this would
be
> the case. This could be an option on the TaxAuthority itself so that it is
> configured. That would be more appropriate as the goal for this code is
> legal compliance according to information we know from the customer at the
> time, not really consistency throughout (as unfortunately compliance is
not

> so simple and friendly...).
>
> Thanks for posting that stuff on the wiki, BTW.
>
> -David
>
>
> Jacopo Cappellato wrote:
>> David,
>>
>> ok, I've reviewed the two TaxAuthorityServices responsible for tax
>> calculations:
>>
>> * rateProductTaxCalc
>> * rateProductTaxCalcForDisplay
>>
>> The former is used during checkout, the latter is used to display the
>> tax with the price in the category and product details screens of the
>> ecommerce site (when the ProductStore.showPricesWithVatTax is set to Y).
>>
>> I think that the main problem (but I'm probably missing something) is
>> that the product store's vatTaxAuthGeoId and vatTaxAuthPartyId are only
>> considered by the rateProductTaxCalcForDisplay service and not by the
>> rateProductTaxCalc service: for this reason the taxes shown in the
>> category pages are different by the taxes used in checkout.
>>
>> I'm not sure what was the original design, however I think that there
>> are two possibilities:
>>
>> a) we leave rateProductTaxCalcForDisplay as is (i.e. to only consider
>> the tax authority set in the product store); we patch the
>> rateProductTaxCalc service to not consider the tax authorities
>> associated to the shippingAddress of the client (but only the tax auth
>> of the product store) IF the ProductStore.showPricesWithVatTax is set to

Y

>>
>> b) we modify the rateProductTaxCalcForDisplay to work in the same way
>> the rateProductTaxCalc service works if a party with a shippingAddress
>> is available; if not available (i.e. anonymous user or logged in user
>> with no postalAddress set) the tax auth of the product store is used
>>
>> What do you think of these?
>>
>> Thanks,
>>
>> Jacopo
>>
>>
>>
>>
>> Jacopo Cappellato wrote:
>>> David,
>>>
>>> thanks for the interesting information: I'll think a bit more about all
>>> this stuff and I'll comment on them later on.
>>>
>>> Jacopo
>>>
>>> David E Jones wrote:
>>>> Jacopo,
>>>>
>>>> I haven't reviewed your patches in detail, so this is mostly just a
> response to your comments...
>>>> The changes for #1 should be good. Solving NPE problems is pretty much
> always a good thing.
>>>> For #2 this brings up a difficult question that the current design
> avoids asking by just supporting the concept that different locales would
> have different ProductStores, even if those different ProductStores were
> used to sell the same Products.
>>>> The hard question is when to charge a VAT tax. The rules for charging
> VAT taxes are often different from a sales tax, so the VAT to charge my

not
> have anything to do with where the customer is having the order billed or
> shipped to, but rather where it is coming from. I think this varies in
> different jurisdictions according to their local tax policy. This was
> another the reason for putting it on the ProductStore, that tax would
> generally just be charged for the location of the business behind the
store,
> or of the fulfillment center or what not.
>>>> Even without considering what is in that last paragraph, and perhaps
> some sort of flag on each TaxAuthority record to specify how tax should be
> handled, and it is necessary to collect a VAT tax based on the customer's
> billing or shipping address, another things that should go into your list
of

> things to check is if the "Company" selling the good (ie the one specified
> on the ProductStore) has a "nexus" or sufficient presence in that Geo to
> have a need to collect taxes there (this is already considered for other
> parts of the tax functionality, so using it here would just make it more
> consistent.
>>>> -David
>>>>
>>>  
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacques Le Roux]

Thanks David and Jacopo,

I will take care of this following your explanations

BTW, sorry for the false object of the first mail (bad habit)

Jacques

----- Original Message -----
From: "Jacopo Cappellato" <[hidden email]>
To: "OFBiz Project Development Discussion" <[hidden email]>
Sent: Thursday, April 27, 2006 11:40 AM
Subject: [OFBiz] Dev - Notes about changing licence to Apache 2 in POS files

> Hi Jacques,
>
> first of all, you should issue an "svn log" command in the pos folder to
> get all the commit messages related to the pos component; then, quickly
> review them to see who contributed code; for every person found, go to
> the http://ofbizwiki.go-integral.com/Wiki.jsp?page=OFBizDevelopers page
> and see if that person has signed the iCLA; then you can change the license.
>
> Jacopo
>
>
> Jacques Le Roux wrote:
> > David,
> >
> > I was asking myself about changing licence to Apache 2 in POS files. Do you

want

> > that I do this task ? Is there any problem to do so ?
> >
> > Jacques
> >
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
> >
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Jacques,

As soon as your CLA has cleared changing the pos license should be fine then.

-David


Jacques Le Roux wrote:

> Thanks David and Jacopo,
>
> I will take care of this following your explanations
>
> BTW, sorry for the false object of the first mail (bad habit)
>
> Jacques
>
> ----- Original Message -----
> From: "Jacopo Cappellato" <[hidden email]>
> To: "OFBiz Project Development Discussion" <[hidden email]>
> Sent: Thursday, April 27, 2006 11:40 AM
> Subject: [OFBiz] Dev - Notes about changing licence to Apache 2 in POS files
>
>
>> Hi Jacques,
>>
>> first of all, you should issue an "svn log" command in the pos folder to
>> get all the commit messages related to the pos component; then, quickly
>> review them to see who contributed code; for every person found, go to
>> the http://ofbizwiki.go-integral.com/Wiki.jsp?page=OFBizDevelopers page
>> and see if that person has signed the iCLA; then you can change the license.
>>
>> Jacopo
>>
>>
>> Jacques Le Roux wrote:
>>> David,
>>>
>>> I was asking myself about changing licence to Apache 2 in POS files. Do you
> want
>>> that I do this task ? Is there any problem to do so ?
>>>
>>> Jacques
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacques Le Roux]

>
> Jacques,
>
> As soon as your CLA has cleared changing the pos license should be fine then.
>
> -David

This seems strange again.
At the post I asked to sent the iCLA with an aknowledgment of receipt. I did not
notice but it was only a registered letter. If the 3rd may I have no news, I'll
send it again this time with a real aknowledgment of receipt.

Jacques

>
>
> Jacques Le Roux wrote:
> > Thanks David and Jacopo,
> >
> > I will take care of this following your explanations
> >
> > BTW, sorry for the false object of the first mail (bad habit)
> >
> > Jacques
> >
> > ----- Original Message -----
> > From: "Jacopo Cappellato" <[hidden email]>
> > To: "OFBiz Project Development Discussion" <[hidden email]>
> > Sent: Thursday, April 27, 2006 11:40 AM
> > Subject: [OFBiz] Dev - Notes about changing licence to Apache 2 in POS files
> >
> >
> >> Hi Jacques,
> >>
> >> first of all, you should issue an "svn log" command in the pos folder to
> >> get all the commit messages related to the pos component; then, quickly
> >> review them to see who contributed code; for every person found, go to
> >> the http://ofbizwiki.go-integral.com/Wiki.jsp?page=OFBizDevelopers page
> >> and see if that person has signed the iCLA; then you can change the

license.
> >>
> >> Jacopo
> >>
> >>
> >> Jacques Le Roux wrote:
> >>> David,
> >>>
> >>> I was asking myself about changing licence to Apache 2 in POS files. Do
you

> > want
> >>> that I do this task ? Is there any problem to do so ?
> >>>
> >>> Jacques
> >>>
> >>>
> >>> _______________________________________________
> >>> Dev mailing list
> >>> [hidden email]
> >>> http://lists.ofbiz.org/mailman/listinfo/dev
> >>>
> >>
> >> _______________________________________________
> >> Dev mailing list
> >> [hidden email]
> >> http://lists.ofbiz.org/mailman/listinfo/dev
> >
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Andrew Sykes]

Jacques,

Perhaps David Welton could suggest a strategy for checking up on this?

On Thu, 2006-04-27 at 12:55 +0200, Jacques Le Roux wrote:

> >
> > Jacques,
> >
> > As soon as your CLA has cleared changing the pos license should be fine then.
> >
> > -David
>
> This seems strange again.
> At the post I asked to sent the iCLA with an aknowledgment of receipt. I did not
> notice but it was only a registered letter. If the 3rd may I have no news, I'll
> send it again this time with a real aknowledgment of receipt.
>
> Jacques
>
> >
> >
> > Jacques Le Roux wrote:
> > > Thanks David and Jacopo,
> > >
> > > I will take care of this following your explanations
> > >
> > > BTW, sorry for the false object of the first mail (bad habit)
> > >
> > > Jacques
> > >
> > > ----- Original Message -----
> > > From: "Jacopo Cappellato" <[hidden email]>
> > > To: "OFBiz Project Development Discussion" <[hidden email]>
> > > Sent: Thursday, April 27, 2006 11:40 AM
> > > Subject: [OFBiz] Dev - Notes about changing licence to Apache 2 in POS files
> > >
> > >
> > >> Hi Jacques,
> > >>
> > >> first of all, you should issue an "svn log" command in the pos folder to
> > >> get all the commit messages related to the pos component; then, quickly
> > >> review them to see who contributed code; for every person found, go to
> > >> the http://ofbizwiki.go-integral.com/Wiki.jsp?page=OFBizDevelopers page
> > >> and see if that person has signed the iCLA; then you can change the
> license.
> > >>
> > >> Jacopo
> > >>
> > >>
> > >> Jacques Le Roux wrote:
> > >>> David,
> > >>>
> > >>> I was asking myself about changing licence to Apache 2 in POS files. Do
> you
> > > want
> > >>> that I do this task ? Is there any problem to do so ?
> > >>>
> > >>> Jacques
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Dev mailing list
> > >>> [hidden email]
> > >>> http://lists.ofbiz.org/mailman/listinfo/dev
> > >>>
> > >>
> > >> _______________________________________________
> > >> Dev mailing list
> > >> [hidden email]
> > >> http://lists.ofbiz.org/mailman/listinfo/dev
> > >
> > >
> > > _______________________________________________
> > > Dev mailing list
> > > [hidden email]
> > > http://lists.ofbiz.org/mailman/listinfo/dev
> >
> > _______________________________________________
> > Dev mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev