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

Оптовый продавец автозапчастей рассылает партнёрам шесть прайс-листов, которые формируются в УТ 11.5 автоматически. Партнёры начали требовать в прайсе сведения о сертификате соответствия: ссылку на запись в реестре или отметку «Не подлежит сертификации». В базе такого реквизита не было, а срок действия сертификатов никто не отслеживал. Сделал отдельное расширение с двумя реквизитами номенклатуры — «Сертификат» и «Срок годности сертификата». Поля выводятся в карточке товара рядом с размерными характеристиками. Форму номенклатуры уже меняло расширение партнёра, и прямое расширение той же формы вызывало конфликт, поэтому поля добавляются через штатную точку расширения форм БСП — без правки формы и без конфликтов с чужими доработками. В механизм автоматической выгрузки прайсов добавил две колонки: сертификат и срок его действия. Колонки появились во всех шести прайсах, макеты файлов остались прежними, так что партнёры получают привычный формат с двумя новыми столбцами. Для контроля сроков расширил монитор учёта, который уже работал у клиента: новая проверка отбирает позиции с истёкшими и истекающими в ближайшие 30 дней сертификатами, включает их в общий отчёт и раз в день отправляет отдельное письмо ответственному. Горизонт и получатели настраиваются в форме.

Компания ведёт продажи в УТ 11.5, бухгалтерия — в БП 3.0, между базами настроен типовой обмен. При закрытии месяца выяснилось, что десятки реализаций и корректировок в БП не проводятся из-за контроля остатков, а отчёт по отрицательным остаткам показывает минусы по товарам, которых в УТ в достатке. Сверка двух баз по дням и типам документов показала три независимые причины. Первая — обрыв обмена в один из дней месяца: в БП не доехали 138 сборок товаров, 9 реализаций и 68 возвратов, а счета-фактуры за этот день пришли, но не провелись. Вторая — порядок документов внутри дня: УТ создаёт сборки товаров автоматически уже после реализации, под которую они нужны, и допускает минус внутри дня, а БП проверяет остаток на момент документа. Таких случаев за месяц набралось около 650. Третья — входящие остатки на начало месяца по нескольким десяткам позиций отличались от УТ ещё с прошлого года и проявились, когда товар в УТ дошёл до нуля. Для досылки документов сделал внешнюю обработку регистрации к обмену по типу, периоду и номерам. Обработку исправления порядка документов доработал так, чтобы она видела непроведённые реализации и умела сдвигать цепочки сборок, где компонент одной сборки производится другой ещё позже, — благодаря этому контроль остатков в БП отключать не пришлось. Расхождения входящих остатков закрыл оприходованием по списку. В расширение для БП добавил автозаполнение счетов учёта в документах, приходящих обменом, — без счетов проверка возврата давала ложную ошибку. Первопричину устранил на стороне УТ отдельным расширением: новой автоматической сборке при создании ставится время начала дня, после приходов её компонентов, так что она всегда оказывается раньше реализации. Всё отработано на копиях, затем повторено на рабочих базах по пошаговой инструкции, доступа к рабочему серверу не требовалось.

Клиент фармацевтической торговли работает на УТ 11.5, в основную конфигурацию которой встроено около 50 объектов обмена с терминалами сбора данных DataMobile, плюс шесть расширений с доработками отгрузки и выгрузок для контрагентов, десятки патчей 1С и внешние печатные формы со штрихкодами. База не обновлялась несколько релизов, а первая попытка обновления закончилась ошибкой компиляции при запуске: в типовом модуле смешались процедуры старой и новой версии. Начал с инвентаризации: сравнил основную конфигурацию с конфигурацией поставщика и точно определил, что именно доработано, а что является техническим мусором прежних обновлений. Выяснил, что сам клиент типовые модули не менял, а все доработки живут в расширениях, и это позволило безопасно отдать приоритет поставщику. Отрепетировал обновление на копии: три последовательных объединения (.61, .79, .81), после каждого автоматизированное сравнение с поставщиком по всей конфигурации, проверка целостности ключевых модулей и контроль, что объекты DataMobile не отмечены на удаление. Только после чистого сравнения применялось обновление базы данных. После обновления прогнал проверку применимости всех расширений. Два расширения с механизмом «Изменение и контроль» не подходили к новой версии, причём, как показал разбор, они не работали ещё до обновления: в них лежала копия типового кода более старой версии. Одно из них пересобрал на актуальном типовом тексте, сохранив доработку клиента (порядок строк приходного ордера по документу-основанию), второе клиент признал неиспользуемым. Для трёх внешних печатных форм провёл статическую проверку всех обращений к метаданным новой версии. По журналу регистрации выявил хвосты, которые нужно доделать руками: профиль прав с ролями, удалёнными поставщиком, и отключённые при переносе регламентные задания. Затем повторил всю схему на актуальной рабочей базе клиента. Попутно собрал набор скриптов для пакетного конфигуратора: сравнение с поставщиком и файлом, частичная выгрузка объектов, проверка применимости расширений, выгрузка и загрузка расширений, чтение журнала регистрации без входа в базу.

Клиент использует связку 1С:Управление торговлей 11.5 и 1С-Битрикс: Управление сайтом через модуль «Интернет-магазин + 1С» (кастомное расширение обмена с классификатором по свободной иерархии). Изначальный запрос — перевести схему разделов каталога с «произвольной иерархии» на «иерархию номенклатуры», чтобы менеджеры не забывали расставлять товары по разделам. Провели анализ кода модуля выгрузки на сайт (не по документации, а напрямую по исходникам расширения) и показали: смена источника иерархии меняет внутренние идентификаторы разделов, что при следующей выгрузке создаёт на сайте задвоенные/осиротевшие категории — то есть именно тот риск, которого клиент и опасался, только с другой стороны. Вместо рискованной смены настройки обмена реализовали точечное решение: серверная процедура, которая при каждом запуске проверяет специально назначенную «сигнальную» папку номенклатуры и добавляет ещё не распределённые товары в отдельную группу «Не распределённые» внутри существующей структуры каталога сайта (с самоисцелением на случай, если группа окажется не в том месте дерева). Реализацию сначала протестировали как расширение конфигурации на тестовой копии базы, затем перенесли в формат стандартной для 1С «Дополнительной обработки» (БСП) — это позволяет обновлять логику на лету, без монопольной блокировки базы и без риска помешать работающим пользователям.

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

Отчёт «О товарах поставщиков» существовал у клиента и раньше, но был неудобным: структуру поставщиков приходилось вести вручную в отдельном дереве категорий, поле «Приоритет» существовало формально и ни на что не влияло, а чтобы узнать, у кого и почём закупали товар в последний раз, менеджеру приходилось искать это в документах отдельно. Плюс накопился ряд багов: настройки не сохранялись, некоторые кнопки падали с ошибкой, защита ключевых разделов от случайного переименования не срабатывала. Отчёт перестроили вокруг реальной иерархии товаров — ручное ведение параллельной структуры больше не нужно. Приоритет поставщика теперь рассчитывается автоматически по фактической частоте закупок и обновляется сам при каждой новой закупке; полный пересчёт по всей истории закупок доступен отдельной кнопкой с предпросмотром изменений перед применением. В отчёт добавили статистику по каждому поставщику (число закупок, дата и цена последней) и остаток товара на складе — вся информация для решения о закупке видна сразу, без переключения между документами. Добавили гибкие отборы (по поставщику, товару, складу, диапазону остатка, цены и даты закупки) и отдельный режим «товары без поставщика» для быстрого поиска незакрытых позиций. Заодно исправили более 8 багов исходного механизма.