totalmx
-
Публикации
7 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем totalmx
-
-
Уважаемый Yoda, текст от моего имени в этой и по этой теме - желание понять как решить проблему и правильно сформулировать ТЗ. А дилетантство - это если бы я стал программировать и лепить "костыли" в код готовых модулей, а также Ваши рассуждения об артикулах и индивидуальных задачах ). Давайте дружить ) польза будет взаимной )
Сравнение с "пентюхом" некорректно, так как я пытаюсь понять, чтобы правильно сформулировать правильное ТЗ исходя из правильных возможностей ОС, которые могут мне объяснить только программисты.
Про Magento я в курсе, поэтому так широко применение ОС. Бюджеты ) Так что, давайте сравнения в одной весовой категории.
Магазинов торгующих экипировкой много, принцип учета товаров и подача на сайте требуется везде одна. Так что, уже не индивидуальная. Все они натыкаются на один ответ - это долго, дорого и незачем потому как есть уже опции пользуйтесь ими. Занавес ) И это объяснимо в свете того, что сделать большой проект интереснее и прибыль больше, чем маленький модуль ) - это правильно, по рыночному.
Решений для реализации ОЧЕНЬ мало (и как писал выше) и все написаны как вспомогайки для себя или видимо являлись составляющими ИНДИВИДУАЛЬНЫХ проектов и потом выложены на продажу. И это очень хорошо, потому мы как заказчики сразу видим что возможно сделать и куда двигаться с нашими "хотелками" ).
-
Спасибо RHCk, за понимание!
За созданную тему не в том месте, мои извинения!
По поводу холивара ) - это полезная для программистов информация, кто не в теме по продаже одежды и обуви или имеет "свое представление" и ошибочно считает его верным. Не надо "Спасиба", я просто хочу поделиться насущным. Еще хочу призвать программистов внимательнее слушать продавцов и вникать в их запросы. Ведь это продаваны в конечном итоге являются конечными потребителями ваших продуктов и крайне важно, то бы вы, программисты, создавали решения для наших торговых задач. Чем внимательнее вы вникаете в наши запросы, тем лучше и точнее вы сможете предложить решение. А если вы сможете эффективно решать нашу боль, то мы, продавцы, захотим ваше решение купить.
Вообще хотел было закончить разговор, но прочитав решил внести немного ясности с учетом, что участники сталкивались с продажей одежды. К сожалению, очевидные вещи не связались в единую картину. По этому как не программист, а продавец, хочу уточнить:
1. Название данного обсуждение все же "Требования...", а не хотелки ). Разница принципиальна. Продажей одежды мы занимаемся давно, есть опыт и сложившиеся требования, произошедшие из опыта. По этому мы сейчас и меняем связку используемого софта, ищем устраивающие нас по функционалу решения, т.к. используемый сейчас софт нас не устраивает. И в этом контексте "Требования" - это общие и необходимые условия для работы магазина.
2. Насчет "уложиться в 5К"... Могу согласиться, но два модуля есть на просторах которые почти могут ), сделаны, как я думаю, с умом и с мелкими недоработками ввиду неглубокого знакомства с предметом. Вот тут - да. Доработки этих модулей или слияние в один в 5К могут не уложиться (а опросы о необходимости тех или иных модулей перед началом разработки я не встречал).
3. И еще раз по поводу Артикула (SKU). Действительно, артикул может отражать только часть свойств изделия. Как правило это относится к недорогим изделиям, которые поставляются комплектами (в упаковке 10 серых в пяти типах размеров, каждого по 2 шт.) все по одной цене. Но подавляющее большинство фирмовой одежды имеет индивидуальные расцветки, серии и т.д. и всегда имеет сложный артикул отражающий все характеристики товара и однозначно идентифицирующий его. У нас в ассортименте весь товар имеет такие артикулы от производителя, это не мы придумали.
4. Цвет и Размер - являются неотъемлемой частью одежды как товара. Остальные варианты деления всегда можно вынести как отдельные группы. По какому-то странному стечению обстоятельств или, скорее всего, из расчета на товары с усеченными характеристиками в ОС цвет и размер являются опциями привязанными к одному артикулу. В том время как в любой программе учета как раз наоборот. Что подтверждается Вами, уважаемый Yoda и RHCk, и вашим опытом работы в организациях торгующих одеждой. Поэтому вдвойне непонятно яростное противостояние нашим требованиям ))))
По поводу бюджета на такой модуль пока не было ответа. Я скинул примеры и даже описывал как удобнее реализовать. Так что описание, права и будущие прибыля пока даже не обсуждались. Просто многим элементарно непонятно "Зачем", если в стандарте ОС этого нет.
-
Изучите вопрос, прежде чем писать о ненормальном артикуле ) а как он будет называться SKU, Артикул, Код товара, ID Products, Part Numders. Дело формулировок )
Что касается бюджетов ) так по отдельности модули в том или ином виде есть и цена у них очень разумная. Так почему не связать все одном месте?
И вы невнимательно читали текст. Данные модули не работают с каждым товаром как с опцией, а используют стандартные методы обработки опции системы.
Про трезвость - это не про инвестиции, а про грамотный подход к конечному продукту, А так получается - бери что есть, не нравится пили сам. Такой подход программистов к своим творениям мне известен. И отношусь я к нему спокойно. Всегда найдется жемчужина ) надо немного терпения. Оно у меня есть.
Про инвестиции - весь набор модулей для этого сейчас можно набрать на сумму до 5000р. Но все они от разных авторов. И тут гордость программиста уступает разумному торгашескому принципу ) объединиться придумать лучше и продать чуть дешевле в сумму, но больше в количестве. Вот так.
И уровень нормальных шаблонов из коробки уже сейчас очень даже достижим ))))
Я Вас понял и вопросы отпали ) предлагаю закончить эту бесплодную для сторон дискуссию )))
Вот вам пример брэндовых SKU (Part Numders), чтобы Вы просто были в курсе )))http://www.revzilla.com/motorcycle/fly-racing-patrol-jersey#skus_tab
и еще
-
Здорово Други! У меня вопрос, когда делают шаблоны и рекламируют его для продажи одежды, кто-нибудь хоть вникал в схему учета и продажи таких вещей? Смотрел ли образцы мировых гигантов. Ну так, чтобы быть в курсе как это работает. Собственно теперь о проблемах и поисках:
Стандартные варианты ОС и всех его ипостасей не могут продавать и вести одежду и обуви как надо. ПОТОМУ ЧТО:
- Не может определять опцию как отдельный артикул товара. Поясняю: майка может иметь серию расцветки, внутри расцветки есть отдельные цветовые решения (основной цвет), и тут же присутствуют размеры. Пример НОРМАЛЬНОГО АРТИКУЛА ТОВАРА где содержатся все данные о товаре: 13245-132-3XL. Все поля Артикула, которые появляются в закладке "Опции" имеют статус информационных и не участвуют в поиске на сайте, не могут быть простыми способами синхронизированы с программами учета. Т.е. В карточке товара мы реальный артикул товара увидеть теоретически можем, вот с поиском и учетом проблема. Частично проблема решается модулем "Группировка товаров по цвету". Так почему нельзя сразу включить в шаблоны?
- Большие надежды всегда на комплекты товаров для одежды. Существующие модули так же никак особо не помогают, требуют доработок и танцев. )
Хочется пообщаться с теми кто ориентируется на продавцов одежды, экипировки. Нас много, средние цены на шаблоны устраивают, даже если докупать модули или заплатить за них в составе шаблона. Но таких нет, а проверять совместимость разных модулей покупая у разных авторов процесс долгий и не всегда удачный.
Прикладываю ссылки на хорошие рабочие образцы по которым (некоторые с доработками) можно сделать хорошие шаблоны с хорошим дизайном, который сильно отличается от повторяемого почти во всех шаблонах для ОС.
Я привожу примеры с точки зрения схемы выбора и конечной обработки заказов, варианты сортировки (поиска). Такие нюансы как работает корзина, расположение меню, вопрос вкуса и желания. Но и для них есть приработанные удобные варианты.
В торговле одеждой и экипировкой всегда присутствуют большие объемы номенклатуру и без учета не обойтись. Используемые сервисы, как правило не понимают опции внутри товара как отдельные артикулы. А также в силу особенностей работы бухгалтерии и систем складского учета не способные их связать (проверено на 1С, Мой Склад, ИнфоПредприятие, думаю у других тоже самое). Да и с точки зрения учета и продаж связывать их не совсем правильно. Поэтому все такие сайты самописные.
Помогите нам, сделайте шаблон с такими возможностями. Подумайте о синхронизации с 1С (кстати есть шикарный модуль для этого, реально работающий в две стороны) и с другими программами учета. Почему их нет, это отдельный вопрос. Если интересно поделюсь результатами общения с бухгалтерскими и складскими сервисами.
Поверьте отдача - будет
https://www.btosports.com/p/fox-racing-180-race-combo
https://www.24mx.com/motocross-gear/motocross-clothing/motocross-kits
https://www.foxracing.com/store/browse/Moto-Mens-Gear-Sets/_/N-1jftbb8
https://www.foxracing.com/store/outfit/FLEXAIR-SECA/_/A-outfit-1000046
-
9 часов назад, savage4pro сказал:
попробуйте связаться с автором линейки модулей "Grouped Product"
http://fabiom7.com/website/oc_gp/index.php?route=product/product&product_id=59
Спасибо. Попробуем такой вариант. )
-
День добрый! Как реализовать такой функционал.
Надо в одной карточке товара связать две номеклатуры, которые имеют опции: цвет и размер. Они должны быть связанны с количество номенклатур на складе.
Это как образец: https://www.btosports.com/p/troy-lee-designs-se-gravity-gear-combo
Хотелки для магазинов одежды (артикулы и т.д.)
в Курилка
Опубликовано:
Уважаемый RHCk )
Озвученное здесь предложение о написании модуля и разделе на него прав мне интересно. Спасибо за это.
К сожалению на данном этапе решение просматривается только на стороне сайта. В связи с тем, что типы данных в 1С (других программ) несколько отличаются от требуемых для сайта. К слову модулей и дополнений для сервисов учета (бухгалтерия) имеющих двустороннюю синхронизацию с ОС практически нет. А если есть, то поддержка слабая. Проверялось для сервисов "Мой Склад", "1С", "Инфо-Предприятие". Так вариаций ОС много, официальной поддержки модулей и кода никто не дает, то никто особо не берется. У кого есть пишут сами, но не все удобно. Остается много ручной работы. А для интернет-магазина важнее продвижение, туда все усилия. А на учет и размещение товара на витрине хочется уделять усилия меньше и как можно менее квалифицированного персонала.
Нашли только одну разработку для 1С. Куча нюансов и ограничений из-за архитектуры 1С и ОС. Поэтому решили пойти по пути работы с номенклатурой на сайте. Тут-то программистам надеемся проще будет решить эти задачи, чем в 1С. Подозреваю, что наши крупные дилеры даже не знают о нем (((( слабая реклама. А уж в 1С вообще сказали, что это невозможно.
Для этого Вам нужно быть гением в 1С и знать хорошо товарный учет в нескольких областях, чтобы модуль был более-менее универсальный. Хотя те требования, которые мы тут обсуждаем, надеюсь покрывают практически все потребности учета в любой отрасли. Подробнее описать товар уже некуда ). Про особенности 1С и связки с ОС писал выше.
Если интересно, могу обсудить отдельно, поделюсь результатами поиска.
Мне нравится это дискуссия, которая приобретает направление к решению. Вы программисты, мы продавцы давайте - дружить и понимать друг друга ) а результат взаимопонимания - удовольствие от взаимовыгодного обмена денег на работу )