Это статья про прописные истины, которые, как показывает опыт, иногда полезно повторять самому себе или делиться ими с другими.
Если открыть описание ошибок при сдаче экзамена на сертификат «Специалист 1С», за которые начисляются штрафные баллы, то можно прочитать следующее: "Получение расчетных данных не из регистра" - 3 штрафных балла. Однако в своей практике мне часто встречаются люди,которые вроде бы имеют большой стаж программирования, продолжают делать отчет по движению товаров, создавая запрос по документам, и удивляются, когда имговорят, что это не совсем правильно, приводя в ответ универсальную фразу, по которой сразу можно вычислить неквалифицированного программиста: «Но ведь это же работает, чего еще надо?».
На эту фразу у меня всегда есть ответ, что сейчас не последнее десятилетие прошлого века, а уже второе нынешнего, и программировать, ориентируясь только на то «чтобы работало», уже давно является признаком непрофессионализма. Программировать необходимо так, чтобы было правильно. А в условиях, когда только 20% процентов времени работы программиста уходит на написание нового кода, а оставшиеся 80% - на поддержание и модернизацию старого, «правильно» - означает гибко, чисто, прозрачно, доходчиво и максимально доступно для внесения изменений.
Так почему необходимо отчеты делать из регистров? Если вдруг на собеседовании вам зададут этот вопрос, то можно привести как минимум три ответа. Кстати, к вопросу, почему я написал эту коротенькую статью: на собеседованиях, которые я провожу, на этот вопрос правильный ответ дают от силы процентов десять кандидатов.
Итак, ответ первый: Многослойность и многоуровневость. Это принцип, который, наверное, известен любому, кто знаком со словосочетанием «паттерны программирования»: разделение на слои позволяет вносить необходимые изменения в слой, не затрагивая другие слои. Рассмотрим простейшую схему – документ розничной продажи, регистр, учитывающий эти продажи, и отчет по продажам. Предположим, что в организации решили торговать еще и по интернету, и операцию продажи фиксировать не стандартным документом, а новым, учитывающим специфику данного вида продаж. Если бы отчет по продажам брал информацию из документов, то и его бы необходимо было переделать для учета нового документа. Если же отчет делается из данных регистра, то нам достаточно корректно оформить движения нового документа по регистру – отчету «все равно», кто заполняет регистр. Эта схема очень простая, но представьте себе, что в компании не один, а пятнадцать отчетов – для каждого подразделения свой. Ладно бы просто будет потрачено время на переделку всех этих пятнадцати отчетов, так по известному закону подлости, будет еще шестнадцатый, о котором вспомнишь только после того, как генеральный директор месяц получал информацию по продажам без учета интернет-торговли.
Относительно приведенной ситуации стоит еще раз упомянуть о особой важности изначально правильной архитектуры регистров учета – в учетной системе это должна быть самая «консервативная» и самая обдумываемая на этапе проектирования часть.
Ответ второй: Эффективность. В этом аспекте все очень просто – считывая в запросе данные документа, пользователь почти всегда «тащит» в запрос лишние данные из документа, тогда как при запросе по регистру, из базы делается выборка только по требуемой информации.
Ответ третий: Безопасность и вопросы доступа. Бывает ситуация, когда в документе содержится информация, закрытая для доступа пользователю. Однако, итоговые данные по документам пользователю необходимы. Выход из ситуации – документ заполняет регистр, на который пользователю даются права на чтение. Здесь опять работает принцип многослойности и многоуровневости.
Ответ четвертый: Возможность заполнения регистра расчетными данными. В данном случае трехслойная схема документ-регистр-отчет просто незаменима. Иногда возникает необходимость хранить информацию, которая может быть получена только расчетным путем на момент проведения документа. Если бы отчет по данной информации делался из документа, то было бы необходимо или вызывать внешнюю процедуру расчета из документа при генерации отчета, или, что еще ужаснее, дублировать эту процедуру в отчете – модернизация процедуры расчета в таком случае весьма трудоемка и чревата ошибками.
Обещал три ответа, получилось четыре. Хотя, по правде говоря, ответов может быть еще больше – каждый может придумать на свой вкус.
Возникает вопрос – а бывают ли исключения? Конечно, бывают. Самый простой вариант исключения – когда просто отсутствует регистр учета. Или данные необходимы в тот момент, пока документ еще не проведен. Хотя, последний вариант, который недавно встретился в моей практике, был успешно решен введением дополнительного регистра учета, в который скидывалась необходимая информация от непроведенного документа и удалялась при его проведении. Через некоторое время, оказалось, что этот временный регистр с успехом можно применить еще в паре разделов учета, упростив его ведение. Это, на мой взгляд, один из признаков удачных и правильных решений – будучи придуманными для решения одних задач, они вдруг помогают и в решении других.
