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

VBA или МИФ? :)

VBA или МИФ?Вы заметили, что среди меток в основном разделе нет метки VBA? Конечно, я сейчас добавлю её для этой статьи, однако, лишь для того, чтобы объяснить посетителю, что материалов по VBA здесь нет 🙂

Да, я использую VBA при загрузке данных в Excel, но никогда не пользуюсь им для айСкалы. Как говорится, от слова «совсем». Не потому что не могу, в этом нет ничего такого, что было бы невозможно понять или освоить, но потому, что считаю, что есть другие более «стандартные» способы получить из айСкалы то, что хочется. На форуме достаточно много упоминаний про VBA (большинство из них очень старые), как восторженных, так и негативных, причем, негативных достаточно часто с моей стороны. Может быть это от того, что в своё время если консультант, продавец или айтишник на стороне клиента не знал, как что-то сделать в Скале, он твердил VBA-VBA-VBA, хотя в большинстве случаев всё можно было сделать стандартными средствами. В самом начале VBA использовался как для глобальных переделок функциональности, так и для привязки списка к определённому полю формы с передачей запросу значения другого поля формы в качестве параметра. Сейчас для второго не нужно никакого VBA, всё это делается стандартными средствами с помощью так называемого быстрого поиска. Более того, появились иерархические быстрые поиски и тот VBA проект, используемый в СоюзБалтКомплекте в мою бытность там ИТ директором, с помощью которого новые сотрудники выбирали код запаса в списке из 40 тысяч позиций, формируя его из отдельных компонентов, мгновенно потерял смысл.

Теперь немного про глобальные переделки функциональности, где VBA тоже часто использовался, причем иногда от Скалы оставался только лэйбл (иногда это были просто внешние приложения на VB). Я всегда задавался вопросом: зачем Скалу продали этому клиенту, если от Скалы осталось 5%, а остальное написано программистами на VB или VBA? Не проще ли было просто взять и написать всё с нуля. Разумеется, я не сторонник самописных ERP систем, но, по крайней мере это более понятно, чем взять готовую систему и изменить её на 95%, какой в этом смысл? Думаю, в большинстве случаев это было потакание клиентским хотелкам по поводу интерфейса или других «бантиков» вместо того, чтобы раскрыть ему преимущества имеющейся функциональности Скалы/айСкалы как интегрированной системы, даже, если где-то интерфейс выглядит не совсем так, как хотелось бы определённому пользователю, на мой взгляд, это не особо существенно.

Я помню, как в прошлом веке 🙂 я был на каком-то Скальском мероприятии и Сергей Шведов, в то время директор R&D, рассказывал, что через несколько лет классические ERP системы исчезнут, пользователи будут использовать интеграционные решения от разных производителей: «закупки» от одной системы, «продажи» от другой, «финансы» от третьей и они будут взаимодействовать между собой. По сути дела так и получилось. С помощью механизма Epicor Service Connect мы можем вводить заказы через какое-то приложение (десктопное или вебсайт), а заказы будут автоматически появляться в iScala и не надо для этого писать информацию напрямую в таблицы iScala (это один их самых худших сценариев интеграции/автоматизации). И это ещё один из путей при котором VBA не нужен.

Разумеется, большинство фанатов VBA-VBA-VBA 🙂 начнут со мной спорить. Но я не собираюсь спорить, я лишь высказываю своё мнение, а заодно объясняю, почему в основном разделе сайта нет упоминаний о VBA. Я не против использования VBA в ситуации, когда «нельзя не использовать» (нет альтернативы), но я против, когда его используют «где попало» (там, где можно использовать стандартную функциональность). Если Вы хотите написать оду VBA для iScala, милости прошу 🙂