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