Есть поставщики и у них свои прайсы товаров.
Есть задумка все прайсы поставщиков хранить в 1с /несколько раз в неделю их заново импортировать/
Цель: нужно быстро находить цены на один и тотже товар от разных поставщик (несколько раз в неделю закупщик проводит процедуры закупки партий товаров
и он должен быстро находить в каком из прайсов минимальная цена на товар)

Думаю над структурой хранения данных прайсов.
Один из вариантов - в виде двух справочников: "ПрайсыПоставщиков" и подчинённый ему справочник "ТоварыПрайса"
Справочник "ТоварыПрайса" периодически очищается и заново импортируется из екселевских прайсов.

Вопрос - правильно ли выбираю структуру данных?

(0) Если делать всё прямыми запросами, то вообще один справочник с нужными полями (товар, поставщик, дата, цена).
Кстати, дату таки рекомендую иметь, а то потом ведь захочется как-нибудь динамику поанализировать.

(31) мля, это надо делать не в оперативной работе менеджера.
а в "регламентах" (полуавтоматических) по засасыванию прайсов.

(32) совет. делай так:
все присылают разные эксели.
под каждый эксель пишешь "нормализатор" (например, есть прйас где артикул и наименование - в одной колонке, нормализатор делит это на две колонки).
а потом уже нормализованный прайс обрабатываешь штатно загрузчиком\привязчиком

(38) Так я вроде уже несколько раз сам выше писал, иимпорт прайсов делается регламентно ночью.

(35) полностью автоматом обработку тебе не удастся сделать.
работа будет полуавтоматической. ибо никто не даст 100% гарантии безошибочного ПРИВЯЗЫВАНИЯ. частью моего упоминавшегося аналит-прайса и была выстроенная технология работы по быстрой привязке. часть делалось автоматом, но потом ступенчато верифицировалось персоналом.
.
совет: для автопривязки прайса если позиция непривязана - делать попытку автопривязки к товару в базе. если нет - смотреть привязки к товару в базе по уже привязанным прайсам. это существенно повышает валдиность и выхлоп автопривязки.

(41) "полностью автоматом обработку тебе не удастся сделать."

Понимаю заняты, и все сообщения выше не перечитаешь )
Но именно это я и писал выше.
Привзяка у меня уже идёт и работает давно. Сейчас вот решил ещё добавить функционала

(39) Вот именно для этого и служит мой справочник "Файлыпрайсов", фото тут: (6)
В котором на каждом прайсе и расписывается, в каком столбце название товара, цены товара, гарантия и другие характеристики, нужные для импорта

А привязка у меня идёт для каждого товара, т.е. для справочника 1с номенклатуры товаров  есть подчинённый справочник "КодыПоставщиков"
в нём два поля: "Прайс поставщика" и "Код поставщика".
Визуально это выглядит так:
http://prntscr.com/pj0pbt

И поэтому я както не воспринимаю предлагаемую "наоборот" структуру (27)
"  Структура должна быть следующей - есть справочник "Товары прайсов", а к нем подчиненный справочник "Поставщики""

Както мне логичней, когда есть прайс поставщика, и для данного прайса в подчинённый справочник добавляются все его товары

(45) Что не понятного в  (27)? Сам же написал "Цель: нужно быстро находить цены на один и тотже товар от разных поставщик ". Один раз товар нашел и тут же получил список поставщиков с ценами - это быстрее, чем найти один и тот же товар по всем прайсам!
Если тебе поставят например, задачу расценку на тендеры, где нужно будет расценить 2000-3000 позиций, то твой вариант может отрабатывать неприемлемое время.
Видимо, база совсем маленькая, поэтому разницы не видишь от своей структуры. Вот если бы ты позанимался запчастями, где один прайс в среднем 20000 позиций, а у некоторых и по 300 тысяч, вот тогда разницу бы ощутил сразу же - упала бы 1С искать по всем прайсам один и тот же товар.

(46) Теперь смысл понял. Только не совсем понятна структура справочника "ТоварыПрайсов" и его подчинённость справочнику номенклатуры в 1с

Врубил. Справочник "ТоварыПрайсов" у меня уже есть, под названием "КодыТМЦПоставщиков"
Этот справочник подчинён справочнику ТМЦ. Просто в это справочник нужно добавить реквизит ЦенаИзПрайсаПоставщика
Видно на фото:
http://prntscr.com/pj9umn

(46) Всё-таки не пойму, как взаимосвязаны справочник номенклатуры ТМЦ из 1с, и этот новый справочник "ТоварыПрайсов" ?

В моём случае справочник"КодыТМЦПоставщиков" /в нём поля: КодТМЦПоставщика, ЦенаПоставщика, КодПрайса/ есть подчинённый справочник относительно справочника Номенклатуры.
Но в таком случае регламентный запрос не сможет добавлять в этот справочник новые товары из прайсов. Ведь взаимосвязь между номенклатурами может установить только Закупщик руками (гадать с большой долей вероятности тут  нельзя).

Поэтому, наверное, моя структура из справочников "ФайлыПрайсов" и подчинённого ему справочника "ТоварыПрайсовПоставщиков" должна иметь место. В "ТоварыПрайсовПоставщиков" легко и понятно регламентно ночью прайсы импортируются.

А процедура поиска цен будет состоять из двух этапов, быстрый и точный этап - для выбранного товара читаем подчинённый справочник с ценами поставщиков.
И второй этап  - через прямые запросы фильтруем по моделе товара справочник "ТоварыПрайсовПоставщиков". И в данном случае в ТЗ результат по маске модели товара могут попадать лишние товары, манагер глазами будет их отсекать.

Ой пля. Я бы уже про другую задачу думал. Автор ты уже начал реализацию
Хоть ЧЕГОТО?

Бери (20) и вперде.

(1) :) ... а вот правительство на словах как раз поддерживает малый бизнес...

(52) у товара максимум 10 поставщиков. Прямые запросы для этого поиска не нужны

(54) бля ну не нужно не бери. Я тебе сказал, что слишком долго думаешь
Над простым. Подчинённый и вперде. Нужно тебе настройки для файла поставщика сделай справочник подчинённый контрагентам. Будут у тебя мменованные настройки под каждого поставщика. Долгий ты.

(55) "Нужно тебе настройки для файла поставщика сделай справочник подчинённый контрагента".
Этот справочник также уже есть.
Вопрос был именно в том, какую структуру сделать для тех товаров, которые есть в прайсах поставщиков, но пока ещё не увязаны с номенклатурой 1с.
Мне советуют (27), когда цены поставщиков подчинены номенклатуре 1с, но этот вариант /насколько я понимаю/ не проходит, т.к. загрузчик не сможет сам построить взаимосвязи между разными номенклатурами.
Получается решение должно быть как здесь на фото (17)

(41) Вот Злопчинский меня понимает, т.к. сам решал похожую задачу )
п.с. мои посты - это наполовину мои размышления, которые помогают найти мне правильное решение.

(41) Автоматическую привязку делать не стоит, прайсы часто меняются, появляется новая не привязанная номенклатура. Поэтому правильное решение скорее всего будет таким: увязка происходит в процессе оприходования товара, закупер  за этим следит глазами.

Автоматически прайсы импортируются в НЕ связанный с номенклатурой 1с справочник, в котором поиск осуществляется через прямые запросы, результатом этого поиска будет ТЗ с примерный соответствием

(57) я вообще не вижу противоречий в том чтоя рассуждаю и что пипл говорит.

.


"Автоматически прайсы импортируются в НЕ связа...."
- вот нахрена тебе ТЗ с примерным соответствием? - для ручной привязки при заполнении приходных доков в базе? тут вообще проблем нет, особенно если прайс уже загружен. Для повышения качества ручной привязки и скорости - возьми ка кпример на ИС "Удар По Бездуховности" - у меня на первом экране правильная позиция в подавляющем количестве случаев находится в первой пятерке списка, если названия некороткие - то вообще 1-2 позиция.

будут вопросы - стучись в личку

(58) Давай на примере поясню
У меня в 1с есть товар:
     21426  Монитор 21.5" LG 22MP48A-P Black (IPS, LED, Dsub)
http://prntscr.com/pjipq4

Как видим, в подчинённом справочнике /назовём  его ЦеныИзПрайсовПоставщиков/ есть сопоставление с пятью прайсами пяти поставщиков.
В этот справочник я скоро добавлю ещё олдну колонку цена, и смогу её переопределять каждую ночь из прайсов.
У каждого поставщика в прайсах этот товар идёт под своим КодомТовара, по этим кодам у меня идёт сопоставление (в момент оприходования либо ещё какимто образом руками)

Но. Вполне возможно, что есть ещё прайс (пусть от поставщика Мерлион), в котором этот монитор присутствует. Но сопоставления с этим прайсом нет, т.к. с Мерлиона товар либо не приходовался, либо руками не сопоставлялся.

Вот и возникает вопрос, что регламентно процедура сама никак не может найти это сопоставление из прайса Мерлиона, согласны?
На товаре у меня например есть реквизит "Модель", у монитора этого она = "22MP48A-P".
Но как Вы понимаете, по этому тексту нельзя программного однозначно найти товар в прайсе Мерилона. Не исключено например, что существует у него ещё модель "22MP48A-P1", и тогда фильтр предложит уже два товара. Программа сама не сможет принять решение, какой товар верный, только руками.

Вот теперь что я хочу /думаю это понятно, но продублирую/:

Чтобы манагер в справочнике ТМЦ нажал на кнопочку и алгоритм просканил ВСЕ прайсы всех наших поставщиков /либо указанные в настройках прайсы/
нашёл там текст  "22MP48A-P" и выдал манагеру цены из этих прайсов / пусть он и выдаст в ТЩ две модели монитора "22MP48A-P" и "22MP48A-P1", это не очень страшно, манагер глазами найдёт нужный.

В теории можно сканить сами экселевские прайсы и ничего не импортировать, но думаю этот процесс будет не самым быстрым

И вот тут мне не понятен совет (27), каким образом программа сама может в прайсе Мерлиона найти по модели "22MP48A-P" нужный товар, его код  и цену и добавить эту инфу в подчинённый номенклатуре 1с справочник "ЦеныИзПрайсовПоставщиков" ??

Как изначально планировал я решение, оно на фото:
https://prnt.sc/pisktv
Сначала алгоритм читает через ADO екселевский файл в ТЗ, а потом из ТЗ его перекидывает в отдельный справочник "ТоварыПоставщиковВПрайсах", который является подчинённым справочнику "Прайсы" - это всё ночью.

И уже через прямые запросы /начала их изучать, но както пока туговато :) /, по команде манагера фильтровать этот справочник для поиска позиции "22MP48A-P"

ну, во первых контейнер содержащий прайсы поставщиков должен иметь флажок\иное указывающий что позиция из прайса привязана или нет.
у меня это вообще две разные таблицы были. все непривязанные позиции были в таблице "непривязанные прайсы".
.
какую именно структуру что кому подчинено - выше уже тебе разжевали - зависит от того, какие "запросы" будут чаще всего выполняться.
.
и не тупи. я давно тебе сказал - НУЖНЫ РЕГЛАМЕНТНЫЕ ПРОЦЕДУРЫ ПРИВЯЗКИ.
ты мне впихиваешь что привязка делается во время оприходования. ну так это и будет по сути "регламентная процедура".
.
(61) я тебе давно написал - нет никакой 100% гарантии правильной автоматической привязки.

я вообще не пойму на чем ты тупишь? что тебя волнует? что не получается?

"Чтобы манагер в справочнике ТМЦ нажал на кнопочку.." - это когда он делает? во время загрузки\вбивания приходного документа (как ты обозначал?) или ты все же хочешь чтото делать отдельно от оприходовани документов?

"я тебе давно написал - нет никакой 100% гарантии правильной автоматической привязки."
Я же это прекрасно понимаю.

"Чтобы манагер в справочнике ТМЦ нажал на кнопочку.." - это когда он делает?
например когда выставляет кому-нибудь счёт и хочет увидеть актуальные цены из прайсов. Это происходит отдельно от оприходования/сопоставления

(62) угу. прямые запросы здесь, возможно, инструмент ускорения, но не инструмент сопоставления. на ИС есть разные алгоритмы сопоставления.
я использовал ВК strmatch.

можно привязывать товар из спр.номенклатуры к прайсу поставщика, а можно наоборот - зависит от ситуации.
.
еще раз: с сипользованием strmatch - подсказка менеджеру получается очень выскокэффективной. даже если названия разнятся, написаны с ошибками и пр.
.
основное время сьедает подготовка кэша для сравнения - вот здесь как раз прямые запросы и зарулят.

где что в каких справочниках хранить грузить - зависит от разрабатываемой архитектуры и наиболее часто выполняющихся задач с этими данными на этой архитектуре.

"я давно тебе сказал - НУЖНЫ РЕГЛАМЕНТНЫЕ ПРОЦЕДУРЫ ПРИВЯЗКИ."

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

(63) "я вообще не пойму на чем ты тупишь? что тебя волнует? что не получается?"

по большому счёту все точки над i я расставил, за исключением одного - (27). Процитирую:

"Структура должна быть следующей - есть справочник "Товары прайсов", а к нем подчиненный справочник "Поставщики". Соответственно, при загрузке прайса от поставщика нужно будет находить товар в справочнике "Товары прайсов" и добавлять/изменять данные в подчиненном"

Вы говорите, что этот совет верный, а я говорю, что регламентый запрос ночью не сможет сам увязать монитор "22MP48A-P"из прайса Мерилоана с моим товаров в 1с , и закинуть инфу в подчинённый справочник!

Вот только этот момент из (27) мне не понятен

(64) ни что - дедаешь примерно как ты и описывал выше
упрощенно:
для каждой позиции из прайса
- выбираешь привязанные позиции из прайсов поставщиков
- из непривязанных позиций прайсов формируешь список похожих
- выдаешь подсказку манагеру
- он выбирает вручную
- - фиксируешь выбранную в привязку.
профит.

не обязательно в таком порядке, но идеология такая.
привязку можно делать по каждому прайсу отдельно. можно в подсказку выкинуть все подходящие из всех непривязанных - и делать сразу множественную привязку.
я так и так делал, по ситуации.
по опыту - работо монтонная. ДОЛЖНО БЫТЬ ПРОСТО И КОНВЕЕРНО.
избешать множественных выборов, перегруженности списокв итд.

(67) млин, при чем здесь ИИ?
(регламентные - не значит полностью автоматические).
если ты можешь однозначно привязываться по артикулам и прочим ЯВНО ВЫДЕЛЕННЫМ ключевым полям - то още весь разгоовор? нет предмета обсуждения.
.
привязки с использованием STRMATCH - делаются хорошо.
вот и все что я хотел сказать.
.
пример: делается соспоставление (сделанное сопоставление\привязка) - не фиксируется http://catalog.mista.ru/public/14255/

(67) "они будут плохо работать"
- ну это смотряи какие прайсы и ка кони структурированы.
я глянул картинку - электроника.
я в свое время писал доработки людям для привязок в магазин игрушек, для бытовой техники и для радиоэлектронных компонент. народ был крайне доволен. смаый сложный был радиоэлектронные компоненты. потому что названия очень коротки и все похоже на все. там пришлось допэвристику подключить.

в твоем случае используя стрматч получится (имхо, хорошо). только вес цифр задрать повыше.

(70) "млин, при чем здесь ИИ?"
"если ты можешь однозначно привязываться по артикулам и прочим ЯВНО ВЫДЕЛЕННЫМ ключевым полям - то още весь разгоовор? "

Как же я могу если я НЕ МОГУ!. Я могу ТОЛЬКО руками. Сам же пишешь, что strmatch может толлко подсказывать. Но только Манагер-Закупер окончательно принимает решение о привязке, т.к. в прайсе Мерлиона моет быть три похожих позиции?

Монитор LG 22MP48A-P2 Black (IPS, LED, Dsub)
Монитор LG 22MP48A-P22 Black (IPS, LED, Dsub)
Монитор LG 22MP48A-P222 Black (IPS, LED, Dsub)

и ваш STRMATCH врядли найдёт однозначно сопоставление с моделью из 1с "22MP48A-P2"

(72) еще раз, для тупых ;-)
несколько раз - 100% гарантии не дает никто.
в этом примере скаорее всего первая позиция из трехпозиционного списка будет стоять в первой строке подсказки.

Злопчинский )), прочитай ниже текст:

я сейчас не веду речь о том, насколько хорошо работает STRMATCH , либо любая другая ВК по привязке разных номенклатур.

Сейчас у меня остался только один не понятный момент: (61)
мне не понятно, почему совет (27) считается верным. Я не вижу каким образом его можно реализовать

(72) если ты можешь "только руками" - то при чем здесь артикулы и прочие поля ДЛЯ ПРИВЯЗКИ? вообще не причем. это просто поля, которые м.б. будут внесены в картчоку при создании нового товара.
.
имей в виду, что уменя эти автопривязки, автозагрузки кучу лет работали и на фарамции и на фильмах\дисках и на чехлах к тлф - там не прайсы а вообще трэш угарный. и все болееменее работало.
.
возьми пример по ссылке и потестируй. он блин РАБОЧИЙ.
в качестве заявки покупателя на вход подсунь свой искуственный прайс, который вообще можешь из нескольких прайсов слепить и посмотреть что будет выдаваться тебе в подсказку.

(75) "если ты можешь "только руками" - то при чем здесь артикулы и прочие поля ДЛЯ ПРИВЯЗКИ?"


"только руками" - это образно. Имел ввиду окончательно решение о привязке приимается манагером-закупером /обычно в приходной накладной/.
А модели у меня не просто поля, при оприходовании в файле экселя или в прйссе я могу вычленить Модель, и тогда по Модели или по штрихкоду алгоритм будет сопоставлять номенклатуры

(75) обязательно просмотрю его.
Но всё-таки изначально мне нужно правильно доработать структуру хранения данных у себя в 1с.
и (27) мне не даёт покоя. я считаю его не правильным, т.к.  справочник "Поставщики" - НЕ МОЖЕТ БЫТЬ подчинённым справочнику Товары, т.к. алгоритм привязки не может сам изначально правильно привязывать позицию из прайса Товару из 1с

   Злопчинский - ответь мне по (27) и пока всё :)

ب_ب упруго

(77) почему это он не может правильно привязывать? очень даже может.

(79) Еп, ну как по чему: в прйсе уо поставщика 4 монитора:

Монитор LG MP48 Black (IPS, LED, Dsub)
Монитор LG 22MP48A-P2 Black (IPS, LED, Dsub)
Монитор LG 22MP48A-P22 Black (IPS, LED, Dsub)
Монитор LG 22MP48A-P222 Black (IPS, LED, Dsub)

а мне нужно найти вот такой: Монитор LG P4 Black (IPS, LED, Dsub)


что по вашему программа должна закинуть в подчинённый справочник???

(80) Пойми ты пытаешься решить задачу которая на твоем уровне в принципе не решается.

(81) Согласен, я бы 13.10.2019 часам к 23.00 ее уже накалякал бы :)

(81) Уже много раз писал, и ещё раз: я не пытаюсь ОДНОЗНАЧНО научиться программно делать связки между номенклатурами. Я прекраснно понимаю, что эти связки можно строить только примерно, с относительной степенью вероятности.

Я последние постов 5 задаю только один вопрос, почему (27) совет считается верным )

(82) С большего уже вчера было накалякано всё кроме прямых запросов. Но мне очень симпатичен анекдот про жену мужа и 3го, который не прав в интернете )

Хочется точку поставить и всё

(77) ты мне тогда четко напиши, запрос на извлечение каких данных должен быть максимально эффективным..?
я так понимаю:
- есть спр.номенклатура.
- есть входящие прайсы поставщиков, прайс поставщика содержит товар и цену.

Стоит задача какая?
(на мой взгляд две)
1. при заполнении приходной накладной, имея товар поставщика (входящий инфопоток), получить товар из спр.номенклатура - либо по имеющимся привязкам (что очевидно), либо для товара поставщика (из входящего товаропотока) максимально быстро выбрать подходящие товары из базы, чтобы дать максимально возможную эффективную подсказку для ручной привязки.
2. при выставлении счета клиенту, имея текущий товар из спр.номенклатура - по какой-то кнопке видеть состояние этого товара у поставщиков, в т.ч. и по прайсам, к которых спр.номенклатура еще не привязан - выдать здесь к спр.номенклатура подсказкой для каждого/текущего непривязанного прайса поставщика список похожих позиций из прайса поставщика для ручной привязки.
.
подводные камни (?навскидку, могу неправ)
- следует учесть, что в прайсе поставщика ВООБЩЕ может не быть позиции, которая может быть привязана к нашей спр.номенклатура. это значит что для пп 1.2 нужно иметь некий "флаг", который показывает что привяка спр.номенклатура к прайс.поставщика отработана и ПРИВЯЗКА ОТСУТСТВУЕТ (чтобы для этих прайсов не тупить пользователя подсказкой для привязки того чего нет). Это означает что такой "флаг" надо "обнулять" после загрузки прайса поставщика если в прайсе поставщика появились НОВЫЕ ПОЗИЦИИ.

блин во наворотили...
по каждой строке екселя - находишь товар? Ок.
тогда для каждого поставщика - указывай свою категорию основной цены поставщика.
и в справочнике цен (ой как неожиданно, да?) веди все эти цены. они там периодические, так что импортируй хоть обимрортируйся, и анализируй хоть обаналзируйся.

прим.: на (86) можешь и аналоги прикрутить. "потом... если ты захочешь..." (с) донна роза дальвадорец.

(86) это ты сейчас мощно выступил и ТС в панике...

1. Прайс поставщика это документ (оферта по сути) - поэтому и храним его в документе 1С 7.7.
Да обычные строчки номенклатуры (НоменклатураПоставщика), числа для цен и остатков.
В шапке будет реквизит Поставщик - справочник контрагенты.

2. Привязка прайсов заключается в сопоставлении наименований (или кодов, артикулов набора параметров и т.д.) из документов к своей номенклатуре.
Поэтому делаем справочник (ПривязкиНоменклатурыПоставщиков) подчиненный Номенклатуре. В нем пишем реквизиты Поставщик и набор реквизитов для синхронизации например в простейшем случае строковое НоменклатураПоставщика.

3. Итого каждой своей номенклатуре будет сопоставлена одна и более номенклатур поставщиков.
Искать можно в обе стороны.
Для удобства привязки добавляем в документу из п.1 реквизит НашаНоменклатура типа Номенклатура и при загрузке документа происходит по кнопке подбор из справочника привязок.
Выбор своей номенклатуры в документе аналогично делает запись в справочник ПривязкиНоменклатурыПоставщиков.

(89)+ Обработка распределения заявок будет заключаться в выборе одного документа со своей номенклатурой и нескольких документов-прайсов.
В итоге будет созданы разные документы ЗаказПоставщику на разных поставщиков, смотря сколько их выбрали и что оно подобрало.

(85) "Стоит задача какая?
(на мой взгляд две)
1. при заполнении приходной накладной, имея товар поставщика (входящий инфопоток), получить товар из спр.номенклатура - либо по имеющимся привязкам (что очевидно), либо для товара поставщика (из входящего товаропотока) максимально быстро выбрать подходящие товары из базы, чтобы дать максимально возможную эффективную подсказку для ручной привязки."

Верно и первая задача была реализована ранее. Взаимосвязь номенклалтур просиходит либо по КодаТовара из прайса поставщика - это есть чёткая стопроцентная связь. Либо /для новых товаров/ по моделям товаров из 1с и входящего товаропотока (либо по штрихколам), но эти новые связи закупер пробегает глазами и перепроверяет

(86) Сложно формулируете, нет чёткости, непонятна мысль

(85) "при выставлении счета клиенту, имея текущий товар из спр.номенклатура - по какой-то кнопке видеть состояние этого товара у поставщиков, в т.ч. и по прайсам, к которых спр.номенклатура еще не привязан - выдать здесь к спр.номенклатура подсказкой для каждого/текущего непривязанного прайса поставщика список похожих позиций из прайса поставщика для ручной привязки."

Да, при выставлении манагером продавцом счёта клиенту, манагер должен видеть не только цену в справочнике ТМЦ, но и "сегодняшние" цены поставщиков в актуальных прайсах, в том числе и для того, чтобы в выставляемом счёте указать прайс, из которого нужно будет осуществить покупку товара (обычно тот, в котором минимальная цена).

Т.е. выбрали товар в счёт, прочитали подчинённый справочник "ЦенаИзПрайсов", это легко.
Затем через прямой запрос придётся отфильтровать те прайсы, которые не имеют привязки к выбранному товару в счёте.

(89) Не увидел преимуществ в использовании документов вместо справочников. И,  не исключаю, что в вашем варианте с документами будет немного сложнее для товара из Номенклатуры 1с, искать в документах-прайсах нужные строки через прямой запрос.

(85) "подводные камни (?навскидку, могу неправ)
- следует учесть, что в прайсе поставщика ВООБЩЕ может не быть позиции, которая может быть привязана к нашей спр.номенклатура, это значит что для пп 1.2 нужно иметь некий флаг"

Не нужны флаги. Ещё раз пример: манагер выставляет счёт клиенту, выбирает товар:  Монитор LG 22MP48A-P.
В подчинённом справочнику Номенклатура "ЦеныИзПрайсов" сразу легко и быстро прочитали привязанные цены из например трёх прайсов.

Далее для группы товаров "Мониторы", определено всего 7 прайсов, в которых есть мониторы. Вот через прямой запрос в оставшихся четырёх прайсах и находим те позиции, в названии которых  содержится модель "22MP48A-P".
И выводим в отдельном окошке их манагеру ( и ничего страшного что из одного прайса было выбрано несколько строк, а из другого вообще ничего, манагер глазами сверит названия товаров и поймёт "правильность" поиска)

(92): там как раз настолько просто, что проще некуда.
В карточке контрагента каждому поставщику укажи свою основную категорию цены поставщика.
У номенклатурного справочника уже еть подчиненный справочник цен (причем периодический).
По прайсу по каждой строке узнаешь товар, зная поставщика - узнаешь его (и только его) категорию цены, в справочник цен этого ТМЦ импортируешь значение цены с такой категорией цены. все.

(96) Что за понятие "категория цены" ?

(96) "По прайсу по каждой строке узнаешь товар"
Каким образом Вы представляете для каждой строки прайса поставщика (в нём 5 тысяс строк, каждую неделю 5% прайса обновляется новыми товарами) УЗНАТЬ товар из номенклатуры 1с?

(98) ну, 5 тысяч - это почти 0, обычно в номенклатуре сотни тысяч наименований. Тем более вы их еще и на группы разобьете МОНИТОРЫ, МЫШИ, КЛАВЫ и т.д. В одной группе вообще меньше тысячи наименований будет. Наверно, с такой мелочью прямые запросы и не нужны, обычными 1с-запросами решите.

(94) Вы не увидели главного.
Я разделил прайсы поставщиков и привязки номенклатуры поставщиков к своей.

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

(100) "Я разделил прайсы поставщиков и привязки номенклатуры поставщиков к своей."

не понял мысль

(95) еще раз, для тупых ;-)
если ты прошерстил прайс и выяснил что в прайсе в принципе нет позиции которая соответствует твоей позиции в спр.номенклатура - то нафига этот прайс (если он не изменился) шерстить каждый раз, когда ты работаешь с этой свое позицией спр.номенклатура.

пример
прайс поставщика обновляется раз в неделю, в прайсе 30тыс позиций.
выставляешь клиенту1 счет. в счете твоя позиция "Монитор1" привязана к 3 прайсам. а всего у тебя 10 прайсов. ищешь свой монитор в этих 7 прайсах. в 2 он есть (привязал попутно), в 5 - его нет в принципе.
через час два три через два дня выставляешь счет клиенту2. позиция Монитор1. привязана к 5 прайсам. всего прайсов -10. сколько надо проверить непривязанных прайсов? - 5? нет. их вообще не надо проверять. потому что 2 дня назад уже было проверено и выяснено, что в 5 прайсах этой позиции нет в принципе.
если у тебя дохрена ресурсов - то можешь их тратить и грузить пользюка бестолковой работой - для Монитора1 предлагать из 5 непривязанных прайсов выбрать подходящее (а подходящее всегда будет, не на 95%, а на 30, или 15 или 5%) - итого у тебя пользюк бездарно пялится в экрна, тратит время. вдобавок лажает. потом лажа вылазит, тратится ресурс на ее исправление. нафига это все..?

(95) "( и ничего страшного что из одного прайса было выбрано несколько строк, а из другого вообще ничего, "
- вот тут ты ошибаешься.
из "другого вообще ничего" - так не будет в подавляющем количесве случаев. так как любое наименование похоже на любоедругое, хотя и с "маленькой" похожестью.
.
"монитор АБВ22" всегда будет похож на твой "монитор АБВ2", хотя и не является им. и будет выведен в список выбора.
.
такой ситуации можно избежать, если включать дополнительную "эвристику", но она работает для частных случаев. и надо быть увереным что этот частный случай присутсвует при "сверке\привязке" что совсем необязательно.

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

или у поставщика появится логист или еще кто, которые перехренячит прайс вдребезги поперек. и жопа.
.
с этой точки зрения 1С:Номенклатура был бы хорошим ходом. но как-то вроде не взлетело. ИЛи наличие в прайсах уникальных ЩК товаров. что далеко не всегда. Некоторые уроды в прайсах пихают коды номенклатуры, ибо по артикулам не работают или их нет в принципе, а ты "привязываешься" к поставщику по коду. А они хреняк и перенумеровали все. а хренли, наименования то все понятно! типа...
.
поэтому ты начинаешь в общем случае рисовать профили, что к этому поставщику в прайсе ты привязываешься по артикулу, к этому прайсу по колонке штрихкод, а к этому - по колонке наименование.
.
а привязываясь по наименованию привязку надо фиксировать по нормализованному наименованию (совет) выкидывая всенефонетические символы и спецзнаки, точки,запяты, тире и пр. бо эти уроды регулярно меняют наименования посредством расстановки точек, запятых, смены слешей с правых на левые, заменой # на № итд. а еще любят переставлять слова исправлять и вносит орфографические ошибки и ваши привязки по наименованию летят к черту. и надо отслеживать что КАК БЫ новую позицию в прайсе поставщика надо привязывать не только к НЕПРВЯЗАННЫМ позициям спр.номенклатура, но и учитывать что может быть привязка, которая уже не работает/неактуальная - и это надо либо регулярно отвязывать, чтобы привязывать заново. итд всякого.

(102) вот теперь мысль донесена более понятно :)

фишка в том, что прайсы меняются каждый день, каждое утром приходят свежие

(103) "- вот тут ты ошибаешься.
из "другого вообще ничего" - так не будет в подавляющем количесве случаев. так как любое наименование похоже на любоедругое, хотя и с "маленькой" похожестью."
_______________
нет. обычно (в 95%) модели товаров уникальны, т.е. в екселе поиск по моделе срабатывает только один раз. Но конечно зависит от применяемого метода нахождения "похожего" товара. Я пока вижу использование обычного Like

(104) Вс-ётаки у меня  в закупке компьютеры ), наиболее продвинутые в этом плане продавцы. Данные ситуации для них уже практически не встречаются, все более менее стали грамотно вести прайсы.

Хотя около 15 лет назад у моего основного поставщика в прайсе код товара был 4х значным ). Он доходил до числа 9999 примерно за полгода )

(106) "т.е. в екселе поиск по моделе срабатывает только один раз. Но конечно зависит от применяемого метода нахождения "похожего" товара. Я пока вижу использование обычного Like"
память ты тоже будешь искать по модели? что будет являться для память "моделью" - DDR2666 или просто DDR? (условно).
лайк это конечно хорошо, если ты уверен в том что поставщики дают все записано и разнесено по столбцам правильно (то есть ты надеешься на человеческий фактор, бо хз как у них и кто прайсы готовит).

а придет у тебя прайс в один раз где вметсо модели
АБС123-22 будет запись АБС123/22 и твой лайк по "АБС123-22" накроется медным тазиком...

ну, польза всё же есть - Злопчинский прямо жжёт своим опытом. не останавливайся, я записываю. серьёзно.

(109) у меня на тлф, кстати, скоро деньга заканчивается... ;-)

(107) "Вс-ётаки у меня  в закупке компьютеры ), наиболее продвинутые в этом плане продавцы."
- это вот хорошо, если удастся получаемые прайсы в достаточной строгой форме иметь и быть уверенным в их более-менее относительной стабильност

(108) "память ты тоже будешь искать по модели? что будет являться для память "моделью" - DDR2666 или просто DDR? (условно)."
_____________
Любой товар имеет модель/артикул. Применительно к памяти у васех поставщик она идёт применительно так:
Оперативная память SO-DDR-3 8GB PC-12800 Patriot [PSD38G16002S].
т.е. имеет свою уникальную модель в []

(112) "PSD38G16002S" чем отличается от "PSD38G16002S" ?

(108) "лайк это конечно хорошо, если ты уверен в том что поставщики дают все записано и разнесено по столбцам правильно (то есть ты надеешься на человеческий фактор, бо хз как у них и кто прайсы готовит)."

Лайк будет использоваться ТОЛЬКО для манагера-продавца, когда он хочет найти цены поставщиков из прайсов. Взаимосвязь между номенклатурами устанавливает только Закупер в момент оприходования товара, поэтому ничего не накроется медным тазом )

(113) Нажал CTRL+F
http://prntscr.com/pk4dz8
и вижу что ничем ))

(108) "а придет у тебя прайс в один раз где вместо модели
АБС123-22 будет запись АБС123/22"
_____________
Вы както очень уж недооцениваете компьютерщиков )
1. Они редко у себя в базе меняют названия товаров, но это и не важно т.к.
2. Когда первый раз я оприходовал эту память от этого поставщика, взаимосвязь между номенклатурами установилась по КодуТовараПоставщика и мне в дальнейшем не важно, как меняются названия товаров и даже их модели.

(115) Ну да сложно искать кошку в темной комнате если ее там нет ))
Но наверно догадался про хреново визуальное отличимую разницу между Р и P.

(117) "Но наверно догадался про хреново визуальное отличимую разницу между Р и P."
_______________
Ну так нужно было наверное поменять раскладку языка ? ))

(117) Да, иного /редко/ попадаются изверги, которые в моделях которые написаны латиницей, используют русские буквы, т.е. в "PSD38G16002S"
первой буквой у них идёт русская буква "ЭР"
Возможно это получается, что они сканируют свои приходы и Файнреадер ошибается, не знаю. НО:

повторюсь, мне это не важно. Всё что произойдёт в данном случае, манагер-продавец не найдёт этот товар в "плохом" прайсе, когда нажмёт кнопку "Узнать цены на товар в прайсах"

А взаимосвязь между номенклатурами у меня создаётся в полуавтоматическом режиме, только Закупером и с контролем глазами, переложить эту задачу 100%но на какойто алгоритм не получится

Реализовывал загрузку прайсов с email для магазина автозапчастей.
Все данные хранил в sqlite базе данных, так как запросы в ней обробатываются очень быстро
и инсертил туда по 499 записей за раз.

Так как sqlite предназначена в основном для однопользовательского режима работы, сделал запрос в цикле.
На данный момент в БД работают постоянно 5-6 пользователей + шедулер который загружает в нее прайсы.
Прайсы содержат до 200 к строк.
К сожалению если шедулер будет часто обновлять прайс - тогда БД будет часто занята...

Сами пользователи занять базу практически не могут, так как запросы отрабатываются очень быстро,
а результат уже обрабатывается в самой эс1

Тут небольшой код работы с БД, возможно кто-то добавит что-то.


Функция ПодключитьВнешнююБазу()
    
    ВнешняяSQLLite = 0;
    база           = 0;

    Попытка
        база = СоздатьОбъект("SQLiteBase");
    Исключение
        Возврат 0;
    КонецПопытки;
    
    
    Если ФС.СуществуетФайл(КаталогИБ()+"ExtForms\")=0 Тогда
        ФС.СоздатьКаталог(КаталогИБ()+"ExtForms\");
    КонецЕсли;
    Если ФС.СуществуетФайл(КаталогИБ()+"ExtForms\DB_SQLite\")=0 Тогда
        ФС.СоздатьКаталог(КаталогИБ()+"ExtForms\DB_SQLite\");
    КонецЕсли;
    ИмяБД = КаталогИБ()+"ExtForms\DB_SQLite\baza.db3";

    Успех = 0;
    Пока Успех = 0 Цикл
        // в цикле + попытка ждем пока БД освободится от другой транзакции
        Попытка
            база.Открыть(ИмяБД);
            ВнешняяSQLLite = база.НовыйЗапрос();
            ВнешняяSQLLite.ВыполнитьЗапрос("PRAGMA journal_mode=WAL");             
            Успех = 1;
            Сообщить("Внешняя база успешно подключена");
        Исключение
            
            БДЗанята = ОписаниеОшибки();
            
            Если Найти(БДЗанята, "database is locked") = 0 Тогда
                //** Значит какая-то сторонняя ошибка, выходим из подключения
                ВнешняяSQLLite = 0;
                Сообщить(БДЗанята);
                Возврат 0;                
            КонецЕсли;
            
        КонецПопытки;    
    КонецЦикла;
    //Рез = ВнешняяSQLLite.ВыполнитьЗапрос("PRAGMA synchronous");
    //Сообщить(Рез.ПолучитьЗначение(1,1));
    
    Возврат 1;
    
КонецФункции




Функция ВыполнитьЗапрос(ТекстЗапроса, НомерКолонки = "") Экспорт
    
    Перем Результат;
    Результат = СоздатьОбъект("ТаблицаЗначений");

    Если ВнешняяSQLLite = 0 Тогда
        Возврат Результат;
    КонецЕсли;    

    Успех = 0;
    Пока Успех = 0 Цикл
        // в цикле + попытка ждем пока БД освободится от другой транзакции
        Попытка            
            Результат = ВнешняяSQLLite.ВыполнитьЗапрос(ТекстЗапроса, НомерКолонки);
            Успех = 1;
        Исключение
            
            БДЗанята = ОписаниеОшибки();            
            
            Если Найти(БДЗанята, "database is locked") = 0 Тогда
                //** Значит какая-то сторонняя ошибка, выходим из запроса
                Сообщить("ПРЕРЫВАЮ:" + БДЗанята, "!!!");                
                Сообщить(ТекстЗапроса);
                Прервать;
            Иначе
                Сообщить(БДЗанята, "!");
            КонецЕсли;
        КонецПопытки;
    КонецЦикла;
    
    Возврат Результат;
    
КонецФункции



так же в sqlite можно хранить и ссылки на справочники при желании...

Работай полностью доволен, пользователи очень быстро получаются все информацию:
Запрос в TecDoc за аналогами, а потом запрос за ценами в sqlite за ценами.

(117) вот именно. а strmatch скорее всего отловит это ка кочень похожее

(120) Предположим прайс содержит 200 тыс строк.

Можете подсказать по скорости фильтрации справочника через оператор Like SQL запроса,
есть ли разница когда эти 200тыс строк хранятся в справочник 1с, либо как у вас в примере - во внешней базе данных?

п.с. Сейчас я прайсы поставщиков храню в 1с, и фильтрация справочника в 40тыс строк занимает около 4сек.
Хотелось бы быстрее

(122) Быстрее это инмемори базы данных и предварительное хеширование по ключевым словам.
Особо крут simhash и другие подобные.

(123) Пока мне не нужны высокие материи ).
Только лишь понимать, где лучше хранить относительно объёмные прайсы /пусть 50-100 тыс строк - весь массив прайсов/
Или в самой 1с или в сторонней базе

Да, стандартными средствами 1с очистка большого справочника - очень длительная процедура.

(122) Если хочется скорости то в базе sqlite, а к ней прикрутить расширение FTS https://www.sqlite.org/fts3.html
Очистку справочников 1С тоже можно сделать из sqlite. Но не уверен насколько быстрее, не измерял.

Правильно ли я понимаю, что если данные хранить в справочниках 1с, то добавлять в него данные можно только простым перебором в цикле? SQL команды Insert нет?
10тыс строк очень долго штатными средствами 1с добавляется. Точно также и удаление

(127) пиши в транзакциях пакетами по 300-500 элементов...

(127) DELETE то я реализовал, это оказалось довольно просто, а вот INSERT и UPDATE фактически потребуют создания объектов, более низкоуровневого варианта я не нашел. Так что да, их нет и не предвидеться.

(129) И у 1sqlite нет этих операторов?

(130) Конечно есть. Я про базу 1С. С базой 1С только SELECT и DELETE.

(128) Да, не плохое ускорение. в 26 раз быстрее с транзакцией /пока сразу всю процедуру включил в транзакции, не разбивал на циклы/

(132) на 10 000 записях...
без транзакции: около 3 мин
в одной транзакции: около 1 мин.
с пакетными транзакциями: 30 сек

(124) Начни с гугления "adodb 1c"
Нечто вроде https://mudritskiy.blogspot.com/2013/05/1-adodb.html

(134)+ Список БД с которыми можно через ado nen https://ru.wikipedia.org/wiki/ADOdb

(135) *nen = тут