Рассмотрим ситуацию, когда после очередного обновления «1С:Зарплата и управление персоналом 3.1» или «1С:Бухгалтерия предприятия 3.0» перестали передаваться ведомости на выплату зарплаты. При этом ранее синхронизация работала: из ЗУП в Бухгалтерию попадали документы Ведомость в банк, Ведомость в кассу или другие документы выплаты, а после обновления новые ведомости перестали появляться в базе Бухгалтерии.
Такая проблема не всегда означает, что обновление содержит ошибку. Чаще всего после изменения версии конфигурации меняется или сбрасывается отдельная настройка синхронизации, отключается детализация расчетов с сотрудниками, документ не регистрируется к отправке либо в Бухгалтерии действует ограничение по дате загрузки данных. Поэтому не будем сразу переустанавливать обмен или вручную создавать ведомости в Бухгалтерии. Сначала проанализируем настройки и определим, на каком этапе прекращается передача документа.
Важно: ведомость на выплату зарплаты передается между ЗУП и Бухгалтерией не сама по себе. Для ее выгрузки должны одновременно выполняться несколько условий: синхронизация должна быть настроена и активна, расчеты с персоналом в Бухгалтерии должны вестись с нужной детализацией, в настройках обмена должна быть включена передача сведений о выплате зарплаты, ведомость должна быть проведена и зарегистрирована к отправке, а в принимающей базе не должно быть запрета на загрузку документа по его дате.
Разберем проблему по шагам и восстановим обмен без потери уже загруженных данных.
При синхронизации ЗУП 3.1 и Бухгалтерии 3.0 передаются не все документы, которые существуют в зарплатной базе. Состав отправляемых данных зависит от параметров синхронизации и варианта отражения расчетов с персоналом в бухгалтерском учете.
Если в Бухгалтерии выбран сводный учет расчетов с сотрудниками, программа может передавать только документ Отражение зарплаты в бухучете без детализации по каждому работнику. Такой вариант удобен для организаций, которые не ведут зарплатные расчеты в Бухгалтерии по сотрудникам и хотят получать только бухгалтерские проводки по счетам учета.
Однако ведомость на выплату зарплаты содержит сведения о конкретных физических лицах, сотрудниках, суммах к выплате, удержаниях и способах получения денег. Поэтому при сводном варианте учета ведомости могут не передаваться. Это нормальное поведение механизма обмена, а не обязательно ошибка программы.
После обновления следует проверить, не изменился ли вариант выгрузки зарплатных данных. В некоторых случаях настройка остается прежней визуально, но при обновлении правил обмена требуется повторно подтвердить параметры на стороне ЗУП или Бухгалтерии.
Также причиной может быть различие релизов. В описанной ситуации использовались версии ЗУП 3.1.25.136 и Бухгалтерии 3.0.142.56. Версия ЗУП 3.1.25.136 относится к более ранней ветке обновлений, тогда как Бухгалтерия 3.0.142.56 уже содержит более поздние изменения в правилах обмена. В октябре 2023 года вышел релиз ЗУП 3.1.27.93, поэтому при работе со старыми версиями важно не обновлять только одну базу, а поддерживать совместимые релизы обеих конфигураций.
Не будем считать различие версий единственной причиной проблемы. Даже если одна база обновлена позже другой, ведомость может не выгружаться из-за отключенной настройки, даты запрета загрузки, непроведенного документа или отсутствия регистрации изменений для обмена.
Сначала определим, какой именно документ не передается. В ЗУП могут использоваться различные документы выплаты:
Ведомость в банк — применяется при перечислении заработной платы, аванса, отпускных, пособий и других сумм на банковские счета сотрудников.
Ведомость в кассу — используется при выплате наличных денежных средств через кассу организации.
Ведомость через раздатчика — используется, если деньги сотрудникам выдает назначенный раздатчик.
Списание с расчетного счета — создается в Бухгалтерии для отражения фактического перечисления денежных средств банком.
Выдача наличных — создается в Бухгалтерии для отражения выплаты из кассы.
Отражение зарплаты в бухучете — передает бухгалтерские проводки по начислениям, удержаниям, страховым взносам и резервам, но не заменяет ведомость на выплату.
Ведомость из ЗУП и банковский платежный документ в Бухгалтерии выполняют разные задачи. Ведомость фиксирует, кому и в каком размере следует выплатить доход. Документ списания с расчетного счета подтверждает фактическое перечисление денежных средств. Поэтому не будем пытаться заменить отсутствующую ведомость ручным документом списания, пока не разберемся с причиной сбоя обмена.
Если из ЗУП продолжает выгружаться документ Отражение зарплаты в бухучете, но не передаются ведомости, это важный диагностический признак. Он означает, что транспорт синхронизации в целом работает: базы видят друг друга, подключение установлено, обмен выполняется. В таком случае необходимо проверять не техническое подключение, а настройки состава выгружаемых данных и вариант учета расчетов с персоналом.
Если же из ЗУП не передается вообще ничего, включая документы отражения зарплаты, справочники и новые кадровые данные, будем проверять подключение, сообщения обмена, права пользователя, дату запрета изменения данных и настройки самой синхронизации.
Первое решение заключается в обновлении обеих конфигураций до совместимых релизов. Не будем обновлять только одну программу и считать, что обмен автоматически восстановится. Правила обмена, форматы данных и состав передаваемых реквизитов могут изменяться одновременно в ЗУП и Бухгалтерии.
Перед обновлением обязательно создадим резервные копии обеих информационных баз. Копия потребуется не только для восстановления в случае технической ошибки, но и для сравнения результатов синхронизации до и после обновления.
Создадим отдельную резервную копию базы ЗУП.
Создадим отдельную резервную копию базы Бухгалтерии.
Зафиксируем используемые версии конфигураций и платформы 1С:Предприятие.
Проверим наличие доработок конфигураций, внешних обработок и расширений, влияющих на обмен.
Обновим сначала конфигурацию ЗУП, затем конфигурацию Бухгалтерии либо выполним обновление в порядке, рекомендованном для используемой линии поставки.
После обновления выполним вход в обе базы под пользователем с административными правами.
Откроем настройки синхронизации и убедимся, что настройка обмена не отключена и не требует повторного сопоставления данных.
Выполним тестовую синхронизацию без ручного удаления существующих настроек.
После обновления не будем сразу выполнять начальную выгрузку всех данных. Повторная начальная выгрузка может создать дубли документов, справочников, банковских счетов, физических лиц и способов отражения зарплаты. Сначала проверим обычный обмен по зарегистрированным изменениям.
Если после обычной синхронизации ведомость не передается, продолжим проверку параметров учета и состава выгрузки.
Одна из наиболее частых причин отсутствия ведомостей — сводный учет расчетов с персоналом в Бухгалтерии. При таком варианте программа не хранит расчеты по каждому сотруднику в необходимой детализации, поэтому передача ведомостей из ЗУП может быть отключена.
Разберем, что необходимо проверить в Бухгалтерии предприятия.
Откроем раздел Администрирование.
Перейдем к параметрам учета или настройке плана счетов. Наименование команды зависит от релиза Бухгалтерии.
Найдем настройку учета расчетов с персоналом.
Проверим, какой вариант установлен: сводно либо по каждому сотруднику.
Для передачи ведомостей выберем вариант учета расчетов с персоналом по каждому сотруднику.
Сохраним настройку и повторно выполним синхронизацию.
Настройка должна быть согласована с реальным способом ведения учета. Если организация ведет расчеты с персоналом в Бухгалтерии только общими суммами и не использует ведомости, перевод на учет по каждому сотруднику может изменить аналитику счетов расчетов с персоналом. Поэтому перед изменением параметра проанализируем последствия для уже отраженных операций.
Если бухгалтерский учет давно ведется с детализацией по сотрудникам, а ведомости ранее успешно передавались, но после обновления настройка изменилась на сводную, вернем прежний вариант. После этого новые ведомости обычно начинают регистрироваться к выгрузке.
Важно: изменение варианта учета не обязательно повторно отправит уже пропущенные ведомости. После восстановления настройки потребуется отдельно проверить регистрацию документов и при необходимости повторно включить их в обмен.
Теперь рассмотрим настройки в «1С:Зарплата и управление персоналом 3.1». Для этого откроем раздел Администрирование, затем перейдем в Синхронизация данных и выберем Настройки синхронизации данных.
В списке настроек найдем обмен с соответствующей базой Бухгалтерии. Если настроек несколько, внимательно выберем именно действующую настройку. Иногда после обновлений или переноса базы создаются несколько подключений с похожими наименованиями, а пользователи запускают обмен не по той настройке.
Откроем настройку и проверим следующие параметры:
Включена ли возможность синхронизации данных.
Правильно ли указана база-корреспондент.
Не изменился ли способ подключения: прямое подключение, файловый обмен, обмен через каталог, обмен через сервис или обмен через интернет.
Нет ли ошибки доступа к каталогу обмена, файловому ресурсу или серверу.
Правильно ли выбран префикс информационной базы.
Не включено ли ограничение по организациям, исключающее нужную организацию.
Не указана ли дата начала выгрузки позже даты ведомости.
Включена ли передача данных о выплате заработной платы.
Выбран ли вариант выгрузки сведений о выплате как ведомостей на выплату зарплаты.
Используется ли детализация данных по сотрудникам, необходимая для передачи ведомостей.
В разных релизах формулировки полей могут отличаться. В частности, настройка может называться «Сведения о выплате зарплаты», «Выгружать ведомости на выплату зарплаты», «Передавать документы выплаты», «Детализация по сотрудникам» или аналогично. Смысл проверки остается одинаковым: сведения о выплатах должны быть включены в состав отправляемых данных, а не ограничиваться передачей только документа Отражение зарплаты в бухучете.
Если настройка передачи ведомостей отключена, включим ее, сохраним изменения и запустим синхронизацию. Затем создадим тестовую ведомость на небольшую сумму в копии базы либо воспользуемся новой рабочей ведомостью, которая еще не участвовала в обмене.
Не будем менять одновременно все параметры синхронизации. Лучше изменим одну настройку, выполним обмен и проверим результат. Такой подход позволит точно определить, какое условие препятствовало выгрузке.
Настройки синхронизации необходимо проверить не только в ЗУП, но и в Бухгалтерии. В Бухгалтерии также откроем раздел Администрирование, затем раздел Синхронизация данных и список настроек синхронизации.
Проверим, что настройка обмена с ЗУП активна и соответствует той базе, из которой отправляются документы. Особенно внимательно проверим настройки, если использовались копии баз, тестовые базы, файловые и серверные варианты одной организации.
На стороне Бухгалтерии проанализируем следующие условия:
Настройка синхронизации не должна быть отключена.
Должна быть указана корректная база ЗУП.
Должен быть выбран правильный пользователь для подключения, если используется прямой обмен.
У пользователя должны быть права на загрузку и запись документов обмена.
Не должна действовать дата запрета загрузки данных, блокирующая ведомость.
В настройках учета должен быть доступен учет расчетов по каждому сотруднику.
В списке организаций должна присутствовать организация, по которой сформирована ведомость.
Не должно быть незавершенного сопоставления физических лиц, сотрудников, организаций, банков и способов выплаты.
Если ведомость не появляется в Бухгалтерии, но в журнале синхронизации указано, что данные успешно получены, проверим не только список ведомостей, но и сообщения обмена. Документ может быть принят, но не записан из-за несопоставленного объекта или противоречивой настройки учета.
Например, ведомость может ссылаться на зарплатный проект, банковский счет организации или сотрудника, который не сопоставлен между базами. В таком случае в сообщениях обмена может быть указано, что требуется ручное сопоставление данных. После сопоставления справочников снова выполним синхронизацию.
Прежде чем искать проблему в настройках обмена, убедимся, что сама ведомость в ЗУП готова к передаче.
Откроем раздел Выплаты и перейдем в список всех ведомостей на выплату зарплаты. Найдем документ, который не выгрузился, и проверим его состояние.
Убедимся, что документ проведен.
Проверим дату ведомости. Она должна попадать в период, разрешенный для загрузки в Бухгалтерию.
Проверим организацию в шапке документа.
Убедимся, что организация включена в настройки обмена.
Проверим вид выплаты: зарплата, аванс, отпускные, межрасчетная выплата, пособие, компенсация или другой вид дохода.
Проверим способ выплаты: через банк, через кассу, через раздатчика.
Убедимся, что в ведомости есть строки сотрудников и заполнены суммы к выплате.
Проверим, не была ли ведомость помечена на удаление.
Проверим, не отменено ли проведение документа после предыдущего обмена.
Если ведомость непроведена, проведем ее и повторно выполним синхронизацию. Если документ был проведен, затем отменен, затем снова проведен, он должен быть зарегистрирован как измененный объект. Но при нестандартных доработках, восстановлении базы из копии или ручном вмешательстве регистрация изменений может быть нарушена.
Если ведомость создана задним числом, дополнительно проверим дату запрета изменения данных. Например, в Бухгалтерии может быть установлен запрет загрузки документов до 1 октября, а ведомость создана датой 30 сентября. В этом случае синхронизация может успешно пройти технически, но документ не будет записан в принимающей базе.
Дата ведомости, дата выплаты и дата документа могут иметь разное значение. Для обмена важно проверять именно дату самого документа, а также настройки ограничений в обеих базах.
После обновления пользователи часто устанавливают дату запрета изменения данных, чтобы защитить закрытые месяцы и сданную отчетность. Это правильная практика, но при синхронизации необходимо учитывать, что ограничение может препятствовать загрузке документов из ЗУП.
Разберем типовую ситуацию. В Бухгалтерии закрыт сентябрь, и дата запрета установлена по 30 сентября включительно. Затем в ЗУП создается ведомость за сентябрь датой 29 сентября. При синхронизации Бухгалтерия может не принять этот документ, поскольку его дата попадает в закрытый период.
Для проверки откроем настройки даты запрета изменения данных в каждой базе и сравним их с датой ведомости. Если проблема подтверждается, не будем бессрочно отменять запрет. Выполним безопасную последовательность действий:
Создадим резервную копию Бухгалтерии.
Временно изменим дату запрета только на период, необходимый для загрузки ведомости.
Выполним синхронизацию.
Убедимся, что ведомость корректно появилась в Бухгалтерии.
Проверим, не загрузились ли нежелательные изменения по закрытому периоду.
Вернем дату запрета в исходное значение.
Если организация использует разграничение доступа по пользователям, проверим не только общую дату запрета, но и персональную дату запрета для конкретного пользователя обмена. Иногда администратор снимает ограничение для себя, но обмен выполняется от имени другого пользователя, для которого запрет остается активным.
Синхронизация 1С обычно передает не все документы при каждом запуске, а только объекты, зарегистрированные как измененные после предыдущего успешного обмена. Это снижает объем передаваемых данных и ускоряет работу, но требует корректной регистрации изменений.
Если ведомость была создана или изменена после последней синхронизации, она должна попасть в список отправляемых объектов. Если документ не регистрируется, он не будет выгружен даже при успешном завершении обмена без ошибок.
Рассмотрим признаки проблемы с регистрацией:
Синхронизация завершается успешно, но количество отправленных объектов равно нулю.
Новые документы отражения зарплаты передаются, а ведомости не передаются.
Ведомость была создана до изменения настроек и после изменения не попала в обмен.
Документ был перенесен из копии базы, загружен обработкой или изменен нестандартным способом.
В базе использовалась доработка, которая записывает документ без стандартной регистрации для обмена.
Вначале выполним безопасную проверку без изменения регистров обмена. Откроем ведомость, проверим реквизиты, при необходимости внесем допустимое изменение, например уточним комментарий, затем запишем и проведем документ повторно. После этого выполним синхронизацию и проверим, появился ли документ в Бухгалтерии.
Не будем менять сумму ведомости, дату выплаты, сотрудников или удержания только для того, чтобы вызвать регистрацию изменений. Изменять следует только реквизиты, которые не влияют на расчет и не искажают учет. Если комментарий не используется в конкретной конфигурации или доработке, можно открыть документ, перепровести его без изменения данных и проверить, зарегистрировался ли объект.
Если ведомость после перепроведения передалась, значит проблема могла заключаться в отсутствии регистрации старого документа. В таком случае проверим остальные пропущенные ведомости и выберем безопасный способ их повторной регистрации.
Если ведомость не передается даже после перепроведения, продолжим анализировать правила выгрузки и журнал обмена.
При отсутствии видимой ошибки пользователи часто делают вывод, что синхронизация работает нормально. Однако успешное завершение обмена означает только то, что технический процесс выполнен. Это не гарантирует, что каждый нужный документ был передан и записан.
Откроем настройку синхронизации и просмотрим сообщения последнего обмена. Нас будут интересовать следующие сведения:
Дата и время последней синхронизации.
Какая база выступала источником, а какая приемником.
Количество отправленных объектов.
Количество полученных объектов.
Наличие предупреждений.
Наличие ошибок сопоставления данных.
Сообщения о пропущенных документах из-за даты запрета.
Сообщения об отсутствии прав у пользователя обмена.
Сообщения о невозможности записи документа.
Если в протоколе есть ошибка, не будем исправлять ведомость вручную в Бухгалтерии. Сначала устраним первопричину. Например, если программа сообщает об отсутствии сопоставления банковского счета, сопоставим банковский счет. Если сообщение связано с организацией, проверим карточку организации и правила обмена по организациям. Если указана дата запрета, временно откроем период или создадим корректную ведомость в разрешенном периоде по правилам учета.
Если журнал содержит предупреждение о дублирующемся объекте, не будем удалять документы в одной из баз без анализа. Сначала определим, имеется ли в Бухгалтерии ведомость с тем же номером, датой и организацией, но созданная вручную. Наличие ручного документа может мешать корректному сопоставлению объекта обмена.
Если ранее ведомости создавались вручную в Бухгалтерии, а затем начали передаваться из ЗУП, необходимо определить единый источник данных. Для зарплатных ведомостей обычно основным источником должна быть ЗУП, а Бухгалтерия должна принимать документы через синхронизацию. Одновременное создание одинаковых ведомостей в обеих базах повышает риск дублей, некорректных остатков по счету 70 и расхождений между расчетами и платежами.
Ведомость на выплату содержит ссылки на большое количество справочных объектов. Для успешной передачи должны быть корректно сопоставлены организация, физические лица, сотрудники, банковские счета, зарплатный проект, подразделения и при необходимости способы отражения зарплаты.
Особенно внимательно проверим организацию. Если в ЗУП используется несколько организаций, а в настройке обмена выбрана только одна, ведомости по другой организации не будут передаваться. Такая ситуация часто возникает после обновления, создания новой организации, изменения ИНН, КПП или переноса данных между базами.
Проверим следующие объекты:
Организации — должны быть сопоставлены между ЗУП и Бухгалтерией.
Физические лица — должны корректно определяться в обеих базах.
Сотрудники — должны быть связаны с соответствующими физическими лицами.
Банковские счета организаций — должны быть доступны для формирования платежных документов в Бухгалтерии.
Зарплатные проекты — должны быть сопоставлены при выплате через зарплатный проект.
Банковские счета сотрудников — должны быть заполнены, если используется перечисление без зарплатного проекта.
Подразделения — должны быть сопоставлены, если они участвуют в правилах отражения или ограничениях обмена.
Не будем создавать дубликаты сотрудников в Бухгалтерии, если программа не находит соответствие. Сначала воспользуемся механизмом сопоставления данных и проверим, не отличается ли написание фамилии, имени, отчества, ИНН, СНИЛС, даты рождения или другого идентификатора. Дубли физических лиц могут привести к тому, что ведомость будет загружена на другого сотрудника либо не будет загружена совсем.
Если используется зарплатный проект, проверим договор с банком, реквизиты зарплатного проекта, банк, лицевые счета сотрудников и способ выплаты в карточках сотрудников. При изменении банка, переоформлении зарплатного проекта или замене банковских реквизитов старые элементы справочников могут потерять соответствие между базами.
Синхронизация между ЗУП и Бухгалтерией может работать в разных режимах. В одном режиме в Бухгалтерию передаются только суммарные бухгалтерские данные. В другом режиме передаются данные с детализацией по сотрудникам. Для ведомостей на выплату зарплаты нужен второй вариант.
При сводном варианте Бухгалтерия получает общую информацию о начислениях и удержаниях. Например, в документе Отражение зарплаты в бухучете могут формироваться проводки по счетам 20, 25, 26, 44, 69, 70, 68 и другим счетам. Но сама Бухгалтерия не получает полный набор данных для ведения выплат по каждому сотруднику.
При детализированном варианте Бухгалтерия получает более подробные сведения о расчетах с персоналом. Такой режим позволяет формировать и использовать ведомости, связывать выплаты с конкретными сотрудниками, контролировать задолженность по зарплате и отражать перечисление средств с необходимой аналитикой.
Рассмотрим пример. В ЗУП начислена зарплата трем сотрудникам на общую сумму 180 000 рублей. При сводной выгрузке в Бухгалтерию может попасть проводка по кредиту счета 70 на 180 000 рублей без распределения по сотрудникам. При детализированной выгрузке суммы будут отражаться в разрезе сотрудников, а ведомость на выплату сможет быть загружена с конкретными получателями.
Если организация фактически ведет выплаты по сотрудникам в Бухгалтерии, но синхронизация настроена сводно, восстановим детализацию. После изменения настройки проверим уже существующие остатки по счету 70 и убедимся, что переход не создал расхождения в расчетах.
Не переключаем вариант учета без резервной копии и анализа закрытых периодов. Изменение аналитики расчетов с персоналом может повлиять на дальнейшее отражение выплат, закрытие задолженности и сверку с ЗУП.
После исправления настроек новые ведомости могут начать передаваться автоматически, но ранее пропущенные документы могут остаться вне обмена. Это связано с тем, что механизм синхронизации передает только зарегистрированные изменения.
Для повторной передачи пропущенных ведомостей будем действовать последовательно.
Сначала восстановим правильные настройки синхронизации.
Затем проверим, передается ли новая тестовая ведомость.
Если новая ведомость передается, определим список старых пропущенных ведомостей.
Проверим, отсутствуют ли эти документы в Бухгалтерии под другим номером или датой.
По каждой пропущенной ведомости откроем документ в ЗУП и проверим проведение.
При необходимости перепроведем документ, не изменяя экономический смысл операции.
После перепроведения выполним синхронизацию.
Проверим появление ведомости в Бухгалтерии.
Если перепроведение не помогло, можно использовать штатные средства регистрации изменений для обмена данными. Однако такие действия следует выполнять только после создания резервных копий и понимания последствий. Принудительная регистрация большого объема данных может привести к повторной передаче справочников и документов.
Не будем удалять вручную записи регистрации обмена, сообщения синхронизации, служебные объекты и данные информационных регистров. Такие действия могут нарушить состояние обмена сильнее, чем исходная проблема. Если стандартная повторная регистрация не помогает, лучше сначала выполнить диагностику в копии базы.
Если ведомость уже присутствует в Бухгалтерии, но не видна в ожидаемом списке, проверим период, организацию, вид выплаты и настройки отбора. Иногда документ не отсутствует, а отображается в другом журнале или скрыт установленным отбором по организации, подразделению, дате либо пользователю.
Если синхронизация запускается вручную под администратором, а затем выполняется автоматически по расписанию под другим пользователем, результат может различаться. Пользователь, от имени которого запускается обмен по расписанию, должен иметь права на чтение и запись всех объектов, участвующих в синхронизации.
Проверим следующие моменты:
Кто запускает обмен вручную.
Кто запускает обмен по расписанию.
Есть ли у пользователя обмена права на документы выплат.
Есть ли права на организации, сотрудников, банковские счета и зарплатные проекты.
Есть ли права на запись в журнал ведомостей в Бухгалтерии.
Не ограничены ли права пользователя по подразделениям или организациям.
Не отключены ли регламентные задания, если синхронизация работает автоматически.
В серверной базе дополнительно проверим состояние РегламентныеЗадания. Если обмен должен выполняться автоматически, но регламентное задание отключено или выполняется с ошибкой, документы не будут загружаться своевременно. При этом ручной запуск может работать корректно.
Если проблема наблюдается только при автоматической синхронизации, а ручной обмен переносит ведомость, причина обычно связана с правами пользователя, расписанием, доступом к каталогу обмена либо отключенными регламентными заданиями.
Иногда пользователи считают, что ведомость не выгрузилась, потому что после синхронизации в Бухгалтерии остается задолженность по счету 70. Однако сама ведомость и фактический платеж — это разные документы.
Рассмотрим пример. Из ЗУП в Бухгалтерию передалась Ведомость в банк. Она содержит сумму к выплате работникам, но фактическое списание денег со счета организации еще не отражено. До ввода или загрузки банковского документа задолженность перед сотрудниками может продолжать отображаться как непогашенная.
В таком случае проверим не только наличие ведомости, но и дальнейшую цепочку документов:
Передалась ли ведомость на выплату зарплаты.
Создано ли на ее основании платежное поручение или реестр в банк.
Отражено ли фактическое списание денежных средств с расчетного счета.
Указан ли правильный вид операции в банковском документе.
Связан ли банковский документ с ведомостью.
Сформировались ли движения по счету 70 и счету 51.
Не будем исправлять остатки по счету 70 ручными операциями, если фактический платеж еще не отражен. Сначала убедимся, что вся цепочка документов выплаты сформирована корректно.
Сценарий первый: из ЗУП выгружается документ Отражение зарплаты в бухучете, но ведомость в банк не передается.
В этом случае транспорт обмена работает. Проверим вариант учета расчетов с персоналом в Бухгалтерии. Если установлен сводный учет, переключим его на учет по каждому сотруднику после создания резервной копии. Затем проверим настройку передачи сведений о выплате зарплаты в ЗУП.
Сценарий второй: ведомости перестали передаваться сразу после обновления ЗУП, а Бухгалтерия осталась на старом релизе.
В такой ситуации обновим обе программы до согласованных релизов. После обновления проверим, не изменился ли состав отправляемых данных. Не будем удалять настройку обмена и создавать новую до проверки существующей настройки.
Сценарий третий: новые ведомости не передаются, но синхронизация завершается без ошибок.
Проверим, зарегистрированы ли документы к отправке. Откроем ведомость, убедимся в ее проведении, выполним перепроведение и запустим обмен повторно. Затем изучим сообщения синхронизации и количество отправленных объектов.
Сценарий четвертый: ведомость за закрытый месяц не передается, а документы за текущий месяц передаются.
Проверим дату запрета загрузки данных в Бухгалтерии. При необходимости временно откроем нужный период, выполним синхронизацию, проверим результат и снова установим запрет.
Сценарий пятый: ведомость по одной организации передается, а по другой организации нет.
Проверим список организаций, включенных в настройку обмена. Убедимся, что организация сопоставлена между ЗУП и Бухгалтерией, не имеет дубля и не исключена правилами выгрузки.
Сценарий шестой: ведомость в кассу не передается, а ведомость в банк передается.
Проверим вид ведомости, настройки кассовых операций, сопоставление кассы организации и возможные ограничения по кассе. Также убедимся, что в Бухгалтерии включен учет наличных денежных средств и пользователь имеет права на создание кассовых документов.
Сценарий седьмой: ведомость передается, но в Бухгалтерии появляется предупреждение о несопоставленных сотрудниках.
Не будем создавать новых сотрудников вручную. Откроем механизм сопоставления данных, найдем соответствующих физических лиц и сотрудников, устраним различия в реквизитах и повторно выполним обмен.
Для практического решения проблемы используем последовательный алгоритм. Он позволяет не потерять документы, не создать дубли и не нарушить уже закрытые периоды.
Создадим резервные копии ЗУП и Бухгалтерии.
Зафиксируем версии конфигураций и платформы.
Проверим, передаются ли другие документы из ЗУП в Бухгалтерию.
Определим, не передаются все ведомости или только отдельный вид ведомостей.
Проверим проведение проблемной ведомости в ЗУП.
Проверим дату документа и дату запрета загрузки данных в Бухгалтерии.
Проверим организацию и включение организации в настройку обмена.
Проверим учет расчетов с персоналом в Бухгалтерии.
Установим вариант учета по каждому сотруднику, если требуется передача ведомостей.
Проверим в ЗУП настройку передачи сведений о выплате зарплаты.
Проверим вариант выгрузки ведомостей в составе отправляемых данных.
Выполним обычную синхронизацию и изучим сообщения обмена.
Если новая ведомость передается, проверим регистрацию пропущенных ведомостей.
Перепроведем отдельную пропущенную ведомость и повторим обмен.
Если проблема сохраняется, обновим обе конфигурации до совместимых релизов.
После обновления повторно проверим настройки, а не только запускаем обмен.
После каждого действия будем проверять результат. Не следует одновременно менять релизы, настройки учета, даты запрета, права пользователей и состав обмена. При одновременном изменении нескольких параметров будет трудно определить причину и оценить последствия.
При восстановлении синхронизации важно не усугубить проблему. Рассмотрим действия, которых лучше избегать.
Не удаляем существующую настройку синхронизации без резервной копии и без необходимости.
Не создаем новую настройку обмена поверх старой, пока не проверим действующее подключение.
Не выполняем начальную выгрузку всех данных без анализа возможных дублей.
Не удаляем вручную служебные данные обмена и записи регистрации изменений.
Не изменяем сумму ведомости, чтобы заставить ее выгрузиться.
Не меняем дату ведомости только для обхода даты запрета, если это нарушает реальную дату выплаты и учетную политику.
Не создаем вручную ведомость в Бухгалтерии, если документ уже существует или должен прийти из ЗУП.
Не создаем дубли сотрудников, организаций, банковских счетов и зарплатных проектов.
Не отключаем дату запрета на длительный период без контроля загружаемых данных.
Не обновляем только одну базу, если обмен перестал работать после изменения релизов.
Основной принцип: сначала определим, почему документ не попадает в состав выгрузки, затем исправим конкретную причину, и только после этого повторно передадим пропущенные данные.
Если после обновления ведомости на выплату зарплаты перестали выгружаться из ЗУП 3.1 в Бухгалтерию 3.0, сначала проверим не само обновление, а настройки синхронизации и вариант учета расчетов с персоналом.
Наиболее вероятные причины — сводный учет расчетов с сотрудниками в Бухгалтерии, отключенная передача сведений о выплате зарплаты, отсутствие регистрации ведомости к отправке, дата запрета загрузки данных, несопоставленные справочники или несовместимые релизы ЗУП и Бухгалтерии.
Для передачи ведомостей обычно необходимо вести расчеты с персоналом по каждому сотруднику, включить выгрузку сведений о выплате как ведомостей на выплату зарплаты, провести документы в ЗУП, проверить дату запрета в Бухгалтерии и убедиться, что организации, сотрудники, банковские счета и зарплатные проекты корректно сопоставлены.
Если после исправления настроек новые документы передаются, а старые ведомости остаются пропущенными, повторно зарегистрируем их для обмена безопасным способом: проверим проведение, выполним перепроведение и повторную синхронизацию. При необходимости сначала протестируем действия в копии базы.
Информация носит справочный характер