При работе в 1С:Бухгалтерия 3.0 пользователи часто сталкиваются с ситуацией, когда при отправке счета на оплату напрямую из программы (через кнопку с изображением конверта) в сформированном письме отсутствует вложение в виде электронного счета (формат XML). Хотя в интерфейсе и обучающих материалах предполагается, что электронное представление документа должно добавляться автоматически, на практике поле вложений может оказаться пустым или содержать только печатную форму. Рассмотрим подробно, почему это происходит, как диагностировать ошибку и какие настройки проверить в первую очередь.
Для начала разберем, как именно 1С формирует это вложение. Процесс не ограничивается простым копированием данных. Программа запускает механизмы подсистемы «Электронное взаимодействие». Даже если вы не используете полноценный ЭДО с передачей через оператора, для формирования XML-файла счета 1С проверяет документ на соответствие форматам ФНС. Если хотя бы один реквизит, обязательный для выгрузки, заполнен некорректно или отсутствует, система молча (или с записью в системный лог) прерывает формирование файла, и в тело письма ничего не прикрепляется.
Одной из самых распространенных причин является отсутствие или некорректность данных в карточке контрагента. Проанализируем типичную ситуацию: в модуле менеджера документа СчетНаОплатуПокупателю существует проверка заполнения ИНН. Рассмотрим фрагмент кода, который может блокировать процесс:
Если Не ЗначениеЗаполнено(ВыборкаДанных.КонтрагентИНН) Тогда
// Формирование электронного представления прерывается
Возврат Ложь;
КонецЕсли;
Если в справочнике Контрагенты у получателя не заполнен ИНН, программа не сможет сформировать юридически значимый XML-документ по стандартам ФНС. Аналогично стоит проверить наличие КПП для юридических лиц и юридического адреса. Если адрес введен в свободной форме, а не по классификатору ФИАС (без индекса или кодов региона), валидация также может не пройти.
Еще один важный момент, на который стоит обратить внимание — это классификатор единиц измерения. Формат электронного счета строго регламентирует длину и формат кода единицы измерения. Разберем пример из практики: если у вас в справочнике КлассификаторЕдиницИзмерения для позиции «Штука» указан код «1» или «шт», система выдаст ошибку, так как ожидается трехзначный цифровой код по ОКЕИ (например, «796» для штук).
Выясним причину через код. В общем модуле ОбменСКонтрагентамиВнутренний в функции СформироватьСчетНаОплатуПоДокументу происходит проверка:
Если Не ЗначениеЗаполнено(Ошибки) Тогда
// Код формирования XML
Иначе
// Запись ошибки: "Ожидается длина кода базовой единицы измерения 3 символа, а получено 1"
КонецЕсли;
Если вы обнаружили подобное несоответствие, необходимо привести справочник единиц измерения в соответствие с общероссийским классификатором.
Если визуально в документе все заполнено верно, но файл не прикрепляется, нам поможет Журнал регистрации. Это основной инструмент технического анализа в 1С. Для поиска причин выполним следующие шаги:
Электронное взаимодействие. Обмен с контрагентами.Справочники.ПрисоединенныеФайлы, так как электронный счет перед отправкой временно сохраняется в системе как присоединенный файл.Иногда проблема кроется не в данных документа, а в настройках самой программы. Рассмотрим параметры, влияющие на отправку:
Администрирование — Обмен электронными документами. Несмотря на то, что вы отправляете файл по почте, флаг «Электронные подписи» и настройки форматов должны быть корректно инициализированы в базе.Шаблоны сообщений (раздел Администрирование — Параметры учета). Если шаблон был отредактирован вручную, проверьте, не удален ли из него параметр, отвечающий за прикрепление электронного документа. Попробуйте выбрать стандартный шаблон «Счет на оплату» при отправке и посмотрите, изменится ли ситуация.В редких случаях проблема может быть вызвана нестандартными символами в наименовании номенклатуры (спецсимволы, кавычки-елочки, невидимые знаки переноса строки), которые не пропускает валидатор XML. Проанализируем также версию платформы 1С. В релизах ветки 8.3.15 наблюдались ошибки в работе модулей криптографии, которые могли косвенно влиять на работу подсистемы обмена. В такой ситуации рекомендуется:
8.3.22 или выше).Подводя итог, можно сказать, что отсутствие вложения — это всегда результат непройденной валидации данных. Проверив ИНН контрагента, коды ОКЕИ и заглянув в Журнал регистрации, вы с высокой вероятностью сможете самостоятельно устранить проблему и обеспечить корректную отправку электронных счетов вашим партнерам.