Разберем достаточно распространенную ситуацию, с которой сталкиваются пользователи и специалисты при интеграции программных продуктов. Представим, что расчет заработной платы ведется во внешней программе, например, в 1С:ЗУП, а финансовый и бухгалтерский учет — в 1С:ERP. При заполнении документа Отражение зарплаты в финансовом учете вручную или при типовом переносе данных вы можете заметить, что по счету 70 не заполняется субконто Работники организации, даже если в табличной части указаны конкретные сотрудники.
Давайте подробно проанализируем, почему система ведет себя таким образом, какие скрытые механизмы здесь задействованы, и почему попытки решить проблему «в лоб» приводят к поломке других подсистем.
В настройках учетной политики организации (в разделе «Зарплата») может быть установлена галочка, предписывающая вести учет расходов на оплату труда по счету 70 с детализацией по работникам организации. Казалось бы, этого должно быть достаточно. Однако, если документ Отражение зарплаты в финансовом учете заполняется вручную в обход типовых алгоритмов обмена, система не подхватывает эту аналитику для проводок.
Выясним причину такого поведения. Документ отражения содержит множество скрытых табличных частей и реквизитов. Он изначально не предназначен для полностью ручного ввода в сложных сценариях. Архитектура 1С:ERP предполагает, что если зарплата считается в сторонней программе (ЗУП), то данные переносятся сводно. Это сделано намеренно: перенос детальных кадровых данных и начислений по каждому физическому лицу сильно перегрузил бы базу ERP дублирующей информацией. Поэтому разделение проводок по отдельным физическим лицам на 70 счете при внешней интеграции по умолчанию отключено на программном уровне.
В попытках заставить программу видеть сотрудников в проводках, специалисты иногда находят скрытую константу ИспользоватьНачислениеЗарплаты и устанавливают ее в значение Истина. Рассмотрим, к чему это приводит.
Сначала кажется, что проблема решена, однако при попытке провести документ Списание безналичных денежных средств возникает критическая ошибка: «Команда не может быть выполнена для указанного объекта».
Посмотрим на ситуацию изнутри:
ВедомостьВБанк, ВедомостьНаСчета, а также привязанных лицевых счетов сотрудников.Если требования вашей учетной политики жестко диктуют необходимость детализации 70 счета по каждому сотруднику именно в базе ERP (а не только в ЗУП), нам придется обойти ограничения типового функционала. Рассмотрим два основных и наиболее безопасных метода решения этой задачи.
Мы не будем ломать внутреннюю логику ERP включением ненужных констант. Вместо этого мы модифицируем правила обмена между 1С:ЗУП и 1С:ERP.
Программисту необходимо вмешаться в правила конвертации так, чтобы при выгрузке документа ОтражениеЗарплатыВБухучете (из ЗУП) в документ ОтражениеЗарплатыВФинансовомУчете (в ERP) принудительно переносилась детализация по физическим лицам в табличные части. Для этого потребуется:
ФизическоеЛицо или Сотрудник передавалось в соответствующие скрытые поля документа приемника.Если изменять правила обмена нецелесообразно (например, при использовании EnterpriseData, где вмешательство сложнее), мы можем использовать механизм расширений непосредственно в ERP. Разберем этот вариант по шагам.
ОтражениеЗарплатыВФинансовомУчете (например, процедуру ОбработкаПроведения или модули формирования проводок).Таким образом, мы оставляем константу ИспользоватьНачислениеЗарплаты в значении Ложь, сохраняя работоспособность казначейства, но при этом добиваемся нужного бухгалтерского результата на 70 счете. Помните, что любые ручные правки в сложных документах ERP без понимания их связи с подсистемами могут привести к скрытым ошибкам учета, поэтому всегда используйте расширения или доработку обмена вместо включения неиспользуемых подсистем.