Представим типичный рабочий сценарий в конфигурации «1С:Управление торговлей», редакция 10.3. Кассир или менеджер оформляет оплату от покупателя. В системе уже зарегистрировано несколько документов Реализация товаров и услуг (РТУ) по одному и тому же контрагенту, например:
Общая сумма задолженности клиента составляет 1650 рублей. Пользователь открывает РТУ №3 (на сумму 600 рублей) и пытается создать на его основании документ Приходный кассовый ордер (ПКО). Ожидается, что в ПКО автоматически подставится сумма 600 рублей. Однако программа подставляет общую сумму долга — 1650 рублей. Давайте подробно разберем, почему типовой алгоритм ведет себя именно так, и рассмотрим три практических способа решения этой проблемы.
Для того чтобы понять, откуда берется эта сумма, обратимся к программному коду конфигурации. Вся логика заполнения ПКО при вводе на основании сосредоточена в модуле документа в процедуре ОбработкаЗаполнения(Основание). Проанализируем ключевой фрагмент этой процедуры, отвечающий за обработку ввода на основании РТУ:
ИначеЕсли ТипЗнч(Основание) = Тип("ДокументСсылка.РеализацияТоваровУслуг") или ТипЗнч(Основание) = Тип("ДокументСсылка.ОтчетКомиссионераОПродажах") Тогда
СтрокаПлатеж = РасшифровкаПлатежа.Добавить;
ВидОперации = Перечисления.ВидыОперацийПКО.ОплатаПокупателя;
Контрагент = Основание.Contragent; // Контрагент из накладной
СтрокаПлатеж.ДоговорКонтрагента = Основание.ДоговорКонтрагента;
// ... Заполнение курсов валют и ставок НДС ...
Если ДоговорКонтрагента.ВестиПоДокументамРасчетовСКонтрагентом Тогда
СтрокаПлатеж.ДокументРасчетовСКонтрагентом = Основание;
Если Основание.Проведен Тогда
стрСпособЗаполнения = "По взаиморасчетам";
Иначе
стрСпособЗаполнения = "По сумме документа";
КонецЕсли;
Иначе
Если Основание.Проведен Тогда
стрСпособЗаполнения = "По взаиморасчетам";
Иначе
стрСпособЗаполнения = "По сумме документа";
КонецЕсли;
КонецЕсли;
Обратите внимание на развилку условий. Программа проверяет, проведен ли документ-основание (наша накладная):
стрСпособЗаполнения присваивается значение "По сумме документа". В этом случае ПКО заполнится ровно на сумму конкретной накладной."По взаиморасчетам".При выборе варианта "По взаиморасчетам" программа обращается к остаткам регистра накопления Взаиморасчеты с контрагентами. Метод пытается получить актуальный остаток долга по договору. И здесь ключевую роль играют настройки самого Договора контрагента:
Теперь, понимая внутреннюю архитектуру решения, мы можем выбрать наиболее подходящий вариант исправления ситуации.
Это самый правильный и методологически верный способ работы в системе 1С. Чтобы программа понимала, по какой именно накладной пришел платеж, необходимо изменить настройки детализации взаиморасчетов.
Выполним следующие шаги:
Важное предупреждение: Если по договору уже велся учет и были проведены документы, программа не позволит вам просто так включить этот флаг, поскольку это нарушит последовательность проведения и логику закрытия остатков. В таком случае рекомендуется закрыть старый договор и открыть для последующих отгрузок новый договор с правильной настройкой детализации.
После включения этой настройки даже проведенная накладная будет отдавать в ПКО только свою сумму долга (600 рублей), а не общий итог по контрагенту.
Если вам необходимо срочно выписать ПКО на точную сумму накладной, но вы не хотите менять настройки ведения договоров или дорабатывать код, можно воспользоваться особенностью работы типового алгоритма.
Давайте вспомним условие: Если Основание.Проведен Тогда ... Иначе стрСпособЗаполнения = "По сумме документа".
Следовательно, достаточно соблюдать следующую последовательность действий при продаже:
Реализация товаров и услуг, заполните табличную часть товарами.Приходный кассовый ордер. Так как накладная еще не проведена, программа заполнит ПКО строго по сумме этого документа (на 600 рублей).Этот способ отлично подходит для небольших компаний, где менеджер и кассир работают в тесном взаимодействии, а документы вводятся в реальном времени в момент визита покупателя.
Если бизнес-процессы компании требуют, чтобы ПКО всегда — при любых обстоятельствах и настройках договоров — заполнялся исключительно на сумму документа-основания, потребуется внести небольшое изменение в программный код.
Давайте откроем конфигуратор, найдем документ Приходный кассовый ордер, перейдем в его модуль и найдем процедуру ОбработкаЗаполнения. Нам нужно скорректировать условия выбора способа заполнения так, чтобы программа игнорировала проверку проведения документа-основания.
Найдем исходный фрагмент кода:
Если ДоговорКонтрагента.ВестиПоДокументамРасчетовСКонтрагентом Тогда
СтрокаПлатеж.ДокументРасчетовСКонтрагентом = Основание;
Если Основание.Проведен Тогда
стрСпособЗаполнения = "По взаиморасчетам";
Иначе
стрСпособЗаполнения = "По сумме документа";
КонецЕсли;
Иначе
Если Основание.Проведен Тогда
стрСпособЗаполнения = "По взаиморасчетам";
Иначе
стрСпособЗаполнения = "По сумме документа";
КонецЕсли;
КонецЕсли;
И заменим его на следующий вариант:
Если ДоговорКонтрагента.ВестиПоДокументамРасчетовСКонтрагентом Тогда
СтрокаПлатеж.ДокументРасчетовСКонтрагентом = Основание;
// Принудительно устанавливаем заполнение по сумме документа, игнорируя проведение
стрСпособЗаполнения = "По сумме документа";
Иначе
// Принудительно устанавливаем заполнение по сумме документа, игнорируя проведение
стрСпособЗаполнения = "По сумме документа";
КонецЕсли;
После этого изменения при вводе ПКО на основании реализации программа всегда будет брать сумму из реквизита СуммаДокумента накладной-основания.
Важные риски программного решения: Прежде чем внедрять эту доработку в рабочую базу, обязательно проанализируйте следующие последствия:
Выбирайте наиболее подходящий для вашей компании метод автоматизации и ведения взаиморасчетов. Для сохранения чистоты учета и возможности автоматических обновлений конфигурации мы рекомендуем использовать Способ №1.