При организации обмена данными между 1С:Управление нашей фирмой (УНФ) и 1С:Бухгалтерия предприятия 3.0 (БП) часто возникает критическая проблема: специфические статьи затрат, созданные в УНФ, при выгрузке в БП превращаются в безликие «Прочие затраты». Это происходит из-за фундаментальных различий в архитектуре программ и логике налогового учета. Рассмотрим детально, почему так происходит и какими способами мы можем добиться стопроцентного соответствия данных, которого требуют банки и налоговые органы.
В системе 1С:УНФ (особенно в версиях 1.3–1.6) статьи затрат могут быть реализованы как элементы, имитирующие план счетов. Бухгалтер часто создает их для каждой номенклатурной позиции, чтобы видеть детальную аналитику. Однако в 1С:Бухгалтерия 3.0 справочник СтатьиЗатрат жестко привязан к налоговому учету (НУ). Каждая статья в БП обязана иметь заполненный реквизит ВидРасхода (например, «Оплата труда», «Материальные расходы», «Прочие расходы»).
Проанализируем ситуацию: если при выгрузке система не находит в БП подходящую статью или не может определить её вид расхода для целей налогообложения, она по умолчанию подставляет предопределенный элемент «Прочие затраты». Чтобы этого избежать, нам необходимо настроить механизмы сопоставления.
Если вы используете современный механизм обмена через Enterprise Data, нам не обязательно сразу лезть в программный код. Разберем шаги по ручной настройке связей между объектами:
Этот метод хорош тем, что позволяет «подружить» базы без внесения изменений в конфигурацию, однако при появлении новых статей процедуру придется повторять.
Выясним причину, по которой автоматическое создание статей не срабатывает. Одной из главных проблем является незаполненный Вид расхода (НУ) в источнике. В 1С:Бухгалтерии это поле является обязательным. Если в УНФ создана пользовательская статья, но у нее не указан тип для налогового учета, БП не сможет корректно создать объект.
Проверим заполнение реквизитов в УНФ. Нам необходимо убедиться, что для каждой уникальной статьи затрат выбран соответствующий тип расхода, который понятен 1С:Бухгалтерии. Если мы обеспечим наличие этой информации в выгружаемом XML-пакете (или JSON-сообщении), система БП сможет создать новую статью затрат с правильными параметрами автоматически.
Иногда статьи затрат подменяются не в момент загрузки, а в момент проведения документа в БП. Посмотрим на работу регистра сведений СчетаУчетаНоменклатуры. В 1С:Бухгалтерии для каждой группы номенклатуры или конкретной позиции можно жестко прописать статью затрат по умолчанию.
Если в этом регистре для импортируемой номенклатуры уже указана статья «Прочие расходы», то правила проведения документа могут игнорировать пришедшую из УНФ аналитику. Нам следует очистить или скорректировать эти настройки в БП, чтобы приоритет отдавался данным из документа поступления или списания.
Если стандартные средства не помогают, придется прибегнуть к корректировке правил конвертации объектов (ПКО). Рассмотрим пример логики, которую можно внедрить в ПКО для справочника СтатьиЗатрат. Нам нужно настроить поиск не по внутреннему идентификатору (GUID), а по наименованию или по комбинации «Наименование + Вид расхода».
В обработчике ПоляПоиска мы можем прописать следующий алгоритм:
// Пример настройки поиска статьи затрат по наименованию
Если НомерВариантаПоиска = 1 Тогда
СтрокаПоиска = СвойстваПоиска["Наименование"];
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ Ссылка ИЗ Справочник.СтатьиЗатрат ГДЕ Наименование = &Наименование";
Запрос.УстановитьПараметр("Наименование", СтрокаПоиска);
Результат = Запрос.Выполнить();
Если Не Результат.Пустой() Тогда
Выборка = Результат.Выбрать();
Выборка.Следующий();
СсылкаНаОбъект = Выборка.Ссылка;
КонецЕсли;
КонецЕсли;
После внесения изменений правила необходимо выгрузить в файл и загрузить обратно в узел синхронизации в УНФ. Это обеспечит создание новых статей в БП с тем же именем, что и в УНФ.
Рассмотрим более гибкий подход, который не требует переписывания структуры плана счетов. Мы можем использовать механизм Дополнительных сведений. В УНФ для статьи затрат создается дополнительное сведение, например, «Соответствие для БП». В этом поле бухгалтер пишет точное название статьи, как она заведена в Бухгалтерии.
В правилах обмена (XDTO или XML) прописывается логика: «Если заполнено доп. сведение, искать статью в БП по этому значению, иначе использовать стандартный поиск». Это позволяет избежать хаоса, если названия в двух базах по каким-то причинам должны различаться, но данные должны попадать в одну «корзину».
Если выгрузка уже прошла и бухгалтер в панике видит сотни документов с «Прочими затратами», мы можем воспользоваться обработкой ГрупповоеИзменениеРеквизитов в базе БП. Выясним, как это сделать максимально безопасно:
Важно: это лишь временная мера. При следующей синхронизации данные могут снова перезаписаться на некорректные, если не настроены правила сопоставления, описанные выше.
Для достижения 100% результата при миграции статей затрат из УНФ в БП, мы рекомендуем следующий алгоритм действий:
Во-первых, проанализируйте заполнение поля Вид расхода в статьях УНФ. Без него БП всегда будет «капризничать».
Во-вторых, настройте таблицу сопоставления объектов непосредственно в интерфейсе синхронизации. Это самый быстрый путь, не требующий программирования.
В-третьих, если требуется полная автоматизация для новых объектов, доработайте правила обмена через Конвертацию данных, обращая особое внимание на ПоляПоиска и обработчики ПередВыгрузкой, чтобы передавать правильный ВидРасхода для налогового учета.