Почему в 1С 7.7 возникают отрицательные остатки по партиям при продаже через кассовый терминал и как это исправить

При работе с аптечными и розничными конфигурациями на базе 1С 7.7 (например, еФарма или решения на базе «Кассир Штрих-М») технические специалисты часто сталкиваются с ситуацией, когда после загрузки продаж из кассы по отдельным партиям номенклатуры образуются отрицательные остатки. При этом суммарное количество товара на складе может оставаться положительным, однако партионный учет оказывается нарушенным.

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

Анализ проблемы и причина появления отрицательных остатков

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

Сбой происходит по следующей схеме:

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

При проведении документа Чек происходят движения по регистру Партии. Поскольку штрихкод привязан к конкретной партии, на которой числился остаток всего в 1 штуку, документ «молча» списывает 20 штук с этой партии. В результате на партии образуется остаток -19 штук, хотя остаток по другим партиям этого товара остался нетронутым.

Архитектура обмена данными в 1С 7.7 с кассовым ПО

Выясним, как устроена схема взаимодействия между основной базой учетной системы и фронт-офисом на кассовом терминале:

Синхронизация происходит в offline-режиме с помощью текстовых файлов обмена:

• Выгрузка в кассу: специальная обработка передает из основной базы в кассовый терминал текущие остатки, розничные цены, наименования и штрихкоды номенклатуры.
• Загрузка из кассы: обработка считывает с кассы файлы пробитых чеков и Z-отчетов. На основании этих данных в 1С 7.7 создаются документы Чек, Z-отчет и Закрытие смены.

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

Способы решения проблемы

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

Способ 1. Доработка алгоритма проведения документа «Чек» в 1С 7.7

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

Рассмотрим пример логики проверки и списания остатка в модуле проведения документа:

// Пример алгоритма списывания партий с автоподбором
ОстатокПоПартии = Регистр.Партии.СМОТРЕТЬОСТАТОК(Номенклатура, ВыбраннаяПартия);

Если ОстатокПоПартии >= КоличествоКCписанию Тогда
    // Остатка хватает на выбранной партии
    Регистр.Партии.Номенклатура = Номенклатура;
    Регистр.Партии.Партия = ВыбраннаяПартия;
    Регистр.Партии.Количество = КоличествоКCписанию;
    Регистр.Партии.ДвижениеРасходВыполнить();
Иначе
    // Списываем доступный остаток с текущей партии
    Недостаток = КоличествоКCписанию - ОстатокПоПартии;
    Если ОстатокПоПартии > 0 Тогда
        Регистр.Партии.Номенклатура = Номенклатура;
        Регистр.Партии.Партия = ВыбраннаяПартия;
        Регистр.Партии.Количество = ОстатокПоПартии;
        Регистр.Партии.ДвижениеРасходВыполнить();
    КонецЕсли;
    
    // Подбираем оставшееся количество с других партий номенклатуры (FIFO)
    ЗапросПартии = СоздатьОбъект("Запрос");
    // Выполняем подбор остальных партий с положительным остатком
    // и списываем Недостаток по найденным партиям
КонецЕсли;

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

Способ 2. Организационный запрет на ввод количества ручками

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

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

Особенности работы с базами DBF и восстановление последовательности

Проанализируем еще одну причину «плавающих» остатков. В файловом режиме 1С 7.7 (базы формата DBF) при частой загрузке данных могут повреждаться индексные файлы (файлы с расширением .cdx). Это приводит к тому, что отчеты показывают временный минус, который «исчезает» или меняется при перепроведении документов.

Для поддержания порядка в остатках рекомендуем выполнить следующие действия:

• Регулярно проводить процедуру «Тестирование и исправление ключей и индексов» через Конфигуратор (пункт меню Администрирование — Тестирование и исправление информационной базы).
• Контролировать точку последовательности документов и выполнять перепроведение документов за период после завершения загрузки продаж за смену.