Вход | Регистрация
    1  2   
1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: Ищу вариант работы с екселевскими прайсами

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

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

Вопрос - правильно ли выбираю структуру данных?
 
 
   H A D G E H O G s
 
1 - 13.10.19 - 21:37
У меня дернулась рука забанить очередную пиар реинкарнацию Евгения Шекина, миллиордера и филантропа, как только я стригерился на keywords "Ищу. Ексель. Прайс", но Белорусский ник вас спас.
   evgpinsk_
 
2 - 13.10.19 - 21:44
Я рад  ).
Либо такая задача: у закупера есть отчёт о товарах, которые продавались за месяц /пусть 500-1000 позиций/.
Многие товары из этого списка можно закупать у разных поставщиков. Поэтому хотелось бы, чтобы этот отчёт указывал на прайс с минимальной ценой товара.
Задача это скорее всего ресурсоёмкая, поэтому нужно изначально правильно выбрать структура хранения данных
   Garykom
 
3 - 13.10.19 - 21:55
(2) Все легко кроме одной глобальной проблемы.
Как будем сопоставлять-синхронизировать одинаковую по сути номенклатуру из разных прайсов разных поставщиков?

Когда они названия хрен знат как называют и артикулов или прочих ШК нетути?
   Garykom
 
4 - 13.10.19 - 21:56
(3)+ А если добавить сюда разные синонимы/аналоги и прочие замены будет жопа.
   evgpinsk_
 
5 - 13.10.19 - 22:02
(3) Эта задача уже решена. Как мы понимаем, во всех прайсах каждый товар имеет свой "Код товара".

В в 1с уже есть сопоставление кодов поставщиков с элементами справоника ТМЦ
   evgpinsk_
 
6 - 13.10.19 - 22:06
Т.е. пока вижу реализацию такой:
http://prntscr.com/pircg8
   evgpinsk_
 
7 - 13.10.19 - 22:11
(3) Т.е. предполагается, что товары из прайсов поставщиков закупщиком периодически виртуально приходуются в 1с, и после процедуры  оприходования и устанавливаются взаимосвязи между КодамиТоваровПоставщиков и справочником ТМЦ в 1с
   Garykom
 
8 - 13.10.19 - 22:40
(7) Погугли Мегапрайс см (1) это самая известная поделка данного рода.

Хотя практически любой 1Сник со стажем за свою карьеру написал (или внедрил готовую) минимум одну такую хрень.

Имхо я бы не внедрял в имеющуюся базу/конфу 1С 7.7 а наваял нечто внешнее с веб-сервисом.
А из текущей 1С 7.7 путем внешней обработки через HTTP (банальный СоздатьОбъект("MSXML2.ServerXMLHTTP")) работал с этим внешним, грузил туда прайсы, сопоставлял и т.д.
Суть легкость внедрения в любую конфу.
   Консультант Баранов
 
9 - 13.10.19 - 22:44
(0) 1. Я бы хранил данные не в справочнике, а в документах типа Установки цен номенклатуры, но без всякого проведения.
2. Каждый день, в перед началом работы, Формировался документ на день с актуальными на эту дату ценами.
3. Возможно с некоторой периодичностью проверять актуальность некоторых товаров: есть ли остатки, были ли оборот, и относить их в архив.
   evgpinsk_
 
10 - 13.10.19 - 22:57
(9) В чём преимущество хранения в документах а не в справочниках?
   evgpinsk_
 
11 - 13.10.19 - 22:57
(8) Уровень моих знаний скорее всего не позволит реализовать данную задачу через HTTP )
   evgpinsk_
 
12 - 13.10.19 - 23:00
Нужна в первую очередь скорость доступа к ценам поставщиков.
Пример, менеджер выбрал товар, нажал кнопочку и обработка должна проанализировать ну пусть 3-4 прайса и вывести найденные цены у поставщиков.
Хотелось бы чтобы эта процедура выполнялась за 1-2 секунды
   Kigo_Kigo
 
13 - 13.10.19 - 23:12
Скорее всего надо пойти от обратного, сделать единый прайс по все поставщикам, а в подченный справочник заносить поставщика и его цену, то есть манагер находит интересующую позицию и открывает подчиненый справочник, где видит кто может поставить и по какой цене, имеем один справочник номенклатуры и не захламленные подчиненые справочники
   evgpinsk_
 
14 - 13.10.19 - 23:32
(13) Не совсем понял суть предложения.
Сейчас у меня такая структура данных:
Справочник номенклатуры "ТМЦ"
У него есть подчинённый справочник "КодыТМЦПоставщиков", в котором для каждого товара определены коды поставщиков из их прайсов.
И 3й справочник: "Файлы прайсов"
Структура видна на фото:
http://prntscr.com/pisbjf

Сейчас в планах содержимое всех екселевских файлов загнать в 1с.
   VladZ
 
15 - 13.10.19 - 23:36
(10) Цена и актуальность - понятия непостоянные.  Я бы тоже хранил в документе.
   evgpinsk_
 
16 - 13.10.19 - 23:44
(15) В чём плюс документа?
Для меня главное - скорость нахождения цены товара в массиве данных.
   evgpinsk_
 
17 - 13.10.19 - 23:58
Наиболее простой для меня способ реализации, как я выше и предполагал - добавить один справочник "ТоварыПоставщиковВПрайсах"
Результат виден на фото:
http://prntscr.com/pisktv

Через ADO читается прайс в ТЗ, затем из ТЗ перекачёвывает в справочник "ТоварыПоставщиковВПрайсах".
Эта процедура запускается раз в сутки.
Вроде как всё красиво?

Только мне не совсем понятно, оптимально ли по скорости поиска информации будет работать данная структура данных, или поиск в табличной части документа был бы быстрее?
   evgpinsk_
 
18 - 14.10.19 - 00:52
Вылезла ещё одна проблемка, берём товар из справочника ТМЦ:
Монитор LG 21.5" 22MK400A-B 16:9, 1920x1080, TN+Film, 60 Гц, D-Sub (VGA).
Его модель, это "22MK400A-B"

Для данного 1с товара коды поставщиков могут быть определены не из всех прайсов, а например только из двух.
Но по факту монитор с моделью "22MK400A-B" может быть в большем количестве прайсов.

И соответственно хотелось бы искать этот товар не только по установленным связям /этот поиск конечно очень быстрый/,
но и по нахождению модели товара в столбце прайса "Наименование товара", а этот поиск в 1с /в отличии от тогоже Excel/ происходит очень не быстро.

Каким образом ускорить данный поиск?
   ДенисЧ
 
19 - 14.10.19 - 05:14
(18) "Каким образом ускорить данный поиск?"

Прямые запросы черезSQL
   Chameleon1980
 
20 - 14.10.19 - 06:00
Я, конечно, давно не брал в руки 77.
У ва же товар делится на поставщиков?
отталкиваемся от товара
создаём подчинённый товарам спр. Ценыпоставщиков
С реквизитами поставщик, цена и далее по вкусу
Ищем в этом всём, как сказал ДенисЧ прямыми запросами.
не?
   МимохожийОднако
 
21 - 14.10.19 - 06:33
(9) Нет смысла использовать документы. Достаточно периодических реквизитов подчиненного справочника. Но если нужны только последние цены, то и периодичности не надо.
...
Но в данном случае проблема в получении актуальных данных от поставщиков и синхронизации номенклатуры в разнородных наименованиях. Правда, я повторяюсь. Об этом уже писали выше.
   evgpinsk_
 
22 - 14.10.19 - 08:08
(19) Ясно, буду вникать в прямые запросы
(21) Первый раз, в момент оприходования, только руками синхронизировать номенклатуру поставщика с номенклатурой 1с.
   evgpinsk_
 
23 - 14.10.19 - 08:11
(20) Всё-таки есть ещё один справочник "ФайлыПрайсов". В нём указываю характеристики прайса
   Сияющий в темноте
 
24 - 14.10.19 - 08:44
Основной подводный камень данной задачи-сопостааление товаров из разнвх прайсов.
то есть,нужен парсер,который будет сопоставлять наименования.
остальное в задаче тривиально - поиск по цене.
просто,все товары сопоставить вручную нереально,а также нужно понимать,что есть аналоги,в чем то очень похожие,но имеющие различия,и менеждер должен увидеть список подходчщих товаров с указанием различий.
   evgpinsk_
 
25 - 14.10.19 - 08:50
(24) Парсер тут не напишешь, только ручное сопоставление /в прайсах (или приходных накладных) часто есть атрибуты товара, по которым помагает автоматизация - модель или штрихкод/, это уже работает.
   evgpinsk_
 
26 - 14.10.19 - 08:54
Сопоставление автоматизировано происходит через процедуру оприходвания товара. В екселевском файле прайса вычленяется Артикул товара /он либо есть изначально в отдельном столбце либо в полуавтоматическом режиме вычленяется из наименования товара/, и уже по Артикулу происходит сопоставление.
   ikea
 
27 - 14.10.19 - 10:15
(0)  Структура должна быть следующей - есть справочник "Товары прайсов", а к нем подчиненный справочник "Поставщики". Соответственно, при загрузке прайса от поставщика нужно будет находить товар в справочнике "Товары прайсов" и добавлять/изменять данные в подчиненном. Такая структура дает возможность очень быстро выводить информацию по массиву товаров, не нагружая систему. Основная нагрузка будет при загрузке прайса, что можно делать ночью, добавляя необходимые условия по поиску ввиде масок, неполного вхождения и т.д.
   VladZ
 
28 - 14.10.19 - 10:52
(16) "Для меня главное - скорость нахождения цены товара в массиве данных." - используй прямые запросы. Скорость будет космическая.
   Злопчинский
 
29 - 14.10.19 - 11:19
(5) совсем необязательно.
делал такую штуку в (0) как "ПрайсАналит" для фармации более 10 лет назад. на основе strmatch. использовал ТИС расширенную возможностями спр.Аналоги.
разработана подсистема, регламентные процедуры (автопривязки, доработки сопоставления) и прочее.
отдельно также учитывались отсрочечные и предоплатные прайсы.
работало. в пике около 15 прайсов работало.
на день определяляся предпочиттельный поставщик по отсрочке и по оплате (писался в карточку товара) - на их основе заявки покупателй автоматом разносились по поставщикам. были также приоритеты поставщиков. грузились автоматом прайсы по привязкам, автообнаружение\регистрация новинок для последующей автообработки, вкл\выкл активных позиций в прайсе и всякое еще.
не скажу чтобы было все на 100% автоматизировано, но все в целом работало. лаже года три после того как ушел (далее инфы нет).
   Злопчинский
 
30 - 14.10.19 - 11:24
(12) в этом случае обработка ничего анализировать не должна. все анализы делаются "регламентами" на этапе заказчки\подготовки данных. отобразить из готовых данных - даже без всяких ухищрений будет выводить за 1-2 сек для одной текущей позиции.
у меня строился отчет при необходимости с лучшими ценами и по убыванию остальные прайсы\цены с допинфой насколько дороже и пр.
основная проблема - что мутные поставщики декларируют в прайсе отсутсвующие товары, и при поступлении от тебя заказа точно также начинают пропихивать позицию дальше. и не выдерживают сроков поставок и заказанной (в итоге у них) номенклатуры. такие поставщики отмечаются как ненадежные
 
 Рекламное место пустует
   evgpinsk_
 
31 - 14.10.19 - 12:43
(30) "все анализы делаются "регламентами" на этапе заказчки\подготовки данных. отобразить из готовых данных - даже без всяких ухищрений будет выводить за 1-2 сек для одной текущей позиции."

но всё-таки без прямых запросов скорее всего не обойтись, если нужна фильтрация справочника по совпадению подстроки поиска.
   evgpinsk_
 
32 - 14.10.19 - 12:44
(30) "в этом случае обработка ничего анализировать не должна. все анализы делаются "регламентами" на этапе заказчки\подготовки данных"
Да, поэтому и задумался над закачкой екселевских прайсов заранее в 1с.
Была мысль решать задачу через онлайн обращение к екселевским файлам, но скорее всего это будет медленнее
   Kigo_Kigo
 
33 - 14.10.19 - 12:47
(32) Смотря какие файлы, с некоторыми 1с ка тупит не по детски
   evgpinsk_
 
34 - 14.10.19 - 12:47
(27) " Структура должна быть следующей - есть справочник "Товары прайсов", а к нем подчиненный справочник "Поставщики""

Что-то не понятно. По логике должно быть наоборот. Есть основной справочник "Поставщики" (или как у меня "ПрайсыПоставщиков") и уже к нему подчинённый справочник "Товары прайсов"
   evgpinsk_
 
35 - 14.10.19 - 12:49
(33) Имеются ввиду файлы больших объёмов?
Большого значения ведь это не имеет, раз закачка будет происходить регламентно, один раз в сутки ночью
   Kigo_Kigo
 
36 - 14.10.19 - 12:53
(34) А что тут не понятного то? читаем прайс из экселя, находим его, пишем в подчиненный справочник "поставщик" "цена" "дата", не находит, создаем новый товар и далее по тексту, я уже выше сказал, манагер находит нужный товар, открывает справочник поставщики- смотрит цены
(35) Имеет, еще как имеет, вы попробуйте любую таблицу больше 5000 строк в эксель сохранить, я у не говорю про прочитать
   ADirks
 
37 - 14.10.19 - 13:38
(0) Если делать всё прямыми запросами, то вообще один справочник с нужными полями (товар, поставщик, дата, цена).
Кстати, дату таки рекомендую иметь, а то потом ведь захочется как-нибудь динамику поанализировать.
   Злопчинский
 
38 - 14.10.19 - 13:42
(31) мля, это надо делать не в оперативной работе менеджера.
а в "регламентах" (полуавтоматических) по засасыванию прайсов.
   Злопчинский
 
39 - 14.10.19 - 13:44
(32) совет. делай так:
все присылают разные эксели.
под каждый эксель пишешь "нормализатор" (например, есть прйас где артикул и наименование - в одной колонке, нормализатор делит это на две колонки).
а потом уже нормализованный прайс обрабатываешь штатно загрузчиком\привязчиком
   evgpinsk_
 
40 - 14.10.19 - 13:46
(38) Так я вроде уже несколько раз сам выше писал, иимпорт прайсов делается регламентно ночью.
   Злопчинский
 
41 - 14.10.19 - 13:47
(35) полностью автоматом обработку тебе не удастся сделать.
работа будет полуавтоматической. ибо никто не даст 100% гарантии безошибочного ПРИВЯЗЫВАНИЯ. частью моего упоминавшегося аналит-прайса и была выстроенная технология работы по быстрой привязке. часть делалось автоматом, но потом ступенчато верифицировалось персоналом.
.
совет: для автопривязки прайса если позиция непривязана - делать попытку автопривязки к товару в базе. если нет - смотреть привязки к товару в базе по уже привязанным прайсам. это существенно повышает валдиность и выхлоп автопривязки.
   evgpinsk_
 
42 - 14.10.19 - 13:50
(41) "полностью автоматом обработку тебе не удастся сделать."

Понимаю заняты, и все сообщения выше не перечитаешь )
Но именно это я и писал выше.
Привзяка у меня уже идёт и работает давно. Сейчас вот решил ещё добавить функционала
   evgpinsk_
 
43 - 14.10.19 - 13:52
(39) Вот именно для этого и служит мой справочник "Файлыпрайсов", фото тут: (6)
В котором на каждом прайсе и расписывается, в каком столбце название товара, цены товара, гарантия и другие характеристики, нужные для импорта
   evgpinsk_
 
44 - 14.10.19 - 13:57
А привязка у меня идёт для каждого товара, т.е. для справочника 1с номенклатуры товаров  есть подчинённый справочник "КодыПоставщиков"
в нём два поля: "Прайс поставщика" и "Код поставщика".
Визуально это выглядит так:
http://prntscr.com/pj0pbt
   evgpinsk_
 
45 - 14.10.19 - 14:16
И поэтому я както не воспринимаю предлагаемую "наоборот" структуру (27)
"  Структура должна быть следующей - есть справочник "Товары прайсов", а к нем подчиненный справочник "Поставщики""

Както мне логичней, когда есть прайс поставщика, и для данного прайса в подчинённый справочник добавляются все его товары
   ikea
 
46 - 14.10.19 - 23:26
(45) Что не понятного в  (27)? Сам же написал "Цель: нужно быстро находить цены на один и тотже товар от разных поставщик ". Один раз товар нашел и тут же получил список поставщиков с ценами - это быстрее, чем найти один и тот же товар по всем прайсам!
Если тебе поставят например, задачу расценку на тендеры, где нужно будет расценить 2000-3000 позиций, то твой вариант может отрабатывать неприемлемое время.
Видимо, база совсем маленькая, поэтому разницы не видишь от своей структуры. Вот если бы ты позанимался запчастями, где один прайс в среднем 20000 позиций, а у некоторых и по 300 тысяч, вот тогда разницу бы ощутил сразу же - упала бы 1С искать по всем прайсам один и тот же товар.
   evgpinsk_
 
47 - 15.10.19 - 00:26
(46) Теперь смысл понял. Только не совсем понятна структура справочника "ТоварыПрайсов" и его подчинённость справочнику номенклатуры в 1с
   evgpinsk_
 
48 - 15.10.19 - 00:33
Врубил. Справочник "ТоварыПрайсов" у меня уже есть, под названием "КодыТМЦПоставщиков"
Этот справочник подчинён справочнику ТМЦ. Просто в это справочник нужно добавить реквизит ЦенаИзПрайсаПоставщика
Видно на фото:
http://prntscr.com/pj9umn
   evgpinsk_
 
49 - 15.10.19 - 00:51
(46) Всё-таки не пойму, как взаимосвязаны справочник номенклатуры ТМЦ из 1с, и этот новый справочник "ТоварыПрайсов" ?
   evgpinsk_
 
50 - 15.10.19 - 01:17
В моём случае справочник"КодыТМЦПоставщиков" /в нём поля: КодТМЦПоставщика, ЦенаПоставщика, КодПрайса/ есть подчинённый справочник относительно справочника Номенклатуры.
Но в таком случае регламентный запрос не сможет добавлять в этот справочник новые товары из прайсов. Ведь взаимосвязь между номенклатурами может установить только Закупщик руками (гадать с большой долей вероятности тут  нельзя).

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

А процедура поиска цен будет состоять из двух этапов, быстрый и точный этап - для выбранного товара читаем подчинённый справочник с ценами поставщиков.
И второй этап  - через прямые запросы фильтруем по моделе товара справочник "ТоварыПрайсовПоставщиков". И в данном случае в ТЗ результат по маске модели товара могут попадать лишние товары, манагер глазами будет их отсекать.
   Chameleon1980
 
51 - 15.10.19 - 06:06
Ой пля. Я бы уже про другую задачу думал. Автор ты уже начал реализацию
Хоть ЧЕГОТО?
   Chameleon1980
 
52 - 15.10.19 - 06:08
Бери (20) и вперде.
   andrewalexk
 
53 - 15.10.19 - 07:49
(1) :) ... а вот правительство на словах как раз поддерживает малый бизнес...
   evgpinsk_
 
54 - 15.10.19 - 08:43
(52) у товара максимум 10 поставщиков. Прямые запросы для этого поиска не нужны
   Chameleon1980
 
55 - 15.10.19 - 08:51
(54) бля ну не нужно не бери. Я тебе сказал, что слишком долго думаешь
Над простым. Подчинённый и вперде. Нужно тебе настройки для файла поставщика сделай справочник подчинённый контрагентам. Будут у тебя мменованные настройки под каждого поставщика. Долгий ты.
   evgpinsk_
 
56 - 15.10.19 - 09:11
(55) "Нужно тебе настройки для файла поставщика сделай справочник подчинённый контрагента".
Этот справочник также уже есть.
Вопрос был именно в том, какую структуру сделать для тех товаров, которые есть в прайсах поставщиков, но пока ещё не увязаны с номенклатурой 1с.
Мне советуют (27), когда цены поставщиков подчинены номенклатуре 1с, но этот вариант /насколько я понимаю/ не проходит, т.к. загрузчик не сможет сам построить взаимосвязи между разными номенклатурами.
Получается решение должно быть как здесь на фото (17)
   evgpinsk_
 
57 - 15.10.19 - 09:42
(41) Вот Злопчинский меня понимает, т.к. сам решал похожую задачу )
п.с. мои посты - это наполовину мои размышления, которые помогают найти мне правильное решение.

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

Автоматически прайсы импортируются в НЕ связанный с номенклатурой 1с справочник, в котором поиск осуществляется через прямые запросы, результатом этого поиска будет ТЗ с примерный соответствием
   Злопчинский
 
58 - 15.10.19 - 13:58
(57) я вообще не вижу противоречий в том чтоя рассуждаю и что пипл говорит.

.


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

будут вопросы - стучись в личку
   evgpinsk_
 
59 - 15.10.19 - 14:27
(58) Давай на примере поясню
У меня в 1с есть товар:
     21426  Монитор 21.5" LG 22MP48A-P Black (IPS, LED, Dsub)
http://prntscr.com/pjipq4

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

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

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

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

В теории можно сканить сами экселевские прайсы и ничего не импортировать, но думаю этот процесс будет не самым быстрым
   evgpinsk_
 
61 - 15.10.19 - 14:38
И вот тут мне не понятен совет (27), каким образом программа сама может в прайсе Мерлиона найти по модели "22MP48A-P" нужный товар, его код  и цену и добавить эту инфу в подчинённый номенклатуре 1с справочник "ЦеныИзПрайсовПоставщиков" ??
   evgpinsk_
 
62 - 15.10.19 - 14:50
Как изначально планировал я решение, оно на фото:
https://prnt.sc/pisktv
Сначала алгоритм читает через ADO екселевский файл в ТЗ, а потом из ТЗ его перекидывает в отдельный справочник "ТоварыПоставщиковВПрайсах", который является подчинённым справочнику "Прайсы" - это всё ночью.

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

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

"Чтобы манагер в справочнике ТМЦ нажал на кнопочку.." - это когда он делает? во время загрузки\вбивания приходного документа (как ты обозначал?) или ты все же хочешь чтото делать отдельно от оприходовани документов?
   evgpinsk_
 
64 - 15.10.19 - 14:53
"я тебе давно написал - нет никакой 100% гарантии правильной автоматической привязки."
Я же это прекрасно понимаю.

"Чтобы манагер в справочнике ТМЦ нажал на кнопочку.." - это когда он делает?
например когда выставляет кому-нибудь счёт и хочет увидеть актуальные цены из прайсов. Это происходит отдельно от оприходования/сопоставления
   Злопчинский
 
65 - 15.10.19 - 14:54
(62) угу. прямые запросы здесь, возможно, инструмент ускорения, но не инструмент сопоставления. на ИС есть разные алгоритмы сопоставления.
я использовал ВК strmatch.

можно привязывать товар из спр.номенклатуры к прайсу поставщика, а можно наоборот - зависит от ситуации.
.
еще раз: с сипользованием strmatch - подсказка менеджеру получается очень выскокэффективной. даже если названия разнятся, написаны с ошибками и пр.
.
основное время сьедает подготовка кэша для сравнения - вот здесь как раз прямые запросы и зарулят.
   Злопчинский
 
66 - 15.10.19 - 14:55
где что в каких справочниках хранить грузить - зависит от разрабатываемой архитектуры и наиболее часто выполняющихся задач с этими данными на этой архитектуре.
 
 Рекламное место пустует
   evgpinsk_
 
67 - 15.10.19 - 14:56
"я давно тебе сказал - НУЖНЫ РЕГЛАМЕНТНЫЕ ПРОЦЕДУРЫ ПРИВЯЗКИ."

Я пока не планирую над их созданием, т.к. они будут плохо работать. Тут по хорошему нужен ИИ.
Мне проще в екселе вычленять программно модели/артикулы товаров, и уже по ним искать товар в 1с, и если его нет,то создаётся новый товар, уже привязанный
   evgpinsk_
 
68 - 15.10.19 - 14:58
(63) "я вообще не пойму на чем ты тупишь? что тебя волнует? что не получается?"

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

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

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

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

не обязательно в таком порядке, но идеология такая.
привязку можно делать по каждому прайсу отдельно. можно в подсказку выкинуть все подходящие из всех непривязанных - и делать сразу множественную привязку.
я так и так делал, по ситуации.
по опыту - работо монтонная. ДОЛЖНО БЫТЬ ПРОСТО И КОНВЕЕРНО.
избешать множественных выборов, перегруженности списокв итд.
   Злопчинский
 
70 - 15.10.19 - 15:02
(67) млин, при чем здесь ИИ?
(регламентные - не значит полностью автоматические).
если ты можешь однозначно привязываться по артикулам и прочим ЯВНО ВЫДЕЛЕННЫМ ключевым полям - то още весь разгоовор? нет предмета обсуждения.
.
привязки с использованием STRMATCH - делаются хорошо.
вот и все что я хотел сказать.
.
пример: делается соспоставление (сделанное сопоставление\привязка) - не фиксируется http://catalog.mista.ru/public/14255/
   Злопчинский
 
71 - 15.10.19 - 15:06
(67) "они будут плохо работать"
- ну это смотряи какие прайсы и ка кони структурированы.
я глянул картинку - электроника.
я в свое время писал доработки людям для привязок в магазин игрушек, для бытовой техники и для радиоэлектронных компонент. народ был крайне доволен. смаый сложный был радиоэлектронные компоненты. потому что названия очень коротки и все похоже на все. там пришлось допэвристику подключить.

в твоем случае используя стрматч получится (имхо, хорошо). только вес цифр задрать повыше.
   evgpinsk_
 
72 - 15.10.19 - 15:07
(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"
   Злопчинский
 
73 - 15.10.19 - 15:11
(72) еще раз, для тупых ;-)
несколько раз - 100% гарантии не дает никто.
в этом примере скаорее всего первая позиция из трехпозиционного списка будет стоять в первой строке подсказки.
   evgpinsk_
 
74 - 15.10.19 - 15:13
Злопчинский )), прочитай ниже текст:

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

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


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

   Злопчинский - ответь мне по (27) и пока всё :)
   Arbuz
 
78 - 15.10.19 - 16:04
ب_ب упруго
   hhhh
 
79 - 15.10.19 - 16:27
(77) почему это он не может правильно привязывать? очень даже может.
   evgpinsk_
 
80 - 15.10.19 - 16:32
(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)


что по вашему программа должна закинуть в подчинённый справочник???
   Garykom
 
81 - 15.10.19 - 16:46
(80) Пойми ты пытаешься решить задачу которая на твоем уровне в принципе не решается.
   Kigo_Kigo
 
82 - 15.10.19 - 16:48
(81) Согласен, я бы 13.10.2019 часам к 23.00 ее уже накалякал бы :)
   evgpinsk_
 
83 - 15.10.19 - 16:57
(81) Уже много раз писал, и ещё раз: я не пытаюсь ОДНОЗНАЧНО научиться программно делать связки между номенклатурами. Я прекраснно понимаю, что эти связки можно строить только примерно, с относительной степенью вероятности.

Я последние постов 5 задаю только один вопрос, почему (27) совет считается верным )
   evgpinsk_
 
84 - 15.10.19 - 16:59
(82) С большего уже вчера было накалякано всё кроме прямых запросов. Но мне очень симпатичен анекдот про жену мужа и 3го, который не прав в интернете )

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

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

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

3. Итого каждой своей номенклатуре будет сопоставлена одна и более номенклатур поставщиков.
Искать можно в обе стороны.
Для удобства привязки добавляем в документу из п.1 реквизит НашаНоменклатура типа Номенклатура и при загрузке документа происходит по кнопке подбор из справочника привязок.
Выбор своей номенклатуры в документе аналогично делает запись в справочник ПривязкиНоменклатурыПоставщиков.
   Garykom
 
90 - 15.10.19 - 22:36
(89)+ Обработка распределения заявок будет заключаться в выборе одного документа со своей номенклатурой и нескольких документов-прайсов.
В итоге будет созданы разные документы ЗаказПоставщику на разных поставщиков, смотря сколько их выбрали и что оно подобрало.
   evgpinsk_
 
91 - 15.10.19 - 22:37
(85) "Стоит задача какая?
(на мой взгляд две)
1. при заполнении приходной накладной, имея товар поставщика (входящий инфопоток), получить товар из спр.номенклатура - либо по имеющимся привязкам (что очевидно), либо для товара поставщика (из входящего товаропотока) максимально быстро выбрать подходящие товары из базы, чтобы дать максимально возможную эффективную подсказку для ручной привязки."

Верно и первая задача была реализована ранее. Взаимосвязь номенклалтур просиходит либо по КодаТовара из прайса поставщика - это есть чёткая стопроцентная связь. Либо /для новых товаров/ по моделям товаров из 1с и входящего товаропотока (либо по штрихколам), но эти новые связи закупер пробегает глазами и перепроверяет
   evgpinsk_
 
92 - 15.10.19 - 22:40
(86) Сложно формулируете, нет чёткости, непонятна мысль
   evgpinsk_
 
93 - 15.10.19 - 22:47
(85) "при выставлении счета клиенту, имея текущий товар из спр.номенклатура - по какой-то кнопке видеть состояние этого товара у поставщиков, в т.ч. и по прайсам, к которых спр.номенклатура еще не привязан - выдать здесь к спр.номенклатура подсказкой для каждого/текущего непривязанного прайса поставщика список похожих позиций из прайса поставщика для ручной привязки."

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

Т.е. выбрали товар в счёт, прочитали подчинённый справочник "ЦенаИзПрайсов", это легко.
Затем через прямой запрос придётся отфильтровать те прайсы, которые не имеют привязки к выбранному товару в счёте.
   evgpinsk_
 
94 - 15.10.19 - 22:59
(89) Не увидел преимуществ в использовании документов вместо справочников. И,  не исключаю, что в вашем варианте с документами будет немного сложнее для товара из Номенклатуры 1с, искать в документах-прайсах нужные строки через прямой запрос.
   evgpinsk_
 
95 - 15.10.19 - 23:08
(85) "подводные камни (?навскидку, могу неправ)
- следует учесть, что в прайсе поставщика ВООБЩЕ может не быть позиции, которая может быть привязана к нашей спр.номенклатура, это значит что для пп 1.2 нужно иметь некий флаг"

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

Далее для группы товаров "Мониторы", определено всего 7 прайсов, в которых есть мониторы. Вот через прямой запрос в оставшихся четырёх прайсах и находим те позиции, в названии которых  содержится модель "22MP48A-P".
И выводим в отдельном окошке их манагеру ( и ничего страшного что из одного прайса было выбрано несколько строк, а из другого вообще ничего, манагер глазами сверит названия товаров и поймёт "правильность" поиска)
   Cthulhu
 
96 - 15.10.19 - 23:29
(92): там как раз настолько просто, что проще некуда.
В карточке контрагента каждому поставщику укажи свою основную категорию цены поставщика.
У номенклатурного справочника уже еть подчиненный справочник цен (причем периодический).
По прайсу по каждой строке узнаешь товар, зная поставщика - узнаешь его (и только его) категорию цены, в справочник цен этого ТМЦ импортируешь значение цены с такой категорией цены. все.
   evgpinsk_
 
97 - 15.10.19 - 23:32
(96) Что за понятие "категория цены" ?
   evgpinsk_
 
98 - 15.10.19 - 23:35
(96) "По прайсу по каждой строке узнаешь товар"
Каким образом Вы представляете для каждой строки прайса поставщика (в нём 5 тысяс строк, каждую неделю 5% прайса обновляется новыми товарами) УЗНАТЬ товар из номенклатуры 1с?
   hhhh
 
99 - 16.10.19 - 00:16
(98) ну, 5 тысяч - это почти 0, обычно в номенклатуре сотни тысяч наименований. Тем более вы их еще и на группы разобьете МОНИТОРЫ, МЫШИ, КЛАВЫ и т.д. В одной группе вообще меньше тысячи наименований будет. Наверно, с такой мелочью прямые запросы и не нужны, обычными 1с-запросами решите.
   Garykom
 
100 - 16.10.19 - 00:52
(94) Вы не увидели главного.
Я разделил прайсы поставщиков и привязки номенклатуры поставщиков к своей.

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

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.