Как в УТ 11 реализовать выписку Реализаций товаров и услуг напрямую из рабочего места кассира (РМК)

В практике автоматизации торговых предприятий на базе 1С:Управление торговлей 11 (УТ 11) часто возникает запрос: «Как сделать так, чтобы продавец мог выписать и обычный чек, и оптовую накладную (Реализацию) из одного окна?». Это актуально для магазинов, которые работают как с физическими лицами, так и с юридическими. Традиционно в типовых конфигурациях эти процессы разделены: кассир работает в РМК, а менеджер — в журнале документов продажи. Разберем, как скрестить эти два мира, с какими трудностями придется столкнуться и какие пути решения существуют.

Почему это не реализовано в типовой конфигурации «из коробки»?

Проанализируем ситуацию с точки зрения архитектуры 1С. Документы ЧекККМ и РеализацияТоваровУслуг (РТУ) имеют принципиально разную природу:

1. Момент оплаты: Чек ККМ — это оперативный документ, который подразумевает мгновенную оплату. РТУ часто предполагает отсрочку платежа, работу по графикам или предварительные заказы.
2. Цнообразование: В рознице действуют фиксированные цены торговых залов, акции и бонусы. В опте (РТУ) цена может быть индивидуальной для каждого контрагента и зависеть от условий договора.
3. Юридическая значимость: Для РТУ требуется указание контрагента, договора и часто — печать комплекта документов (ТОРГ-12, УПД, Счет-фактура).

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

Вариант 1: Глубокая кастомизация интерфейса РМК

Рассмотрим вариант полной переработки рабочего места кассира. Основная цель здесь — создать единую «корзину» товаров, которая в конце оформления может превратиться либо в ЧекККМ, либо в РеализациюТоваровУслуг.

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

1. Пользователь наполняет корзину в стандартном или модифицированном интерфейсе подбора.
2. При нажатии кнопки «Оформить» система запрашивает тип покупателя.
3. Если выбран «Юр. лицо», система должна потребовать ввод ИНН или выбор контрагента.
4. Программа программно создает документ РеализацияТоваровУслуг, заполняет его данными из корзины и проводит.

Особое внимание стоит уделить вводу данных. Опытные разработчики рекомендуют заменять стандартные поля выбора справочника Контрагенты на текстовый поиск. Это позволяет кассиру быстро вбить ФИО или телефон, а системе — автоматически найти или создать карточку, не прерывая процесс продажи. Рассмотрим фрагмент кода для программного создания РТУ на основании данных из временной таблицы товаров:

// Пример заполнения Реализации из данных корзины
НоваяРеализация = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
НоваяРеализация.Дата = ТекущаяДата();
НоваяРеализация.Партнер = ВыбранныйПартнер;
НоваяРеализация.Контрагент = ВыбранныйКонтрагент;
НоваяРеализация.Организация = Объект.Организация;
НоваяРеализация.Склад = Объект.Склад;
НоваяРеализация.Валюта = Константы.ВалютаУправленческогоУчета.Получить();

Для Каждого СтрокаТовара Из Объект.Товары Цикл
    НоваяСтрока = НоваяРеализация.Товары.Добавить();
    ЗаполнитьЗначенияСвойств(НоваяСтрока, СтрокаТовара);
    // Дополнительная логика пересчета цен под вид цен контрагента
    ОбработкаТабличныхЧастейКлиентСервер.ПриИзмененииНоменклатурыВТабличнойЧасти(НоваяСтрока, НоваяРеализация);
КонецЦикла;

НоваяРеализация.Записать(РежимЗаписиДокумента.Проведение);

Вариант 2: Использование Заказа клиента как универсального буфера

Если разработка собственного РМК кажется слишком трудоемкой (а на форумах отмечают, что на полную отладку такого решения может уйти до года), стоит рассмотреть схему «Заказ как основа». Этот метод считается более стабильным для УТ 11.

Суть метода заключается в том, что в РМК добавляется возможность создания Заказа клиента. В современных версиях 1С:Управление торговлей (начиная с 11.5) этот функционал частично присутствует в «Новом РМК».

Рассмотрим шаги этого процесса:

1. Продавец подбирает товар в стандартном РМК.
2. Вместо пробития чека выбирается опция «Оформить заказ».
3. Система фиксирует резервы и цены.
4. На основании этого заказа в фоновом режиме или в отдельном окне менеджер (или тот же продавец) формирует Реализацию товаров и услуг.

Преимущество этого подхода в том, что сохраняется вся типовая логика учета: контроль остатков, работа с договорами и зачет авансов. Нам не нужно «изобретать велосипед» в части проведения документов.

Соблюдение требований ФФД 1.1 при продаже юрлицам

Выясним причину, по которой просто выписать накладную недостаточно. Согласно 54-ФЗ, при расчетах между организациями наличными или по карте, кассир обязан выдать чек, в котором указаны ИНН и наименование покупателя-организации (теги 1227 и 1228).

При реализации этой задачи в РМК необходимо предусмотреть передачу этих данных в фискальный регистратор. В коде это выглядит примерно так:

// Добавление данных покупателя для чека (ФФД 1.1)
ПараметрыЧека = Новый Структура;
ПараметрыЧека.Вставить("Покупатель", СокрЛП(Объект.Контрагент.НаименованиеПолное));
ПараметрыЧека.Вставить("ИННПокупателя", Объект.Контрагент.ИНН);

// Далее эти параметры передаются в типовой механизм печати чека
МенеджерОборудованияКлиент.ВыполнитьКомандуПечатиЧека(УникальныйИдентификатор, ПараметрыЧека);

Важный момент: Если вы оформляете РТУ, то чек должен пробиваться не как «Чек ККМ», а как фискальный чек на основании документа расчетов (Реализации). В УТ 11 для этого используется механизм «Предъявление чека к оплате».

Проблемы и «подводные камни»

Проанализируем основные сложности, с которыми сталкиваются программисты при реализации единого РМК:

• Частичная оплата: РТУ позволяет оплатить товар частично, в то время как стандартный Чек ККМ в РМК настроен на полную оплату здесь и сейчас. Придется переписывать логику распределения платежей.
• Возвраты: Возврат по чеку и возврат от клиента по РТУ — это разные бизнес-процессы. Объединив фронт-офис, вам придется объединять и механизмы возвратов, что тянет за собой сложную цепочку корректировок.
• Производительность: Динамические списки и подписки на события при создании сложных документов (РТУ + Счет-фактура) могут замедлять работу кассира, создавая очереди.
• Человеческий фактор: Если дать кассиру возможность свободного ввода ФИО клиента текстом, справочник Контрагенты быстро заполнится дублями («Иванов И.И.», «Иванов Иван», «Иванов Иван Иванович»). Необходимо внедрять алгоритмы нечеткого поиска.

Рекомендации по реализации

Подведем итог. Если перед вами стоит задача объединить РТУ и чеки в одном окне, придерживайтесь следующего плана:

1. Используйте расширения: Не меняйте типовую конфигурацию. Все изменения формы РМК и логики проведения лучше вынести в расширение, чтобы сохранить возможность легкого обновления УТ 11.
2. Автоматизируйте поиск по ИНН: Интегрируйте сервис 1С:Контрагент прямо в форму РМК. Кассир вводит ИНН — система сама создает карточку и договор. Это сэкономит время и исключит ошибки.
3. Разделите интерфейсы логически: Оставьте стандартное РМК для быстрых розничных продаж, а для «сложных» клиентов добавьте кнопку переключения режима, которая будет подменять доступные поля и алгоритм закрытия сделки.
4. Тестируйте печатные формы: Убедитесь, что при создании РТУ из РМК принтер документов (обычный А4) и фискальный регистратор работают синхронно и не блокируют друг друга.

Разработка единого РМК — это не просто «добавление кнопки», а серьезное изменение бизнес-процесса. Однако при правильном подходе это позволяет значительно сократить расходы на обучение персонала и ускорить обслуживание клиентов в торговых точках смешанного типа.