gifts2017

Дропшиппинг или "виртуальные" склады поставщиков в 1С

Опубликовал Денис Аграновский (de0nis) в раздел Управление - Техническое задание

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

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

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

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

Собственно схема автоматизации Дропшиппинга в 1С:

  1. Заводим фиктивную организацию ООО «Виртуальные склады» (далее ВС), ну или как нравится. :) без отражения в регламентированном учете. 
  2. Под каждого поставщика заводим свой виртуальный склад в справочнике склады. (В целом склад может быть один, но по нескольким складам удобнее будет смотреть у какого поставщика есть товар). В первом случае это будет видно по остаткам на складах – склад = поставщик. Во втором по движению партий, т.е. надо будет анализировать от какого поставщика было оформлено поступление.
    •  
  3. Остатки по этим складам будут типовыми средствами 1С, в зависимости от настроек, попадать в отчеты о наличии товаров, прайс-листы, выгружаться на сайты.
  4. Делаем фиктивное поступление от поставщика на организацию ВС на соответствующий склад. Можно использовать документ оприходование товаров вместо поступления. Для упрощения работы с большими объёмами информации загружаем его из Excel типовыми средствами или доработанной обработкой. Если мы хотим вести статистику по себестоимости и наценкам, то желательно делать поступление в закупочных ценах поставщика. Заводим на основании поступления отгрузочные цены (цены продажи) в базу документами Установка или Изменение цен.
  5. Дальше получая новые остатки и цены от поставщика, удаляем старое поступление и делаем новое. (или перезаполняем старое), что б скорректировать остаток по складу дропшиппинга на текущие остатки поставщика. 
    • Если для загрузки используем созданную под нашу задачу обработку, то можно доработать ее так, что б она вместо поступления формировала списание и оприходование товаров, корректируя текущий остаток на складе с учетом прошлого остатка. Т.е. на пример, был остаток на складе 5 шт. в обновленном файле пришло - 3 – списываем две, был 4, в обновленном файле нет - списываем 4 и т.д. Тогда не надо будет контролировать и удалять предыдущие поступления.
    • Удалять предыдущие поступления необходимо, что б получить актуальные остатки, т.к. мы не видим оборота по складу поставщика, то поступление должно формироваться на "пустой склад", т.к. по сути это не поступление, а текущие остатки поставщика.
  6. Получаем заказ от покупателя. В заказе могут быть как товары со склада, так и по дропшиппингу, на товары со склада делаем реализацию как обычно. По товарам по дропшиппингу, зависит от схемы работы:
    1. Если это виртуальный склад поставщика (товар под заказ), то на основании заказа покупателя делаем заказ поставщику, в большинстве конфигураций при правильных настройках, должны попасть только те товары, которых нет на складе. Оформляем поступление товара от поставщика на основную организацию и его последующую отгрузку клиенту. При этом заказ покупателя "закроется" после отгрузки товара. 
      • По организации ВС остатки на складе поставщика в данном случае можно не корректировать, они будут скорректированы при последующем обновлении остатков.
  7. Если это именно Дропшиппинг, т.е. поставщик сам отгружает товар клиенту, а нам просто перечисляет вознаграждение, то два варианта:
    1. Простой. Когда заказ будет передан поставщику, заказ покупателя по основной организации на позиции по дропшиппингу надо закрыть корректировкой заказа покупателя, отгрузку заводить не нужно, т.к. отгружает сам поставщик, а не наша организация. В этом случае теряем статистику по продажам товаров поставщика и положенному нам вознаграждению, искажаем статистику отказов по заказам.
      • Можно удалять товары под заказ из заказа или разбивать заказ покупателя на два заказа, на основную организацию - товары со склада и на ВС – товары по дропшиппингу. Заказ на ВС по факту отгрузки поставщиком закрываем корректировкой. Тогда мы не будем искажать статистику по отказам по основной организации + если поставщик предоставляет информацию о факте отгрузки товара покупателю, то сможем дополнительно контролировать поставщика и какие отгрузки закрыты.
    2. Более сложный. Для учета статистики по продажам можно сделать отгрузку этого товара от организации ВС, зафиксировать товарный состав, количество и цену продажи. Себестоимость товара должна быть заведена при поступлении на склад. Если мы используем модель с одним поступлением, то необходимо будет сделать поступление этого товара, т.к. иначе после удаления основного поступления у нас пойдут отрицательные остатки. Если схему с регулярной корректировкой остатков, то ничего делать не надо будет, остатки откорректируются с учетом нашей отгрузки.
      • В этом варианте мы сможем в отчетах о продажах посмотреть статику продаж по товарам поставщика, себестоимость и наценку (с отбором по организации ВС).
      • По задолженности поставщиков перед ВС можно контролировать сколько нам должны вознаграждения. Закрывать эту задолженность можно или Приходным кассовым ордером или выпиской банка по факту оплаты поставщиком. Если вознаграждение перечисляется на счет основной организации, то его надо будет продублировать на ВС.
      • Отгрузку делать по факту информирования поставщиком об отгрузке, это позволит контролировать не закрытые заказы.
  8. Оплаты о покупателя и поставщику по основной организации в случае виртуального склада проводятся по факту как обычно. В случае дропшиппинга 
    • Если покупатель оплачивает на прямую поставщику, то по основной организации проводится только выплата вознаграждения от поставщика и на него выписываются закрывающие документы поставщику (Акт и СФ).
    • Если покупатель оплачивает на нашу организацию, то задолженность перед покупателем корректировкой долга переносится на поставщика, поставщику переводится оплата закупочной стоимости товара, а на разницу выставляются закрывающие документы на вознаграждение.

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

К основным плюсам данного решения можно отнести следующие: 

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

Из минусов:

  • Определенный объём ручных операций, и он возрастает с увеличением количества поставщиков (в целом решается доработками конфигурации). 
  • Проблематична обработка прайсов. Если на пример нам надо расчитать отгрузочную цену по каким-либо сложным алгоритмам, выбрать товары с минимальными ценами от разных поставщиков, подменить номенклатуру на аналоги и др.
  • Не всегда удобно хранить все товары поставщика в справочнике номенклатуры. К примеру если Вы продаёте только определенные номенклатурные группы, а прайс получаете от большого многопрофильного поставщика. (Решается исключением не нужных позиций из прайса в ручную или по договоренности с поставщиком. Как вариант на одном из проектов делали отдельное хранилище на базе регистров сведений, куда загружалась информация из прайсов, правда в данном решении пришлось доделывать и обработку прайс-лист и выгрузку на сайт.)
  • Не подходит для отражения остатков поставщика в "реальном времени".

Пути решения проблемм:

  • Доработки, доработки и еще раз доработки. :) Тут всё индивидуально и зависит от поставленных задач, количества поставщиков и товаров, частоты изменения остатков, количества и частоты изменения форматов прайсов и источников их получения.
    • В первую очередь необходимо сократить объем ручных операций - это различные загрузки документов из различных форматов (Excel, txt, csv и тд.), автоматическое создание новой номенклатуры, "закрепление" своих форматов прайсов за поставщиком , т.е. что б при выборе поставщика система автоматически подбирала настройки формата прайса этого контрагента (что в каких колонках и тд), жесткая или гибкая настройка форматов файла (потребуется ли помощь программиста если появится новый формат или изменится существующий)
    • Для сокращения объема хранимой номенклатуры и захламления справочника - использовать для хранения остатков добавленные регистры сведений. Это так же сократит время загрузки прайс-листов, но при большом количестве прайсов необходимо будет задуматься о блокировками. И позволит обрабатывать данные перед записью в регистр, к примеру делать различные наценки и т.д. Но приведет к необходимости доработки механизмов, где эти данные будут использоваться - печать прайс-листа, выгрузка на сайт и т.д.
    • Если поставщиков несколько и товар пересекается, то автоматизация заказа поставщику, т.е. какому поставщику какие товары заказывать, по минимальной цене, наличию или другим алгоритмам.
    • При большом количестве поставщиков или частых изменениях остатков - автоматическое получение прайсов из электронной почты, ftp серверов, url ссылок и пр. скриптами или регламентными заданиями.
    • Для больших прайсов - оптимизация времени загрузки, к примеру, использование ADO вместо COM  и пр.
    • Для очень большого количества записей и/или сложных алгоритмов расчетов можно использовать внешние базы данных на различных СУБД и переложить на них часть работы по загрузке информации и ее обработке, а при необходимости получать выборки уже обработанных данных в 1С.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Xolli Xolli (Xolli) 03.09.16 15:37
Есть ли описание к добавленным опциям?
2. Xolli Xolli (Xolli) 03.09.16 15:38
3. Денис Аграновский (de0nis) 03.09.16 23:12
(1) Xolli, да тут в целом почти всё в рамках типовой можно сделать. Какая конфигурация у Вас?
4. Петр Самчук (Frogger1971) 07.09.16 10:36
"Интересное" решение.... допустим у вас 10 поставщиков с прайсами по 10 000-15 000 позиций, вы продаете их все - каждый раз создавать 10 документов прихода со столькими позициями, удаляя старые приходы? или, еще "идеальный" вариант, когда остатки активно меняются в течении дня
в таких случаях функционал нужно "допиливать", использую Регистр сведений "Информационные остатки контрагентов"
platon_; корум; +2 Ответить 2
5. Ruslan (rus128) 07.09.16 10:44
Все хорошо, но количество опечаток удручает ("опреции", "опреаций", "поствщиком", "доделавать").
6. Денис Аграновский (de0nis) 07.09.16 13:08
(5) rus128, Спасибо. Опечатки вроде поправил. )
7. Денис Аграновский (de0nis) 07.09.16 13:21
(4) Frogger1971, Ну 10-15 поставщиков это еще не такой объём, при автоматической загрузке документов, особенно, если старые не удалять, а при загрузке корректировать остатки, то можно справиться :)) Хотя, конечно, уже не очень удобно.
8. Денис Аграновский (de0nis) 07.09.16 13:46
(4) Frogger1971, Ну собственно про это я написал в самом начале, что это не "идеальное" решение, а максимально ПРОСТОЕ и БЮДЖЕТНОЕ, для небольшого количества поставщиков и номенклатуры. На пример, есть клиенты, которые пару раз в месяц обновляют несколько прайсов, зачем им платить за дополнительные доработки, когда можно всё сделать на типовом?? (Не считая загрузки документов, хотя и ее можно, но не удобно :) )
Много поставщиков, номенклатуры и уже тем более "он-лайн" изменения остатков - это СОВСЕМ другая история. Про вариант с хранилищем на базе регистра сведений написано с самом конце. А там дальше на сколько хватит фантазии и денег ) Есть проект, где в автоматике 1С получает прайсы из эл. почты, FTP, URL и веб-сервисов, грузит их в регистр сведений, обсчитывает и так же автоматически рассылает покупателям (почта, ftp). Работает 20-30 поставщиков с прайсами по 5 000-150 000 строк, полет нормальный, в основном проблемы из-за изменений форматов поставщиками. Будет время, может напишу про него.
9. Сергей Огородников (Serg O.) 07.09.16 14:08
не очень "прозначный" и не удобный вариант

обычно надо ещё показывать (где-то хранить и обновлять) - остатки этого поставщика... желательно со сроком доставки
для прайсов, для "понимания" сколько есть...

для этого лучше сделать "параллельный" регистр сведений (даже не периодический) - и "подхватывать" доп.остатки в заказ покупателя... как свободный
НО! в Заказе - ввести признак (галку/флажок или статус) - что это под заказ, тогда резервировать товары можно...

а отгружать можно будет - только после реального "прихода" на склад
10. Денис Аграновский (de0nis) 07.09.16 15:34
(9) Serg O., спасибо за Ваш комментарий.
"обычно надо ещё показывать (где-то хранить и обновлять) - остатки этого поставщика... желательно со сроком доставки
для прайсов, для "понимания" сколько есть... " - это будет остаток по фиктивной организации по виртуальному складу поставщика, т.е. понимание сколько есть как раз прозрачно и даже проще чем с РС, т.к. выводится типовыми отчетами, а во многих конфигурациях и в формах номенклатуры. Срок поставки обычно один для каждого поставщика или прайса. Для большого количества поставщиков с разными сроками поставки - это решение не применимо и требует доработок конфигураций.

Параллельный РС самый оптимальный вариант, но требует и доработок функционала дальнейшей обработки этой информации. Тут всё зависит от задачи, количества поставщиков и частоты обновления данных.

Про "подхватывать" остатки в заказ не очень понял, да и не вижу смысла, просто делается заказ поставщику, а поставщик уже присылает подтверждение зарезервировал он у себя под наш заказ или нет. При поступлении от поставщика товар ставится на резерв под соответствующий заказ покупателя. Резервировать что-то у себя раньше не вижу смысла, т.к. наличие в прайсе еще не гарантирует, что поставщик нам всё отгрузит.
11. Вадим Никонов (V.Nikonov) 09.09.16 19:14
Встречаются варианты, когда вместо полноценных документов типа "Оприходование+Списание" или "Поступление+ВозвратПоставщику" используют более экономное по ресурсам "КорректировкаРегистров". В документе производят движения по единственному регистру "ТоварыНаСкладах". Цены Поставщиков регистрируют Установками Цен (Номенклатуры или Контрагента).
При этом Доработка заключается в создании Загрузчиков...
Специальный Регистр сведений по Остаткам экономичнее по ресурсам, позволяет учитывать прогноз прихода товара Поставщику... Но придется допиливать использование этого регистра во множестве мест.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа