forum.clarionlife.net

Как организовать проект для оптовика.
Есть склад. Клиент заказывает товар на месте или через интернет чтобы сэкономить время, (секретарь будет принимат заказ через телефон) .
вот так примерно : Как лучше организовать базу данных?(стационарная база, интернет база...)
Какими инструментами пользоваться?
Какие технологии использовать чтобы с экономить время?

Чем торгует?
У меня для хозяйственных товаров навороченная учетная система, включающая электронные заказы через сайт, настольное приложение, мобильное приложение (андроид).
Сайт (точнее, интернет приложение) на php, обмен через программу робота, база sqlite. Оповещения о поступлении заказов приходят сразу в учетную систему, заказы загружаются нажатием кнопки. Учетная система может работать и на закрытом сервере без прямого доступа в интернет. Параллельно операторы могут принимать заказы по телефону, работая в учетной системе.
В месяц около 300 магазинов пользуются. В сезон за день может приходить более 100 заказов (включая дозаказы). Заказы обычно несколько десятков позиций.
Учетная система на кларионе, база tps. Для многопользовательского доступа используется терминальный сервер.

На django писал для свой конторы. Правда, так и не внедрили- большой песец наступил... .
Есть куча готовых магазинов https://www.google.com/search?q=%D0%B4% ... D&ie=UTF-8 и курсов на Youtube, как писать. Например,
https://www.youtube.com/channel/UCkBGH1 ... zPpdV493sQ, а знакомство с Python/Django никогда лишним не будет. Ну и при необходимости книгами поделюсь.

ibrohim78 писал(а): 22 Июнь 2017, 3:33 Как организовать проект для оптовика.

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

Если новый проект, берёте SQL сервер (какой именно - вопрос обсуждаемый), организуете хороший железный сервак. В качестве интернет-модуля - H5.
А ресурсы для проекта есть? Мы тут годами развиваем что-то в этом роде. А вы что хотите?

Если новый проект, берёте SQL сервер (какой именно - вопрос обсуждаемый), организуете хороший железный сервак. В качестве интернет-модуля - H5.

Согласен полностью

А ресурсы для проекта есть?

Если есть, то WinServer+SQLserver+TS+фиксир.IP для роутера.+проброс порта на лок. сервер
Для локальных и удаленных юзеров TS+ClarionApp, для остальных редирект с Вашего сайта на H5-модуль
Главное, имхо, вопрос приема платежей

Как лучше организовать базу данных?(стационарная база

Однозначно (имхо)

Какими инструментами пользоваться?

SQL. Т.к. к нему можно прикрутить любой Frontend (кроме 1С)

Какие технологии использовать чтобы с экономить время?

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

Реализация возможно разная, зависит от предметной области. Основная проблема, которая возникает при эксплуатации таких систем в том, что часто встречается непонимание, что система приема электронных заказов в опте сильно отличается от обычного интернет магазина. То есть она совсем другая, другой контингент пользователей, другие бизнес-процессы. Чтобы понять, как построить такую систему, надо достаточно долго повариться в конкретной оптовке и осмыслить происходящие там процессы. Огромное количество нюансов, без реализации которых система будет "сайтом-визитницей", а не рабочим инструментом. И, разумеется, никто не рассказывает все эти нюансы, эта информация дорогого стоит...

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

finsoftrz писал(а): 22 Июнь 2017, 13:06 Основная проблема, которая возникает при эксплуатации таких систем в том, что часто встречается непонимание, что система приема электронных заказов в опте сильно отличается от обычного интернет магазина.

Естественно. Но это же не значит, что не надо делать онлайн-заказ?

finsoftrz писал(а): 22 Июнь 2017, 13:34 И еще. Коллеги тут предлагают прямой коннект к локальной базе данных. Надо много раз подумать, так как такое решение создает дополнительные точки отказа...

Можно через прокладку. Но это тоже дополнительные точки отказа. Привожу пример Ulmart'а. Я вижу остаток данного товара на экране. Но когда пытаюсь забронировать, то такого количества уже нет. Плохо? Плохо! В чём выигрыш? Сервер периодически (раз в полчаса) сбрасывает информацию в xml-виде для удобства интернет-площадки. Напрягается. Возможно даже другой сервер. И т.д. Может полный онлайн и лучше. Особенно для оптовиков.

Вот все так и рассуждают - я попробовал купить что-то в интернет магазине...

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

Под точкой отказа имеются ввиду ситуации, когда при возникновение проблемы в одно месте приводит к парализации работы всех пользователей. Если используете свой локальный сервер и возникли проблемы с ним или с каналом интернет у вашего офиса, то работать не смогут все покупатели. Если пользователи работают с базой данных на хостинге, то эти проблемы на их работу не влияют. Если данные храните в sql сервере на хостинге, то проблемы с этим сервером приведут к останову работы всех. Если у каждого покупателя свой файловый буфер для заказов, то этой проблемы нет. Основная точка отказа остается в том месте, где хостится наша система заказов. За 5 лет работы несколько раз возникали такие ситуации, они сопровождались шквалом звонков от пользователей. Но организации, которые предоставляют услуги хостинга, занимаются этим профессионально. У них хорошее оборудование, системы резервных каналов доступа и т.п. При этом я всегда держу в голове и фатальную ситуацию, когда все на хостинге накроется и не помогут резервные копии. Система заказов должна быстро и в автоматизированном режиме быть реанимирована из учетной системы...

Часть магазинов работают через настольную систему электронных заказов. Я особо ее пока не рекламирую, хотя она с ряда точек зрения более удобна, чем заказы в вебе. Это обычное кларионовское приложение. Вот там точек отказа, можно сказать, нет совсем...

опт от розницы отличается
1. инфой по остаткам товаров по всем филиалам (суммарно)
2. организацией одноразового создания документа (заказа, прих и отпуск. накладной), который в дальнейшем только изменяется или вообще удаляется. В общем идет по кругу пока не придет к месту "назначения".
3. неважностью для клиентов наличие остатков товара, касается инет магазинов, так как заказ(спрос) формирует заказ для поставщиков
4. скоростью обработки данных минимальными силами и минимизация возможности внести ошибки, например раздача с поступившей накладной товаров по торг. точкам за один проход (с учетом остатков на т.точках и пр.), создает 10 накладных для 10 филиалов и т.п.
5. разделение прав при перемещении товаров между торг. точек, например кто отправляет товар тот имеет право вносить изменения в накладные, принимаемая сторона только может принять(подтвердить) накладную
6 и много чего такого... лениво писать
Кстати это все работает вне зависимости есть интернет или нет