Для начала номенклатура будет загружаться с текущей иерархией справчника _Товары.
Вид номенклатуры будет определяться на основании текущего реквизита Категория. При этом к Швейным изделиям будет отнесена номенклатура, которая сейчас обозначена категориями "01. Швейные изделия" и "02. Трикотажные изделия". "Аксессуары" и Бижутерия, Обувь, РМО как есть. Всё остальное будет отнесено в Прочее.
Трикотаж при загрузке нужно будет пометить каким-нибудь свойством.
Виды номенклатуры создаются и настраиваются вручную. При этом нужно указать значения, которые будут назначаться всем элементам номенклатуры данного вида по умолчанию: единица измерения, НДС.
Для Швейных изделий включается использование характеристик, общих для всего вида номенклатуры. Для характеристик нужно настроить 2 свойства: рост и размер. Для Аксессуаров и Обуви включается использование характеристик, общих для всего вида с одним свойство -- размер.
Пришлось включить через Все функции: Константы -- Использовать дополнительные реквизиты и сведения. В Доп. реквизитах добавить для характеристик Рост и Размер. Значения реквизитов и характеристики будут создаваться автоматически при загрузке номенклатуры.
Будем использовать общие характеристики для вида номенклатуры везде, где это возможно. Например, для швейных изделий.
Значения свойств характеристик Рост
Нужно добавлять по мере необходимости элементы в списки значений свойств для характеристик номенклатуры (Рост, Размер). Для этого нужно найти элемент плана видов характеристик ДополнительныеРеквизитыИСведения, имеющий соответствующее наименование и привязанный к соответствующему ВидуНоменклатуры, использующийся для характеристик номенклатуры.
Как отличить, для какой номенклатуры не ведётся учёт по характеристикам? Вероятно, для бижутерии не ведётся. А вот для аксессуаров понадобится для головных уборов и перчаток, например. Возможно, для аксессуаров стоит использовать не общие характеристики? Но тогда получится зоопарк.
В УТ признак использования характеристик есть в явном виде среди реквизитов номенклатуры. Думаю, нужно сделать как-то однообразно. Например, для всех швейных изделий всегда использовать характеристики (если у артикула нет размеров, у него будет назначаться характеристика без размеров). Для всей бижутерии характеристики не используются. Проблема с аксессуарами. Там есть перчатки и головные уборы, для которых есть размеры, а почти для всего остального нет. Может, для аксессуаров стоит использовать индивидуальные характеристики?
Пока решение такое. Для швейных изделий характеристики используются всегда, применяются общие для вида номенклатуры. Для обуви характеристики используются всегда, общие для вида номенклатуры. Для аксессуаров используются индивидуальные характеристики, учёт характеристик включается при поступлении первого размерного штрихкода. Для всех остальных видов номенклатуры учёт в разрезе характеристик не используется.
В итоге решил сделать вот как. При первичной загрузке артикула для него устанавливается режим неиспользования характеристик. Но при поступлении первого штрихкода, имеющего размер, артикул обновляется и режим использования характеристик устанавливается такой, как задано для вида номенклатуры. Это происходит только для следующих видов номенклатуры:
| Вид номенклатуры | Режим использования характеристик | Свойства |
|---|---|---|
| Швейные изделия | Общие для вида номенклатуры | Рост, Размер |
| Аксессуары | Индивидуальные для изделия | Размер |
| Обувь | Общие для вида номенклатуры | Размер |
Возможно, в будущем надо будет предусмотреть возможность конвертации загруженного безразмерным швейного артикула в размерный или наоборот.
В УТ штрихкоды хранятся в регистре сведений и не могут быть помечены на удаление. Поэтому при загрузке штрихкода, помеченного на удаление, его нужно просто удалить, если он был загружен. Или же просто не создавать.
Сложнее с характеристикой. При попытке загрузить безразмерную характеристику при включённом учёте по характеристикам не нужно вызывать исключение. Просто ничего не создавать. Размерную характеристику создать всё-таки необходимо, но пометить её на удаление. Связано это с тем, что теоретически могут быть ссылки (например, остатки) на помеченную на удаление характеристику.
Случай ошибочного создания размерных штрихкодов сейчас предполагает только ручной способ отключения учёта характеристик. Проделать это придётся во всех системах.
Перед загрузкой пулов необходимо включить учёт комплектов номенклатуры. НСИ и администрирование -> Настройка НСИ и разделов -> Склад и доставка -> Сборка (разборка).
После этого нужно создать вид номенклатуры Пул, для которого указать Тип номенклатуры = Товар.
Состав пула хранится в справочнике Варианты комплектации.
При наличии в сообщении элемента комплектации, помеченного как изменённый, считается, что пул был изменён и инициируется полная загрузка пула. Также инициируется загрузка пула, если он сам помечен как изменённый. При загрузке пула всегда обновляется его состав.
Единица измерения для швейных изделий назначается на основании единицы, указанной для ВидаНоменклатуры. Пока это всегда штуки. Думаю, также будет и для всех остальных видов номенклатуры.
Если в сообщении для номенклатуры указан вес, он загружается (в килограммах на одну штуку).
Для включения использования видов цен нужно перейти в настройки: НСИ и администрирование -> CRM и маркетинг -> Маркетинг -> Несколько видов цен. Нужно обсудить, как будут цены использоваться, и какие именно стоит грузить и как их называть.
Добавление вида цены осуществляется в справочнике: CRM и маркетинг -> Настройи и справочники -> Виды цен.
Добавил Оптовая. В неё будет грузиться Цена4.
В УТ цены устанавливаются документами УстановкаЦенНоменклатуры. При загрузке справочника будет по мере необходимости создаваться документ установки цены, если цена в сообщении отличается от цены на текущий момент (или на дату документа, если загрузка номенклатуры инициирована загрузкой документа).
На каждый артикул, на каждый вид цены будет создаваться один документ установки цены. Нулевые цены загружаться не будут. Документ будет заполнен строками в соответствии с имеющимися штрихкодами для артикула.
Нужно решить, какие свойства будут общими для номенклатуры, а какие применимы только внутри определённого вида номенклатуры.
Использование товарных категорий включается с помощью НСИ и администрирование -> CRM и маркетинг -> Товарные категории. Товарные категории подчинены видам номенклатуры.
В "1С Единая" товарные группы и подгруппы является независимым от категорий (видов номенклатуры) справочником. Поэтому нельзя так просто синхронизировать эти элементы по UID.
Загрузка товарной категории происходит по следующей последовательности:
e=>end: End
поиск=>operation: Поиск Группы по UID
услНайдена=>condition: Найдена?
услВид=>condition: Вид
номенклатуры
совпадает?
добУИД=>operation: Добавление по UID
добНаименование=>operation: Добавление по наименованию
поиск->услНайдена
услНайдена(yes)->услВид
услНайдена(no)->добУИД
услВид(yes)->e
услВид(no)->добНаименование
добУИД->e
добНаименование->eДля прозрачности работы и удобства отладки нужно полноценное логирование с сохранением исходного сообщения, сопоставленного с текстовым логом загрузки. При этом не хочется нагружать саму базу необходимостью хранить логи и сообщения. А также не хочется нагрузку по упаковке и отправке логов размещать в тех же транзакциях, в которых происходит сама загрузка.
Для этого в базе нужно организовать несложную очередь сообщений, которая позволит помещать в неё исходные данные, необходимые для формирования сообщения, отправляемого в систему логирования. Эта очередь будет обрабатываться в отдельном потоке (например, фоновым заданием).
Исходное сообщение можно помещать в систему логирования ещё до загрузки. Его можно отправить туда параллельно с отправкой в базу-приёмник. Нужно только определить идентификатор, по которому с ним впоследствии можно будет совместить логи.
Набор необходимых полей для внутренней очереди:
| Имя поля | Назначение |
|---|---|
| Дата | Дата и время помещения сообщения в очередь. Задаёт порядок обработки сообщений. |
| Очередь | Строковый идентификатор, определяющий тип сообщения. В зависимости от типа может использоваться обработчик для подготовки и отправки сообщения. |
| Данные | Хранилище значения, содержащее все исходные данные. |
Справочники загружаются методом рекурсивного обхода дерева, переданного в сообщении xml. Пока не загрузятся концевые элементы, элемент с которого началась загрузка не может быть записан. Так соблюдается логическая целостность данных.
Данные загружаемого элемента обновляются только в том случае, если в сообщении для него установлен признак changed, либо если его не существовало, а он понадобился. Так сделано для оптимизации процесса загрузки (не нужно вхолостую обновлять элемент, если по нему не было зарегистрировано изменений).
| Единая | Matrix | Рег. | Всегда | УТ |
|---|---|---|---|---|
| _Товары | ModelEnhancer | Да | Номенклатура | |
| ТоварныеГруппы | ModelGroupEnhancer | Да | ТоварныеКатегории | |
| КатегорияИзделия | CategoryOfProductEnhancer | Да | ВидыНоменклатуры | |
| РостаРазмеры | ScancodeEnhancer | Да | Да | ХарактеристикиНоменклатуры, ШтрихкодыНоменклатуры |
| _Комплектация | ModelSetEnhancer | Да | Нет | ВариантыКомплектацииНоменклатуры.Товары |
Нет штрихкода в элементе справочника, в котором он предусмотрен. Решается запуском обработки, инициализирующей УИДы. Сообщение при этом надо из очереди извлечь и повторить.
Загрузка безразмерного штрихкода после загрузки размерного и включения использования характеристик. Сейчас обработка загрузки в таком случае выдаёт исключение и прекращает загрузку. Сценарий возникновения:
Допустим, изначально неверно был создан безразмерный штрихкод. В таком случае, нужно пометить его на удаление в 1С Единая. При поступлении нового сообщения в УТ ошибки возникать не будет, а неправильный штрихкод будет удалён из системы.
Проблема в том, что такие ситуации возникают постоянно. Их нужно как-то легко обрабатывать, а не выяснять каждый раз, в чём дело.
Инвентаризация будет проводиться в новой базе УТ. Для этого будет разработана специальная обработка.
Перед началом пересчёта в обработку будет загружаться список артикулов. По этому списку будет производиться загрузка информации о номенклатуре по мере надобности. Также будет загружаться информация по учётным остаткам на складах из базы Единая.
Загрузка должна производиться синхронно через веб-сервис сервера glance-grato.
Основная папка проекта. Тут находятся обработки.
Содержит логи, формируемые при загрузке сообщений синхронизации справочников.
| Название | Описаниее |
|---|---|
| ВнутреннийМаршрутизатор | Обработка определяет по сообщению, какой обработкой оно должно обрабатываться. После этого загружается нужная обработка и у неё вызывается метод СообщениеЗагрузить(Корень). В качестве параметра передаётся корневой узел сообщения. |
| ЗагрузкаЗаказа | |
| Манлог | Обработка используется для стекового логирования. |
| СинхронизацияСправочников | Выполняет загрузку сообщения с изменениями справочников. |
Входящие сообщения, содержащие данные справочников поступают со старого сервера шины Glance BIS.
| Расположение | \\apps-srv-1\e$\programs\servers\glance-bis-SERVER |
| ActiveMQ | http://apps-srv-1:8161/admin/ |
| User | Admin |
| Password | admin |
| Очередь | bluz.urib.enhanced.TM |
Новый сервер, который в будущем будет брать на себя функциональность glance-bis назвается glance-grato. За основу взят Spring Boot. Сейчас он занимается только забором сообщений из очереди bluz.urib.enhanced.TM и отправкой на REST-сервис базы УТ.
Новый сервер временно расположен на моём Ubuntu-компьютере. Spring Boot умеет запускаться в linux как сервис. В будущем планируется сделать для него специальных linux-сервер, либо Docker-контейнер.
Про деплоймент Spring Boot приложений рассказывается в Reference.
Сервер glance-grato должен деплоиться на linux как сервис systemd. Про это достаточно написано в разделе 62.2.2 Installation as a systemd Service.
Статья, в которой описано, как смотреть логи, которые пишутся systemd: Управление логгированием в systemd.
Команды для управления сервисом:
sudo systemctl status grato
sudo systemctl start grato
sudo systemctl stop gratoЧтобы сервис автоматически запускался при старте системы:
sudo systemctl enable grato