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

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

Вопрос какие существуют средства и методы для автоматизации подобного процесса? Интересует именно процесс ручного заказа, а не методы автоматического пополнения товарного запаса.

LSVДолжна быть доступна инфа:
* Данный товар бывает на РЦ (распред. центр) ? Обычно это небольшая часть ассортимента.

Кол-во товара, который когда-либо был на РЦ (то есть хотя бы раз попал в заявку) ~75000
Кол-во товара, который имеется на РЦ в данный момент ~17000
LSV* Каков актуальный остаток хотя бы на прошлые сутки ?

Кол-во позиций товара в торговой точке 8-15 тыс (зависит от параметров торговой точки)
LSVПосле формирования и отправки заказа полезно получить подтверждение, что из товаров "принято в работу", а что нет.

Это понятно, меня сейчас интересует только процесс формирование заявки
LSVзы: какого типа товар ? От этого зависит методика.

Товар фармацевтического ассортимента

Андрей Ж.Затем, в условно ручном режиме вносим требуемое количество по позициям. Список можно фильтровать по куче условий, запоминать его, печатать заказ, выводить на различные устройства.

Желательно дополнить режимами:
1. Пометить цветом позиции, рекомендованные программой к заказу по неким критериям, например "малый остаток", но есть "продажи". У меня делается через фильтр.
2. Рекомендовать (заполнять поле заказа) в соответствии с неким критерием.



Примерно так и сделано, но пользователи хотят видеть ВЕСЬ справочник, мотивируя это тем, что они могут что-нибудь забыть.

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

Короче, по-моему, дело здесь не в информационной системе, а в пользователях, которые никак не могут отвыкнуть от Excel и печатных прайсов.

LSVВопрос был про остатки на ЦС .
Показывать только с ненулевыми остатками.


Для ЦС я тоже написал ~17000. А как они смогут заказать товар, остаток у которого =0? Склад содержит далеко не все позиции, которые заказывают точки. Заказ с ЦС - это частный случай, большинство товаров точки заказывают из справочника номенклатуры и поставщик привозит товар, минуя ЦС.

LSVзы: если им нравится, то зачем переделывать ? :)

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

alex.aprmМожно попробовать динамически подгружать список по мере прокрутки вниз. Грузить только то что на экране, как это делает, например, гугл, при просмотре картинок в результатах поиска.

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

Можно еще сделать постраничный вывод, как это делают в веб, памяти на клиенте отнимать меньше будет. Только мне кажется листать огромные списки все это от Excel, прошлый век.

С этого места по подробнее, пожалуйста.
alex.aprmНадо получить из БД общее количество
Количество чего, записей?
alex.aprmзаполнить список (чтобы скроллбару крышу не сносило)
Что значит заполнить список?
alex.aprmа по мере их появления на экране -- подгружать данные.
Куда подгружать?

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

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

LSVЗачем точка пытается сделать сразу весь заказ по всем товарам в один клик ?

Потому что так привыкли и утверждают, что этот способ самый быстрый и точный. Объективных причин нет.

LSVКто принимает решение, где заказывать, на ЦС или у поставщика ?


Определенная группа товаров заказывается у поставщика, остальное с ЦС. Такова специфика отрасли.

LSVКакой вы хотите услышать совет, если не можете толком сформулировать проблему ?

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

Я хотел услышать что-то типа этого:
LSVВыводите в список:
* только товары, для кот. запас требует пополнения. Хотя тут сразу всплывает вопрос аналогов. :(
* Имейте в локальной базе по возможности свежие остатки ЦС.
* формируйте отдельные выборки : "заказ для ЦС", "прямые заказы для поставщиков".
* следите за актуальными статусами номенклатуры. Не выводите товар, кот. уже нельзя заказать ввиду "устаревания". Просите поставщиков ставить вас в известность о товарах ставших неактуальными.
* разбивайте/сортируйте товар на макрогруппы. Так проще вести учет что заказано, а что нет.
* попробуйте понять тактику мышления заказывающего. Возможно появятся подсказки для решений.


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

Спасибо

alex.aprmДа, записей. select count(*) from ... или как-то так.
сделать фальшивые записи с пустыми полями, чтобы только количество отражало суть.


А у пользователя от этого крышу не снесет?

alex.aprmПопробуйте, всё-таки, заказчика убедить сделать запросную систему.

В общем давайте не будем про технические аспекты реализации. Запросная система более перспективное направление.

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

Кто сказал, что постановку менять нельзя? Как раз, в данном случае, и стоит вопрос как поменять постановку задачи. Клиент не говорит: "нужно вот так". Клиент говорит: "Мне пофиг как, главное чтобы было быстро и удобно". Вот я и думаю какие могут быть варианты: выводить весь список - удобно, но не быстро, запрос-ответ - быстро, но неудобно. Что еще мне подсказали выше, буду копать в этом направлении.

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


А как вы им объяснили, что новый способ лучше, добровольно-принудительно?

Пользователь получит по голове, если клиент спросит товар, а его нет, потому что он забыл его заказать. Поэтому пользователь готов просматривать огромные списки, лишь бы ничего не забыть.
При возможности поиска система никак не поможет пользователю ничего не забыть. Да, список это плохо, но убрав его, мы создаем пользователю проблему, а по идее должны помочь ему эту проблему решить. Иначе вход пойдет блокнот/Excel

stiЕсли уж говорить о нас, то сейчас формирование заказа может делаться нажатием одной кнопки. В таком варианте "забыть заказать" как-то проблематично.

Процедура заказа делается не в один этап. Примерно для 80% заказываемого товара заявка формируется автоматически на основе прогноза продаж. Но эта часть покрывает примерно 20% номенклатурного справочника. Остальные 20% товара нужно выбрать из 80% справочника. Здесь полностью автоматически никак, только вручную с применением вспомогательных средств - поиск, различные группировки, вспомогательные расчетные величины и т.п. Пока еще не знаю как это будет выглядеть окончательно, но думаю задача решаемая

Petro123Нужно по гриду-таблице выбирать платформу, а не модному слову.

Платформу выбирают исходя из ее стоимости и стоимости разработчиков, а иногда просто их наличия, на рынке труда.

Petro123вот и вышло, что твоя Net дороже чем студент с Delphi

К сожалению, перевелись в наших краях студенты с Delphi, на Net все перешли. Приходится выбирать из того, что есть

Petro123m13,
опаздываете, c Net тоже все ушли

Далеко не все, пока еще реально найти, по крайне мере в наших краях. А куда у вас с Net все ушли?

Petro123- десктоп обратно в Delphi :)


Ничего себе, Delphi снова жив? Я уже несколько лет проектов на Delphi не видел. У нас с Delphi пока все глухо

LSVОн и не умирал. Постоянный спрос есть. Для десктопов - самое оно. Надежная и простая технология.
Жаба и .НЕТ рулят из-за обилия оффшоров, где Делфи почти нет.

А если судить по ЗП, то лучшие ЯП это ABAP/Cobol(SAP) и 1C. Ога... :)

Delphi для десктопов лучший вариант, не спорю, но что-то в последнее время специалистов по Delphi становится все меньше. К тому же Delphi 2006 - жутко тормозная IDE, написанная на .net, с закосом под visual studio. Delphi 2010 не знаю, не видел.

Petro123Delphi 7 - работает для Висты и Win7.
В D8 - 2010 нету ничго нового.

Согласен, но только где его, Delphi7, взять. Где его продают? По-моему нигде.

А в более новых версиях не только ничего нового нет, но и добавлены тормоза/косяки

GerrosЧто мешает держать номенклатуру локально на клиентском компьютере, а перед началом оформления заказа синхронизировать её с номенклатурой центральной базы?
В этом случае по сети будет передаваться только полный перечень Первичных Ключей и атрибуты новых единиц номенклатуры.

С синхронизацией с ЦС проблем нет. На сервере в торговой точке лежит актуальный справочник, синхронизируется примерно так как вы сказали.

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

Самая большая проблема в том, что пользователь не может объяснить что ему нужно. Эту проблему и предстоит решить