За последние месяцы мне довелось «впечатлиться» кастомизациями 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 году) директор по консалтингу покинул компанию, а проклятие подобных, с позволения сказать, «решений», осталось.
И к чему это я? Наверное, мой диплом по менеджменту не даёт мне пройти мимо спокойно 🙂 🙂 🙂
