О системах планирования ресурсов предприятия Scala, iScala
“ За последние месяцы мне довелось "впечатлиться" кастомизациями iScala у нескольких клиентов, где "внешние" программы пишут "напрямую" в таблицы iScala! Разумеется, я буду "молчать как рыба" относительно их имен, но не могу не сказать о своих впечатлениях. Вот уж это тот самый метод, противником которого я всегда являлся и продолжаю таковым быть. Не буду описывать, чем это чревато и с какими последствиями иногда сталкиваются пользователи этих приложений, у меня нет желания обсуждать что-то конкретное или, упаси Господь, критиковать своих коллег, которые это разработали, я критикую лишь подход.
  • Главная
    • О проекте
      • Разъяснение о проекте и его участниках
      • Заявление / 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
  • Контакты
  • Поиск
Главная  »»»  Избранное  »»»  Снова о разных подходах к внедрению iScala

Снова о разных подходах к внедрению iScala

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

За последние месяцы мне довелось «впечатлиться» кастомизациями iScala у нескольких клиентов. Разумеется, я буду «молчать как рыба» относительно их имен, но не могу не сказать о своих впечатлениях. Видел замечательные в своём роде внешние приложения, полностью автоматизирующие процесс продаж взамен стандартной функциональности модуля «Заказы на Продажу» iScala. Всё разработано с учётом пожеланий пользователей, с хорошим распределением обязанностей, в общем, впечатляет! Также видел «внешнюю» программу взаимодействия с банк-клиентом. Здорово проработано, существенно уменьшает рутинную работу. Программа даже понимает, когда клиент пишет в назначении платежа «оплата счетов 100234, 235, 240-242», разнося оплату по счетам 100234, 100235, 100240, 100241, 100242. По-настоящему, производит впечатление!

Но ещё больше меня впечатлило, что всё вышеописанное пишет «напрямую» в таблицы iScala! Вот уж это тот самый метод, противником которого я всегда являлся и продолжаю таковым быть. Не буду описывать, чем это чревато и с какими последствиями иногда сталкиваются пользователи этих приложений, у меня нет желания обсуждать что-то конкретное или, упаси Господь, критиковать своих коллег, которые это разработали, я критикую лишь подход.

Разумеется, гораздо проще сделать то, что просит клиент, чем убедить его в том, что писать напрямую в базу данных, это опасно, это попытка переписать стандартную функциональность iScala и это может привести к тому, что будет невозможно перейти на новую версию системы, а при изменении параметров внутри iScala приложения могут этого не учесть и появится расхождения в их работе и работе iScala. Я лично предпочитаю реализовать «внешнюю» функциональность таким образом, чтобы подготовить данные для iScala, а далее «засунуть» их туда каким-то корректным способом, например с помощью стандартного импорта или с помощью механизма Epicor Service Connect.

Помогая клиентам перейти с 2019 года на новую ставку НДС также столкнулся в одном месте с доработками системы консультантом Эпикора в 2008 году.

Это тоже впечатляет! Почти 10 тысяч строк кода — хранимые процедуры вызываются из быстрого поиска и пишут информацию в таблицы НДС, журнал счетов-фактур, журнал платежей, дневной журнал Главной книги…

И всё ради чего? Я так и не понял сакральный смысл всего этого. Даже если признать, что нужно создавать дополнительные строки проводок при печати журналов, а прямые автораспределения не работают или не удобны, а периодические автораспределения тоже по каким-то соображениям не могут быть использованы, то абсолютно ясно, что можно было подготовить данные для импорта и импортировать дополнительные строки проводок стандартным способом без всех этих ужасных хранимых процедур.

А дело, на мой взгляд в том, что в своё время на должность директора по консалтингу Эпикор взял человека, который очень хорошо продавал консалтинг, но ничего не понимал в iScala и потерял контроль за тем, что его подчинённые творят, внедряя iScala. Я уже писал ранее, что чем меньше опыта у консультанта, тем более он склонен «наворачивать» какие-то «внешние» процедуры вместо того, чтобы сделать всё стандартными средствами. Вот, например, у того же самого клиента, где я столкнулся с 10 тысячами строк кода, я обнаруживаю, что в карточке покупателя поле «Код поставщика» переименовано в «Код НДС» и используется в хранимой процедуре. Все дело в том, что поле «Код НДС» в карточке покупателя доступно только в том случае, когда включен соответствующий параметр в настройках компании:

В зависимости от параметра компании при использовании модуля "Заказы мна Продажу" НДС может браться из карточки покупателя или из карточки запаса

Консультант, видимо этого не знал и не нашёл ничего лучшего, как использовать для этих целей другое поле.

Через какое-то время (в 2009 году) директор по консалтингу покинул компанию, а проклятие подобных, с позволения сказать, «решений», осталось.

И к чему это я? Наверное, мой диплом по менеджменту не даёт мне пройти мимо спокойно 🙂 🙂 🙂

Рубрика: Избранное, Управление Метки: iScala, внедрение, кастомизация, хранимая процедура
VK Telegram

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

Gammapolis WordPress Theme by ERP & Business Consulting

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