Сделать поле "Количество на складе" множественным!

Рейтинг: 59.1050  
Внедрено
Предложил Роман Забродин 19.10.2011 15:05:54

Сделать поле "Количество на складе" множественным!

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

Рейтинг: 14.7743  
Малышин Иван 20.10.2011 23:46:00
Задача отображения остатков по складам и правда есть, но нужно что-то более чем просто множественное свойство. Т.е склад имеет описание, название, и внятную интеграцию с 1С.

Думаю можно по аналогии с ценами
Рейтинг: 0.3513  
Konstantin Obuhov 26.10.2011 20:05:31
+1. Несколько складов - уже давно реальность.
Рейтинг: 0  
Krikunov Slava 15.11.2011 14:50:44
Согласен, такое желание у каждого второго клиента возникает
Рейтинг: 0  
r3c130n 23.12.2011 10:04:10
Обязательно должно быть "из коробки", не понятно почему всё еще нет такого (негодую)
Рейтинг: 0  
Рябинков Артем 12.01.2012 18:51:23
Роман, а что значит фраза "А так же уменьшались при покупке и 1С узнавала об этом." Как вы себе это видите?

Я зашел в интернет-магазин, выбрал, заказал. С какого склада уменьшать количество? И зачем 1С это узнавать, если заказ поступает в 1С, там уже по нему делают отгрузку и количество уменьшается именно там.
Рейтинг: 0.6355  
Роман Забродин 13.01.2012 08:04:23
Роман, а что значит фраза "А так же уменьшались при покупке и 1С узнавала об этом." Как вы себе это видите?
Артём, мы работу со складами сейчас и сами успешно реализуем следующим образом:

1. Заводим каждому складу в 1С отдельное свойство типа число.

2. Эти свойства выгружаются на сайт.

3. При покупке товара с определенного склада количество товара на нем уменьшается и идет синхронизация с этими свойствами в 1С.

Далее, например, у нас есть 4 склада в городах:
Красноярск
Сосновоборск
Канск
Москва

на каждом из этих складов есть какое-то кличество товара и доставка товара с кажого склада до города покупателя занимает определенное время. Допустим Товар А имеется на складах в следующих количествах:

Красноярск 9
Сосновоборск 0
Канск 0
Москва 10

Допустим посетитель проживающий в Красноярске ложит в корзину 10 штук Товара А.
Тогда, мы даем ему оформить заказ, а на последнем шаге даём ему выбрать удобную для него схему получения заказа (учитывая город проживания указанный посетителем в местоположении профиля покупателя, некоторые из которых связаны с местоположением складов магазина):



После оформления заказа он либо идет одним заказом либо раздваивается. По каждому приходит почтовое уведомление покупателю, каждый отображается в списке заказов личного кабинета итд

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

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

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


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

Рейтинг: 0.3868  
Рябинков Артем 07.02.2012 11:53:31
Роман, вы много написали про свои реализации, все здорово и вы молодцы. Но на мой вопрос вы не ответили. Вопрос не простой, я не зря его задал :)

Я зашел в интернет-магазин, выбрал, заказал. С какого склада уменьшать количество?
Количество товара должно уменьшиться на соответствующем складе причем это количество на сайте и в 1С должно оперативно синхронизироваться чтобы не получилась ситуация когда человек купил товар, которого уже нет, но информация обновиться не успела.
Как то у вас все размыто написано. Что такое "количество должно синхронизироваться"?, если вы хорошо смотрели как работает обмен данными с сайтом и интеграция, то все очень запутанно получается и нескладно.

В большинстве случаев склад нужен только если мы делаем самовывоз и сами туда поедем. Если вы заказываете с доставкой, вам все равно откуда они его повезут, хоть из Африки, лишь бы уложились в срок доставки.

Есть еще вариант, когда сам выбираешь точку самовывоза, куда твой товар доставляют с одного или нескольких больших складов (например, www.citilink.ru). Но это немного другая тема.

Итак. Я решил сделать заказ на сайте и за товаров поехать сам забрать его.

У меня есть товар, 2 склада. На первом ближнем 1 штука, на другом 5. Мне нужен 1 товар, я выбрал первый склад при покупке, оформил заказ. На нем сразу количество уменьшилось и стало равным нулю.

В ближайшем обмене 1С с сайтом, она получает этот заказ. Менеджер уже в 1С смотрит данные заказа и видит, что хотел я его забрать именно с этого склада. И при отгрузке документа САМ ПОВТОРНО выбирает склад. Хорошо, если все хорошо и этот товар есть и исправен. Тогда они его отгрузили, я забрал.

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

Я все это к чему написал. что ОКОНЧАТЕЛЬНЫЙ ВЫБОР СКЛАДА ВСЕ РАВНО ПРОИЗВОДИТСЯ В 1С - ТАМ ГДЕ С ЭТИМИ СКЛАДАМИ РЕАЛЬНО ВЕДЕТСЯ РАБОТА. Сайт может запаздывать по отображению информации, клиент может передумывать. Поэтому НЕТ НИКАКОЙ ВОЗМОЖНОСТИ с достаточной вероятностью знать, что клиент заберет товар именно с того склада, который он выбрал на сайте.

Теперь добавим сюда ситуацию, когда магазинов несколько с одних складов торгуют (а такой вариант совсем не редкий). Тогда станет все еще сложнее.

Поэтому наш вывод пока такой. На сайт информацию о наличии по складам выгружать и актуализировать на сайте надо, это востребованно, и будет сделано в ближайшем будущем. Но НИКАКИМ образом эта информация и склады на сайте не влияют на бизнес-процесс заказа.
Рейтинг: 0  
Роман Забродин 07.02.2012 12:59:43
В большинстве случаев склад нужен только если мы делаем самовывоз и сами туда поедем. Если вы заказываете с доставкой, вам все равно откуда они его повезут, хоть из Африки, лишь бы уложились в срок доставки.
На самом деле разница для покупателя ОГРОМНАЯ:
1. Если склады расположены в разных городах — срок доставки может сильно отличаться (1 день vs 1 неделя.)
2. Может отличаться цена, когда и-м (классический посредник) торгует со складов разных поставщиков, у которых разные цены на один и тот же товар.
В ближайшем обмене 1С с сайтом, она получает этот заказ. Менеджер уже в 1С смотрит данные заказа и видит, что хотел я его забрать именно с этого склада. И при отгрузке документа САМ ПОВТОРНО выбирает склад. Хорошо, если все хорошо и этот товар есть и исправен. Тогда они его отгрузили, я забрал.
Есть ли в 1С возможность автоматизировать процесс выбора склада (на основе данных в заказе)?
Но представьте ситуацию, что товар в единственном числе на ближнем складе и выставочный образец. Менеджер созванивается с клиентом и объясняет это ему. Клиент отказывается брать, тогда менеджер говорит мы сами привезем вам с другого склада на этот, заберете тогда через день. Тогда менеджер делает перевод со склада на склад. На сайт выгружается уже новое количество на обоих складах и перетирает то, что клиенты там на сайте поизменяли своими заказами.
Надо окончательно изменять количество на складах, когда товар оплачен и доставлен. В промежуточном состоянии необходимо как-то помечать что товар на соответсвующем складе забронирован.
На сайт информацию о наличии по складам выгружать и актуализировать на сайте надо, это востребованно, и будет сделано в ближайшем будущем. Но НИКАКИМ образом эта информация и склады на сайте не влияют на бизнес-процесс заказа.
А я думаю, что ничего невозможного нет, нужно просто как следует подумать и задачу можно полностью автоматизировать. Автопилоты программируют, не то что автоматическое уменьшение количества товара на кладе :-)
Рейтинг: 0  
Роман Забродин 16.08.2013 07:34:18
Кому интересно, по мотивам этого обсуждения у нас родилось собственное типовое решение..
Рейтинг: 0  
Роман Забродин 30.01.2014 19:30:48
Ура!
На #bitrixconf обещают развитие идеи.
Рейтинг: 0  
Роман Забродин 25.04.2014 18:05:09
- Мой любимый пример: допустим, мы торгуем ручками, система знает, что у нас их на складе сейчас 30 штук. Этой информации недостаточно для того, чтобы контакт-центр сказал клиенту: «Есть в наличии, покупайте». Почему, спросите вы, например, из них 27 уже могут быть зарезервированы под заказы, а 3 быть бракованными, т.е. все 30 сразу недоступны. Но и сказать «нет, не покупайте», тоже может быть ошибкой. Правильно организованная система может знать, что запланирована входящая поставка еще 500 этих ручек сегодня вечером, а звонок поступает из Екатеринбурга, поэтому если мы скажем «Нет», мы зря потеряем заказ, а сказав «Да», мы не удлиним им доставку ни на секунду, но получим заказ. Таких случаев у нас несколько десятков. Количество нюансов может быть огромно.


Еще один пример - разбор возвратов. Все говорят, что в e-commerce разбор возвратов очень важен, но очень сложен. Например, отгрузили 5000 заказов, из них 500 – одинаковые (они уехали в разные места, но в них лежат одинаковые вещи): ручка, кружка, ложка. Из этих 500 заказов 50 вернулось, из 50 вернувшихся 25 при обратной логистике были так помяты и разорваны, что маркировка заказа оказалась нарушена, и номер заказа не считывается. Но нам надо как-то быстро, без расследования определить, каким 25 людям из 500 нужно вернуть деньги?  Для этого нужно иметь возможность, достать товар (кружку, например) и просканировав, понять, в каком заказе она лежала, а для этого надо трэкить каждую кружку, для этого при поступлении мы должны знать, что к нам поступила кружка не просто белая, неразличимая, а со своим уникальным номером. И тогда система скажет, что кружка с таким-то идентификатором была положена в заказ с таким то номером, ее заказал, а потом вернул Михаил Иванович из Самары, на его расчетный счет мы переводим деньги. Если этот процесс  не автоматизировать, появляются отделы из большого количества людей, которые реально начинают ходить и выяснять, кому же деньги нужно вернуть.
http://prograbli.ru/experience/everada-we-want-our-clients-to-grow-quickly/

Классные сценарии! :)