Различные подходы к доработке Скалы

а я про что Вам говорил:
Модуль Договора сбоку от Scala с включением туда заказов на закупку, условий поставок и платежей спасет вас.

Уважаемый, Dubrovin! Не делайте пжста ошибок в моем «погоняле». Следите за последней буквой.
Я — руководитель отдела автоматизации в одной организации в г. Москва, которая 6 лет назад зачем-то купила Scala.
Вот и думайте: кто я — сопровожденец или внедренец.

Мои контакты есть в профайле, как-то месяц назад я с вашим г-ном салимовым общался по Аське.

А Scala сама пропогандирует системы сбоку….
У любого консультанта стоит MsAccess мо всеми табличками.
Новым клиентам сейчас предлагается Рушан генератор, вроде.
Раньше Dex предлагался….. типичные системы сбоку.
У Scala ИМХО был единственный шанс сделать нормальную систему — это разогнать всех студентов и уговорить г-на Чанышева быть руководителем разработки новой системы, набрать ему несколько спецов и чтобы они сделали систему хотя бы как нынешний HR Модуль. и всех ведущих консультантов внешних перевести в функциональные советники по развитию системы, каждого на свой модуль.
сорри если это тут ОФФ….

У нас большая система сбоку (в ней вообще нет логистики — она нам не нужна, только финансы)- основные направления
контроль данных
бюджет
основные средства и НМА
и упрощение ввода данных
как нибудь будет время расскажу про нее подробно — если кому интересно будет

На встречах с сотрудниками кадровых агенств и потенциальными работодателями в ответ на мое отношение к Scala говорю «Microsoft тоже все ругают, но все же на нем работают»

Никаких Access’ов у консультантов, которые более-менее на ты с техникой не стоит. То есть присутствовать-то он присутствует, но пользуются им только те, кто не нашем в себе силы освоить «Транзакт Эскуэль». Access, хоть и является детищем того же производителя, но не всегда корректно преобразует одни типы данных в другие (а они на все 100 не всегда совпадают). Как мне сказали однажды (года 3-4 назад), что пора с ним завязывать, так я его и завязал

При хорошем опыте работы с системой и понимании процессов профайлер процентах в 98 становится не нужен. Что касается образования и опыта пользователей, то, может быть это Вам покажется странным, но иногда «с нуля» пользователя научить проще. Трудно научить того, кто гнет пальцы веером и считает все, что отличается от привычной ему системы, убогим. Другое дело, что всяких «доработок» все равно не избежать и, по-моему, это нормально. Я бы в данном случае вел речь о системе, где одна из программ является «ядром», а вокруг нее есть некоторое количество «обвязок» дополняющих или расширяющих функциональность. Особенно это касается модулей логистики, где я бы не советывал «переписывать», а по-возможности, пользовался бы стандартной функциональностью, пусть немного улучшенной (подкорректированный интерфейс и т.п.). Если нужно что-то добавить, лучше это сделать через стандартные процедуры импорта. Иногда профайлер не поможет, ибо скальская логика довольно разветвленная вещь. В одном случае идет по одному пути, при чуть отличающейся ситуации — по другому. Взять хотя бы такой пример: при перемещении запаса со склада на склад иногда номер партии передается без изменения, иногда меняется на новый. В чем разница? Да в том, что в одном случае партия перемещается целиком, а в другом — частично. Профайлер не поможет, это «зашито» внутри программы. Также не поможет он и тогда, когда результаты запроса забираются в курсор или происходит обработка данных внутри программы и т.д.
К чему это я так долго и нудно?
Хочу проагитировать за «взвешенный» подход, без излишнего махания шашкой

aav писал(а):

Никаких Access’ов у консультантов, которые более-менее на ты с техникой не стоит. То есть присутствовать-то он присутствует, но пользуются им только те, кто не нашем в себе силы освоить «Транзакт Эскуэль». Access, хоть и является детищем того же производителя, но не всегда корректно преобразует одни типы данных в другие (а они на все 100 не всегда совпадают). Как мне сказали однажды (года 3-4 назад), что пора с ним завязывать, так я его и завязал

Щас заплачу
Не довелось мне видеть таких консультантов Scala

А про данные Вы правы, но основной глюк там с битовыми полями.
а Это только в GL06 и где то в запасах тоже…
Ну и с Empty надо аккуратно.
Некоторые вещи в Access проще делать чем в Сиквеле.
Но в Сиквеле правильнее и быстрее.
Опять уходим от темы………

Принято

Вах! Мне стыдно. Передайте мои извинения г-ну Салимову.

Я никогда в Scala не работал, но посмотрите их объявления о наборе персонала….

Такие особенные штуки есть в любой приличной системе.

А мы разве с Вами не общаемся сейчас?

Ерунда получится, когда Вы будете пытаться переписать Скалу и чего-нибудь не учтете, а потом это аукнется месяцев через несколько. А стандартный импорт — механизм, при использовании которого Скала сама знает, где и что добавить/обновить/удалить. Иногда одним импортом можно сделать сразу несколько операций подряд, например, выполнить импорт заказа на продажу с поставкой, с номером счета-фактуры и с флагом, что счет-фактура уже распечатан. В результате Вам останется только закрыть проимпортированные заказы и вуаля, и проводки по расходу запасов созданы, и по покупателю, и по НДС, и статистика обновлена. Если делать это с помощью «веревочной петли и палки», то Вам придется обновить штук 20 таблиц с непредсказуемыми последствиями.
Впрочем, я ни на чем не настаиваю, здесь нет единственно правильных решений. Как учили меня в OUBS, правильное решение (при «мягкой» задаче) — то, что Вы считаете правильным.

Тетеньке не надо. Надо дяденьке
Есть такой tool, Connectivity Solution называется. Там все можно сделать автоматически, впрочем я сам не пользовал, но есть примеры создания собственных систем сканирования каталогов или VBA проектов для запуска макросов импорта данных в Скалу и без этого инструмента, в простонародье именуемого «Коньюктивитом»

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

Самый крутой специалист по «коньюктивиту» работает в Скале в Москве и зовут его Дмитрий Осипов

Попробую сегодня написать о «системе сбоку»
о ее функциях и задачах, которые она решает.
Извините, работы много, так что к концу дня ждите…

Я вот в Скале недавно, но до этого занималась разработками в другой системе. Мы ее тоже ругали. Но механизм доработки функциональности в ней был отменный: можно было добавить в «Администраторе» любой пункт меню, навесить на него свою dll, указать кому из пользователей (группе), что разрешено — гибкая единая политика доступа через стандартные и простые механизмы. Можно было хоть всю систему переписать заново, не написав НИ ОДНОЙ ВНЕШНЕЙ программы. Какие были преимущества:
1. Все модули централизованно обновлялись, никаких локальных старых версий на дисках С у пользователей.
2. Не надо было в своей прорамме заново прописывать стандартные механизмы политики доступа к данным (таблице, записи, запуску процедуры). Каждый видит и делает то, что ему положено (почти как у сервера).
3. Бизнес-логика тоже в основном была реализованав на сервере. То есть из своей программы можно было запустить хранимую процедуру из репозитория с входными параметрами, код которой открыт (вместо того, чтобы готовить текстовый файл для импорта).
4. Стандартные механизмы заново переписывать было не надо. Их можно было немного адаптировать под себя.
5. Да, и очень простой интерфейс для построения стандартных печатных форм (я сравниваю со Скальским).
Экономилась куча времени.
Когда я уходила в Скалу, я ожидала, что тут будет намного все круче и продуманней, чем было у нас. С точки зрения функционала, действительно, это так, но вот если этот функционал не подходит в силу специфики предприятия, получается, что надо начинать писать систему №2 практически с нуля. (И систему №3 для закачки данных из №2 в №1 — у нас сейчас так ). А как же тогда «полный контур», стандарты ERP?

Вот такие у меня впечатления.

И сейчас можно добавить свой пункт меню и подключить к нему любой exeшник

Стандартные печатные формы лучше всего делать в Crystal’е

Очень многое в Скале можно реализовать с помощью VBA (при условии, что в Вашей лицензии присутствует Automation Manager). Для этого Вам понадобится докупить Integrated VBA developer

Leshic писал(а):

Если в системе 2 сделать функциональность «импорт в Scala», то систему 3 писать не нужно

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

Если буду говорить глупости про Скалу, поправляйте, я еще только учусь… Только не ругайте… У нас 2.1, многое, наверное, уже в 2.2 реализовано.

Рассказываю: в девелопере Скалы можно создать проект svp, и навесить в нем свою дополнительную функциональность, загружается такой проект при входе в систему, а не при обращении к этой функциональности. Замечено: установили Скалу — грузится моментально, подключили проекты — почувствовали разницу. Казалось бы, ну и что, пользователи потерпят. У нас торговое предприятие, клиент может подойти в любое время, не заставлять же его ждать когда Скала загрузится, в ней и без того тормозов много. А раз войти в систему требуется значительное время, пользователи из нее не выходят => требуется куча лицензий. Соответственно, логично написать dll, которая загрузится только тогда, когда это нужно (можно ее из svp подгружать, наверное, я не пробовала). Зачем менеджеру загружать в память проект «Основные средства», если он пользуется только одним пунктом меню «Заказы на продажу»?

С обновлением в Скале тоже не просто. По крайней мере в 2.1 точно. На меня до сих пор наши админы дуются за то, что их заставляли обновлять клиентскую Скалу на ок. 100 машинах после установки хотфикса. У меня есть права администратора на мой компьютер, но Скала почему-то не обновилась, переставляла себе сама Может подскажите из-за чего это?

Ну а я под обновлением имела в виду следующее (как было в той системе): написали проект, сгенерили из него dll, создали пункт меню, связали с dll и кинули ее в специальную папку на сетевом диске. Заходит пользователь в систему, запустилось обновление файлов (не версий, как в Скале — а именно наших самописных dll-лек, ну и версий, кстати говоря, тоже). Они скопировались (или обновились) у него на С: в соответствующую папку, и лежат там, пока их не попросят в процессе работы. (На жесткий копируется, чтобы облегчить сетевой трафик, и с С: быстрее грузится)

И еще такой вопрос: мне вот странно, что нужно давать пользователям полный доступ на папку Scala Business Solutions NV? Как это с точки зрения безопасности?

С Кристалом мы уже познакомились, но печатные формы рисовать в Кристале все таки дольше чем в Excel, и возможностей потом у пользователей меньше: нет поиска, сортировки, и еще требуется лицензия… Оказалось, у нас ее нет… Видили бы вы, как мы изворачиваемся, чтбы добавить нужное нам поле без конвертера. Кристальские печатные формы нам внедренцы разрабатывали, а сейчас их нет.

Цитата:

Очень многое в Скале можно реализовать с помощью VBA (при условии, что в Вашей лицензии присутствует Automation Manager). Для этого Вам понадобится докупить Integrated VBA developer

Тоже уже осваивала, даже кое-что писала сама, в частности закрывала кое-какие поля, кому это не положено. Удобная штука.

С 2.1 точно нужно уходить

Стоит попробовать, причем, ходят слухи, что лучше скомпилить не dll, а exe, они, говорят, используют разные пространства памяти и проблем с конфликтами меньше.

А не пробовали снять права на проект «Основные средства» и оставить права только на «Заказы на продажу»?

Переходить на 2.2 — это значит перетряхивать все внешние программы и проекты, а они написаны под 2.1. В этом есть небольшой стопор, но переходить безусловно придется. Если в таблицу добавили хотя бы 1 поле, программу надо переписывать….

А если это бухгалтер и ему требуется и тот, и другой проект, только в разное время? Проекты у нас тоже от внедренцев остались, и логически они не разделены, как в моем примере. Насколько я помню, действительно, проекты грузятся только у тех, у кого есть Permissionы. Так что это тоже выход.

Может быть в этом случае создать 2 логина и заходить для работы с основными средствами под одним логином, а для работы с Заказами на продажу — под другим. Впрочем, бухгалтер-то как раз может подождать, когда проекты загрузятся, а вот в случае с продавцами в ситуации, которая приводилась выше, это гораздо актуальнее