В практике автоматизации на базе 1С часто возникает ситуация, когда учет себестоимости в «1С:Управление торговлей 11» (УТ) и «1С:Бухгалтерия предприятия 3.0» (БП) начинает расходиться. Причины могут быть разными: использование характеристик в УТ, которые отсутствуют в БП, разные моменты проведения документов, использование серий или специфических алгоритмов распределения дополнительных расходов. В таких случаях перед разработчиком встает задача: как «заставить» бухгалтерскую базу принять ту себестоимость, которая уже была рассчитана в торговой системе. Разберем подробно, как реализовать этот механизм, избежав стандартных ошибок и затирания данных при закрытии месяца.
Рассмотрим стандартный механизм синхронизации через EnterpriseData. По умолчанию он передает только количественные данные и суммы выручки. Логика фирмы «1С» заключается в том, что бухгалтерия — это самодостаточная система, которая должна самостоятельно рассчитать себестоимость по своим правилам (ФИФО или «По средней») на основании имеющихся остатков и партий. Однако, если требования бизнеса (особенно иностранных собственников или жестких стандартов отчетности) диктуют необходимость идентичности цифр, нам придется вмешаться в работу механизмов проведения документов БП.
Проанализируем структуру документов в БП 3.0, таких как РеализацияТоваровУслуг. На уровне метаданных в конфигураторе мы можем обнаружить, что в табличной части Товары присутствует реквизит СуммаСписания. В обычном пользовательском интерфейсе это поле скрыто и не заполняется, так как программа рассчитывает его автоматически при проведении документа.
Если мы программно запишем в это поле сумму себестоимости из УТ, то при проведении документа программа возьмет именно это значение для формирования проводки по дебету счета 90.02.1 и кредиту счета 41 (или 43, 10). Рассмотрим, как это работает по шагам:
Товары сопоставляем номенклатуру с данными из УТ.СуммаСписания.Важный нюанс: Если просто записать сумму, первое же перепроведение документа пользователем или регламентной операцией «Закрытие месяца» уничтожит ваши данные. Система увидит, что нужно рассчитать себестоимость заново, и перезапишет проводки.
Чтобы защитить перенесенную себестоимость от автоматического пересчета, необходимо использовать механизм ручной правки проводок. Разберем, как это реализовать программно. В каждом документе БП есть реквизит РучнаяКорректировка. Если установить его в значение Истина, алгоритмы проведения перестают изменять движения документа.
Однако полная ручная корректировка — это «палка о двух концах», так как она блокирует обновление вообще всех движений. Более элегантный способ — заполнение СуммаСписания и понимание того, что при включенном флаге ручной корректировки система сохранит ваши цифры в проводках. Посмотрим на пример кода, который может быть использован в обработке загрузки данных:
// Пример заполнения себестоимости в документе Реализация
Для Каждого СтрокаТЧ Из ДокументОбъект.Товары Цикл
// Предположим, СебестоимостьИзУТ получена из внешней структуры
СтрокаТЧ.СуммаСписания = СебестоимостьИзУТ;
КонецЦикла;
// Включаем ручную корректировку, чтобы зафиксировать движения
ДокументОбъект.РучнаяКорректировка = Истина;
ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
Выясним причину, по которой ГБ может возражать против такого подхода: при ручной корректировке документ перестает реагировать на изменения в первичных данных (например, если изменится цена в поступлении, себестоимость в реализации сама не обновится).
Если в учетной политике БП установлен метод ФИФО, то для корректного списания недостаточно просто указать сумму. Программа должна понимать, с какого именно документа поступления (партии) списывается товар. Если в УТ и БП партии не совпадают, возникнет ситуация, когда количественные остатки по конкретной партии уйдут в минус, а по другой останутся висеть.
Для решения этой проблемы при переносе данных из УТ необходимо транслировать и информацию о партиях. Рассмотрим последовательность действий:
ВыручкаИСебестоимостьПродаж, где указан документ партии.ДокументПартии (если оно доступно в данной конфигурации/настройке).Если этого не сделать, при списании последней единицы товара на счете 41 могут оставаться «копеечные» хвосты или, наоборот, отрицательные стоимостные остатки при нулевом количестве.
В некоторых случаях, когда разрыв между базами слишком велик, рекомендуется рассмотреть радикальный метод — ведение на 41 счете в БП только суммового учета. Выясним, как это реализовать:
Операция (бухгалтерский учет).Этот метод полностью исключает расхождения, так как БП перестает самостоятельно считать себестоимость «штук», а просто принимает итоговую цифру из УТ. Однако это лишает бухгалтера возможности видеть остатки в единицах измерения непосредственно в БП.
Проанализируем наиболее безболезненный путь реализации. Вместо того чтобы ломать типовую синхронизацию, лучше создать отдельную регламентную обработку, которая будет работать по следующему алгоритму:
COM-соединение или HTTP-сервис.РеализацияТоваровУслуг, ОтчетОРозничныхПродажах, ТребованиеНакладная.СуммаСписания и устанавливает РучнаяКорректировка = Истина.Важно помнить: Прямой перенос себестоимости — это всегда ответственность главного бухгалтера. Перед внедрением необходимо убедиться, что ГБ понимает последствия ручной корректировки и готов к тому, что стандартные отчеты по себестоимости в БП будут показывать данные, «навязанные» извне, а не рассчитанные по внутренним алгоритмам программы.