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