С учетом сложившихся в компании практики финансовой отчетности с помощью бухгалтерских счетов, было сформулировано требование формирования аналогичных бухгалтерских отчетов. В УТ11 бухгалтерские счета не используются, а ERP – содержит избыточную функциональность. Поэтому решили внедрять решение 1С:Комплексная автоматизация 2.

Команда проекта была сформирована такая: Консультант (методическая проработка, обучение, внедрение), Разработчик-Архитектор (в моем лице – архитектура, методическая проработка, разработка), Программист заказчика (подпроект миграции, приемка релиза и его перенос в рабочий контур), руководитель проекта со стороны Заказчика (организационные вопросы).

Работа была построена следующим образом. Вначале с Заказчиком обговорили основные этапы проекта на нашей устоявшейся схеме: моделирование, ТЗ на разработку, разработка, тестирование и приёмка, обучение, запуск.

Задача по миграции данных с Navision была выделена в отдельный подпроект и была поручена программисту Заказчика.

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

Моделирование проводилось полное, все процессы компании, которые велись до сих пор в Navision, а также были включены некоторые очевидные для внедрения возможности КА2.

Доработки можно классифицировать следующим образом:

• Разработка АРМ менеджеров по продажам. Интерфейсы для работы с резервами, каталогом товаров.
• Проверки при контроле отгрузки товаров на различные условия и права доступа.
• АРМ складских работников. Изменения процесса при работе с серийными номерами. Документооборот при доставке. Различные печатные формы
• Двухсторонняя интеграция с интернет-магазином (цены, остатки, заказы, REST-сервисы, нетиповые, все с нуля).
• Синхронизация с исторической базой с 1С:Бухгалтерия 3 (EnterpriseData 1.5, КД3), переработана схема конвертации некоторых объектов

Этап моделирования занял 2 месяца, этап разработки — 4. Практически вся разработка выполнена в расширении (в режиме совместимости 8.3.10)

Запуск системы состоялся в начале сентября 2018 и прошел достаточно спокойно. В КА2 прошло два закрытия месяца, эксплуатация идет в спокойном режиме (что большая редкость на практике :D).

Первое закрытие месяца встретило некоторые трудности в виде отрицательных остатков по видам запасов, но выработали таблетку от таких проблем в будущем (контроль остатков по регламентированному учету).

Миграция — остатки по номенклатуре, взаиморасчеты по договорам. Справочники соответствующие. Контрагенты и партнеры — ведутся отдельно. Рабочие нюансы в типах расчетов, в остатках расчетов по расчетным документам. Тут в 1С все предусмотрено (пустышка документ Реализации на дату переноса). Все не с первого раза, но все получилось.

Управление резервированием — пожалуй самая сложная часть. В Nav схема очень сильно от 1С отличается. Тут придумали следующую схему.
Резервирование идет с обособлением. Если Товар есть на складе — резервирование документом Корректировка назначения. Если товар в пути (через транзитный склад), обособление производится в документе Заказ на перемещение. Обработка управления резервированием изменяет поле «Назначение» в ТЧ Заказ на перемещение. После чего товар поступает на склад продажи как обособленный.
Схема логически сложная, интерфейс также сложный. Переделывался трижды раз прежде, чем пришел к настоящему виду. Но вариант оказался вполне рабочий.

Следующая проблема — сложность схемы учета по серийным номерам. Посчитали, что вообще не подходят типовые схемы учета и контроля серийных номеров. Решили сделать реквизит, в который можно сканировать серийные номера. Просто по количеству, без привязки к строкам. Есть или нет в товаре серийник — признак в карточке. Контрольная сумма количества серийников — контролируется, но не жестко.

Интеграция с сайтом — через http сервис. Упрощенно, схема следующая. При изменении остатков, номенклатуры или цен подпиской на событие асинхронно формируется запись в транспортном регистре, а затем и отправка данных в сервис сайта. В регистр лога записывается ответ. Если ответ с ошибкой — отправку повторяем по расписанию.

При приеме заказа — все в обратном порядке. Сайт вызывает наш http сервис. Сервис создает заказ, в реквизит заказа записывает исходный json-запрос. Отдает статус успешности заказа. Записывает в лог-регистр.

Из интересного все пожалуй. Но много рутинных простых мелочей. Хорошо, что работали с ТЗ и консультантом, обеспечили проект должными ресурсами. И сроки переносили, если кто не успевал. Поэтому все без нервов.

Приведу пару скриншотов интересных с моей точки зрения доработок.

Контекстный (по строке) динамический список с состоянием резервов по строке

Управление резервами в заказе. Основная схема – резервирование с обособлением.

Управление осуществляется документами Корректировка резервов (для резервирования товаров на складах) и Заказ на перемещение с обособлением под Заказ клиента (для резервирования товаров в пути)

АРМ Кладовщика (упаковка товара). Форма вызывается при сканировании ШК накладной.
S/n добавляется в многострочное текстовое поле, затем записывается в допреквизит документа.

Доп реквизиты накладной

На момент написания статьи релиз КА — 2.4.5.143, платформа 8.3.12.1440.