Регистры накопления в 1С хороши своей простотой. Но не слишком ли они просты? Разговор о том, что могло бы быть в регистрах 1С, позволит вам лучше понять как устроено 1С:Предприятие. Какие типовые задачи приходится решать разработчикам конфигураций и о каких ограничениях следует знать аналитику.
Неотрицательный остаток
В регистр накопления можно сделать запись со знаком "+" или со знаком "-". Другими словами, приход или расход. Сложив эти плюсы с минусами мы получаем остаток. Функцию получения остатка нам предоставляет платформа. Для того, чтобы извлекать остатки по возможности быстрее, платформа хранит актуальные данные в служебных таблицах. В более ранних версиях в служебных таблицах по умолчанию хранились еще и остатки на каждый месяц. Это было откровенно непродуманное решение и сейчас от него отказались. Остатки по месяцам все еще можно включить по желанию, но лучше этого не делать.
Не будем дальше углубляться в технические подробности. На эту тему и так уже написано достаточно. Нас здесь интересует другое. Такое простое устройство регистра накопления таит в себе одну проблему. Минусы могут "перевесить" плюсы и тогда остаток окажется отрицательным.
Если бы можно было бы каким-то образом подсчитать количество рабочего времени программистов, потраченного на решение тех или иных вопросов, то борьба с отрицательными остатками наверняка заняла бы призовое место. Что интересно, во многих случаях эта борьба лишена смысла, но есть одна ситуация, в которой отрицательные остатки действительно представляют опасность определенного рода. Речь идет о резервировании. Если у вас есть регистр резервов, тогда отрицательный остаток в этом регистре будет увеличивать свободный остаток. Т.е. у вас, к примеру, на складе остаток товара ноль. В регистре резервов минус 100. И это будет означать, что якобы готово к продаже 100 единиц товара, которого нет.
С этим надо что-то делать. Некоторые идут по пути контролируемого проведения документов. Т.е. в момент внесения записей в регистр делается проверка на возникновение отрицательного остатка и далее либо операция запрещается, либо количество корректируется соответствующим образом. Этот путь практически безнадежен, потому что контролировать надо не только добавление и изменение записей регистра, но и удаление, т.е. отмену проведения. Отмена проведения тоже может привести к отрицательному остатку, если отменяется проведение документа, который ранее сделал движение со знаком плюс. Также всегда есть вероятность, что ваш контроль просто не отработает. Запись в регистр будет сделана мимо вашего контроля. Чаще всего такое происходит при обмене данными с другими базами, но не только. Важно помнить, что платформа допускает такого рода поведение.
Поэтому, чаще всего выбирают второй путь. Прекращают бесплодную борьбу с отрицательными остатками. Вместо этого, получив остаток из регистра резерва, применяют нехитрую операцию:
резерв = максимум(0,резерв)В целом это более правильное решение. Но мы все еще вынуждены полагаться на внимательность разработчиков конфигурации. Здесь было бы идеальным, если бы этот самый максимум() взяла на себя платформа. Указав гипотетическую опцию неотрицательный остаток у регистра, мы могли бы быть уверены, что остаток не будет отрицательным ни при каких обстоятельствах.
Распределение
Другой рекордсмен по "поеданию" времени разработчиков - это распределение. Вообще, применительно к учету, стандартную арифметику следовало бы расширить и добавить туда еще одно действие. Все (или почти все) что мы делаем в учете, это приходуем, расходуем и... распределяем. Поэтому, к уже имеющимся в нашем распоряжении операциям сделать приход и сделать расход, я бы добавил операцию распределить. Распределять можно различными способами. Обычно выделяют три: по среднему, FIFO, LIFO.
Можно было бы также дополнить список способов распределения еще одним способом под условным названием просто расход и тогда вернуться к системе из двух операций: приход и распределение, где расход был бы частным случаем распределения.
Мы создаем в регистре записи прихода и расхода и далее уже не заботимся о том, каким образом из них получится остаток. Эту "магию" мы взваливаем на плечи платформы 1С:Предприятие. Просто обращаемся к виртуальной таблице остатков и получаем остаток. Точно так же мы могли бы создавать записи с операцией распределение и быть уверенными, что при обращении к виртуальным таблицам остатков и оборотов, мы получим правильный результат. Где бы и когда бы мы его ни запросили.
Я бы сказал, что именно наличие такой операции в арсенале стандартных инструментов делает продукт по настоящему заточенным под решение учетных задач.
Заключение
Есть нечто, что объединяет две эти, только что рассмотренные темы. Наличие таких инструментов дает нам возможность при разработке конфигураций придерживаться одного важного принципа. Движения документа по регистрам формируются на основании данных документа, но не на основании данных окружения. Т.е. то, что пишет в регистр документ, зависит только от самого документа. Но не от того, какие записи попали в регистр ранее (и не от того, какие попали позднее!) Этот принцип было бы правильным назвать функциональным. Он достаточно широко используется за пределами 1С.
Несоблюдение этого принципа приводит к следующему. Учетная система так или иначе пытается моделировать время. Под видом документов мы регистрируем в системе некие события. Каждое событие располагается где-то на временной оси. Но сам процесс ввода (и тем более последующей корректировки) документов тоже разворачивается во времени! Если не придерживаться функционального принципа при отражении документов в регистры, тогда мы получим эффекты машины времени. Это многократно описано в фантастической литературе. Что будет, если пробраться в прошлое и расстроить свадьбу бабушки и дедушки?
В настоящий момент, как мне кажется, этот принцип не соблюдается ни в одной конфигурации 1С:Предприятие. Поэтому и для разработчика и для аналитика важно помнить об этом, и хорошо представлять себе: какие потенциальные проблемы скрываются в той или иной конфигурации и каким образом разработчики конфигураций пытаются их решать.
В завершение хочу порекомендовать вам бесплатный вебинар, на котором преподаватели OTUS подробно расскажут на что обратить внимание при составлении ТЗ на разработку 1С, как правильно декомпозировать задачи, какие ошибки не совершить чтобы не переделывать ТЗ впоследствии.
