Migration Notes

提供: iDempiere ja

ADempiere 3.6.0からADempiere 3.6.1への移行


Apply migration scripts from the following three folders:

ADempiere 3.6.0からiDempiere 1.0への移行


Apply migration scripts from the following three folders:

NOTE: The folder specified above can vary on every release - the idea is to apply all migration scripts until you arrive to the release you're migrating to.



Constructor account schema parameter have been changed from MAcctSchema[] to MAcctSchema. This can break extensions that modify accounting, solution is simple, just change it to use new method and accomodate code.


The new 2pack format is not backward compatible


The xposition and yposition column now stored the node's position in a grid instead of absolute pixel value.

Change Log設定

The change log is now enabled by default in most of the tables.

Enabling the change log is done with the script 201306261840_EnableChangeLog.sql

If you have already tuned your change log configuration, you can skip that script - or run it and then recover your specific fine tuning changes.

Note also that enabling the change log it will increase the disk consumption - if that's a concern on your installation you must fine tune this configuration after running the script.

Jasper ID parametersの連携 (BigDecimal->Integer)

In some cases the ID parameters (table, table direct, search) were passed to jasper reports as BigDecimal, while in other cases same parameters were passed as Integer (like RECORD_ID or ranges), with IDEMPIERE-1422 that behavior is now consistent, always using Integer for _ID parameters.

This change can break old jasper reports that defined the ID parameter as BigDecimal, the fix is simple, just change the jasper parameter to Integer and compile again.

When this error is reached running the jasper report throws this exception:

16:47:32.058===========> ProcessUtil.startJavaProcess: org.compiere.report.ReportStarter [17]
java.lang.ClassCastException: java.lang.Integer cannot be cast to java.math.BigDecimal
	at net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.setStatementParameter(JRJdbcQueryExecuter.java:553)
	at net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.setStatementParameter(JRJdbcQueryExecuter.java:399)
	at net.sf.jasperreports.engine.query.JRJdbcQueryExecuter$1.visit(JRJdbcQueryExecuter.java:332)
	at net.sf.jasperreports.engine.query.JRAbstractQueryExecuter$QueryParameter.accept(JRAbstractQueryExecuter.java:157)
	at net.sf.jasperreports.engine.query.JRAbstractQueryExecuter.visitQueryParameters(JRAbstractQueryExecuter.java:646)
	at net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.createStatement(JRJdbcQueryExecuter.java:317)
	at net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.createDatasource(JRJdbcQueryExecuter.java:196)
	at net.sf.jasperreports.engine.fill.JRFillDataset.createQueryDatasource(JRFillDataset.java:1087)
	at net.sf.jasperreports.engine.fill.JRFillDataset.initDatasource(JRFillDataset.java:668)
	at net.sf.jasperreports.engine.fill.JRBaseFiller.setParameters(JRBaseFiller.java:1281)
	at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:900)
	at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:845)



Because of IDEMPIERE-675 you need to set manually the inventory document subtype for your inventory documents (internal use and physical inventory).

In case you used the same document type for both cases - then recommendation is to inactivate the old mixed document and create new document types for each specific case.


With IDEMPIERE-362, IDEMPIERE-170, IDEMPIERE-247 some functionalities that were not working properly where deprecated, please check the tickets and commits for details, most prominent are:

  • Cash Journals (all cash functionalities can be modeled using payments)
  • MRP Heavy Manufacturing (Light Manufacturing was integrated)
  • Payroll (being developed as extension)

製造 (Production)

If you used the old Production window (original from Compiere with three tabs) - please note some changes are required as noted in IDEMPIERE-521

ADempiere 3.6.1からiDempiere 1.0への移行


You need to apply the migration scripts like migrating from 360, EXCLUDING those already applied when you migrated from 360 to 361.


Same technical notes from ADempiere 360 apply here.


Same functional notes from ADempiere 360 apply here.

Note about migrating from ADempiere 370

Pb_integratio is sharing and documenting experience about this at Migration from ADempiere 370 to iDempiere

ADempiere 3.6.0よりも旧バージョンからの移行についてのメモ


Migrating some Adempiere installations before 360 to iDempiere generates a problem when using postgresql 9.2 - applying the script 201309192024_IDEMPIERE-1370.sql:222 throws:

ERROR:  cannot change name of input parameter "p_product_id"


An issue has been detected migrating a database pre-360 to iDempiere using postgresql 9.2

The function bomqtyonhand from the database seed doesn't match with the function bomqtyonhand present on the migration scripts (pre-360), the script 201309192024_IDEMPIERE-1370.sql fixes that situation, but postgresql 9.2 doesn't allow changing a parameter name for a function.


  • You can do the migration using postgres 8.4 and at the end migrate to 9.2 (postgres 8.4 allows changing name of function parameters)


  • You can drop the old function bomqtyonhand (and all the associated views) and recreate them properly