- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
неужели не очевидно ?
конечно нет... коробка - это желание продать... Надеюсь Вы не будите отрицать, что очень много продается такого, что мало кто хочет покупать... так-же много скриптов, которые связывают массовые магазины с 1с, инфобугалтором и подобными...
PS я лишь сказал, что кроме поиска "в лоб" решения задачи, можно на нее взглянуть и с другой стороны. Каждое из ершний имеет свои плюсы и рассчитано на свою аудиторию...
всегда есть вопрос - накой х..?
то что что-то можно сделать, совсем не значит что делать это стит...
пример:
магазин в котором больше половины товаров могут иметь остатки 1-2 штуки (и при этом товар имеет цвет - например 1 желтый товар, 1 зеленый товар)
Даже есть делать выгрузку данных из внутренней учетной системы раз в одну минуту - то все равно можно получить коллизии.
Поэтому разумно весть "оперативный" учет остатков в магазине. И проверку-подтверждение заказов - тоже в магазине.
А обновлять данные об остатках только по команде оператора (когда не висит необработанных заказов)
Пример - реальный.
T.R.O.N, а бесплатный oscommerce? даже от стандартного набора у новичков глаза разъезжаются.
vrom, При частоте заказов, при которой 1 минута играет роль, коллизия возможна даже в момент, пока покупатель заполняет свои данные (или нет =) ) или пока заказ обрабатывается опреатором. При такой требовании к актуализации данных, используется система транзакций (как при покупке авиа/жд билетов), независио от того, где находится основная база
T.R.O.N добавил 24.05.2010 в 14:37
netwind, ну если даже джумла нашла своих почитателей, то и остальное тоже... Каждый выбирает себе любовь сам (если большой брат не подсказывает)
vrom, При частоте заказов, при которой 1 минута играет роль, коллизия возможна даже в момент, пока покупатель заполняет свои данные (или нет =) ) или пока заказ обрабатывается опреатором. При такой требовании к актуализации данных, используется система транзакций (как при покупке авиа/жд билетов), независио от того, где находится основная база
это понятно все... но вот реальный клиент, который продает реальные товары, которые в количестве 1-2 штук. И если он ставит такой товар на главную, чтобы продать - то он с большой вероятность получает коллизию. А вот если оперативный учет товаров в магазине есть - то вероятность проблемы снижается в разы.
А вот если оперативный учет товаров в магазине есть - то вероятность проблемы снижается в разы
эти две вещи никак не связаны. коллизия разруливается простым способом временных блокировок (еще раз скажу, независимо от расположения учетной базы). А вот учет вести на удаленном сервере, по меньшей мере, очень необдуманное решение.
но вот реальный клиент, который продает реальные товары, которые в количестве 1-2 штук. И если он ставит такой товар на главную, чтобы продать - то он с очень большой вероятность получает коллиизию.
вот Вы вдумайтесь в суть... чел ставит на главную товар, которого у него осталось 2 шт, при этом ожидает что за минуту появится более 2-х желающих... =))) что-то не очень клеится...
PS Нравится Вам выбранное Вами-же решение - чудесно. Просто описываемые Вами решения, решают задачу... как и наоборот. всегда приходится использовать компромисс.
Amiro.CMS поддерживает.
Пример: http://www.ltb.ru/katalog/products/m...tjum-rossija-2
учета остатков по каждому цвету-размеру наверняка нет
Есть дополнительные поля. Их можно использовать для остатка. А осуществлять их учет и списание можно внешней частью, как описывает T.R.O.N
эти две вещи никак не связаны. коллизия разруливается простым способом временных блокировок (еще раз скажу, независимо от расположения учетной базы). А вот учет вести на удаленном сервере, по меньшей мере, очень необдуманное решение.
вот Вы вдумайтесь в суть... чел ставит на главную товар, которого у него осталось 2 шт, при этом ожидает что за минуту появится более 2-х желающих... =))) что-то не очень клеится...
Все нормально клеится. К тому же заказчик хочет, чтоб оператор делал предварительную обработку заказов (прозвон, подтверждение) в интерфейсе магазина, а не в 1с. А стало быть надо считать реальные остатки в магазине.. иначе никак.
заказчик хочет, чтоб оператор делал предварительную обработку заказов (прозвон, подтверждение) в интерфейсе магазина
дык если так, то и вопроса нету. Что хочет, то пускай и получает. Он, как говорят, всегда прав =)
дык если так, то и вопроса нету. Что хочет, то пускай и получает. Он, как говорят, всегда прав =)
Ага, но грамотный специалист нужен чтобы сообщить стоимость и трудоемкость всех разумных вариантов.
После этого заказчик, иной раз, меняет мнение и адаптирует свои бизнес-процессы.