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

В этот раз я хотел рассказать о проблеме, устранение которой на поздних этапах проектирования финансовой системы будет наиболее дорогостоящим и трудозатратным.

Рассмотрим пример.
Допустим имеется несколько таблиц в базе данных вашей системы. Одна из них — справочник юридических лиц. Вам как разработчику/аналитику необходимо спроектировать функционал для работы с некоторым типом документов. Для примера предположим что вам необходимо разработать функционал для создания и редактирования платежных поручений. Допустим 1 платежное поручение должно иметь следующие поля:

1. уникальный номер
2. дата и время создания
3. дата и время оплаты
4. юридическое лицо (контрагент) которому была произведена оплата
5. сумма
6. тип платежа

Сразу отмечу что почти никогда не стоит связывать уникальный номер документа с id записи в таблице БД. Дело тут вот в чем: пользователи имеют свойство ошибаться. Логика пользователей иногда весьма своеобразна, к примеру, периодически им легче удалить неправильно созданный документ и создать его по новой (особенно это касается новых сотрудников, которые боятся “накосячить”). После подобных действий у вас в системе будет множество пустых “дыр” между номерами документов. Казалось бы мелочь, но любая проверка со стороны “заинтересованных” лиц найдет в этом тайный умысел. (Если хотите реальных примеров, погуглите “Прайм-ТАСС подало в суд на мэрию Москвы”. Вся их доказательная база — номера документов шли по порядку, но в общественном доступе есть только часть из них). Лучше всего, по нашему мнению, вновь создаваемому документу присваивать номер = максимальный уникальный номер в системе по данному типу документов + 1.
Но вернемся к нашему примеру. Обратим внимание на поле №4 — юридическое лицо. Коль скоро у нас имеется справочник юридических лиц, то очевидным является записывать в это поле ссылку на запись в этом справочнике.
А теперь представим себе несколько возможных ситуаций:
1) Платежное поручение было создано в 2009 году. Платеж был произведен ООО “Кровать”. В январе 2010 фирма была переименована в ООО “Стулья”. Получается что если мы откроем форму платежного поручения в конце 2010 года, то увидим что платеж был произведен фирме, которой в 2009 году физически не существовало.
2) Допустим в марте 2010 года произошло слияние ООО “Кровать” и ЗАО “Диваны”, результатом стало ОАО “Диваны и кровати”. Что могут сделать пользователи? А они могут переименовать фирму ООО “Кровать” в ОАО “Диваны и кровати”, а еще они могут переименовать ЗАО “Диваны” в “Диваныи кровати”. Самое интересное начнется при первом же отчете, когда окажется что все платежи между разным юридическим лицами (3мя фактическими и 4мя в базе) перемешались и отличить их могут только люди, которые производили оплату (которые, к сожалению, попали под сокращение штата и уже несколько месяцев не работают в вашей фирме).

По моему скромному опыту, у нас в стране нет разделения на разработчиков программного обеспечения и разработчиков финансовых систем. Самое бОльшее что я встречал на собеседованиях — вопрос имел ли я дело с информационными системами, которые работают под высокими нагрузками (Первый канал, Яндекс и т.д.). В остальном всегда интересуются лишь знанием определенных информационных технологий. По моему же мнению, разработка информационных систем — это целая культура разработки и проектирования архитектуры. При этом на первом месте всегда должна стоять архитектура: ее сбалансированность, гибкость, безопасность и продуманность насчет будущего развития системы (в том числе и возможная интеграция со сторонними системами, у которых не будет той гибкости, той продуманности и той заточенности под бизнес-процесс).

Пример различий построение обычных систем, которые ориентируются на текущую информацию, и финансовых систем.

Создается система финансового учета и аудита. Система, что называется, все в одном. Система разрабатывается, принимается заказчиком, развивается и дорабатывается. Через пару лет заказчик придумывает разделить весь бизнес процесс на две обособленные составляющие, а именно: финансовая служба делится на две части: финансовую и бухгалтерию. Под это дело планируется разделение систем: заказчик хочет чтобы старая система осталась, но некоторый функционал (связанный с бухгалтерской деятельностью) полностью проходил в 1С-Бухгалтерии. И тут сразу же встает вопрос интеграции двух систем. 1С-Бухгалтерия — замечательная финансовая система, вернее даже не 1С-Бухгалтерия, а весь фреймворк. Я даже не буду говорить про существенные проблемы 1С: часть встроенного функционала настолько “вшита” что изменить ее без последствий в будущем не получится; очень сложно интегрировать хоть один справочник из внешней базы. Скажу только что “на лету” подгружать в нее все изменения из основной системы — довольно нетривиальная задача. Но вернемся к нашей системе и зададимся вот каким вопросом: коль скоро у нас теперь не одна система, а целых две (три, четыре, пять,..) то что делать с сущностями, которые становятся общими для этих систем. Мы даже можем опустить те сущности создание, редактирование и удаление которых разрешено только в одной из систем (тут бизнес процесс можно расписать даже на уровне баз данных). А вот что делать, скажем, с общими для обеих систем справочниками? Ведь пользователи — это такие люди, которых хлебом не корми — дай только задвоить какую-нибудь информацию. Результаты этого могут быть если не катастрофическими, то отберут довольно много человеко-часов, которые потребуются на решение этих, казалось бы, маленьких проблем. А еще окажется что выяснилось это в конце декабря, когда начали собирать отчетность за год, а данные, скажем, по договорам расползаются. Пользователи же, отвечающие за эти данные, конечно же не помнят по какой причине несколько месяцев назад они сделали именно то что сделали. Логика product owner’а обычно сводится к тому что “это проблема системы, вы за нее отвечаете — вы и решайте проблему”, забывая что проблема может быть не столько в системе, сколько в данных. Всего бы этого не случилось при одном условии — архитектура системы и регламент взаимодействия были бы продуманы с самого начала.