Постановка задачи
Столкнулись с довольно специфической ситуацией в 1С:Бухгалтерии предприятия 3.0.
У клиента создается несколько документов «Отражение НДС к вычету» на основании разных приобретений.
Для каждого из них необходимо зарегистрировать полученный счет-фактуру.
При этом поставщик может передать документы, у которых совпадают:
-
контрагент;
-
номер счета-фактуры;
-
дата счета-фактуры.
Но суммы операций разные.
Например, первое «Отражение НДС к вычету»:
Контрагент: ООО "Поставщик"
Номер входящего СФ: 125
Дата входящего СФ: 01.09.2026
Сумма документа: 100 000 руб.
Второе:
Контрагент: ООО "Поставщик"
Номер входящего СФ: 125
Дата входящего СФ: 01.09.2026
Сумма документа: 75 000 руб.
Пользователь ожидает получить два самостоятельных документа:
Счет-фактура полученный №125 от 01.09.2026
Сумма: 100 000 руб.
Основание: Отражение НДС к вычету №1
и
Счет-фактура полученный №125 от 01.09.2026
Сумма: 75 000 руб.
Основание: Отражение НДС к вычету №2
Однако при регистрации второго документа Бухгалтерия находит уже существующий счет-фактуру №125 от 01.09.2026 и добавляет новое основание в него.
В результате вместо двух счетов-фактур получается один документ с несколькими основаниями.
Это ошибка или штатное поведение?
Это не случайная ошибка интерфейса.
В типовой Бухгалтерии предусмотрен сценарий, когда один счет-фактура поставщика относится сразу к нескольким документам приобретения.
Поэтому при регистрации нового счета-фактуры программа сначала пытается найти уже существующий документ с подходящими реквизитами.
Если такой счет-фактура найден, новый документ создавать не требуется. Программа добавляет еще одно основание в существующий.
Для большинства стандартных ситуаций это правильное поведение.
Проблема возникает, если в конкретном учете одинаковые:
Контрагент + Номер СФ + Дата СФ
не гарантируют, что речь действительно идет об одном и том же документе поставщика.
В нашем случае дополнительным надежным признаком оказалась сумма документа.
Поэтому решили изменить условие следующим образом:
Организация
+
Контрагент
+
Номер входящего СФ
+
Дата входящего СФ
+
Сумма документа
Если все пять значений совпадают, можно использовать существующий счет-фактуру.
Если номер и дата те же, но сумма отличается, необходимо создать новый.
Почему не стоит просто всегда создавать новый счет-фактуру
Самое простое решение могло бы выглядеть так:
Не искать существующий СФ вообще, а всегда создавать новый.
Но я бы так делать не советовал.
Типовой механизм объединения существует не просто так.
Например, поставщик действительно может выставить один счет-фактуру по нескольким документам поступления. В таком случае в Бухгалтерии совершенно нормально иметь:
Счет-фактура полученный №100 от 01.09.2026
Поступление №1
Поступление №2
Поступление №3
Если полностью отключить поиск существующего счета-фактуры, вместо одного корректного документа можем получить три отдельных.
Поэтому задача была не в отключении механизма, а в уточнении критерия поиска.
Где Бухгалтерия принимает решение об объединении
После анализа типового кода нужная точка нашлась в общем модуле:
УчетНДСПереопределяемый
Нас интересует функция:
ДобавитьОснованиеВСчетФактуруПолученный
По смыслу ее работа выглядит примерно так:
Нужно зарегистрировать СФ
|
v
Ищем существующий подходящий СФ
|
+---- найден ----> добавляем новое основание
|
+---- не найден -> создаем новый СФ типовым механизмом
Именно поиск существующего документа нам и требуется немного изменить.
Важно, что создание нового счета-фактуры переписывать не будем.
Это принципиальный момент.
Расширение вмешивается только в ответ на вопрос:
Есть уже подходящий счет-фактура или нет?
Если подходящего документа нет, дальнейшее создание выполняет сама типовая Бухгалтерия.
Создаем расширение
В конфигураторе открываем:
Конфигурация -> Расширения конфигурации
Создаем новое расширение.
Например:
Имя: РПП_РазделениеСФПоСумме
Синоним: Разделение счетов-фактур по сумме
Назначение можно оставить:
Исправление
Далее необходимо добавить в расширение общий модуль:
УчетНДСПереопределяемый
То есть мы расширяем существующий типовой общий модуль.
В его модуле расширения будет всего одна перехватываемая функция.
Полный код расширения
Ниже приведен полный рабочий вариант.
В исходной задаче изменение применяется только для документа «Отражение НДС к вычету».
Для остальных документов Бухгалтерия продолжает выполнять полностью типовой алгоритм.
&Вместо("ДобавитьОснованиеВСчетФактуруПолученный")
Функция РПП_ДобавитьОснованиеВСчетФактуруПолученный(
Основание,
НомерСчетаФактурыПолученного,
ДатаСчетаФактурыПолученного,
ОбновлятьСтатусСчетаФактурыПоДокументу = Истина,
ОригиналСчетаФактуры = Неопределено,
ВидСчетаФактуры = Неопределено) Экспорт
// Меняем типовой подбор существующего СФ
// только для документа "Отражение НДС к вычету".
//
// Для всех остальных оснований выполняется
// исходная функция конфигурации без изменений.
Если ТипЗнч(Основание) =
Тип("ДокументСсылка.ОтражениеНДСКВычету") Тогда
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ РАЗРЕШЕННЫЕ
| СчетФактураПолученный.Ссылка КАК СчетФактура
|ИЗ
| Документ.СчетФактураПолученный КАК СчетФактураПолученный
|ГДЕ
| СчетФактураПолученный.ПометкаУдаления = ЛОЖЬ
| И СчетФактураПолученный.ВидСчетаФактуры = &ВидСчетаФактуры
| И СчетФактураПолученный.Контрагент = &Контрагент
| И СчетФактураПолученный.Организация = &Организация
| И СчетФактураПолученный.НомерВходящегоДокумента =
| &НомерСчетаФактурыПолученного
| И СчетФактураПолученный.ДатаВходящегоДокумента =
| &ДатаСчетаФактурыПолученного
| И СчетФактураПолученный.СуммаДокумента =
| &РПП_СуммаДокумента
| И НЕ СчетФактураПолученный.Исправление
| И НЕ СчетФактураПолученный.ИсправлениеСобственнойОшибки";
Запрос.УстановитьПараметр(
"ВидСчетаФактуры",
?(
ВидСчетаФактуры = Неопределено,
Перечисления.ВидСчетаФактурыПолученного.НаПоступление,
ВидСчетаФактуры
)
);
РеквизитыОснования =
ОбщегоНазначения.ЗначенияРеквизитовОбъекта(
Основание,
"Контрагент,Организация,Проведен,СуммаДокумента"
);
Запрос.УстановитьПараметр(
"Контрагент",
РеквизитыОснования.Контрагент
);
Запрос.УстановитьПараметр(
"Организация",
РеквизитыОснования.Организация
);
Запрос.УстановитьПараметр(
"НомерСчетаФактурыПолученного",
НомерСчетаФактурыПолученного
);
Запрос.УстановитьПараметр(
"ДатаСчетаФактурыПолученного",
ДатаСчетаФактурыПолученного
);
Запрос.УстановитьПараметр(
"РПП_СуммаДокумента",
РеквизитыОснования.СуммаДокумента
);
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Количество() > 0 Тогда
Выборка.Следующий();
СчетФактура =
Выборка.СчетФактура.ПолучитьОбъект();
НоваяСтрока =
СчетФактура.ДокументыОснования.Добавить();
НоваяСтрока.ДокументОснование = Основание;
ПараметрыСчетаФактуры =
ПараметрыСчетаФактуры(СчетФактура);
ЗаполнитьЗначенияСвойств(
СчетФактура,
ПараметрыСчетаФактуры
);
СтруктураПараметров = Новый Структура;
СтруктураПараметров.Вставить(
"Дата",
СчетФактура.Дата
);
СтруктураПараметров.Вставить(
"ВидСчетаФактуры",
СчетФактура.ВидСчетаФактуры
);
СтруктураПараметров.Вставить(
"Исправление",
СчетФактура.Исправление
);
СтруктураПараметров.Вставить(
"КодВидаОперацииОснования",
""
);
СтруктураПараметров.Вставить(
"ДокументыОснования",
СчетФактура.ДокументыОснования
);
СтруктураПараметров.Вставить(
"НДСПоСтавкам4и2",
Ложь
);
Если ЗначениеЗаполнено(
СчетФактура.ДоговорКонтрагента
) Тогда
СвойстваДоговора =
ОбщегоНазначения.ЗначенияРеквизитовОбъекта(
СчетФактура.ДоговорКонтрагента,
"УчетАгентскогоНДС, ВидАгентскогоДоговора"
);
СтруктураПараметров.Вставить(
"НДСИсчисляетсяНалоговымАгентом",
СвойстваДоговора.УчетАгентскогоНДС = Истина
И Перечисления.ВидыАгентскихДоговоров.
НДСИсчисляетсяНалоговымАгентом(
СвойстваДоговора.ВидАгентскогоДоговора
)
);
КонецЕсли;
СчетФактура.КодВидаОперации =
Документы.СчетФактураПолученный.
ПолучитьКодВидаОперации(
СтруктураПараметров
);
РежимЗаписи =
?(
РеквизитыОснования.Проведен,
РежимЗаписиДокумента.Проведение,
РежимЗаписиДокумента.Запись
);
Если НЕ ОбновлятьСтатусСчетаФактурыПоДокументу Тогда
// Передаем документ-основание,
// по которому статус счета-фактуры
// уже был установлен.
СчетФактура.ДополнительныеСвойства.Вставить(
"ДокументСУстановленнымСтатусом",
Основание
);
КонецЕсли;
Если ЗначениеЗаполнено(
ОригиналСчетаФактуры
) Тогда
СтатусДокумента =
?(
ОригиналСчетаФактуры,
Перечисления.СтатусыДокументовПоступления.
ОригиналПолучен,
Перечисления.СтатусыДокументовПоступления.
ОригиналНеПолучен
);
СчетФактура.ДополнительныеСвойства.Вставить(
"СтатусДокумента",
СтатусДокумента
);
КонецЕсли;
СчетФактура.Записать(РежимЗаписи);
Возврат Выборка.СчетФактура;
Иначе
// СФ с тем же контрагентом, организацией,
// номером, датой И суммой не найден.
//
// Вызывающий типовой код сам создаст
// новый СчетФактураПолученный.
Возврат Неопределено;
КонецЕсли;
КонецЕсли;
Возврат ПродолжитьВызов(
Основание,
НомерСчетаФактурыПолученного,
ДатаСчетаФактурыПолученного,
ОбновлятьСтатусСчетаФактурыПоДокументу,
ОригиналСчетаФактуры,
ВидСчетаФактуры
);
КонецФункции
Что именно мы изменили
Несмотря на объем функции, принцип изменения довольно простой.
Сначала из документа-основания дополнительно получаем:
СуммаДокумента
Вот эта строка:
РеквизитыОснования =
ОбщегоНазначения.ЗначенияРеквизитовОбъекта(
Основание,
"Контрагент,Организация,Проведен,СуммаДокумента"
);
Далее передаем сумму параметром запроса:
Запрос.УстановитьПараметр(
"РПП_СуммаДокумента",
РеквизитыОснования.СуммаДокумента
);
И добавляем дополнительное условие поиска:
И СчетФактураПолученный.СуммаДокумента =
&РПП_СуммаДокумента
Вот эта строка и является главным изменением.
Теперь существующий счет-фактура подходит только при совпадении:
Организация
Контрагент
Номер входящего документа
Дата входящего документа
Сумма документа
Что происходит при разных суммах
Предположим, уже зарегистрирован:
ООО "Поставщик"
СФ №125 от 01.09.2026
Сумма 100 000 руб.
Далее пользователь регистрирует:
ООО "Поставщик"
СФ №125 от 01.09.2026
Сумма 75 000 руб.
Типовой вариант без нашей правки мог подобрать первый счет-фактуру и добавить в него второе основание.
После изменения запрос содержит:
И СчетФактураПолученный.СуммаДокумента =
&РПП_СуммаДокумента
Поэтому документ на 100 000 рублей уже не подходит для основания на 75 000 рублей.
Запрос возвращает пустой результат.
Мы возвращаем:
Возврат Неопределено;
И здесь очень важно понимать дальнейшую цепочку.
Мы не создаем счет-фактуру самостоятельно.
Типовой вызывающий код Бухгалтерии получает Неопределено и выполняет стандартное создание нового:
СчетФактураПолученный
То есть заполнение нового СФ, его дальнейшая запись и стандартные механизмы учета остаются типовыми.
Почему именно такой вариант мне нравится больше
Можно было переписать гораздо больше.
Например:
-
самостоятельно создавать новый объект
СчетФактураПолученный; -
заполнять все его реквизиты;
-
переносить основание;
-
определять вид СФ;
-
рассчитывать код вида операции;
-
устанавливать статусы;
-
проводить документ.
Но это резко увеличивает количество собственного кода.
А вместе с ним увеличивается вероятность того, что после очередного обновления Бухгалтерии типовой механизм изменится, а расширение продолжит работать по старым правилам.
Здесь мы используем другой подход:
Изменяем только критерий поиска существующего СФ.
Все остальное по возможности оставляем конфигурации.
Зачем нужен &Вместо
Функция перехватывается аннотацией:
&Вместо("ДобавитьОснованиеВСчетФактуруПолученный")
То есть при вызове типовой:
ДобавитьОснованиеВСчетФактуруПолученный
сначала выполняется наша функция расширения.
Но мы не хотим менять поведение всей Бухгалтерии.
Поэтому ниже стоит ограничение:
Если ТипЗнч(Основание) =
Тип("ДокументСсылка.ОтражениеНДСКВычету") Тогда
Только в этом случае выполняется наша версия поиска.
В самом конце функции имеется:
Возврат ПродолжитьВызов(
Основание,
НомерСчетаФактурыПолученного,
ДатаСчетаФактурыПолученного,
ОбновлятьСтатусСчетаФактурыПоДокументу,
ОригиналСчетаФактуры,
ВидСчетаФактуры
);
ПродолжитьВызов() передает управление обратно оригинальной функции конфигурации.
То есть:
Отражение НДС к вычету
|
v
наш измененный поиск по сумме
а:
любое другое основание
|
v
полностью типовая функция Бухгалтерии
Как сделать такую проверку для другого документа
Это сделать очень просто.
В нашем варианте область действия задается этой строкой:
Если ТипЗнч(Основание) =
Тип("ДокументСсылка.ОтражениеНДСКВычету") Тогда
Допустим, необходимо распространить поведение еще на некоторый документ НужныйДокумент.
Условие можно изменить так:
Если ТипЗнч(Основание) =
Тип("ДокументСсылка.ОтражениеНДСКВычету")
Или ТипЗнч(Основание) =
Тип("ДокументСсылка.НужныйДокумент") Тогда
Для нескольких документов:
Если ТипЗнч(Основание) =
Тип("ДокументСсылка.ОтражениеНДСКВычету")
Или ТипЗнч(Основание) =
Тип("ДокументСсылка.Документ1")
Или ТипЗнч(Основание) =
Тип("ДокументСсылка.Документ2")
Или ТипЗнч(Основание) =
Тип("ДокументСсылка.Документ3") Тогда
То есть для расширения области действия нужно менять именно строку с:
ТипЗнч(Основание)
Можно ли применить алгоритм для всех документов сразу?
Можно, но здесь требуется осторожность.
Технически можно убрать:
Если ТипЗнч(Основание) =
Тип("ДокументСсылка.ОтражениеНДСКВычету") Тогда
и соответствующий:
КонецЕсли;
Тогда измененная функция будет выполняться для всех оснований, попадающих в:
ДобавитьОснованиеВСчетФактуруПолученный
Но в текущем коде присутствует получение:
"Контрагент,Организация,Проведен,СуммаДокумента"
Следовательно, у документа-основания обязательно должны существовать реквизиты:
Контрагент
Организация
Проведен
СуммаДокумента
Если какой-либо тип основания не содержит СуммаДокумента, функция:
ОбщегоНазначения.ЗначенияРеквизитовОбъекта()
не сможет получить требуемый набор данных.
Поэтому универсальный вариант я бы делал только после проверки всех типов оснований, которые реально проходят через этот участок конфигурации.
Безопаснее явно перечислить нужные документы.
Как сделать универсальнее без жесткой проверки типа
При желании можно проверять наличие реквизита метаданными или получать сумму разными способами в зависимости от типа документа.
Например, логика может быть такой:
Если у основания есть СуммаДокумента:
использовать Контрагент + Номер + Дата + Сумма
Иначе:
выполнить типовой алгоритм
Это уже более универсальный вариант, но для одной конкретной задачи он избыточен.
Чем уже исправление, тем проще его сопровождать.
А можно использовать не сумму?
Да.
Сумма здесь не является каким-то обязательным техническим ключом 1С.
Это просто дополнительный бизнес-признак, который подошел под конкретный учет клиента.
В другой базе может потребоваться учитывать:
Договор
Подразделение
Документ расчетов
Вид операции
Склад
Проект
Дополнительный реквизит
Принцип останется тем же.
Допустим, необходимо добавить договор.
Тогда получаем его из основания:
РеквизитыОснования =
ОбщегоНазначения.ЗначенияРеквизитовОбъекта(
Основание,
"Контрагент,Организация,Проведен,СуммаДокумента,ДоговорКонтрагента"
);
Передаем параметр:
Запрос.УстановитьПараметр(
"ДоговорКонтрагента",
РеквизитыОснования.ДоговорКонтрагента
);
И добавляем условие:
И СчетФактураПолученный.ДоговорКонтрагента =
&ДоговорКонтрагента
Тогда ключ станет:
Организация
+
Контрагент
+
Номер
+
Дата
+
Сумма
+
Договор
Но добавлять критерии «на всякий случай» не нужно.
Каждый новый критерий уменьшает вероятность объединения счетов-фактур.
Почему не стоит исправлять номер вручную
Иногда проблему пытаются решить без программирования.
Например, вместо двух одинаковых номеров:
125
125
пользователь вводит:
125
125/1
или:
125
125-2
Да, технически Бухгалтерия перестает считать документы одинаковыми.
Но теперь номер в базе не соответствует реальному первичному документу поставщика.
А это уже совсем другая история.
Номер счета-фактуры участвует в учете НДС и может использоваться:
-
в книге покупок;
-
в отчетах;
-
при сверке документов;
-
при поиске первички;
-
при электронном документообороте;
-
при проверке данных;
-
при последующем анализе учета.
Если поставщик выставил документ №125, то в базе желательно сохранить именно №125.
Исправлять лучше критерий внутреннего поиска, а не первичные реквизиты документа.
Какие сценарии обязательно проверить
После добавления расширения я бы минимум проверил четыре варианта.
1. Одинаковые номер и дата, разные суммы
Первый документ:
Контрагент: Поставщик
СФ: №125 от 01.09.2026
Сумма: 100 000
Второй:
Контрагент: Поставщик
СФ: №125 от 01.09.2026
Сумма: 75 000
Ожидаем:
2 отдельных Счета-фактуры полученных
2. Одинаковые номер, дата и сумма
Первый:
Поставщик
№125 от 01.09.2026
100 000 руб.
Второй:
Поставщик
№125 от 01.09.2026
100 000 руб.
В таком случае наш дополнительный критерий тоже совпадает.
Следовательно, счет-фактура может быть объединен.
Это ожидаемое поведение данной реализации.
3. Разные контрагенты
Например:
ООО "Поставщик 1"
№125 от 01.09.2026
100 000
и:
ООО "Поставщик 2"
№125 от 01.09.2026
100 000
Они не должны объединяться, поскольку контрагент уже присутствует в стандартном критерии.
4. Обычный документ приобретения
Обязательно стоит зарегистрировать СФ обычным способом не через «Отражение НДС к вычету».
Наша функция должна дойти до:
ПродолжитьВызов()
и весь сценарий должен выполниться типовым кодом.
Это один из главных контрольных тестов, потому что мы специально ограничивали область вмешательства.
Что будет с уже созданными объединенными счетами-фактурами
Это расширение не занимается исправлением истории.
Оно меняет алгоритм подбора существующего счета-фактуры при дальнейшей работе.
Если до установки расширения уже был создан:
СФ №125
Основание №1
Основание №2
он автоматически не превратится в два документа.
Исправление таких счетов-фактур является отдельной задачей.
Там необходимо учитывать:
-
период;
-
состояние книги покупок;
-
проведенность;
-
закрытые периоды;
-
наличие корректировок;
-
дальнейшие документы;
-
регламентированную отчетность.
Поэтому я бы не смешивал профилактику новых объединений и массовое исправление старых данных в одном расширении.
Ограничение решения
У дополнительного критерия по сумме есть один очевидный крайний случай.
Если существуют два действительно разных счета-фактуры, у которых полностью совпадают:
Организация
Контрагент
Номер
Дата
Сумма
то наш алгоритм по-прежнему может считать их одним документом.
Например:
СФ №125 от 01.09.2026
100 000 руб.
и совершенно другой:
СФ №125 от 01.09.2026
100 000 руб.
При таком сценарии суммы недостаточно.
Тогда потребуется дополнительный признак.
Например:
Документ-основание
или другой реквизит, позволяющий однозначно отличить документы.
В рассматриваемой базе клиенту было достаточно суммы, поэтому усложнять механизм не стали.
Что проверять после обновления Бухгалтерии
Решение использует:
&Вместо("ДобавитьОснованиеВСчетФактуруПолученный")
Поэтому после существенного обновления конфигурации желательно проверить типовую функцию:
УчетНДСПереопределяемый.
ДобавитьОснованиеВСчетФактуруПолученный()
Особенно обращаем внимание на:
-
сигнатуру функции;
-
количество параметров;
-
новые параметры;
-
изменение логики поиска;
-
изменение табличной части
ДокументыОснования; -
изменение заполнения кода вида операции;
-
новые статусы счетов-фактур;
-
изменение механизма исправленных СФ.
Если фирма «1С» изменит типовую функцию, расширение с &Вместо необходимо сравнить с новой версией.
Это нормальная цена за перехват типовой функции.
Именно поэтому мы не стали распространять изменение без необходимости на всю конфигурацию.
На каком релизе проверялось
Разработка выполнялась на:
1С:Бухгалтерия предприятия КОРП, редакция 3.0
3.0.203.24
Сам подход применим и к другим релизам Бухгалтерии 3.0, но перед использованием кода необходимо открыть свой:
УчетНДСПереопределяемый
и сравнить функцию:
ДобавитьОснованиеВСчетФактуруПолученный
с приведенным вариантом.
Если сигнатура или внутренняя логика отличаются, код расширения необходимо адаптировать под конкретный релиз.
Итог
Получилась достаточно небольшая по смыслу доработка.
Проблема:
Несколько разных операций
+
одинаковый контрагент
+
одинаковый номер СФ
+
одинаковая дата СФ
=
один СчетФактураПолученный
После изменения:
Контрагент
+
Организация
+
Номер
+
Дата
+
Сумма
становятся критериями подбора существующего документа.
Поэтому:
№125 от 01.09.2026, 100 000 руб.
и:
№125 от 01.09.2026, 75 000 руб.
регистрируются раздельно.
При этом:
-
номер первичного документа не искажается;
-
типовой механизм создания нового счета-фактуры сохраняется;
-
другие документы продолжают работать по стандартному алгоритму;
-
область вмешательства ограничена одной функцией;
-
весь код находится в расширении;
-
основная конфигурация остается без изменений.
Для распространения решения на другие документы достаточно изменить условие:
Если ТипЗнч(Основание) =
Тип("ДокументСсылка.ОтражениеНДСКВычету") Тогда
и добавить нужные типы через Или.
Если требуется использовать новую логику вообще для всех оснований, ограничение можно убрать, но предварительно нужно проверить наличие необходимых реквизитов, в частности:
Контрагент
Организация
Проведен
СуммаДокумента
у каждого возможного документа.
В результате получаем не глобальное отключение типового механизма объединения счетов-фактур, а его небольшую адаптацию под особенности конкретного учета.
Вступайте в нашу телеграмм-группу Инфостарт