В сентябрьскую подборку Инфостарт Маркетплейс вошли пять решений для совершенно разных задач в 1С. Здесь есть инструменты для разработчиков, автоматизация электронных перевозочных документов и банковских операций, а также решение для розницы, где важно корректно работать с МРЦ и кодами маркировки.
При этом у продуктов есть общая черта: каждый закрывает вполне конкретную рабочую проблему, которую неудобно решать вручную или которая не полностью покрывается типовыми механизмами. Где-то это поиск правильного объекта в большой конфигурации перед написанием кода, где-то – оформление одной перевозки по нескольким реализациям, а где-то – ежедневное скачивание банковских выписок из почты.
Разбираемся подробнее, какие решения вошли в сентябрьскую пятерку, как они работают и в каких сценариях могут пригодиться пользователям и специалистам 1С.
Что вошло в ТОП в сентябре
Разговор с универсальной языковой моделью может помочь разработчику написать фрагмент кода, но остается важный вопрос: действительно ли модель понимает устройство конкретной информационной системы? В типовой конфигурации с расширениями, собственными реквизитами и объектами с похожими названиями одного знания синтаксиса недостаточно.
Pilot 1C построен вокруг другой логики. Перед тем как предложить архитектуру или написать код, помощник собирает факты о конкретной конфигурации: ищет упомянутые в задаче объекты, проверяет их состав, связи, вызовы, роли и другие сведения, которые могут повлиять на реализацию.
Основным источником этих данных выступает Analyzer 1C. Из графа конфигурации Pilot получает ответ на вопрос «что действительно есть в системе», а не пытается восстановить структуру базы по похожим названиям из типовых решений. Если объект или связь подтвердить не удалось, помощник может запросить уточнение у разработчика вместо того, чтобы заполнять пробел правдоподобным предположением.
Второй источник – встроенный справочник знаний по 1С. Он содержит сведения об объектной модели платформы, типах, методах и свойствах, языке запросов и стандартах разработки. За счет этого код дополнительно сверяется с возможностями нужной версии платформы и правилами разработки.
При необходимости к работе подключается Insight 1C. Он помогает понять не только то, что описано в конфигурации, но и то, что фактически используется в базе. Например, если в системе присутствует несколько похожих объектов, Insight может показать, какой из них заполнен реальными данными, а какие существуют только формально.
Можно подключать и собственную документацию команды – регламенты, стандарты, описания внутренних решений в PDF, TXT или Markdown. После обработки эти материалы становятся дополнительным набором фактов, на который Pilot может опираться при работе над задачей.
Сам процесс разработки разбит на шесть этапов. Сначала выполняется исследование конфигурации. Затем формулируются требования, отдельно принимается архитектурное решение, после чего появляется структурированное техническое задание. На следующем шаге формируется результат – код или карта изменений – и завершается процесс сценариями проверки.
Каждый этап сохраняется отдельно, поэтому к нему можно вернуться. Если в ходе работы выяснилось, что решение нужно пересмотреть, не обязательно начинать задачу заново – можно продолжить с нужной фазы.
Предусмотрено пять режимов работы. В автоматическом режиме Pilot сам определяет подходящий сценарий по постановке. «Опрос» помогает прежде всего сформулировать саму задачу. «Выработка решения» проходит полный путь до кода и тестов. «Анализ» подходит, когда нужна справка по конфигурации без разработки, а режим код-ревью используется для проверки уже написанного кода.
Работать можно интерактивно или автономно. В первом случае помощник останавливается, если ему не хватает данных, и задает вопрос пользователю. В автономном режиме недостающие сведения фиксируются как предположения, после чего работа продолжается – такой вариант подходит, например, для получения первоначального черновика.
Перед выдачей результат проходит более 150 проверок. Проверяются синтаксис, наличие методов и свойств в используемой версии платформы, сигнатуры событий, контекст исполнения, работа с движениями и запросами, слой внесения изменений и соответствие стандартам разработки.
В итоговом материале отдельно показывается, какие выводы подтверждены найденными фактами, а какие остались предположениями. Это важно в тех случаях, когда часть информации невозможно проверить автоматически.
При этом Pilot не вносит изменения в информационную базу самостоятельно. Он отдает разработчику код и карту вставки, но применение изменений остается за человеком. Не запускает продукт и 1С:Предприятие для отладки на живых данных – такую проверку также выполняет специалист.
Материалы задачи можно выгружать в Markdown и Word. Техническое задание можно передать заказчику или другому разработчику, а сценарии тестирования формируются на русском языке Gherkin для Vanessa Automation.
Еще одна особенность – возможность развернуть рабочую часть продукта внутри контура компании. Сервер Pilot, его база и справочная информация могут работать локально. Языковая модель выбирается пользователем: подойдет сервер, совместимый с API OpenAI, в том числе локальный. Сама модель в поставку не входит.
Кому подойдет: разработчикам и аналитикам 1С, ведущим разработчикам, руководителям команд и интеграторам, которые работают с большими или доработанными конфигурациями и хотят сократить время на исследование системы перед реализацией задачи.
Технически: для полноценного сценария нужен Analyzer 1C с загруженной конфигурацией и доступом к графу по MCP. Сервер Pilot разворачивается через Docker. Поддерживаются конфигурации на платформе 1С:Предприятие 8.3, загруженные в Analyzer 1C. Insight 1C является дополнительным источником данных и не обязателен.
Организации, которые используют электронные перевозочные документы, могут столкнуться с ситуацией, когда типовыми средствами УТ или КА удобно оформить Электронную транспортную накладную или заказ-наряд, а сформировать именно Электронный заказ (заявку) непосредственно по реализациям оказывается сложнее.
Расширение добавляет этот участок в привычный процесс работы и рассчитано на цепочку «Реализация товаров и услуг → Электронный заказ (заявка) → Электронная транспортная накладная».
Первый сценарий – одна реализация соответствует одной перевозке. В стандартном меню документа «Реализация товаров и услуг» появляется дополнительная команда «Оформить ЭПД → Электронный заказ (заявка)». Пользователю не требуется отдельно переходить в журнал документов и переносить данные вручную.
Второй сценарий предназначен для ситуаций, когда одной машиной покупателю отправляется товар сразу по нескольким документам реализации. Для этого используется отдельное рабочее место «Формирование ЭПД из реализаций».
В рабочем месте пользователь задает период, организацию и контрагента. После заполнения отбора система показывает подходящие проведенные реализации. По каждому документу можно увидеть дату, склад, адрес доставки, сумму, количество грузовых мест, вес, объем, наличие неполных данных и информацию о том, сформирован ли ранее Электронный заказ.
Затем пользователь отмечает реализации, относящиеся к одной перевозке. Перед объединением расширение проверяет совместимость документов: они должны относиться к одной организации, одному контрагенту и иметь одинаковый адрес доставки. Это помогает исключить случайное объединение документов из разных перевозок.
Количество грузовых мест, масса и объем рассчитываются суммарно по выбранным реализациям.
Перед созданием документа открывается отдельное окно параметров. Здесь можно уточнить дату и время погрузки и выгрузки, перевозчика, транспортное средство, крайнее время подачи автомобиля и наименование груза. Часть параметров может подставляться из настроек автоматически, но перед формированием документа пользователь может изменить значения для конкретной перевозки.
В расширении предусмотрены значения по умолчанию для перевозчика, крайнего времени подачи транспортного средства, наименования груза, метода определения массы и источника адреса погрузки. В качестве адреса погрузки может использоваться фактический адрес организации либо адрес склада реализации.
После проверок создается стандартный документ УТ/КА «Электронный заказ (заявка)». В него автоматически передаются данные о грузоотправителе и грузополучателе, перевозчике, датах перевозки, адресах подачи, погрузки и выгрузки, описание груза, вес, объем, количество грузовых мест и параметры транспортного средства.
Отдельно рассчитываются характеристики груза. Для этого используются сведения из номенклатуры, упаковок и единиц измерения. Если в реализации используется упаковка и для нее заполнены характеристики, расчет идет по упаковке. Если этих данных нет, используются параметры основной единицы измерения.
Если определить вес или объем по информации в базе не удалось, пользователь получает предупреждение с перечнем проблемных позиций и может проверить данные до создания ЭПД.
Расширение также контролирует повторное использование реализаций. Если документ уже связан с действующим Электронным заказом, повторно включить его в новый заказ нельзя.
Связи с исходными реализациями сохраняются и после создания документа. Кроме того, номера документов-оснований автоматически записываются в комментарий Электронного заказа. Если впоследствии по нему создается ЭТрН, этот комментарий также переносится дальше по цепочке.
Важно, что расширение не создает отдельный механизм обмена с ГИС ЭПД. Оно помогает подготовить стандартный документ 1С. После создания пользователь видит его обычную форму, может проверить и скорректировать сведения, а дальнейшее подписание, проверка и отправка выполняются штатными средствами 1С.
Основная конфигурация при установке не изменяется – разработка поставляется как расширение.
Кому подойдет: компаниям, которые регулярно оформляют автомобильные перевозки и работают с электронными перевозочными документами, особенно если одна перевозка часто объединяет несколько реализаций.
Совместимость: 1С:Управление торговлей редакции 11 и 1С:Комплексная автоматизация 2.5/2.6. Основные сценарии протестированы на УТ 11.5.27.75 и КА 2.5.27.70, 2.5.27.81 и 2.6.1.59. Для других релизов может потребоваться дополнительная проверка совместимости, поскольку механизмы ЭПД изменяются между версиями.
КонфигРедактор — IDE для 1С: CF/EPF, синтаксис и ИИ в одном окне
Небольшая правка в модуле, просмотр нескольких процедур или работа с внешней обработкой не всегда требуют полного цикла работы в конфигураторе. На таких сценариях и сфокусирован КонфигРедактор – отдельная десктопная IDE для разработчиков 1С.
Программа работает с файлами CF, CFE, EPF и ERF. Встроенный проводник метаданных показывает дерево объектов и помогает быстро перейти к нужному модулю или форме.
Это может быть удобно, например, когда специалист получает конфигурацию клиента и сначала хочет изучить ее структуру, найти нужный документ и проверить код модуля, не переключаясь между большим количеством окон.
Сам редактор построен на базе Monaco. Поддерживаются вкладки, подсветка синтаксиса и автодополнение для типовых конструкций и БСП. Поэтому рабочий процесс ближе к привычной IDE: можно открыть несколько модулей одновременно и переключаться между ними, не закрывая предыдущие.
Отдельная функция – проверка синтаксиса на лету. Ошибки отображаются непосредственно во время редактирования и в статусной области. Это позволяет заметить часть проблем до того, как файл будет выгружен и запущен в 1С.
Один из типичных сценариев выглядит так: разработчик открывает CF клиента, находит модуль нужного документа, меняет процедуру и получает сообщение о синтаксической ошибке еще до сохранения результата.
Другой сценарий – работа с внешними обработками. EPF можно открыть, доработать код в редакторе и затем выгрузить готовый файл.
В программу также встроена ИИ-панель с учетом текущего контекста. Чат видит открытый пользователем код, поэтому к нему можно обратиться, например, с просьбой объяснить чужой BSL-фрагмент или помочь переработать запрос.
Для работы с ИИ предусмотрено два варианта. Первый – локальная Ollama на компьютере пользователя. В этом случае обработка выполняется локально и код не требуется отправлять в облачный сервис.
Второй вариант – облачный ИИ с использованием ключа из личного кабинета. Таким образом, пользователь может выбирать сценарий в зависимости от требований к инфраструктуре и данным.
КонфигРедактор рассчитан не только на разработку «с нуля». Его можно использовать и просто как инструмент быстрого просмотра нескольких модулей, проверки структуры конфигурации или анализа чужого кода.
Кому подойдет: разработчикам внедрения и сопровождения, фрилансерам, специалистам на аутсорсе и тем, кто регулярно работает с CF, CFE, EPF и ERF и хочет иметь отдельный редактор с вкладками, поиском и подсветкой.
При этом важно учитывать текущий статус продукта: КонфигРедактор находится в Beta, поэтому функциональность продолжает развиваться. При покупке предоставляется доступ к ИИ на три месяца.
Совместимость: продукт проверен на 1С:БП 3.0, 1С:ERP, 1С:ERP Управление предприятием 2, 1С:КА, 1С:УНФ, 1С:УТ и 1С:ЗУП. Код программы закрыт.
Автоматическая загрузка банковских выписок с почты
Получить банковскую выписку по электронной почте – обычный сценарий. Но если дальше сотруднику каждый раз приходится открыть письмо, сохранить вложение, перейти в 1С и отдельно загрузить файл, регулярная операция быстро превращается в рутину.
Расширение «Автоматическая загрузка банковских выписок с почты» для 1С:Бухгалтерии предприятия 3.0 переносит этот процесс непосредственно в учетную систему.
После установки обработка доступна в подсистеме «Банк и касса». Пользователь указывает учетную запись электронной почты, в которой требуется искать выписки, и настраивает правила их получения.
Поддерживаются два основных варианта поступления файла. В самом простом случае банковская выписка прикреплена непосредственно к письму – тогда обработка может получить вложение и использовать его для загрузки.
Второй вариант – банк присылает не сам файл, а ссылку на скачивание. Для такого отправителя можно настроить шаблон ссылки, по которому обработка определяет, откуда получить выписку. В исходном описании отдельно приводится пример подобного сценария для Сбербанка.
Файлы могут поступать в том числе в архивированном виде.
После настройки возможна работа в ручном режиме. Пользователь нажимает кнопку поиска, после чего найденные выписки появляются на соответствующей вкладке. Их можно проверить и затем запустить загрузку в информационную базу.
Такой режим удобен, если сотруднику важно самостоятельно контролировать момент загрузки или предварительно просматривать найденные документы.
Если же выписки поступают регулярно, процесс можно перевести в автоматический режим. Для этого используется регламентное задание «АЗВ автоматическая загрузка выписок», для которого задается подходящее расписание.
После этого поиск и загрузка могут выполняться без необходимости каждый раз запускать обработку вручную.
Практический эффект здесь достаточно понятен: сотруднику не требуется постоянно переключаться между почтой, файловой системой и 1С для выполнения одной и той же операции. Особенно заметно это становится в организациях, где банковские выписки поступают регулярно.
Есть и важное ограничение, которое стоит учитывать при настройке почты: на текущий момент обработка не ищет выписки во вложенных папках почтового ящика. Поэтому письма должны находиться в доступной для поиска папке.
Кому подойдет: бухгалтериям и организациям, где банковские выписки регулярно поступают на электронную почту и затем загружаются в 1С.
Совместимость: 1С:Бухгалтерия предприятия 3.0. В исходных данных указано тестирование на релизе 3.0.205.22.
МРЦ из марки: цена сигарет из кода маркировки и контроль чека для 1С:Розница 2.3 и 1С:УТ 11.5
При продаже сигарет возникает особенность, которой нет у большинства обычных товаров: максимальная розничная цена относится к конкретной пачке и содержится в ее коде маркировки.
На одной полке при этом могут одновременно находиться пачки одной номенклатуры со старой и новой МРЦ. В справочнике 1С у товара может быть установлена одна текущая цена, но для конкретной пачки допустимая максимальная стоимость будет другой.
Если кассир использует только цену из учетной системы, появляется риск продать часть товара дороже МРЦ, зашитой в маркировочный код.
Расширение решает эту задачу непосредственно во время работы с чеком. После сканирования пачки оно получает МРЦ из кода маркировки и устанавливает эту цену в соответствующей строке.
В 1С:Управление торговлей пачки одной номенклатуры с разной МРЦ при этом могут автоматически разделяться по разным строкам – каждая получает свою цену и пересчитанный НДС.
Но цена – только одна часть задачи. В исходном описании продукта обращается внимание еще на одну менее очевидную проблему: соответствие конкретного кода маркировки конкретной строке чека.
Перед пробитием типовой механизм может заново распределить коды между строками. Товары и маркировочные коды сортируются независимо, после чего сопоставляются по порядку. Пока у всех пачек одинаковая МРЦ, пользователь может не заметить разницы.
Сложность появляется, когда в одном чеке находятся, например, две пачки одной номенклатуры, но одна имеет МРЦ 160 рублей, а вторая – 170 рублей. Если код второй пачки окажется связан со строкой первой пачки, в ККТ и систему маркировки может уйти код с ценой, которая ему фактически не соответствует.
Расширение перед пробитием возвращает маркировочные коды на строки, цена которых совпадает с их МРЦ. Сам документ при этом не переписывается – корректируется состав данных, передаваемых в ККТ.
Третий механизм – контроль превышения максимальной цены. Если кассир пытается продать пачку дороже МРЦ, чек не пробивается, а пользователь получает понятное сообщение с названием товара, текущей ценой и МРЦ из марки.
При этом касса остается работоспособной – блокируется именно некорректная операция.
После установки доступно несколько настроек. Можно отдельно разрешить продажу дороже МРЦ, хотя по умолчанию такая возможность выключена. Также есть настройка остановки чека, если пачки одной номенклатуры продаются по разным ценам, и подробный журнал для диагностики.
Проверка не должна вмешиваться в уже завершенные операции: она не затрагивает пробитые, архивные и аннулированные чеки, возвраты, закрытие смены и архивирование. Если во время самой проверки возникает внутренняя ошибка, продажа не блокируется – информация записывается в журнал регистрации.
Разработка проверялась не только на тестовых примерах. В исходных данных приведены результаты прогона на копиях рабочих баз табачного магазина.
Для 1С:Управление торговлей анализировались 5 864 чека с табачной продукцией за август. Из них 64 операции были определены как продажи выше МРЦ. На 58 проверенных табачных позициях после обработки расхождений между МРЦ кода и ценой передаваемой позиции не осталось.
В 1С:Рознице до данных, передаваемых в ККТ, были доведены 154 чека, включая 90 позиций с МРЦ в коде. В контрольных сценариях с пачками разной МРЦ типовой механизм переставлял коды между строками, а расширение возвращало их к соответствующей цене.
Решение не требует изменения основной конфигурации. В базе не создаются собственные таблицы, поэтому установка, обновление и удаление расширения не требуют реструктуризации и монопольного режима.
Есть несколько ограничений. В «Рознице» работа рассчитана на новый РМК «Рабочее место кассира» – старый РМК в управляемом режиме при продаже не проверялся.
Кроме того, МРЦ берется только из тех маркировочных кодов пачек, где эта информация присутствует. Для блоков, стиков, сигарилл и кодов без МРЦ цена не изменяется.
После обновления конфигурации рекомендуется проверять корректность применения расширения, поскольку типовые процедуры в новых релизах могут изменяться.
Кому подойдет: табачной рознице, где в обороте одновременно находятся пачки одной номенклатуры с разной МРЦ и важно контролировать не только цену в чеке, но и ее соответствие конкретному коду маркировки.
Совместимость: решение проверено на «1С:Розница» 2.3.26.13 и «1С:Управление торговлей» 11.5.22.182 на платформе 8.5.1.1302.
Что объединяет сентябрьскую подборку
Сентябрьская пятерка получилась разноплановой: два решения адресованы прежде всего разработчикам 1С, еще три закрывают конкретные рабочие процессы пользователей – перевозочные документы, банковские операции и продажи маркированной продукции.
Но общий принцип у них один. Вместо попытки заменить целую учетную систему продукты автоматизируют отдельные участки, где много повторяющихся действий и необходимы ручной контроль или дополнительная проверка данных.
Для разработчика это может быть предварительное исследование конфигурации и проверка кода. Для специалиста по логистике – формирование Электронного заказа сразу по нескольким реализациям. Для бухгалтера – получение выписок без постоянного сохранения файлов из писем. Для розничного магазина – контроль МРЦ именно той пачки, код которой передается в систему маркировки.
Другие готовые инструменты для разработки, учета и автоматизации рабочих процессов можно посмотреть в каталоге Инфостарт Маркетплейс.
