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

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


Перейти к публикации

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

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

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

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

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

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