[14900] Увеличить разрядность номера объекта и номера точки учета

Клиент хочет в номерах размесить кодированную информацию, позволяющею однозначно идентифицировать объекты и точки и при этом быть совместимой с их ERP-системой и биллингом. Что, на мой взгляд, очень логично. Использовать под эти цели атрибуты неудобно, т.к. ЛЭРС не обеспечивает уникальность значений атрибутов, а то тех.процессу предприятия не уникальность кодов может возникать и нужно сразу это пресекать.

Что вы подразумеваете под “увеличить разрядность”? Сейчас там может хранится число от 1 до примерно 2млрд. Какая нужна разрядность? Как должен выглядеть номер точки?

Оказалось я не указал желаемый размер. Прошу прощения.

Сейчас номер - 9 десятичных разрядов. Я прошу - 24

К сожалению, сходу эту задачу решить невозможно. Максимум, что мы можем обеспечить легко и быстро это увеличение разрядности вдвое. То есть, будет максимум 18 цифр. Это техническое ограничение БД. Сейчас у нас 4-байтное число, без больших преобразований мы можем только изменить его на 8-байтное.

Мы продумывали переход к произвольным “номерам”, в которых можно будет указать любую строку. Это сильно упростит работу и пользователям и нам, так как будет гораздо легче генерировать уникальные номера для новых точек учёта.

Но мы сталкиваемся с проблемами с обратной совместимостью, так как номера очень часто используются в различных пользовательских системах интеграции, в задачах импорта/экспорта, и так далее. Задачу мы принимаем, но в виду достаточно высокой сложности версию указать не могу.

Можно использовать втором, дополнительный параметр номера, которым будет управлять пользователь? Со стороны же ЛЭРСа только контроль уникальности значения. Этот параметр будет служить для интеграции в сложных ситуациях. Его наличие не повлияет на обратную совместимость
Описываемый вами путь имеет большой недостаток – он долог. Клиент может не дождаться.

Я бы не хотел добавлять такой параметр, который потом придётся поддерживать. Получится, что вместо проблем с генерацией одного номера мы получим проблемы с генерацией двух, что гораздо хуже.

Пока единственный возможный вариант - использовать атрибут.