пользователям программных продуктов Scala 5.1, iScala 2.1, iScala 2.2, iScala 2.3, iScala 3.0, iScala 3.1 (и так далее)

Записи автора Алексей Васильев

Multi Level Approvals for Requisitions: How it works?

Multi Level Approvals for Requisitions: How it works? Alexey Vasiliyev, principal consultant, Epicor’s partner

English version of the presentation at the Epicor client conference in Moscow 12.09.2017

MSRS channel — what to use instead in case of very old version of Scala/iScala?

Настройка принтера для печати через внешнюю программу в Scala 5.1

You can use MSRS channel to design documents with rich formatting in case of modern versions of iScala (starting from iScala 2.3 SR2 and SQL server 2008). And what if you have Scala 5.1, for example? Can anything be done for this version more or less gracefully? 🙂

Аудит системы: для чего, кому может быть полезен и на каких условиях?

Письмо про Аудит системы

Поймите меня правильно, я вовсе не пытаюсь Вам продать услуги по проведению аудита системы (я готов был бы провести его бесплатно, если Вы заинтересуете меня какой-нибудь интересной задачей и при условии, что мне не придётся нести дополнительных затрат, например, на поездку в другой город), я просто пытаюсь понять почему люди достаточно часто продолжают работать в современной версии iScala так, как будто это Scala 5.1.

Канал MSRS — что делать, если он недоступен из-за очень старой версии?

Настройка принтера для печати через внешнюю программу в Scala 5.1

Недавно изменилась форма российского счёта-фактуры. Если у Вас iScala не старее версии 2.3 SR2, тогда Вы можете использовать канал MSRS чтобы очень быстро создать или откорректировать любой документ со сложным форматированием. А что делать, если у Вас Scala 5.1, например? На прошлой неделе я общался с клиентом, которому необходимо изменить форму счёта-фактуры именно для Scala 5.1. Можно ли что-то сделать для этой версии более-менее изящно? 🙂

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

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

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

Собственный сотрудник или внешний консультант?

Директор по информационным технологиям

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

Email фильтры — это хорошо или плохо?

Добавление домена электронной почты в список надежных отправителей

Вопрос интересный, неправда ли? С одной стороны, это, безусловно, хорошая вещь, защищает нас от нежелательных писем. С другой стороны, одно неправильно отфильтрованное письмо перечёркивает весь положительный эффект. Вот, например, из-за попадания подтверждающего письма от компании, продающей авиабилеты, в нежелательную почту я этим летом дважды купил и оплатил билеты

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

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

12 сентября состоялась долгожданная конференция клиентов компании Эпикор. В конференции приняли участие сотрудники компании Эпикор, партнёры и клиенты из разных городов России, Эстонии, Финляндии, Азербайджана, Казахстана. Честно говоря, меня поразило меньшее, чем обычно, количество участников со стороны клиентов, в частности не было тех, кто ранее проявлял неподдельный интерес к планировавшемуся мероприятию…

Многоуровневое утверждение заявок в Epicor iScala: как это работает? Доклад на конференции клиентов Эпикор в Москве 1...

Слайды презентации

Часто задаваемые вопросы. В какой версии iScala изменилась длина поля «Полное имя» в карточке поставщика?

Часто задаваемые вопросы. В какой версии iScala изменилась длина поля «Полное имя» в карточке поставщика?

Этот вопрос был задан в кулуарах конференции клиентов компании Эпикор в Москве 12.09.2017. Ответ найти очень легко на странице, описывающей изменения структуры базы данных iScala разных версий

Для любителей статистики

Для любителей статистики

14 сентября проекту scala.org.ru исполняется 13 лет. Дата, конечно, не очень круглая, но достаточно солидная 🙂 И я решил в связи с этим подсчитать количество файлов (не считая служебных), записей, страниц, описаний структуры базы данных и картинок, вдруг кому-то будет интересно 🙂

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

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

В сентябре в Москве состоится долгожданное мероприятие для клиентов компании Эпикор, возможно, те из Вас, кого оно может заинтересовать, уже получили сообщение на эту тему. Возможно, Вы получите его в самое ближайшее время. Лично я всегда пытаюсь сделать всё от меня зависящее, чтобы принять в нём участие, чего не могу иногда сказать про моих коллег. А зря, в конце концов, даже не сами темы выступлений важны, хотя, разумеется, будет рассказано много интересного, а именно возможность пообщаться с себе подобными. На мой взгляд, любые рутинные дела стоит отодвинуть, чтобы не упускать подобной возможности