Эпикор

Эра ERP закончилась?

У Краснаго Моста

Во времена, когда неподалёку от этого места был офис Эпикора, этот дом не был таким шикарным, его отреставрировали значительно позднее, сейчас только несколько моих бывших коллег мысленно представят то место и то время. Что же стало со всеми нами? Не только с теми, кто работал в питерском офисе, а более глобально: что стало с теми, кто ещё до недавнего времени работали в Эпикоре в России? Я имею ввиду программистов, аналитиков, менеджеров продукта под названием iScala, хотлайнеров, консультантов, партнёров и рядовых работников

Что произошло с клиентами Scala/iScala за последний год?

Тип лицензии никак не коррелирует с продолжением/прекращением бизнеса компаний-клиентов Эпикор в России

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

Даже Эпикор теперь готов получать документы через ЭДО :)

Электронный документ в диадок. Нижняя часть со штампом подписей

А вы? Вы уже отправляете документы своим контрагентам через систему электронного документооборота? Если нет, то может быть пора об этом задуматься? Ведь даже Эпикор уже «дозрел» :)))

Новости проекта scala.org.ru

Новостная рассылка

Похоже, в этом году знакомого нам всем мероприятия «День клиента Эпикор» не будет. Позвольте мне в связи с этим задать Вам вопрос: А Вы? Зантересованы ли Вы (были) в участии в подобных мероприятиях? Что для Вас самое важное в них? Какие темы могли бы Вас заинтересовать? Какие вопросы Вы хотели бы задать представителям Эпикора? А другим клиентам?

А знаете ли Вы что? Ожидаемые революционные изменения в iScala

Customer Day 2018

11 сентября 2018 в Москве состоялся традиционный день клиента Epicor. Никогда не пропускаю такие мероприятия. Для меня лично наиболее интересными новостными темами были 2 тезиса: первый, о том, почему нужно переходить на новые версии, а второй, заявленная революция в механизме отчётности в новой версии iScala 3.3

Электронный документооборот в iScala

Электронный документооборот в iScala. Актуальная тема

Слайды выступления на конференции пользователей Epicor iScala в Москве 11.09.2018 и комментарии по результатам обсуждения доклада с коллегами

Внеочередной выпуск рассылки новостей проекта scala.org.ru — The Show must go on!

Компания Эпикор уведомила своих клиентов об организационных изменениях, в рамках которых начиная с 1-го апреля 2018 года все консалтинговые услуги в России и СНГ будут предоставляться не отделом консалтинга, а через партнерскую сеть Epicor. Я просто не могу это не прокомментировать 🙂

Здесь нет инструкции по установке iScala. Она на сайте Epicor!

Не ищите здесь инструкции по установке iScala, ищите их на сайте Epicor! Это та самая информация, которую нужно брать из официальных источников.

Работа с модулем «Требования» в Epicor iScala: Возможные усовершенствования процедуры

Пример из практики: Предполагается, что пользователи в подразделениях вводят требования типа 0 (неопределённый тип) – имеется ли это на складе неизвестно, цены «предварительные», поставщик не указан; После этого производится предварительное одобрение руководителем отдела; После предварительного согласия руководителя подразделения кладовщик проверяет, имеется ли на складе заказываемые позиции. Если нет, он передаёт процесс дальше (закупщику), если да, меняет тип требования на 2 (перемещение между складами) и передаёт дальше; Закупщик, получив «эстафету» смотрит на тип строки, если он 2 (на складе есть необходимое количество), то ничего не меняет, если 0 (на складе нет) – меняет на тип 1 (заказ на закупку), указывает правильного поставщика, правильную цену. Передаёт дальше; Процесс утверждения снова попадает к руководителю отдела, на сей раз все цены уже окончательные. Руководитель отдела снова даёт своё согласие. Если сумма небольшая, процесс утверждения на этом прекращается, иначе, переходит к Финансовому директору и, если необходимо, то после него к Генеральному менеджеру; После финального утверждения Требование преобразуется в перемещение с основного склада на склад, ассоциированный с подразделением, или в заказ на закупку.

Если предполагается, что запасы, закупаемые у поставщика, будут сразу оприходованы на склад, ассоциированный с подразделением, сотрудник которого создал требование, тогда, вроде как и говорить не о чем. Вот только это в теории. На практике обычно за получение запасов от поставщика отвечает сотрудник склада (центрального, а не маленькой кладовки или полки в самом подразделении). В этом случае в системе логично сделать приход на центральный склад, а уже с него выдать в подразделение