Хотелки для магазинов одежды (артикулы и т.д.)

[totalmx]

Здорово Други! У меня вопрос, когда делают шаблоны и рекламируют его для продажи одежды, кто-нибудь хоть вникал в схему учета и продажи таких вещей? Смотрел ли образцы мировых гигантов. Ну так, чтобы быть в курсе как это работает. Собственно теперь о проблемах и поисках:

 

Стандартные варианты ОС и всех его ипостасей не могут продавать и вести одежду и обуви как надо. ПОТОМУ ЧТО:

1. Не может определять опцию как отдельный артикул товара. Поясняю: майка может иметь серию расцветки, внутри расцветки есть отдельные цветовые решения (основной цвет), и тут же присутствуют размеры. Пример НОРМАЛЬНОГО АРТИКУЛА ТОВАРА где содержатся все данные о товаре: 13245-132-3XL. Все поля Артикула, которые появляются в закладке "Опции" имеют статус информационных и не участвуют в поиске на сайте, не могут быть простыми способами синхронизированы с программами учета. Т.е. В карточке товара мы реальный артикул товара увидеть теоретически можем, вот с поиском и учетом проблема. Частично проблема решается модулем "Группировка товаров по цвету". Так почему нельзя сразу включить в шаблоны?
2. Большие надежды всегда на комплекты товаров для одежды. Существующие модули так же никак особо не помогают, требуют доработок и танцев. )

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

 

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

 

Я привожу примеры с точки зрения схемы выбора и конечной обработки заказов, варианты сортировки (поиска). Такие нюансы как работает корзина, расположение меню, вопрос вкуса и желания. Но и для них есть приработанные удобные варианты.

 

В торговле одеждой и экипировкой всегда присутствуют большие объемы номенклатуру и без учета не обойтись. Используемые сервисы, как правило не понимают опции внутри товара как отдельные артикулы. А также в силу особенностей работы бухгалтерии и систем складского учета не способные их связать (проверено на 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

[totalmx]

Изучите вопрос, прежде чем писать о ненормальном артикуле ) а как он будет называться SKU, Артикул, Код товара, ID Products, Part Numders. Дело формулировок )

Что касается бюджетов ) так по отдельности модули в том или ином виде есть и цена у них очень разумная. Так почему не связать все одном месте?

И вы невнимательно читали текст. Данные модули не работают с каждым товаром как с опцией, а используют стандартные методы обработки опции системы.

 

Про трезвость - это не про инвестиции, а про грамотный подход к конечному продукту, А так получается - бери что есть, не нравится пили сам. Такой подход программистов к своим творениям мне известен. И отношусь я к нему спокойно. Всегда найдется жемчужина ) надо немного терпения. Оно у меня есть.

 

Про инвестиции - весь набор модулей для этого сейчас можно набрать на сумму до 5000р. Но все они от разных авторов. И тут гордость программиста уступает разумному торгашескому принципу ) объединиться придумать лучше и продать чуть дешевле в сумму, но больше в количестве. Вот так.

 

И уровень нормальных шаблонов из коробки уже сейчас очень даже достижим ))))

 

Я Вас понял и вопросы отпали ) предлагаю закончить эту бесплодную для сторон дискуссию )))

Вот вам пример брэндовых SKU (Part Numders), чтобы Вы просто были в курсе )))

http://www.revzilla.com/motorcycle/fly-racing-patrol-jersey#skus_tab

 

и еще

[RHCk]

54 минуты назад, totalmx сказал:

Здорово Други!

И вам не хворать.

Просьба создавать отдельные темы для обсуждений, не засоряя темы поддержки модулей и шаблонов.

 

По вашему вопросу. Проблема актуальна, каждый решает её в меру своих возможностей.

То, что вы хотите сделать в 5К не уложить.

 

Решение - закажите себе необходимую реализацию, обговорите с автором кому будут принадлежать права на код - Профит!

У вас есть ИМ, и вы продаете модуль, который необходим продавцам одежды.

[RHCk]

8 минут назад, Yoda сказал:

Иму говорят что Артикул это SKU, а размер дополнительное свойство товара.

Думаю, он имел в виду, что в SKU или (артикуле, суть в данном случае не в терминологии), есть информация о нескольких характеристиках товара.

И если для однотипного товара сделать одну карточку, то и SKU будет один, а не для каждого варианта сочетания характеристик.

 

Тут "два путя" (с), делать под все варианты отдельные товары, либо собирать их модулем в один с опциями (но этот вариант видимо автору не совсем удобен).

 

8 минут назад, Yoda сказал:

Кароче холиварщик

Немного флуда:)

Насколько может отличаться цена на модуль, если права на него останутся у автора или перейдут к заказчику?

[RHCk]

7 минут назад, Yoda сказал:

у каждой единицы цвет/размер свой sku всегда

Зависит от производителя. Я работал с белорусской фабрикой Conte.

Большая часть изделий имела SKU, по которыму можно было однозначно идентифицировать изделие.

У остальных по SKU определялась только модель, цвет и размер туда не входили.

Удобство работы во многом зависит от производителя.

 

13 минуты назад, Yoda сказал:

Тут вот у меня какие мысли.

Спасибо.

[totalmx]

Спасибо RHCk, за понимание!

За созданную тему не в том месте, мои извинения!

 

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

 

Вообще хотел было закончить разговор, но прочитав решил внести немного ясности с учетом, что участники сталкивались с продажей одежды. К сожалению, очевидные вещи не связались в единую картину. По этому как не программист, а продавец, хочу уточнить:

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

2. Насчет "уложиться в 5К"... Могу согласиться, но два модуля есть на просторах которые почти могут ), сделаны, как я думаю, с умом и с мелкими недоработками ввиду неглубокого знакомства с предметом. Вот тут - да. Доработки этих модулей или слияние в один в 5К могут не уложиться (а опросы о необходимости тех или иных модулей перед началом разработки я не встречал).

3. И еще раз по поводу Артикула (SKU). Действительно, артикул может отражать только часть свойств изделия. Как правило это относится к недорогим изделиям, которые поставляются комплектами (в упаковке 10 серых в пяти типах размеров, каждого по 2 шт.) все по одной цене. Но подавляющее большинство фирмовой одежды имеет индивидуальные расцветки, серии и т.д. и всегда имеет сложный артикул отражающий все характеристики товара и однозначно идентифицирующий его. У нас в ассортименте весь товар имеет такие артикулы от производителя, это не мы придумали.

4. Цвет и Размер - являются неотъемлемой частью одежды как товара. Остальные варианты деления всегда можно вынести как отдельные группы. По какому-то странному стечению обстоятельств или, скорее всего, из расчета на товары с усеченными характеристиками в ОС цвет и размер являются опциями привязанными к одному артикулу. В том время как в любой программе учета как раз наоборот. Что подтверждается Вами, уважаемый Yoda и RHCk, и вашим опытом работы в организациях торгующих одеждой. Поэтому вдвойне непонятно яростное противостояние нашим требованиям )))) 

 

По поводу бюджета на такой модуль пока не было ответа. Я скинул примеры и даже описывал как удобнее реализовать. Так что описание, права и будущие прибыля пока даже не обсуждались. Просто многим элементарно непонятно "Зачем", если в стандарте ОС этого нет.

[RHCk]

38 минут назад, totalmx сказал:

Спасибо RHCk, за понимание!

Пожалуйста.

38 минут назад, totalmx сказал:

два модуля есть на просторах которые почти могут

Они почти могут полностью решить задачу взаимодействия с программой товароучёта или только касательно сайта?

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

38 минут назад, totalmx сказал:

непонятно яростное противостояние нашим требованиям

Противостояния требованиям нет.

Есть ответное требование огласить бюджет мероприятия, чтобы было понятно о чём идёт речь.

Доступные варианты разработки описаны выше.

В противном случае данная тема не более чем хотелки:)

38 минут назад, totalmx сказал:

Просто многим элементарно непонятно "Зачем"

Набросайте ТЗ, прикиньте бюджет, создайте тему в разделе Стол заказов.

На форуме есть разработчики, которые смогут реализовать вашу задачу качественно.

[totalmx]

Уважаемый Yoda, текст от моего имени в этой и по этой теме - желание понять как решить проблему и правильно сформулировать ТЗ. А дилетантство - это если бы я стал программировать и лепить "костыли" в код готовых модулей, а также Ваши рассуждения об артикулах и индивидуальных задачах ). Давайте дружить ) польза будет взаимной )

 

Сравнение с "пентюхом" некорректно, так как я пытаюсь понять, чтобы правильно сформулировать правильное ТЗ исходя из правильных возможностей ОС, которые могут мне объяснить только программисты.

 

Про Magento я в курсе, поэтому так широко применение ОС. Бюджеты ) Так что, давайте сравнения в одной весовой категории.

 

Магазинов торгующих экипировкой много, принцип учета товаров и подача на сайте требуется везде одна. Так что, уже не индивидуальная. Все они натыкаются на один ответ - это долго, дорого и незачем потому как есть уже опции пользуйтесь ими. Занавес ) И это объяснимо в свете того, что сделать большой проект интереснее и прибыль больше, чем маленький модуль ) - это правильно, по рыночному.

 

Решений для реализации ОЧЕНЬ мало (и как писал выше) и все написаны как вспомогайки для себя или видимо являлись составляющими ИНДИВИДУАЛЬНЫХ проектов и потом выложены на продажу. И это очень хорошо, потому мы как заказчики сразу видим что возможно сделать и куда двигаться с нашими "хотелками" ).

 

[totalmx]

Уважаемый RHCk )

 

Озвученное здесь предложение о написании модуля и разделе на него прав мне интересно. Спасибо за это.

Цитата

Они почти могут полностью решить задачу взаимодействия с программой товароучёта или только касательно сайта?

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

 

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

 

Цитата

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

Для этого Вам нужно быть гением в 1С и знать хорошо товарный учет в нескольких областях, чтобы модуль был более-менее универсальный. Хотя те требования, которые мы тут обсуждаем, надеюсь покрывают практически все потребности учета в любой отрасли. Подробнее описать товар уже некуда ). Про особенности 1С и связки с ОС писал выше.

 

Если интересно, могу обсудить отдельно, поделюсь результатами поиска.

 

Мне нравится это дискуссия, которая приобретает направление к решению. Вы программисты, мы продавцы давайте - дружить и понимать друг друга ) а результат взаимопонимания - удовольствие от взаимовыгодного обмена денег на работу )

[RHCk]

49 минут назад, totalmx сказал:

Давайте дружить ) польза будет взаимной )

Так уже б давно отписали в личку ТЗ и начинали работать. В личку комраду @Yoda.

27 минут назад, totalmx сказал:

Нашли только одну разработку для 1С

Что касается 1С, поговорите с @19th19th, наверняка найдёте общий язык.

Организовывать работу на стороне сайта удобнее только для удобства доступа.

Во всех других случаях товароучёт проще сделать в 1С, и написать именно под себя двухсторонний обмен.

Этим занимался комрад @spown при поддержке @savage4pro. Тоже есть смысл обсудить.

 

P.S. Скорее всего это будет дорого, но это будет работать. И будет возможность договориться о поддержке.

За сим попытки переубеждения друг друга предлагаю оставить и перейти к конструктивному диалогу.

Цените время друг друга:)

[Blade]

прошу прощения что подредактировал

нет, с модулем обмена знаком хорошо, но до писать точно не доходило)

а так без вопросов, пишите

 

[Nameless]

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

[twicers]

На самом деле автор сумбурно, но адекватную вещь пишет - я также лоб разбил пытаясь понять адский известный модуль "обновление/парсинг остатков и всего на свете". У нас товар который имеет связанные опции. Цвет+размер. Чтобы это чудо обновлять пришлось допилить свой артикул на каждую такую опцию.

 

Вот теперь ищу варианты быстрого обновления по yml всего этого.

[Blade]

я уже запутался кто что хочет))

есть миллион решений под все что можно

и связанные опции те же

что вы все хотите сделать ?