- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Вообще любой коммерческий проект сделанный "чтоб работал" а не "чтоб денег освоить"....
а что за проект, где меньше ?
100к$ - это образно человекогод. Это немного совсем.
Если говорить о "движке" пригодном для 90% применений, даже
с базовым функционалом, то это мало яб сказал.
Речь не о ТЗ, речь о SRS :).
работать он будет, но за его поддержку надо будут платить много, и многие с закрытым исходным кодом, где вы не сможете ничего сделать. Кроме того специально так сделано чтобы вы больше платили за поддержку
я думаю, если вы будите поддерживать свой проект и РАЗВИВАТЬ бизнес, то сумма 100к$ будет на все 5-15лет оправдана
от куда сумма 100к$? есть сомнения
что такое SRS? знакомое слово, это тип инфраструктуры интернет коммерции?
.
Ок, если я не прав, покажи, плз, проблемы невозможности создания универсального экспорта. (тут "универсального" - в см. подходящего для большинства ИМ).
Основные "грабли" связаны с группировкой товара, его свойствами, артикулами.
Для кого-то "платье с пуговицами 1" и "платье с пуговицами 2" - это просто одно
и тоже платье и два набора пуговиц, которые пришьют при покупке, причем хорошо-бы
это всё представить для 1С, как набор из платья и пуговиц, пуговиц как-бы тоже
ограниченное количество.
А для других "синее платье" и "красное платье" - это два абсолютно разных
уже упакованных платья, которые никто допиливать не будет.
Итд итп.
Универсального "готового" тут не сделать, но набор функций можно было-бы,
с качественно описанной документацией. Пока "не наблюдаю".
---------- Добавлено 28.07.2014 в 12:44 ----------
работать он будет, но за его поддержку надо будут платить много, и многие с закрытым исходным кодом, где вы не сможете ничего сделать. Кроме того специально так сделано чтобы вы больше платили за поддержку
Я не приобретаю продукты с закрытым исходным кодом. Вообще.
Кроме тех редких случаев, когда no exit.
я думаю, если вы будите поддерживать свой проект и РАЗВИВАТЬ бизнес, то сумма 100к$ будет на все 5-15лет оправдана
100к надо потратить прямо сейчас :), SRS пишут до начала работы над продуктом.
После потраченных 100к у меня будет только документ в ворде :)
от куда сумма 100к$? есть сомнения
Один человекогод... сомнения остались ?
что такое SRS? знакомое слово, это тип инфраструктуры интернет коммерции?
http://en.wikipedia.org/wiki/Software_Requirements_Specification
Возможно, мой практический опыт работы с ИМ не такой большой, как твой. И я даже кодер никакой. Но! Есть товар и есть его характеристики. Несмотря на всё многообразие товаров их характеристик для подавляющего большинства ИМ ну 10-к, ну 20, не больше. Да пускай даже 100 или 1000 хар-к - проблем нет их экспортировать. В моём практическом опыте - разбор ХМЛ вполне тривиальная задача.
Ок, если я не прав, покажи, плз, проблемы невозможности создания универсального экспорта. (тут "универсального" - в см. подходящего для большинства ИМ).
Вы правильно рассуждаете как продавец, но проблема с импортом в том, что дело приходится иметь с информацией, а не с товаром. И проблема часто не в том, что в разных магазинах информация по-разному организована, но и исходная информация тоже по-разному организована, и процесс преобразования данных из исходного состояния в конечное как правило существенно сложнее чем простой разбор XML файла (особенно если вспомнить, что это XML не всегда есть).
Примеров море. Например в Opencart атрибуты организованы так, что в них записывается влияние цены стартовую цену товара, а значить с заливкой атрибута нужно строить не самый простой вариант расчета этой дельты. И это хорошо, если такой атрибут один (разницу посчитать проще, а если несколько влияют на цену, то дельты придется считать вручную до заливки). В мадженто эта дельта строится динамически а в базу заливается именно товар со значениями атрибутов но нужно во входном файле задавать группировку товаров в настраиваемые. В Преста из атрибутов строятся комбинации, либо с конечной ценой, либо с дельтой. Но самое главное, что входная информация может быть виде прайс-листа в формате PDF. Вот и попробуйте сделать универсальное решение. :-)
А вообще все просто, вы попробуйте сами разработать этот универсальный импорт и все станет ясно :-). Я попробовал и мне все ясно :-).
Но самое главное, что входная информация может быть виде прайс-листа в формате PDF. Вот и попробуйте сделать универсальное решение. :-)
это надуманная проблема, если владелец магазина не может предоставить данные в xml формате - ему магазин на фиг не нужен!
лучше бы они на завод пошли, толку было бы больше - ни одного инструмента для создания нормального сайта не существует, тупо отсутствует в природе как класс!!
Ну с этим не поспоришь :-D.
Основные "грабли" связаны с группировкой товара, его свойствами, артикулами.
Для кого-то "платье с пуговицами 1" и "платье с пуговицами 2" - это просто одно
и тоже платье и два набора пуговиц, которые пришьют при покупке, причем хорошо-бы
это всё представить для 1С, как набор из платья и пуговиц, пуговиц как-бы тоже
ограниченное количество.
А для других "синее платье" и "красное платье" - это два абсолютно разных
уже упакованных платья, которые никто допиливать не буде
Думаю, что понимаю о чём ты. Но это НЕ проблема экспорта. Это проблема ПОДГОТОВКИ данных для экспорта.
Проблема группировки по артикулу (когда разные хар-ки (напр. цвета) будут под одним или под разным артикулом) - как бэ проблема, но опять же решается грамотной подготовкой данных.
И потом - осуществить слияние\группировку при экспорте - проблем нет. Но для этого, конечно, нужна не домохозяйка, а грамотный менеджер, не забивающий на настройку параметров импорта. (ну или хотя бы подготовивший эти настройки).
Как-то так, я думаю.
это надуманная проблема, если владелец магазина не может предоставить данные в xml формате - ему магазин на фиг не нужен!
Это практика. Причем повсеместная.
Основные "грабли" связаны с группировкой товара, его свойствами, артикулами.
Для кого-то "платье с пуговицами 1" и "платье с пуговицами 2" - это просто одно
и тоже платье и два набора пуговиц, которые пришьют при покупке, причем хорошо-бы
это всё представить для 1С, как набор из платья и пуговиц, пуговиц как-бы тоже
ограниченное количество.
это достаточно легко решается в настройках экспорта - банальное соответствие полей и структуры магазина :)
а вот что касается 1с, это отдельная тема - их давно пора номинировать на нобелевскую премию по экономике, "за развод клиентов"
Думаю, что понимаю о чём ты. Но это НЕ проблема экспорта. Это проблема ПОДГОТОВКИ данных для экспорта.
Ну да, если все данные будут подготовлены в формате SQL запроса для заливки в БД, то проблема действительно не в импорте, а в подготовке :-D.
это достаточно легко решается в настройках экспорта - банальное соответствие полей и структуры магазина :)
Интересно как вы собираетесь достичь соответствия.
Вы эээ... предлагаете вместе с подключением оффлайн-бизнесу магазина заставить его
переделать у себя ВСЁ, что было до того сделано ?
Или всё-таки придется магазин допиливать ?
Тут на мой взгляд почти неразрешимая коллизия.
Но это не должно мешать нормально работать всему остальному :), что работает НЕ нормально.
Почему... ... .... ... в некоторых магазинах догадались сделать "из коробки" "обязательный к указанию атрибут",
а в других нет. Это что ... ... ....... ..... никому ненужная хрень :) ?
Да без этого половина лифчиков будет дефолтного размера доставлена и возвёрнута обратно...