◆IKORG
English

← Практика · 22 октября 2026

В 1С сбилась нумерация документов: грабли массовой загрузки

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

10 минут чтения1С

Когда в 1С сбивается нумерация, рука тянется найти настройку и поставить следующий номер на место. Но при массовом восстановлении в базу одновременно возвращаются старые документы, сотрудники создают новые, а обмен отправляет данные в бухгалтерию. Номера пересекаются, записи затираются, повторная загрузка добавляет двойников. Одной настройкой этот узел не распутать.

С этим столкнулись при восстановлении учёта транспортной компании: пять юрлиц, 1С на собственном сервере. Шифровальщик зашифровал сервер вместе с резервным диском в нём. Новый сервер подняли с чистого листа, рабочую отраслевую базу восстановили из копии примерно на конец апреля. Май–сентябрь оказались пустыми. Бухгалтерию тоже собирали заново: по книгам продаж, распознанным сканам и электронному документообороту. Дешифратора нет — учёт возвращали из сохранившихся источников.

Разберём ошибки этого восстановления: нумерацию, дубли рейсов, обмен, банковские поступления и временные файлы сервера. Полная история — в кейсе восстановления учёта после шифровальщика. Здесь главный вопрос практический: как вернуть документы и не получить вместе с ними новую головную боль.

Почему в 1С сбилась нумерация документов

В этой базе номер определялся как «максимум + 1» в пределах префикса, а нумерация шла в пределах года. Префикс складывался из двух букв организации и двух букв базы. Отдельного счётчика нет: следующий номер сдвигает только документ с бо́льшим номером. Подкрутить счётчик было бы удобно — осталось бы только его найти.

Пока сотрудник создаёт новый документ, загрузка возвращает записи за пропущенный период. Два потока встречаются в одной базе. Если сохранять старые номера одновременно с обычной работой, появляются совпадения.

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

Перед исправлением нужно выяснить:

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

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

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

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

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

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

Перед массовой загрузкой стоит согласовать:

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

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

Как в 1С найти дубли документов после восстановления

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

Для транспортной компании использовали понятный признак: одна машина с одним водителем не сделает два одинаковых рейса в одну дату. Найденных двойников и дубли пометили на удаление.

Ключевое здесь — «два одинаковых рейса». Одной машины и даты для вывода об ошибке мало. Автоматический поиск собирает подозрительные записи, а проверка устанавливает, повторяют ли они одну операцию.

Порядок разбора такой:

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

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

Как перенести реализации из бухгалтерии в рабочую базу

Восстановленная бухгалтерия стала источником для отраслевого учёта. Около 2 500 реализаций из 1С:Бухгалтерии превратили в заявки, акты и счета-фактуры рабочей базы, без ручной перепечатки.

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

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

Результат проверяют сопоставлением документов источника с созданными записями, отдельно разбирая пропуски и неоднозначные соответствия. Общее количество показывает объём работы; правильность связей приходится проверять отдельно.

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

Почему загрузка банковской выписки в 1С 8.3 оставляет долги

После заявок нужно было вернуть связь с деньгами. Около 1 250 банковских поступлений разобрали и привязали к заявкам. Надёжно, по номеру счёта из назначения платежа, нашлось около 960. Для остальных понадобились другие признаки.

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

Если заказчик указал не тот счёт, на одной заявке возникает переплата, на другой — недоплата. Деньги в учёте есть, а распределение расходится с фактическими расчётами. Поэтому загрузка банковской выписки в 1С 8.3 заканчивается проверкой привязок и остатков. Иначе руководитель увидит долг, причина которого — неверное назначение платежа.

В этом кейсе расхождения закрыли флагом «оплачено по акту сверки». Его установили у 339 заявок. Так в рабочей базе отразили результат сверки; для других конфигураций этот способ не универсален. Исходное назначение платежа при этом осталось прежним.

Когда автоматическое сопоставление даёт неоднозначный ответ, подключается человек. Одного совпадения суммы для распределения недостаточно.

Были и другие случаи. 19 платежей перепривязали с непроведённых или задвоенных заявок, разбивая оплату строками на несколько счетов. 41 заявку, созданную раньше «под оплату», провели по правилу руководителя: был платёж — заявку проводим. Четыре заявки провести не удалось из-за даты запрета изменения данных закрытого периода. Её стоит проверить до массовой загрузки.

При проверке выписки отдельно смотрят:

Переплату и недоплату полезно рассматривать вместе: у этих на вид разных проблем может быть общая причина.

Как проверить НДС после переноса документов

После восстановления документов и распределения оплат оставалась ещё одна задача: в 242 документах ставки НДС выровняли по бухгалтерии.

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

НДС стоит проверять вместе с составом документов, связями и оплатами. Позже, когда пользователи уже активно работают с восстановленными записями, расхождения разбирать сложнее.

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

Почему обработка загрузки перестала компилироваться

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

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

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

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

«Файл не обнаружен v8 tmp»: что проверить и при чём тут rphost

Ещё одна ловушка — временные файлы пользователя, под которым работает сервер 1С. Чистить их во время работы нельзя: приложению они могут быть нужны прямо сейчас. Уборка получается усердной, но несвоевременной.

В этом случае CRM выдавала ошибку «Файл не обнаружен …v8_*.tmp». Её устранял перезапуск рабочего процесса rphost.

Если вы ищете «rphost что это», речь о рабочем процессе сервера 1С. Он обслуживает работу пользователей и выполняет серверный код. Перезапуск нужно согласовывать с текущей работой, особенно во время загрузки документов.

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

Что проверить перед массовой загрузкой в 1С

Чек-лист связывает технический запуск с проверкой учёта. Пройти его лучше до того, как спорные решения превратятся в тысячи записей.

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

Частые вопросы

Можно ли просто поставить нужный следующий номер документа?

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

Одинаковые номера означают, что документы задвоились?

Это повод для проверки. Дубль операции определяют по содержанию и связям. В транспортном учёте искали одинаковые рейсы одной машины с одним водителем в одну дату.

Можно ли сразу удалить все найденные дубли?

Здесь дубли пометили на удаление. Перед окончательным решением проверяют связанные документы и оплаты. Разрушительных действий без решения руководителя не выполняли.

Почему после загрузки выписки заявка осталась неоплаченной?

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

Удалось ли расшифровать файлы после атаки?

Нет, дешифратора нет. Учёт восстанавливали из сохранившейся бухгалтерии, банковских поступлений и сканов отчётов водителей. Восстановление учёта и расшифровка файлов — разные задачи.

Разобраться с вашей базой?

IKORG помогает восстановить документы, найти дубли, проверить обмен и распределение оплат в 1С. Работу выполняет ИИ-агент Claude Code под контролем владельца студии. Изменения записываются в журнал, неоднозначные случаи проверяет человек, разрушительные действия требуют решения руководителя.

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