Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014395Openbravo ERPA. Platformpublic2010-09-01 17:392010-09-17 00:00
Reportervmromanos 
Assigned Tomtaal 
PriorityimmediateSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version2.50MP20 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customerOBPS
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0014395: Strange behaviour updating a dataset
DescriptionDue to the bug 0014034, we have updated the Spanish Taxes dataset with the following modifications:

1. Remove C_TAX_ZONE records associated with 6 taxes
2. Remove the Country and To Country data from the C_Tax table of these 6 taxes
3. Added more Taxes with their new C_TAX_ZONE records.

We have applied this new dataset into a new client and everything works fine, however, if we use this dataset for updating an existing client the point 2 (remove the Country and To Country data from the C_Tax table of these 6 taxes) doesn't work. The old data is still there.
Steps To Reproduce1. Install the Spanish Taxes Module version 1.2.17 from the Central Repository (last stable version)

2. Create a new client and apply the Taxes dataset in the Initial Client Setup

3. Search "Importaciones 16%" tax at Financial Management || Accounting || Setup || Tax Rate. Check Country= USA and To Country=Spain

4. Install the 1.2.18 version from the provided .obx

5. Apply the dataset to the previous client through the Enterprise Module Management (Org *)

6. Search again the "Importaciones 16%" tax at Financial Management || Accounting || Setup || Tax Rate. Check Country= USA and Destination Country=Spain, which is wrong, these two fields should be empty.

7. Create a new client applying the 1.2.18 dataset.

8. Search again the "Importaciones 16%" tax at Financial Management || Accounting || Setup || Tax Rate. Check Country= NULL and Destination Country=NULL, which is OK.
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
blocks defect 0014034 closed psanjuan Localization Pack: Spain  "Import" (Importaciones) related Tax Rates setup as both 0% tax rates and 18/16%-8/7%-4% to be used depending on the needs 
blocks defect 0014456 closed vmromanos Localization Pack: Spain There are some taxes that have no countries defined in the tax zone tab. 
blocks defect 0014453 closed vmromanos Localization Pack: Spain Wrong setup in Spanish Taxes reference data 
Attached Files? org.openbravo.localization.spain.referencedata.taxes-1.2.18.obx (279,277) 2010-09-01 17:39
https://issues.openbravo.com/file_download.php?file_id=3005&type=bug
Issue History
Date ModifiedUsernameFieldChange
2010-09-01 17:39vmromanosNew Issue
2010-09-01 17:39vmromanosAssigned To => alostale
2010-09-01 17:39vmromanosFile Added: org.openbravo.localization.spain.referencedata.taxes-1.2.18.obx
2010-09-01 17:39vmromanosOBNetwork customer => No
2010-09-01 17:40vmromanosRelationship addedblocks 0014034
2010-09-01 17:47rafarodaIssue Monitored: rafaroda
2010-09-02 08:29alostaleStatusnew => scheduled
2010-09-02 08:29alostaleAssigned Toalostale => mtaal
2010-09-02 08:29alostalefix_in_branch => pi
2010-09-02 09:19mtaalNote Added: 0030565
2010-09-02 09:19mtaalStatusscheduled => feedback
2010-09-02 10:22vmromanosNote Added: 0030575
2010-09-02 10:22vmromanosStatusfeedback => new
2010-09-06 08:10alostaleStatusnew => scheduled
2010-09-07 15:58networkbOBNetwork customerNo => Yes
2010-09-07 15:58networkbfix_in_branchpi =>
2010-09-07 15:58networkbIssue Monitored: networkb
2010-09-07 16:29psanjuanRelationship addedblocks 0014456
2010-09-07 16:29psanjuanRelationship addedblocks 0014453
2010-09-09 13:41hgbotCheckin
2010-09-09 13:41hgbotNote Added: 0030897
2010-09-09 13:41hgbotStatusscheduled => resolved
2010-09-09 13:41hgbotResolutionopen => fixed
2010-09-09 13:41hgbotFixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/acf15c4cab5cfe2b47e2201f8b12eb336380da12 [^]
2010-09-10 09:07hudsonbotCheckin
2010-09-10 09:07hudsonbotNote Added: 0030919
2010-09-16 12:36marvintmNote Added: 0031152
2010-09-16 12:36marvintmStatusresolved => closed
2010-09-17 00:00anonymoussf_bug_id0 => 3068051

Notes
(0030565)
mtaal   
2010-09-02 09:19   
The import does normally not remove data. There is one case where data is removed. This is:
- when the data is child data and the parent and child exported together
- the parent is exported as a business object (see the isBusinessObject flag in the dataset_table), so when checking the xml you would see the hierarchical structure of the parent and childs in the xml

Then when such a xml gets imported then any removed child (not present anymore in the xml) should be removed from the database also.

gr. Martin
(0030575)
vmromanos   
2010-09-02 10:22   
Hi Martin,

The problem is not when removing the children data (C_TAX_ZONE). This is working fine using the IsBusinessObject flag.

The problem is that 2 columns of the C_Tax table remember its previous value instead of changing to the new one (NULL)
(0030897)
hgbot   
2010-09-09 13:41   
Repository: erp/devel/pi
Changeset: acf15c4cab5cfe2b47e2201f8b12eb336380da12
Author: Martin Taal <martin.taal <at> openbravo.com>
Date: Thu Sep 09 13:40:34 2010 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/acf15c4cab5cfe2b47e2201f8b12eb336380da12 [^]

Fixes issue 14395: Strange behaviour updating a dataset

---
M src/org/openbravo/dal/xml/XMLEntityConverter.java
---
(0030919)
hudsonbot   
2010-09-10 09:07   
A changeset related to this issue has been promoted to main after passing a series of tests and an OBX has been generated:

Changeset: http://code.openbravo.com/erp/devel/main/rev/acf15c4cab5c [^]
Merge Changeset: http://code.openbravo.com/erp/devel/main/rev/c135d149a438 [^]
Tests: http://builds.openbravo.com/view/int/ [^]
OBX: http://builds.openbravo.com/erp/core/obx/OpenbravoERP-2.50CI.18362.obx [^]
(0031152)
marvintm   
2010-09-16 12:36   
Verified that the change fixed the issue (the countries are null after reapplying the dataset through the Enterprise Module Management)