Сервис коннект дарит дополнительное время продавцам.

Началось все с вопроса: — «А можно с помощью сервис коннекта импортировать заказы на продажу в iScala 3.0?». Начал разбираться а в чем собственно дело. И по мере прояснения картины возникало все большее желание как-то помочь людям. Судите сами.
Есть у нас несколько покупателей которые пользуются системами электронного документооборота, который, кроме передачи счет-фактур и накладных позволяет передавать документы в своем формате. Вот они и шлют нам заявки, что они хотят купить. Но загвоздка в том, что из этой системы можно получить документ в формате Adobe Acrobat, который можно только распечатать, либо в формате .xml, который можно обработать с помощью других программ.
Но это еще полбеды, дело в том, что у каждого покупателя 1.5-2 десятка адресов поставки и своя кодировка наших запасов. И процесс оформления заказа в нашей системе выглядит следующим образом:
• Продавец, или его помощник, смотря у кого меньше неотложных задач, распечатывают запрос покупателя, и вручную проставляют наши коды запасов, а это порядка 25- 160 позиций;
• Далее для каждого кода запаса ставят свое учетное измерение — вид запаса, по которому бухгалтерия собирает свои отчеты;
• И для каждого учетного вида запасов вводится в iScala свой заказ на продажу, как правило 3- 6 заказов.
Хороший объем рутинной работы. И вполне понятно что его делают только тогда, когда это уже срочно надо. Этот процесс сопровождается ошибками, даже потерями заказов. Что, конечно, вызывает определенные чувства у нашего покупателя, надеюсь вы догадываетесь какие.
Ну что ж задача есть, будем ее решать. Для определения адреса поставки пригодилась функциональность книги продаж — Дополнительные адреса поставки. в одно из полей (мы использовали EDI адрес) внесли код, который указывается в заявке как код получателя.
Для перекодировки кодов запаса использовали функциональность управления запасами — Прейскуранты покупателя/поставщика, в поле примечание ввели код запаса покупателя.
Затем в сервис коннекте, благо у него есть возможность выполнять запросы к базе данных, в первом «обработчике» (ToStockItemSBK) заменяем значения, которые указаны в заявке покупателя на наши, подтягиваем необходимое учетное измерение для каждого кода запаса, в общем получилось 3 запроса.
Во втором (ToSubWorkFlow)- сортируем и группируем по учетному измерению. Сделал так, что бы не загромождать первый «обработчик». Затем передаем в менеджер по одному получившемуся заказу, которые импортируются в Скалу как предварительные заказы, это было сделано для того, что бы продавцы имели некоторую свободу действий с данным заказом, например могли бы поменять склад, с которого будет производится отгрузка. При желании можно импортировать полноценный заказ на продажу, добавив еще один запрос в первом обработчике, который выбирает склад из карточки запаса.
Теперь действия продавца стали значительно проще:
• Сохранить файл .xml в определённый каталог;
• По получении письма о успешно завершившимся импорте заказа, проверить его и перевести в заказ, указав нужные склады;
• При ошибке — разобраться в причинах, как правило неправильная перекодировка кодов запасов.
И все. Заказ заведен в систему. Вместо 30 — 60 минут в первом случае, вся операция занимает 5-10 минут.
Эта ситуация когда выигрывают все:
• Продавцы тратят меньше времени на рутинную работу, освобождая себе время на действительно важные задачи.
• Покупатели получают заказ быстрее и получают то, что они заказывали.