BiTel

Собственно вопрос - что это за ошибка и как исправлять?
Валится их много в логи Access и Accounting слушателей.

accounting 10-08/14:20:49 ERROR [inetServ-load-p-13-t-2] InetServRuntimeMap - Parameter index out of range (11 > number of parameters, which is 10).
java.sql.SQLException: Parameter index out of range (11 > number of parameters, which is 10).
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:982)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927)
at com.mysql.jdbc.PreparedStatement.checkBounds(PreparedStatement.java:3729)
at com.mysql.jdbc.PreparedStatement.setInternal(PreparedStatement.java:3713)
at com.mysql.jdbc.PreparedStatement.setInternal(PreparedStatement.java:3755)
at com.mysql.jdbc.PreparedStatement.setInt(PreparedStatement.java:3699)
at org.apache.commons.dbcp.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:120)
at bitel.billing.server.contract.bean.ContractStatusManager.getStatusList(ContractStatusManager.java:775)
at ru.bitel.bgbilling.modules.inet.runtime.InetServRuntimeMap.newRuntime(InetServRuntimeMap.java:434)
at ru.bitel.bgbilling.modules.inet.runtime.InetServRuntimeMap.load(InetServRuntimeMap.java:355)
at ru.bitel.bgbilling.modules.inet.runtime.InetServRuntimeMap.access$0(InetServRuntimeMap.java:329)
at ru.bitel.bgbilling.modules.inet.runtime.InetServRuntimeMap$2.runImpl(InetServRuntimeMap.java:298)
at ru.bitel.common.worker.WorkerTask.run(WorkerTask.java:86)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:40)

кажется разобрался... не знаю фича это или баг, но в настройке
contract.status.suspend.codes=1,2,3,4,5,6,7,10,11
НЕ может быть более 10 статусов или всё перестаёт работать.

Выложили обновление для >=6.2.
А для чего так много приостановленных статусов, какие они?

Спасибо!
Статусов много, так как в процессе общения техподдержки, call-центра, техников в поле все пытаются ориентироваться в причинах отключения абонентов на поле статуса, не запоминая как выявить причины, которые могут вызвать выключение абонента(типа отключен за долги без включения автоматом по приходу денег, кандидат на закрытие/списание, отключена часть услуг, есть комбинация 2х статусов, дающая перенос последнего начисления на последующий месяц без новых начислений, т.е. если абонент ушёл в минус - тащим этот минус в новый месяц и это не у всех абонентов, а в привязке к тарифам и группам; абонент запланирован на физическое отключение в brcrm и т.д.).

Вероятно есть и документрованные способы реализовать это меньшим числом статусов, но у нас так сложилось - смотришь на статус - знаешь что случилось с абонентом.

Поэтому проще наплодить статусов и управлять ими ещё скриптами дополнительно onEvent или из bgcrm и выводить абонентов в них, чем объяснять подробную структуру всей карточки техникам и коллцентрам.

Текущее ограничение по кол-ву приостановленных статусов - 20.