НДС меняется в конфигураторе, но теряется в письме и PDF

Где появляется расхождение

Учебный посетитель собирает комплект и переключает способ отображения цены. На экране видна сумма с пояснением о налоге. После отправки письма режим пропадает, а PDF показывает иной набор строк. Это не обязательно ошибка арифметики. Возможные причины включают потерянный флаг, независимый расчёт шаблона и использование другого состояния сборки. Их проверяют раздельно.

Сначала фиксируют, что именно означает переключатель. Он может менять только представление суммы либо влиять на выбранные условия расчёта. Эти варианты нельзя смешивать. Если действие лишь скрывает строку налога, итог не должен изменяться без основания. Если меняется расчётная модель, это должно быть явно показано и передано серверу. Смысл кнопки определяют до исправления письма.

Источник задачи подтверждает необходимость согласованности представлений, но не даёт права объявлять конкретный налоговый режим правильным для любой продажи. Поэтому числовые примеры в статье служат проверке передачи состояния. Реальные ставки, исключения и формулировки документов согласуют с ответственными специалистами и действующими требованиями отдельно от технического шаблона.

Расчёт и отображение

Полезно разделить исходные данные, результат расчёта и визуальные подписи. Исходные данные включают выбранные позиции, количество, валюту и согласованные параметры. Результат содержит суммы по принятой модели. Представление решает, какие строки и пояснения видит человек. Если каждый шаблон заново строит все три слоя, вероятность расхождения увеличивается.

Такое разделение не требует обязательно сложного сервиса. В небольшом проекте это может быть одна проверенная функция и ограниченный объект результата. Важно, чтобы экран и документы использовали согласованный контракт. Не нужно создавать универсальный финансовый движок, если задача состоит в передаче уже определённого режима между тремя представлениями.

Что включить в снимок

В снимке фиксируют выбранную конфигурацию, количество, валюту, результат расчёта и существенные пояснения. Если режим имеет отдельное значение, его передают явно. Название кнопки или текст локализованной подписи не подходит как технический ключ. Он может измениться при переводе, а смысл расчёта должен оставаться устойчивым. Внутренние коды не обязательно показывать пользователю.

Снимок создают в определённый момент. Если пользователь изменил сборку после открытия формы, нужно понять, какая версия отправляется. В письме должна быть та, которую человек подтвердил, а не случайное актуальное состояние страницы через несколько секунд. Сервер проверяет допустимость данных и сохраняет принятый результат. Браузерная сумма сама по себе не является доверенным финансовым расчётом.

Если документы формируются отложенно, они читают сохранённый снимок либо осознанно пересчитывают по отдельному правилу. Второй вариант может изменить предложение и требует объяснения. Нельзя незаметно использовать новый курс или обновлённую цену, пока письмо продолжает называться копией прежней конфигурации. Поддержка должна понимать, какой момент отражает каждый документ.

Учебный расчёт без универсальной ставки

Для проверки можно задать условные величины: базовая сумма 1000 единиц, учебная добавочная составляющая 200 и итог 1200. Эти числа не называют действующей налоговой ставкой. Они позволяют увидеть, передаются ли три разных значения и подписи без потери. После технической проверки модель заменяют утверждёнными правилами проекта, не перенося учебные числа в рабочий каталог.

На экране, в письме и PDF сравнивают одно и то же состояние. Если выбран режим с отдельной строкой, все представления показывают согласованные составляющие. Если режим скрывает детализацию, итог сохраняется по принятому правилу. Такой тест обнаруживает потерю флага даже без настоящих цен. Важно проверять точные значения, а не только визуальное наличие слова «НДС».

Для количества больше единицы используют отдельный опыт. Округление по строкам и округление общего итога могут давать разные результаты, поэтому последовательность задают явно. Статья не выбирает её за владельца расчёта. Она требует, чтобы все потребители использовали одно согласованное решение и не добавляли собственное округление при форматировании.

Письмо как потребитель готовых данных

Шаблон письма получает значения и условия из снимка. Он может форматировать числа и переводить подписи, но не должен восстанавливать режим по косвенным признакам. Например, наличие непустой суммы не всегда означает, что нужно показать конкретное налоговое пояснение. Условные блоки должны опираться на явное состояние и корректно обрабатывать отсутствие необязательных данных.

Проверяют длинные названия сборки, несколько строк и пустую необязательную опцию. Скрытый блок не должен оставлять незакрытую таблицу или пустую рамку. Почтовое представление отличается от веб-страницы, поэтому итог смотрят в поддерживаемых клиентах. Но визуальная совместимость не заменяет сверку сумм: красивое письмо может содержать расчёт из другой версии.

После повторной отправки того же снимка значения должны совпадать. Если сотрудник осознанно изменил предложение, это новая версия или отдельное действие с понятным обозначением. Нельзя сохранять старый заголовок и молча подставлять обновлённую сумму. История должна позволять понять, что именно было отправлено, не раскрывая лишние клиентские сведения в техническом журнале.

PDF и ограничения движка

Генератор PDF может использовать отдельный шаблон и иметь свои ограничения CSS, шрифтов и загрузки изображений. Поэтому для него проверяют и данные, и отображение. Потеря режима может быть серверной, а отсутствие строки визуальной. Например, блок существует, но вышел за границу страницы или перекрыт другим элементом. Разбор должен различать эти причины.

Полезно сравнить подготовленный HTML для PDF и готовый файл, если такой промежуточный этап существует. Если данные уже отсутствуют в шаблоне, проблема не в движке. Если присутствуют, смотрят переносы, размеры и условные блоки. Универсального исправления для неизвестного генератора нет; конкретные возможности проверяют по его документации и фактической версии.

Файл должен открываться после формирования и содержать полный набор страниц. Нельзя считать задачу завершённой только по успешному ответу генератора. На учебной конфигурации проверяют короткий и длинный документ, разные языки и перенос таблицы. Подпись режима и итоговая сумма не должны отрываться от относящегося к ним расчёта так, что смысл теряется.

Язык и форматирование чисел

Локаль может менять разделитель дробной части, пробелы разрядов и подписи, но не математическое значение. Поэтому в контракте расчёт хранится в согласованном числовом представлении, а форматирование выполняется на последнем шаге. Не следует разбирать обратно отформатированную строку из экрана, чтобы получить сумму для PDF. Такой путь зависит от языка и легко ломается на пробелах или запятых.

В учебной проверке одна сборка формируется в двух языках. Сравнивают значения без форматирования и видимые подписи. Если в одном языке пропал режим, вероятно, условие привязано к тексту или не обновлён один шаблон. Но причину подтверждают просмотром фактической передачи, а не предположением о переводе. Общий расчёт должен оставаться единым для обоих представлений.

Проверяют и валюту. Слово «евро» в заголовке документа не исправляет сумму, рассчитанную в другой единице. Код валюты, символ и количество знаков отображения должны соответствовать принятой модели. Если проект поддерживает несколько валют, набор приёмки включает хотя бы одну конфигурацию для каждого различающегося пути форматирования.

Повторная отправка и устаревшие данные

Сотрудник может повторно сформировать письмо через время после первоначального обращения. Нужно решить, повторяет ли он старый снимок или создаёт новое предложение по текущим данным. Оба действия допустимы в разных процессах, но их нельзя смешивать под одной кнопкой без пояснения. Пользователь должен понимать, почему суммы изменились, если это произошло осознанно.

Если исходная сборка содержит уже недоступную опцию, повтор старого документа не должен подтверждать текущую доступность. Снимок показывает историю выбора, а актуальное предложение требует проверки. В документе можно использовать согласованное указание статуса и даты, если оно действительно предусмотрено. Статья не добавляет юридические оговорки за проект, а обозначает техническую границу данных.

При неопределённом результате отправки повтор не должен создавать несколько противоречивых версий. Внутренний признак операции связывает документ с принятым снимком и результатом доставки. Поддержка видит, что было сформировано, а не только общий статус «письмо ушло». Персональные данные и полный документ не нужно дублировать во все технические логи.

Приёмка трёх представлений

Для каждого разрешённого режима создают одну учебную сборку и сравнивают экран, письмо и PDF по строкам. Проверяют итог, составляющие, валюту, количество и пояснение. Затем повторяют отправку, меняют язык и используют длинную конфигурацию. Ожидаемые значения записывают заранее по утверждённой модели. Совпадение двух документов между собой ещё не доказывает правильность, если оба читают неверный источник.

Отдельно проверяют отсутствие режима или неподдерживаемое значение. Система не должна молча выбирать коммерчески значимый вариант по умолчанию без согласованного правила. Лучше отклонить зависимое формирование с понятной причиной или потребовать уточнение. Конкретный ответ зависит от процесса, но он должен быть проверен, а не оставлен необработанной веткой.

Готовое исправление обеспечивает единый смысл расчёта во всех представлениях. В документации остаются структура снимка, владелец формулы и набор учебных сравнений. Это позволяет менять оформление письма и PDF без повторного изобретения финансовой логики и без выдачи неподтверждённых правил за свойства исходного проекта.

Сравнение одного снимка в трёх каналах

Учебный расчёт содержит базовую сумму 1000, условную добавочную часть 200 и итог 1200. Это не действующая налоговая ставка. Выбирают режим отдельного показа составляющих и формируют экран, письмо и PDF из одного снимка. Затем переключают только представление по принятому правилу. Числовой смысл не должен меняться от шаблона или языка. Если один документ читает текущую цену вместо снимка, опыт покажет расхождение после обновления каталога.

Далее создают длинную сборку, чтобы таблица заняла несколько страниц. Режим и итог должны оставаться связанными с нужным расчётом. Иногда данные переданы правильно, но строка уходит за границу PDF. Поэтому сравнивают промежуточный шаблон и готовый файл, если такой путь доступен. Арифметическая и визуальная приёмка имеют разные причины отказа.

Неопределённый или отсутствующий режим проверяют отдельно. Система не должна выбирать коммерчески значимую модель по тайному умолчанию. Возможен отказ формирования или требование уточнить данные по согласованному процессу. Именно этот отрицательный опыт помогает избежать ситуации, когда письмо выглядит убедительно, но отражает предположение, которого пользователь не подтверждал.

Смежная тема разобрана в материале Разработка интернет-магазина с конфигуратором товара.

Вопросы по теме

Как сохранить одинаковые сведения о НДС на экране, в письме и в PDF?

Чтобы выбранный режим НДС не терялся в письме и PDF, нужно передавать единый снимок расчёта из конфигуратора во все документы. Шаблоны не должны самостоятельно угадывать режим или повторять разные формулы. Проверяют исходные суммы, отображение налога, округление и повторную отправку. В статье используется учебная модель, без назначения универсальной ставки или налоговой рекомендации.

Документация и источники

• 1С-Битрикс: обмен с 1С: Наличие компонентов обмена CommerceML; конкретные правила проекта проверяются отдельно.