This may be regression due to IDEMPIERE-2183. As now period are cached, period.getC_Calendar_ID() try to access closed transaction from period which result in exception at MPeriod line 147.
Thinking there may be use of transaction while first time period created from process, So resetting transaction only when retrieving back from cache.
I followed the instructions you gave me on IRC:
Deepak_: It is reproduced in this way 13:09
Deepak_: 1. After starting system, Run account processor from idempieremonitor 13:10
Deepak_: 2. Then try to repost any of document 13:10
Deepak_: When I tried to post same from idempiere first, then it was working well
Tried with Invoice (Customer) but the issue is not reproducible.
Breakpoint shows that findByCalendar is returning a period with a different trx than the intended - but maybe I'm trying with the wrong document?
Or maybe there is a customization trying to use the period trxName which is stale and must use a different trx?
Carlos there is no customization. Exception come from org.compiere.model.X_C_Period.getC_Year(X_C_Period.java:120).
Which is called from MPeriod.findByCalendar(MPeriod.java:146).
still cannot reproduce it
MPeriod.getC_Calendar_ID never goes to the getC_Year because m_C_Calendar_ID is set.
But even I put a breakpoint and changed m_C_Calendar_ID to zero so forced the getC_Year and the exception was not raised.
My concern is that there can be a bug somewhere else using wrong trx and this patch can hide it.
Still I was not able to reproduce the issue - even forcing the debug session to use a closed transaction.
However, made a bit refactoring to avoid using full MYear object when just a column is required, and also avoid some deprecated messages.