Портфолио

Списание недостач по инвентаризации не проводилось: программа сообщала о нехватке товара, хотя складская ведомость показывала остаток. Разбор показал, что УТ ведёт остаток организации в разрезе ключей аналитики (товар + склад), и в части документов ключи оказались неверными. Причины три: в проведённых документах меняли номенклатуру или склад, при объединении дублей номенклатуры остатки повисли на ключах, недоступных документам, а один ключ в справочнике указывал на чужой товар. Всего неверные ключи нашлись в 331 документе, остатки организации и склада по основному складу расходились на 255 единиц. Перепровести всё было нельзя: часть периода закрыта блокировкой, а перепроведение задним числом ломает закрытые месяцы. Поэтому разработали внешнюю обработку. Она находит неверные ключи и одной корректировкой регистров на начало года переносит накопленное расхождение на правильные ключи — и по количеству, и по себестоимости, чтобы закрытие месяца проходило без ошибок. Документы текущего года обработка перепроводит сама, временно снимая контроль остатков. Есть режим проверки, который ничего не меняет, а повторный запуск безопасен. Для закрытия месяцев подряд сделали отдельную обработку. Всё отработали на копии базы и передали клиенту пакет с пошаговой инструкцией и контрольными цифрами для сверки.

Компания собирает подарочные наборы. Закупщики вели расчёты в Google-таблице и постоянно переключались между 1С, таблицей и сервисом коммерческих предложений. Ссылки на товары и согласованные цены хранились вне учёта, а переплату по закупке замечали только через месяц. Сделали доработку в расширении. Типовые формы не копировали: новые колонки и подсветка добавляются программно через штатные точки конфигурации, поэтому обновлять УТ будет проще. В заказе на сборку закупщик видит: согласованную цену из КП; иконку товара; ссылку, где купить; поставщика — основной подставляется сам по приоритету из карточки номенклатуры; комментарий. Иконки уменьшаются на сервере: платформа сама уменьшать картинки не умеет, поэтому использован приём с конвертацией через SVG, плюс кэш. Из заказа печатается спецификация для закупа с фотографиями. В заказе поставщику цена из КП подтягивается из заказа на сборку и пересчитывается под упаковку строки. Строка с ценой выше согласованной выделяется красным. Поддержаны оба способа создания заказов: на основании заказа на сборку и массово, обработкой формирования заказов поставщикам.

Компания печатает из заказа клиента счёт-договор в Word, это внешняя печатная форма. Поле «Стоимость доставки» всегда было пустым, а «в т.ч. НДС» не учитывал доставку, хотя общий итог был верным. В коде формы нашлась ошибка при подготовке итогов: сумма доставки записывалась не в своё поле и терялась. НДС доставки к итогу не прибавлялся. При разборе нашлись и скрытые проблемы: доставкой считалась любая услуга, поэтому «Упаковка и комплектация» пропадала из таблицы; для заказов с ценой без НДС итог печатался без налога; в счёт попадали отменённые строки; колонка «№» была пустой из-за ошибки в шаблоне Word; форма была привязана к несуществующему документу и могла пропасть из меню при обновлении. Всё исправили. Результат проверили, сравнив документы старой и новой версии на реальных заказах.

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

Закрытие 3 квартала в БП — что сделано Сначала проверил базу и нашёл, что мешало закрыть квартал: сентябрь почти не был проведён: обмен приносит документы из УТ непроведёнными; август не был закрыт; июль нужно было перезакрыть; на 41.01 были минусы; часть сборок стояла по времени позже реализаций того же дня. Всё исправил на копии, закрыл квартал и проверил. Затем копию перенесли на рабочую. Что изменено в документах: Добавил сборки от 01.07 — пары к уменьшенным сборкам 2 квартала, как в УТ: ОРБП-000001, 000002, 000003. Восстановил и провёл поступление Соколовой № 75 от 14.08. 11.09 его перезаписал обмен. Списания недостач ОРУТ-000022, 000023, 000024 поставил по времени после сборок того же дня и провёл. Провёл около 1 000 документов сентября: реализации, сборки, корректировки, счета-фактуры. 648 сборок сентября поставил по времени раньше реализаций, чтобы товар сначала собирался, а потом продавался. Расхождения входящих остатков БП и УТ закрыл оприходованием ОРБП-000009 от 01.09: 049127311A — 2 шт., 06569372256 — 1 шт. Поступление № 81 поставил на 18.08 9:57, раньше реализации ОРУТ-005819. В поступлениях Соколовой заполнил номер и дату документа поставщика. Нашёл, почему корректировки Соколовой ОРУТ-000029 и 000033 давали минусы. В БП они остались в первоначальном виде, по три позиции, а в УТ их 11.09 исправили до одной позиции — возвращённого товара. Корректировки приведены к версии УТ. После этого минусов на 41.01 за квартал нет. Июль, август и сентябрь закрыты. Доработка: расширение «ЕСП_ДоработкиБП» (версия 1.0.0.15) Корректировки реализации, которые приходят обменом из УТ, раньше загружались без счетов учёта. Их приходилось заполнять вручную, а повторный обмен затирал исправления. Теперь расширение само заполняет счета при загрузке, и корректировки проводятся без ручной правки. Расширение стоит на рабочей базе.

Руководитель попросил: если товара в ячейке нет две недели, переводить его в «Без ячеек»; показывать освободившиеся ячейки и выгружать их в Excel; посчитать стоимость склада и хранения одной ячейки; понять, есть ли смысл держать большой запас. Сделано расширением к УТ 11.5, три вкладки: «К очистке». Товары с остатком 0 и без движения дольше N дней (параметр) переносятся в «Без ячеек» кнопкой или регламентным заданием по расписанию сервера. Каждое изменение пишется в новый регистр «История мест хранения»: была ячейка, стала, кто и когда. Руководителю уходит письмо со списком освободившихся ячеек. «Свободные ячейки». Ячейки без закреплённого товара, отсортированные с учётом номера внутри названия (A-2 раньше A-10). Печатный «Список для обхода» с клетками для отметок, выгрузка в Excel. «Стоимость ячеек». Аренда склада делится на занятые ячейки — получается стоимость хранения. Прибыль ячейки считается по реализациям: выручка без НДС минус себестоимость Закуп2, справочно — минус типовая себестоимость. Сравнение прибыли с хранением даёт решение с подсветкой: «Закупать много», «Брать понемногу у конкурента», «Не окупает хранение». Ещё на вкладке: сводка и лучшие ячейки; поиск ячейки; детализация по товарам ячейки; предупреждение, если месяц не закрыт или «открылся». Весь расчёт вынесен в модуль обработки. Его проверили без интерфейса через COM: независимый запрос, написанный заново, сверен по всем ячейкам за 30 и 60 дней. К обработке — инструкция в Word со скриншотами и описанием показателей.

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

Менеджер отправлял УПД клиентам вручную из формы печати: около 20 писем в день, двумя волнами, утром и вечером. Часть документов терялась: примерно по 9% отгрузок УПД клиенту не уходил. Была и тонкость: без проведённого счёта-фактуры та же печатная форма выходит со статусом 2, а клиенту нужен УПД со статусом 1. Сделал отдельное расширение, типовую конфигурацию и чужие доработки не трогал: Когда уходит письмо. Только если реализация проведена, клиент в списке рассылки и по реализации есть проведённый счёт-фактура. В готовом файле дополнительно проверяется «Статус: 1». Если счёта-фактуры долго нет, ответственный получает оповещение. Тот же файл, что при ручной печати. УПД формируется той же командой печати и с теми же параметрами печати менеджера: файл совпадает с ручным байт в байт. Без дублей. Если менеджер уже отправил УПД этому клиенту вручную, повторное письмо не уходит. Защищено и от одновременного запуска по расписанию и по кнопке. Гибкое расписание. Несколько раз в день в заданное время, каждые N часов или сразу после готовности. Есть скрытая копия писем на рабочую почту компании. Кнопка «Отправить УПД клиенту» в документе для разовой или повторной отправки. Панель управления: настройки, список клиентов (заполняется по истории писем) и журнал статусов по каждой реализации. Колонка в журнале документов продажи. Значок показывает: УПД отправлен клиенту, ушёл на тестовый адрес или требует внимания. Колонка работает у всех пользователей, а не только у администраторов, и не мешает обновлениям конфигурации. Контроль проблем. Отслеживаются изменения документа после отправки, ошибки почтового сервера, отклонённые адреса. Ответственный получает одно письмо-оповещение, без повторов. Безопасный запуск. Тестовый режим включается отдельной галочкой и по умолчанию включён: клиентам не уходит ничего ни автоматически, ни по кнопке, все письма идут на тестовый адрес. В каждом письме указано, кому оно ушло бы в рабочем режиме и не было бы оно дублем.

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

За годы работы на серверах и рабочих машинах накапливаются десятки выгрузок баз и файловых баз: копии перед обновлением, архивы, тестовые развёртывания. Место на диске уходит, а что именно лежит и насколько оно старое — никто не знает. Сделал скрипт, который обходит все локальные диски и собирает единый отчёт: полный путь, размер в гигабайтах, дата создания и дата последнего изменения. Файлы сортируются по размеру, сверху сразу видны самые тяжёлые. В шапке отчёта — итог по количеству и суммарному объёму. Первая версия работала медленно и без обратной связи, поэтому переработал обход: вместо трёх проходов по дискам (по одному на каждое расширение) остался один, а системные каталоги вроде Windows исключаются как заведомо бесполезные. Добавил полосу прогресса с процентом, счётчиками просмотренного и оценкой оставшегося времени, а также строку по каждой завершённой папке — сразу видно, что процесс жив и сколько ещё ждать. Скрытые и недоступные папки скрипт пропускает молча, но считает их и сообщает в отчёте: если запускали не от администратора, это заметно сразу. Отдельно довёл до ума переносимость, чтобы скрипт можно было отдать на любую машину: определение дисков работает тремя способами подряд (для старых версий Windows), кодировки подобраны так, чтобы кириллица не ломалась ни в консоли, ни в отчёте, а к скрипту приложен bat-файл для запуска двойным кликом — без объяснений про PowerShell и политики выполнения. Скрипт только читает файловую систему: ничего не удаляет, не перемещает и не изменяет.

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

Менеджеры по продажам работали под широкими правами. Им были видны суммы и печатные формы по заказам коллег, реализации, отчёты по выручке и другие лишние разделы. Компании нужно было, чтобы каждый менеджер полноценно вёл только свои заказы, а права новому сотруднику назначались в один шаг. Что сделано: Профиль и группа доступа «Менеджер по продажам». Их создаёт внешняя обработка. Её можно запускать повторно: состав прав возвращается к эталону, а список сотрудников в группе не меняется. В профиле только нужное: заказы клиентов, чтение справочников и остатков, просмотр заказов на сборку. Свой и чужой заказ. «Своим» считается заказ, который сотрудник создал сам. Чужой заказ открывается только для просмотра. В нём скрыты цены, суммы, скидки, итоги и этапы оплаты. Кнопки записи и проведения убраны, печать заблокирована. Запись чужого заказа запрещена и на сервере, поэтому запрет нельзя обойти через список или групповую обработку. В списке заказов денежные колонки по чужим заказам пустые. Совместимость с существующим расширением. Учёт брендирования работает в режиме ограниченных прав, а в заказе клиента появилась кнопка перехода к заказам на сборку. По ним менеджер видит состав заказанного подарочного набора, в том числе в заказах коллег. Отчёт о товарах поставщиков для закупщиков. Рядом с ценой последней закупки появились цена по выбранному виду цен и дата, с которой она действует. Повторная установка той же цены дату не сдвигает. Инструкции. Подготовил для менеджеров по продажам, для закупщиков по отчёту и для администратора по назначению прав новым сотрудникам. Все доработки сделаны в расширениях, без изменения типовой конфигурации, и сначала отлажены на копии базы.

Компания торгует медицинским трикотажем и ортопедическими изделиями. Одна модель выпускается в нескольких типоразмерах и цветах, и наименования отличаются одним-двумя символами. Склад собирал заказы по типовой печатной форме «Заказ клиента». В ней цены, ставки и суммы НДС, а размер и артикул теряются в длинном наименовании. Кладовщики вручную обводили маркером размер, артикул и количество. Я сделал отдельную печатную форму «Заказ клиента (Для склада)». Шапка, реквизиты сторон и подпись берутся из типового макета, поэтому форма выглядит привычно и подхватывает правки макета, если они будут. В таблице осталось четыре колонки: номер, товар, количество и единица измерения. Колонка товара расширена на всю ширину листа. Размер и артикул в карточках товаров не хранятся отдельными реквизитами, они записаны прямо в наименовании в разных вариантах. Поэтому форма разбирает наименование по правилам и выделяет жирным только значимую часть: «Типоразмер № 4», вид изделия с номером, длину и ширину бинта, значение артикула. Количество и единица выводятся жирным целиком.

Оптовая компания получает заказы от клиентов файлами Excel и загружает их в учётную систему своей обработкой. Каждый клиент присылает файл в своём формате, обработка разбирает его, находит товары по артикулу и бренду и создаёт заказ. Цены при этом переносились из файла как есть. Если клиент работал по старому прайсу или ошибся в цене, заказ уходил в работу с неправильными суммами, и замечали это уже после отгрузки. Встроил проверку в момент создания заказа, не меняя сам механизм загрузки. Строки файла сопоставляются с номенклатурой по тем же правилам, что и при создании заказа: бренд через справочник соответствий, затем артикул. Для каждой найденной позиции берётся действующая цена по виду цен, закреплённому за клиентом, с приведением к цене с НДС. При расхождении в форме открывается отдельная вкладка. Там по каждой строке видно цену из файла, цену в 1С, разницу в рублях и отклонение в процентах. Одновременно появляется вопрос с тремя вариантами. По умолчанию выбрана остановка загрузки, чтобы заказ со спорными ценами нельзя было создать случайно. При замене на цены из 1С суммы строк и итог пересчитываются автоматически. Позиции без цены в учёте, ненайденные товары и внутренние заказы проверкой не блокируются, о них по-прежнему сообщает основная загрузка. Доработку наложил на актуальную версию расширения с рабочей базы и сверил файлы, поэтому параллельные изменения других разработчиков не потерялись.

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

У оптовой компании несколько сотрудников ежедневно переоценивают товары: руководитель выдаёт каждому пул позиций, сотрудник проходит его по одной позиции в специальном рабочем месте. Проблема была в том, что никто не видел картину в моменте. Понять, успевает ли человек закрыть выданное за день, можно было только постфактум, а качество работы не отслеживалось вовсе: позицию можно пролистать за секунду, и в учёте она считалась обработанной наравне с остальными. Штатный отчёт показывал завышенные цифры, потому что учитывал каждую запись по каждому виду цены и считал за работу любой простой с открытой позицией. Разработал отдельный модуль контроля в расширении. Он считает выработку по уникальным позициям, отделяет активное время от простоя (всё, что дольше десяти минут на одной позиции без нажатой паузы, уходит в простой) и отдельно помечает позиции, закрытые быстрее порога и без изменения цены. Норма темпа берётся от восьмичасового бюджета активной работы, делённого на размер дневного пула, поэтому она подстраивается под объём и не зависит от часового пояса сотрудника. В рабочее место добавил цветную плашку на поле HTML-документа с анимированным индикатором состояния и полосой прогресса, где отдельно видна доля реально обработанных позиций. Руководителю настроил два регламентных задания: короткая сводка каждые два часа и подробный недельный отчёт с выборкой пролистанных позиций для выборочной проверки. Все пороги вынесены в настройки.

Прайс поставщика приходит на почту вложением в Excel и попадает в базу пересылкой на служебный ящик. Менеджер открывал письмо, сохранял файл и прогонял его через обработку загрузки — ручная операция, которую легко забыть или сделать по устаревшему письму. В конфигурации уже был код загрузки из почты, но он ни разу не запускался: регламентного задания не существовало, а сам код содержал две ошибки в работе со стандартной библиотекой и падал при первом обращении к вложению. Обе исправил и добавил регламентное задание. Логику отбора писем переработал. Рассматриваются письма за скользящие сутки, из них берётся самое свежее по дате отправки, в котором реально есть файл прайса. После успешной загрузки более старые письма гасятся, чтобы устаревший прайс не применился следующим запуском. Отдельная часть работы — доводка на боевой почте. Выяснилось, что при пересылке в тему и имя файла попадают невидимые символы, из-за которых точное сравнение не срабатывало, а несколько отборов в запросе отсекали настоящие письма. Сделал сравнение нечувствительным к таким вещам: тема ищется по ключевому слову, имя файла сравнивается после нормализации, лишние фильтры убраны. При этом каждое пропущенное письмо теперь пишется в журнал регистрации вместе со списком его реальных вложений — разбирать такие случаи можно по журналу, без отладчика. Механизм прогнал сквозным тестом на копии базы: письмо, вложение, разбор файла, создание и проведение документа установки цен, запись остатков. Отдельно проверил, что повторный запуск не создаёт второй документ.

У клиента был механизм загрузки прайса от поставщика (ручной из файла и автоматический из входящей почты) — он создавал документы установки цен и обновлял остатки. Данные о сертификатах соответствия при этом велись отдельно и заполнялись вручную, что при большом ассортименте отнимало время и приводило к устаревшей информации. Я встроил в единую точку разбора прайса обновление двух реквизитов номенклатуры: ссылки на сертификат и срока его действия. Логика построена аккуратно: значение перезаписывается в карточке только если оно пришло из прайса и реально отличается от текущего, а пустая ячейка не затирает уже имеющиеся данные. Поскольку обе цепочки загрузки (ручная и почтовая) сходятся в одном месте, доработка одинаково работает в обоих сценариях. Также заложил переключение на колонку срока из файла — на случай, если поставщик начнёт передавать её в выгрузке. Перед переносом на рабочую базу решение проверено на копии автоматическим прогоном по реальному файлу прайса.

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

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

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

Владелец сети из двух розничных магазинов не мог оперативно смотреть показатели бизнеса: всё было внутри 1С, куда он заходил редко, а сводить цифры по двум точкам приходилось вручную. Сделал автоматический канал выгрузки: регламентное задание в 1С раз в час собирает данные запросами и отправляет их HTTP-запросом в Google Apps Script, который раскладывает всё по листам таблицы. Отдельно проработал схему авторизации так, чтобы не требовалось криптографии на стороне 1С — это упростило внедрение и обслуживание. В таблице 15 листов. Пять с деньгами и остатками: выручка по документам (опт и розница отдельно), расходы по статьям, остатки товаров в закупочных ценах, долги клиентов и поставщиков, остатки по счетам и кассам. Ещё шесть с первичкой: реализации и чеки ККМ, проданные позиции с расчётом маржи, документы закупки, закупленные позиции, возвраты товаров и возвраты денег. Плюс зафиксированные начальные остатки как точка отсчёта, сводка со сравнением точек и диаграммой, справка по листам и журнал выгрузок. Данные выгружаются в «сыром» виде, по документам, с датами и контрагентами — чтобы поверх них можно было строить любые свои отчёты и сводные таблицы, а не только смотреть готовые цифры. Отдельно разобрался с нетривиальными местами учёта: розничная выручка через кассы ККМ проходит по другому регистру, чем оптовая, а оплата поставщикам вообще не попадает в статьи расходов. Все суммы сверил с типовыми отчётами 1С. Листы защитил от ручного редактирования, настроил форматирование, фильтры и подсветку проблемных значений.

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

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

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

Помогло пересоздать папку с переносом основных данных C:\Program Files\1cv8\srvinfo

Со стороны 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" для организации "##". Разработана внешняя обработка с предварительным просмотром списка затрагиваемых документов-регистраторов и последующим точечным удалением строк набора записей только по нужной организации (без отмены проведения самих документов и без затрагивания других организаций в тех же регистраторах).

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

В обработке ВПФ «Товарный чек» добавлена регистрация назначения для документа «Заказ клиента» в СведенияОВнешнейОбработке(). В функции формирования печатной формы реализовано определение типа документа-основания (ТипЗнч), на основании которого динамически подставляется имя таблицы документа в текст запроса — для «Заказа клиента» и «Реализации товаров и услуг» состав табличной части «Товары» и шапочные реквизиты идентичны, поэтому логика формирования самого чека (шапка/тело/подвал, настройки печати на чековый принтер XP-80C) осталась без изменений.

В автоматическом модуле ПДВ_ВыгрузкаПрайсов в запрос формирования таблицы товаров добавлена временная таблица ВТ_Ц3 (вид цены "##") по аналогии с ####, заведена колонка Цена ##, добавлен 6-й блок выгрузки с макетом МакетНаличияНовыйНашСайт и файлом Прайс_##.xlsx. В ручной процедуре ОтправкаФайловНаFTP использовано уже существующее поле Цена##табличной части (оно давно заполняется реальной ценой ##, а не через старую функцию ЗаполнениеЦеныНоменклатурыМин) — добавлен аналогичный блок сохранения без FTP/копирования в подпапку, только запись в D:\ftp\Выгрузка прайсов из 1с\. Фильтр остатков — по образцу ##. Подключены исключения через ПДВ_ИсключенияПрайсов / Перечисления.ПДВ_ВидПрайса.##.

В компании ведётся автоматическая выгрузка 5 прайс-листовна FTP для разных контрагентов-получателей. Ранее фильтрация строк ограничивалась только логикой остатков ("0шт."), без возможности вручную исключить конкретные позиции из отдельного прайса. Реализовано: новое перечисление видов прайсов, независимый регистр сведений для хранения исключений (с привязкой к прайсу и возможностью задать исключение по номенклатуре, марке или артикулу), общая серверная функция получения списка исключений, интеграция фильтра в оба действующих механизма выгрузки — актуальный (единая функция СобратьТаблицуДляПрайса) и старый ручной (5 отдельных блоков в процедуре ОтправкаФайловНаFTP). Для управления списками сделана отдельная форма с 6 независимыми таблицами (общий список + по одному на каждый прайс), открывается кнопкой с формы ручной выгрузки.

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

В расширении отчёта фильтр расшифровки (drill-down) по клику на сумму в дереве отчёта безусловно применял условие Проект В Иерархии(&Проект). Для обычных проектов это работало корректно, в том числе с учётом иерархии "Группа" в справочнике Проектов. Однако для двух служебных узлов дерева — "Без проекта" (пустая ссылка) и "Без направления деятельности" (в коде передаётся как текстовая метка, а не ссылка на Проект) — такое условие либо не срабатывало как фильтр вообще, либо сравнивало несовместимые типы данных, из-за чего в расшифровку попадали документы, относящиеся к совершенно другим проектам и направлениям деятельности. Диагностика проводилась пошагово через отладчик: проверка движений документов, сравнение справочных данных (Проекты, Направления деятельности), проверка значений на конкретных точках останова в коде типового и доработанного модулей отчёта.

Команда «Заполнить по поступлению (по остатку)» в документе Реализация. Данные из регистра бухгалтерии по счёту 41.

Настройка и доработка стандартного обмена CommerceML. Решение конфликтов дублирования, фильтрация выгружаемой номенклатуры.

Внешняя печатная форма, формирующая КП в формате .docx с логотипом, таблицей позиций и итоговой суммой прямо из документа 1С.

Внешний отчёт с группировкой по направлениям деятельности, визуализацией статусов задач и возможностью drill-down по проектам.

Механизм автоматического формирования заказов поставщикам на основе дефицита по клиентским заказам с учётом минимальных партий.

Разработали обработку загрузки заказов и остатков с трёх маркетплейсов. Автоматическое создание номенклатуры, сопоставление артикулов, обновление цен.