Данная схема описывает взаимодействие работы интернет магазина со сторонним поставщиком складских услуг и службами доставки. Поставщик складских услуг предоставляет услуги по приему, обработке, хранению и транспортировке заказов до службы доставки.
Общая концепция работы со сторонним поставщиком складских услуг представлена на схеме(см. изображение):
Заказы собираются и подтверждаются менеджерами на сайте интернет-магазина. Затем заказы направляются на удалённый склад для комплектования и отправки их покупателю. Одновременно подтвержденные заказы выгружаются в информационную базу предприятия, в нашем случае такой базой является конфигурация «Управление торговлей». Документ «Заказ» является ключевым элементом автоматизируемого бизнес процесса, связывающим такие документы как «Реализация», «Возврат» и «Оплата». Удалённый склад после комплектования заказов передает посылки службам доставки и формирует отчет о реализации, в который включены сведения о службе доставки и номере РПО. Номер РПО – это уникальный номер почтового отправления, который назначается Заказу службой доставки. На основании этого отчета, в управленческой базе предприятия создаются документы Реализации и соответствующим Заказам присваиваются номера РПО. Присвоение Заказу номера РПО необходимо для дальнейшей однозначной привязки Оплаты к Заказу и формирования отчётности.
Реализация делится на два типа: отгрузка без перехода права собственности и продажа. Тип реализации зависит от договора, который был заключен со службой доставки и вида оплаты, выбранного покупателем. В случае отгрузки без перехода права собственности, необходимо в момент получения данных об оплате заказа создавать дополнительный документ «Отгрузка товаров».
Факт оплаты регистрируется службами доставки. Оплаты загружаются в УТ отдельными файлами с номерами РПО, по которым совершилась доставка и оплата.
При таком варианте торговли неизбежно возникает большое количество возвратов, которые также делятся на два типа. Первый тип возврата – покупатель отказывается от получения заказа до его оплаты. Второй тип возврата – возврат товара из-за брака или несоответствия характеристик после оплаты товара. С Возвратами так же работает удалённый склад, отправляя отчеты для загрузки в управленческую базу. В зависимости от типа, определяется сумма возврата денежных средств покупателю.
При такой схеме работы документ «Реализация» создается на основе данных по всем обработанным Заказам в течение дня от имени контрагентов «Служба доставки» или «Частное лицо». Данная реализация позволяет минимизировать количество документов в базе данных. Для обеспечения возможности загрузки Заказов с данными реального покупателя, необходимо модернизировать табличные части типовых документов «Реализация», «Возврат», «Оплата заказов».
Сайт разработчика: http://informser.ru/
В принципе схема понятна.
Правда есть несколько вопросов:
1.За один день создается один документ реализация, возврат, оплата (для каждой службы доставки). Есть ли возможность при загрузкесоздании документа устанавливать ограничение на количество строк в документе, т.к. в некоторых случаях это очень актуально.
2.Некоторые интернет магазины работают по частичной оплате, полня оплата производится при получении заказа (насколько я понимаю в базу УТ должно пройти две оплаты с одинаовым номером РПО). Есть ли такая возможность у вас.
1. Нет, такой проблемы не возникало. 1С ограничивает табличные части 100 0000 записей, но я думаю, что в обработках загрузки такой момент учесть не составит большого труда.
2. Дело в том, что РПО — реквизит документа «Заказ покупателя» и с впрос рабты с РПО сходится к вопросу работы в УТ с заказами, а для них частичная оплата вполне предусмотрена. Единственный нюанс, что в свое время было найдено при отладке — переплата по заказу и соответственно РПО, эти суммы должны падать как бы на аванс и зачитываться как переплата от службы доставки, а вот далее как с этими суммами работать — вопрос бухгалтеру.
Вопрос:
А как у вас обстоят дела с корректировками заказа, на каком этапе можно еще корректировать заказ, а на каком нельзя. И вообще, если статистика о корректировках
По корректировками понимаю :
— Клиент хочет поменять что то в заказе
— Клиент хочет отказатся от заказа
К счастью, эта задача отрабатывается базой данных сайта. А поставщик складских услуг забирает заказы с определенной переодичностью скриптом прямо с сайта. В других реализациях мы делали расширенную линейку статусов заказа и обрабатывали их в 1С. Думаю, что самое правильное сорнировать заказ и заводить новый с префиксом или просто новым номером и ссылкой на сторнированный заказ, тогда можно хранить историю и последний заказ будет всегда правильный!
Ну хотел услышать ответ не много другой. Давайте задам вопрос по другому:
— Клиент заказал товар
— Склад забрал его скриптом
— Клиент сделал корректировку заказа
— Что делает Склад?. Или у вас если склад забрал заказ, то клиент не может редактировать заказ. А если на складе по какой то причине не нашли товар, то что.
Я как раз и сказал в ответе, что такие ситуации обрабатываются еще на сайте, тут взаимодействуют сайт и склад. С этим обменом разбираются битриксовцы. В 1С-ку от склада попадает информация только об отгруженных заказах. Кстати в данной реализации нет возможности редактирования заказов. Т.е. заказал и все — жди… Если интересует теоретический вопрос, то могу рассказать, как это организовано в других местах, без постороннего склада?
Ну вообщем интересует, именно потому что такую систему разработали, очень много времени потратили на модуль который связан с корректировкой (корректировка со стороны заказчика или корректировка со стороны склада). Просто хочется узнать а как данная схема работает у других.
В нескольких компаниях делали, на разных платформах и битрикс и др. Делается поле — статус заказа с перечислением, Вработе, отгружен, подтвержден, не подтвержден и др. Причем такую форму работы организовывали не тольео для интернет магазина, а и для оптовой торговли с удаленными складами с организацие прав доступа по статусам(т.е. например кладовщик не может отрузить заказ ,пока нет статуса «В отгрузку» и менеджер не может изменить заказ, если стоит статус — отгружается складом или отгружено). Набор статусов индивидуален, как заказчик захочет детализировать! Ну и далее в разных вариантах — запреты на формирование документов по определенным статусам и т.д. Самый главный нюанс в статусах заказов, чтобы меняли их в одном месте, т.е. либо на сайте либо в 1С, потому что и там и там не получалось(либо как описывал выше устанавливать очередность, «В отгрузке» — может менять только склад, «В работе» может менять только менеджер или пользователь на сайте.). Либо формировать два статуса — один для сайта — один для склада. Вот как-то так. Хотя конечно в каждой компании есть нюансы.
(7) MarryJane, У нас заказы могут корректироваться в 1С. Но не всеми и не всегда. Разграничен доступ по Менеджеру (поле в заказе и у каждого 1С-пользователя есть права изменять заказы только определенных Менеджеров) и по статусу заказа. Статус заказа реализован в простейшем виде: булево поле (флаг) ЗаблокированСкладом. Установить этот флаг может кто угодно. После чего редактировать заказ могут только работники склада. Причем пока флаг не стоит, склад этот заказ не обрабатывает. Т.е. установка этого флага является одновременно окончанием редактирования (возможности изменения) заказа и началом работы склада по отгрузке товара. Таким образом четко делится ответственность за заказ между теми, кто создает заказ и теми, кто отгружает товар по имеющемуся заказу. Схема устойчиво работает как с собственным складом (который у нас через дорогу и работает в 1С через VPN), так и со сторонними складскими/логистическими компаниями (там свой обмен информацией).
Принцип остается неизменным: пока заказ окончательно не готов, его склад не обрабатывет, а если склад заказ обрабатывает, значит его уже нельзя редактировать.
Добрый день. Заинтересовала Ваша публикация. Вы не работали с складской организацией Major?
Сейчас есть задача автоматизации обмена между сайтом, 1С:УТ 11 и Major. Они (Major) предлагают свой формат обмена xml.
Определяемся с схемой взаимодействия, пока не решили. Есть ли у Вас возможность поучаствовать в автоматизации, оплату готовы обсудить.