Обработка запросов по наличию и ценам

[VKot]

Дано:
1. Прайс-лист на 10 тысяч позиций и склад (в наличии обычно около 60%).
2. Запросы от клиентов, в количестве около 20 ежедневно, объёмом 5-6 тысяч позиций в день в сумме.
Позиции в запросах клиентов называются иначе, чем в моём прайсе (и у каждого по-своему в основном). В среднем в запросах 30% позиций имеются у меня в наличии.

Задача:
Найти такую программу складского учета, в которой была бы предусмотрена возможность составлять ответы на такие запросы более или менее автоматически. По крайней мере у оператора не должно уходить на обработку одной позиции более 3-5 секунд. "Мышкование" в классически устроенных складах не устраивает: слишком долго, к тому же оператор иногда ошибается. Перевести клиентов под мою систему обозначений нельзя. Своя программа для этого дела есть, но ищу замену: не верю, что такая задача редко встречается - значит, должны быть готовые решения. Может быть, проще купить, чем самому выращивать.

Не подскажете?

[Mrak]

Как может быть мнее 3-5 секунд на обработку 1 позиции, если у клиентов позиции называются по-другому?..
Если только организовать своей номенклутаре синонимы названий по обозначениям клиентов и делать обработку их заказы автоматически, если через файлы идут заказы...

[Dracosha Andrew]

По крайней мере у оператора не должно уходить на обработку одной позиции более 3-5 секунд.

Не подскажете?

3-5 секунд не реальные сроки.

Оператор ваш просто не поймёт что нужно.
Если 3-5 секунд на обработку запроса на сервере - вполне возможно.

Я так понимаю вам не столько программа нужна, сколько форма, алгоритм поиска.Что-то типа надстройки. Если б вы работали на 1С я бы рекомендовал использовать библиотеку rainbow, если память мне не врёт. Она позволяет напрямую обращатся к SQL серверу. Если у вас система работает на чём-то другом - к разработчикам. В любом случае, это не проблема при правильном подходе к задаче.

А что у вас сейчас?

[VKot]

Как может быть мнее 3-5 секунд на обработку 1 позиции, если у клиентов позиции называются по-другому?..
Если только организовать своей номенклутаре синонимы названий по обозначениям клиентов и делать обработку их заказы автоматически, если через файлы идут заказы...

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

Заказы присылаются либо в книгах XLS, либо в файлах DBF, либо обычным текстом (по одному названию в каждой строке)

[Mrak]

VKot, это можно организовать в 1С, доработать типовую конфигурацию, либо написать новую. Для каждого клиента завести его название и вид файла заказа. И обработку соответвтующую написать.

[VKot]

3-5 секунд не реальные сроки.

Оператор ваш просто не поймёт что нужно.
Если 3-5 секунд на обработку запроса на сервере - вполне возможно.

Я так понимаю вам не столько программа нужна, сколько форма, алгоритм поиска.Что-то типа надстройки. Если б вы работали на 1С я бы рекомендовал использовать библиотеку rainbow, если память мне не врёт. Она позволяет напрямую обращатся к SQL серверу. Если у вас система работает на чём-то другом - к разработчикам. В любом случае, это не проблема при правильном подходе к задаче.

А что у вас сейчас?

Понять за 3-5 секунд реально, нереально найти нужную категорию -> прокрутить её до нужной позиции -> нажать кнопку "добавить" -> перейти в окно с заказом, чтобы посмотреть, какая позиция следующая -> и т.д.. Ну, вы понимаете, о чем речь.

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

Система с "синонимами" изначально правильная, но сейчас она не фактически у нас не реализована. Поэтому прежде, чем её делать, хочу поискать готовые решения.

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

По поводу 1С: этот вариант пока текущий, с написанием конфигурации "под нас". Но хотелось бы знать и другие варианты.

[VKot]

Dracosha Andrew, Mrak
Я так понимаю, что ничего похожего среди готовых систем, по вашим сведениям, нет?
Тогда вопрос - сколько бы стоила конфигурация с такими возможностями к 1С? Если нужны какие-либо подробности, отвечу

[Mrak]

VKot, среди готовых, думаю, нет.
Проще доработать типовую, чем разрабатывать новую.

[VKot]

Mrak, тогда: сколько бы стоила доработка? Хотя бы порядок величины (извините уж за назойливость

[Dracosha Andrew]

VKot, есть, только те, что я знаю стоят 12000 (не рублей). Если доработка 1С то за 200-300 я бы сам бы взялся , если б было время. В Питере я знаю человека, который такие вещи делал неоднократно, могу дать адрес. Но условие - обязательно SQL версия, иначе скорость не та, в случае DBF версии преимущества не получите.

[Mrak]

VKot, если честно по московским ценам я еще не ориентируюсь пока.
Долларов 100 может быть.

[Dracosha Andrew]

Mrak, порядок похожий. Это просто я такой жадный. Примерная трудоёмкость 10-12 часов работы. (10 долларов в час по рекомендации 1С 100-120)

[VKot]

Dracosha Andrew, за 12000 нерублей я сам буду запросы обрабатывать
200-300 - это дёшево! Франчайзеры предлагали гораздо дороже. Единственное - SQL версия предполагает лицензию за 2 тысячи тоже, в общем-то, не рублей...
Mrak, сто долларов за такую доработку отдал бы прямо сразу, наличными, не торгуясь Боюсь, там всё сложнее. Если интересно, могу более подробно почтой

[Mrak]

VKot, может франчи предлагали отдельную конфигурацию писать? А вообще интересно.

[VKot]

Mrak, франчи, судя по всему, хотели бабла слупить Письмо получил, ответ пишу.

[Mrak]

VKot, вам надо просто отчет по остаткам по заявкам клиентов?

[VKot]

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

А так - да.

[Dracosha Andrew]

Единственное - SQL версия предполагает лицензию за 2 тысячи тоже, в общем-то, не рублей...

К сожалению, 100% уверенности, что это можно сделать на другой платформе у меня нет. Как вариант, можно попробывать прикрутить ADO от 8-ого или 9-ого фокса, но то, что скорость будет ниже чем на SQL стопудово. Можно, конечно, на это дело специальный сервер запросов организовать , но конечная цена (железо+работа) будет тех же порядков. Чудес не бывает. А жаль...

[VKot]

Dracosha Andrew, неужели это такая тяжелая (в смысле нагрузки на железо) задача? Вопрос, конечно, риторический...
Просто у меня лицензия на SQL-сервер в бюджет не укладывается

[Dracosha Andrew]

VKot, Нет не тяжёлая, можно и на сервере с базой запустить. Сэмулировать так сказать SQL.

[training1C]

Давайте, давайте.
Как прочитаете полное тех. задание - опухните.
100 - 200-300 - это смешно.

[Mrak]

training1C, ну сама обработка запросов и формирование выходных файлов - примерно столько и стоит.

[training1C]

Mrak, короче, напишите человеку ради интереса и возьмитесь за это дело.

Если вы решите проблему человека за 200 долларов в том виде, в котором он хочет, то я готов доплатить еще 200 долларов и получить эту разработку.

[Mrak]

training1C, ради интереса я эту обработку написал как раз по тем задачам, который написаны в 1 посте.

[training1C]

По посту или по ТЗ?

[Dracosha Andrew]

training1C, человеку надо просто организовать быстрый неточный поиск.
SQL имеет для этого средства. а всё остальное - это уже роскошь.

[Mrak]

training1C, по посту и часть по письму. Обрабатываются файлы заказов и формируются ответы.

[VKot]

training1C, ради интереса я эту обработку написал как раз по тем задачам, который написаны в 1 посте.

Подтверждаю

быстрый неточный поиск

Если бы "неточный". Неточный уже есть . На самом деле, нужен точный поиск. Только простого введения синонимов мне всё-таки мало... Поскольку одной позиции у клиента может соответствовать несколько позиций у меня (бывают такие "аналоги"). И ещё бывает, что при отсутствии на складе какой-либо позиции вместо неё надо предложить другую.

Нужно было сразу написать, как disclaimer: содержимое поста не является исчерпывающим описанием задачи!

[Dracosha Andrew]

VKot, тогда всё сложнее. Вам нужен ассоциативно-словарный поиск. Это значительно более дорогая работа. Не по сложности алгоритма, а по сложности составления словарей. Тут потолок практически е ограничен. Я, к сожалению, не знаю серийной программы, которая осуществляла бы такую функцию.

[da4nik]

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

Кстати вместо внутренних кодов можно использовать Штрихкоды EAN13 или аналогичные, что намного универсальнее.