Upgrading from opentaps 0.8 to opentaps 0.9

opentaps 0.9 is the first complete ERP release of the opentaps suite and includes Financials, CRM, as well as the e-Commerce, Manufacturing, Warehouse, Point Of Sales, and Order Management modules. It brings a significant amount of new features and enhancements and greater stability as well. This document discusses how to upgrade from opentaps 0.8 to 0.9.

General Comments

There are many fewer differences between opentaps 0.8 to 0.9 than there were between ofbiz 3.x and opentaps 0.8, so this would be a much easier upgrade. If you have not made custom modifications to opentaps 0.8, then follow these steps:

1. Download and install opentaps 0.9
2. Change opentaps 0.9's framework/entity/config/entityengine.xml to use the same database as opentaps 0.8
3. Start opentaps 0.9 once with startofbiz.sh or startofbiz.bat so that it can add new tables and columns to your database
4. Run use the upgrade script to change your database. Note that once you run this script, your database will no longer work with the old version of opentaps. If you have any doubts, try it on a backup version first.
5. After it has finished modifying your tables, just do an

$ ant run-install-seed

again to install the new seed data. Then you should be able to run opentaps 0.9 with your existing data. Make sure that you comment out the file PasswordSecurityData.xml in applications/securityext/ofbiz-component.xml before doing an ant run-install-seed.

If you have made custom modifications, you would need to merge versions 0.8 and 0.9 against your internal code base and then manually resolve any conflicts which show up. Note that between versions 0.8 and 0.9, many services and entity definitions were split into different files for better grouping, so this could cause conflicts. Also many old JPublish FTL/BSH/XML files have been replaced with the new screen- and form-widget tools, so make sure you maintain any changes you have made in your custom version with the new application. Finally, the framework/tests/ component has been removed.

Data Model Changes

The upgrade scripts will take care of many of these data model changes for you, but you should be aware of the following:

1. Most important one is tax authorities. SimpleSalesTaxLookup is no longer used. Instead, the new set of TaxAuthority_ entities are used to model sales and usage taxes. This is the only major data model change which the automated scripts do not address. See instructions below.
2. SupplierProduct.availableFromDate is now a primary key field and must be filled in.
3. InventoryItem now have unitCost for tracking inventory value. You must fill these in, either with lot or average inventory values. Also you must now fill in the ownerPartyId and currencyUomId of your inventory items.
4. SurveyResponseAnswer now has an additional field surveyMultiRespColId which needs to be set to a default of "_NA_"
5. InvoiceItemTypeMap now has an additional primary key, invoiceItemTypeId. The existing rows in your database should be changed to have SALES_INVOICE as the invoiceItemTypeId, since the old data model dealt only with sales invoices.
6. ProductPrice entity now has an additional key field of ProductPricePurpose which should be set to "PURCHASE" by default for all your existing products.

API Changes

performFind service which is used on many pages to find information now has a noConditionFind parameter which is automatically turned off. Thus, when you click to a page, you may not see a list of all values by default. To turn it back on, you must set parameters.noConditionFind=”Y”

service-multi requests now have _checkGlobalScope turned on to “Y” by default, so if you have parameters which do not end with _ o _ #, they will be applied to every service call. You can put in a hidden _checkGlobalScope parameter of “N” to fix it.

The SurveyWrapper now returns SurveyQuestionAndAppl rather than SurveyQuestions, so change your survey.ftl templates

Many pages and requests now use "orderId" instead of "order_id", so if you have problems seeing orders, this might be why.

Tax Model

The most significant change from opentaps 0.8 to opentaps 0.9 is the tax model. In opentaps 0.8, sales tax was usually specified in one entity, SimpleSalesTaxLookup, which allowed you to associate productStoreId, countryGeoId, stateProvinceGeoId, taxCategory, and fromDate with tax percentages. In opentaps 0.9, the tax model is around a TaxAuthority with different tax rates, General Ledger accounts, and exemption rules and parties.

Because it is such a large change, it is not possible to transform the old SimpleSalesTaxLookup automatically to the new TaxAuthority-based model. Instead, you would need to re-create your tax settings by following these steps:

1. Set up a new PartyGroup (using Party Manager) for each sales tax collecting authority, such as the California Board of Equalization or the New York State Department of Taxation and Finance.
2. Create a new Tax Authority (using Accounting Manager's Tax Authorities tab) for each tax collecting authority.
3. Set up a TaxAuthorityRateProduct for the sales tax of each product store, their geographic area, and their rate.
4. Configure GL accounts for your tax authorities with TaxAuthorityGlAccount.

For an example, see applications/ecommerce/data/DemoTaxAuthority.xml.

Email Settings

Another significant change from opentaps 0.8 to 0.9 is that email templates are now based on screen-widget screens rather than the old FTL files. There is no simple database change which could fix this. You should go through your ProductStoreEmailSetting's templatePath from opentaps 0.8 and convert those FTL files to screen-widget definitions and point to them with the new screenLocation field in ProductStoreEmailSetting.