iScala Developer

Этот вопрос не может обсуждаться в открытом разделе

Вопросов было несколько Если один из них не может обсуждаться в открытом форуме, ответьте на любой из тех, что может

Самый главный вопрос стоит так: нужен ли компании, в которой я работаю, iScala Developer. Показать толком этот продукт мне пока не смогли, рассказать на форуме о нем тоже нельзя, в инете информации мало и она противоречива. Напрашивается вывод: да ну его нафиг — работали без него и дальше будем.
С другой стороны, если окажется, что продукт потребуется в дальнейшем, а я рекомендовала его не брать, то как это будет выглядеть? Что мне было леньки докапаться до сути?

Dreamy_Helga писал(а):

Вопросов было несколько Если один из них не может обсуждаться в открытом форуме, ответьте на любой из тех, что может

Буквально только я отправил это сообщение сразу получил письмо, но решил этот текст оставить, пусть люди знают, как я "зверствую"
Теперь ветка перемещена в закрытый форум и можно обсуждать

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

Что касается информации в Интернете, то я с Вами согласен, в форумах общего пользователя информация не может быть хоть малость объективной именно потому, что в писателях представители компаний поставщиков конкурирующих продуктов, сам поставщик, естественно, будет хвалить продукт, конкурент — однозначно ругать, а Вы никогда не узнаете, кто есть кто!

А теперь по существу вопроса:
Мне хотелось бы подчеркнуть, что VBA проекты — это не панацея, необходимо соблюдать баланс стандартной и дополнительной функциональности. Мне кажется неверным подход, когда 95 % функциональности — "навесная", какой тогда смысл в самой Скале.
На мой взгляд, лучше как можно больше изучить стандартную функциональность и по максимуму приспособить ее к бизнес процессам компании. Кстати, если строить какие-то "внешние" прибамбасы, не всегда для этого нужен именно iScala Developer

В финансовом модуле нас практически все устраивает. Отсутствуют нужные отчеты (размышляю об БиАй сервере, но такое пречатление, что поставщик не очень стремится его продать — так плохо описывает мне прелести этого продукта).
Некоторые отчеты достаточно заковыристы — нужно писать обработку данных. Как я сейчас это делаю, то это сохраненки на сервере + пользовательский интерфейс в дельфи, а почему не все — скальским девелопером?
Данные для финансового модуля готовятся в других приложениях: на данный момент это самописные программы на дельфи, 1С, MS Access (досталось в наследство). Все это я должна поддерживать и, что печально, доделывать. Предпочту купить/заказать/разработать в чем-то одном — почему не в скала девелопере?
Даже если все, кроме финансов, автоматизировать, например, используя 1С, то мне не очень нравится стандартная загрузка в скалу транзакций, инвойсов и оплат — тектовыми файлами. Хочется что-то поизящнее, а главное, чтобы это делали бухгалтера, а не я. Стандартная процедура загрузки для них слишком утомиительна, надо чтобы одной кнопкой и не думать.

А почему скальским девелопером?
Ведь есть же лучший инструмент MS SQL Server Reporting Services. Это: а) бесплатно б) не занимается очень недешевое рабочее место в Скале

А в чем его преимущество для этих целей?

Dreamy_Helga писал(а):

Даже если все, кроме финансов, автоматизировать, например, используя 1С, то мне не очень нравится стандартная загрузка в скалу транзакций, инвойсов и оплат — тектовыми файлами. Хочется что-то поизящнее, а главное, чтобы это делали бухгалтера, а не я. Стандартная процедура загрузки для них слишком утомиительна, надо чтобы одной кнопкой и не думать.

Ну разве что одной кнопкой. Или iScala Connectivity. А на счет "не думать", это надо клавиатуру менять на однокнопочную, а бухгалтера на уборщицу тетю Машу, она с нажатием на единственную кнопку справится, я думаю.

Это Вы меня спрашиваете? А я, наоборот, надеялась от Вас или кого другого, бывалого, ответ получить.

Пусть думают об отражении хозяйственных операций на счетах бухгалтерского учета. А нажимать одну кнопку и ожидая сообщения "Все прекрасно" или "Все плохо, срочно зови администратора" — много ума не надо, при этом можно и о цветочках подумать, о пестиках с тычинками…

Спасибо.
Подскажите, функциональность, я подразумеваю стандартную бизнес-функциональность, разработана/ывается в этом самом девелопере? если ли доступ к исходному коду? К примеру, стандартная процедура переоценки валютных счетов работает несколько не так, как нужно бухгалтеру — переоценивается общая сумма на счете, а нужно в разрезе аналитик, и я хотела бы унаследовать/скопировать (уж не знаю, пока не знаю, поддерживает ли VB наследование) и переделать код так, как нужно бухгалтеру — это возможно в девелопере?
Какие параллели можно провести с другими системами? Например, с Ахаpta/MorphX/X++?

Отвечу кратко — НЕТ. Сама скальская функциональность на VBA не пишется. В очень ограниченном объеме можно получить доступ к процедурам. Можно обрабатывать стандартные отчеты (я этого никогда не делал, т.к. предпочитаю внешние отчеты по собственным рецептам).

Нет!

Вы не пробовали использовать VBA, встроенный в MS Excel? Там есть доступ к исходным кодам Excel? Вот примерно то же самое и в отношении iScala Developer. Пусть коллеги меня поправят, если я не прав

и в MS Excel это именуется гордо "Microsoft Excel Developer"
вопрос риторический

СПАСИБО ВСЕМ ЗА ОТВЕТЫ
мне расхотелось приобретать это чудо

Цитата:

и в MS Excel это именуется гордо "Microsoft Excel Developer" вопрос риторический

Это 5

Ок, я попробовала использовать МИФ , встроенный в эксель.
я могу открыть существующий файл, добавить новый лист, понакидывать данных в ячейки и сохранить эти изменения в каком-то.

Могу ли я с скальском девелопере создать экземпляр класса "проводка в журнале главной книги", подобавлять "строк проводки", позадавать значения свойств и вызвать метод "сохранить в бд"??? Это — к примеру.
А вообще, можете дать информацию об объектной модели скалы, доступной через девелопер?

Все, что есть — это встроенный help в iScala (vba.chm). Он у вас есть. Плюс Object Browser уже в VBA Editor. Ежели у вас нет девелоперской лицензии, то все тоже можно увидеть в Object Browser создав пустой проект хоть в том же Excel (или VB6) и сделав reference на скальские COM-объекты (SfwIII.exe и компания)

Dreamy_Helga писал(а):

Ок, я попробовала использовать МИФ , встроенный в эксель. я могу открыть существующий файл, добавить новый лист, понакидывать данных в ячейки и сохранить эти изменения в каком-то. Могу ли я с скальском девелопере создать экземпляр класса "проводка в журнале главной книги", подобавлять "строк проводки", позадавать значения свойств и вызвать метод "сохранить в бд"??? Это — к примеру.

Сомневаюсь… Если только не сделать это все за скалу самому, записав в БД "напрямую". VBA может помочь проимпортировать подготовленные данные через штатный механизм импорта. С его помощью можно будет закрыть ненужные поля в форме импорта, подчитать название файла из каталога импорта и т.п., не более. Но через iScala Connectivity, насколько я знаю, можно кое-что в этом роде сделать (то что Вы спрашиваете, т.е. с помощью мастера создать проводку. Для ГК не видел, а для склада точно знаю, что можно). Но спросить об этом надо у тех, кто этот механизм пользует, а мы пока еще не "пощупали" это руками.

А на мой взгляд, напрасно. Стоимость одной лицензии на VBA developer невелика (по крайней мере была ). Стандартную скаловскую функциональность действительно не изменишь (а стоит ли, если базовая функциональность не подходит — может программу сменить?), а вот кой-какие полезные вещи смастерить можно. Например вставить в процессе ввода данных доп. информационные экраны, или добавить в скаловское меню формы ввода данных в нескаловские таблицы и т.д. Тут все зависит от цели.

Juri писал(а):

Стоимость одной лицензии на VBA developer невелика (по крайней мере была ).

Вы забываете про VBA Runtime. Для того, чтобы смастеренный VBA проект работал, нужна лицензия VBA Runtime, а их количество должно быть равно количеству пользователей, например, если у Вас лицензировано 40 пользователей, то придется купить 1 девелопера, но 40 лицензий на VBA Runtime, а это уже немалые деньги

А ввод данных в околоскаловские таблицы можно осуществить через функциональность, которая называется "Базы данных, определяемые пользователем". Разумеется, все зависит от цели, но, есть классное консервативное правило: изменяй не тогда, когда можно изменить, а тогда, когда нельзя НЕ изменить. Перефразируя в применение к скальским VBA проектам, я бы сказал так: их надо использовать ТОЛЬКО когда без них совсем никак! И дело тут даже не в деньгах на лицензии (и следовательно цены этих самых дополнительных форм), но еще и в том, что на хотлайне, как только Вы скажете, что у Вас VBA проект, сразу умоют руки (и будут, в общем-то, правы)

Опа! Это, похоже, различия в региональной политике продаж. У нас отдельного прайса на VBA Runtime нет. Сколько лицензировано пользователей, столько и пользователей VBA Runtime (причем это было и до приобретения нами VBA developer)

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

В целом согласен, но уж не так сурово
А что касается этого:

Так волка бояться.. Если так сильно оглядываться на хотлайн, то ничего к Скале прикручивать нельзя. Я думаю, среди уважаемых посетителей форума очень немногие могут сказать, что у них стоит Скала в своем девственном первозданном (с поправкой на версионность) виде и с настройками, описанными в классической литературе Просто проекты VBA (и др.) по возможности должны быть самостоятельно разработанными. И вообще, зависимость от хотлайна должна быть минимальна. В более-менее средних и крупных предприятиях это вполне возможно.