Введение

Информационные системы так устроены, что практически любой ценный объект в системе требует адресации, для того чтобы можно было на него сослаться.

Значит объекту надо присвоить некоторый код или адрес. Этот адрес-код должен быть уникальным и быть жестко закреплён за объектом. Причем, как бы этот объект не менялся сам, адрес его должен оставаться неизменным.

Например: Вы хотите мальчика Васю отправить передать сообщение Петровым, которые живут на вашей улице в доме, покрашенном в зелёный цвет. Хорошо, если мальчик знает Петровых лично, и это именно те Петровы, которых вы имеете в виду. Хорошо, если дом не перекрасили, всякое в жизни бывает. Хорошо, если если зелёный дом на улице один. И так далее. Чтоб избежать таких проблем надо выполнить три простых операции: пронумеровать все дома, занести все номера в тетрадь, передать тетрадь специально обученному человеку.

Есть 4 основных подхода к формированию кодов-идентификаторов в базах данных:

• Счетчик
• UID
• Хэш
• Натуральный ключ

Счетчик – старый прадедовский способ. Как правило поле называют ID. Способ формирования значения понятен и прост. Если новый журнал – начинаешь с единицы. Каждый следующий экземпляр получает номер на единицу больше. Чтобы не связываться с проблемой MAX+1 в каждой системе или СУБД есть какой-то свой раздавальщик счётчиков или механизм (триггеры, сиквенсы, идентити, автоинкрементные поля). В системе SAP ERP этот раздавальщик называется “Диапазоны номеров”.

Одна из договоренностей, которые обычно стараются соблюдать – счетчики являются внутренними номерами конкретной системы и не подлежат выходу за её границ. Например: если у вас для валюты “Евро” присвоен ID = 1, то при передаче в стороннюю будет использован общепринятый коды валюты EUR. Это практичнее, чем выверять справочники двух систем и строить таблицы соответствия.

UID – это уже тенденция нового века. Генерируется длинное случайное число. С ними всё хорошо, пока их не требуется показать на экране, записать, сравнить или передать голосом по телефону. Если вы можете обойтись без всего этого – флаг в руки и вперёд. В системе SAP такие идентификаторы тоже используются, причем такие UID не

Хэш – тоже тенденция нового века. Он может быть очень похож на UID на вид, но есть важное отличие. На одинаковых входных данных хэш даёт одинаковый результат. Возьмём человека: ему можно было бы присвоить хэш на основе ФИО и даты рождения. Значит, вы определяете границы уникальности. Однако ФИО и дата рождения не являются уникальной комбинацией в мировом контексте. Кроме этого необходимо гарантировать неизменяемость данных. Однако, человек может поменять фамилию, в редких случаях даже имя. Поэтому внутри информационных систем хэши практически не используются. Зато хэши можно наблюдать на стыке информационных систем – в системах передачи данных, там как раз обе эти предпосылки работают успешно (уникальность и неизменяемость).

Натуральные ключи – это допрадедовский способ. Цифры, считать, записывать в журнал – это очень сложно. Проще дать объекту какое-то имя, и рассказать его всем и использовать в дальнейшем. Именно поэтому люди, книги, улицы, города, корабли имеют уникальные или почти уникальные имена, а не номера. Но у имён есть свои ограничения, поэтому в системах им всё равно присваивают какие-то коды. Причем эти коды могут быть или чистыми счетчиками или  псеводнатуральными ключами, то есть как бы натуральными, но всё равно там внутри есть маленький счетчик, чтобы гарантировать уникальность. Например: номер автомобиля, ИИН/БИН, РНН/ИНН в себе несет как условно натуральную часть, так и счетчик. И тем не менее можно наблюдать в природе и чистые натуральные ключи, например: логины/емейлы, коды банков SWIFT и другие. В терминологии SAP такие натуральные ключи называются “Внешний номер”.

 

Стандартное использование диапазонов номеров

В системе SAP ERP первыми попавшимися под руку объектами с диапазонами номеров будут: кредиторы, дебиторы, основные средства, материалы, бухгалтерские документы.

Идентификатор каждого этого объекта представлен полем в базе данных с физическим типом CHAR. Почему не INT или не NUMC? Потому что мы не исключаем возможности использовать текстовые идентификаторы.

Допустим, длина кода для нашего объекта 10 знаков. Значит, самым маленьким номером будет 0000000001, а самым большим 9999999999. Тогда общая ёмкость – десять миллионов, если начинать с начала и идти с шагом +1. Но для облегчения восприятия, делёжки на кучки и по другим причинам всю ёмкость можно поделить на интервалы. И каждой особой группе объектов присвоить интервал, в рамках которого будут присваиваться отдельные номера. Если у нас объекты можно разложить на девять групп, то каждой группе можно присвоить диапазон номеров:

• первой – с 1000000000 до 1999999999;
• второй – с 2000000000 до 2999999999;
• и так далее.

 

Для примера, номера автомобилей имеют явные особые признаки: принадлежность к региону, признак собственности ФЛ/ЮЛ, особый признак (обычный, военные, дипломатический).

Если бы автомобильный номер имел бы вид обычного счетчика, то взглянув на номер мы бы не смогли определить без базы данных его главные определяющие свойства. Соответственно:

• свой/чужой (по коду региона);
• хозяин/подневольный;
• осторожное отношение (по цвету);
• крутой номер с лидирующими нулями (по порядковому номеру);

 

Точно такую же роль выполняют диапазоны номеров.

Так кредиторы делятся на резидентов, нерезидентов, физиков, юриков, членов холдинга и прочие особые группы. Так основные средства делятся на землю, здания, оборудование, мебель и другие классы.

Определение нумерации является частью начальной настройки и доступно в соответствующих ветках SPRO:

Сначала нужно определить сами интервалы:

В затем присвоить каждый интервал подвиду объекта. В случае основных средств подвидами являются классы:

По прочим объектам нумерации ситуация практически такая же, с отличиями:

• у основных средств – классы и зависимость от БЕ;
• у кредиторов и дебиторов – группы без всяких зависимостей;
• у бухгалтерских документов – виды документов зависимость от года и БЕ.

 

Ограничения диапазонов номеров

У диапазонов есть два существенных ограничения.

Номер диапазона

Номер диапазона номеров – это две цифры. Только так и не как иначе. При большом желании в Z-диапазонах эта ситуация поправимая, подобъекты решают такие задачи.

Смешанная нумерация

Диапазоны номеров не могут управляться со смешанными номерами, де есть хотя бы одна буква. Стандартный подход допускает только цифры. Только цифры.

Если вам нужны какие-то отступления от стандарта – следует использовать юзер-экзиты. У каждого объекта нумерации могут быть свои пляски вокруг этого. Например: для нумерации закупочных документов (контрактов, заказов) используется расширение CMOD MM06E003 (EXIT_SAPMM06E_001). Пишете свой ABAP-код – и вуаля.