Автоматизируем ваш бизнес
на платформе 1С

В ходе разработки функции списания бонусных баллов на сайте обнаружено, что реальные покупатели, совершавшие покупки с картой лояльности (чеки ККМ, реализации, заказы клиентов), баллы не получали, хотя тестовые данные показывали корректную работу механизма. Диагностика показала: начисление в 1С:УТ 11 реализовано не через справочник "Правила начисления и списания бонусных баллов" (он предназначен для условных периодических начислений вроде дня рождения), а через типовой механизм скидок/наценок с особым способом применения "Начисление бонусных баллов". Скидка была настроена корректно (3% от суммы, программа "Розница"), но получатель ошибочно был ограничен списком из 2 конкретных карт вместо общего условия "все держатели карт программы". После исправления условия получателя скидки написан запрос по всем документам с непустым реквизитом "Карта лояльности" (Заказ клиента, Реализация товаров и услуг, Чек ККМ) за период простоя правила, данные агрегированы по картам лояльности. Для реализаций и заказов клиентов клиент пересчитал скидки самостоятельно — правило сработало автоматически задним числом. Отдельно написан и выполнен скрипт доначисления по 36 картам держателей на основании чеков ККМ (где табличная часть начисления оставалась пустой, автоматика не отработала) — с указанием в комментарии каждого документа конкретных исходных документов-оснований для последующего аудита. Дополнительно выявлена особенность типовой логики: при наличии связанного заказа клиента сумма для начисления бонусов делится между заказом и реализацией (в реализации считаются только позиции "сверх заказа") — это учтено при интерпретации расхождений в расчётах.

Со стороны 1С реализован HTTP-сервис (ЕДС_ДанныеИз1СУТ, метод GET /balance), возвращающий текущий остаток бонусных баллов клиента по регистру накопления БонусныеБаллы, с суммированием по всем бонусным программам лояльности. Идентификация клиента — по штрихкоду карты лояльности (Справочник.КартыЛояльности) или по номеру телефона (табличная часть контактной информации справочника Партнеры, с нормализацией формата номера). Авторизация запросов — двухуровневая: Basic Auth реальным технической учётной записью ИБ (обязательное требование хостинга на уровне платформы) плюс собственный секретный токен в отдельном заголовке X-Loyalty-Token (поскольку заголовок Authorization уже занят под Basic Auth). В процессе разработки и тестирования на реальных данных выявлены и исправлены: несовпадение имени реквизита карты лояльности с синонимом в интерфейсе, отличие фактической структуры хранения контактной информации от предполагаемой типовой, отсутствие ограничения периода в запросе остатков (некорректно учитывались ещё не наступившие движения активации баллов), и — самое нетривиальное — потеря заголовка авторизации из-за нормализации регистра HTTP-заголовков при работе по HTTP/2 между сервером сайта и хостингом 1С (заголовки на сервере хостинга приходят в нижнем регистре, что потребовало регистронезависимого поиска в коде 1С). Со стороны сайта (PHP, 1С-Битрикс) реализован вызов HTTP-сервиса из шаблона компонента bitrix:sale.personal.account, с идентификацией клиента по номеру телефона из его профиля; при недоступности 1С или отсутствии данных блок с баллами просто не показывается, не влияя на остальной функционал страницы. Учётные данные для доступа к 1С вынесены из шаблона в защищённый конфигурационный файл /bitrix/php_interface/after_connect_d7.php.

Необходимо произвести обновление доработанной конфигурации Бухгалтерия 3.0 и ЗУП

После обновления УТ 11 до редакции 11.5.27.50 в двух внешних печатных обработках («Заказ клиента с штрихкодами» и «Счёт на оплату с штрихкодами») перестала работать функция получения штрихкодов номенклатуры. Основная причина — изменение сигнатуры метода РегистрыСведений.ШтрихкодыНоменклатуры.ШтрихкодыНоменклатуры(): вместо трёх позиционных параметров (Номенклатура, Характеристика, Упаковка) метод стал принимать единую структуру отбора. Функция ПолучитьШтрихкодыНоменклатуры() в обоих модулях переведена на новый формат вызова во всех точках использования (5 вызовов на файл). После этого вскрылась вторая проблема: менеджер регистра дополнительно требовал в структуре поле «Серия» (ошибка «Поле объекта не обнаружено»), которое было добавлено в структуру отбора без заполнения значением.

Задача заказчика — упростить работу кассира с программой лояльности: видеть остаток баллов и имя клиента сразу при подборе карты, а также находить карту, если у покупателя нет её при себе, но известен номер телефона. Реализовано через расширение (без изменения типовой конфигурации): В информационную панель РМК добавлен вывод ФИО клиента и остатка бонусных баллов рядом с картой лояльности — через доработку типовой процедуры сборки данных панели. Остаток баллов рассчитывается через типовые серверные функции подсистемы бонусных программ лояльности (БонусныеБаллыСервер). В форму считывания карты лояльности добавлено поле ввода телефона с маской. При нажатии "Готово" система ищет партнёра по последним 10 цифрам телефона (устойчиво к форматам +7/8, пробелам, скобкам — так как контактная информация в базе хранится как свободный текст), находит его карты лояльности и, если карт несколько, предлагает выбор — используя типовой механизм формы.

В боевой базе накопились некорректные движения по регистру накопления "ПДВ_СебестоимостьЗакуп2" для организации "##". Разработана внешняя обработка с предварительным просмотром списка затрагиваемых документов-регистраторов и последующим точечным удалением строк набора записей только по нужной организации (без отмены проведения самих документов и без затрагивания других организаций в тех же регистраторах).