Создание характеристик номенклатуры в РБД на 300 узлов
Конфигурация "1С Розница". Есть справочник "Характеристики номенклатуры", подчиненный справочнику "Номенклатура" (30 000 элементов). Необходимо создавать для номенклатуры характеристику, различающуюся реквизитом "Срок годности", причем заранее не известно сколько характеристик и с каким "сроком годности" должно быть у номенклатуры. Проблема заключается в том, что "одновременно" создавать (до того как обмен пройдет со всеми узлами) в 300 узлах к одной номенклатуре могут быть созданы характеристики с одинаковым "сроком годности", что логически неправильно. Подскажите, пожалуйста, как решить данную ситуацию.
еется в виду что может быть такой вариант, что во всех узлах есть номенклатура со сроком годности 01.10.13 и если узлы одновременно создадут характеристики, то после обмена с ЦУ будет создано 300 "разных" характеристик (элементов) и это только при наличии на всех узлах номенклатуры с одним сроком годности, а таких сроков может быть очень много, плюс не по одной номенклатуре.
Можно провести небольшой расчет: 1000 номенклатуры по 15 разных сроков годности в 300 узлах. После обмена в ЦУ появиться 4,5 МИЛЛИОНА (1000*15*300) характеристик, а должно 15 ТЫСЯЧ (1000*15).
еется в виду что может быть такой вариант, что во всех узлах есть номенклатура со сроком годности 01.10.13 и если узлы одновременно создадут характеристики, то после обмена с ЦУ будет создано 300 "разных" характеристик (элементов) и это только при наличии на всех узлах номенклатуры с одним сроком годности, а таких сроков может быть очень много, плюс не по одной номенклатуре.
Можно провести небольшой расчет: 1000 номенклатуры по 15 разных сроков годности в 300 узлах. После обмена в ЦУ появиться 4,5 МИЛЛИОНА (1000*15*300) характеристик, а должно 15 ТЫСЯЧ (1000*15).
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Почему бы не обменять , и сразу после обмена в центральной базе уже создать сроки годности по которым есть данные. В случае если создавать в узлах , и у вас все таки будут дубли , убрать дублирующие объекты обработку "Поиск и замена дублирующих объектов" с группировкой по владельцу (тут на инфостарте должна быть такая)
А чем эти вопросы о создании характеристик отличаются от аналогичных вопросов о создании самих товаров?
То есть, так же можно спросить: что если эти 300 узлов одновременно создадут новый товар с одинаковым названием, и что если в том узле где оставили права нет такого товара который есть в других?
Ответ - не допускать одновременного создания одинаковых элементов - применим в обоих случаях. Почему то, как вы решаете это для номенклатуры, неприменимо для ее характеристик?
То есть, так же можно спросить: что если эти 300 узлов одновременно создадут новый товар с одинаковым названием, и что если в том узле где оставили права нет такого товара который есть в других?
Ответ - не допускать одновременного создания одинаковых элементов - применим в обоих случаях. Почему то, как вы решаете это для номенклатуры, неприменимо для ее характеристик?
(7) mixa4, Номенклатуру можно создавать в ЦУ, т.к. ее набор одинаков для всех узлов, и ее количество не очень большое 30 000.
С характеристикой сложнее. Возьмем пример со сроками годности. Узлам необходимо создать характеристики к номенклатуре с заканчивающимся в течении 6 месяцев сроком годности. Если создавать характеристики в ЦУ то необходимо предугадать все возможные варианты 180 элементов (6 месяцев по 30 дней) к каждой номенклатуре (30 000), всего получиться 5,4 млн. элементов, а это в 180 раз больше чем справочник номенклатуры!!!
Если создавать характеристики по фактическим срокам годности в узлах, то может возникнуть ситуация когда 300 узлов создадут характеристику с сроком годности "01.10.13" к одной номенклатуре, Вы понимаете что будет когда ЦУ примет обмен. Можно написать обработку, которая будет "сворачивать" характеристики по номенклатуре, но это ведь уже "танцы с бубнами", должен быть способ по-элегантней.
С характеристикой сложнее. Возьмем пример со сроками годности. Узлам необходимо создать характеристики к номенклатуре с заканчивающимся в течении 6 месяцев сроком годности. Если создавать характеристики в ЦУ то необходимо предугадать все возможные варианты 180 элементов (6 месяцев по 30 дней) к каждой номенклатуре (30 000), всего получиться 5,4 млн. элементов, а это в 180 раз больше чем справочник номенклатуры!!!
Если создавать характеристики по фактическим срокам годности в узлах, то может возникнуть ситуация когда 300 узлов создадут характеристику с сроком годности "01.10.13" к одной номенклатуре, Вы понимаете что будет когда ЦУ примет обмен. Можно написать обработку, которая будет "сворачивать" характеристики по номенклатуре, но это ведь уже "танцы с бубнами", должен быть способ по-элегантней.
(9) не понятно как это на практике "можно создавать в ЦУ", приход же наверно на местах все-таки вбивается, в случае нового товара нельзя вбить приход пока кто-то не создаст новую номенклатуру в ЦУ и не произведет обмен? что-то не очень, объясните как у вас ввод организован, тогда и с характеристиками будет понятнее
(12) mixa4, На местах не может приходоваться товар, который не прошел проверку отделом маркетинга, только после проверки его вводят в базу (ЦУ), а после обмена он попадает в узлы. А Вы считаете что на местах менеджеры должны сами вводить новые элементы справочника "Номенклатура"? Это был бы полный бардак.
(14) я уточняю условия задачи, своеобразная таки у вас система: не часто встречаются 300 узлов на Рознице и не часто при этом в ЦУ кто-то работает, но это ладно.
Ну, по логике, если через тех, кто вводит новые товары, не проходят складские документы и они не могут также по-создавать нужные характеристики, то предлагаю рассмотреть такие варианты.
В подчиненных узлах или 1) заводят нужную им характеристику срока годности, или 2) в приходной накладной проставляют в отдельной колонке срок годности;
при обмене, ЦУ в первом случае смотрит - нет ли уже такой характеристики - если есть, то использует в документе уже существующую характеристику а новую удаляет (точнее даже не создает), во втором случае - по дате создает характеристику (если нет) и проставляет в документе;
ЦУ выгружает исправленный документ обратно в ПУ.
В первом случае нужно будет поковырять обмен, и поскольку ЦУ будет изменять документы - организовать обмен так чтобы исключить коллизии.
Во втором случае документ по сути проводится в ЦУ, а до тех пор товар не получится продавать, что тоже нехорошо.
Ну, по логике, если через тех, кто вводит новые товары, не проходят складские документы и они не могут также по-создавать нужные характеристики, то предлагаю рассмотреть такие варианты.
В подчиненных узлах или 1) заводят нужную им характеристику срока годности, или 2) в приходной накладной проставляют в отдельной колонке срок годности;
при обмене, ЦУ в первом случае смотрит - нет ли уже такой характеристики - если есть, то использует в документе уже существующую характеристику а новую удаляет (точнее даже не создает), во втором случае - по дате создает характеристику (если нет) и проставляет в документе;
ЦУ выгружает исправленный документ обратно в ПУ.
В первом случае нужно будет поковырять обмен, и поскольку ЦУ будет изменять документы - организовать обмен так чтобы исключить коллизии.
Во втором случае документ по сути проводится в ЦУ, а до тех пор товар не получится продавать, что тоже нехорошо.
(16) mixa4,
Идея с размещением в отдельной колонке срока годности и с контролем при проведении замечательная.
(17) mixa4,
А что здесь такое НовыйУИД и зачем он В ЭТОТ МОМЕНТ нужен? Если это УИД создаваемой в ПУ характеристики, то он может быть получен только после записи (а записывать до сверки с ЦУ нельзя - вдруг уже есть такая характеристика, потом придётся подменять и удалять, иначе будет дубль). Если это просто Новый УникальныйИдентификатор(), то в чём смысл его создания в ПУ?
Идея с размещением в отдельной колонке срока годности и с контролем при проведении замечательная.
(17) mixa4,
ПУ шлет WEB-сервисом на ЦУ таблицу типа Номенклатура;СрокГодности;НовыйУИД,
А что здесь такое НовыйУИД и зачем он В ЭТОТ МОМЕНТ нужен? Если это УИД создаваемой в ПУ характеристики, то он может быть получен только после записи (а записывать до сверки с ЦУ нельзя - вдруг уже есть такая характеристика, потом придётся подменять и удалять, иначе будет дубль). Если это просто Новый УникальныйИдентификатор(), то в чём смысл его создания в ПУ?
Можно в ЦБ поднять WEB-сервис, который будет следить за уникальностью характеристик:
Запрос из магазина на предмет наличия характеристики. Если есть, то получить из ЦБ и создать в магазине с копированием уникального идентификатора ссылки - тогда при обмене дублирования не будет. Если нет, то создать в ЦБ, а потом тоже получить в магазин как описано выше.
Запрос из магазина на предмет наличия характеристики. Если есть, то получить из ЦБ и создать в магазине с копированием уникального идентификатора ссылки - тогда при обмене дублирования не будет. Если нет, то создать в ЦБ, а потом тоже получить в магазин как описано выше.
WEB-сервис при создании каждой характеристики плох тем что при проблемах с инетом процесс ввода документа встанет по середине, но можно это делать при проведении, как во втором случае предыдущего поста, то есть:
в ПУ в приходе заполняют отдельную колонку - срок годности,
при проведении прихода, ПУ шлет WEB-сервисом на ЦУ таблицу типа Номенклатура;СрокГодности;НовыйУИД,
ЦУ, если уже есть характеристика Номенклатура-СрокГодности, то возвращает её УИД, иначе создает такую характеристику с НовыйУИД,
ПУ создает характеристику Номенклатура-СрокГодности исползуя УИД возвращенный ЦУ, использует ее в соответствующей строке документа.
Вполне себе ничего, а при проблемах с инетом приход не проведется, но по крайней мере документ можно будет полностью ввести и сохранить, провести при восстановлении связи.
в ПУ в приходе заполняют отдельную колонку - срок годности,
при проведении прихода, ПУ шлет WEB-сервисом на ЦУ таблицу типа Номенклатура;СрокГодности;НовыйУИД,
ЦУ, если уже есть характеристика Номенклатура-СрокГодности, то возвращает её УИД, иначе создает такую характеристику с НовыйУИД,
ПУ создает характеристику Номенклатура-СрокГодности исползуя УИД возвращенный ЦУ, использует ее в соответствующей строке документа.
Вполне себе ничего, а при проблемах с инетом приход не проведется, но по крайней мере документ можно будет полностью ввести и сохранить, провести при восстановлении связи.
Реализовано так:
1) В ПУ создается документ в котором заполнен срок годности и не выбраа характеристика.
2) При проведении в ПУ документ через XML выгружается на FTP
3) ЦУ регламентным заданием забирает файл и создает документ и проводит его, при записи документа создаются характеристики, если характеристика есть выбирается существующая. При проведении документа он опять же через XML падает на FTP + в этот же файл попадают характеристики.
4) ПУ забирает с FTP файл с характеристиками и полностью заполненным документом.
1) В ПУ создается документ в котором заполнен срок годности и не выбраа характеристика.
2) При проведении в ПУ документ через XML выгружается на FTP
3) ЦУ регламентным заданием забирает файл и создает документ и проводит его, при записи документа создаются характеристики, если характеристика есть выбирается существующая. При проведении документа он опять же через XML падает на FTP + в этот же файл попадают характеристики.
4) ПУ забирает с FTP файл с характеристиками и полностью заполненным документом.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот