О системах планирования ресурсов предприятия Scala, iScala
пользователям ERP систем Scala 5.1, iScala 2.2, iScala 2.3, iScala 3.0, iScala 3.1, iScala 3.2, iScala 3.3, iScala 3.4, iScala 3.5 (и так далее)
  • Главная
    • О проекте
      • Разъяснение о проекте и его участниках
      • Заявление / Memorandum
    • Новости проекта
    • Список опубликованных материалов основного раздела
    • Информация, перенесённая из старых форумов
    • Подписаться на новостную рассылку
  • Статьи
    • Статьи
    • Избранное
    • Мысли вслух
  • Процедуры
  • Доходчиво о сложном
    • Обучение
    • Как сделать?
    • iScala «для чайников»
    • Оч.умелые ручки
  • Структура таблиц
    • Scala 5.1 SR13
    • iScala 2.2 HF 2.3318
    • Tables structure changes history from iScala 2.2 SR2 to iScala 3.0 FSP4
    • Epicor iScala 2.3 — 2.03.3363
    • Epicor iScala 2.3 SR1
    • Epicor iScala 2.3 SR2
    • Epicor iScala 2.3 SR3
    • Epicor iScala 3.00 FSP 2 — 3.00.02254
    • Epicor iScala 3.0 FSP4 — 3.0.4267
    • Изменение структуры таблиц iScala 3.1 по сравнению с iScala 3.0 FSP4 / Table structure changes between iScala 3.0 FSP4 and iScala 3.1
    • Epicor iScala 3.1 — 3.1.0511
    • Epicor iScala 3.2 — 3.2.0317
    • Epicor iScala 3.3 — 3.3.0419
    • Epicor iScala 3.4 — 3.4.0399
    • Epicor iScala 3.5 — 3.5.0.0429
    • Изменение полей в таблицах БД iScala 3.4 по сравнению с iScala 3.2 / Difference between DB structure of iScala 3.4 and iScala 3.2
    • Изменение полей в таблицах БД iScala 3.5 по сравнению с iScala 2.2 / Difference between DB structure of iScala 3.5 and iScala 2.2
  • Материалы по модулям iScala
    • Главная Книга
    • Основные Средства
    • Книга Закупок
    • Книга Продаж
    • Заказы на Закупку
      • Требования
    • Заказы на Продажу
    • Управление Запасами
    • Установка, Администрирование
      • Настройка определений документов MSRS
    • Заработная плата
    • Структура базы данных
    • Отчётность SSRS
    • Отчётность AFR
    • Примеры отчётов
    • Примеры отчётов AFR
    • Интеграция с другими системами
    • Epicor Service Connect
  • English
  • Контакты
  • Поиск
Главная  »»»  Epicor Service Connect  »»»  Сервис коннект дарит дополнительное время продавцам.

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

11.02.2016 Автор Владимир Меньшиков

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

Рубрика: Epicor Service Connect Метки: Service Connect, xml, документооборот, интеграция, как сделать?, продавец
VK Telegram

Copyright © 2023 О системах планирования ресурсов предприятия Scala, iScala.

Gammapolis WordPress Theme by ERP & Business Consulting

Прокрутка вверх