Торговля "с колес" или дропшиппинг — это бизнес-модель, при которой компания не хранит товар на собственном складе, а закупает его у поставщика только под конкретный заказ клиента. В 1С:Управление торговлей 11 (УТ 11) этот механизм реализован через систему обеспечения потребностей, однако типовой функционал часто кажется менеджерам неудобным из-за отсутствия оперативной информации о наличии товара у поставщика непосредственно в момент оформления продажи. Рассмотрим подробно, как настроить эту схему и какие существуют способы её улучшения.
Разберем базовый сценарий, заложенный разработчиками 1С. Для того чтобы система понимала связь между заказом покупателя и заказом поставщику, используется функционал Обособленного обеспечения. Проанализируем, как это работает пошагово:
Обеспечивать обособленно. Это создает в системе жесткую связь ("резерв под назначение").ЗаказПоставщику в колонке Назначение автоматически проставляется ссылка на конкретный ЗаказКлиента.ПриобретениеТоваровУслуг, он сразу попадает в резерв под клиента. Другой менеджер не сможет продать этот товар "свободно".Рассмотрим важный нюанс, упомянутый опытными специалистами: существует две вариации связи. В первом случае менеджер делает заказ поставщику без указания клиента, и тогда привязку резерва нужно делать вручную после поступления. Во втором случае в заказе поставщику сразу указывается заказ покупателя — это автоматизирует всю цепочку, но ограничивает гибкость при перераспределении товара между клиентами.
Для эффективной работы менеджер по продажам должен знать не только "что" хочет клиент, но и "у кого" из поставщиков это есть и по какой цене. Выясним, какие объекты 1С помогают хранить эти данные:
Номенклатура поставщика: Это справочник, в котором хранятся артикулы и наименования товаров в том виде, в котором их предоставляет контрагент. Это критически важно, так как ваши внутренние наименования могут отличаться. Объекты типа Справочник.НоменклатураПоставщиков позволяют сопоставить ваш товар с позициями десятков разных прайс-листов.
Регистрация цен поставщика: Документ РегистрацияЦенПоставщика позволяет фиксировать стоимость закупки. Однако здесь кроется проблема, которую мы назовем "зависанием" цен. Если в новом прайсе поставщика позиция исчезла (выбыла), типовой механизм 1С (срез последних) все равно будет показывать последнюю известную цену. Для решения этой проблемы рекомендуется создавать "нулевые" регистрации или программно помечать цены как неактуальные, если они отсутствуют в свежем файле загрузки.
Самый сложный вопрос: как увидеть остатки поставщика в окне подбора товара? В типовой УТ 11 остатки поставщиков не хранятся в регистрах накопления остатков на складах. Проанализируем три подхода к решению этой задачи:
Суть метода заключается в создании в базе "Виртуального поставщика" как организации. Под него создается склад, на который программно (например, через документ ИнвентаризацияТоваров или ОприходованиеИзлишков) ежедневно загружаются остатки из прайс-листа.
Плюсы: Менеджер видит остатки в типовом подборе в колонке "В наличии" по соответствующему складу. Минусы: Это "раздувает" базу и требует ежедневной очистки старых виртуальных остатков перед загрузкой новых, чтобы не продать "воздух".
Более изящный способ — хранить данные прайс-листов в отдельном регистре сведений или использовать типовой механизм Планов остатков. Посмотрим на примерную логику хранения данных:
// Пример структуры данных для хранения остатков прайса
СтруктураЗаписи = Новый Структура;
СтруктураЗаписи.Вставить("Номенклатура", СсылкаНаТовар);
СтруктураЗаписи.Вставить("Поставщик", СсылкаНаПартнера);
СтруктураЗаписи.Вставить("Цена", ЦенаИзПрайса);
СтруктураЗаписи.Вставить("Остаток", КоличествоИзПрайса);
СтруктураЗаписи.Вставить("ДатаАктуальности", ТекущаяДата());
Чтобы эти данные увидел менеджер, необходимо модифицировать форму подбора товаров. Рассмотрим внедрение расширения, которое добавляет в динамический список подбора колонку "Остаток поставщика", получаемую левым соединением из вашего нового регистра.
Современные версии УТ 11 поддерживают сервис 1С:Бизнес-сеть. Если ваши поставщики работают в этом сервисе, вы можете видеть их предложения (цены и наличие) прямо в документе заказа. Если же поставщик предоставляет API, мы можем реализовать динамический запрос данных:
Разберем ситуацию, когда менеджер ошибся в заказе под заказ. В типовой системе цепочка документов "Заказ клиента — Заказ поставщику — Поступление" является жесткой. Если нужно изменить номенклатуру задним числом, придется перепроводить всю цепочку. Чтобы облегчить работу, рекомендуем обратить внимание на документ КорректировкаНазначений. Он позволяет программно или вручную перебросить зарезервированный под один заказ товар на другой, не нарушая складской учет.
Подводя итог, можно сказать, что УТ 11 обладает всеми необходимыми структурами данных (номенклатура поставщиков, типы обеспечения, регистры цен), но для удобной работы менеджеров-продажников ("перепродаванов") требуется надстройка в виде удобного АРМ (автоматизированного рабочего места). Такое рабочее место должно объединять данные из справочника Номенклатура и оперативные данные из загруженных прайс-листов, позволяя в один клик формировать потребность именно под того поставщика, чьи условия на текущий момент наиболее выгодны.