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

← На главную

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

Постановка задачи и анализ ситуации

Типичный сценарий: клиент заказывает товар на 900 рублей, но просит выписать счет и накладную на 1000 рублей. Разница в 100 рублей должна где-то аккумулироваться (например, как долг перед посредником) или просто фиксироваться для управленческой отчетности, при этом она не должна искажать официальную выручку предприятия в регламентированном учете.

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

Вариант 1. Использование дополнительных реквизитов и внешних печатных форм

Это самый «щадящий» метод для типовой конфигурации. Мы не меняем структуру метаданных в основной конфигурации, а используем механизм ДополнительныеСведения или ДополнительныеРеквизиты.

Алгоритм реализации следующий:

Создаем дополнительный реквизит для документа Заказ клиента (например, «ПроцентНаценкиДляПечати» или «ФиктивнаяСумма»).
Разрабатываем внешнюю печатную форму (ВПФ). В логике формирования печатной формы прописываем алгоритм пересчета: ЦенаВПечатнойФорме = РеальнаяЦена * (1 + Наценка).
Для удобства менеджеров можно добавить расширение, которое выводит этот доп. реквизит непосредственно на форму заказа.

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

Вариант 2. Создание подчиненного фиктивного документа

Этот метод предполагает использование двух документов Заказ клиента: один — реальный (проведенный), второй — фиктивный (непроведенный, только для печати). Рассмотрим пошагово, как организовать эту связь:

В расширении добавим в документ Заказ клиента реквизит ФиктивныйЗаказ с типом ДокументСсылка.ЗаказКлиента. При создании фиктивного документа он записывается, но не проводится, чтобы не делать движений по регистрам накопления. Печать всех форм (Счет, УПД) в этом случае выполняется из этого «теневого» документа.

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


// Пример логики в расширении формы заказа
&НаКлиенте
Процедура СоздатьФиктивныйДокумент(Команда)
    Если Объект.Ссылка.Пустая() Тогда
        Предупреждение("Сначала необходимо записать основной заказ!");
        Возврат;
    КонецЕсли;
    
    // Вызов серверной функции копирования
    СоздатьФиктивныйНаСервере();
КонецПроцедуры

&НаСервере
Процедура СоздатьФиктивныйНаСервере()
    ФиктОбъект = Объект.Ссылка.Скопировать();
    ФиктОбъект.Дата = ТекущаяДата();
    ФиктОбъект.Комментарий = "ФИКТИВНЫЙ ДЛЯ ПЕЧАТИ. Основание: " + Объект.Ссылка;
    
    // Здесь реализуем логику изменения цен
    Для Каждого СтрокаТЧ Из ФиктОбъект.Товары Цикл
        СтрокаТЧ.Цена = СтрокаТЧ.Цена * 1.1; // Условно +10%
        СтрокаТЧ.Сумма = СтрокаТЧ.Цена * СтрокаТЧ.Количество;
    КонецЦикла;
    
    ФиктОбъект.Записать(РежимЗаписиДокумента.Запись);
    
    // Привязываем к основному документу
    ОсновнойОбъект = Объект.Ссылка.ПолучитьОбъект();
    ОсновнойОбъект.ДополнительныеРеквизиты.Очистить(); // Если используем доп. реквизит для связи
    // Или используем добавленный через расширение реквизит
    ОсновнойОбъект.СсылкаНаФиктивныйЗаказ = ФиктОбъект.Ссылка;
    ОсновнойОбъект.Записать();
КонецПроцедуры

Вариант 3. Реализация через специализированное АРМ менеджера

Если специфика бизнеса требует массовой работы с такими заказами, создание документов вручную станет «узким горлышком». Оптимальным решением будет создание АРМ (Автоматизированного рабочего места). Разберем этот вариант как наиболее комплексный.

АРМ менеджера представляет собой обработку, которая визуально полностью повторяет форму заказа, но содержит дополнительные колонки: Цена факт, Цена фикт, Разница, % Вознаграждения.

При нажатии кнопки «Оформить пакет документов» система автоматически генерирует:

Реальный заказ клиента: проводится, является основанием для склада и бухгалтерии.
Фиктивный заказ клиента: не проводится, используется только для печати и хранения данных, которые клиент должен видеть в документах.
Документ «Приобретение услуг и прочих активов»: (опционально) на сумму разницы. В качестве поставщика указывается посредник. Это позволяет сразу сформировать задолженность перед агентом в типовом механизме взаиморасчетов.

Проанализируем ситуацию с редактированием: чтобы данные не «разъехались», редактирование таких документов должно происходить только через это АРМ. При открытии стандартной формы документа система должна предлагать перейти в АРМ.

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


&НаСервере
Процедура ПриЧтенииНаСервере(ТекущийОбъект)
    // Проверяем, является ли документ частью "пакета"
    Если ТекущийОбъект.ЭтоСпецЗаказ Тогда
        // Блокируем стандартные реквизиты для редактирования
        ЭтаФорма.ТолькоПросмотр = Истина;
        // Выводим сообщение со ссылкой на АРМ
    КонецЕсли;
КонецПроцедуры

Вариант 4. Агентская схема (Типовой функционал)

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

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

Важные рекомендации по безопасности и учету

Выполняя подобные доработки, следует помнить о нескольких критических моментах:

Разграничение прав доступа (RLS): фиктивные суммы и данные о посредниках не должны быть видны рядовым сотрудникам бухгалтерии или склада. Используйте роли и механизм RLS для ограничения видимости доп. реквизитов.
Версионирование объектов: если вы используете схему с временным изменением суммы (Вариант 8 из обсуждения форума), помните, что механизм версионирования сохранит все промежуточные состояния. При проверке это может вызвать вопросы.
Синхронизация: при изменении количества товаров в реальном заказе (например, при частичной отгрузке), необходимо программно обновлять данные в фиктивном документе, чтобы печатные формы оставались актуальными.

Рассмотренные методы позволяют гибко настроить систему под требования заказчика. Для небольших правок достаточно Варианта 1. Для серьезной автоматизации с контролем взаиморасчетов с посредниками лучше всего подходит Вариант 3 (АРМ), который обеспечивает целостность данных и удобство работы пользователя в режиме «одного окна».