Заказ клиента без реализации в 1С: деньги видны, а склада нет

Заказ клиента в 1С попадает в отчёт о продажах и показывает сумму сделки сразу после оформления, а физический остаток на складе списывается только документом «Реализация товаров и услуг». Пока эта проводка не сделана, деньги в системе есть, а товара на складе нет — разрыв возникает из-за схемы резервирования, забытой отгрузки или сбоя интеграции. Исправляется проверкой настроек резерва и регламента склада.

Почему в 1С заказ клиента «зависает» без реализации

Отдел продаж оптовой компании на 60 позициях номенклатуры закрывает месяц. Менеджер оформляет заказ клиента на 340 000 рублей 28 числа вечером — товар в наличии, клиент внёс аванс, и в отчёте руководителя сумма сразу встаёт в план продаж этого месяца. Утром 29-го кладовщик получает заявку на сборку и не находит половину позиций: по документам они зарезервированы, но физически стоят на полке в открытом доступе, и час назад их же отгрузили другому клиенту, который просто зашёл раньше.

Причина не в кладовщике и не в человеческой невнимательности. В 1С:Управление торговлей и 1С:ERP заказ клиента резервирует товар только если в настройках выбрана схема с жёстким резервом по конкретному складу, а не мягкая схема без физической привязки к остаткам — в терминах конфигурации это разница между «Отгрузка» и «Заказ» на уровне справочника складов. Компания из примера работала по схеме, унаследованной с внедрения три года назад, когда склад был один и путаницы не возникало в принципе — заказ и остаток совпадали автоматически. Но склад давно распался на три: розничный, оптовый, транзитный, — а логика резерва осталась прежней. Заказ отражает сумму в финансовых отчётах и в дебиторской задолженности, но не блокирует остаток ни на одном конкретном складе, потому что резерв считается «по организации в целом», а не по месту хранения.

Поэтому в обороте видно 340 000 рублей ожидаемой выручки, а на складе — ничего конкретного под этот заказ. Если не разобраться, компания теряет не абстрактную эффективность, а вполне конкретные деньги: повторную отгрузку одного и того же товара двум разным клиентам, штраф за срыв срока по контракту с оптовым покупателем, аванс, который приходится возвращать после того, как выясняется, что товара физически нет, и рабочий день менеджера, потраченный на разбор жалобы вместо новых продаж. В компаниях с оборотом от нескольких миллионов рублей в месяц такие эпизоды повторяются не раз в год, а еженедельно — просто до поры до времени их гасят вручную, пока кто-то из менеджеров не забудет позвонить и извиниться вовремя. А там, где заказы идут потоком через нескольких менеджеров одновременно, разрыв не видно вообще до конца месяца, когда бухгалтерия сверяет план с фактом и обнаруживает, что часть «проданного» товара физически лежит на складе или, наоборот, отгружена без документа.

Где искать разрыв между заказом и реализацией

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

• ✓Схема резерва в документе «Заказ клиента». У каждой позиции есть статус: резерв на складе, заказано поставщику или без резерва. Если по умолчанию стоит последний вариант, товар в отчётах числится проданным, а на складе доступен для любого другого заказа, оформленного позже.
• ✓Регламент склада. Кто и когда создаёт документ «Реализация товаров и услуг» на основании заказа — автоматически по расписанию, вручную по факту отгрузки или через бизнес-процесс. Если ответственного за этот шаг формально нет, заказы копятся неделями.
• ✓Интеграция с сайтом или маркетплейсом. Заказы из обмена данными иногда создаются без привязки к конкретному складу, потому что правило обмена писали под старую структуру и не обновили после доработки интернет-магазина или открытия нового филиала.

Как исправить: пошагово по схеме резерва и отгрузке

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

Быстрое исправление

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

Системное исправление

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

Что делать, если ошибка повторяется

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

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

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

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

Как предотвратить повторение проблемы

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

• ✓Ежедневный контрольный отчёт «заказы к отгрузке, просроченные более суток» — рабочий инструмент кладовщика и менеджера, который занимает пять минут в начале дня и сразу показывает, где застряла отгрузка.
• ✓Закреплённая ответственность за создание реализации: либо это делает автоматика через бизнес-процесс, либо конкретный сотрудник, у которого шаг прописан в должностной инструкции, а не решается по ситуации.
• ✓Технический аудит после любых структурных изменений — новый склад, новое юрлицо, новая интеграция с сайтом, потому что именно в такие моменты схема резерва чаще всего перестаёт совпадать с реальной структурой бизнеса.

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

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

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

Как понять, что заказ клиента завис без реализации?

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

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

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

Сколько стоит аудит и исправление схемы резервирования?

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

Обязательно ли переходить на 1С:ERP, чтобы решить проблему?

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

Что делать, если разрыв возникает из-за заказов с сайта?

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