не указано значение в поле phrase

25.05.202226.05.2022 admin 0 Comments

Новые правила заполнения платежных поручений с 1 октября 2021 года

C 1 октября 2021 года начинают действовать новые правила заполнения платёжных поручений. Изменения внесли приказом Минфина от 14 сентября 2020 года № 199н. Рассказываем, как теперь заполнять платёжки.

Основания платежа

В поле «106» c основанием платежа значения «ТР», «ПР», «АП», «АР» больше использовать нельзя. При платежах, не связанных с налогами и сборами, таможенными сборами и пошлинами, поле «106» оставляйте пустым — тут изменений нет. При перечислении текущих налоговых платежей указывайте «ТП». При перечислении недоимки, пеней и штрафов в поле «106» вписывайте «ЗД».

Если в поле «106» указано значение «ЗД», обязательно нужно заполнить поле «108» — внести реквизиты документов. Например:

Сначала указывайте буквенный код вида документа, а потом без пробелов — номер документа. И не забывайте указать дату документа — основания платежа в поле «109».

Важно! Номер должен строго соответствовать значениям и количеству знаков, указанным в документе.

Продолжают действовать коды:

Статус плательщика

Перестают действовать статусы:

В поле «101» (статус составителя поручения) значение «13» (плательщик сборов, страховых взносов и иных платежей, администрируемых налоговыми органам) нужно использовать следующим плательщикам:

Налоговые агенты по-прежнему указывают статус «02».

Будьте внимательны при формировании платёжек и не забудьте изменить шаблоны для их заполнения.

Источник

Чек-лист для тестирования числового поля

При тестировании встречаются как интересные задачки с замудреной логикой, так и простые, вроде проверки простой строки или числового поля. Для простых полей можно один раз написать чек-лист проверок, а потом переиспользовать, лишь немного меняя под «своё» поле.

Сегодня мы разберем чек-лист для числового поля. Сначала я напишу общий чек-лист, потом пройдемся по каждому пункту и разберемся, зачем он нужен, а в конце напишем чек-лист по этому шаблону.

Итак, у нас есть некое поле, куда нужно вводить число. Например, поле «возраст» при регистрации:

При этом на сайте нельзя регистрироваться до 18 лет, есть запрещённый контент.

Какие проверки тут можно провести:

Корректные значения

Представьте, что у вас буквально 5 минут на проверку функционала. И вы успеваете провести только первые несколько тестов из чек-листа. А чек-лист у вас:

Для поля с возрастом какие у нас будут корректные значения? Все, что выше 18 лет:

Тут надо понимать, что мы выбираем какое-то ОДНО значение. Просто каждый раз разное, для избежания эффекта пестицида.

Также важно понимать, что у нас может быть не одно корректное значение. Это когда у нас есть несколько диапазонов, и разные условия на каждом.

Например, тот же возраст:

Или если у нас идет расчет страховки в зависимости от стажа вождения:

Каждый раз берем разные значения, но в этом пункте смысл один — взять корректные значения из ТЗ.

Некорректные значения

Тут есть разные варианты. Что значит некорректное значение?

— А что будет, если мы возьмем значение из «неправильного» диапазона? Что, если мне меньше 18 лет? Ну, скажем, 10.

Потом внимательно смотрим на выбранный интервал:

— Хммммм, но ведь возраст не может быть меньше 0. То есть у нас есть логическая граница, разделяющая два разных класса эквивалентности:

— Если у нас есть некая логическая граница снизу, должна быть и сверху. Какой максимально возможный возраст у регистрирующихся на нашем сайте? Скорее всего, это около 55-65 лет, потому что более старшее поколение не любит компьютеры. Но можно заложить и условные 100-110 лет долгожителей.

Получаем еще один интервал с неявной границей. Но в любом случае, значения 25 и 145 будут различаться — одно реалистичное, а другое нет. Значит, стоит его тоже попробовать!

А дальше снова эффект пестицида. Один раз берем 145, а другой — 6666666.

Тут мы можем столкнуться с тем, что в поле нельзя ввести больше 2-3 символов. Разработчик перестраховался «от дурака». Это не повод опускать руки и отказываться от своей проверки. Потому что скорее всего разработчик просто установил maxlength на поле, а он легко обходится!

Граничные значения

Граничные значения отделяют один интервал от другого. Их обязательно надо тестировать. Потому что именно на границах чаще всего встречаются баги. Почему? Да потому что попадают в оба диапазона, или не попадают ни в один.

В нашем примере в ТЗ есть условие «регистрация только для лиц старше 18 лет». Это значит, что разработчик должен сделать в коде программы логику вида:

Источник

Ошибка формата: значение поля не соответствует типу строка

Если посмотреть лог ошибок https://barberchair.ru/bych.errors.txt там строка ‘error’ => ‘Ошибка формата: значение поля \’href\’ не соответствует типу строка’.

Подскажите, что это за ошибка, как её решать?

Вероятно, что ошибка отдается вам в случае неверной ссылки на доп. поле в запросе на создание заказа. Вам необходимо проверить в каком формате передаются эти данные. Мы советуем максимально простой вариант заполнения доп. поля (в случае, если на момент создания документа, поле уже существует в системе).

При передаче заказа в теле запроса необходимо указать массив attributes в котором просто перечислить id поля и его значение:

Такой вариант подходит, если у вас используются поля Строка, Текст, Число целое, Число дробное.

Более подробно о работе с доп. полями вы можете посмотреть в документации.

Уточнение, вот, что приводит к проблеме. Сначала подозревали артикулы косячные у каких то товаров. Всё проверили. Оказывается не приходит заказ (не создается продажа), если оформляет его новый клиент. Только создается контрагент в МоемСкладе. При повторном оформлении, когда такой контрагент уже есть в системе, всё хорошо.

Значит дело не в массиве с товарами. Кто может помочь поправить модуль. пишите на sis1983@ya.ru

Войдите в службу, чтобы оставить комментарий.

Источник