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

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

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

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

Вопрос - правильно ли выбираю структуру данных?
 
 
   evgpinsk_
 
101 - 16.10.19 - 00:53
(100) "Я разделил прайсы поставщиков и привязки номенклатуры поставщиков к своей."

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

пример
прайс поставщика обновляется раз в неделю, в прайсе 30тыс позиций.
выставляешь клиенту1 счет. в счете твоя позиция "Монитор1" привязана к 3 прайсам. а всего у тебя 10 прайсов. ищешь свой монитор в этих 7 прайсах. в 2 он есть (привязал попутно), в 5 - его нет в принципе.
через час два три через два дня выставляешь счет клиенту2. позиция Монитор1. привязана к 5 прайсам. всего прайсов -10. сколько надо проверить непривязанных прайсов? - 5? нет. их вообще не надо проверять. потому что 2 дня назад уже было проверено и выяснено, что в 5 прайсах этой позиции нет в принципе.
если у тебя дохрена ресурсов - то можешь их тратить и грузить пользюка бестолковой работой - для Монитора1 предлагать из 5 непривязанных прайсов выбрать подходящее (а подходящее всегда будет, не на 95%, а на 30, или 15 или 5%) - итого у тебя пользюк бездарно пялится в экрна, тратит время. вдобавок лажает. потом лажа вылазит, тратится ресурс на ее исправление. нафига это все..?
   Злопчинский
 
103 - 16.10.19 - 02:05
(95) "( и ничего страшного что из одного прайса было выбрано несколько строк, а из другого вообще ничего, "
- вот тут ты ошибаешься.
из "другого вообще ничего" - так не будет в подавляющем количесве случаев. так как любое наименование похоже на любоедругое, хотя и с "маленькой" похожестью.
.
"монитор АБВ22" всегда будет похож на твой "монитор АБВ2", хотя и не является им. и будет выведен в список выбора.
.
такой ситуации можно избежать, если включать дополнительную "эвристику", но она работает для частных случаев. и надо быть увереным что этот частный случай присутсвует при "сверке\привязке" что совсем необязательно.
   Злопчинский
 
104 - 16.10.19 - 02:18
ситуации обрвботки прайсов могут быть улучшены если прайсы хоть както струткурированы и формализованы - как выше омечалось мониторы в разделе "мониторы" итд.
.
но обязательно в формализованный прайс появится внезапно подраздел "допродажа" где кучей будет свален всякое от поставщика и "формализация" не сработает.

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

фишка в том, что прайсы меняются каждый день, каждое утром приходят свежие
   evgpinsk_
 
106 - 16.10.19 - 08:12
(103) "- вот тут ты ошибаешься.
из "другого вообще ничего" - так не будет в подавляющем количесве случаев. так как любое наименование похоже на любоедругое, хотя и с "маленькой" похожестью."
_______________
нет. обычно (в 95%) модели товаров уникальны, т.е. в екселе поиск по моделе срабатывает только один раз. Но конечно зависит от применяемого метода нахождения "похожего" товара. Я пока вижу использование обычного Like
   evgpinsk_
 
107 - 16.10.19 - 08:16
(104) Вс-ётаки у меня  в закупке компьютеры ), наиболее продвинутые в этом плане продавцы. Данные ситуации для них уже практически не встречаются, все более менее стали грамотно вести прайсы.

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

а придет у тебя прайс в один раз где вметсо модели
АБС123-22 будет запись АБС123/22 и твой лайк по "АБС123-22" накроется медным тазиком...
   Arbuz
 
109 - 16.10.19 - 15:08
ну, польза всё же есть - Злопчинский прямо жжёт своим опытом. не останавливайся, я записываю. серьёзно.
   Злопчинский
 
110 - 16.10.19 - 15:26
(109) у меня на тлф, кстати, скоро деньга заканчивается... ;-)
   Злопчинский
 
111 - 16.10.19 - 15:28
(107) "Вс-ётаки у меня  в закупке компьютеры ), наиболее продвинутые в этом плане продавцы."
- это вот хорошо, если удастся получаемые прайсы в достаточной строгой форме иметь и быть уверенным в их более-менее относительной стабильност
   evgpinsk_
 
112 - 16.10.19 - 17:28
(108) "память ты тоже будешь искать по модели? что будет являться для память "моделью" - DDR2666 или просто DDR? (условно)."
_____________
Любой товар имеет модель/артикул. Применительно к памяти у васех поставщик она идёт применительно так:
Оперативная память SO-DDR-3 8GB PC-12800 Patriot [PSD38G16002S].
т.е. имеет свою уникальную модель в []
   Garykom
 
113 - 16.10.19 - 17:30
(112) "PSD38G16002S" чем отличается от "PSD38G16002S" ?
   evgpinsk_
 
114 - 16.10.19 - 17:31
(108) "лайк это конечно хорошо, если ты уверен в том что поставщики дают все записано и разнесено по столбцам правильно (то есть ты надеешься на человеческий фактор, бо хз как у них и кто прайсы готовит)."

Лайк будет использоваться ТОЛЬКО для манагера-продавца, когда он хочет найти цены поставщиков из прайсов. Взаимосвязь между номенклатурами устанавливает только Закупер в момент оприходования товара, поэтому ничего не накроется медным тазом )
   evgpinsk_
 
115 - 16.10.19 - 17:32
(113) Нажал CTRL+F
http://prntscr.com/pk4dz8
и вижу что ничем ))
   evgpinsk_
 
116 - 16.10.19 - 17:36
(108) "а придет у тебя прайс в один раз где вместо модели
АБС123-22 будет запись АБС123/22"
_____________
Вы както очень уж недооцениваете компьютерщиков )
1. Они редко у себя в базе меняют названия товаров, но это и не важно т.к.
2. Когда первый раз я оприходовал эту память от этого поставщика, взаимосвязь между номенклатурами установилась по КодуТовараПоставщика и мне в дальнейшем не важно, как меняются названия товаров и даже их модели.
   Garykom
 
117 - 16.10.19 - 17:40
(115) Ну да сложно искать кошку в темной комнате если ее там нет ))
Но наверно догадался про хреново визуальное отличимую разницу между Р и P.
   evgpinsk_
 
118 - 16.10.19 - 17:46
(117) "Но наверно догадался про хреново визуальное отличимую разницу между Р и P."
_______________
Ну так нужно было наверное поменять раскладку языка ? ))
   evgpinsk_
 
119 - 16.10.19 - 17:52
(117) Да, иного /редко/ попадаются изверги, которые в моделях которые написаны латиницей, используют русские буквы, т.е. в "PSD38G16002S"
первой буквой у них идёт русская буква "ЭР"
Возможно это получается, что они сканируют свои приходы и Файнреадер ошибается, не знаю. НО:

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

А взаимосвязь между номенклатурами у меня создаётся в полуавтоматическом режиме, только Закупером и с контролем глазами, переложить эту задачу 100%но на какойто алгоритм не получится
   botman4
 
120 - 16.10.19 - 22:10
Реализовывал загрузку прайсов с 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 за ценами.
   Злопчинский
 
121 - 16.10.19 - 22:11
(117) вот именно. а strmatch скорее всего отловит это ка кочень похожее
   evgpinsk_
 
122 - 03.11.19 - 21:09
(120) Предположим прайс содержит 200 тыс строк.

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

п.с. Сейчас я прайсы поставщиков храню в 1с, и фильтрация справочника в 40тыс строк занимает около 4сек.
Хотелось бы быстрее
   Garykom
 
123 - 03.11.19 - 21:20
(122) Быстрее это инмемори базы данных и предварительное хеширование по ключевым словам.
Особо крут simhash и другие подобные.
   evgpinsk_
 
124 - 03.11.19 - 21:28
(123) Пока мне не нужны высокие материи ).
Только лишь понимать, где лучше хранить относительно объёмные прайсы /пусть 50-100 тыс строк - весь массив прайсов/
Или в самой 1с или в сторонней базе
   evgpinsk_
 
125 - 03.11.19 - 23:22
Да, стандартными средствами 1с очистка большого справочника - очень длительная процедура.
   Djelf
 
126 - 04.11.19 - 07:40
(122) Если хочется скорости то в базе sqlite, а к ней прикрутить расширение FTS https://www.sqlite.org/fts3.html
Очистку справочников 1С тоже можно сделать из sqlite. Но не уверен насколько быстрее, не измерял.
   evgpinsk_
 
127 - 04.11.19 - 11:20
Правильно ли я понимаю, что если данные хранить в справочниках 1с, то добавлять в него данные можно только простым перебором в цикле? SQL команды Insert нет?
10тыс строк очень долго штатными средствами 1с добавляется. Точно также и удаление
   HawkEye
 
128 - 04.11.19 - 11:21
(127) пиши в транзакциях пакетами по 300-500 элементов...
   Djelf
 
129 - 04.11.19 - 11:36
(127) DELETE то я реализовал, это оказалось довольно просто, а вот INSERT и UPDATE фактически потребуют создания объектов, более низкоуровневого варианта я не нашел. Так что да, их нет и не предвидеться.
   evgpinsk_
 
130 - 04.11.19 - 11:50
(129) И у 1sqlite нет этих операторов?
 
 Рекламное место пустует
   Djelf
 
131 - 04.11.19 - 11:51
(130) Конечно есть. Я про базу 1С. С базой 1С только SELECT и DELETE.
   evgpinsk_
 
132 - 04.11.19 - 11:57
(128) Да, не плохое ускорение. в 26 раз быстрее с транзакцией /пока сразу всю процедуру включил в транзакции, не разбивал на циклы/
   HawkEye
 
133 - 04.11.19 - 12:15
(132) на 10 000 записях...
без транзакции: около 3 мин
в одной транзакции: около 1 мин.
с пакетными транзакциями: 30 сек
   Garykom
 
134 - 04.11.19 - 12:20
(124) Начни с гугления "adodb 1c"
Нечто вроде https://mudritskiy.blogspot.com/2013/05/1-adodb.html
   Garykom
 
135 - 04.11.19 - 12:21
(134)+ Список БД с которыми можно через ado nen https://ru.wikipedia.org/wiki/ADOdb
   Garykom
 
136 - 04.11.19 - 12:21
(135) *nen = тут
  1  2

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