Товарищи, коллеги, собратья!)
Помогите, пожалуйста, советом) А быть может и решением…
Дано —
гигантская таблица с номенклатурой, в excel, которая обновляется по цене, скажем раз в квартал… Ответственный человек, также раз в квартал, берет ее и переносит данные вручную в Storehouse.
Номенклатура в excel и shouse по наименованию не совпадает…
Тоесть есть какие-то опознавательные знаки, по которым можно найти позицию и в excel и shouse, но наименования не идентичны…
Вопрос — как автоматизировать перенос данных из excel в shouse?
Пока в голове, на уровне дауна, идея — выгружать в xls таблицу номенклатуры с shouse, каким-то макаром сверять с исходной excel по общим «маркерам» в наименованиях и автоматом вносить в выгруженный shouse…. затем заливать его обратно…
В том ли направлении смотрю? Может есть готовые решения или кто-то писал что-нибудь подобное «на коленке»?
Буду рад любой помощи, человек чуть ли не умирает от этих таблиц, настолько это муторно и долго.
Спасибо.
Там вроде Interbase в качестве БД, я бы рекомендовала сделать нормальный ETL-процесс, для наименований завести словарь, первично состыковать имена по расстоянию Левенштейна с разбивкой по словам, на каждое изменение цены (загрузку) заводить документ, чтобы это прозрачно отрабатывалось в системе.
как это технически реализовать?) можешь показать в какую сторону копать?
Если самому такую штуку проектировать, то надо бы, наверное, так:
1) загрузить Excel файл в таблицу Interbase внешней самописно утилитой
2) провести проверку значений — где они должны быть обязательны, где допустимы только цифры, где должны быть только индивидуальные значения
3) первичный Data Cleansing
4) из поля Наименование сделать список, разбить его по словам, собрать хэши (типа soundex) и ссылки наименований на слова, и собрать такую же информацию по наименованиям в базе, и собрать релевантность для каждой пары наименований из файла и базы, низко-релевантные пары можно сразу же отсеивать, потом профильтровать похожие «конкурирующие пары» по алгоритму расстояния Левенштейна, оставив только 1 с наименьшим расстоянием.
Ну или сопоставить 1 раз список наименований в файле и базе вручную.
5) Создать документ, кторый меняет эти цены и заполнить его, преобразуя наименование по получившемуся словарю в айдишки номенклатуры, с новой ценой ессесно.
6) Вторичный Data Cleansing
7) документ «провести» в системе
Вот как-то так. С самим StoreHouse особо не знаком, но имел дело когда-то с их кипером и 1С, не думаю, что общая концепция сильно изменилась.
очень хорошо написано, спасибо, буду пробовать разбираться как это сделать)
Если есть время и желание сделать самому, то п.4 будет весьма интересным)
Между полем наименование и отдельными словами надо будет реализовать связь меногие-ко-многим, слова из словаря очистить от «стоп-слов» — вроде «и» и т.п. общеупотребимых слов и союзов, скорее всего и от символов, а сами слова привести к одному регистру.
С Soundex тоже будет интересно, т.к. оригинальный алгоритм адаптирован под английские слова, но есть так называемый «восточно-европейский soundex» или Daitch-Mokotoff Soundex, единственно этот алгоритм тоже надо будет адаптировать под кириллицу (если она используется) — простая транслитерация должна подойти. По хэшам сопоставлять отдельные слова значительно проще. Мерой релевантности в данном случае будет количество слов в единичном наименовании из, скажем, файла, которые нашли похожие слова в одном и том же наименовании из базы, по отношению к общему количеству слов в наименовании из файла. Это считается простым агрегирующим запросом.
Но важно понимать, что даже единица не может означать точного совпадения наименований и нужна еще проверка по расстоянию Левенштейна (или даже лучше — расстояние Дамерау-Левенштейна). Реализации как DM Soundex, так и расстояния Дамерау-Левенштейна есть в сети.
Первичный Data Cleansing включает в себя по возможности исправление «косяков» в данных, которые могут быть исправлены автоматически, и принятие решения о судьбе данных, которые не могут быть исправлены — удалить или оставить на усмотрение оператора.
Вторичный Data Cleansing должен включать контроль за сопоставлением наименований, обработку дублирующих записей, возникших по многим причинам — когда одному наименованию номенклатуры в файле сопоставляются несколько в базе и наоборот, контроль прочих условий (например, если цена не может снижаться) и т.п.