Вопрос списания себестоимости при смене учетной политики является одним из самых «подводных» камней на экзамене «1С:Специалист по платформе». Кандидаты часто сталкиваются с дилеммой: нужно ли физически изменять данные в регистре при смене политики или достаточно программной обработки в момент проведения документа. Проанализируем методически верный подход, который ожидают увидеть экзаменаторы, и разберем техническую реализацию этого процесса.
Прежде всего, разберем, как должна храниться сама учетная политика. Для целей экзамена мы используем периодический Регистр сведений УчетнаяПолитика. Периодичность регистра обычно устанавливается «В пределах месяца» или «В пределах дня», в зависимости от условий конкретного билета. Основным ресурсом регистра является перечисление МетодСписания с вариантами ФИФО и ПоСредней.
Рассмотрим важный момент: на экзамене не требуется создавать сложные механизмы пересчета итогов прошлых периодов при изменении записи в этом регистре. Мы исходим из того, что учетная политика меняется с начала нового отчетного периода (года или месяца), и наша задача — обеспечить корректную работу алгоритмов списания «с этой даты и далее».
Многие начинающие разработчики совершают ошибку, пытаясь «очистить» партии в регистре накопления, когда учетная политика меняется на среднюю. Разберем, почему этого делать не стоит. Если мы будем использовать отдельный документ-регламент для очистки партий, мы потратим драгоценное время экзамена и усложним систему. Правильный подход заключается в модификации запроса при получении остатков.
Проанализируем ситуацию: в регистре накопления ОстаткиНоменклатуры есть измерение Партия. При методе ФИФО мы получаем остатки в разрезе каждой партии. При методе По средней нам необходимо игнорировать это измерение. В коде это реализуется следующим образом:
СрезПоследних().Партия в список полей выборки и группировки запроса к виртуальной таблице Остатки.Таким образом, система автоматически просуммирует количество и стоимость по всем имеющимся партиям, выдав единый итог по товару. Это и будет нашей базой для расчета средней цены: СуммаОстаток / КоличествоОстаток.
Рассмотрим обратную ситуацию. Предположим, ранее велся учет «По средней», и в регистре накопления остались записи, где в измерении Партия стоит ПустаяСсылка. Теперь политика сменилась на ФИФО. Как система должна понять, когда списывать этот «старый» товар?
Для экзаменатора идеальным решением считается логика, при которой пустая ссылка рассматривается как самая старая партия. В языке запросов 1С при сортировке по полю ссылки (или по моменту времени документа-партии) пустая ссылка всегда будет находиться в начале списка. Следовательно, при списании по ФИФО система сначала заберет остатки с пустой партией, а затем перейдет к новым поступлениям, где партии уже заполнены.
Разберем по шагам, как организовать универсальный алгоритм в обработке проведения РасходнойНакладной. Посмотрим на структуру запроса и программную логику.
Сначала подготовим управляемые блокировки. Это критично для получения максимального балла. Если политика «По средней», нам нужно заблокировать только Номенклатуру (и склад, если он есть). При ФИФО в идеале блокируется комбинация Номенклатура + Партия, но на практике на экзамене допустимо блокировать всю номенклатуру в обоих случаях, так как это упрощает код и исключает риск коллизий при расчете остатков.
Далее проанализируем пример кода для получения остатков с учетом политики:
// Получаем учетную политику
УчетнаяПолитика = РегистрыСведений.УчетнаяПолитика.СрезПоследних(Дата).МетодСписания;
Запрос = Новый Запрос;
ТекстЗапроса =
"ВЫБРАТЬ
| ОстаткиНоменклатуры.Номенклатура КАК Номенклатура,
| &ПартияПоле КАК Партия,
| СУММА(ОстаткиНоменклатуры.КоличествоОстаток) КАК Количество,
| СУММА(ОстаткиНоменклатуры.СуммаОстаток) КАК Стоимость
|ИЗ
| РегистрНакопления.ОстаткиНоменклатуры.Остатки(&МоментВремени, Номенклатура В (&СписокНоменклатуры)) КАК ОстаткиНоменклатуры
|СГРУППИРОВАТЬ ПО
| ОстаткиНоменклатуры.Номенклатура,
| &ПартияГруппировка";
// Динамически меняем запрос
Если УчетнаяПолитика = Перечисления.МетодыСписания.ПоСредней Тогда
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "&ПартияПоле", "ЗНАЧЕНИЕ(Документ.ПриходнаяНакладная.ПустаяСсылка)");
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "&ПартияГруппировка", ""); // Группировка по партии не нужна
Иначе // ФИФО
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "&ПартияПоле", "ОстаткиНоменклатуры.Партия");
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "&ПартияГруппировка", "ОстаткиНоменклатуры.Партия");
КонецЕсли;
Выясним причину, почему такая конструкция эффективна. Мы используем один и тот же запрос, но для «Средней» мы подменяем реальную партию на пустую ссылку прямо в тексте. В результате группировки мы получаем одну строку на каждую позицию номенклатуры, где в колонке Стоимость будет лежать общая сумма всех партий. Это позволяет нам рассчитать среднюю стоимость без изменения данных в базе.
Рассмотрим подробнее алгоритм обхода выборки. После выполнения запроса мы должны проверить, хватает ли нам общего остатка товара. Это обязательное требование экзамена: проверка на отрицательные остатки выполняется до начала любых расчетов себестоимости.
Если товара достаточно, приступаем к списанию:
(СуммаОстаток / КоличествоОстаток) * КоличествоКВписанию. Важно помнить про округление последней партии (если списываем весь остаток, то списываем и всю сумму под ноль).Партия.МоментВремени ВОЗР. Если в остатках есть пустая партия (наследие «Средней»), она выйдет первой и успешно спишется.Проанализируем еще несколько моментов, которые влияют на оценку:
1. Скользящая средняя vs Средневзвешенная. На экзамене по умолчанию реализуется «скользящая средняя» (расчет в момент проведения). Если в билете явно не указано использование регламентного документа «Закрытие месяца», не усложняйте себе задачу. Реализуйте расчет прямо в РасходнойНакладной.
2. Контроль итогов. Не забывайте, что при списании последней единицы товара необходимо списывать всю оставшуюся стоимость, чтобы избежать «копеек», зависающих на остатках. Это актуально как для ФИФО (внутри каждой партии), так и для «Средней» (по номенклатуре в целом).
3. Избыточность кода. Не пытайтесь писать два абсолютно разных модуля проведения. Постарайтесь максимально унифицировать код, вынося различия в логику формирования запроса или в небольшие ветвления Если...Тогда внутри цикла обхода партий.
Таким образом, корректное решение задачи смены учетной политики заключается не в физической модификации данных, а в гибком программном получении и интерпретации этих данных через запрос к регистру накопления. Использование пустой ссылки в качестве универсального идентификатора для «Средней» политики позволяет бесшовно переходить между режимами учета, что полностью удовлетворяет требованиям сертификации «1С:Специалист по платформе».