Проанализируем ситуацию: вы перешли на 1С:Предприятие 8.3 и 1С:Бухгалтерию предприятия 3.0, ввели начальные остатки по зарплате на 31.12.2024, затем загрузили банковскую выписку с платежными поручениями на выплату зарплаты за декабрь. При проведении платежных поручений программа ругается, что в выбранной ведомости «отсутствуют сведения о заработной плате сотрудника». Разберем, почему так происходит именно в 1С:Бухгалтерии 3.0, как диагностировать причину (поможет расширенная проверка учета на ошибки и риски) и какие есть рабочие способы исправления, чтобы документы начали проводиться.
Ключевая идея: в 1С:Бухгалтерии 3.0 «зарплатные» платежи по ведомостям проводятся не просто по суммам на счете 70, а по «зарплатным данным» в самой ведомости и в связанных регистрах. Если остатки введены «бухгалтерски» (только долг по счетам), но «зарплатные» регистры/документы не содержат нужных строк по сотрудникам, то ведомость формально существует, но для конкретного сотрудника в ней нет «сведений о зарплате» — и платежка не проводится.
Сначала разберем логику проверки, из-за которой появляется сообщение об ошибке. Когда в документе ПлатежноеПоручениеИсходящее (или в документе списания/выписки, который создается при загрузке из банка) вы выбираете ведомость, программа ожидает, что:
ВедомостьВБанк или аналогичный документ подсистемы зарплаты) есть табличные строки по сотрудникам с суммами к выплате.Если хотя бы один пункт нарушен, 1С воспринимает ситуацию так: «ведомость выбрана, но по этому сотруднику в ведомости зарплата не числится», и блокирует проведение. На практике чаще всего причина — не в самом платежном поручении, а в том, что ведомость либо заполнена «не тем способом», либо не содержит «зарплатных остатков» после миграции, либо сотрудник «не тот» (задвоился/создался новый при загрузке банка).
Это самая распространенная причина при переходе на новую базу. Вы ввели задолженность по сотрудникам на 31.12.2024 через помощник ввода остатков, но ввели ее в части бухучета так, что в «зарплатных документах/регистрах» фактически нет того, что нужно ведомости.
В 1С:Бухгалтерии 3.0 есть важное разделение:
Если в базе есть только бухостаток, но нет «зарплаты к выплате» в зарплатном контуре, ведомость либо не заполняется автоматически, либо заполняется не так, как ожидает механизм проведения банковского документа. В итоге вы видите долг, но платеж по ведомости не проходит.
Проверим это по шагам:
Откройте ведомость (например, ВедомостьВБанк), которую вы выбираете в платежке.
Посмотрим табличную часть: есть ли строки по сотрудникам? Есть ли суммы? Совпадает ли сотрудник/физлицо с тем, что указано в платежном документе?
Если ведомость пустая или там нет нужного сотрудника — это прямое подтверждение причины: в ведомости нет «сведений о зарплате сотрудника».
Дальше проверим, видит ли программа вообще задолженность в зарплатном учете: сформируйте отчет по зарплате (например, анализ задолженности/выплаты по сотрудникам) и сравните с тем, что вы ожидали увидеть на 31.12.2024.
Если отчеты зарплатного блока показывают нули или не совпадают с введенными остатками — значит, остатки «не дошли» до зарплатного контура, и ведомость не может корректно связать выплату с сотрудником. Этот сценарий типичен при переносе и вводе остатков «только проводками» или в неправильном разделе помощника.
Разберем по шагам, как правильно привести базу в состояние, когда ведомость станет «настоящей», а платежки начнут проводиться.
Найдите, каким способом вы вводили зарплатные остатки. Важно, чтобы ввод начальных остатков был выполнен именно по расчетам с сотрудниками (а не только по счету 70 в общей части). В 1С:Бухгалтерии 3.0 для зарплаты обычно используется ввод остатков/задолженности в разделе «Зарплата и кадры» с детализацией по сотрудникам.
Если остатки введены неверно — исправьте их: корректнее всего откорректировать документы ввода остатков (или удалить некорректные документы ввода остатков по зарплате и ввести заново правильным способом). Смысл: программа должна «увидеть», что конкретному сотруднику на дату перехода должна быть выплачена конкретная сумма.
После корректного ввода остатков создайте новую ведомость: в «Зарплата и кадры» создайте ведомость нужного вида (банк/касса/лицевые счета/зарплатный проект) и нажмите «Заполнить», чтобы программа подтянула остатки. После этого проведите ведомость.
Только затем связывайте платежку с ведомостью: либо сформируйте платежные документы из ведомости штатной кнопкой «Выплатить/Создать платежные документы» (если используете такой сценарий), либо в загруженных из банка документах выберите уже корректную ведомость.
Почему важно «пересоздать» ведомость? Потому что старая ведомость могла быть создана/заполнена до корректного ввода зарплатных остатков и поэтому не содержит нужных строк, а платежка проверяет именно содержание ведомости на момент проведения.
Похожая логика встречается и в практических разборах: проблема часто решается именно приведением «сотрудников и данных ведомости» к корректному состоянию перед проведением банковского документа.
Теперь рассмотрим второй типовой источник ошибки — несоответствие «режима выплаты» между ведомостью и платежным документом.
В 1С:Бухгалтерии 3.0 обычно различают как минимум два практических сценария выплаты через банк:
Ошибка может проявляться так: ведомость создана «на личные счета», а загруженная из банка операция пытается провести выплату «в рамках зарплатного проекта», либо наоборот. Тогда система не находит соответствующих строк для конкретного «получателя» — и пишет, что в ведомости нет сведений по сотруднику.
Практическая подсказка: если при загрузке выписки 1С создала документ с видом операции «Перечисление заработной платы по ведомостям», но ведомость у вас «не проектная», сопоставление может не сработать. В отдельных случаях помогает прямо привести вид места выплаты к нужному значению и затем повторить проведение.
Разберем по шагам, как действовать без «угадываний».
Определите, как реально платили в банке. Если это реестр по зарплатному проекту — работаем в режиме «зарплатный проект». Если это отдельные платежи по реквизитам сотрудников — режим «личные счета».
Проверьте ведомость: в ведомости должна быть выбрана корректная настройка выплаты (в рамках проекта или на счета). Если ведомость создана «не тем видом», проще создать новую ведомость правильного вида и заполнить ее заново.
Проверьте банковский документ: в документе, который не проводится, проверьте вид операции (как минимум, чтобы он соответствовал «зарплатной» операции, а не, например, «прочее списание») и чтобы реквизит «Ведомость» был заполнен ведомостью нужного типа.
Если загружено много документов и везде ошибка: вместо ручной правки каждого документа используйте групповое изменение реквизитов («Изменение выделенных элементов») для приведения «вида места выплаты/операции» к правильному значению, а затем перепроведите документы.
Важно: не пытайтесь «подогнать» ведомость под платежку, если ведомость не отражает реальный сценарий выплаты. Правильнее сделать наоборот: сначала корректно отражаем реальный сценарий выплаты (правильная ведомость), затем корректно привязываем банковские документы.
Это частая проблема в переходных периодах: в базе появляются «два одинаковых» сотрудника или два физлица — поможет обработка поиска и устранения дублей сотрудников. Один используется в зарплатных документах и ведомости, а другой — неожиданно создается при загрузке банковской выписки (например, по ФИО/назначению платежа банк дал данные так, что 1С создала новый элемент справочника).
Симптом выглядит так:
Такие случаи описывают как «сдвоенность сотрудников» или «не совпало ФИО из банка с тем, что в базе». Практическое решение — привести элементы справочников к соответствию, убрать дубли, перепривязать документы к «правильному» сотруднику/физлицу.
Разберем по шагам, как действовать аккуратно, чтобы не сломать учет.
Сопоставьте сотрудника в ведомости и получателя в платежке. Откройте ведомость, найдите строку по сотруднику и посмотрите, какой элемент справочника «Сотрудники»/«Физические лица» используется. Затем откройте платежный документ и посмотрите, кого он считает получателем (часто это тоже сотрудник/физлицо/контрагент — зависит от настройки).
Если элементы разные — ищем дубль. Обычно у дублей совпадают ФИО и дата рождения (у физлица), но отличаются, например, реквизиты, формат имени, наличие пробелов/инициалов, разные банковские счета.
Выбираем «основной» элемент. Как правило, основным делаем того сотрудника/физлицо, который уже участвует в зарплатных документах (начисления, ведомости, отчеты).
Перепривяжите документы к основному элементу. Тут есть два распространенных подхода:
После перепривязки перепроведите ведомость и банковские документы. Важно именно перепровести, чтобы контрольные проверки и движения по регистрам пересчитались.
Практический ориентир: если после исправления «дублей» платежи начинают проводиться без изменения ведомостей — значит, вы попали точно в эту причину.
Посмотрим на вопрос, который обычно задают в таких темах: «Ведомости выгружали из ЗУП или создавали в Бухгалтерии? Перечисление делали по зарплатному проекту или на личные счета?» — он очень показателен, потому что комбинации «источник ведомости + способ выплаты» напрямую влияют на то, как 1С сопоставляет строки и проводит документы.
Если вы ведете расчет зарплаты в отдельной программе (например, ЗУП), а в Бухгалтерию выгружаете ведомости, то в Бухгалтерии важно соблюдать связность объектов обмена: сотрудников, физлиц, способов выплаты, банковских счетов, зарплатного проекта. Если при переходе с 7-ки на 8-ку часть данных вводили вручную, а часть грузили — риск несоответствий очень высокий.
Типовые проявления:
Разберем пошагово, что именно проверять.
Проверьте карточку сотрудника и физлица: должен быть корректный способ выплаты (банк/касса), а для банковской выплаты должны быть заполнены реквизиты счета/карты (в зависимости от вашей схемы).
Проверьте ведомость: создайте ведомость того типа, который соответствует способу выплаты (зарплатный проект или личные счета) и заполните ее. Если часть сотрудников «не попадает» — это сигнал, что у них другой способ выплаты или не хватает реквизитов.
Приведите данные к единому виду: массово исправьте способ выплаты в карточках сотрудников (если это допустимо вашей учетной политикой) и затем сформируйте ведомость заново.
Практика показывает, что проблемы «не попадает сотрудник в ведомость» часто связаны именно с настройками способа выплаты или несоответствием типа ведомости.
Отдельно разберем ситуацию, которая часто возникает при загрузке банковской выписки:
В ведомости вы отражаете выплату «одним документом на всех сотрудников», а банк/клиент-банк возвращает платежи «по каждому сотруднику отдельно» (или наоборот: один платеж на реестр, а вы пытаетесь связать его с ведомостью на личные счета).
Тогда в платежке появляется «получатель», который в ведомости не представлен так, как ожидает проверка. Ведомость может быть «реестровая», а платежка — «персональная», и сопоставление ломается.
Если платите зарплатным проектом: делайте одну ведомость «в рамках зарплатного проекта», а в банк отправляйте реестр/один платеж (как предусмотрено вашим банком). В 1С старайтесь формировать платежный документ из ведомости, а не собирать «персональные» платежи вручную.
Если платите на личные счета: используйте ведомость «на счета сотрудников», чтобы строки ведомости соответствовали персональным выплатам. При загрузке выписки убедитесь, что банковские документы создаются в том же формате (персональные перечисления).
Если формат банка не совпадает с вашим привычным учетом: выберите один стандарт и придерживайтесь его. Смешение «реестра» и «персональных платежей» почти всегда приводит к ошибкам сопоставления.
Теперь сделаем более «технический» шаг, который помогает быстро понять, почему ведомость пустая или почему сотрудник не находится. Мы проверим, есть ли в системе записи в зарплатных регистрах по состоянию на дату перехода.
В разных релизах и настройках 1С:Бухгалтерии 3.0 набор регистров может отличаться, но логика одинаковая: должен существовать регистр, где хранится «к выплате/взаиморасчеты с сотрудниками» в разрезе сотрудников. Часто в обсуждениях и методических материалах встречаются регистры с логикой «зарплата к выплате» и «взаиморасчеты с сотрудниками». Важно не название, а факт: должны быть строки по сотрудникам и суммы на дату.
Разберем по шагам, как искать:
Откройте УниверсальныйОтчет.
Выберите объект отчета: регистр накопления, который отвечает за расчеты/выплату сотрудникам (в зависимости от вашей базы это может быть регистр типа ЗарплатаКВыплатеОрганизаций или аналогичный по смыслу).
Постройте отчет по остаткам на дату 31.12.2024 (или на 01.01.2025 — как вы ведете переход), в разрезе сотрудника.
Сравните: есть ли там суммы? совпадают ли с вашим вводом остатков?
Если суммы там отсутствуют — это подтверждает причину №1: остатки введены не в тот контур.
Иногда в реальных проектах (особенно после переносов/сверток) бухгалтеры сталкиваются с тем, что стандартные документы ввода остатков уже проведены, но ведомость все равно не формируется корректно из-за «сломанного» регистра. В таких случаях консультанты применяют точечное исправление через запись в регистр накопления набором записей — для этого подойдёт редактирование записей регистров накопления и бухгалтерии.
Важно: такой способ используйте только если вы уверены в структуре данных вашей конфигурации и понимаете последствия. В идеале сначала решайте проблему «правильными документами», а ручную запись в регистры применяйте как исключение (например, на копии базы, с контролем движений и отчетов).
Посмотрим на пример кода, который иллюстрирует подход (названия регистров и измерений подставляйте строго по вашей конфигурации):
Процедура ДобавитьОстатокЗарплатыКВыплате(Сотрудник, Организация, ДатаОстатка, СуммаКВыплате) Экспорт
Набор = РегистрыНакопления.ЗарплатаКВыплатеОрганизаций.СоздатьНаборЗаписей();
Набор.Отбор.Организация.Установить(Организация);
Запись = Набор.Добавить();
Запись.Период = ДатаОстатка;
Запись.Организация = Организация;
Запись.Сотрудник = Сотрудник;
Запись.ВидДвижения = ВидДвиженияНакопления.Приход;
Запись.Сумма = СуммаКВыплате;
Набор.Записать(Истина);
КонецПроцедуры
Повторим еще раз: это не «универсальная таблетка», а пример методики. На практике чаще всего достаточно исправить ввод остатков и заново сформировать ведомость.
Соберем все в понятный порядок действий — «разберем по шагам» то, что почти всегда приводит к успеху при ошибке «нет сведений о заработной плате сотрудника».
Определим тип выплаты: зарплатный проект или личные счета.
Проверим ведомость: правильный тип ведомости, проведена, табличная часть содержит нужных сотрудников и суммы.
Проверим сотрудника: один ли он в базе (нет дублей), заполнены ли реквизиты банка/счета, верный ли способ выплаты.
Проверим ввод остатков: есть ли задолженность не только на счетах, но и в зарплатном контуре (через отчеты/универсальный отчет).
Пересоздадим ведомость после исправлений: создадим новую ведомость нужного типа и заполним ее заново.
Свяжем платежи с правильной ведомостью: либо создадим платежки из ведомости, либо в загруженных документах выберем корректную ведомость и перепроведем.
Чтобы закрепить результат, посмотрим на типовые ошибки миграции, которые усиливают вероятность этой проблемы (поможет перенос начальных остатков из Бухгалтерии 7.7):
Остатки введены одной суммой без детализации по сотрудникам — в бухгалтерском учете «долг есть», а в ведомости «сотрудника нет».
Смешали схемы выплаты (часть через проект, часть на личные счета) и при этом пытаются использовать одну ведомость и один тип банковских документов.
Дубли сотрудников/физлиц из-за разного формата ФИО, загрузки из банка, неполного переноса справочников.
Незаполненные банковские реквизиты сотрудников — ведомость может быть, но сопоставление по получателю ломается.
Документы ввода остатков введены, но не перепроведены после обновлений/исправлений — в результате движения по регистрам не соответствуют ожиданиям.
Если мы последовательно пройдем по этим пунктам, то в большинстве случаев полностью устраним ошибку и добьемся проведения как ведомостей, так и платежных документов.
Итог: ошибка «в выбранной ведомости отсутствуют сведения о заработной плате сотрудника» почти всегда означает одно из трех: (1) в ведомости реально нет строки по нужному сотруднику (часто из-за неверного ввода остатков), (2) режим выплаты не совпадает (проект/личные счета), (3) сотрудник/физлицо задвоены и платежка «смотрит» не на того. Мы разобрали диагностику и несколько рабочих решений, включая корректный ввод остатков и приведение справочников/ведомостей к одному сценарию.
Информация носит справочный характер.