Доработка 1С:УНФ под то, как вы работаете

Кому подходит УНФ и где она упирается

Конфигурация для небольших и средних компаний, которым нужен весь учёт в одном месте.

1С:Управление нашей фирмой выбирают торговые компании, сервисы и небольшие производства. В одной базе есть заказы покупателей, склад, закупки, деньги, зарплата и простое производство. Для старта этого хватает, и многие компании годами работают на типовой УНФ.

Упор начинается, когда компания растёт. Появляется второй склад, оптовые цены по договорам, доставка, сборка заказов, отчёты для собственника. Типовая УНФ даёт базовые механизмы, но не знает ваших правил. Тогда сотрудники начинают вести рядом таблицы, и данные в 1С перестают совпадать с реальностью.

Доработка УНФ возвращает эти процессы в базу. Мы не переписываем конфигурацию, а добавляем недостающее точечно и аккуратно.

Типичный пример: компания продаёт товар оптом и в розницу, у неё есть склад и торговый зал, часть заказов уезжает доставкой, часть забирают сами клиенты. В типовой УНФ всё это можно провести документами, но не видно главного: что уже собрано, что уехало, что оплачено, а что висит в долг. Собственник узнаёт об этом из разговоров с менеджерами, а не из программы.

Другой пример: сервисная компания ведёт заказ-наряды в УНФ, но мастера работают на выезде и не видят свои задания с телефона. Данные вносятся задним числом, и руководитель не понимает, сколько реально заработал каждый мастер.

Склад и адресное хранение в УНФ

Штатные ячейки УНФ плюс то, чего не хватает складу.

В УНФ есть ячейки склада, но без загрузки адресов, адреса в документах и удобной печати ими почти не пользуются. Мы загружаем адреса из Excel, выводим ячейку в строки накладной и делаем лист сборки, отсортированный по маршруту. Подробно об этом на странице адресного хранения в 1С.

Пример такой работы есть в нашем кейсе: торговая компания на УНФ, адреса для 209 из 209 артикулов, лист сборки, отчёты и мобильный сканер. Смотреть кейс.

Кроме адресов, в УНФ часто дорабатывают контроль выдачи. Накладная может быть проведена, а товар по ней ещё не выдан клиенту, особенно когда часть заказа забирают сразу, а часть отправляют доставкой. Мы добавляем статус выдачи и отчёт по проведённым, но не выданным документам, чтобы склад и менеджеры видели одну и ту же картину.

Для инвентаризации делаем пересчёт по ячейкам со сканером: кладовщик проходит стеллаж, сканирует товары, а программа сразу показывает расхождения с учётом.

Обмены: сайт, Kaspi, приложения

УНФ становится источником данных для всех каналов продаж.

Остатки и цены из УНФ уходят на сайт и в Kaspi, заказы возвращаются в базу. Для мобильных приложений и ботов делаем HTTP-сервис в расширении, который отдаёт данные в реальном времени. Всё это не требует снятия конфигурации с поддержки.

Для Kaspi и других площадок есть отдельная страница интеграции 1С с маркетплейсами.

Отдельная частая задача это загрузка банковских выписок казахстанских банков и автоматическое разнесение оплат по заказам. Бухгалтер перестаёт вручную сопоставлять платежи, а менеджер сразу видит, что клиент оплатил.

Когда УНФ пора менять, а не дорабатывать

Честно говорим, если доработка будет дороже перехода.

Иногда задачи компании выходят за пределы УНФ: сложное производство с маршрутами, много юрлиц с межфирменными продажами, глубокий складской учёт с ордерной схемой. Доработать можно и это, но поддерживать такую базу будет дорого. В таких случаях мы предлагаем сравнить доработку с переходом на Управление торговлей или Комплексную автоматизацию и считаем оба варианта.

Во многих случаях граница проходит не по функциям, а по нагрузке. Если в базе работает больше двадцати-тридцати пользователей одновременно, а документов тысячи в день, стоит заранее оценить производительность и, возможно, перевести базу на клиент-серверный вариант. Это тоже часть нашей работы.

Цена и сроки доработки УНФ

Точную цену называем после осмотра базы.

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

Все работы фиксируем письменно: что делаем, срок и стоимость. Если по ходу появляются новые пожелания, оцениваем их отдельно, а не растягиваем исходную задачу.

Типичные ошибки доработок УНФ, которые мы исправляем

Что мы находим в базах, которые дорабатывали до нас.

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

Доработки без описания. Прошлый программист ушёл, и никто не знает, какие изменения он сделал и зачем. Мы составляем короткий реестр доработок: что делает каждая, кто ею пользуется, нужна ли она сейчас. Часть оказывается ненужной, и её можно убрать.

Медленная работа. Тяжёлые запросы в обработчиках проведения, отчёты, которые строятся минутами, лишние подписки на события. Разбираем замеры производительности и переписываем узкие места.

Внешние обработки вместо доработок. Десятки внешних файлов лежат в папке у бухгалтера, часть перестала работать после обновления. Нужное переносим в расширение, остальное удаляем.

Обмены без контроля. Выгрузка на сайт или в Kaspi иногда останавливается, и об этом узнают от покупателей. Добавляем журнал обмена и уведомления об ошибках.

После такого разбора база становится предсказуемой: понятно, что в ней изменено, обновления ставятся штатно, и новые доработки не ломают старые.