Многие пользователи и бухгалтеры, работающие в конфигурации 1С:Управление торговлей 11.5 (а также в Комплексной автоматизации и ERP), рано или поздно сталкиваются с пугающей ситуацией: система позволяет создавать документы СчетФактураВыданный с абсолютно одинаковыми номерами и датами — для очистки базы есть готовая обработка поиска и удаления дублей в 1С. При этом, если попробовать провернуть подобное с документом РеализацияТоваровУслуг, программа выдаст ошибку не уникальности. Давайте подробно рассмотрим эту проблему, выясним причину такого поведения системы и разберем по шагам, как правильно настроить контроль уникальности в вашей базе.
Первая мысль при обнаружении дублей — «в программе баг» или «слетели настройки». Однако, проанализируем официальный ответ отдела разработки 1С: поведение полностью соответствует задуманному. Стандартная «галочка» контроля уникальности в конфигураторе намеренно снята. Разберем основные причины такого решения:
Бухгалтеров часто пугает ситуация с дублями, так как Налоговый кодекс РФ (ст. 169) и Постановление № 1137 требуют хронологической и сквозной нумерации. Проанализируем, грозят ли за это штрафы.
С точки зрения законодательства, прямых штрафов за сбой нумерации счетов-фактур нет. Грубым нарушением (ст. 120 НК РФ) считается полное отсутствие счетов-фактур, а не их задвоение. Более того, одинаковые номера не могут служить поводом для отказа вашему покупателю в вычете по НДС, если налоговая инспекция может четко идентифицировать продавца, покупателя, товары и сумму налога. Максимум неприятностей — это дополнительные вопросы от инспекторов при встречных проверках.
Посмотрим на практическую сторону проблемы, из-за которой пользователи бьют тревогу. Универсальный передаточный документ (УПД) формируется на основании реализации, но свой номер он берет именно из документа счета-фактуры.
Если нумерация реализаций и счетов-фактур расходится (из-за дублей, пропусков, создания документов задним числом), бухгалтеру становится невероятно сложно сопоставлять бумажные подписанные УПД с электронными документами РеализацияТоваровУслуг в журнале 1С. Приходится искать документ по контрагенту, сумме и дате, что при больших объемах превращается в мучение. Именно поэтому многие компании стремятся приравнять номер счета-фактуры к номеру реализации.
Важно! Не пытайтесь просто поставить галочку «Контроль уникальности» в Конфигураторе для документа СчетФактураВыданный. Это сломает логику обменов и не даст создавать исправительные документы.
Рассмотрим правильный современный подход — использование механизма Расширений. Нам необходимо добавить обработчик события ПередЗаписью, который будет проверять базу на наличие дублей только для обычных (не исправительных) счетов-фактур.
Алгоритм работы расширения будет следующим:
ПередЗаписью документа СчетФактураВыданный.Отказ = Истина и выводим пользователю понятное сообщение об ошибке.Концептуальный пример кода для модуля объекта в расширении (событие ПередЗаписью):
Процедура Расш1_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Проверяем, что это не исправительный счет-фактура
Если ЭтаФорма.Исправление Тогда
Возврат;
КонецЕсли;
// Ищем дубли запросом
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| СчетФактураВыданный.Ссылка КАК Ссылка
|ИЗ
| Документ.СчетФактураВыданный КАК СчетФактураВыданный
|ГДЕ
| СчетФактураВыданный.Номер = &Номер
| И СчетФактураВыданный.Дата МЕЖДУ НАЧАЛОПЕРИОДА(&Дата, ГОД) И КОНЕЦПЕРИОДА(&Дата, ГОД)
| И СчетФактураВыданный.Ссылка <> &ТекущаяСсылка
| И СчетФактураВыданный.Исправление = ЛОЖЬ";
Запрос.УстановитьПараметр("Номер", ЭтотОбъект.Номер);
Запрос.УстановитьПараметр("Дата", ЭтотОбъект.Дата);
Запрос.УстановитьПараметр("ТекущаяСсылка", ЭтотОбъект.Ссылка);
РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
ВызватьИсключение "Документ с таким номером уже существует! Контроль уникальности не пройден.";
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
Также, используя подобное расширение, вы можете настроить автоматическую синхронизацию номеров. В обработчике события ПриУстановкеНовогоНомера или ПередЗаписью можно прописать логику, которая будет брать номер из документа-основания (документа РеализацияТоваровУслуг) и принудительно присваивать его счету-фактуре. Это полностью избавит бухгалтерию от проблемы несовпадения номеров в УПД и реализациях.
Таким образом, мы выяснили причину поведения типовой конфигурации и разобрали гибкий и безопасный метод решения задачи, который сохранит базу на поддержке и не нарушит типовые механизмы обмена 1С.