← На главную

Разберем ситуацию, с которой на практике столкнулись многие бухгалтеры в 1С:Бухгалтерии предприятия 3.0: сотрудник часть месяца работает, затем уходит в отпуск или в отпуск без сохранения заработной платы, а документ Начисление зарплаты с переключателем Аванс показывает заниженное количество отработанных дней. На первый взгляд кажется, что проблема связана с настройками графика, производственным календарем или неверно введенным кадровым документом. Но в рассматриваемом случае причина другая: в ряде релизов программы действительно была зарегистрирована ошибка расчета рабочих дней аванса при наличии отпуска.

Проанализируем описанный пример. У первого сотрудника отпуск без сохранения зарплаты оформлен с 16.08.2024 по 26.08.2024. При расчете аванса программа ставит 8 отработанных дней, хотя пользователь ожидает 11. У второго сотрудника отпуск начинается с 12.08.2024 и продолжается по 08.09.2024. В авансе программа показывает 4 отработанных дня, хотя пользователь ожидает 7. Конфигурация: 1С:Предприятие 8.3.23.1865, Бухгалтерия предприятия 3.0.155.23.

Выясним причину. Для редакции 3.0 разработчиками была зарегистрирована ошибка расчета: если в расчетном периоде аванса у сотрудника есть отпускные невыходы, документ Начисление зарплаты в режиме Аванс может некорректно определять количество рабочих дней. Позже эта ошибка была исправлена в более новом релизе, а также для нее выпускался отдельный патч EF_30180350.

То есть в подобной ситуации важно сразу сделать правильный вывод: проблема не обязательно вызвана неправильными действиями бухгалтера. Если используется релиз 3.0.155.23, а ситуация совпадает по признакам, прежде всего нужно проверить, не попадает ли база под известную ошибку программы.

Что именно происходит в программе и почему цифры оказываются меньше ожидаемых

Рассмотрим подробнее логику расчета. Аванс в БП 3.0 рассчитывается документом Начисление зарплаты с установленным переключателем Аванс. При автоматическом заполнении программа анализирует:

1. месяц начисления;
2. график работы сотрудника;
3. норму времени;
4. невыходы, зарегистрированные кадровыми и расчетными документами;
5. вид начисления, например Оплата по окладу или Оплата по окладу, пропорционально отработанным дням.

Если у сотрудника есть документ Отпуск или документ, связанный с отпуском без оплаты, программа должна исключить из расчета те дни, которые на момент выплаты аванса считаются неотработанными. В нормальной ситуации это работает корректно. Но в проблемных релизах происходил сбой именно на этапе определения рабочих дней за первую половину месяца. В результате в табличной части документа Начисление зарплаты занижалось значение отработанного времени, а вслед за ним уменьшалась и сумма аванса.

Обратим внимание на важный момент: сама по себе методика расчета аванса в 1С не предполагает фиксированный процент от оклада. Программа ориентируется на фактически отработанное время за первую половину месяца. Поэтому если количество дней оказалось меньше ожидаемого, это всегда нужно проверять по связке:

1. какой график установлен сотруднику;
2. какая норма дней в первой половине месяца;
3. какие невыходы зарегистрированы документально;
4. не сработала ли известная ошибка конкретного релиза.

Главная причина в рассматриваемом случае: ошибка релиза 3.0.155.23

В описанной ситуации версия программы 3.0.155.23 как раз относится к периоду, когда ошибка уже проявлялась у пользователей. Позже экспертные разборы по этой теме прямо указывали: если в расчетном периоде аванса сотрудник был в отпуске, количество дней в документе Начисление зарплаты может рассчитываться некорректно.

Далее разработчики зарегистрировали ошибку с кодом 30180350. Ее суть формулируется так: если в расчетном периоде аванса сотрудник был в отпуске, количество дней в документе «Начисление зарплаты» с режимом «Аванс» рассчитывается некорректно. Позже было указано, что исправление вошло в релиз Бухгалтерия предприятия 3.0.156.30, а до обновления можно было применять патч EF_30180350.

Это и есть ключ к решению вопроса. В описанном примере не нужно искать экзотические причины, переписывать начисления или срочно менять графики сотрудников без проверки версии. Сначала нужно признать, что на релизе 3.0.155.23 программа действительно могла ошибаться при расчете рабочих дней аванса в связке с отпуском и отпуском без сохранения оплаты.

Как проверить, что проблема вызвана именно этой ошибкой

Разберем по шагам, как убедиться, что перед нами именно известная ошибка, а не обычная настройка учета.

1. Проверьте релиз программы. Если используется Бухгалтерия предприятия 3.0.155.23 или близкий релиз до исправления, вероятность очень высокая.
2. Проверьте вид ситуации. Если сотрудник в первой половине месяца работает часть дней, а затем уходит в отпуск или в отпуск без сохранения оплаты, и именно после этого число отработанных дней резко уменьшается, это характерный признак.
3. Сравните расчет вручную. Возьмите производственный календарь, график сотрудника и посчитайте рабочие дни до даты начала отпуска. Если ручной расчет дает одно значение, а документ Начисление зарплаты в режиме Аванс показывает меньше — симптом совпадает.
4. Проверьте, нет ли дополнительных невыходов. Если больничных, прогулов, простоев и других документов нет, а разница сохраняется, версия с программной ошибкой становится основной.
5. Посмотрите, что произойдет после обновления или установки патча. Если на исправленном релизе после перепроведения расчет становится правильным, причина подтверждается окончательно.

Именно такой подход позволяет не тратить время на бессмысленную перенастройку всей зарплатной подсистемы, когда причина уже известна и описана разработчиком.

Как правильно посчитать дни в таких примерах вручную

Посмотрим на пример ручной логики, потому что она нужна и для проверки программы, и для временной корректировки аванса.

Пример 1. Сотрудник уходит в отпуск без сохранения заработной платы с 16.08.2024 по 26.08.2024. Если у сотрудника обычная пятидневка, то до 16 августа включительно нужно определить, какие рабочие дни первой половины месяца фактически отработаны по графику. Если отпуск начинается с 16 числа, то день начала отпуска уже не должен считаться рабочим днем по оплате оклада. Следовательно, в расчет попадают рабочие дни с 1 по 15 августа включительно, за исключением выходных по графику.

Пример 2. Сотрудник уходит в отпуск с 12.08.2024 по 08.09.2024. В таком случае в первую половину августа должны попасть только рабочие дни с 1 по 11 августа, но с учетом того, что 10 и 11 августа — это выходные при стандартной пятидневке. Значит, оплачиваемыми рабочими днями обычно будут рабочие даты с 1 по 9 августа.

Почему же пользователь может ожидать 7 дней, а программа ставит 4? Потому что в ошибочном релизе часть фактически отработанных дней могла исключаться из расчета из-за неверной обработки периода отпуска при заполнении аванса.

Здесь важно подчеркнуть: корректное количество дней всегда нужно проверять именно по графику сотрудника, а не только по календарным границам отпуска. Если график сменный, суммированный или индивидуальный, ручная проверка выполняется по установленному графику, а не по общей пятидневке.

Первое решение: обновите программу до версии, в которой ошибка исправлена

Это основное и правильное решение. Если база работает на версии 3.0.155.23, нужно перейти на релиз, в котором ошибка уже исправлена. Для данной проблемы в экспертных материалах указывалось исправление в версии 3.0.156.30. Если полноценное обновление по каким-то причинам временно недоступно, имеет смысл проверить возможность установки патча EF_30180350.

Рассмотрим подробнее, что даст обновление:

1. программа начнет корректнее определять отработанные дни за первую половину месяца при наличии отпусков;
2. снизится риск ручных исправлений в каждом отдельном документе;
3. уменьшится вероятность искажения суммы аванса и последующих удержаний НДФЛ;
4. станет проще сопровождать зарплатный учет без накопления локальных ручных правок.

После обновления не ограничивайтесь только установкой релиза. Разберем, что нужно сделать дополнительно:

1. откройте кадровые и расчетные документы за проблемный месяц;
2. проверьте проведение документов Отпуск, отпусков без оплаты и документа Начисление зарплаты;
3. выполните перепроведение в правильной последовательности;
4. заново проверьте число отработанных дней в документе аванса;
5. убедитесь, что итоговая сумма совпадает с ручным расчетом по графику.

Важно: если до обновления вы уже вручную исправили количество дней или сумму, программа не обязана автоматически все пересчитать так, как вы ожидаете. Нужно внимательно контролировать, нажимаете ли вы кнопку Заполнить повторно и не перезаписываете ли ручную корректировку.

Второе решение: до обновления скорректируйте аванс вручную

Если обновить программу сразу нельзя, временно примените ручную корректировку. Это допустимый рабочий вариант, когда известна ошибка релиза и нужно вовремя выплатить сотрудникам аванс.

Разберем по шагам безопасный порядок действий:

1. Создайте документ Начисление зарплаты за нужный месяц.
2. Установите переключатель Аванс.
3. Выполните автоматическое заполнение документа.
4. Сравните количество дней, подставленное программой, с ручным расчетом по графику.
5. Если дни занижены, вручную скорректируйте показатель в документе или сумму начисления, в зависимости от того, какие поля доступны для редактирования в вашей настройке.
6. После ручной корректировки не запускайте повторно команду Заполнить, иначе программа может снова подставить ошибочное значение.
7. Сформируйте ведомость на выплату уже на основании проверенного документа.

Это временное решение не устраняет причину, но позволяет корректно выплатить деньги сотруднику до обновления релиза.

Что важно учесть: ручная правка аванса требует дисциплины. Если в базе несколько бухгалтеров или расчетчиков, нужно заранее договориться, что проблемные документы нельзя автоматически перезаполнять до установки исправления.

Третье решение: перепроведите документы после обновления, если ошибка уже попала в регистры

Рассмотрим ситуацию, когда база уже обновлена, но цифры в документах все равно выглядят неправильно. Такое возможно, если ошибочный расчет уже был записан в регистры до обновления, а затем документы остались неперепроведенными.

В этом случае одних слов “мы обновились” недостаточно. Нужно пройти техническую часть исправления до конца.

Рекомендуемый порядок такой:

1. проверьте, что новый релиз действительно установлен; при наличии нескольких баз задачу можно автоматизировать с помощью инструмента для фонового обновления конфигураций 1С.
2. уточните, нет ли локального патча, который нужно дополнительно активировать;
3. откройте документы отсутствий сотрудника за проблемный период;
4. перепроведите документы отпусков и отпусков без оплаты;
5. перепроведите Начисление зарплаты за первую половину месяца;
6. пересоздайте или перепроведите ведомость на выплату, если она уже была сформирована ранее;
7. сверьте расчет по сотруднику в отчетах по зарплате и НДФЛ.

На практике после перепроведения ошибка часто перестает проявляться. Это связано с тем, что документ пересчитывается уже по исправленному алгоритму.

Что проверить, если после обновления расчет все равно кажется неверным

Хотя в рассматриваемом случае основная причина — ошибка релиза, не будем ограничиваться только одним объяснением. Посмотрим, какие дополнительные проверки обязательно сделать, чтобы исключить сопутствующие проблемы.

1. Проведение документа отсутствия. Документ Отпуск или отпуск без сохранения оплаты должен быть проведен корректно и иметь правильные даты.
2. Месяц документа. В документе Начисление зарплаты должен быть указан именно тот месяц, за который считается аванс.
3. График работы сотрудника. Если у сотрудника индивидуальный или сменный график, количество дней нельзя проверять по общему производственному календарю без учета графика.
4. Вид начисления. Для сотрудников на окладе обычно используется начисление, которое рассчитывается пропорционально отработанным дням или часам. Если вид начисления настроен нестандартно, это тоже влияет на расчет.
5. Неактуальность данных учета. Если программа сообщает, что данные учета неактуальны, нужно выполнить актуализацию или перепроведение, чтобы расчеты брались из согласованного состояния базы.
6. Ручные корректировки. Если ранее документ уже исправляли вручную, старые правки могут конфликтовать с новым автоматическим расчетом.

Именно поэтому после обновления важно не просто открыть документ и посмотреть цифру, а пройти полноценную контрольную цепочку.

Какие объекты 1С и механизмы здесь наиболее важны

Теперь систематизируем объекты программы, которые участвуют в решении вопроса. Это пригодится и бухгалтеру, и специалисту сопровождения 1С.

1. Начисление зарплаты — основной документ, которым в БП 3.0 формируется расчет за первую половину месяца и окончательный расчет.
2. Аванс — режим документа Начисление зарплаты, при котором программа определяет оплату за первую половину месяца.
3. Отпуск — документ, влияющий на расчет невыходов и времени.
4. Начисление вида Оплата по окладу или Оплата по окладу, пропорционально отработанным дням — именно оно использует норму времени и количество фактически отработанных дней.
5. Ведомость в банк или Ведомость в кассу — документы выплаты, которые зависят от корректности расчета аванса.
6. Подробный анализ НДФЛ по сотруднику — полезный отчет, если после исправления аванса появились вопросы по удержанию налога.
7. Механизм перепроведения документов и актуализации данных учета — нужен, если ошибка уже повлияла на регистры.

Если в организации зарплатный контур в Бухгалтерии используется активно, именно эти объекты нужно проверять в первую очередь.

Как влияет ошибка на сумму аванса и почему это важно не только для дней

Может показаться, что ошибка касается только числа дней в колонке документа. На самом деле последствия шире. Если программа занижает отработанные дни, то она автоматически:

1. занижает сумму аванса;
2. искажает расчет дохода сотрудника за первую половину месяца;
3. может повлиять на сумму удерживаемого НДФЛ в зависимости от последовательности выплат;
4. создает расхождения между ожиданием бухгалтера и фактическими ведомостями на выплату.

Поэтому исправлять нужно не только “красивую цифру” в графе дней, но и сам расчет. Иначе в конце месяца могут появиться дополнительные вопросы: почему сумма к выплате не совпадает, почему налог удерживается не так, почему остатки по сотруднику выглядят странно.

Что делать с уже рассчитанными документами за прошлый период

Разберем по шагам практический подход, если ошибка уже попала в августовские документы, а месяц частично закрыт.

1. Сначала определите, были ли деньги уже выплачены сотруднику по ошибочному расчету.
2. Если выплата еще не произведена, проще всего исправить документ начисления и заново сформировать ведомость.
3. Если выплата уже произведена, оцените сумму отклонения. Далее либо внесите корректировки в текущем периоде, либо, если учетная политика и внутренние правила это допускают, оставьте выравнивание на окончательный расчет месяца.
4. После обновления программы не пересчитывайте бездумно все подряд. Сначала проверьте, не приведет ли перерасчет к расхождению с уже выплаченными суммами.
5. По окончании месяца обязательно сверьте итоговую сумму начислений, удержаний и выплаты по сотруднику.

Здесь нет универсальной кнопки “исправить все автоматически”. Даже если ошибка известна, уже проведенные расчеты нужно анализировать с учетом того, были ли выплаты и какой период уже закрыт.

Нужно ли менять настройки начисления или графики

В большинстве случаев — нет, не нужно. Это важный практический вывод. Когда бухгалтер видит неправильное количество дней, первое желание — срочно лезть в настройки графика, менять начисление, переписывать кадровые документы или создавать собственные обходные схемы. В рассматриваемой ситуации такой подход скорее навредит.

Если признаки совпадают с известной ошибкой релиза, не стоит без необходимости:

1. создавать новый вид начисления вместо штатного;
2. менять график работы сотрудника только ради одного месяца;
3. переводить расчет с дней на часы без методической причины;
4. вносить ручные правки в большое количество прошлых документов без плана.

Сначала обновите программу или примените патч. И только если проблема останется после исправления релиза, тогда уже имеет смысл анализировать настройки глубже.

Нужен ли здесь программный код 1С

В самой теме практического пользовательского обсуждения программный код не приводился, и для решения именно этой задачи он не требуется. Рассматриваемая проблема относится не к пользовательской доработке, а к типовому механизму расчета зарплаты в БП 3.0. Поэтому основными средствами решения являются:

1. обновление типовой конфигурации;
2. установка патча;
3. перепроведение документов;
4. ручная корректировка проблемного документа до момента обновления.

Если же базу сопровождает разработчик и требуется техническая диагностика, он уже может дополнительно анализировать движения документов, регистры расчета и поведение типового алгоритма заполнения документа Начисление зарплаты. Но для обычного рабочего решения со стороны бухгалтера это, как правило, не нужно.

Практический алгоритм действий для бухгалтера

Соберем все в один рабочий порядок, чтобы можно было применить его сразу.

1. Проверьте версию программы. Если это 3.0.155.23, считайте ошибку релиза основной версией причины.
2. Посчитайте отработанные дни вручную. Возьмите график сотрудника и определите рабочие дни до начала отпуска или отпуска без оплаты.
3. Сравните результат с документом Начисление зарплаты в режиме Аванс.
4. Если есть расхождение, скорректируйте расчет вручную, чтобы выплатить правильный аванс.
5. Не выполняйте повторное автозаполнение документа после ручной правки.
6. Обновите программу до релиза, где ошибка исправлена, либо установите патч EF_30180350.
7. После обновления перепроведите документы отсутствий и начислений за проблемный период.
8. Проверьте ведомости и НДФЛ, если по сотруднику уже были выплаты.
9. Сверьте итог месяца, чтобы убедиться, что ошибка не потянула за собой перекосы по зарплате и налогу.

Именно такой порядок позволяет решить проблему аккуратно и без лишних переделок в базе.

Как сформулировать итог по описанной ситуации

Подведем итог. В описанном случае 1С неверно учитывает количество отработанных дней не потому, что бухгалтер неправильно оформил отпуск без сохранения зарплаты, а потому что в используемом релизе БП 3.0 есть известная ошибка расчета аванса при наличии отпусков. Для релиза 3.0.155.23 это полностью укладывается в известную проблему, зарегистрированную разработчиком. Исправление было включено в версию 3.0.156.30, также выпускался патч EF_30180350.

Следовательно, оптимальная стратегия такая:

1. не искать ошибку там, где ее нет;
2. не ломать штатные настройки начислений без необходимости;
3. временно корректировать аванс вручную;
4. как можно быстрее обновить конфигурацию;
5. после обновления перепроверить и перепровести проблемные документы.

Если действовать именно так, можно быстро восстановить корректный расчет и избежать дальнейших расхождений по зарплате и НДФЛ.

Информация носит справочный характер.