Проанализируем ситуацию: у ИП 4 работника, учет ведется в Эльбе, а реестр для зарплатного проекта сейчас формируется прямо в интернет-банке, после чего выписка загружается в Эльбу. Логичное желание — сделать «как в 1С»: сформировать реестр в учетной системе, выгрузить файл в банк и не собирать выплаты вручную.
Разберем по шагам, что реально можно сделать сейчас, почему в Эльбе это ограничено, и какие есть практичные обходные варианты (включая сценарий «как в 1С», если реестр нужен именно файлом для зарплатного проекта).
Сначала зафиксируем ключевой факт: формирование реестра зарплатного проекта для передачи в банк в Эльбе не реализовано. Причина — банки предъявляют разные требования к структуре и формату реестра (поля, порядок, кодировки, контрольные суммы, идентификаторы договора/реестра, разные форматы файлов), и «единой формы», которую можно было бы выгружать всем, нет. Поэтому в типовом сценарии банк предлагает создавать реестры прямо в интернет-банке, где уже заложены их правила проверки и импорта.
Из этого следует практический вывод: если у нас банк, который требует «свой» файл/шаблон для зарплатного проекта, то универсальная выгрузка из Эльбы будет регулярно «ломаться» об особенности конкретного банка. Именно поэтому Эльба и предлагает решать задачу либо внутри интернет-банка, либо через индивидуальное пожелание с указанием банка и примера реестра.
Посмотрим на самый надежный путь без смены инструмента: оставляем создание реестра в банке, но наводим порядок в исходных данных и последовательности действий, чтобы это занимало минимум времени.
Разберем по шагам, как выстроить процесс:
Проверим реквизиты сотрудников: ФИО, дата рождения (если банк просит), паспорт (если требуется), номер карты/счета/лицевого счета зарплатного проекта, БИК/банк получателя (если выплаты не внутри проекта, а как переводы). Чем аккуратнее справочник сотрудников, тем меньше ручных правок при создании реестра.
Отделим «зарплатный проект» от «обычных переводов физлицам». В зарплатном проекте банк часто ожидает загрузку реестра именно в разделе «Зарплатный проект» (а не как платежные поручения). Если сделать наоборот, банк может взять комиссию или запросить дополнительные подтверждения.
Используем шаблоны/импорт банка. Многие банки дают импорт из CSV/Excel/TXT/XML/DBF — но структура зависит от банка. Смысл такой: вместо ручного ввода сотрудников каждый месяц мы один раз приводим данные к шаблону банка и дальше лишь меняем суммы и период.
Фиксируем регламент: дата начисления → дата формирования реестра → дата платежа → загрузка выписки в Эльбу. Это снижает риск расхождений, когда начисления и фактические выплаты «разъезжаются» по месяцам.
Дальше уже работаем по правилам конкретного интернет-банка: как правило, в разделе зарплатного проекта создается документ «реестр», выбираются сотрудники, проставляются суммы и отправляется на подпись/платеж. В справочных материалах банков (например, в СберБизнес) такая последовательность описана именно как основной штатный путь работы.
Плюс этого решения — максимальная совместимость с требованиями банка и минимум рисков отказа в загрузке. Минус — реестр не «рождается» из Эльбы автоматически, а собирается в банке.
Теперь рассмотрим вариант, который частично закрывает потребность «сделать выплату из Эльбы», даже если классический реестр зарплатного проекта не формируется.
Есть интеграционный сценарий: для клиентов Эльбы и Контур.Банка заявлена возможность выплачивать зарплату всем сотрудникам «за пару кликов» без создания зарплатного проекта и без загрузки реестра. То есть логика меняется: мы не формируем файл реестра, а инициируем массовую выплату из Эльбы через интеграцию банка.
Разберем по шагам, как обычно выглядит такой подход (на уровне идеи и организации работы):
Подключаем банк как сервис в учетной системе, чтобы Эльба могла инициировать выплаты и получать подтверждение по операциям.
Проверяем карточки сотрудников: для массовой выплаты должны быть корректно заполнены реквизиты, которые ожидает интеграция (обычно это счет/карта, привязанная к выплатам).
Фиксируем основание выплаты: зарплата за период, отпускные, больничные — в зависимости от того, как вы ведете начисления.
Запускаем выплату сразу на всех сотрудников одним действием, вместо ручного создания реестра в банке.
Важно понимать: это не «выгрузка реестра зарплатного проекта в формате банка», а альтернативная модель выплаты, где банк и Эльба обмениваются данными по интеграции. Поэтому если ваш банк — не Контур.Банк, этот путь может быть недоступен, и придется идти по Решению 1 или 3/4.
Теперь посмотрим на путь, который помогает «сдвинуть» продукт в вашу сторону, если реестр нужен именно файлом и именно для вашего банка.
Логика такая: поскольку у каждого банка свой формат, команда Эльбы просит присылать конкретику — тогда пожелание можно корректно зарегистрировать, а дальше оно попадает в бэклог как задача «под определенный банк/формат».
Разберем по шагам, что подготовить, чтобы обращение было максимально полезным:
Укажем банк и точное название продукта банка (например, «СберБизнес зарплатный проект», «ВТБ Бизнес Онлайн зарплатный проект» и т.п.). Даже внутри одного банка бывают разные правила для разных каналов/версий.
Приложим пример реестра (обычно банк дает образец файла или выгруженный тестовый реестр).
Приложим правила формирования: какие поля обязательны, в какой кодировке файл, какие разделители, какие идентификаторы договора/реестра, нужны ли итоги и контрольные поля.
Опишем сценарий: «ИП, столько-то сотрудников, хотим выгружать реестр одним файлом из Эльбы, далее загружать в интернет-банк в разделе зарплатного проекта».
Даже если функция появится не сразу, такой запрос снижает риск, что «ваш» банк окажется неподдерживаемым из-за нехватки данных. А для вас это минимум усилий: один раз собрать пакет и отправить.
Теперь разберем вариант, который ближе всего к запросу «по аналогии с 1С»: если бизнес-процесс критично требует именно файл реестра в формате банка (а банк не дает удобного конструктора в интернет-банке или вы хотите полностью убрать ручной труд), то практично использовать 1С, где формирование ведомостей/реестров под банки — типовой сценарий.
Посмотрим, как это устроено в экосистеме 1С на уровне терминов (без привязки к одной конфигурации):
В 1С настраивается «зарплатный проект» (договор/соглашение с банком) и формат обмена/выгрузки.
Дальше формируется документ выплаты (обычно «ведомость в банк»), в который попадают сотрудники и суммы.
Из ведомости выполняется выгрузка файла для банка, и в интернет-банке этот файл загружается в раздел зарплатного проекта.
Рассмотрим подробнее, какие объекты/разделы 1С нам помогают (названия зависят от конфигурации, но смысл общий):
Справочник банков — проверяем корректность БИК, коррсчета, реквизитов банка. В терминах 1С это обычно Справочник.Банки или аналогичный справочник. Важно, чтобы банк был заполнен корректно, иначе формат выгрузки может быть недоступен или файл будет некорректен.
Настройка зарплатного проекта — заводим соглашение/договор с банком, выбираем банк и параметры обмена. Во многих описаниях по 1С отдельно подчеркивается, что нужно указать формат обмена (часто встречается упоминание семейства форматов клиент-банка, например «1CClientBankExchange», но конкретика зависит от банка и конфигурации).
Документ выплаты «ведомость в банк» — именно он собирает сотрудников и суммы. В типовых конфигурациях это документ уровня Документ.ВедомостьВБанк (или близкое по смыслу название). Из него обычно и выполняется команда «Выгрузить»/«Выгрузить файл».
Механизм выгрузки реестров — 1С умеет выгружать реестры для зачисления зарплаты и прочих выплат, но набор поддерживаемых форматов зависит от конфигурации и банка. В материалах по ЗУП/ЗГУ отдельно описывается «выгрузка реестров в банк» как штатная функция.
Теперь разберем по шагам практический алгоритм «как в 1С», чтобы понять, что именно вы получаете, если решите закрывать задачу через 1С (полностью или частично):
Подготовим данные по сотрудникам: ФИО, статус, реквизиты для зарплатного проекта (обычно это «лицевой счет/номер счета/номер карты», который банк выдает сотруднику в рамках проекта). В 1С это хранится в карточках сотрудников/физлиц и связанных реквизитах (например, через Справочник.Сотрудники и Справочник.ФизическиеЛица в разных конфигурациях).
Создадим/настроим зарплатный проект для банка: укажем банк, договор, параметры обмена. На этом этапе важно выбрать правильный «формат выгрузки», если конфигурация предлагает список форматов под разные банки.
Сформируем ведомость на выплату: заполним период, вид выплаты, автоматически подтянем суммы по сотрудникам (или загрузим начисления, если учет разнесен по системам). Итог — документ «ведомость в банк» со списком сотрудников и сумм.
Выгрузим файл из ведомости: получим реестр в формате, который ожидает банк. Далее загружаем его в интернет-банк в раздел зарплатного проекта.
Проконтролируем статус: в 1С ведомость обычно может менять состояние (например, «подготовлено», «передано», «выплачено») — это удобно для контроля, чтобы не платить дважды и быстро находить расхождения.
Плюс решения с 1С — вы действительно получаете «как в 1С»: ведомость → файл → банк. Минус — нужно вести хотя бы часть зарплатного блока в 1С или настраивать обмен, иначе придется вручную переносить суммы/начисления, что сведет выгоду на нет.
Чтобы не усложнять себе жизнь, давайте посмотрим на выбор как на простую развилку и вместе решим, какой путь вам подходит.
Если банк уже удобен для реестров (есть массовое заполнение, шаблоны, импорт, повторяющиеся платежи) — берем Решение 1 и просто оптимизируем процесс. Это почти всегда быстрее, чем городить отдельную выгрузку там, где ее нет.
Если у вас Контур.Банк и цель — «платить из Эльбы», а не «получить файл реестра» — смотрим Решение 2 и уходим от реестров вообще (в пользу интеграции).
Если вам нужен именно файл под конкретный банк, но вы хотите остаться в Эльбе — делаем Решение 3: отправляем в поддержку банк + пример + правила формирования. Это единственный путь, который потенциально приведет к появлению формата именно под ваш банк.
Если нужна типовая выгрузка реестров «как в 1С» уже сейчас — выбираем Решение 4 и используем 1С (ЗУП/ЗГУ/Бухгалтерия, в зависимости от того, где у вас зарплата). Там логика «ведомость → выгрузка файла» — штатная.
Рассмотрим подробнее типовые причины, из-за которых реестры/массовые выплаты «не взлетают», и сразу заложим контрольные точки.
Смешали зарплатный проект и обычные платежи физлицам. В зарплатном проекте банк ожидает реестр в своем разделе, а для обычных платежей — платежки/переводы. Разведем эти сценарии и не будем пытаться загрузить «не тот» файл «не туда».
Некорректные реквизиты сотрудников. Самая частая причина отказа импорта — неверный номер счета/карты/лицевого счета или несоответствие ФИО. Договоримся, что перед первой массовой выплатой делаем сверку по одному сотруднику тестовым платежом/тестовым реестром.
Разные требования к кодировке и разделителям. Даже если банк принимает «CSV», он может требовать определенную кодировку и конкретный разделитель (запятая/точка с запятой/таб). Поэтому всегда берем шаблон именно из интернет-банка.
Нет «правил формирования» при запросе в поддержку. Если хотим, чтобы в Эльбе появилась выгрузка под наш банк, обязательно прикладываем не только «пример», но и описание правил (какие поля обязательны, откуда берутся значения, как формируется номер реестра, как округлять суммы и т.д.).
Давайте зафиксируем практичный план действий, чтобы решение было не теоретическим, а рабочим:
Если ваша цель — минимум ручной работы и у вас есть возможность платить через интеграцию, рассмотрим связку Эльба + Контур.Банк и уйдем от реестра как файла.
Если ваш банк — другой, и вы уже формируете реестр в интернет-банке, оптимизируем этот процесс: приводим справочник сотрудников к требованиям банка, используем шаблон/импорт и регламент по датам.
Если принципиально нужен файл реестра из учетной системы, действуем параллельно: (а) регистрируем пожелание в поддержку Эльбы с банком/примером/правилами, (б) при необходимости подключаем 1С для формирования ведомости и выгрузки.
Информация носит справочный характер и предназначена для общего понимания вариантов решения; конкретные действия и форматы реестров зависят от вашего банка, версии интернет-банка и выбранной учетной системы.