Есть склад ~20 000 наименований (автозапчасти)

Склад ведется уже 5-й год в однажды сформированном файле в Excell (когда оборот еще был малюсеньким а ассортимента - мало).

структура файла склада:
на закладке "Имя бренда"
1 столбец: код запчпсти. (обычно ищут по этому коду)
 иногда следующий столбец содержит альтернативный код
2 столбец: применимость (если код не знают, ищут по автомобилю)
3 столбец: цена
4 столбец: (если амортизатор к примеру, то перед/зад
5 столбец: (если амортизатор к примеру, то левый правый
 [здесь становится понятно что единой структуры для каждого бренда/вида запчастей сделать нельзя - потому что даже амортизаторы могут левый/правый, передний/задний быть разными и одинаковыми и т.п. а про колодки и говорить не стоит и т.п. А видов запчастей там более 50, и везде свои особенности]
6 столбец: цена опт (или вход)
7 столбец: количество


Сейчас этих файлов уже 4. Они лежат на отдельном компьютере в сети в расшаренной папке
В сети на сегодня 15 машин, Windows XP SP2 (целероны 1800-2200 и 2 стареньких целерона 1100. Сам "сервер" - на Win2000 workstation SP4/ Сеть 100MBit свитч D-link 1024D (24 порта) сетевые встроенные intel, внешние rtl8139)

Есть еще точки. Там аналогичная структура прайсов. но совместно естественно они не ведутся. Т.е. в конце рабочего дня по электронной почте продавцы с точек присылают список проданного (чтобы на утро подвезли). Это делается ручками...


Как происходит продажа:
Приходит человек, называет машину или вин-код. У продавца открыты все файлы в Экселе (в торг.зале 5 компьютеров, 5 продавцов). Естественно только для чтения, т.к. Утром эти файлы уже открыл на весь день один из менеджеров.
Он
1) в электронном каталоге ищет по вин-коду номер запчасти
2) Ищет этот номер в фалйле-складе.xls или по автомобилю, если это проще.
3) смотрит количество на складе. Если например нету одного бренда, смотрит ту же запчать другого бренда, третьего и т.п.
4) смотрит цены, сообщает их клиенту и тот выбирает. (очевидно что все не выставишь не витрине)
5) Покупатель оплачивает в кассе товар, продавец идет на склад и приносит запчасть(сти). После этого нужно отметить в складе что количество уменьшилось. Продавец вынужден идти до менеджера (в менеджерскую комнату) и просить его отметить продажу.
   Либо на листочке записывается что и сколько продано, а один из менеджеров вечером правит склад.

както не правильно, правда?


При всем при этом 1С-торговля и склад 7.7 была куплена 4 года назад (1-пользовательская версия), через год купили 3-х пользовательскую сетевую, а в прошлом году - ее сменили на сетевую без ограничения пользователей.
Затем посадили девушку, которая вбила за 2 недели всю номенклатуру в склад.
уже 2 года бухгалтерия пользуется 1С:Предприниматель, причем довольно успешно. а на шкафу зачем то еще лежит 1С:Бухгалтерия (я так понял она не нужна, если есть 1С:Предприниматель)

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

Вот.

Прошлая попытка перейти на 1С:ТиС не увенчалась успехом  - при открытии базы номенклатуры приходилось ждать 10 минут. Когда исключил .dbf и другие типы вайлов в Kaspersky Monitor - время сократилось до 5 минут. Но каждая операция все равно занимала уйму времени.
Просто открыть закладку с нужным брендом в Экселе и пролистать (либо ctrl+"f" и ввести номер запчасти) - занимает намного меньше времени, чем лезть в базу 1С, даже локальную, которая занимает ~60 мегабайт.
Насколько я понимаю, 1С при первом запуске копирует все 60МБ на по сети к себе на компьютер в кэш и потом работает с ним локально, но после каждой покупке происходит сохранение - это тоже очень долго (по сравнению с Excell).

Надо еще сказать что я сам не занимался никогда 1С. Приглашали программиста со стороны. он настраивал, и обьяснял.

Но сейчас , я думаю надо простроить оптимальную модель движения данных, а уже потом правильно настраивать конфигурацию. Потому и пытаюсь испросить у вас совета.




Итак. как я себе представляю то, что мне нужно:

Есть база данных, она большая и лежит на отдельном мощном компьютере в сети (думаю для этой цели щас выделить P4-1600/Asus i865 2x512MB/80GB SATA, понимаю что многие посоветуют скази, но бюжет не тот, и этот то компьютер уже есть. А пока базы 1С лежат на компьютере глав.буха).

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

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

И вот тут я не могу понять - зачем пересылать по 60МБ данных и устраивать такие тормоза (а с увеличением количества продавцов и их компьютеров - только возрастет нагрузка), когда можно пользовать чтото типа SQL запросов, в случае если мне нужно просто у 3-х только что проданных запчастей изменить их количество на складе (это ~10 символов) !?!??
Или еще тупее - зачем она переносит ВСЮ базу целиком, когда я ищу 1 амортизатор с таким-то номером - почему ельзя чтобы это сделал специальный процесс - там на сервере, и мне он чтобы прислаа не 60МБ, а ~50 байт - строчку с наименованием и количеством !?!??

1С-Программист, в которым я советовался обьяснил так, что в SQL-версия 1С тоже не лучше, ибо она работате примерно так же, и использует по своему закрытые способы взаимодействия с SQL-ядром СУБД MS SQL, и он вручную настроить оптимальнее ничего не сможет - в итоге будут теже тормоза (просто иногда побыстрее) но только уже на 1000$ дороже.
И что даже если оставить только ядро 1С, а к нему будут обращаться интерфейсы, оно - однозадачное - т.е. когда один продавец займет ядро на 3 минуты другой его будет эти 3 минуты ЖДАТЬ. (блииин. слов нету. и за ЭТО мы заплптили 960$ !?!?!)

Сразу скажу что абстрагироваться вообще от 1С (посредством отдельной программы-интерфейса для звпросов) предпочтительнее чем ставить TerminalServer (хотелось бы всетаки лицензионное, а пока впечатление от 1С крайне негативное, отдавать еще килобакс чтобы подстраиваться под нее - не вижу повода). И кроме того я считаю КРАЙНЕ неправильным принцип - впихивать "КОСТЫЛЬ", - считаю что нужно "выправлять ногу" - т.е. правильно построить принцип организации и потока данных.


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


Думаю что эта программа-интерфейс должна позволять продавцу следующие вещи:

1) упрощенное представление ВСЕГО прайса (номер запчасти, применимость, количество, цена - тоесть полностью заменять уже существующую систему складов на Excell. [я так понял что это более трафико-времене-емкий вариант, чем следующий]

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

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


3) очень хочется избавить продавцов в филиалах от ручного вбивания продаж - пусть 1С (или программа-клиент) те склады сама (по интернету,  sql- или xml/csv файлами) синхронизирует склады и формирует заказ на восстановление в филиале проданных за день запчастей.

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

5) Отчеты для оптовых менеджеров:  вот пришол заказ оптовому менеджеру на 1000 амортизаторов. это скорее всего либо просто текстовый список номеров, либо .xls-файл с теми же номерами.
Что делает менеджер сейчас? - он каждый номер должен найти в складе, посмотреть количество, недостающее найти у поставщиков (это конечно он сам, но циферки количеств должна уже сформировать 1С - чтобы ему руками не вбивать) и т.п. - колоссальная рутинная работа.
Думаю нужно сделать возможность точно такого ж екомплексного поиска по базе, с выводом отчета о найденных/отсутствующих запчастях за один запрос скопом. 

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

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


8) И наконец главное - Корпоративный сайт:
Для оптовых клиентов на сайте регистрируются учетные записи. Каждому такому клиенту доступы цены его уровня (т.е. Дядя Вася имеет вход +n% потому что уже год лоялен и берет по много наименований большого количества запчастей, а Дядя Коля имеет вход + y% потому что берет только первую партию небольшого количества). [Несколько групп опта (разные уровни)]

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

Кроме того НА САЙТЕ клиент должен иметь историю сделок, для своего удобства. Менеджер тоже должен иметь доступ к истории сделок с каждым клиентом. Все эти данные должны быть экспортированны из 1С автоматически, и наоборот - если заказ формируется через сайт - он должен импортироваться в 1C с сайта и приходить менеджеру (либо складываться в отдельную базу заказов), формируя тем самым историю заказов. По истории заказов можно вести поиск, упорядочивать по времени, контрагенту и т.п.
Важно чтобы это все было возможно как локально (через программу-интерфейс) так и через сайт - удаленный менеджмент так сказать - что позволит Менеджеру оперировать движением токава даже в командировке.

На сайте также должен присутствовать онлайн-прайс (розничному клиенту он удобнее) - где можно оперировать корзиной. и в результате так-же формировать заказ и история корзины - практически аналогична истории оптового клиента. Этот онлайн-прайс тоже должен формироваться сам (ну или менеджер для этого должен нажать только 1 кнопочку).


насколько я понял WEB-расширение для интеграции сайта и 1С мне не подходит (сайт на freeBSD 4.7 + Apach 1.3 + MySQL 4.1.16+ cms на php (на основе drupal)/
Видимо здесь придется пользоваться файлами с разделителсми (csv) или xml... не знаю что лучше.

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

Вот что я надумал... :-)

Что можете посоветовать?
 

Посмотри технологию NauRP 

посмотри:
http://naumen.ru/go/products/naudoc
http://download.naumen.ru/naudoc/trial/Nau...ree-200docs.exe