Вопрос корректного оформления первичной документации и счетов-фактур всегда стоит остро, особенно когда речь заходит о взаимодействии с требовательными контрагентами. Одной из частых точек преткновения становится заполнение строк 3 («Грузоотправитель и его адрес») и 4 («Грузополучатель и его адрес») в Универсальном передаточном документе (УПД) или счете-фактуре при реализации услуг.
В этой статье мы подробно разберем нормативную базу, выясним, почему возникают споры между бухгалтерами, и рассмотрим, как программисту 1С технически решить эту задачу, если того требует бизнес-процесс.
Первым делом обратимся к законодательству, чтобы понять, кто прав: тот, кто требует заполнить адреса, или тот, кто ставит прочерки. Основным документом, регламентирующим правила заполнения счетов-фактур (и, соответственно, статуса 1 в УПД), является Постановление Правительства РФ от 26 декабря 2011 г. № 1137.
Давайте проанализируем текст правил заполнения счета-фактуры (раздел II, пункт 1, подпункты «е» и «ж»). Формулировки менялись со временем, и это важно учитывать.
Ранее правила предписывали жесткое требование: «ставится прочерк». Однако в действующих редакциях (например, с изменениями от 02.04.2021 № 534) формулировка стала мягче и звучит следующим образом:
При составлении счета-фактуры на выполненные работы (оказанные услуги), имущественные права продавцом, в том числе налоговыми агентами... в этой строке продавец... вправе поставить прочерк.
Это ключевой момент. Давайте разберем, что означает фраза «вправе поставить прочерк»:
Многие бухгалтеры заказчиков требуют заполнения этих полей, опасаясь, что налоговая инспекция откажет в вычете НДС из-за «некорректного» оформления. Обоснован ли этот страх?
Давайте посмотрим на пункт 2 статьи 169 Налогового кодекса РФ. В нем четко сказано, что является основанием для отказа в вычете. Ошибки в счетах-фактурах и корректировочных счетах-фактурах, не препятствующие налоговым органам при проведении налоговой проверки идентифицировать:
...не являются основанием для отказа в принятии к вычету сумм налога.
Таким образом, даже если налоговый инспектор посчитает заполнение строк 3 и 4 при услугах «излишним» или, наоборот, прочерк — «недостаточным» (что вряд ли, учитывая Постановление № 1137), это не мешает идентифицировать участников сделки и сумму налога. Следовательно, риска потери вычета НДС здесь нет ни в одном из вариантов.
Если закон разрешает ставить прочерки, почему возникают требования заполнить эти поля? В ходе анализа реальных ситуаций (в том числе обсуждения на форуме) выясняется, что причины часто кроются не в налоговом законодательстве, а в управленческом учете или специфике бизнеса.
Рассмотрим частый пример: компания имеет сеть филиалов или обособленных подразделений. Услуга (например, ремонт оборудования) была оказана в конкретном филиале. Головной офис клиента, получая документы, хочет видеть, к какому именно подразделению относятся затраты.
Если в строках «Грузоотправитель» и «Грузополучатель» стоят прочерки, а в шапке указаны реквизиты головных организаций, бухгалтеру клиента сложно разнести затраты по центрам финансовой ответственности (ЦФО). Именно поэтому они просят указать адрес фактического места оказания услуг в строке Грузоотправителя или Грузополучателя.
Как программистам и консультантам 1С реагировать на такие запросы? Стандартная логика типовых конфигураций (например, 1С:Бухгалтерия, 1С:ERP, 1С:УТ) обычно следует букве закона и пытается ставить прочерки для услуг. Но 1С — система гибкая. Рассмотрим варианты решений.
Если требование клиента связано с идентификацией обособленного подразделения, наиболее методологически верным способом будет использование правильного КПП.
В строке 2б «ИНН/КПП продавца» и строке 6б «ИНН/КПП покупателя» должны быть указаны КПП соответствующих обособленных подразделений. Это позволяет однозначно идентифицировать филиал без нарушения логики полей «Грузоотправитель/Грузополучатель».
Убедитесь, что в базе заведены соответствующие записи в справочнике РегистрацииВНалоговомОргане и выбраны в документах реализации.
Если клиент категорически настаивает на заполнении строк 3 и 4 полными данными даже для услуг, и руководство принимает решение пойти навстречу, нам придется вмешаться в алгоритм формирования печатной формы.
Обычно в модулях менеджеров документов или в общих модулях печати (например, УчетНДС или ПечатьТорговыхДокументов) существует проверка вида номенклатуры.
Логика выглядит примерно так:
// Псевдокод алгоритма заполнения строки 3
Если СтрокаТаблицы.ЭтоУслуга Тогда
СведенияОГрузоотправителе = "-"; // Или пустая структура
Иначе
СведенияОГрузоотправителе = ПолучитьСведенияОГрузоотправителе(Организация);
КонецЕсли;
Чтобы изменить это поведение, лучше всего использовать механизм Внешних печатных форм (ВПФ), чтобы не снимать конфигурацию с поддержки. В ВПФ мы можем скопировать стандартный макет и алгоритм, но убрать условие, проверяющее услугу. Для быстрой сборки и настройки таких бланков без конфигуратора можно использовать конструктор внешних печатных форм.
Например, в процедуре формирования данных для печати мы можем принудительно заполнять структуры грузоотправителя и грузополучателя данными из шапки документа (организация и контрагент), игнорируя факт того, что в табличной части находятся услуги.
// Пример модификации в ВПФ
// Игнорируем проверку на услугу и всегда заполняем данные
ДанныеПечати.Грузоотправитель = СформироватьПредставлениеГрузоотправителя(Шапка.Организация, Шапка.Склад);
ДанныеПечати.Грузополучатель = СформироватьПредставлениеГрузополучателя(Шапка.Контрагент);
Самый гибкий подход, который обсуждался профессиональным сообществом — дать возможность выбора пользователю, не меняя код каждый раз под нового капризного клиента.
Рассмотрим алгоритм реализации:
ЗаполнятьГрузоотправителяВУслугах.
Если ЗначениеДопРеквизита(Шапка.Договор, "ЗаполнятьГрузоотправителяВУслугах") = Истина Тогда
// Принудительное заполнение
ЗаполнитьРеквизитыГруза(ОбластьМакета, Шапка.Организация, Шапка.Контрагент);
Иначе
// Стандартное поведение (прочерки для услуг)
Если ЕстьТовары Тогда
ЗаполнитьРеквизитыГруза(ОбластьМакета, Шапка.Организация, Шапка.Контрагент);
Иначе
ОбластьМакета.Параметры.Грузоотправитель = "--";
ОбластьМакета.Параметры.Грузополучатель = "--";
КонецЕсли;
КонецЕсли;
Это решение позволяет удовлетворить требования конкретных заказчиков, не нарушая правильный документооборот с остальными.
Если проблема именно в указании адреса места проведения работ (как в случае с ремонтом), программист может предложить альтернативные варианты, не затрагивающие спорные поля 3 и 4:
Подведем итоги анализа проблемы:
Таким образом, выбор стратегии зависит от гибкости вашей компании. Если бизнес готов идти навстречу клиенту — техническая реализация через ВПФ является делом пары часов работы программиста.