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

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

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

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

Собственно схема автоматизации Дропшиппинга в 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С.